参考
https://www.cnblogs.com/dulijuan/p/4474657.html
https://www.csdn.net/gather_2a/MtTagg4sNDc2Ni1ibG9n.html

https://blog.csdn.net/bit666888/article/details/81078499

通用测试用例写作规范
软件测试用例得出软件测试用例的内容，其次，按照软件测试写作方法，落实到文档中，两者是形式和内容的关系，好的测试用例不仅方便自己和别人查看，而且能帮助设计的时候考虑的更周。
一个好的测试用例必须包含足够的内容，将这些内容可以拆分为八个要素：用例编号、测试项目、测试标题、重要级别、预置条件、测试输入、操作步骤、预期输出。
1、用例编号
1）规则：是由字符和数字组成的字符串，具有唯一性、易识别性。
2）不同阶段的测试用例的用例编号
--系统测试用例：产品编号ST系统测试项名_系统测试子项名XXX（具体用例序号）
--集成测试用例：产品编号IT集成测试项名集成测试子项名XXX（具体用例序号）
--单元测试用例：产品编号UT单元测试项名单元测试子项名_XXX（具体用例序号）
2、测试项目
1）规则：对应测试用例编号中的测试子项名
2）不同阶段的测试用例项目的具体规则
__系统测试用例：对应一个功能点（功能测试）、性能指标（性能测试）界面中控件（GUI测试）等，即软件需求项
__集成测试用例：集成后的模块功能名或者内部的接口名
__单元测试用例：被测试的函数名
3、测试标题（TestCase Title）
1）规则：体现测试的出发点、关注点以及测试用例期望的测试结果；
将测试项目和测试标题串在一起表示的是在“测试标题”情况下测试“测试项目”。
4、重要级别/优先级别（TestCase Priority）
1）含义：用例的重要级别一般分为3个等级：高、中、低，具体划分依据：
（1）高级别：对应保证系统基本功能、核心业务、重要特性、实际使用频率比较高的测试用例；
（2）中级别：对应重要程度介于高和低之间的测试用例；
（3）低级别：对应实际使用频率不高，对系统业务功能影响不大的模块或功能的测试用例。
2）测试用例的优先级作用
（1）便于制定测试规程（测试用例执行的顺序）即测试过程；
（2）回归测试中依据优先级可以选择不同方法；
（3）自动化测试
（4）缺陷报告严重性和优先级
@测试用例写作范例（一）
以下测试用例是针对用例编号、测试项目、测试标题、重要级别进行举例说明：
范例【1】：系统测试用例
1针对计算器中加法功能进行测试
* 用例编号 CALC_ST_ADD_01
* 测试项目 测试加法功能
* 测试标题 两个合法数相加得到合法的和
* 重要级别 高
2针对word中打开文件功能进行测试
* 用例编号 WORD_ST_FileMenu_OpenFile_08
* 测试项目 测试打开文件功能
* 测试标题 打开合法doc文档
* 重要级别 高
3针对word中新建空白文件功能进行测试
* 用例编号 WORD_ST_FileMenu_NewFile_BlankFile_01
* 测试项目 测试新建空白文件功能
* 测试标题 内存充足时新建空白文档
* 重要级别 高
4针对手机拨打紧急号码进行测试
(1) * 用例编号 HUAWEI3c_ST_CALL_URGENTCALL_001
* 测试项目 测试手机在没有SIM卡的情况下可以拨打紧急号码
* 测试标题 无SIM卡时，在NOKIA的网络环境中拨打119
* 重要级别 高

             (2)  * 用例编号 HUAWEI3c_ST_CALL_URGENTCALL_001
                  * 测试项目 测试手机在没有SIM卡的情况下可以拨打紧急号码
                  * 测试标题 无SIM卡时，在NORTEL的网络环境中拨打119
                  * 重要级别 高

             (3)  * 用例编号 HUAWEI3c_ST_CALL_URGENTCALL_001
                  * 测试项目 测试手机在没有SIM卡的情况下可以拨打紧急号码
                  * 测试标题 无SIM卡时，在ERICSIION的网络环境中拨打119
                  * 重要级别 高

