如何编写测试用例

如何编写测试用例

用例的五个构成元素：

1. 用例标题
2. 前置条件
3. 测试步骤
4. 指望结果
5. 后置条件

下面从这五个元素的角度，去剖析如何编写测试用例

用例标题

用例标题就是测试点名称。用例标题是用来讲明这个用例的测试目的的，好的用例标题是别人看完你这个用例标题后就知道你这个用例是测什么的。但并非标题越详细越好。既然是标题，就要言简意赅，能多简洁就多简洁，但简洁的同时又要能体现你的测试目的。用例的标题最好不要超过30个字，太长会让人看起来很累也很不专业。通常能够遵循这样的公式：主体(可省略) + 动词 + 名词 + 结果(可省略)(即谁作了什么有什么影响)，但不少时候是动词 + 名词的形式。要注意：咱们写的每个案例对应的就是要测试的一个点。其实每一个点都是用户的一种操做行为。

前置条件

用例的前置条件就是在测这个用例以前你要先准备的环境和数据。同时，咱们须要将前置条件和测试步骤区分开来，但怎么区分呢，是否是仍是比较模糊？咱们从用例标题入手，咱们的用例标题是动做+名词嘛，那咱们的测试重点是动做，那产生这个动做以前的所需的全部环境和数据都算是前置条件，产生这个动做和这个动做带来的后果都算是测试步骤。这样是否是就比较清晰了。 前置条件只是说明测试这个用例须要准备的环境和数据，故前置条件不用像步骤那样写得那么详细，但也不能太过于简洁，不能有歧义。

测试步骤

测试步骤是一个用例的精髓，用例标题体现测试的目的，用例步骤就是如何来测从而达到测试的目的。即然是步骤那就是一步一步的操做过程，但这个操做过程并非写得越详细越好。咱们的步骤是来体现咱们的测试目的的，即要怎样作什么操做，这个操做后要如何检查产生的结果。这个操做多是一步，也多是几步，也多是来回循环。不论是什么操做都是告诉别人如何去作，如何去检查。但步骤不能写得过于详细，如【登陆控制台，打开xx页面，点击xx按钮】这种就不必写上去，由于这种既是浪费时间也会给用例的维护带来成本。只需精简明确地告诉别人在哪作什么操做便可，同时，写案例时须要遵循一些准则规范：

• 用例规范

