测试执行中非常有效的策略

标签: 测试工作测试工具软件测试产品
11998人阅读 评论(13) 收藏 举报
分类:
版权所有 :-)

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

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

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

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

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

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

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

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

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

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:2249380次
    • 积分:24406
    • 等级:
    • 排名:第249名
    • 原创:202篇
    • 转载:94篇
    • 译文:7篇
    • 评论:2492条
    最新评论