测试管理篇

太过爱你忘了你带给我的痛 2022-02-24 02:44 238阅读 0赞

## 一、从测试需求开始 ##

需求分析注意事项：

> 1.测试应尽早介入（介入越早发现问题越早解决问题成本越低）；  
> 2.不断变化的需求需要及时的收集和整理；  
> 3.没有需求文档时，需要测试人员不断的收集原始的客户需求；  
> 4.要有质疑、坚持精神，当需求不明确时，我们可以将需求追溯到终端客户。

**分析需求的具体方法：**

1.需求串讲

> 主要解决问题：需求理解不一致  
> 方式：介绍需求背景、内容，进行答疑

2.验证需求

> 需求文档也需要测试：正确性、必要性、完整性、一致性等

3.从设计需求中提取测试需求

> 软件需求是软件测试需求的主要来源，但不是全部来源，软件设计需求、软件概要设计、详细设计也都是测试需求的分析对象，是对测试需求的一种有力的补充。对于黑盒功能测试，几乎98%的需求都是来源于需求说明书，但有那么一小部分需求来自设计需求或概要设计、详细设计。也就那么小部分需求，如果我们没有意识到，就会给用户带来隐患。

## 二、测试策略制定 ##

在分析了需求之后，我们要确认测试业务涉及的测试类别，例如：

*  功能测试
 *  性能测试
 *  安全性测试
 *  兼容性测试
 *  文档测试
 *  安装卸载测试
 *  其他专项测试

**测试策略的具体实施**

测试策略需要确认测试使用的测试技术、测试过程的管理和控制、测试团队的组建根据测试的需要，选择测试技术。

**测试计划的制定**  
根据不同的开发模式，确认测试计划，计划主要包括：什么人、什么时间、做什么事情。 测试的目标要明确，同时要确认跟踪机制。

## 三、测试方案设计 ##

测试方案主要包括以下内容 ：  
1、测试范围：由需求分析而来  
2、测试策略：包括针对不同部分的测试方法、测试用例  
3、测试控制：包括测试流程，测试执行，缺陷跟踪  
4、其他：环境、版本管理等  
5、测试风险  
总结：  
测试策略是确定多少个人用什么方法什么技术对项目进行测试（方向的选择）  
测试计划是什么人什么时间做什么事情  
测试方案更详细更具体告诉我们如何去做

## 四、风险分析 ##

目的：及时的调整测试内容和测试方案

**需求风险**

*  已经纳入基线的需求在继续变更
 *  需求定义不准确,进一步的定义会扩展项目范畴
 *  增加额外的需求
 *  产品定义含混的部分比预期需要更多的时间
 *  在做需求中客户参与不够
 *  缺少有效的需求变化管理过程

**计划编制风险**

*  计划、资源和产品定义全凭客户或上层领导口头指令,并且不完全一致
 *  计划是优化的,是"最佳状态",但计划不现实,只能算是"期望状态"
 *  计划基于使用特定的小组成员,而那个特定的小组成员其实指望不上
 *  产品规模(代码行数、功能点、与前一产品规模的百分比)比估计的要大
 *  完成目标日期提前,但没有相应地调整产品范围或可用资源
 *  涉足不熟悉的产品领域,花费在设计和实现上的时间比预期的要多

**人员风险**

*  作为先决条件的任务(如培训及其他项目)不能按时完成
 *  开发人员和管理层之间关系不佳,导致决策缓慢,影响全局
 *  缺乏激励措施,士气低下,降低了生产能力
 *  某些人员需要更多的时间适应还不熟悉的软件工具和环境
 *  项目后期加入新的开发人员,需进行培训并逐渐与现有成员沟通,从而使现有成员的工作效率降低
 *  由于项目组成员之间发生冲突,导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作
 *  不适应工作的成员没有调离项目组,影响了项目组其他成员的积极性
 *  没有找到项目急需的具有特定技能的人

## 五、测试执行流程的设计 ##

**1.需求测试**  
**2.内部发布版本测试（冒烟测试）**  
**3.系统测试**  
**4.回归测试（内容、方式、用例和bug的回归）**  
**5.交叉测试（功能基本稳定时进行）**

## 六、测试报告的输出 ##

在项目测试完毕后，需要出具测试报告

*  测试概况
 *  测试过程分析
 *  缺陷分析
 *  测试结论
 *  缺陷清单

回顾整个测试过程

需求分析（需求串讲、验证、从设计需求中提取）——>测试计划（测试方案、测试策略）——>测试用例编写（需求测试）——>测试执行（冒烟测试、系统测试、回归测试，交叉测试、自由测试）——>测试报告（缺陷分析、测试结论）