测试用例的产生

前面介绍到好的软件测试计划是测试活动的能够顺利开展、进行的保障，那么好的测试用例就是测试活动质量的保障。一个测试用例集合的覆盖率、测试方法的选择以及测试粒度和深度的选择直接影响到了测试活动的质量。

1.何时开始编写测试用例

我们都知道测试活动开展得越早越好。在早期我们就应当对需求和设计文档进行静态测试。阅读、分析文档，对文档中不清楚的部分进行询问，对文档中的错误进行更正。这实际上就是编写测试用例的预热，因为通过前面的对文档进行阅读、分析、提问、纠错的活动我们就可以对软件产品的需求和设计有一个较深的认识，而且这个认识会建立在设计、开发、测试人员意见一致的基础上。 这样，测试人员编写测试用例时就可以减少主观的臆断。

所以我们认为在对需求和设计文档进行静态测试的阶段就开始了编写测试用例的准备工作，并且此时已经形成了初步的测试用例文档。一旦需求和设计文档定稿之后，测试用例编写人员就可以开始按照需求和设计文档中确定的设计对测试用例文档进行修改和补充，最终形成符合最新设计的测试用例。

之后我们就需要对需求和设计文档文档条目与测试用例之间的对应关系进行梳理。最后形成- -张对应表格，如表3-1所示。

使某一需求条目或设计条目的修改可以很快定位到其对应得测试用例，以对其进行修改。而在测试时，也可以很快地看出每条测试用例覆盖了哪些需求或设计条目。

2.选定测试方法

在编写测试用例的阶段需要对测试的方法做出选择。在选择测试方法时通常采用自顶向下的方法。

首先是对测试用例适用的测试阶段进行划分，例如单元测试、集成测试、系统测试、用户验收测试等。然后在每一个测试阶段中再对测试用例的测试目标进行划分，例如在单元测试阶段要进行白盒测试，在系统测试阶段要进行功能性测试、性能测试等，这也就形成了每- - 个测试用例的测试目标。再继续往下分就可以开始分析为了实现某一个测试目标应该使用何种测试方法了。例如在白盒测试中，我们要用语句测试来覆盖所有语句，用基本路径测试来覆盖所有逻辑路径，又如用等价类划分和边界值法来覆盖功能测试中界面的输入框等。

3.测试用例的内容

每一个测试用例至少需要给出以下测试信息以供测试人员能够正确的完成测试:测试目标、测试对象、测试环境设置、前提步骤、输入数据、操作步骤和期望结果。

●测试目标:指测试用例的目的，是对测试对象进行哪方面的测试。如功能性测试、性能测试，易用性测试，压力测试等。

●测试对象:指测试用例所测试的对象，如软件产品中的某一模块的某- -功能。又如在单元测试中，测试对象可以是代码中的-一个类.函数等。在性能测试中，也可以是软件产品的某一个性能指标。

●测试环境设置:指在执行该测试用例时,需要对测试环境进行的(特殊)配置。例如在网站测试中，配置操作系统和浏览器的搭配及浏览器的配置。又如在性能测试中，配置模拟器以模拟网络中的流量、延时、带宽等情况。

●**前提步骤:**指在执行该测试用例时，需要把软件事先运行到某一 初始状态的步骤，然后再对软件进行针对该测试用例的测试。

●输入数据:指在执行该测试用例时需要事先准备好的测试数据。例如在执行性能测试时需要准备的输入数据。又如在VCard与电话簿记录的对应转化测试中，需要事先准备大量的VCard文件以备在测试时倒入手机中。对于此类的输入数据及其比对结果，测试用例编写人员一般都应该事先编写好，并以附件或连接的形式附加在测试用例中。这样的耦合的形式方便了测试输入数据的升级，避免了对测试用例本身的修改。

●操作步骤:指在执行该测试用例时，从前提步骤设置完成到比对期望结果之间需要运行的测试操作。

●期望结果:即该测试用例的验证点。通常每个测试用例设-一个验证点， 验证点过多容易造成测试用例覆盖面过大，甚至出现在多个测试用例中重复的验证点，这样的结果就是轮测试完成之后的测试报告的数据可能会不准确。例如一个测试计划集合中包含了100个测试用例，其中有5个测试用例重复地覆盖了-一个验证点。

这种情况下，当这个验证点被验证有缺陷时就会使5条测试用例无法通过测试，这明显影响了测试报告中的数据反应软件真实质量的能力。此外，测试用例的期望结果还应该注意其描述的准确性,避免产生二意。

