上周二我们已经学习了测试用例的基本设计方法，各位是否学会了呢？如果没有学会请点击传送门：测试工程师必备武器，我们现在已经可以写很多很多用例了，但是这只限于我们自己执行，如果某天该功能模块不是用例编写者负责了，其他人是否也能顺利执行用例呢？该如何让其他人也能顺利执行呢？请跟小编一起看看”测试用例正规化”的相关知识吧！
用例结构正规化
对于刚刚接触测试用例的同学来说，怎么去划分用例结构？怎么去统一用例结构？这样的问题会频繁出现，那么如何解决呢？请看下图：
功能
功能是需求产品内部固有的效能，是一个过程。
要求：
以动宾短语命名，或者加上功能两个字
子功能
子功能是从功能拆分出来的对象，同样是一个过程。
要求：
以动宾短语命名，或者加上功能两个字
检查点
检查点是子功能的属性、特征。
要求：
以偏正短语命名，即“……的……”
影响因素
影响因素是使检查点发生变化的条件、场景、动作等。
要求：
描述清楚，以“当……验证…….”填写(文末有彩蛋)
黑盒层面
为了提高测试用例的覆盖度，将产品划分好功能后，记得要加一个黑盒层面的模块。
要求：
黑盒层面需要考虑功能间、子功能间和使整体流程顺畅的三部分因素。
Ps：（测试老鸟儿请直接忽略，不过可以看看，欢迎吐槽）
用例说明正规化
用例说明这块儿是别人能不能执行好你用例的重要组成部分，都由什么组成呢？
测试目的：(高必要性)
测试目的主要是用来一句话概括阐明该条测试用例内容，一般的形式为”在XXX条件下，做XXX操作，验证XXXX”。测试目的内容需要遵照以下规则：
测试用例必须要有测试目的。即使是脑图维护，也需要在具体影响因素后面的Notes中写清楚该条Case的测试目的。
测试目的需要描述明确的预期结果。
测试说明：(中必要性)
测试说明是用来对测试用例进行补充说明的，它主要包含的内容有：
描述测试环境：
1) 例如Case需要在慢网络环境下执行
描述测试数据：
例如：
1) 手动构造Json文件
2) 特定的教育网站点列表
描述测试工具及其使用方法：
例如：
1) 数据库查看工具
2) 解密工具使用方法
3) 测试页面地址
前提条件：(中必要性)
前提条件被认为是组成测试步骤的一部分，是在测试步骤开始之前做需要做的前序工作。而测试说明主要描述的是测试对象之外的环境场景。当前提条件和预期结果存在相关性，对前提条件的概括就是显得有必要。
测试步骤：(中必要性)
一个操作一条步骤，一条步骤里不混合多个操作
尽量不用界面上具体的控件或者语言描述，避免版本升级后的维护工作量
如果涉及输入数据，那么需要写清楚具体的数据内容，例如在输入框上输入“张三”等
避免不确定的词句使用，例如可能、大概这些会导致理解不一致的用词
注意前后步骤之间的衔接，如果前面的步骤会作为前提对后面的操作步骤产生影响，最好能够描述得清晰一些
预期结果：(中必要性)
预期结果中的检查点必须是具体的、可检查的对象
用例级别：(高必要性)
用例级别字段的格式：可选字段：Smoke、Normal、Important、Extend，如果要多个关键字来标识该条用例的话，各关键字之间用英文逗号隔开，比如checklist,important，如图：
小编特别奉献（一）
不知各位看到这里是否存在这样的疑问：那么多的用例我怎么知道该如何划分用例级别？请收下方法
Smoke：
提交的版本新增加的功能。
其他测试用例依赖的基本功能，该功能不通过会导致40%以上的用例失效。
Important：
验证功能使用的正确性。
用户最常使用的功能。
本软件独有的创新的功能。
Normal：
测试功能的异常情况。
在保证正常功能可以实现的前提下，验证软件的稳定性和健壮性。
Extend：
界面GUI测试。
提示信息。
压力测试。
性能方面的测试。
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
