第14章 软件测试过程和管理

一、主要内容

1、测试过程模型

2、组织级测试过程

3、测试管理过程

4、静态测试过程

二、测试过程模型 

1、组织级测试过程

（1）作用

• 用于开发和管理组织级测试规格说明。常用的组织级测试规格说明包括组织级测试方针和组织级测试策略。

2、测试管理过程

（1）注意

• 测试管理过程中包含测试管理和动态测试。其中“测试设计和实现过程”“测试环境构建和维护过程”“测试执行过程”“测试事件报告过程”就是动态测试过程中需要做的事。

（2）测试管理过程的作用

• 主要结合过程测试的通用过程,定义涵盖整个测试项目或任何测试阶段(例如系统测试)或测试类型(例如性能测试)的测试管理过程。 例如项目测试管理、系统测试管理、性能测试管理。
• 动态测试可以在测试的特定阶段执行（例如单元测试、集成测试、系统测试和验收测试），或者用于测试项目中特定类型的测试（例如性能测试、信息安全测试和功能测试）。

（3）涉及到7个子过程

• 测试 策划过程
• 测试设计和实现过程
• 测试环境构建和维护过程
• 测试执行过程
• 测试事件报告过程
• 测试 监测和控制过程
• 测试 完成过程

3、静态测试过程

（1）作用

• 定义了在不运行代码的情况下，通过一组质量准则或其他准则对测试项进行检查的测试。 也常称为审查、走查或检查。
• 静态测试既包括人工代码审查，也包括使用静态分析工具在不运行代码的前提下发现代码和文档中的缺陷（例如编译器、 或代码的安全分析器）。

三、组织级测试过程 

1、目的

• 制定、监测符合性并维护组织级测试规格说明，例如组织级测试方针和组织级测试策略。
• 组织级测试方针是一个执行级文档，描述组织内的测试目的、目标和总体范围。
• 组织级测试策略是一个详细的技术性文档，它定义了如何在组织内执行测试。不是针对特定的项目，而是一个通用文档，为组织中的许多项目提供指导。

2、组织级测试过程的输入

3、活动和任务

（1）建立组织级测试规格说明

• 组织级测试规格说明要求应从组织内的当前测试实践和利益相关方中进行识别，或通过其他方式进行开发。
• 组织级测试规格说明要求应当用于组织级测试规格说明的制定。
• 组织级测试规格说明的内容应获得利益相关方的同意。
• 向组织中的利益相关方传达可用的组织级测试规格说明。

（2）监测和控制组织级测试规格说明的使用

• 应监测组织级测试规格说明的使用情况，以确定其是否在组织内部被有效地使用。
• 应采取适当措施，鼓励利益相关方的行为与组织级测试规格说明的要求保持一致。

（3）更新组织级测试规格说明

• 评审组织级测试规格说明的使用反馈。
• 考虑组织级测试规格说明使用和管理的有效性，并确定和批准任何改进其有效性的反馈和变更。
• 如果组织级测试规格说明的变更已确定并得到批准，则应实施这些变更。
• 组织级测试规格说明的所有变更应在整个组织内传达，包括所有利益相关方。

4、结果

5、信息项

四、测试管理过程 

1、测试管理过程的7个子过程

• 测试 策划过程
• 测试设计和实现过程
• 测试环境构建和维护过程
• 测试执行过程
• 测试事件报告过程
• 测试 监测和控制过程
• 测试 完成过程

2、组织级测试过程和测试管理过程的关系

• 组织级测试过程是在组织范围内都会生效的， 所以说组织级测试过程会作用于测试管理过程，测试管理过程在执行的过程中会把相关的一些信息（例如组织级测试规格说明的有效性、是否需要变更等）反馈给组织级测试过程，然后组织级根据这些反馈信息进行更新。
• 所以组织级过程与管理过程的关系是：指导与反馈。

五、测试策划过程

1、目的

• 用于制订测试计划。根据该过程在项目中的实施时机，可以是项目测试计划或特定阶段的测试计划（例如系统测试计划）或特定测试类型的测试计划（例如性能测试计划）。

2、输入

3、活动和任务

（1）理解上下文

• 理解软件需求和功能实现方法，及测试需求等。

（2）组织测试计划开发

• 在理解活动上下文的基础上识别并安排测试计划需要完成的活动；
• 确定完成活动所需的利益相关方有哪些；
• 应该从项目经理、测试经理等方面去获得测试计划活动、进度和一些参与者的同意。

（3）识别和分析风险

• 确定软件测试的相关风险；

• 已经识别出的风险需要进行评审，评估与待测内容（如某个需求）的相关性（分析是否波及待测内容）。
• 选取合适的分类方法对识别出的风险进行分类，并标注风险级别。

