目录
1.测试策略管理
需求,是软件设计与测试的来源,但是需求除了终端用户的功能需求外,还有设计性需求、可靠性需求、可测试性需求、性能需求、安全性需求等。
1.1 从测试需求开始
50%以上的错误来源于需求的错误
测试需求的识别是后续的测试工作的基础,也是起点。测试需求主要来源于业务需求。
完整的需求文档包括以下内容:参见《需求规格说明书模板》
功能需求非功能性需求性能需求安全性需求扩展性需求可靠性需求可移植性需求易用性需求兼容性需求
需求分析注意事项:
测试应该尽早的介入不断变化的需求需要及时的收集和整理没有需求文档时,需要测试人员不断的收集原始的客户需求应有质疑、坚持精神,当需求不明确时,我们可以将需求追溯到终端客户
分析需求的具体方法 :
1
、快速理解需求的捷径:需求串讲
主要解决问题:需求理解不一致
方式:介绍需求背景、内容,进行答疑
案例:需求要求注册时姓名可以输入 16 个字符开发理解: 16 个字符,也就是英文 16 个,中文 8 个。测试理解:无论英文、中文或其他语言都是 16 个。
2、验证需求
需求文档也需要测试:正确性,必要性,完整性,一致性等
3
、从设计需求中提取测试需求
软件需求是软件测试需求的主要来源,但不是全部来源,软件设计需求、软件概要设计、详细设计也都是测试需求的分析对象,是对测试需求的一种有力的补充。对于黑盒功能测试,几乎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 过程风险
大量的纸面工作导致进程比预期的慢 ;前期的质量保证行为不真实 , 导致后期的重复工作风险管理粗心 , 导致未能发现重大的项目风险