1. 每一个文件夹下不能超过10个测试用例
2. 每一个用例的步骤不能超过8步(算整个案例测试步骤，好比测试步骤和后置条件中执行1-3步)
3. 测试用例不写“编号”和“测试步骤名称”
4. 每一个测试用例一个测试点，用例标题不宜过长，须要精简明了
5. 详细测试需求点、测试步骤和预期结果必须体现测试目的和测试重点
6. 测试用例中须要用到附件的，需附上文件和文件存放路径；(附件大于1M可指定路径）
7. 预期结果要量化和直接化，减小用例执行的沟通成本
8. 测试用例设计时需考虑测试执行效率，功能用例执行10分钟原则：用例里用到的数据或样本、脚本须要在备注里附上
9. “测试步骤”和“预期结果”必须可实现和可执行
10. 测试用例需验证客户业务，不能只检查配置和页面，除非为纯页面测试
11. 体现强关联，去掉弱关联；强关联：案例中缺乏此步骤就没法达到案例目的；弱关联：案例中缺乏此步骤能够达到案例目的；对于你们都知道或应该清楚的点不用体如今用例中
12. 测试用例须要有正反对比验证：开和关的对比、匹配和不匹配对比、输出结果的对比等，这种用例能够合并，减小用例冗余
13. 提示内容不用写的太具体，说明大概意思便可，后面修改了提示须要返工用例
14. 用例里不能有具体的版本号
15. 模块备注尽量详细，便于测试和观察测试点
16. 测试方法可实现，测试数据贴近于用户环境
17. 和其它功能、第三方之间有关联的测试场景有没有遗漏
18. 标题精简，须要体现测试目的
19. 模块目录中的备注是否足够详细，能支撑其它人快速理解特性和提升测试效率
20. 测试结果的检查有没有站在客户的角度进行测试和验证
21. 页面的测试须要覆盖多款浏览器的测试
22. 不用把全部检查点放在一个用例上，这样会出现执行漏测或前面失败了后面就不执行了，问题发现滞后
23. 若多个案例之间在步骤上就是互相覆盖的，须要合并：如测最长字符和包含特殊字符这两个测试点能够合并为一个案例
24. 用例里不能出现有歧义的词，阐述须要清晰，不能两我的执行一样的 案例可能会产生两种执行结果
25. 用例须要专业性，不能出现口语化的词语；
26. 指望结果须要明确性，不能出现模糊的词语；如可能、若是、符合要求等

• 可维护性规范

1. 测试用例中不能出现页面配置路径，如：系统配置-网络配置-网络接口
2. 测试用例中不能出现操做过程，好比打开XX目录下文件，点击什么；直接写需作的操做便可
3. 测试用例需用到的例行检查点、公共检查点、后台、调试、配置文件等查看方法统一写到模块备注

指望结果

指望结果对应的是测试步骤，每个测试步骤都对应一个指望结果，即作了这个操做后，但愿它产生的后果。即你们在用例里看到的测试步骤里的1,2,3对应指望结果里的1,2,3。理论上每个测试步骤都须要有一个对应的指望结果，但有些测试步骤咱们并不关注这一步骤的操做后果，那这样的指望结果可写可不写。

这里须要注意指望两字，指望的意思是说要从用户的角度出发，我用户作了这个操做后，我但愿它能给我反馈的结果。这个结果不是开发程序代码返回的结果，开发程序代码返回的结果是实际结果，执行用例时只有实际结果与用例指望结果一致时，案例才能标pass。因此在写案例或执行案例时，获得实际结果与指望结果不一致时不要轻易被开发忽悠了，一切以用户主。

后置条件

与前置条件对应，即执行完这个用例后须要还原环境，不然会给下个用例带来影响。通常写功能用例时，后置条件基本不用太关注，由于测试环境原本就须要多样化才能模拟用户的环境，若每次执行用例都保持一个纯净环境则带来的测试工做量也大，并且也不能很好地体现测试环境的多样性。后置条件通常是自动化须要作的，由于自动化须要保持环境的独立性，彼此不依赖，执行完一个案例后须要将这个案例建立的数据、策略等所有清空，防止影响下一个案例。

 

如何划分用例等级

现用例等级是怎么划分的？

通常在一个模块里的案例按照等级进行划分时，遵循下面的比例：

• BVT(10%)：模块最基本的功能验证(含经常使用部署、基本关联)，推荐1级用例的20%左右
• Leve1(30%)：基本需求点，基本逻辑，基本可靠性，基本关联，基本用户场景
• Leve2(40%)：常见功能/逻辑细化点/专项细化点，常见关联/容错/边界值/用户场景
• Leve3(20%)：错误提示，极少测试的用例，很是见部署方式/用户场景/容错/边界值等

咱们在划分用例等级时，为何要这样划分？

BVT的案例应该是最基本最简单的案例，如一个功能模块的增删改就是最基本的；

level1是基本的功能需求基本操做相关的，如上面说的增删改，增可能有多种增长方式，BVT只是最基本的操做，level1是对BVT的一种补充；

level2是一些内部逻辑细化点或一些常见的异常操做。Level2的异常是对用户来是比较常见的，是很大几率上会遇到的；

level3是可能会出现但出现几率很低的一些操做或异常场景。level3的异常是很极端的异常，是很小几率会发生的，如不断重启之类的。

这样划分的意义何在？

这样划分是有意义的，从这个等级划分的原则上看就知道BVT是最好执行的，而后等级越高难度系数越大，特别是level3这种，可能涉及到很复杂的网络部署或很异常的环境构造。

不一样等级的案例须要消耗的时间和带来的影响是不同的。当一个模块转测后，咱们但愿的是能快速验收这个模块的质量，那如何验收？不就是它的基本功能是否是完成了，它的基本操做是否是都能顺畅执行，在这些基本功能基本操做都没问题的状况下，再来检视内部逻辑细节处理是否是到位，最后再检视各类异常场景下的处理是否是已经合理。即从简单到困难，先保障基本功能再检验其余的发散点。