测试用例的编写和评审
1.测试用例
1.1 定义：
测试用例（TestCase）是为了项目需求而写的一组测试数据输入、执行条件和预期结果，以便于测试某个程序是否满足用户的需求。是测试工作过程中，最小的执行单元
1.2 为什么测试用例重要
- 是评估测试结果的基准，是软件测试的核心，测试用例是测试工作的指导，是软件测试质量稳定的根本保障
- 保证测试的时候没有遗漏的功能点，编写过程可以熟悉需求，对架构和业务流程有一个整体，深入的了解
- 有章可查，有据可循
- 好的测试用例可以方便别人查看，而且帮助设计时能考虑的更加周全
1.3 测试用例的八大要素：
- 用例编号：唯一标识用例序号 数字或者模块名首字母大写+数字 🌰：测试“注册功能”（ZC_001，ZC_002,...）
- 测试项目：所测试的功能模块的名称
- 测试标题：一句话总结该条用例的用意和目的，直接对测试点进行细化得出 输入内容+结果， 同一个测试项目标题不能重复
- 重要级别：高/中/低,依据功能的重要程度、内容划分，重点保证是功能上的测试，其次是UI，再次兼容性...
- 预置条件：执行该用例的前提条件，也就是说需要做什么准备工作 🌰：登陆之前必须保证已经注册
- 测试输入（数据）：需要输入的内容，根据具体情况设计（跟步骤结合起来一定要有指导性意义）
- 操作步骤：明确给出每个步骤的描述，执行人员可以根据该步骤完成执行工作，要详细明确。
- 预期结果：正常情况下会出现的结果，期望出现的结果。预期结果要唯一，不能出现“是否或者”
实际结果就是通过执行测试步骤得到的对应的实际结果，一般写用例的时候不会写任何数据，要等执行结束之后才来写。
1.4 测试用例的评审
用例评审是有效提高测试用例质量的方法之一，无论是初级还是高级测试工程师，设计出来的用例都需要经过评审
1.4.1 为什么要评审？（用例评审的重要性）
- 测试用例一般分配到个人来设计，设计用例的人并不知道用例在具体执行的时候是否有问题，不能保证自己设计的用例是否能覆盖完全。
- 保证测试人员和开发人员对被测功能的理解一致性。避免测试过程中针对bug测试和开发有分歧
- 需求人员参与评审，他们能帮助你找出更多的问题。经常在测试时，有些细节是无法从需求文档得到的，需要频繁和需求人员沟通
- 按照测试用例数量来评估工作量，用例不完整，工时给的少了，实际测试就会无端的增加工时
总之： 保证用例的正确性和需求的覆盖率（尽可能全部覆盖）由测试人发起会议
