如何编写测试用例

一、测试用例的概述、基本原则

1. 概念：为特定的目的而设计的一组测试输入、执行条件和预期的结果，以便试是否满足某个特定需求。通过大量的测试用例来检验软件的运行效果，它是指导测试工作进行的依据。
2. 明确思路：要测什么，怎么测 。
3. 基本原则
   准确性：明确的测试目标（一定要有需求文档）；
   经济性：避免一些重复的步骤（冗余）、资源的占用；
   可复用性：尽可能在类似的情况下重复使用；
   可追踪性：必须追溯到需求说明；
   恰当性：对测试环境、测试人员的要求恰当；
   完整性：考虑到各个情况，尽可能的覆盖；
   不依赖性：即便不是测试人员也能看懂并执行测试用例。
4. 测试用例的重要性
   1）测试用例是软件测试的核心。（影响软件测试的因素很多，如软件本身的复杂程度，开发质量，测试方法和技术的运用，但有些因素是客观存在的，不可避免的，如IT团队的流动，环境，情绪等。）
   2）评估测试结果的基准：测试用例的通过率以及错误率，是测试结束的一个重要依据，用来判断该软件测试结果是否通过，是否达到上限的标准。（测试工作结束的标志的什么？用例的通过率。）
   3）保证测试时候不遗漏测试功能点，可以在测试人员疲累的时候起到一个牵引的作用。（全面性）
   4）在编写测试用例的过程，可以熟悉需求，对系统架构或者业务流程有一个整体的，深入的了解。（不依赖性）
   5）好的测试用例不仅方便自己和别人查看，而且能帮助设计的时候考虑的更周全，因此测试用例的写作和设计一样，也是非常重要的。测试用例要有执行性（指导性）。

二、测试用例的八大要素

1. 用例编号：产品名-测试阶段（单元测试、集成测试、系统测试、验收测试）-测试项-xxx（如：xx电商-继系统测试-登录-0001）。
2. 所属模块：对应一个功能模块（细分功能） 子模块 手机号 密码 验证码。
3. 测试标题：直接对测试点进行细化得出，输入内容+结果（手机号为汉字时，界面提示格式非法）。同一功能模块标题不能重复（因为标题是来自测试点）。
4. 重要级别：高/中/低 （先看对于当前迭代而言、再看对于整个软件）。
5. 预置条件：需要满足一些前提条件，否则用例无法执行。
6. 测试输入：需要输入的内容，根据具体情况来设计（跟步骤结合起来一定要具有指导意义）。
7. 操作步骤：明确给出每个步骤的描述，执行人员可以根据该步骤完成执行工作。
8. 预期结果：根据预期输出比对实际结果，来判断被测对象是否符合需求，（预期结果唯一，不能出现“是否或者”，且以需求文档为依据）。
9. 实际结果：录入执行结果。

三、如何编写测试用例

1. 对测试需求进行分析，依照不同的功能模块列出测试点。
2. 选择等价类，边界值，错误推测法等测试用例设计方法，细化测试点分解为不同的测试标题，并补充相应的测试步骤及测试数据，预期结果。
3. 测试用例覆盖所有的用户需求，包括单个功能及功能业务的覆盖，正面（有效等价类）和反面用例（无效等价类）的覆盖。
4. 编写时注意测试用例编写格式要求，元素包含测试编号，测试标题，预置条件，不存在冗余，重复，二义性（即可能，也许，或许）等 。

建议：

1. 功能划分时，一个测试用例集对应一个功能模块（可读性）。
2. 测试用例划分时，一个测试用例对应一个功能点的一种情况（条理清晰）。
3. 测试用例要有一个简单的目的描述，有助于读者对测试用例的理解。
4. 测试用例要有明确的预置条件，包括环境，数据，场景（弱网/余额不足）。
5. 测试用例的步骤描述要简单，清晰，一步就是一步，比如第一步：用户登录；第二步，用户点击“用户信息”；第三步，用户修改姓名为“张&三”；第四步，用户点击保存（可操作性）。
6. 测试用例的数据要明确，特别是测试输入和预期结果，比如，测试输入：用户：张三，李四，王二，预期结果为：张三，李四，王二（可操作性）。

四、用例评审的重要性

1. 无论是初级测试工程师，还是高级的，专家级的，设计出来的测试用例都需要经过评审。
2. 测试用例一般分配到个人进行设计，设计用例的人并不知道用例在具体执行的时候是否有问题，不能保证自己设计的用例能覆盖完全。
3. 保证测试人员和开发人员对于被测试功能的理解的一致性，避免测试过程中针对bug测试人员和开发人员扯皮 。
4. 需求人员参与评审，能帮助设计用例的人找出更多的问题，经常在测试的时候，有些细节是无法从需求文档上得知的，需要频繁和需求人员沟通。
5. 若项目是外包或人员是外包，则每完成一项用例编写工作，先在内部团队评审，通过后再交付给客户进行评审，以确保用例质量。
6. 基本上测试排期是按照用例数量来评估工作量，若用例不完整，工时给少了，实际测试的时候将付出惨痛的代价（各种疯狂加班填坑）。

五、用例评审的流程

1. 评审材料（用例）。
2. 提前（2天）发布评审通知（OA通知，邮件，或者讨论组发布信息），同时将评审材料发送给评审组的成员，以节约沟通成本主要的参与评审人员：项目经理，测试负责人，测试人员，产品经理，开发人员。
3. 召开会议评审：针对评审用途检查清单，评审过程中收集相关人员的反馈信息（即问题记录清单），并在此基础上进行测试用例更新，直到评审通过。
4. 评审结束后，测试负责人输出测试用例评审报告给相关人员评审，结果经项目经理同意确认。
5. 主要评审标准：
   1）用例是否按照公司规定模板进行编写（名称、编号，是否标注执行优先级或重要性）
   2）用例本身描述是否清晰，是否存在二义性
   3）用例内容是否正确，是否与需求保持一致
   4）用例的期望结果是否是确定且唯一
   5）用例操作步骤与描述是否一致
   6）用例是否包含相关的前置信息
   7）用例是否覆盖所有需求
   8）用例是否存在冗余性
   9）用例是否具有可执行性
   10）用例是否从用户角度出发设计其使用场景和业务流程
   11）用例是否包含了合法、非法的用例
   12）场景用例是否覆盖最复杂的业务流程
   13）对于由系统自动生成的输出项是否标注了生成规则
   14）用例应包含对中间和后台数据的检查

觉得还八错的小伙伴点个赞哇(✿◡‿◡)~~~