测试管理篇

测试需求

完整的需求文档包括以下内容：

• 功能需求
• 非功能需求
• 性能需求
• 安全性需求
• 扩展性需求
• 可靠性需求
• 可移植性需求
• 易用性需求
• 兼容性需求

需求分析注意事项：

• 测试应该尽早的介入
• 不断变化的需求需要及时的收集和整理
• 没有需求文档时，需要测试人员不断的收集原始的客户需求
• 应有质疑、坚持精神，当需求不明确时，我们可以将需求追溯到终端客户

分析需求的具体方法：

1）快速理解需求的捷径：需求串讲

主要解决的问题：需求理解不一致

方式：介绍需求背景、内容，进行答疑

2）验证需求

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

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

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

测试策略制定

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

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

测试策略的具体实施：

1）需不需要白盒测试？

2）自动化测试采用哪种工具？针对接口测试还是UI测试？

3）性能测试采用哪种工具？jmeter还是loadrunner？

4）兼容性测试如何做？手工测试还是使用平台测试？

在测试方案中，我们也需要确认测试过程如何管理，确认管理使用的工具和方法，比如：用例的管理方式、bug的管理方式和工具。在没有固定测试团队的企业，还需要考虑团队的组建，比如测试的人数，高中低级的配比，入场出厂时间等等。确认测试资源，需要多少资源？资源是否到位？根据不同的开发模式，确认测试计划，计划主要包括：什么人、什么时间、做什么事情。测试的目标要明确，同时要确认跟踪机制。

测试方案设计

每一个公司对测试计划和测试方案的定义都不一致，不是每一个公司都有测试计划和测试方案，有些只有测试计划，有些只有测试方案，有些两个都有。

测试方案主要包括以下内容：

1. 测试范围：由需求分析而来
2. 测试策略：包括针对不同部分的测试方法、测试用例
3. 测试控制：包括测试流程、测试执行、缺陷跟踪
4. 其他：环境、版本管理等。
5. 测试风险
    

风险分析

风险分析的目的是及时的调整测试内容和测试方案

软件项目风险是指在软件开发过程中遇到的预算和进度等方面的问题以及这些问题对软件项目的影响，软件项目的风险主要来源于需求、技术、成本和进度

• 需求风险

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

• 计划编制风险

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

• 组织和管理风险

1. 仅由管理层或市场人员进行技术决策，导致计划进度缓慢，计划时间延长
2. 低效的项目组结构降低生产率 
3. 管理层审查决策的周期比预期的时间长 
4. 预算削减，打乱项目计划
5. 管理层作出了打击项目组织积极性的决定 
6.  缺乏必要的规范，导至工作失误与重复工作 
7. 非技术的第三方的工作(预算批准、设备采购批准、法律方面的审查、安全保证等)时间比预期的延长

• 人员风险

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

• 开发环境风险

1. 设施未及时到位
2. 设施虽到位，但不配套，如没有电话、网线、办公用品等
3. 设施拥挤、杂乱或者破损 
4. 开发工具未及时到位 
5. 开发工具不如期望的那样有效，开发人员需要时间创建工作环境或者切换新的工具 
6. 新的开发工具的学习期比预期的长,内容繁多

• 客户风险

1. 客户对于最后交付的产品不满意，要求重新设计和重做 
2. 客户的意见未被采纳，造成产品最终无法满足用户要求，因而必须重做 
3. 客户对规划、原型和规格的审核决策周期比预期的要长 
4. 客户没有或不能参与规划、原型和规格阶段的审核，导致需求不稳定和产品生产周期的变更
5. 客户答复的时间(如回答或澄清与需求相关问题的时间)比预期长 
6. 客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的客户关系管理工作

• 产品风险

1. 矫正质量低下的不可接受的产品，需要比预期更多的测试、设计和实现工作 
2. 开发额外的不需要的功能(镀金)，延长了计划进度
3. 严格要求与现有系统兼容，需要进行比预期更多的测试、设计和实现工作 
4. 要求与其他系统或不受本项目组控制的系统相连，导致无法预料的设计、实现和测试工作 
5. 在不熟悉或未经检验的软件和硬件环境中运行所产生的未预料到的问题 
6. 开发一种全新的模块将比预期花费更长的时间 
7. 依赖正在开发中的技术将延长计划进度

• 设计和实现风险

1. 设计质量低下，导致重复设计
2. 一些必要的功能无法使用现有的代码库实现，开发人员必须使用新的库或者自行开发新的功能 
3. 代码库质量低下，导致需要进行额外的测试，修正错误，或重新制作 
4. 过高估计了增强型工具对计划进度的节省 
5. 分别开发的模块无法有效集成，需要重新设计或制作

• 过程风险

1. 大量的纸面工作导致进程比预期的慢
2. 前期的质量保证行为不真实，导致后期的重复工作 
3. 太不正规(缺乏对软件开发策略和标准的遵循)，导致沟通不足，质量欠佳，甚至需重新开发 
4. 过于正规(教条地坚持软件开发策略和标准)，导致过多耗时于无用的工作
5. 向管理层撰写进程报告占用开发人员的时间比预期的多
6. 风险管理粗心，导致未能发现重大的项目风险

测试执行流程的设计

• 需求测试

基于需求的测试方法是最基本的测试方法，而需求的质量直接影响到后续的开发和测试工作

1. 需求审核
2. 需求测试
3. 测试设计中进行需求测试
4. 需求测试要素：正确性、必要性、完整性、一致性
5. 需求测试应该尽早开始

• 内部发布版本测试（冒烟测试）

1. 冒烟测试
2. 版本测试中信息传递：修改内容，风险分析，配置管理

• 系统测试

1. 根据测试用例一条一条的执行
2. 缺陷管理

• 回归测试

1. 确认回归内容
2. 确认回归的方式：手工、自动化
3. 用例的回归
4. bug的回归

回归测试是自动化测试最好的用处

• 交叉测试

1. 测试的枯燥性、重复性、引起的惰性
2. 不同的思维模式

交叉测试多在测试的后期，功能基本稳定时执行

测试报告的输出

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

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

回顾整个测试过程:

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