范例【2】：集成测试用例
1针对加法函数接口进行测试
* 用例编号 CALC_IT_AddInterface_01
* 测试项目 测试加法接口函数
* 测试标题 x>y求和
* 重要级别 高
AddInterface对应加法函数接口。
范例【3】：单元测试用例
1针对ctrl函数进行测试
* 用例编号 CALC_UT_Ctrl_01
* 测试项目 测试ctrl函数
* 测试标题 x=y调用减法函数
* 重要级别 高
Ctrl对应ctrl函数。
5、预置条件（Test Pre_condition）
1）含义：测试用例在执行时需要满足一些前提条件，否则测试用例是无法执行的，这些前提条件就是预置条件，设置预置条件时经常分为两种情况：
（1）环境的设置，例如测试word文档打开功能，需要提前准备打开的文档，这就是预置条件。
（2）先要运行其他的测试用例，例如测试自动取款机功能，有输入账户信息的测试用例和输入取钱金额的测试用例，则后者的预置条件就可以写为输入正确账户信息的测试用例。
2）注意（PS）：测试预置条件--是针对单个用例
测试环境--针对所有用例（测试环境有问题会导致测试活动挂起/暂停）
@测试用例写作范例（二）
以下测试用例是针对用例编号、测试项目、测试标题、重要级别、预置条件进行举例说明：
范例【1】：系统测试用例
1针对自动取款机的取款功能进行测试
* 用例编号 ATM_ST_Account_01
* 测试项目 测试ATM的账户识别功能
* 测试标题 输入正确的账户信息
* 重要级别 高
* 预置条件 无

              * 用例编号 ATM_ST_GetMoney_01
              * 测试项目 测试ATM的取款功能
              * 测试标题 取款金额不是50的倍数
              * 重要级别 高
              * 预置条件 ATM_ST_Account_01

6、测试输入（Test Input）
1）含义：指测试执行过程中需要加工的外部信息。
2）规则：避免用描述性的语言，要具体；
根据软件测试用例的具体情况，有手工输入、文件、数据库记录等。
7、操作步骤（Operation/Execute Steps）
1）规则：执行当前测试用例需要经过的操作步骤，需要明确的给出每一个步骤的描述，测试用例执行人员可以根据该操作步骤完成测试用例执行。
@测试用例写作范例（三）
以下测试用例是针对用例编号、测试项目、测试标题、重要级别、预置条件、测试输入、操作步骤进行举例说明：
范例【1】：系统测试用例
1针对word中打开文件功能进行测试
* 用例编号 WORD_ST_FileMenu_OpenFile_08
* 测试项目 测试打开文件功能
* 测试标题 打开合法doc文档
* 重要级别 高
* 预置条件 新建WORD_ST_FileMenu_OpenFile_08.doc文件，其中只有“helloWorld”字符串
* 测试输入 WORD_ST_FileMenu_OpenFile_08.doc
* 操作步骤 1.点击word文件菜单中“打开”子菜单；
* 2.选择WORD_ST_FileMenu_OpenFile_08.doc，点击打开按钮。
8、预期输出（Expected Results）
1）含义：预期输出是测试用例中非常重要的部分，要想判断被测对象是否正常工作，都需要通过预期输出来进行判定。
在编写预期输出时可以从以下三个方面来进行考虑：
（1）界面显示（操作步骤执行完毕后，界面显示的提示信息）
（2）数据库的变化（操作步骤执行完毕后，数据库中的记录会发生相应的变化）
（3）相关信息的变化（操作步骤执行完毕后，一些和被测对象相关的信息会发生变化）
@测试用例写作范例（四）
以下测试用例是针对用例编号、测试项目、测试标题、重要级别、预置条件、测试输入、操作步骤及预期输出进行举例说明，即完整的测试用例写作方法，以系统测试用例为例：
范例【1】针对论坛的注册功能进行测试
* 用例编号 DISCUZ_ST_Register_02
* 测试项目 测试注册功能
* 测试标题 用户名长度不够
* 重要级别 中
* 预置条件 无
* 测试输入 参数1 用户名：yinjidudu
* 参数2 密码：yinjidudu
* 参数3 密码确认：yinjidudu
* 参数4 邮件地址：yinjidudu@126.com
* 操作步骤 1.进入注册页面；
* 2.顺序输入以上4个参数；
* 3.点击注册按钮。
* 预期输出 1.界面提示注册失败；
* 2.数据库中查不到yinjidudu用户；
* 3.无法访问必须用户才能访问的界面。

