由于软件测试的复杂性，我们企图使经过测试的软件做到零缺陷是不可能的，而应该以用户的需求要求为检验标准，从而做到足够好的测试。权衡投入/产出比的原则：不充分的测试是不负责任的；过分的测试是一种资源的浪费，同样也是一种不负责任的表现。因为我们没有办法充分届定什么样的测试是不充分的， 什么样的测试是过分的。所以，再软件开发过程中应在早期开展各种质量保证活动，以用户需求为标准，制定低测试通过标准和测试内容，尽早和不断的测试。通过制定严格的测试计划和详尽的测试方案，按照需求的质量要求进行验证和确认测试，并尽可能多地发现缺陷。在设计测试用例时，测试用例应由输入数据和与之对应的期望输出结果及其执行步骤和运行环境等几部分组成，在输入数据和执行条件应考虑正面的和负面的两种情况。在文档和代码的修改过程中，需要防止因为修改而带来新的错误（修改验证与回归测试），在改错之后一定要马上重新测试，以免引入新的错误。回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多的错误出现的现象并不少见。对每一个测试结果分析并进行记录，防止以后发生类似的错误。妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。

    测试可能永无休止。测出所有的缺陷和和修复才停止测试是不可能的。我们可以在某一点上，停止测试和交付软件，问题是何时停止。实际上，测试是预算，时间和质量的折衷。它是受利润模式驱动。悲观的，可惜也是常用的决定测试停止的办法，当任何一个或几个所分配的资源--时间，预算，或测试用例枯竭。 乐观的停止规则是停止测试时要么可靠性符合要求，要么是继续测试的花费与将来的收益相比得不偿失。这通常需要在测试中使用可靠性模型来评价和预测。每一评价需要反复运行以下循环：失败数据采集--建模--预测。

    软件测试的花费可以很高昂。自动化是一个节省时间和成本的好办法。软件自动化测试的工具和技术，往往苦于缺乏通用的适用性和伸缩性。原因是显而易见的。为了实现测试过程的自动化，我们必须有一些办法，能够依据软件需求或规格设计说明书，针对测试对象，自动生成测试用例，测试脚本并能自动执行，自动验证其正确性。我们还没有一个完全能达到此一目标而颇具规模的系统。一般来说，大量的人为干预，都需要测试。自动化程度仍停留在自动化测试脚本的水平。