测试用例编写规范

        在当前软件测试越来越规范化的背景下，所有重视产品质量的公司也越来越重视测试用例库的建设。软件测试编写测试用例，就好比于开发者编写代码。在项目开发过程中，代码规范程度影响着维护成本，同理，测试用例的规范也对维护成本的影响很大。试想：如果作者编写测试用例不规范，输入输出不匹配，下次再测试相应功能的时候，测试用例就毫无作用，反而会影响测试人员的判断，导致错测漏测，无法保证产品质量。

        不同的公司会对测试用例的内容有不同的要求，但是一些基本要求都差不多，一般都需要包括标题，优先级，前置条件，测试步骤，输入数据，预期结果这些。

        测试用例规范主要考虑到：

        1.测试的覆盖；

        2.测试用例的维护；

        3.测试用例的易读性；

        4.测试执行的效率。

以下是我总结的一些测试用例的规范，不容易理解的部分我会举例说明：

1.测试用例的标题应该简要描述测试点

        测试用例的标题对于读者来讲，就是概述测试用例的主要内容，明确测试用例的意图，简单来说，就是测什么。

        我们以微信的输入框举例，我们要测试它的登录：

测试用例标题	前置条件	测试步骤
1.正常登录	软件有网	1.输入用户名密码，登录；
2.异常登录_无网	软件无网	1.输入用户名密码，登录；
3.异常登录_用户名输入为空	软件有网	1.输入用户名，不输入密码，登录；
4.异常登录_密码输入为空	软件有网	1.输入密码，不输入用户名，登录；
4.异常登录_输入错误值	软件有网	1.输入用户名密码，登录;

       

       

2.用条件而不是参数来描述测试用例的标题

        有些测试点主要是包含一些数据，例如有一个需求是“一个长度输入框的输入范围是0-100”，这类测试点有两个特点：

        ①.数据取值范围是一个范围；

        ②.系统对于允许输入的数据作出的处理和响应往往是一样的；

        针对数据类的测试点，我们需要用条件来描述测试用例的标题。以需求“一个长度输入框的输入范围是0-100”为例，我们要测试他的最大输入和最小输入。

        我们先用参数来描述测试标题，【长度0输入】和【长度100输入】，后续接手的测试人员如果出现接口的改动，输入范围变成了0-1000，可能测试人员就无从下手，在不了解的情况下，测试最大值输入就会还是按照100来输入。

        我们以条件来命名时，测试标题应该为【最大长度输入】和【最小长度输入】，

3.如果一个用例中包含有多个参数，用例中应该是每个参数的取值；

        这个特性针对参数类的测试点，这一类的测试点的特征是输入参数可选的个数是有限的，系统对每个参数值的表现不同。对于这些参数，我们设计的测试用例应该是所有参数的取值，而每个参数的取值都应该是一个测试用例，每个测试用例的标题都要表明参数的选择。如果直接在一个用例里面取所有的值，即难保证可读性，又难以保证覆盖的全面性。

        例如：在一个客户类型下拉列表里有三个选项：白金会员，黄金会员，普通会员，每个会员对应不同的折扣价格；

        那么我们的测试用例标题在命名时就应该是以下的样子（XXX表示要做的操作）：

测试用例标题	预期结果
1.白金会员-折扣计算	折扣价格为100元
2.黄金会员-折扣计算	折扣价格为150元
3.普通会员-折扣计算	折扣价格为180元

        这种模式直接就能从标题看出测试是否覆盖全面；而错误的测试用例：

测试用例标题	预期结果
1.所有会员类型-折扣价格	当会员为【白金会员】时，折扣价格为100元； 当会员为【黄金会员】时，折扣价格为150元；        当会员为【普通会员】时，折扣价格为180元；

          

        像这样的测试用例，难以判断测试是否覆盖全面，后续需求做出变更后，要考虑到变更点对整个用例的影响，比如，删除了黄金会员+普通会员的折扣价格改变为150元，在修改用例时，就有修改错误的可能性，比较难维护。

