对于大型项目，软件测试的执行，除了需要很好的测试范围分析、测试计划制定和测试资源的分配与组织之外，还是有一个容易被大家忽视的策略问题。

    对于大多数应用项目（非国防、载入飞船上天、净室工程等），我们都知道，测试不是为了证明所有的功能能正常工作，恰恰相反，测试就是为了找出那些不能正常工作、不一致性的问题，也就是说，测试的一般工作就是发现缺陷 (detect bug)，当然这些缺陷包括需求分析、设计等的缺陷，不仅仅是程序中的运行。测试的启动和项目启动是同时发生的，测试的重要工作是在测试用例的设计，这是随后测试执行的基础。同时，我们应该承认，测试的主要工作是在测试的执行，当自动化测试工具在功能测试中发挥作用比较困难时，测试执行的工作量还是很大的。

    如何更早地发现缺陷又不增加风险？测试的本质是什么，发现缺陷还是风险评估？如何引导大家向着一个目标——产品及时高质量发布努力？

1. 首先就要向测试人员灌输一个概念——“测试的一般工作就是发现缺陷 (detect bug)”，达成共识，这是很重要。这样，测试人员，就知道什么是自己真正的工作。这一点，不仅在测试执行时发挥作用，而且在设计测试用例时更能发挥作用。

2. 测试执行阶段可以划分为两个子阶段，前一个阶段的目的非常清楚，就是发现缺陷，督促大家就是找出缺陷。测试用例的执行，应该是帮助我们更快地发现缺陷，而不是成为“发现缺陷”的障碍——使发现缺陷的能力降低。从理论上说，如果缺陷都找出来了，质量也就有保证了。所以在这一阶段，要不顾风险，就是发现缺陷，这样不仅对开发团队也非常有利，能尽早地修正大部分缺陷；对测试有利，测试效率高，后面的回归测试也会稳定，信心更充分。

3. 在代码冻结或产品发布前的稍后的子阶段，目的是减少风险，增加测试的覆盖度，这时测试的效率会低一些，以损失部分测试效率以极大降低风险、获得更高质量的收益。

4. 在前一阶段，测试用例的执行速度要低一些，测试人员多思考，多做些ad-hoc 测试，这样又帮助提高测试用例的质量，从而对随后的回归测试提供了更有力的保障。

 5. 测试执行要进行有效监控，包括测试执行效率（缺陷数/KTC, KTC = 1000 test cases）、Bug历史情况和发展趋势等。根据获得的数据，必要时对测试范围、测试重点等进行调整，包括对测试人员的调整、互换模块等手段，提高测试覆盖度，降低风险

6. 测试总是是有风险的，正是始终存在的风险，使之测试更具有艺术性。