【软件测试-6】& 测试管理篇

在之前的学习中，我们没有涉及测试管理部分的工作。这部分工作往往在公司中由team leader的角色来承担。包括整个测试过程的组织、测试方案的制定、测试报告的输入、以及进一步的测试的分析与改进。

在本篇文章中我们将涉及以下内容：

• 测试需求分析和测试策略制定
• 测试方案的设计
• 测试执行流程的设计
• 测试报告的输出

测试策略制定

需求，是软件设计与测试的来源，但是需求除了终端用户的功能需求外，还有设计性需求、可靠性需求、可测试性需求、性能需求、安全性需求等。

对于测试工作而言，所有的需求最后都需转化为测试需求。之后分析这些需求，并以此为根据来制定测试策略，合理选择各种测试技术。比如是否需要自动化测试？是否需要性能测试？回归测试的范围是什么？是否需要专项测试？黑盒测试能否满足，要不要白盒测试或者灰盒测试？

从测试需求开始

50%以上的错误来源于需求的错误

项目组成员要积极参与需求评审，在评审会议上发现更多的需求缺陷。需求一旦确定，后期进行修改会给我们带来很大的成本。

测试需求的识别是后续的测试工作的基础，也是起点。测试需求主要来源于业务需求。我们在拿到需求后，要能识别测试需求，接着是分析此测试需求，最后确定并提取出测试对象。

提取出了测试对象后，接下来需要确定对每一对象如何进行测试，拿出具体的方法及措施出来，这便是测试策略制定的问题。

完整的需求文档包括以下内容：参见《需求规格说明书模板》

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

需求分析需要注意的事项

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

分析需求的具体方法

1、快速理解需求的捷径：需求串讲（项目经理做的）

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

案例：
需求要求注册时姓名可以输入16个字符
开发理解：16个字符，也就是英文16个，中文8个。
测试理解：无论英文、中文或其他语言都是16个。

2、验证需求

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

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

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

案例：
2008汶川地震废墟一片，其中有一个学校屹立不倒
学校在建立时就考虑到了抗震，在设计、施工、用料方面都有对地震进行了防保措施。
思考一下软件开发设计需要对预估可能要发生的事情做什么？

测试策略制定

学校放假了，大家都收拾行李计划回家，路远的条件好的同学坐飞机回家，路远的条件一般的同学坐火车回家，路近的坐汽车回家的，有的是家长开车来回家。

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

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

思考案例：

一个全新上线的app需要做哪些测试？

答：功能测试、性能测试、安全性测试兼容性测试、文档测试安装卸载测试其他专项测试等都要测试

一个增加了新功能的app需要做哪些测试？

答：测试新的功能和新功能我影响的功能

一个只修改了页面广告的app需要做哪些测试？

答：只做界面测试就行了

测试策略的具体实施

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

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

1、需不需要白盒测试
2、自动化测试采用哪种工具？针对接口测试还是UI测试？
3、性能测试采用哪种工具？jmeter还是loadrunner？
4、兼容性测试如何做？手工测试还是使用平台测试？

在测试方案中，我们也需要确认测试过程如何管理，确认管理使用的工具和方法，比如：用例的管理方式、bug的管理方式和工具。

在没有固定测试团队的企业，还需要考虑团队的组建，比如测试的人数，高中低级的配比，入场出厂时间等等。

确认测试资源，需要多少资源？资源是否到位？

测试计划的制定

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

测试计划评审通过后，测试组需严格按计划中的时间完成各项任务。如果delay会直接影响绩效工资，如果多次严重出现可能会失去这次工作机会，对后期找工作有负面影响。

测试方案设计

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

学校放假，几个同学打算先去成都旅游，其中选择一个同学来负责安排大家的行程、吃饭、住宿
该同学会考虑：
1.乘坐什么交通工具
2.去成都哪些景点玩，先去哪里后去哪里？
3.住在哪里，住多钱的标准，对住的环境有什么要求
4.怎么吃饭，在景点吃还是自己备吃的
5.玩几天
6.如何各自回家
7.提前购买雨具以防下雨
8.每个人的预算够吗？
9.中途有人生病怎么办？
10.景点临时不接游客怎么办？

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

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

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

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

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

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

5、测试风险

风险分析（了解）

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

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

软件项目风险是指在软件开发过程中遇到的预算和进度等方面的问题以及这些问题对软件项目的影响。

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

需求风险

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

计划编制风险

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

组织和管理风险

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

人员风险

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

开发环境风险

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

客户风险

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

产品风险

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

设计和实现风险

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

过程风险

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

测试执行流程的设计

根据项目特性制定适合项目的测试执行流程。可以在公司要求的流程上进行裁剪。

测试方案与用例的设计，是属于纯测试技术上的设计，但对于整个项目的测试过程，光有技术还不够，需要配合合适的测试流程，策划什么时候做什么事，达到什么要求。好的策划可以对项目的测试起到事半功倍的作用。

需求测试

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

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

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

测试人员决定是否正式进行本次迭代的测试时有一个原则，要先进行冒烟测试！！

冒烟测试通过了才能进行接下来的测试，冒烟测试不通过就需要先让开发人员把错误的地方改正过来；

冒烟测试是由测试人员测还是由开发人员有时候也取决于一个公司的文化；

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

系统测试

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

回归测试

确认回归内容

• 确认回归的方式：手工、自动化
• 用例的回归
• bug的回归

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

交叉测试

• 交叉测试就是在有一定时间和条件的情况下与其他测试人员互相测试，你测测我的，我测测你的。
• 测试的枯燥性、重复性，引起的惰性
• 不同的思维模式

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

测试报告的输出

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

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

回顾整个测试过程

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