（转载）如何编写更好的测试用例（四）

　　这是一个故事，即五个软件质量分析师如何学会好的测试用例达到一个可测量的区别。他们经验丰富，自成管理小组，对于测试用例看起来应该像什么，每一个人都有不同的想法。一个用例罗列成从几十个杂乱、冗长的指导，到一个根本没有指导的一个矩阵。测试者是对软件几乎没有信心的商业用户。他们渴望测试，但经过一个星期后，花费的更多的时间是在试图找出做什么，而不是在实际测试中，他们非常无奈。他们的经理最后告诉分析师，他们已投入了他们议定的大量的时间，再没有更多的时间给他们了。在该点上不到一半测试才被执行。就这些，许多结果还只是个问号。一个测试者甚至在测试中写下愤怒的言辞。分析师表现出的测试者只是抱怨者，而不是很聪明的。

　　在这痛苦的周期中，分析师遇到新的测试经理。她看着测试用例，并开始了一个培训和辅导方案。她展示了好的测试用例的模样，给了他们一份核查表，并让小组在下一个软件模块中用它来写用例。该用例将在两个月后安排测试。她一个接一个接触了他们每个人并在如何改善方面给了他们具体的帮助。每一个编写者开始产出达到标准的用例。第一个星期的编写进展很慢，但在两个月期间的最后，他们都达到生产率的目标。在下一个测试周期，用例就较短，每一个都有明确的目的和准确的通过或失败的标准。尽管如此，分析者仍担心测试将又一次是棘手的。

　　测试者开始预期另一个负面的经历，但很快改变了他们的态度。他们发现，他们可以很容易地完成每一个用例，无需拨打电话或来到编写者的小隔间。他们的信心增长，而且有些人说，他们已害怕这个软件的改动，但现在他们可以看到它明显好于他们所使用的。这个话传到了销售人员，使他已经迫切地希望了解该软件。他们的经理来了，问是否他们也可以测试。测试经理在该周期并不需要更多的测试者，但和他们签约了下一个周期。技术编写者问是否他们也可以拥有用例的复件。

　　测试经理保持着一些指标的提高。当她最初到来时，分析师一天花费2到3个小时和测试者排查不好的用例。他们安排的测试时间是每个测试用20分钟，而事实上他们平均用时约45分钟。除了与测试者花费的时间外，在当前的周期中，一些分析师还花费一个小时或两个天时尝试修改用例，而不是进行他们安排的工作– 为下一个模块写用例。

　　在培训和标准确定后，下一个测试周期的指标看上去更好。没有分析师再一天花费超过一小时来帮助测试者。即使有更多的测试，因为简短的测试用例的标准，测试者可以在20分钟内完成测试，而测试往往提前一天完成。在项目结束时，分析师和测试者已确信会加快发表一个月。

附录A

测试用例核查表

 质量属性

 ● 精确的 - 只测试描述中所说的将测试的内容。

 ● 经济的 - 只有对于它的目标所需要的步骤

 ● 可重用的、自立的 - 不管是谁测试它都是相同的结果。

 ● 适合的 – 不仅对当前而且对今后的测试者

 ● 可追溯的 – 对应到一个需求

 ● 可自我清理的 - 返回测试环境到未使用状态

 结构和可测试性

 ● 有一个名称和编号

 ● 有一个明确的目标，其中包括什么需求将被测试

 ● 有一个测试方法的描述

 ● 指定设置信息 - 环境、数据、前提测试、安全访问

 ● 进行的活动和预期结果

 ● 陈述需要被保存的任何证据，如报告或抓屏

 ● 留下干净的测试环境

 ● 使用生动的用例语言

 ● 不超过15个步骤

 ● 矩阵不需要超过20分钟的时间来测试

 ● 自动脚本用目标、输入、预期结果来注释

 ● 如果可能的话，设置提供前提测试的替代品

 ● 与其他测试处于正确的商业场景顺序中

 配置管理

 ● 使用命名和编号协定

 ● 以指定的格式、文件类型保存

 ● 对应版本和受测软件相匹配

 ● 包括用例需要的测试对象，如资料库

 ● 存储为可读取形式

 ● 以受控访问的形式存储

 ● 存储在网络备份操作处

 ● 现场外存档

附录B

附录C

　矩阵模