1 学习内容与目标
1）什么是测试用例
2）测试用例的重要性
3）测试用例的8大要素（重要）
4）测试用例评审
2 什么叫软件测试用例
2.1 什么是测试用例?
测试用例（TestCase）是为项目需求而编制的一组测试输入，执行条件以及预期结果，以便测试某个程序是否满足客户需求。
可以总结为：每一个测试点的数据设计和步骤设计
2 测试用例的重要性
2.1 测试用例是软件测试的核心
软件测试的重要性毋庸置疑，测试用例是测试工作的指导，是软件处屙屎质量稳定的根本保障。影响软件测试的因素很多，如软件本身的复杂程度，开发质量，测试方法和技术的应用。但有些因素是客观存在，不可避免的，如IT团队的流动，环境，情绪等。
2.2 评估测试结果的基准
测试用例的通过率以及错误率，是测试结束的一个重要依据，用来判断该软件测试结果是否通过，能否达到上线的标准
2.3 保证测试的时候不遗漏测试功能点。可以在测试人员疲累的时候起到一个牵引的作用。
2.4 在编写测试用里的过程，可以熟悉需求，对系统架构或者业务流程有一个整体的，深入地了解。
2.5 好的测试用例不仅方便自己和别人查看，而且能够帮助设计的时候考虑的更周全，因此测试用例的写作和设计一样，也是非常重要的。执行性（指导性）
3 测试用例的八大要素
3.1 用例编号：产品名_测试阶段_(st (system test 系统测试) it (intergration test 集成测试) uat 验收测试)_测试项_xxx（英文）
3.2 测试项目：对应一个功能模块（细分功能）
3.3 测试标题：直接对测试点进行细化得出，输入内容+结果，同一功能模块标题不能重复（来自测试点）
3.4 重要级别：高/中/低
3.5 预置条件：需要满足一些前提条件，否则用例无法执行
3.6 测试输入（数据）：需要加工的输入信息，根据具体情况来设计（跟步骤结合起来一定要就要指导性）
3.7 操作步骤：明确给出每个步骤的描述，执行人员可以根据该步骤完成执行工作
3.8 预期结果：根据预期输出对比实际结果，来判断被测对象是否符合需求。（预期结果唯一，不能出现“是否或者”）
3.9 实际结果
测试用例案例：
用例编号 | 测试项目 | 测试标题 | 重要级别 | 预置条件 | 测试输入 | 操作步骤 | 预期结果 |
Pro_ ST _ZC _001 | 用户注册 | 输入正确的注册用户信息，能否正常完成注册 | 高 | 1.网络正常 2.系统访问正常 | 手机号码：138888 88888 密码：abcd1 233 | 1.访问网站--点击注册 2.输入手机号码 3.输入图片验证码 4.点击获取短信验证码，输入短信验证码 5.输入密码 6.勾选同意协议 7.点击注册 | 注册成功 |
注意：有些用例作为其他用例中的步骤，可以在其他用例的步骤中，设置预期结果中设置，不用额外再写一个用例。
例如：已勾选协议，在如上用例中已经实现，后续不用单独再写
4 用例评审流程
4.1 发起评审：
1）确定评审对象、目标、人员等
2）通知相关人员（会议时间、会议地点）
4.2 评审会
1）根据用例编写标准，覆盖范围评审用例
2）记录用例中存在的问题并编号排序
4.3 修正问题：修改用例中的问题
4.4 完成评审：
1）确定和检查问题是否已修改到位
2）结束
测试用例评审checklist
编号 | 类别 | 评审点 | 评审结果 |
1 | 规范性 | 用例是否按照公司规定的模板进行编写？ | 通过 |
2 | 文档是否采用标准模板格式？ | 通过 | |
3 | 用例是否按照需求文档编写？ | 通过 | |
4 | 用例是否参考设计文档编写？ | 通过 | |
5 | 是否区分前台页面测试、控台测试、业务逻辑流程测试，和接口测试？ | 通过 | |
6 | 是否列出每个功能点所有边界条件？ | 通过 | |
7 | 用例设计是否采用了边界值、等价类和错误推测主要的用例设计方法？ | 通过 | |
8 | 是否列出每个功能点所有边界条件？ | 通过 | |
9 | 用例是否定义优先级和执行时间？ | 通过 | |
10 | 用例标题（场景描述）是否清晰地描述了测试用例的目的？ | 通过 | |
11 | 用例是否清晰地描述了预置条件？ | 通过 | |
12 | 用例是否清晰地描述了操作步骤？ | 通过 | |
13 | 用例是否清晰地描述了预期结果以及预期结果是否可以验证？（三要素：测试现象、数据库、log） | 通过 | |
14 | 用例excel的是否调整了打印区域，方便别人打印？ | 通过 | |
15 | 用例的粒度是否合理和统一，不存在一个用例覆盖多个场景的情况？ | 通过 | |
16 | 符合性 | 用例设计是否考虑了正向和反向两方面的情况？ | 通过 |
17 | 用例是否考虑到了每次系统交付的安全性？ | 不适用 | |
18 | 用例是否根据多输入条件的组合情况，逐一编写测试用例？ | 通过 | |
19 | 对于接口测试是否列出接口测试点？ | 不适用 | |
20 | 对于前台页面测试是否列出页面测试内容？ | 通过 | |
21 | 用例是否考虑到兼容性需求测试要求？ | 不适用 | |
22 | 用例是否考虑到数据库事务测试？ | 不适用 | |
23 | 用例是否考虑到有性能测试要求？ | 不适用 | |
24 | 质量目标 | 用例覆盖率是否达到相应质量标准（如用例数（个）/千行）？ | 通过 |
25 | 是否每个边界值至少一条测试用例？ | 通过 | |
26 | 是否每个等价类至少1条测试用例？ | 通过 | |
27 | 是否每个功能因果关系至少一条测试用例？ | 通过 | |
28 | 是否针对前台页面测试设计测试用例？ | 通过 | |
29 | 针对前台页面测试用例是否每个录入框测试用例不低于3个？ | 通过 | |
30 | 针对前台测试用例是否每个链接至少一个测试用例？ | 通过 | |
31 | 针对前台页面测试用例，是否每个页面显示至少3个测试用例？ | 通过 | |
32 | 针对前台页面测试用例是否每个页面空间至少3个测试用例？ | 通过 | |
33 | 针对前台页面测试用例是否每个页面流转至少1个测试用例？ | 通过 | |
34 | 是否针对接口测试进行用例设计？ | 不适用 | |
35 | 对于接口测试是否进行输入报文格式校验。每个字段至少3个测试用例？ | 不适用 | |
36 | 对于接口测试是否输出报文格式验证（正常/异常）。至少2个测试用例？ | 不适用 | |
37 | 对于接口测试是否存在系统间交互测试用例？ | 不适用 | |
38 | 对于接口测试是否前置系统的每个主要响应码至少1条测试用例？ | 不适用 | |
39 | 对于接口测试是否本系统每个主要响应码至少1条测试用例？ | 不适用 | |
40 | 对于接口测试是否签名验签测试至少2条测试用例？ | 不适用 |
5 测试用例的变更
由于需求变更、对于业务的不断深入和了解和测试用例评审，测试用例是无法一次全部写好，所以，测试用例在完成之后是需要不断修正的。
测试用例变更通常包括：
1）需求变动
2）执行完成后的用例完善
3）评审后的用例修改
注意：用例变更的时候，要使用版本控制工具，避免数据丢失。
标签：04,是否,通过,评审,用例,测试用例,测试,页面 From： https://blog.51cto.com/u_15932265/5993504