探索式软件测试分析方法研究

王华

（中国电子科技集团公司第二十九研究所 四川省成都市 610036）

传统测试中，通常在测试计划阶段测试人员需要按照需求或设计要求写出测试方案和测试用例，但在我们没有真正接触一个软件之前，我们很难完全了解这个软件，因此写出的测试方案和测试用例的可操作性有可能不强，而且在进行软件测试分析时往往过于注重对测试需求点的分解，对软件的运行欠缺系统性的整体分析，这对软件质量的保证绝无裨益，基于此，有必要对软件测试分析的方法进行研究。本文提出“探索式软件测试分析方法”，利用探索式方式为软件测试分析提供一种思考路径。

1 探索式软件测试思维模型

James Bach将传统的测试行为分为检验和测试。检验就是使用确定的测试步骤或者测试脚本来检验系统，而测试则是通过对未知的探索、学习和实验等一系列科学手段，发现并设计出新的测试用例，最后执行这些测试用例来验证系统。因此他认为真正的测试都需要探索，而测试分析则是探索式测试的核心部分，没有良好的测试分析是不可能做好探索式测试的。

探索式软件测试的思维模型简称为CPIE，即收集(collation)、划分优先级(prioritization)、分析(investigation)和实施(experimentation)。

CPIE过程是一个循环的过程，在软件的探索式测试过程中，信息的收集和优先级的划分，是测试分析的前提，有利于加强对被测软件的系统性认识，提高后续测试分析的针对性，而测试分析和实施又是互相驱动和完善的过程。

2 探索式软件测试分析方法研究

基于探索式软件测试思维模型的特点，本文将从信息的收集、划分优先级和基于场景的探索式测试分析三个方面对探索式软件测试分析方法进行研究。

2.1 信息收集

探索式软件测试思维模型的第一步是收集，即接收到测试任务后，测试人员首先需要收集关于被测软件的所有信息，如项目信息、需要达成的测试目标等。

2.1.1 项目信息

项目信息一般可从研制方案报告、软件研制要求、研制任务书、需求规格说明等研发文档中获取，但探索式测试分析更强调测试人员与项目利益相关方（如用户、软件负责人、项目经理）的沟通交流，通过交流获取项目相关信息，如软件的使用用户，用户可能的使用行为、用户的兴趣点和使用目的、软件重要等级、进度节点、测试环境、软件复用信息、利益相关方明确的测试要求、项目相关的人员信息等。

图1：测试场景分析法

获取的项目信息是后续划分优先级和测试分析的重要输入，从信息的收集及与项目利益相关方的交流中，我们往往能够发现软件的典型使用场景和风险点，从而明确测试分析的重点。

项目信息的获取应该是持续性的，贯穿于整个测试生命周期之中，并根据实时获取到的项目信息明确或更新测试目标、优先级划分及测试分析的内容。

2.1.2 项目测试目标

项目测试目标一般包括两个方面：进度目标和质量目标。测试人员需要根据获取的项目信息及与项目利益相关方的交流，明确利益相关方需要测试达成的测试目标是什么，即明确在什么时候以什么质量完成测试。

进度目标可结合项目研发计划进行明确。质量目标可从以下维度考虑：是否满足需求、是否满足用户标准、用户反馈的重大缺陷是否已经解决。但同时质量目标应便于量化，参考量化指标如：用例密度、千行代码缺陷数、需求覆盖率、逻辑覆盖率等，并参考同属性项目历史度量数据进行量化指标的分析评价。

测试目标可根据实际情况进行分解，如根据被测软件不同特性的开发进度和交付节点的不同可确定不同的进度目标，根据被测软件不同特性的重要程度、复用情况不同也可建立不同的质量目标，这便于为后续测试优先级的划分和测试分析的重点提供依据。

2.2 划分优先级

信息收集完成之后，进入探索式软件测试思维模型的第二个过程：划分优先级。即测试人员需要对被测软件进行优先级的划分，优先级的划分可从项目周期、模块或特性的重要等级、软件成熟度和测试目标等维度进行探索分析，分析思路如下：

