我们为什么要写测试用例?

3160人阅读 评论(0) 收藏 举报
 
我们为什么要写测试用例?
 
陈能技
2007-9-25
 
原文: Why do we write Test Cases? - Ainars Galvans
 
测试用例的编写作为QC特定的概念、技能,成为唯一广泛公认的东西,这是我进入测试行业时感到很惊讶的事情。现在,过去10多年了,我终于有点明白了。现在,我是探索性测试(Exploratory Testing)的鼓吹者,我在这之前甚至没有听过这个术语和方法。但是,我现在仍然写测试用例,在一些有意义的地方,相信“银弹”适用于任何地方是错误的。
 
在上年的时候,我曾经把测试用例比喻成盾,而把测试比喻成剑。(http://www.testingreflections.com/node/view/3041),我仍然相信测试用例的创建会有两个用途或目的:
 
1) 测试用例被认为是要交付给顾客的产品的一部分。测试用例在这里充当了提高可信度的作用。典型的是UAT(可接受)级别。
 
2) 测试用例只作为内部使用。典型的是系统级别的测试。在这里测试效率是目的。在代码尚未完成时,我们基于设计编写测试用例,以便一旦代码准备好了,我们就可以很快地测试产品。
 
在转向敏捷开发的过程中,第二条失去了它的价值。我在我们公司和其他公司都看到了这样的事情。看起来要变成以下的方式:
a) 测试用例被内部使用,但是目的是可信度,而不是效率。也意味着测试用例会在测试执行过程中被不断修改和重写。
 
b) 探索性测试会取而代之,不写测试用例
 
我不回进一步去探讨a)的方式,因为很明显这种是很不可靠的测试管理 – 你不能使管理层相信这是低效的利用资源的方式。也有一些时候,测试用例被创建只是用于报告测试进度。比如说,我们有80%的测试用例编写了,而其中70%通过测试。我已经在抨击这种方式,并且还会继续抨击它。因为这是典型的用缺陷数字来衡量质量,用测试用例个数来衡量测试进度的错误方法。
 
上面两种方式是否正确依赖于我们是否需要可重用的测试用例。我相信回归测试用例的编写和自动化测试脚本的编写有很多共同点。甚至可以说它们有3个级别:
 
1、 纯探索性测试
2、 执行编写好的测试用例
3、 执行自动化测试脚本
 
从上到下,设计所需的时间要不断增加,但是测试执行的时间不断减少,因为自动化测试可能仅会验证你在脚本里写好要验证的东西,那就意味着你要预测什么缺陷会出现。而在手工测试过程中,你可能看到间接的证据表明存在某些缺陷。测试用例越详细,测试人员已经测试的时间就会越多(现在会执行得更快了),能找到那些间接验证的问题的可能性越低。
 
讲了这么多理论,现在来点实践性的东西。我在新项目是按下面的方式做的:
 
首先,我会找出所有在第一个版本中界面自动化失效的地方。这可能会与那些只发布一次的项目不一样,但是我在那些方面没有什么经验。当然单元测试像JUnit执行指定的API函数也会很有用,能被开发人员很好地创建,但是测试人员有时候也应该帮助一下他们。
 
接下来,在测试执行周期中,我不会写任何测试用例。我只会在版本发布后更新测试计划,详细地写出被测试功能特性的列表,以及对应有哪些功能特性不生效、对应的缺陷ID。在版本发布后,我创建详细的测试用例文档描述怎样调用每个功能特性,输入什么数据等等。看起来像是文档,但是有着不同的目标和用途:目的是让回归测试执行更快速进行。例如,我把数据附加上去,从而减少准备数据的时间;我细化一些琐碎的测试用例,测试人员(新手除外)会添加错误处理的一些细节。
 
我尝试使用测试白板(Testing Dashboard)去替换正式的包含测试用例执行/通过/失败/未执行等信息的测试报告。有时候,我只是通过非正式的所谓我的感觉之类的东西来沟通进度,而这其实是PM(项目经理)想要知道的,而不是测试用例的数字。
 
 
0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:3719713次
    • 积分:48873
    • 等级:
    • 排名:第64名
    • 原创:959篇
    • 转载:211篇
    • 译文:96篇
    • 评论:1021条
    我的微博
    最新评论
    我的博客