4.测试用例的粒度

测试用例的粒度通常对测试计划的执行有很大的影响。在保证测试覆盖面的情况下，粒度越大，测试用例开发编写人员的工作量越小，测试用例执行周期越短，但对软件产品的质量保证能力越差;粒度越小，测试用例开发编写人员的工作量越大，测试用例执行周期越长，但对软件产品的质量保证能力越强。

如果测试用例的力度非常粗，有时非常细节的设计条目有所修改也不会引起到这类粗粒度的测试用例的修改(即使该用例是用来覆盖被修改的设计条目)。但是这类测试用例在被执行阶段给执行者很大的自由空间，以至于不同的执行者因其理解不同在同样的产品上执行多次会获得多个不同的结果。这对于测试新手来说一般不是件好事。

如果测试用例的力度非常细，则所有其对应的设计条目的修改都会引起到这类细粒度的测试用例的修改，这无疑加大了工作量。当然，这类测试用例规定了测试人员的执行细节，即使是测试新手也能按部就班地执行这类测试用例。因此我们应当设计粒度适当的测试用例，这样就可“进可攻、退可守”。

5.测试用例的组织方式

测试用例的编写一般 都采用测试用例套件的编写和组织形式，这是-种非常自然的组织形式，正如我们之前在“选定测试方法”小节中介绍的。我们会自顶向下将测试用例集合分为适用于某一测试阶段的集合，然后将某-测试阶段 的测试用例集合按照不同的功能进行划分，之后再将针对某个功能的测试用例按照组件的方式进行划分。组件之下就是测试套件了，一个组件可以有一到多个测试套件，如图3-2所示。

6.测试用例的审查

与其他的文档审查一样，测试用例的审查也是相关人员意见达成一致的过程。 当测试用例开发完成以后，用例开发人员就应当开始着手组织开发和测试人员对测试用例进行正式审查。

正式审查会议的组织人员需要在事先订好会议室，并至少提前一周将文档通过邮件等正式的形式发送给参与审查的角色，以便各角色对文档进行阅读，发现错误，并在文档发出到审查会议开始的这段时间内定期地提醒参与审查者提交发现的问题和文档中写得不够清楚的地方。

在收集完问题之后，组织人员应当积极地对这些问题做准备。

在审查会议上要对前期收集的问题–作出答 复。遇到会议上:提出的新问题应当详细解答，如果会议上不能立即解决的问题应当将其记录下来。在审查会议结束之后要将会议中解决了的问题、达成的一致的问题 和未解决的问题进行归档，并安排责任人对其进行跟踪，然后将以上归档和责任人的安排制成会议记录，再将会议的记录发送给与会者和其他相关人员等。

待所有审查中发现的缺陷都得到更正、所有问题都被解决以及各方的意见都达成一致之后，测试用例开发人员就可以将通过审查的测试用例文档定稿了。

7.测试用例的有效性验证

当新的测试用例:文档定稿之后，我们还有必要对测试用例进行一次有效性验证。这个过程可以在软件的非正式测试版本上进行。由于测试结果并不作为任何正式测试轮次的报告，其作用只是验证测试用例与待测产品的一致性及测试用例中所描述的测试环境等的有效性，所以测试用例的有效性验证中并不要求将所有测试用例进行测试，只需要有代表性的挑选几个能体现产品特性和环境有效性的用例进行测试即可。

最后：

1、点赞。防止以后找不到，想看的时候，在自己主页就能找到了，很方便;
2、关注我。让我们成为长期关系，下一个视频会分享更多的硬核干货;
3、本文章学习资源，均可以免费分享。

微信公众号：程序员阿沐。这样的好内容，里面还有近百篇。 谢谢你的支持！

目前测试平台项目研发已经完成并且在Github开源，有兴趣的朋友可以去Github下载
https://github.com/ooqitech/ATP

不要只做收藏从未停止，行动从未开始的人，很多事情，做着做着就无师自通了。如果在做的过程中还能稍微加点思考，稍微看一些别人的经验和做法，成长会更快，效果也会更好！加油吧，测试人！路就在脚下，成功就在明天！

一个用心码了这么多文字的人，往往渴望得到大家的认可。如果你觉得这篇文章对你有帮助，双击屏幕，给我点个赞呀！

更多软件测试资源分享微信公众号：【程序员阿沐】
软件测试技术交流群：810119819