4.测试用例应该保证相互独立性，不要在测试用例中引用别的测试用例：

        在我们测试的时候，有一些重复的操作是不可避免的，所以我们设计的测试用例不可避免的有重复部分，在设计测试用例时，切忌不能相互引用，相互引用会导致测试用例的内容变多，不仅测试执行者在执行测试用例时容易遗漏，也不利于测试计划的安排，还会给后期用例的修改，维护和移植带来麻烦。

5.避免在测试用例中使用笼统的词汇：

        这个特点强调了测试的准确性，针对输入输出，我们的描述要尽可能的准确，输入一定要是准确的数据，不能使用【大量】、【多次】、【几次】这些词汇，而输出一定要是具体的现象，不能以【正常】，【正确】，【成功】这些词语来表示。

        比如一个在线升级需求：在服务器上有新版本时，支持主动点击按钮在线升级，点击的时候弹窗确认并提示客户服务器上的新版本号。

测试用例标题	前置条件	测试步骤	预期结果
正常升级	软件处于有网环境，服务器上有新版本XXX。	1.点击【更新】按钮； 2.确认升级；	2.升级成功
异常升级_无网	软件处于无网环境，服务器上有新版本XXX。	1.点击【更新】按钮；	1.升级失败
。。。

        其他人看到这个测试用例就会很懵逼，升级成功是什么意思，升级失败又是什么表现，没有详细的输出描述，就只能去找相应的开发人员，甚至去找产品经理核对需求；正确的测试用例应该是：

测试用例标题	前置条件	测试步骤	预期结果
正常更新	软件处于有网环境，服务器上有新版本XXX。	1.点击【更新】按钮； 2.确认升级；	2.软件弹出下载安装进度条，安装完成后，版本号为XXX
异常	软件处于无网环境，服务器上有新版本XXX。	1.点击【更新】按钮；	1.软件提示：网络异常，升级失败；

6.明确测试步骤与预期结果的对应关系

        在我们设计测试用例时，针对流程类的测试点，往往最终的功能实现效果是依靠多个操作步骤达成的，每条测试用例，可能会有多个测试点，每个步骤都应当有其对应的预期结果；当然，如果有些步骤检查点已经在其他测试用例里面体现过了，就不用重复编写，这些操作步骤可以作为前置条件。

7.避免在测试用例中包含过多的用户接口细节：

        这一点其实是所有的规范里面最难把握的，因为你的测试用例要保证可读性，而又不能描述得过于具体，这一点主要是在测试用例的操作步骤里体现，如果测试用例的操作步骤写得过于详细，包括每个按钮是什么形状这种细节，这样在UI产生变动后，会难以维护，这一点在APP的测试中表现尤为明显，因为APP的按钮大多都是图标，有些功能可能很难直接通过图案表示清楚。特别是对于一些TO-B的业务软件测试来说，很难做到对业务一窍不通的测试人员直接拿着测试用例测试就能保证软件的质量，所以我们的测试用例大多时候，都需要测试人员对业务有一点理解，才能完成。

        针对这一点，我的建议是在主流程的一条测试用例中可以详细描述接口细节，其他用例则直接用业务动作来覆盖接口操作；

8.测试用例的顺序应该尽可能的安排合理

        在编写测试用例时，有的时候我们会发现，多个测试用例重复了很多次相同的步骤。

        以一个登录的需求为例，测试用例包括3条：正常登录，无网登录，退出登录。

测试用例标题	前置条件	测试步骤
正常登录	软件有网	1.输入用户名密码，登录；
异常登录-无网	软件无网	1.输入用户名密码，登录；
退出登录	软件有网，已经登录成功	1.点击退出登录；

        如果我们按照这样的顺序执行，那么我们对软件的操作一定是正常的登陆后，再退出登录进行异常登录的操作，最后又要测试一遍登录-退出登录，这就造成了测试的无意义的叠加，增加了我们的工作量，所以我们测试用例的顺序可以是：

测试用例标题	前置条件	测试步骤
1.正常登录；	软件有网	1.输入用户名密码，登录；
2.退出登录；	软件有网，已经登录成功	1.点击退出登录；
3.异常登录_无网；	软件无网	1.输入用户名密码，登录；

        这样就即保证了测试的覆盖，又提高了测试效率。