day03-测试流程

目录

测试流程

需求评审

需求来源

需求评审

测试需求分析

---

测试流程

1. 分析：需求评审、测试需求分析，得到测试点。

2. 计划：测试计划和方案文档编写

3. 设计：测试用例设计（测试工程师的基本的要求）

4. 实现：编写测试用例、测试脚本等

5. 执行：搭建测试环境、执行测试脚本、缺陷报告

顺序不能打乱，按照依照以上步骤，一步步实现。

需求评审

需求来源

合同型项目（外包，有甲方乙方）

用户业务需求->产品需求

甲方或用户提出需求，产品经理将用户的需求整理成产品需求。

产品型项目（没有明确的用户）

• 协议/标准/规范

• 继承性需求（根据老的版本分析需求）

• 竞品分析（根据竞争对手的产品分析需求，如：QQ音乐和网易云音乐，界面功能都很像）

没有需求规格说明书可以利用竞品分析，比如说测播放器，可以按照别的播放器的使用经验来测

需求评审

1. 需求从哪里来，如果没有需求怎么办？

2. 需求评审怎么评

 

测试需求分析

为什么要做需求分析？

 

测试需求分析流程

1. 根据产品需求提取系统的测试点

2. 编写需求跟踪矩阵

3. 根据测试点利用适当的测试用例设计方法设计测试用例

测试设计的概念

将测试点转化为测试用例的过程，就叫测试设计。

测试用例的概念

测试用例就是一种用来说明具体如何进行测试操作并验证结果的文档

测试用例模板

 

 

• 测试编号：TC （TestCase）

• 测试标题：用一句话来表述该条用例是测试哪个测试点的。

• 优先级：高中低。作用是在项目时间不够或人员不充足的时候，我们可以优先测试重点的测试用例。

• 预置条件：在执行该条用例时，系统必须预先达到的一个状态或者条件。可选，有就写，没有就不写。

• 测试步骤：详细描述在测试这条用例时，需要进行哪些操作。

• 预期结果：来自需求，要求达到的一个结果。

• 实际结果：实际操作系统之后得到的结果

• 测试结果：pass/fall/NA。pass预期结果和实际结果相同。fail预期结果和实际结果不同。N/A指当前用例不适用或无法操作。

• 备注：如N/A 特殊情况写清楚