范例【2】针对论坛的帖子删除功能进行测试
* 用例编号 DISCUZ_ST_DeletePost_06
* 测试项目 测试删帖功能
* 测试标题 删除多个帖子
* 重要级别 高
* 预置条件 登录成功且该用户有删帖权限
* 测试输入 无
* 操作步骤 1.进入删帖页面；
* 2.选择4篇帖子；
* 3.点击删除按钮，并确认。
* 预期输出 1.界面提示删除成功；
* 2.数据库中查不到这4篇帖子；
* 3.无法访问这4篇帖子对应的链接，提示帖子已删除。
范例【3】针对论坛的注销功能进行测试
* 用例编号 DISCUZ_ST_LogOut_03
* 测试项目 测试注销功能
* 测试标题 编辑帖子并上传了附件时注销
* 重要级别 高
* 预置条件 登录成功
* 测试输入 无
* 操作步骤 1.编辑帖子，并上传1个附件文件；
* 2.点击注销按钮。
* 预期输出 1.界面提示注销成功；
* 2.数据库中session表中该用户状态发生变化；
* 3.无法访问必须用户才能访问的界面。

软件测试：用例篇
本节主要内容

• 测试用例的基本要素
• 测试用例的设计方法
• 测试用例的有效性
• 测试用例的粒度和评价

测试用例的基本要素
测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包括：测试环境、操作步骤、测试数据、预期结果等要素。

评价测试用例好坏的标准：

• 用例表达性清楚，无二义性。
• 用例可操作性强
• 用例的输入与输出明确。一条用例只有一个预期结果。
• 用例的可维护性好。可维护性好包含两个方面：用例的可读性好、用例易修改。
• 用例对需求的覆盖率高。需求的覆盖率=用例的条数/功能点的个数。
• 暴露程序Bug的能力强。

测试用例的优点

• 测试执行者的依据
• 自动化测试的基础
• 评估需求覆盖率
• 用例的复用
• 基类测试的方法思路以供后续借鉴

测试用例的缺点

• 费时费力，往往在设计测试用例时花费的时间比执行是花费的时间还多。
• 测试的覆盖率无法衡量，不知道是否较全面的测试了所有功能。
• 对新版本的重复测试很难实施，存在大量冗余测试影响测试效率。

测试用例具体的设计方法
设计方法有5种：基于需求的设计、等价类、边界值、因果图、正交排列、场景设计法、错误猜测法。

基于需求的设计
RBT是基于需求的测试方法，会使测试更加有效，因为它使测试专注于质量问题产生的根源，即需求。

基于需求的测试是一种最根本的软件测试，主要关注以下两个问题：

1. 验证需求是否正确、完整、无二义性，并且逻辑一致。
2. 要从“黑盒”的角度，设计出充分并且必要的测试集，以保证设计和代码都能完全符合需求。

案例：

等价类
依据需求将输入划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。

有效等价类：对于程序的规格说明来说是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能。
无效等价类：根据需求说明书，不满足需求的集合。

案例：
超市买水果
有效等价类：苹果、桃子、香蕉…
无效等价类：牛奶、青菜…

