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

2. 测试策略制定

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

功能测试

性能测试

安全性测试

兼容性测试

文档测试

安装卸载测试

其他专项测试

2.1 测试策略的具体实施

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

根据测试的需要，选择测试技术，例如：

1 、需不需要白盒测试？

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

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

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

确认管理使用的工具和方法，

比如：用例的管理方式、bug的管理方式和工具。

2.2 测试计划的制定

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

3. 测试方案设计

每一个公司对测试计划和测试方案的定义都不一致。

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

1 、测试范围：由需求分析而来

2 、测试策略：包括针对不同部分的测试方法、测试用例

3 、测试控制：包括测试流程，测试执行，缺陷跟踪

4 、其他：环境、版本管理等

5 、测试风险

4. 风险分析

良好的管理是能在问题发生之前，就可以进行预警

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

软件项目的风险主要来源于需求、技术、成本和进度。

4.1 需求风险

已经纳入基线的需求在继续变更

需求定义不准确 , 进一步的定义会扩展项目范畴

增加额外的需求

产品定义含混的部分比预期需要更多的时间

在做需求中客户参与不够

缺少有效的需求变化管理过程

4.2 计划编制风险

产品规模( 代码行数、功能点、与前一产品规模的百分比 ) 比估计的要大

完成目标日期提前 , 但没有相应地调整产品范围或可用资源

涉足不熟悉的产品领域 , 花费在设计和实现上的时间比预期的要多

4.3 组织和管理风险

管理层作出了打击项目组织积极性的决定

缺乏必要的规范 , 导至工作失误与重复工作

非技术的第三方的工作 ( 预算批准、设备采购批准、法律方面的审查、安全保证等 ) 时间比预期的延长

4.4 人员风险

项目后期加入新的开发人员 , 需进行培训并逐渐与现有成员沟通 , 从而使现有成员的工作效率降低

由于项目组成员之间发生冲突 , 导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作

没有找到项目急需的具有特定技能的人

4.5 开发环境风险

开发工具未及时到位

开发工具不如期望的那样有效 , 开发人员需要时间创建工作环境或者切换新的工具

新的开发工具的学习期比预期的长 , 内容繁多

4.6 客户风险

客户对于最后交付的产品不满意,要求重新设计和重做

客户的意见未被采纳,造成产品最终无法满足用户要求,因而必须重做

客户对规划、原型和规格的审核决策周期比预期的要长

4.7 产品风险

矫正质量低下的不可接受的产品 , 需要比预期更多的测试、设计和实现工作

开发额外的不需要的功能 ( 镀金 ), 延长了计划进度

严格要求与现有系统兼容 , 需要进行比预期更多的测试、设计和实现工作

4.8 设计和实现风险

一些必要的功能无法使用现有的代码库实现 , 开发人员必须使用新的库或者自行开发新的功能

分别开发的模块无法有效集成,需要重新设计或制作

4.9 过程风险

大量的纸面工作导致进程比预期的慢 ;

前期的质量保证行为不真实 , 导致后期的重复工作

风险管理粗心 , 导致未能发现重大的项目风险

【测试】测试管理

1.测试策略管理

1.1 从测试需求开始