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