边界值
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

案例一：
1.[1,50]:0,1,50,51
2.(1,50):1,2,49,50
3.(1,50]:1,2,50,514.[1,50):0,1,49,50
1
2
3
4
在实际的测试设计中，会将等价类和边界值结合起来使用。

案例二：
以注册邮箱的软件需求为例子
用户名要求长度为6-15位
边界值上点为：5，6，15，16 全了吗？
答案是：NO，最终我们确认的用例设计为：5，6，10，15，16
1
2
3
4
5
因果图
因果图是一种简化了的逻辑图，能直观地表明程序输入条件（原因）和输出动作（结果）之间的相互关系。因果图法是借助图形来设计测试用例的一种系统方法，特别适用于被测试程序具有多种输入条件、程序的输出又依赖于输入条件的各种情况。

• 恒等

恒等：如果原因为真，那么结果必定为真。
1

• 与

只有2个原因都为真，那么结果才为真。
1

• 或

2个原因中有一个为真时，结果就为真。
1

• 非

只有原因为假，结果才为真。
1
因果图法设计测试用例的步骤如下：

分析所有可能的输入和可能的输出；
找出输出与输入之间的对应关系；
画出因果图；
把因果图转换成判定表；
把判定表对应到每一个测试用例。

案例三：
假设业务单据的处理规则为：“淘宝618活动，订单已提交，订单合计金额大于300元或有红包，则进优惠”。

1. 首先通过分析该条业务所有可能的输入和可能的输出为：

• 输入：订单已提交、金额大于300元、有红包
• 输出：优惠、不优惠

2. 第二步，找出输入与输出之间的对应关系，经分析，有以下对应关系：

• 订单未提交，则不优惠；
• 订单未提交，金额 > 300，不优惠；
• 订单未提交，有红包，不优惠；
• 订单未提交，金额 > 300，且有红包，不优惠；
• 订单已提交，金额 <= 300，且没红包，不优惠；
• 订单已提交，金额 > 300，优惠；
• 订单已提交，有红包，优惠；
• 订单已提交，金额 >300 且有红包，优惠。

3. 第三步，根据上一步的分析，画因果图如下图：
4. 第四步，根据因果图画出判定表，如下：
5. 最终的测试用例：
   1，2，3，4，5（包含6，7，8）

因果图：

判定表：

因果法测试用例可以帮助测试人员理清输入和输出的关系，但是对于比较复杂的输入和输出，会耗费大量的时间。所以引出了下面的正交法。

正交排列
正交法的目的是为了减少用例数目。用尽量少的用例覆盖输入的两两组合。

正交试验设计(Orthogonal experimentaldesign)是研究多因素多水平的一种设计方法，它是根据正交性，由试验因素的全部水平组合中挑选出部分有代表性的点进行试验，通过对这部分试验结果的分析了解全面试验的情况，找出最优的水平组合。正交试验设计是一种基于正交表的、高效率、快速、经济的试验。

正交法中的重要概念：

• 因素：在一项试验中，凡欲考察的变量称为因素（变量）。
• 水平：变量的取值。

正交表的构成：

• 行数：正交表中的行的个数，即试验的次数，用N代表。
• 因素数：正交表中列的个数，用C代表。
• 水平数：任何单个因素能够取到的值的最大个数。正交表中的包含的值为从0到数”水平数-1“或1到” 水平数“，用T代替。

正交表的表示形式：
L=行数（水平数*因素数） 即：
L=N(TC)
L=N(TC)
正交表的两条性质：

• 每一列中各数字出现的次数都一样多。
• 任何两列所构成的各有序对出现的次数都一样多。

正交法设计测试用例的步骤：

1. 分析有哪些因素（变量）；
2. 每个因素有哪几个水平（变量的取值）；
3. 选择一个合适的正交表；
4. 把变量的值映射到表中；
5. 把每一行各因素水平的组合作为一个测试用例；
6. 加上你认为可疑且没有在表中出现的用例组合。

