测试用例编写和评审
学习目标
- 理解什么是测试用例
- 了解用例评审过程
1. 什么是用例
用户使用的案例
2. 什么是测试用例
执行测试前的用户案例。在测试执行之前，由测试人员编写的用来指导测试过的重要文档。英文：Test Case
3. 测试用例的组成
- 用例编号：唯一编号，根据公司的不同格式进行编写，如：项目简称_模块简称_001
- 所属模块：非必填，本条测试用例的功能点，所属于哪个功能模块
- 用例标题：用例的测试点
- 测试目的：非必填，一句话描述本条测试用例的作用，通常包含“做什么+验证什么”
- 前置条件：要执行当前用例时，需要提前满足的条件
- 测试步骤：要验证当前用例的功能点，需要如何一步步操作。尽量保持在8个步骤以内（3~5步最优），避免一条用例覆盖的测试目的过多
- 预期结果：按照“测试步骤”执行后，应当有什么样的执行结果。属于结果的预测，若实际操作的结果与预期结果不符合，则会认为是bug
- 测试数据：执行该条用例时使用的数据
- 优先级：有的公司分为p0~p4（p0最高），有的公司使用数字1、2、3、4来表示（1最高）
- 高：功能的主功能流程、重点流程、使用率高的流程，可以将1级用例作为开发自测用例，和冒烟测试用例
- 中：一般性的功能流程、次要分支流程、使用率中等的流程，大部分用例都会是“中级”
- 低：界面展示内容、UI层面、温馨提示、使用率较低的流程
- 备注：非必填，可以对该条用例进行额外表述，如：该条仅适用IOS版本，小程序版本可忽略
4. 编写测试用例的注意事项
- 用词用语要简洁、清晰、专业、不能有歧义、易懂、注意断句、排版整齐，少用过长的句子
- 用例的重点组成部分不能遗漏，每家公司使用的用例格式不一样，需要提前去了解适应
- 测试步骤要详细，操作要明确
- 根据实际项目情况调整用例的颗粒度
- 不是每一步操作步骤，都需要对应一个预期结果
5. 用例的颗粒度
粒度，指的是粗细程度。
案例：假设有一个如下需求：
- 颗粒度大：一条用例所涵盖的关注内容比较多，总的用例数就少，用例看起来也简洁。
- 颗粒度小（新手建议使用）：一条用例关注的测试点很集中，总的用例数就多，不容易遗漏，并且执行需要的时间比较好估计。
6. 设计测试用例（功能测试/黑盒测试）的常用方法
- 等价类划分法
- 边界值法
- 判定表法（决策表）
- 因果图法
- 正交排列法
- 场景法
- 错误推论法
7. 设计测试用例时需要参考的资源
- 需求相关文档：需求规格说明书、原型→找【产品经理】
- 核心技术文档：数据库设计、接口设计→找【程序员】
- UI交互文档：设计的UI稿、交互原型→【设计组】
- 被测程序
- 与测试人员、产品经理、开发人员、设计组、用户之间的沟通讨论
- 竞品、网络资源
8. 测试用例设计思想
- 穷举测试思想：将所有有可能的数据或情况都进行测试。
- 理想的测试思想：用最少的测试数据，达到最佳的测试效果
9. 测试用例的作用
- 提高测试效率，避免了穷举测试的窘境
- 保证了测试的覆盖率，测的全面
- 进行重复测试时，可以通过测试用例重复执行，提高用例的重用度，节省测试时间
- 通过测试用例可以监督测试工作，保证测试质量
- 缩短测试周期，当软件进行升级或二次开发时，只需要对修改的功能或新功能进行用例设计，其余功能的用例可以不做调整。
- 给自动化测试、性能测试、开发自测提供主流程测试用例
10. 测试用例的执行状态
- Block（阻塞）：功能或者测试环境等的欠缺、受其他bug影响，导致测试不能进行到底
- Fail（失败）：当实际执行结果与预期结果不符时
- Pass（通过）：当实际执行结果与预期结果相符
- N/A（不适用）：客观原因导致无法适用于当前测试
- Investigate（观察）：当用例正在执行中，但是需要耗较多时间去观察其结果
- No Test（未执行）：当用例还没开始执行时
11. 经验分享
- 要有灵活发散的思维，和全面的视野，写出的用例能保证涉及软件运行时的各个关键要点，在执行完这样的用例，所发现的bug被解决，我们就可以对软件的质量下一个良好的结论
- 当测试用例编写完成后，要分类出“开发自测用例”、“回归用例”
- 测试用例并不可能一开始就写得很完美，可能也有写错的，可能也有遗漏的测试点。随着测试的不断开展，测试人员对产品的理解逐渐加深，我们需要不断地优化自己的测试用例
12. 用例评审过程
测试用例必须要经过评审，评审通过后才可以执行
- 评审方式：
- 日常交换评审：1V1评审，某些小功能调整，由于关联的人不多，不需要组织会议进行评审，可以进行1V1、1V2这种小规模交流审核用例
- 内部评审：公司内部项目参与人员组织会议进行评审，参会的人有产品经理、前端开发、后端开发、设计组、其他测试人员
- 外部评审：若项目承包于甲方，会联合甲方组织外部测试用例评审
- 会议流程：
- 主持人（测试人员）确定评审日期、参与评审人员
- 评审提前1天，将测试用例发给参会人员
- 评审人员提前浏览测试用例，并提前记录下用例问题
- 会议中，测试人员逐条讲解用例，回答并记录其他人提出的问题
- 会议结束后，根据会议室记录的问题，进行用例，准备二次评审（二评不需要组织大规模会议）
- 评审通过后，用例基线化，并将基线化后的用例正式发给对应的项目参与人员
- 评审方向：
- 用例设计策略是否正确
- 用例覆盖率是否达标
- 用例书写格式是否符合规范
- 用例可读性
- 用例可执行性
- 评审具体的内容：
- 检查用例是否覆盖了所有需求
- 检查用例内容是否正确，是否与需求保持一致
- 评审用例内容是否完整，是否清楚包含了输入和预期输出结果
- 是否具有指导性，是否能灵活知道测试人员通过用例发现更多缺陷，而不限制他们的思维
- 列出哪些需求不可测：无法准备环境、测试下达不到等等原因
- 对具体需求的实现结果的确认（设计人员、开发人员、测试人员的认识是否一致，如果不一致，尽量现场解决）
- 检查用例内容是否描述清晰，用词用句是否存在歧义
- 是否考虑到测试用例的执行效率，用例中是否存在步骤不断重复、测试点冗余性
- 用例的重心分布：
- 流程性用例占比15%
- 基本功能用例占比35%
- 深入逻辑用例占比40%
- 极限值、特殊场景用例占比10%
- 讲解案例顺序：
- 核心功能 先于 次要功能
- 正向用例 先于 逆向用例
- 常规场景 先于 异常场景