第一章 用例的五个构成元素：
1. 用例标题
2. 前置条件
3. 测试步骤
4. 期望结果
5. 后置条件
下面从这五个元素的角度，去剖析如何编写测试用例。
1.1 用例标题
用例标题就是测试点名称。
用例标题的作用： 说明这个用力的测试目的。
用例标题要做到： 见题知意且言简意赅。要做到他人看到标题就知道测的是什么，同时能多简洁就多简洁。即简洁的同时体现测试目的。
用例标题的字数： ≤30字。
用例标题的公式： 主体（可忽略）动词+名词+结果（可忽略）
（谁做了什么产生了什么影响）
* 每个案例对应一个测试的点。每个点都是用户的一种操作行为。
1.2 前置条件和测试步骤
用例的前置条件就是在测这个用例之前你要先准备的环境和数据。
用例标题的公式：主体（可忽略）动词+名词+结果（可忽略）
用例标题的重点是动词。
前置条件和测试步骤的区别：
前置条件：动词 发生前 的所有原有的环境以及数据都是前置条件。
测试步骤：动词及动词 发生后 的结果都是测试步骤。
*前置条件是测试这个用例前需要准备的环境和数据，所以没有测试步骤详细，但不能简洁到有歧义。
1.3 测试步骤
用例步骤就是如何来测从而达到测试的目的。
测试步骤是用例的精髓。步骤就是一步一步的操作过程。
只需精简明确地告诉别人在哪做什么操作即可。如要怎样做什么操作，这个操作后要如何检查产生的结果等。
如【登录控制台，打开xx页面，点击xx按钮】这种就没必要写上去，既浪费时间还会给用例的维护带来成本。
*用例步骤不能写的过于详细。
1.4 期望结果
期望结果对应的是测试步骤，每一个测试步骤都对应一个期望结果，即做了这个操作后，希望它产生的后果。
用例中的测试步骤1、2、3对应期望结果中的1、2、3。
理论上每一个测试步骤 都有 与之对应的期望结果，但有些测试步骤不需要关注其对应的操作结果，这种期望结果可以不写。
期望是从 用户的角度 出发。
期望结果： 用户做了某个操作后期望能够得到的反馈
实际结果： 用户做了某个操作后开发程序返回的结果
执行用例时只有 实际结果=用例结果 时案例才可以pass
*一切以用户的体验为主。
1.5 后置条件
与前置条件对应，即执行完这个用例后需要还原环境，否则会给下个用例带来影响。
一般写功能用例时，后置条件基本不用太关注，因为测试环境本来就需要多样化才能模拟用户的环境，若每次执行用例都保持一个纯净环境则带来的测试工作量也大，而且也不能很好地体现测试环境的多样性。后置条件一般是自动化需要做的，因为自动化需要保持环境的独立性，彼此不依赖，执行完一个案例后需要将这个案例创建的数据、策略等全部清空，防止影响下一个案例。
第二章 用例规范
2.1 一般的用例规范
- 每个文件夹下不能超过10个测试用例。
- 每个用例的步骤不能超过8步(算整个案例测试步骤，比如测试步骤和后置条件中执行1-3步)。
- 测试用例不写“编号”和“测试步骤名称”。
- 每个测试用例一个测试点，用例标题不宜过长，需要精简明了。
- 详细测试需求点、测试步骤和预期结果必须体现测试目的和测试重点。
- 测试用例中需要用到附件的，需附上文件和文件存放路径；(附件大于1M可指定路径)。
- 预期结果要量化和直接化，减少用例执行的沟通成本。
- 测试用例设计时需考虑测试执行效率，功能用例执行10分钟原则：用例里用到的数据或样本、脚本需要在备注里附上。
- “测试步骤”和“预期结果”必须可实现和可执行。
- 测试用例需验证客户业务，不能只检查配置和页面，除非为纯页面测试。
- 体现强关联，去掉弱关联；
强关联：案例中缺少此步骤就无法达到案例目的；
弱关联：案例中缺少此步骤可以达到案例目的；
*对于大家都知道或应该清楚的点不用体现在用例中。 - 测试用例需要有正反对比验证：
开和关的对比、匹配和不匹配对比、输出结果的对比等。
这种用例可以合并，减少用例冗余。 - 提示内容不用写的太具体，说明大概意思即可，后面修改了提示需要返工用例。
- 用例里不能有具体的版本号
- 模块备注尽可能详细，便于测试和观察测试点。
- 测试方法可实现，测试数据贴近于用户环境。
- 和其它功能、第三方之间有关联的测试场景有没有遗漏。
- 标题精简，需要体现测试目的。
- 模块目录中的备注足够详细，能支撑其它人快速理解特性和提高测试效率。
- 测试结果的检查要站在客户的角度进行测试和验证。
- 页面的测试需要覆盖多款浏览器的测试。
- 不能把多个检查点放在一个用例上，这样会出现执行漏测或前面失败了后面就不执行了，问题发现滞后。
- 多个案例之间在步骤上是互相覆盖的，需要合并：如测最长字符和包含特殊字符这两个测试点可以合并为一个案例。
- 用例里不能出现有歧义的词，阐述需要清晰，不能两个人执行同样的案例可能会产生两种执行结果。
- 用例需要专业性，不能出现口语化的词语。
- 期望结果需要明确性，不能出现模糊的词语；如可能、如果、符合要求等。
2.2 可维护性规范
- 测试用例中不能出现页面配置路径，如：系统配置-网络配置-网络接口。
- 测试用例中不能出现操作过程，如：打开XX目录下文件，点击什么；直接写需做的操作即可。
- 测试用例需用到的例行检查点、公共检查点、后台、调试、配置文件等查看方法统一写到模块备注。
第三章 如何划分用例等级
3.1 现用例等级是怎么划分的？
一般在一个模块里的案例按照等级进行划分时，遵循下面的比例：
BVT-冒烟测试(10%)： 模块最基本的功能验证(含常用部署、基本关联)，推荐1级用例的20%左右；
Leve1(30%)： 基本需求点，基本逻辑，基本可靠性，基本关联，基本用户场景；
Leve2(40%)： 常见功能/逻辑细化点/专项细化点，常见关联/容错/边界值/用户场景；
Leve3(20%)： 错误提示，极少测试的用例，非常见部署方式/用户场景/容错/边界值等。
3.2 为什么要这样划分用例等级？
BVT的案例应该是最基本最简单的案例，如一个功能模块的增删改就是最基本的；
level1是基本的功能需求基本操作相关的。 如上面说的增删改，增可能有多种增加方式，BVT只是最基本的操作，level1是对BVT的一种补充；
level2是一些内部逻辑细化点或一些常见的异常操作。 Level2的异常是对用户来是比较常见的，是很大概率上会遇到的；
level3是可能会出现但出现概率很低的一些操作或异常场景。 level3的异常是很极端的异常，是很小概率会发生的，如不断重启之类的。
3.3 这样划分的意义何在？
这样划分的意义在于从这个等级划分的原则上看就知道BVT是最好执行的，然后等级越高难度系数越大，特别是level3这种，可能涉及到很复杂的网络部署或很异常的环境构造。
不同等级的案例需要消耗的时间和带来的影响是不一样的。当一个模块转测后，我们希望的是能快速验收这个模块的质量，那如何验收？不就是它的基本功能是不是完成了，它的基本操作是不是都能顺畅执行，在这些基本功能基本操作都没问题的情况下，再来检视内部逻辑细节处理是不是到位，最后再检视各种异常场景下的处理是不是已经合理。即从简单到困难，先保障基本功能再检验其他的发散点。
|