测试管理篇

测试管理篇

基于需求的
测试目标 量化指标 性能测试 需求：同一时刻支持100个用户并发，相应时间不超过5s
测试范围
测试工具：兼容性测试，app主流机型；性能测试：jmeter,loadrunner;接口测试：postman,soupUI 写脚本
测试资源：人力资源 物力资源
测试计划：时间
测试策略：有限的时间，有限的资源要达到一个平衡，最终软件质量和测试所产生的风险之间的平衡

需求分析

功能性需求：登录，注册，查询，上传，下载功能
非功能性需求（易用性，兼容性，可靠性，可移植性，安全性，性能，扩展性）：在功能性的需求上增加一些限制
例如登录：在高峰期，用户平均成功登陆时间不超过3s
安全性限制：上传的时候不能上传任何病毒，上传病毒时报警
不同的产品，不同的用户群体，测试需求不同
手机分老年版本，智能机
测试人员如果有测试需求不明确的地方，一定要和产品经理确认清除或找用户弄清楚

需求分析注意事项：

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

测试案例：

一个全新上线的app需要做哪些测试？
兼容性，安全性，功能性，接口，可靠性，可移植性，性能
一个增加了新功能的app需要做哪些测试？
对增加的功能进行测试，如果有其他非功能性测试需求，也要进行相应的测试。回归测试（测试范围，可能会影响的历史功能也要进行测试）
一个只修改了页面广告的app需要做哪些测试？
页面测试 兼容性测试

风险分析

良好的管理是能在问题发生之前，就可以进行预警
分析风险的目的是及时的调整测试内容和测试方案

需求风险

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

计划编制风险

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

组织和管理风险

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

人员风险

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

开发环境风险

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

客户风险

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

产品风险

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

设计和实现风险

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

过程风险

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

测试执行流程的设计

需求测试

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

• 需求审核
• 需求测试
• 测试设计中进行需求测试
• 需求测试要素：正确性，必要性，完整性，一致性
• 需求测试应该尽早开始

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

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

系统测试

• 根据测试用例一条一条的执行
• 缺陷管理

回归测试

• 确认回归内容
• 确认回归的方式：手工、自动化
• 用例的回归
• bug的回归
  回归测试是自动化测试最好的用处

交叉测试

• 测试的枯燥性、重复性，引起的惰性
• 不同的思维模式
  交叉测试多在测试的后期，功能基本稳定时进行

测试报告的输出

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

• 测试概况
• 测试过程分析
• 缺陷分析
• 测试结论
• 缺陷清单
  回顾整个测试过程