对于大多数应用项目(非国防、载入飞船上天、净室工程等),我们都知道,测试不是为了证明所有的功能能正常工作,恰恰相反,测试就是为了找出那些不能正常工作、不一致性的问题,也就是说,测试的一般工作就是发现缺陷 (detect bug),当然这些缺陷包括需求分析、设计等的缺陷,不仅仅是程序中的运行。测试的启动和项目启动是同时发生的,测试的重要工作是在测试用例的设计,这是随后测试执行的基础。同时,我们应该承认,测试的主要工作是在测试的执行,当自动化测试工具在功能测试中发挥作用比较困难时,测试执行的工作量还是很大的。
如何更早地发现缺陷又不增加风险?测试的本质是什么,发现缺陷还是风险评估?如何引导大家向着一个目标——产品及时高质量发布努力?
1. 首先就要向测试人员灌输一个概念——“测试的一般工作就是发现缺陷 (detect bug)”,达成共识,这是很重要。这样,测试人员,就知道什么是自己真正的工作。这一点,不仅在测试执行时发挥作用,而且在设计测试用例时更能发挥作用。
2. 测试执行阶段可以划分为两个子阶段,前一个阶段的目的非常清楚,就是发现缺陷,督促大家就是找出缺陷。测试用例的执行,应该是帮助我们更快地发现缺陷,而不是成为“发现缺陷”的障碍——使发现缺陷的能力降低。从理论上说,如果缺陷都找出来了,质量也就有保证了。所以在这一阶段,要不顾风险,就是发现缺陷,这样不仅对开发团队也非常有利,能尽早地修正大部分缺陷;对测试有利,测试效率高,后面的回归测试也会稳定,信心更充分。
3. 在代码冻结或产品发布前的稍后的子阶段,目的是减少风险,增加测试的覆盖度,这时测试的效率会低一些,以损失部分测试效率以极大降低风险、获得更高质量的收益。
4. 在前一阶段,测试用例的执行速度要低一些,测试人员多思考,多做些ad-hoc 测试,这样又帮助提高测试用例的质量,从而对随后的回归测试提供了更有力的保障。
5. 测试执行要进行有效监控,包括测试执行效率(缺陷数/KTC, KTC = 1000 test cases)、Bug历史情况和发展趋势等。根据获得的数据,必要时对测试范围、测试重点等进行调整,包括对测试人员的调整、互换模块等手段,提高测试覆盖度,降低风险
6. 测试总是是有风险的,正是始终存在的风险,使之测试更具有艺术性。