软件测试：管理篇

软件测试：管理篇

本节内容

• 测试需求分析和测试策略制定
• 测试方案的设计
• 测试执行流程的设计
• 测试报告的输出（在系统测试阶段）

测试策略制定

1. 需求，是软件设计与测试的来源。需求除了终端用户的功能需求外，还有设计性需求、可靠性需求、可测试性需求、性能需求、安全性需求等。需求也是要进行测试的。
2. 需求，设计，编码，开发，测试一系列阶段中，需求成本最低，测试成本最高。
3. 对于测试工作而言，所有的需求最后都需要转换为测试需求。

从测试需求开始

1. 50%以上的错误来源于需求的错误。
2. 测试需求的识别是后续的测试工作的基础，也是起点。
3. 测试需求主要来源于业务需求。我们在拿到需求后，要能识别测试需求，接着是分析此测试需求，最后确定并提取出测试对象。
4. 提取出了测试对象后，接下来需要确定对每一对象如何进行测试，拿出具体的方法及措施出来，这便是测试策略制定的问题。 完整的需求文档包括以下内容：
   • 功能需求
   • 非功能性需求
   • 性能需求
   • 安全性需求
   • 扩展性需求
   • 可靠性需求
   • 可移植性需求
   • 易用性需求
   • 兼容性需求

需求分析注意事项：

• 测试应该尽早的介入，从用户需求阶段就要介入。
• 不断变化的需求需要及时的收集和整理。
• 没有需求文档时，需要测试人员不断的收集原始的客户需求，（敏捷的测试对于需求文档的要求比较低。）
• 应有质疑、坚持的精神，当需求不明确时，可以将需求追溯到终端用户。

案例1：手机的日历提醒事件丢失了

A是软件测试部负责此日历行程的测试工程师，在做日程提醒事件测试时，他发现如果手机电力不足（不足于开机），而这段时间正好有提醒事件发生，则在下次开机后不会再提醒，即发生在没电池时段内的提醒事件会丢失。

而对于这种特殊情况，需求并未有明确定义（需求只定义了到达约定的时间便进行响铃提醒，并弹出事件窗口）。于是A找到需求、开发讨论关于这种特殊情况的处理。开发认为，电力不足的情况下，本来就不可能开机，提醒事件也就不可能弹出来，目前的处理是合理的。需求设计人员认为，如果在不能开机的情况下，提醒事件需在下次开机后进行积累提醒，如果用户一个月没用此机，事务每天又多的话，再次开机后的消息太多了，光关闭这些事件窗口都不是—件易事，用户未必欢迎。最后这个问题就此搁浅（挂起）了。

无独有偶，当该产品上线约一年后，从市场返回一张更改申请单，上面反映“客户一天晚上，取出机子的电池在机外充电。后来由于忙于其他事情，3天后才再次打开MP4来使用后发现，这3天内的提醒事件一个都没有，导致她把提前3天预订飞机票的事给忘了，误了她的一桩大事。后来打电话到某公司当地办事处进行投诉。

思考一下原因： 测试如何做能规避该问题的发生？应该给出什么样的建议？ 答：可以根据时间维度来确定提醒事件的取舍，可以只将前三天或前一个礼拜的提醒事件通知给用户。

注：

• 上线前发现的BUG叫缺陷；
• 上线后用户发现的BUG故障，此时就比较严重了。

分析需求的具体方法

1. 快速理解需求的捷径：需求串讲 主要解决问题：需求理解不一致 方式：介绍需求背景、内容、进行答疑
2. 验证需求 需求文档也要测试：正确性、必要性、完整性、一致性等。
3. 从设计需求中提取测试需求
   • 软件需求是软件测试需求的主要来源，但不是全部来源，软件设计需求、软件概要设计、详细设计也都是测试需求的分析对象，是对测试需求的一种有力的补充。
   • 对于黑盒功能测试，几乎98%的需求都是来源于需求说明书，但有那么一小部分需求来自设计需求或概要设计、详细设计、数据库设计甚至包含一些架构设计。

测试策略制定

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

• 兼容性测试：web测试：要考虑到版本
• 文档测试：可以用文档的方式进行评审
• 安装卸载测试：根据不同的阶段，采用不同的测试方法（白盒。黑盒、灰盒）去进行测试。