案例四：
以注册邮箱为例：
1. 因素（变量）：姓名、邮箱、密码、确认密码、验证码
2. 水平（变量取值）：yes(填写)、no(不填写)
3. 表中的因素数(C) >= 5；表中的每个因素数的水平数(T) >= 2；行数取最少的一个，即试验次数最少的一个。 即 ：L=N(TC)=5*(2-1)+1=6
选择正交表，这里选择了L6_2_5。
4. 生成测试用例：注意要满足正交的两条性质，表格如下：
5. 增补测试用例：
只填姓名和验证码，不填email、密码和确认密码。
1
2
3
4
5
6
7
8
9
正交表：

作业：用什么方法来设计以下两个作业，5个条件都是可填和可不填的。

查询页面：姓名、性别、学号、学校、班级

正交法设计：
- 因素（变量）：姓名、性别、学号、学校、班级
- 水平（变量取值）：填写、不填写
- 表中的因素数(C)>=5；水平数(T)>=2；行数取最少的一个。即：L=N(TC)=5*(2-1)+1=6。选择正交表，L6_2_5。
- 生成测试用例：表格如下正交表1所示：    
- 增补测试用例：
    只填姓名和班级，不填性别、学号和学校。                     

1
2
3
4
5
6
7
正交表1：

场景设计法
事件流
通俗的说，单击鼠标后不同的触发顺序和处理结果就形成了时间流。

控制流
是指按一定的顺序排列程序元素来决定程序执行的顺序。

场景设计法可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，是测试
用例更容易理解和执行。
典型的应用是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向。

错误猜测法
错误猜测法是经验丰富的测试人员喜欢使用的一种测试方法。

基于经验和直觉，找出程序中你认为可能出现的错误，有针对性地设计测试用例。
经验可能来自于在对某项业务的测试较多，也可以来自于售后用户的反馈意见，或者从故障管理库中整理bug。梳理出产品以往哪些地方容易出现问题，问题越多的地方，潜在的bug也就越多。

以注册邮箱为例：

1. 校验中特殊字符空格的处理：

• 当空格出现在前面或后面时，正规开发人员会对空格进行截取，所以不会影响；
• 但当空格出现在中间时，就会将空格认为是一个字符，就会报错。

2. 密码校验中的大小写
3. 姓名中的特殊字符
4. 密码发送是否明文

测试用例的有效性
苹果7手机微信添加了mobile单车小程序，扫码不能开锁，只能使用mobile APP开锁，测试用例未涉及到苹果7微信小程序扫码开锁。此时该测试用例就是无效的。
苹果7手机微信添加了mobile单车小程序，用例已写到了苹果7微信添加mobile小程序扫码开锁，问题被发现。此时该测试用例就是有效的。
已知某代码此处无bug，用某条测试用例来测试也没有出现bug，则这条测试用例也是有效的。
测试用例的粒度和评价
测试用例的粒度
粒度：指测试用例编写的详细程度
测试用例编写时：

1. 写的过于简单，则可能失去了测试周例的意义；
2. 写的过于复杂或详细，会带来两个问题：

• 效率问题
• 维护成本问题
• 容易限制测试人员的思维
  大多数测试团队编写的测试用例的粒度介于两者之间。而如何把握好粒度是测试用例设计的关键，也将影响测试用例设计的效率和效果。应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测试用例。

主要考虑可参考以下内容：

• 产品的质量要求
• 项目对用例的要求
• 测试时间和资源是否充足

测试用例的评价
主要有：

• 同行评审：体现了敏捷的“个体和交互比过程和工具更有价值”这一原则。
• 用户检查：体现了敏捷的“顾客的协作比合同谈判更有价值”这一原则。
• 项目组评审

本文来自 bit_ 的CSDN 博客 ，全文地址请点击：https://blog.csdn.net/bit666888/article/details/81078499?utm_source=copy