（1）项目周期：短周期项目可将基本场景的遍历作为高优先级；长周期项目可将特殊场景和异常场景的深度挖掘作为高优先级；

表1：数据记录软件子场景分析

（2）模块或特性的重要等级：可根据用户的主要应用和需求的优先顺序来确定模块或特性的重要等级，重要等级高的模块或特性作为高优先级；

（3）软件成熟度：新增部分的用户需求应作为高优先级，在新增部分做重点分析及测试，即加强深度测试；继承性部分加强特殊场景和异常场景的分析及测试，作为继承性部分的高优先级；

（4）测试目标：根据确定的测试目标可在以上维度进行优先级的调整，保证整体测试目标的达成。

2.3 基于场景的探索式软件测试分析

测试人员划分好优先级后就进入探索式软件测试思维模型的第三个过程：分析，即测试人员需要对确定即将测试的软件进行分析，并预测其可能输出的结果。

探索式软件测试分析的立场是测试人员结合场景真正使用了解被测试软件，因为只有对被测软件有一定的了解和掌握才能高效地对该软件进行测试，因此，探索式软件测试分析注重对软件运行场景的分析。

2.3.1 场景分析过程描述

对软件运行场景的测试分析是一个从整体到局部的过程，可先将整个测试对象作为一个大系统，从系统角度进行探索分析。首先，前期收集的信息和优先级的划分可作为测试分析的重要输入，从信息的收集和用户的交流中，我们能够获取软件的使用用户，进而探索分析其兴趣点和使用目的，从用户使用角度尽可能挖掘所有显性和隐性的使用需求和可能的用户使用行为，并探索分析潜在的系统破坏行为，即可能造成软件失效的危险事件，从而提炼出典型的应用场景。然后，根据提炼出的典型应用场景，结合整个系统的外部输入和输出梳理系统业务流程图，从整个全局的系统业务流程图对运行场景进行探索分析不同的可能性，分析思路可参考典型的场景法，见图1所示。

通过对系统业务流程图的探索分析，获取用户可能的使用行为事件，事件触发形成场景，不同的事件，其触发和处理结果形成事件流；梳理场景中的主线，即可确定基本流；同时围绕基本流，结合潜在的系统破坏行为，形成备选流事件。

2.3.2 场景分析实例

基于场景的探索式测试分析是循序渐进、逐渐分解的过程，逐层从主场景向下进行探索分析形成子场景，最终梳理形成整个被测软件的所有运行场景。本次研究选取了某数据记录软件作为试点，对该软件基于场景的探索式测试分析具体过程为：根据提炼出的典型应用场景，结合整个系统的外部输入和输出梳理系统业务流程图，对业务流程图中的主要输入输出业务点分析其可能存在的用户使用行为、系统事件、以及潜在的系统破坏行为，结合这些行为事件，根据图1典型的测试场景分析法梳理形成子场景，针对每一个子场景进行测试要点的探索分解，直到分解到不能再进行细分为止。本次实践过程中，对该数据记录软件子场景的具体细分过程见表1，对每个子场景的分解从测试目标、输入描述、输入来源、触发方式、测试要点、要点分解，观测点及预期输出共8个方面进行探索分析。

3 总结

传统的测试分析能够根据已有的业务需求和验收条件梳理出每个需求验收点，但欠缺对软件运行的整体系统性分析，为解决这一问题，本文提出探索式软件测试分析方法，并通过对软件运行场景的系统性分析给软件测试者一个基于场景的探索式测试分析思路。随着测试人员对项目信息的收集、优先级的划分、软件运行场景的逐层分解和分析，对软件有了越来越深入的了解之后，测试人员会发现哪些是软件运行过程中最为重要且风险最高的场景和技术点，并根据分析结果及时调整测试思路或方法，补充测试点，从而获得更多高价值的测试用例，这将使测试变得更加有效率。