（4）确定风险缓解方法

（5）设计测试策略

• 测试策略包括测试阶段、测试类型、要测试的特性、测试设计等。 注意，测试策略的选择与风险类别和风险级别有关。
• 根据风险的优先级，设计测试活动的优先级，根据风险的类别选择不同的测试资源和测试方法。

（6）确定人员配置和调度

（7）编写测试计划

（8）获得一致性测试计划

（9）沟通并提供测试计划

4、结果

5、信息项

六、测试设计和实现过程

1、目的

• 用于获取测试用例和测试规程，通常记录在测试规格说明中。

2、输入

3、活动和任务

（1）识别特征集

• 首先分析测试依据，理解每个测试项的特征；
• 然后将这些测试项的待测特征组合成特征集； 然后对特征集进行排序；
• 再然后是将测试特征集的组成和优先级，记录在《测试规格说明书》中；
• 同时还需将测试依据和测试特征集之间的可追溯性也记录下来；
• 要让 测试特征集的组成、优先级 获得利益相关方的同意。

（2）导出测试条件

• 首先根据测试计划中规定的完成准则，去确定每一个特征的测试条件；
• 然后基于每一个测试条件做风险分析（从风险的识别、风险的暴露水平等方面进行分析），然后根据风险优先级对测试条件进行排序； 
• 然后将测试条件记录在《测试设计规格说明书》中；
• 同时也要将特征集和测试条件的可追溯性记录下来。
• 然后让测试条件得到利益相关方的同意。

（3）导出测试覆盖项

• 通过测试技术（测试设计基于什么技术），基于测试条件去生成测试覆盖项；
• 测试覆盖项生成之后，同样要基于风险的识别和风险暴露水平进行优先级排序； 
• 然后将测试覆盖项记录到《测试设计规格说明书》中。
• 同时也要将特征集、测试条件和覆盖项之间的可追溯性记录下来。
• 然后让测试覆盖项得到利益相关方的同意。

（4）导出测试用例

• 生成测试覆盖项之后就要设计测试用例。 设置每一个测试用例之前可能都会有一些要求，也就是“ 前置条件 ”；
• 设计测试用例之前要分析每一个测试用例的条件，例如测试用例的输入、动作先后等。
• 对于测试用例同样需要按照应用风险管理的理念，做优先级的排列； 
• 然后将测试用例记录在《测试用例说明书》中。
• 同样需要将特征集、测试条件、测试覆盖项、测试用例的可追溯性记录下来。
• 然后让测试用例得到利益相关方的同意。

（5）形成测试集

• 基于执行的约束条件的分配，会将测试用例分配到一个或多个测试集合中进行测试。
• 然后将测试集记录下来，并将特征集、测试条件、测试覆盖项、测试用例和测试集之间的可追溯性记录下来。

（6）导出测试规程

• 测试规程的导出一般会根据测试用例的前置条件、活动，用例之间的依赖性，进行排序。
• 同样需要考虑相关数据和测试环境，要做风险分析和暴露水平的估计，然后基于风险的优先级排出测试规程的优先级，并记录在《测试规格说明书》中。
• 同时要将特征集、测试条件、测试覆盖项、测试用例、测试集的可追溯性记录下来。
• 然后让测试规程得到利益相关方的同意。

4、结果

5、信息项

（1）测试规格说明和相关可追溯信息

（2）测试数据需求

（3）测试环境需求

七、测试环境构建和维护过程

1、目的

• 用于建立和维护测试执行的环境。
• 维护测试环境可能根据先前测试结果进行变更。
• 在存在变更和配置管理过程的情况下，可以使用这些过程来管理对测试环境的变更。
• 测试环境需求最初在测试计划中描述，但测试环境的详细组成通常只有在测试设计和实现过程开始后才会变得清晰。

2、输入

3、活动和任务

（1）创建测试环境

（2）维护测试环境

4、结果

5、信息项

八、测试执行过程

1、目的

• 测试执行过程是在测试环境构建和维护过程所建立的测试环境上运行测试设计和实现过程产生的测试规程。
• 测试执行过程可能需要执行多次，因为所有可用的测试规程可能不会在单个迭代中执行。如果问题得到解决，则需要重新进入测试执行过程进行复测。

2、输入

3、活动和任务

（1）执行测试规程

（2）比较测试结果

（3）记录测试执行

4、结果

5、信息项

九、测试事件报告过程

1、目的

• 用于向利益相关方报告需要测试执行确定的进一步操作的事件。
• 该过程将识别测试不通过、测试执行期间发生异常或意外事件，或复测通过的情况。

2、输入

3、活动和任务

（1）分析测试结果

