测试用例的编写&评审

1、什么叫软件测试用例

什么是测试用例
测试用例(TestCase) 是为项目需求而编制的一组测试输入、执行条件 以及预期结果，以便测试某个程序是否满足客户需求。–测试依据
可以总结为:每一个测试点的数据设计和步骤设计。–测试用例

2、测试用例的重要性(了解)

2.1、测试用例是软件测试的核心。

软件测试的重要性是毋庸置疑的，测试用例是测试工作的指导，是软件测试质量稳定的根本保障。

2.2、评估测试结果的基准

测试用例的通过率以及错误率, 是测试结束的-一个重要依据，用来判断该软件测试结果是否通过，能否达到上线的标准 – 测试报告 考虑

测试用例数量(1000+) --绩效考核 --能力，态度

2.3、保证测试的时候不遗漏测试功能点。 --漏测，错误测试

可以在测试人员疲累的时候起到一个牵引的作用。

2.4、在编写测试用例的过程，可以熟悉需求，对系统架构或者业务流程有一个整体的，深入地了解。–深入测试，提bug

3、测试用例的八大要素(重点! ! ! )

1、用例编号:产品名-测试阶段(it st uat) -测试项-XXX (英文)
It（integration test）：集成测试
St（system test）：系统测试
Uat（user acceptance test）：验收测试
Regression test：回归测试
Smoking test：冒烟测试

2、测试项目:对应一个功能模块(细分功能) – 子项目
3、测试标题:直接对测试点进行细化得出，输入内容+结果，同-功能模块标题不能重复(来自测试点) --建议一行写一个测试点，细致,数量越多
4、重要级别:高(核心功能) /中(次要–异常) /低(界面，不常用场景) - high、medium, low — P1P2，P3，P4,P5 — 冒烟测试(P1) ，回归测试(p1,P2) --测试策略
5、预置条件:需要满足-些前提条件，否则用例无法执行-- 不必须
6、测试输入(数据) :需要加工的输入信息，根据具体情况来设计(跟步骤结合起来-定要具有指导性意义)
7、操作步骤:明确给出每个步骤的描述，执行人员可以根据该步骤完成执行工作–详细–小白执行
8、预期结果:根据预期输出比对实际结果，来判断被测对象是否符合需求。(预期结果唯一， 不能出现“是否或者”)
9、实际结果:执行后的重要结果

总结：哪些东西可以放到第一条冒烟测试用例去写？ ----- 不需要单独写一条测试用例
1、包含在步骤里的检查项 — 第一条包含，结果 --预期结果
2、测试点是一些检查项 — 页面正常，同意协议正确，自动登录首页里面 — 预期结果里检查

4、用例评审

如何保证测试用例的完整性？ — 用例评审

组内评审— 你 组员 组长 – 家丑不可外扬
组外评审— 开发 产品 项目经理（防止背锅）

简单流程 — 用例发邮件 — 项目组相关人员

5、测试用例的变更

由于需求变更、对于业务的不断深入了解和测试用例评审，测试用例是无法一次全部写好的，所以，测试用例在完成之后是需要不断修正的。

测试用例变更通常包括:
1、需求变动
2.执行完成后的用例完善
3.评审后的用例修改
ps: 一定要记得备份
v1.0（保存） —改需求 --修改用例 – 备份
v1.1

笔试面试题整理

1:用例需要评审么?紧急情况用例也需要评审么? — 需要；简单的内部评审，发邮件
2:如果被测项目很紧急,来不及写用例，怎么办? - -列测试点,补充测试用例
3:遇到隐性需求如何写用例? (需求不明确)
1、经验充分熟悉产品2、成熟参考3、产品确认
4:用例有没有优先级?如果一定要有优先级, 依据什么来确定呢? --有，重要级别（优先级），依据功能重要性
5:如何编写测试用例? (以项目为基础来讲一 个小模块用例设计，手机号)