今天我们的软件测试培训想要跟大家分享的是测试用例正规化的内容，怎么去划分用例结构，用例正规化的必要性等内容，希望对大家有所帮助。

上周我们已经学习了测试用例的基本设计方法，各位是否学会了呢?如果没有，那你可以来达内软件测试培训班，我们一起探讨交流。如果学会了的话，那我们现在已经可以写很多很多用例了，但是这只限于我们自己执行，如果某天该功能模块不是用例编写者负责了，其他人是否也能顺利执行用例呢?该如何让其他人也能顺利执行呢?请跟小编一起看看”测试用例正规化”的相关知识吧!

用例结构正规化

对于刚刚接触测试用例的同学来说，怎么去划分用例结构?怎么去统一用例结构?这样的问题会频繁出现，那么如何解决呢?请看下图：

功能：

功能是需求产品内部固有的效能，是一个过程。

要求：

以动宾短语命名，或者加上功能两个字

子功能：

子功能是从功能拆分出来的对象，同样是一个过程。

要求：

以动宾短语命名，或者加上功能两个字

检查点：

检查点是子功能的属性、特征。

要求：

以偏正短语命名，即“……的……”

影响因素：

影响因素是使检查点发生变化的条件、场景、动作等。

要求：

描述清楚，以“当……验证…….”填写(文末有彩蛋)

黑盒层面：

为了提高测试用例的覆盖度，将产品划分好功能后，记得要加一个黑盒层面的模块。

要求：

黑盒层面需要考虑功能间、子功能间和使整体流程顺畅的三部分因素。

用例说明正规化：

用例说明这块儿是别人能不能执行好你用例的重要组成部分，都由什么组成呢?

测试目的：(高必要性)

测试目的主要是用来一句话概括阐明该条测试用例内容，一般的形式为”在XXX条件下，做XXX操作，验证XXXX”。测试目的内容需要遵照以下规则：

测试用例必须要有测试目的。即使是脑图维护，也需要在具体影响因素后面的Notes中写清楚该条Case的测试目的。

测试目的需要描述明确的预期结果。

测试说明：(中必要性)

测试说明是用来对测试用例进行补充说明的，它主要包含的内容有：

描述测试环境：

例如Case需要在慢网络环境下执行：

描述测试数据：

例如：

1) 手动构造Json文件

2) 特定的教育网站点列表

描述测试工具及其使用方法：

例如：

1) 数据库查看工具

2) 解密工具使用方法

3) 测试页面地址

前提条件：(中必要性)

前提条件被认为是组成测试步骤的一部分，是在测试步骤开始之前做需要做的前序工作。而测试说明主要描述的是测试对象之外的环境场景。当前提条件和预期结果存在相关性，对前提条件的概括就是显得有必要。

测试步骤：(中必要性)

一个操作一条步骤，一条步骤里不混合多个操作；

尽量不用界面上具体的控件或者语言描述，避免版本升级后的维护工作量；

如果涉及输入数据，那么需要写清楚具体的数据内容，例如在输入框上输入“张三”等；

避免不确定的词句使用，例如可能、大概这些会导致理解不一致的用词；

注意前后步骤之间的衔接，如果前面的步骤会作为前提对后面的操作步骤产生影响，最好能够描述得清晰一些。

预期结果：(中必要性)

预期结果中的检查点必须是具体的、可检查的对象

用例级别：(高必要性)

用例级别字段的格式：可选字段：Smoke、Normal、Important、Extend，如果要多个关键字来标识该条用例的话，各关键字之间用英文逗号隔开，比如checklist,important，如图：

小编特别奉献(一)

不知各位看到这里是否存在这样的疑问：那么多的用例我怎么知道该如何划分用例级别?请收下方法

Smoke：

提交的版本新增加的功能。

其他测试用例依赖的基本功能，该功能不通过会导致40%以上的用例失效。

Important：

验证功能使用的正确性。

用户最常使用的功能。

本软件独有的创新的功能。

Normal：

测试功能的异常情况。

在保证正常功能可以实现的前提下，验证软件的稳定性和健壮性。

Extend：

界面GUI测试。

提示信息。

压力测试。

性能方面的测试。

恭喜你已经阅读完了本文，相信你已经知道了测试用例正规化的相关内容。不知道今天的分享是否对你有帮助呢?你还想了解软件测试哪方面的知识呢?欢迎你来达内软件测试培训机构告诉我吧!

免责声明：内容和图片源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。