• 测试结果与之前提交的事件相关时，需要分析测试结果并记录事件的详细情况。
• 如果发现了新的问题，那么需要对测试结果进行分析，然后确定该事件是否需要报告，然后采取适当的措施分配给适当的人员去跟踪完成。

（2）创建/更新事件报告

4、结果

5、信息项

十、测试监测和控制过程

1、目的

• 检查测试是否按照测试计划以及组织级测试规格说明进行。 如果与测试计划的测试进度、活动或其他方面存在重大偏差，则将采取措施以纠正或弥补由此产生的偏差。
• 用于确定测试进程是否与更高级别的测试计划一致，例如项目测试计划。

2、输入

3、活动和任务

（1）准备

• 实施准备工作或采取预备措施，开展监控活动，如监控测试状态或采集测试指标并上报。
• 注意：如果这些措施是针对测试计划监控进度的，那么应该确定这些措施尚未在测试计划或组织测试策略中定义。

（2）监测

• 收集测试指标并记录测试进度；
• 通过检查测试状态报告，分析测试指标；
• 识别与计划的测试活动的差异，并记录阻碍测试进展的因素；
• 确定和分析新风险，并确定需要通过测试缓解的风险和其他风险；
• 监测已知风险的变化，以确定需要通过测试缓解的变化和需要告知其他利益攸关方的变化。

（3）控制

• 测试计划中的活动都应被实施，如明确测试人员职责并实施；
• 分层次进行测试，如集成测试、系统测试；
• 测试过程中出现于测试计划中的偏差，采取必要的控制操作，这些控制操作可能需要对测试、测试计划、测试数据、测试环境和人员进行更改。

（4）报告

• 每个报告阶段，向相关利益者汇报测试过程中与测试计划中的偏差、新的风险或者发生变化的已知风险。

4、结果

5、信息项

十一、测试完成过程

1、目的

• 在测试活动完成后执行的。它用于对特定测试阶段 或测试类型、以及完整项目的测试的总结。
• 为以后使用提供有用的测试资产（如测试计划、测试用例规格、测试脚本、测试工具、测试数据和测试环境基础设施等），恢复测试环境至初始状态，并记录测试结果并与相关人员沟通。

2、输入

3、活动和任务

（1）存档测试资产

• 那些可能在以后使用的测试资产应该被归档和保存，供后续测试活动参考。
• 要被重用的测试资产（例如，用于回归测试）在配置管理系统中被适当地标记出来。
• 那些可以在其他项目上重用的测试资产应该被识别并存档，如测试计划，手动和/或自动化测试过程，测试环境基础设施。
• 可重用测试资产的可用性应记录在《测试完成报告》中，并传达给相关干系人。

（2）清理测试环境

• 恢复软件配置和硬件设置至测试初始状态。

（3）识别经验教训

• 在测试和相关活动中顺利进行的内容；
• 在测试和相关活动中失败的内容，如bug；
• 对测试和其他过程（如开发过程）提出改进建议。

（4）总结测试完成情况

• 测试计划（例如，项目测试计划、系统测试计划或性能测试计划）；
• 测试结论；
• 测试状态报告；
• 各个测试阶段和测试类型的完结报告，及事件报告。

4、结果

5、信息项

十二、静态测试过程

1、目的

• 在不执行代码的情况下检查软件应用程序中的缺陷。
• 进行静态测试是为了仅早在开发的早期阶段发现程序缺陷，因为这样可以更快速地识别缺陷并低成本解决缺陷，它还有助于查找动态测试过程找不到的缺陷。

2、输入

3、活动和任务

（1）计划

• 需在静态测试计划中明确执行静态测试的范围、目的、评审的对象、质量特性、提通过的准则、依据等； 同时需要考虑人力、时间等资源方面的要求；
• 评审的特征要保持一致。例如用什么工具、有哪些活动、采用什么技术要达成一致；
• 确定哪些人参加评审、这些人的角色。

（2）启动评审

• 依据计划启动评审、将评审的准备资料发给相关的的参会人员；
• 评审组长组织评审人员确定评审范围、特征的要求，并确定参评人员的角色、职责和内容；
• 文档的作者对要评审的内容进行讲解。

（3）个人评审

• 每个人执行各自的评审。

（4）问题交流与分析

• 对评审发现的问题进行交流；
• 然后分析查明问题产生的原因，并根据问题的严重程度，考虑相关的测试处理相关问题；
• 然后再按根据问题状态情况分配给适当的个人或团体；
• 对评审的产品的质量要进行评价，作为评审决定的依据。

（5）修正和报告

• 对需要进行处理和变更的问题，应该创建事件报告并分配给合适的人员，与其进行沟通，处理掉相关的问题，确认评审工作的结束或者更新评审工作的状态。
• 接受评审结果为通过的工作产品，报告评审结果。

4、结果

5、信息项