软件测试：管理篇

软件测试：管理篇

本节内容

• 测试需求分析和测试策略制定

• 测试方案的设计

• 测试执行流程的设计

• 测试报告的输出（在系统测试阶段）

测试策略制定

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

2. 需求，设计，编码，开发，测试一系列阶段中，需求成本最低，测试成本最高。

3. 对于测试工作而言，所有的需求最后都需要转换为测试需求。

从测试需求开始

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

2. 测试需求的识别是后续的测试工作的基础，也是起点。

3. 测试需求主要来源于业务需求。我们在拿到需求后，要能识别测试需求，接着是分析此测试需求，最后确定并提取出测试对象。

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

   完整的需求文档包括以下内容：

• 功能需求

• 非功能性需求

• 性能需求

• 安全性需求

• 扩展性需求

• 可靠性需求

• 可移植性需求

• 易用性需求

• 兼容性需求

需求分析注意事项：

• 测试应该尽早的介入，从用户需求阶段就要介入。

• 不断变化的需求需要及时的收集和整理。

• 没有需求文档时，需要测试人员不断的收集原始的客户需求，（敏捷的测试对于需求文档的要求比较低。）

• 应有质疑、坚持的精神，当需求不明确时，可以将需求追溯到终端用户。

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

A是软件测试部负责此日历行程的测试工程师，在做日程提醒事件测试时，他发现如果手机电力不足（不足于开机），而这段时间正好有提醒事件发生，则在下次开机后不会再提醒，即发生在没电池时段内的提醒事件会丢失。
而对于这种特殊情况，需求并未有明确定义（需求只定义了到达约定的时间便进行响铃提醒，并弹出事件窗口）。于是A找到需求、开发讨论关于这种特殊情况的处理。开发认为，电力不足的情况下，本来就不可能开机，提醒事件也就不可能弹出来，目前的处理是合理的。需求设计人员认为，如果在不能开机的情况下，提醒事件需在下次开机后进行积累提醒，如果用户一个月没用此机，事务每天又多的话，再次开机后的消息太多了，光关闭这些事件窗口都不是—件易事，用户未必欢迎。最后这个问题就此搁浅（挂起）了。
无独有偶，当该产品上线约一年后，从市场返回一张更改申请单，上面反映“客户一天晚上，取出机子的电池在机外充电。后来由于忙于其他事情，3天后才再次打开MP4来使用后发现，这3天内的提醒事件一个都没有，导致她把提前3天预订飞机票的事给忘了，误了她的一桩大事。后来打电话到某公司当地办事处进行投诉。

• 1

• 2

• 3

思考一下原因： 

注：

• 上线前发现的BUG叫缺陷；

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

分析需求的具体方法

1. 快速理解需求的捷径：需求串讲 

2. 验证需求 

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

• 软件需求是软件测试需求的主要来源，但不是全部来源，软件设计需求、软件概要设计、详细设计也都是测试需求的分析对象，是对测试需求的一种有力的补充。

• 对于黑盒功能测试，几乎98%的需求都是来源于需求说明书，但有那么一小部分需求来自设计需求或概要设计、详细设计、数据库设计甚至包含一些架构设计。

测试策略制定

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

• 兼容性测试：web测试：要考虑到版本

• 文档测试：可以用文档的方式进行评审

• 安装卸载测试：根据不同的阶段，采用不同的测试方法（白盒。黑盒、灰盒）去进行测试。

案例： 

测试策略的具体实施

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

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

测试计划的制定

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

测试方案设计

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

测试方案主要包括： 

风险分析

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

需求风险 

计划编制风险 

组织和管理风险（较深，了解就行） 

人员风险 

开发环境风险 

客户风险 

产品风险 

设计和实现风险 

测试执行流程的设计

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

根据项目特性制定适合项目的测试执行流程。 

需求测试

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

内部发布版本测试

• 冒烟测试

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

回归测试

• 确认回归的内容

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

• 用例的回归

• bug的回归

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

交叉测试

• 测试的枯燥性、重复性，引起的惰性

• 不同的思维模式

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

自由测试（探索性测试）

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

测试报告的输出

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

测试报告的内容如下： 

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