测试管理篇

一、从测试需求开始

需求分析注意事项：

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

分析需求的具体方法：

1.需求串讲

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

2.验证需求

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

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

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

二、测试策略制定

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

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

测试策略的具体实施

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

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

三、测试方案设计

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

四、风险分析

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

需求风险

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

计划编制风险

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

人员风险

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

五、测试执行流程的设计

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

六、测试报告的输出

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

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

回顾整个测试过程

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