案例： 思考案例： 1. 一个全新上线的app需要做哪些测试？ 答： 从需求规格说明书里提取信息。 2. 一个增加了新功能的app需要做哪些测试？ 答： 针对其新功能进行测试 3. 一个只修改了页面广告的app需要做哪些测试？ 答：兼容性测试，测试该页面广告设计是否合理。

测试策略的具体实施

测试策略需要确认测试使用的测试技术、测试过程的管理和控制、测试团队的组建。 根据测试的需求，选择测试技术； 在测试方案中，需要确认测试过程如何管理，确认管理使用的工具和方法。 测试过程的管理：即是测试流程，不同公司的流程是不一样的。 在没有固定测试团队的企业，还需要考虑团队的组建，比如测试的人数，高中低级的配比，入场出厂时间等等。

测试策略中包含测试计划。

测试计划的制定

根据不同的开发模式，确认测试计划，计划主要包括：：什么人、什么时间、做什么事情。 测试的目标要明确，同时要确认跟踪机制。 测试计划评审通过后，测试组需严格按计划中的时间完成各项任务。如果delay会直接影响绩效工资，如果多次严重出现可能会失去这次工作机会，对后期找工作有负面影响。

测试方案设计

每一个公司对测试计划和测试方案的定义都不一样。而且不是每一个公司都有测试计划和测试方案。

测试方案主要包括： - 测试范围：由需求分析而来 - 测试策略：包括针对不同部分的测试方法、测试用例 - 测试控制：包括测试流程，测试执行，缺陷跟踪 - 其他：环境、版本管理（配置管理和变更管理） - 测试风险：螺旋模型强调的是风险。

风险分析

分析风险的目的是及时的调整测试内容和测试方案 软件项目风险是指在软件开发过程中遇到的预算和进度等方面的问题以及这些问题对软件项目的影响。 软件项目的风险主要立案源于需求、技术、成本和进度。

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

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

组织和管理风险（较深，了解就行） - 仅由管理层或市场人员进行技术决策,导致计划进度缓慢,计划时间延长 - 低效的项目组结构降低生产率 - 预算削减,打乱项目计划 - 缺乏必要的规范,导至工作失误与重复工作

人员风险 - 作为先决条件的任务(如培训及其他项目)不能按时完成 - 开发人员和管理层之间关系不佳,导致决策缓慢,影响全局 - 缺乏激励措施,士气低下,降低了生产能力 - 某些人员需要更多的时间适应还不熟悉的软件工具和环境 - 没有找到项目急需的具有特定技能的人

开发环境风险 - 设施未及时到位 - 设施虽到位，但不配套 - 设施拥挤。杂乱或者破损 - 开发工具未及时到位 - 新的开发工具的学习期比预期的长,内容繁多

客户风险 - 客户对于最后交付的产品不满意,要求重新设计和重做 - 客户对规划、原型和规格的审核决策周期比预期的要长

产品风险 - 严格要求与现有系统兼容,需要进行比预期更多的测试、设计和实现工作 - 要求与其他系统或不受本项目组控制的系统相连,导致无法预料的设计、实现和测试工作 - 开发一种全新的模块将比预期花费更长的时间 - 依赖正在开发中的技术将延长计划进度

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

测试执行流程的设计

整个测试过程包括： 需求分析—测试计划—测试方案—需求测试—测试用例编写—测试执行（冒烟测试，系统测试，回归测试，交叉测试）—测试报告

根据项目特性制定适合项目的测试执行流程。 测试方案与用例的设计，是属于纯测试技术上的设计，但对于整个项目的测试过程，光有技术还不够，需要配合合适的测试流程。 好的策划可以对项目的测试起到事半功倍的作用。

需求测试

基于需求的测试方法是最基本的测试方法。而需求的质量直接影响到后续的开发和测试工作。 - 需求审核 - 需求测试 - 测试设计中进行需求测试 - 需求测试的要素：正确性、必要性、完整性、一致性。 - 需求测试应该尽早开始。

内部发布版本测试

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

回归测试

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

回归测试是自动化测试最好的方式

交叉测试

• 测试的枯燥性、重复性，引起的惰性
• 不同的思维模式

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

自由测试（探索性测试）

来自于项目的需求，用错误推测法来测试。

测试报告的输出

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

测试报告的内容如下： - 测试概括 - 测试过程分析 - 测试结论 - 缺陷清单 最重要的是：缺陷的分析（是功能还是设计或其他方面的缺陷）

本文转自：https://blog.csdn.net/bit666888/article/details/81161026