171 lines
4.2 KiB
Markdown
171 lines
4.2 KiB
Markdown
---
|
||
title: 测试过程
|
||
date: 2023-04-11 20:13:58.366
|
||
updated: 2023-04-19 14:35:05.501
|
||
url: /archives/ceshiguocheng
|
||
categories:
|
||
- 软件测试
|
||
tags:
|
||
- 测试基础
|
||
---
|
||
|
||
# 测试过程
|
||
|
||
## 测试的四个阶段
|
||
|
||
### 单元测试阶段
|
||
|
||
检查实现出来的函数代码是否符合详细设计
|
||
|
||
- 测试依据：详细设计说明书
|
||
- 测试对象：函数
|
||
- 测试重点：函数内部逻辑实现是否正确
|
||
- 评估标准：主要是逻辑覆盖率
|
||
|
||
### 集成测试阶段
|
||
|
||
检查实现出来的模块代码是否符合概要设计
|
||
|
||
- 测试依据：概要设计说明书
|
||
- 测试对象：模块
|
||
- 测试重点：模块功能是否正确实现，模块内部函数调用是否正确
|
||
- 评估标准：主要是接口覆盖率
|
||
|
||
### 系统测试阶段
|
||
|
||
检查实现出来的软件代码是否符合需求规格
|
||
|
||
- 测试依据：需求规格说明书
|
||
- 测试对象：整个软件
|
||
- 测试重点：功能测试，界面测试，性能测试
|
||
- 评估标准：主要是需求规格覆盖率
|
||
|
||
### 验收测试阶段
|
||
|
||
检查实现的软件代码是否符合**用户需求**
|
||
|
||
- 测试依据：用户需求
|
||
- 测试对象：整个软件
|
||
- 评估标准：用户需求是否满足
|
||
|
||
#### 正式验收测试
|
||
|
||
第三方评测
|
||
|
||
#### 用户验收测试
|
||
|
||
阿尔法测试
|
||
|
||
- 在开发环境下进行（不对外）
|
||
- 开发主导
|
||
- 处于受控状态，例如游戏内测
|
||
|
||
贝塔测试
|
||
|
||
- 在生产环境下进行
|
||
- 处于不受控状态，例如游戏公测
|
||
|
||
## 回归测试
|
||
|
||
把已经测试的再测试一遍，四个阶段都会发生
|
||
|
||
原因：
|
||
|
||
1. 验证BUG是否修复
|
||
2. 有没有引发新的问题
|
||
|
||
### 回归策略
|
||
|
||
- 选择性回归
|
||
|
||
- 覆盖修改法：发现bug的用例重新执行
|
||
- 周边影响法：bug所在模块及有交互的模块全部覆盖
|
||
- 指标达成法：bug修复涉及的代码全部覆盖，相关接口60%覆盖
|
||
|
||
- 完全回归
|
||
|
||
重新执行所有用例，工作量较大，一般配合自动化测试
|
||
|
||
## 测试的四个活动
|
||
|
||
每个测试阶段都可以细分为四个测试活动
|
||
|
||
### 测试计划活动
|
||
|
||
从管理角度规划和控制整个测试工作
|
||
|
||
人员：测试经理
|
||
|
||
输出：测试计划
|
||
|
||
内容：测试范围what，测试人员安排who，测试时间的安排when
|
||
|
||
### 测试设计活动
|
||
|
||
从技术角度规划和控制整个测试工作
|
||
|
||
人员：资深测试工程师
|
||
|
||
输出：测试方案
|
||
|
||
内容：测试怎样进行：测试方法和测试工具等
|
||
|
||
### 测试实现活动
|
||
|
||
**测试用例** 用一组数据按照一定的步骤检查软件的实现是否正确
|
||
|
||
人员：测试工程师
|
||
|
||
输出：测试用例
|
||
|
||
### 测试执行活动
|
||
|
||
根据测试用例对被测对象进行操作
|
||
|
||
人员：初级测试工程师
|
||
|
||
输出：搭建测试环境，执行用例，记录结果，提交缺陷报告，测试日报，测试分析报告，测试总结等
|
||
|
||
## 双V模型
|
||
|
||
**瀑布模型** 计划-需求分析-设计-编码-测试-维护
|
||
|
||
测试在编码之后进行，细分为：
|
||
|
||
单元测试：计划-设计-实现-执行
|
||
|
||
集成测试：计划-设计-实现-执行
|
||
|
||
系统测试：计划-设计-实现-执行
|
||
|
||
验收测试：计划-设计-实现-执行
|
||
|
||
|
||
|
||
**双V模型**
|
||
|
||
1. 需求分析完成输出SRS
|
||
2. 架构师依据SRS进行HLD设计，同时测试依据SRS进行系统测试计划的设计和实现，输出系统测试计划、方案和用例
|
||
3. 架构师完成HLD设计，开发进行LLD设计，同时测试依据HLD进行集成测试计划的设计和实现，输出集成测试计划、方案和用例
|
||
4. 开发完成LLD设计，同时测试依据LLD进行单元测试计划的设计和实现，输出单元测试计划、方案、和用例
|
||
5. 开发完成编码，测试进行代码审查
|
||
6. 测试完成代码审查，进行单元测试执行
|
||
7. 测试完成单元测试执行，进行集成测试执行
|
||
8. 测试完成集成测试执行，进行系统测试执行
|
||
|
||
**代码审查**
|
||
|
||
代码编译，编码规则检查，注释率统计
|
||
|
||
**验证与确认**
|
||
|
||
验证：检测每一阶段形成的工作产品是否与前一阶段定义的规格一致
|
||
|
||
确认：检测每一阶段的工作产品是否与最初定义的需求规格一致
|
||
|
||
**特点**
|
||
|
||
1. 测试和开发同步展开工作
|
||
2. 测试执行的顺序和开发的活动顺序相反
|
||
3. 测试计划、设计、实现和执行分离
|
||
4. 系统测试计划、设计、实现最早开始，系统测试执行最晚结束 |