软 件 探 索 性 测 试 研 究 进 展

余久久, 张佑生

(安徽三联学院 计算机科学与技术系,安徽 合肥 230601)

0 引 言

软件探索性测试[1]是一种测试思想或测试策略，要求测试人员在测试过程中同时展开测试学习、测试设计、测试执行和测试结果评估等活动，达到持续优化测试工作的目的。探索性测试不是、也不隶属于某一种具体的软件测试技术(白盒测试、黑盒测试、灰盒测试)，在实际测试应用中不会受到测试软件的某一特性或方面(如功能测试、性能测试、易用性测试、界面测试等)所约束，在软件开发过程中的任一测试阶段(如单元测试、集成测试、系统测试、验收测试等)均可应用，亦可运用于不同的测试实施组织(如用户测试、第三方测试等)或与相应的测试技术结合起来。

探索性测试需要测试人员在测试过程中反复了解与学习被测软件，结合自身测试经验把不断整理与综合分析得出的测试信息快速反馈至下一次测试活动中，从而激发出更多的测试思想或测试策略。探索性测试也是当前软件测试领域中较前沿的思想理论，并不完全依赖于事先所设计的一尘不变的测试场景或测试脚本。以测试目标为向导，测试人员充分利用任何与测试目标有关联的信息，例如需求文档、用户手册、甚至是被测软件或类似产品的缺陷历史信息等，在无明确的测试指导环境下通过主动的“探索”来发现软件缺陷。

1 探索性测试

1.1 探索性测试的引入

探索性测试是近年来针对脚本化测试过程中因严格遵循“先测试设计，后测试执行”策略所暴露出的若干问题[2-5]所提出。例如，测试初期因测试需求不明确而无法确定测试场景；测试执行对需求变更的应对能力较弱，测试环境与组合的不断变化使脚本化测试难以及时跟踪；使用事先设计好的测试用例去指导测试实施过程会降低测试者的主观能动性；耗费在测试设计阶段的时间已远远超过测试执行时间而增加测试成本等。鉴于现代企业在实际测试项目的运作过程中均存在开发初期文档资料缺乏、短时间内开发版本演化过于频繁或产品不稳定、测试人员缺乏相应专业技能而没有充裕时间编写测试计划和测试脚本的现状，测试人员在测试实践中均有意或无意的不同程度采用“探索或摸索的思想”执行测试过程来弥补脚本化测试的不足，从而引入了对软件“探索测试”的思维方式。

1.2 探索性测试的组织与实施过程

探索性测试中，平行展开且相互支持而形成循环反馈的学习、设计、执行与结果分析四个测试活动构成了测试实施过程。学习阶段中，学习的内容不仅包括测试软件的用途和系统需求、显示用途及特性，也包括对相关软件的风险与失效信息(如同类软件或被测对象以前版本的失效信息)、被测对象的隐形规格说明(如开发人员、专家和用户等软件不同利益相关者提出的设计规格要求)等。设计阶段中，如何由学习阶段所获得一切与软件有关的信息而设计出高效的测试用例(集)来定位软件潜在的缺陷风险是该阶段重要的挑战。文献[6]把开发针对测试对象的测试数据与判断准则作为探索性测试设计的输出，但不必形成规范的脚本文档。文献[7]认为设计内容来源于软件的失效列表和简单的被测功能信息清单。文献[8]认为把如何从应用于某具体测试技术中所获得的以及同类软件的缺陷或风险列表中生成测试用例(集)是探索性测试设计的关键。文献[9]提出了构建分别由测试功能点描述信息与测试人员组合资源分配以行与列所组成的二维测试图作为测试设计对象，通过把不同的测试功能点组合分配给不同测试人员测试所生成的各种排列组合来指导探索性测试的执行。执行阶段可以采用手工测试或自动化测试方式，通常采用不拘泥于测试计划实现，而易于激发测试人员测试主观创造性的结对测试方式[10](两位测试人员同时参与测试过程，其中一人执行测试活动，另一人记录测试结果并且提供测试建议或提出问题)进行。其优点在于把两个不同背景的测试人员的测试信息洞察力同时运用于测试用例的设计或分析问题，有利于测试思想的激发与延伸。结果分析主要是判断测试用例是否执行，测试过程中是否产生新发现或存在测试遗漏等问题。测试用例执行通过的评判标准是该阶段的关键。作者倾向于文献[11]中提出的准则。

实施探索性测试的难点在于测试执行环节，需要具有丰富测试设计经验的测试者在项目开发周期中不完全依赖事先编写好的测试用例或测试脚本，充分发挥自由想象空间去探索被测对象。当前国内外不少专家学者都一致提出“脚本化测试为主、探索性测试为辅”的二者相互融合的方案，在不同的项目中采取不同的结合方式可以取得良好的测试效果。比较典型的有：软件测试之初以正式脚本为指导，然后在脚本中随机加入各种变化进行探索性测试并观察[12]；或是先有计划地修改事先所制定测试脚本中定义的某些步骤再进行测试；以及先脱离测试脚本的描述，而使用探索性测试思想进行自由发挥，再马上回到脚本中[13]等。尽管以上研究已取得一定进展，但是当前针对有关在探索性测试执行环节中如何取代脚本化测试中事先设计测试用例的活动，而采用另一种途径计划、建构、引导及追踪测试过程的探究仍属空白，这将成为未来关注的热点方向。

1.3 探索性测试的特点

近年来很多文献[14-16]只是把探索性测试归结为是一种可有可无的随机测试方法，旨在发现更多的缺陷。和随机测试不同，探索性测试注重对测试结果的分析与判断，把对被测对象的学习、测试设计、测试执行与分析结果作为并行与相互支持的测试活动来形成一个快速迭代，达到持续优化测试价值的目的。测试者可以缺乏测试经验，但是需要具备一定的天赋、测试直觉及想象力，高水平智商与外向型性格将直接决定探索性测试的效率[17]。探索性测试运用于敏捷开发项目会呈现出较高测试效率。敏捷开发模式下，测试者设计和执行的内容来源于频繁演化的测试用例。不断设计与执行被测对象中功能及数据的不同输入组合将导致测试对象中新的测试组合，从而拓宽和增加测试覆盖率[18]。然而其所表现出的测试组合无穷性，在脚本化测试中却无法预先全部定义。此外，迭代开发早期所呈现出软件需求变更频繁、测试场景不确定等因素将导致软件设计及测试文档的更新有难度，而探索性测试在实际应用中所具备的文档最小化特征将体现出很好的测试优势。

但是探索性测试也存在不足之处。由于当前缺乏系统的理论指导，不了解应用探索性测试的具体流程及缺乏事先计划好的测试架构，在评估测试效果与发现测试覆盖率方面还存在困难。文献[19]指出探索性测试在实际测试项目的应用中没有预防缺陷的能力。文献[20]则认为探索性测试会导致纯自由或单一的测试过程，使得测试者在测试中没有重点，漫无目的尝试各种情况试图发现软件缺陷，测试效率低下。所以目前大多数测试机构都是把探索性测试及其应用作为对常规脚本化测试过程的有益补充。

1.4 对发现缺陷特征的研究

对发现缺陷特征方面的研究也是近几年软件测试研究的热点，目前国内研究尚未起步。但是国外一些测试机构已开始尝试，主要采取与脚本化测试过程的实验数据比较来研究所发现缺陷的数目、特征类型及覆盖情况，并取得一定的成果。Juha.Itkonen等人在文献[21]中通过对两组测试者就包含于事先植入错误的开源软件分别进行探索性与脚本化测试方式的实验，实验结果表明在发现缺陷的难度方面两种测试方法无显著区别，但就所发现缺陷的危害严重程度而言，探索性测试所发现的较严重的缺陷数目略高于脚本化测试，严重性低的缺陷数目却明显高于脚本化测试。在发现缺陷类型方面，探索性测试所发现的功能性缺陷数目略高于脚本化测试；而用户界面接口缺陷与软件可用性缺陷数目则要显著高于脚本化测试。而在发现技术性缺陷及性能缺陷方面，探索性测试明显低于脚本化测试。

同样文献[22]也认为探索性测试能发现更多的用户图形界面接口缺陷，常规的脚本化测试过程中事先设计的测试用例在后续指导测试软件用户界面接口方面所起作用不大。

Prakash.V等人在文献[23]中则根据迭代开发某算数计算器程序为例，分别通过脚本化与探索性两种方法进行测试，每次测试时间为8 h、共进行7轮测试周期的迭代测试实验(实验数据如表1所示)。得出尽管脚本化测试与探索性测试都是可以发现大量缺陷，所发现的缺陷总数大体相当(试验中两种测试方法所发现缺陷数目总数分别为51和59)。但是在基于迭代开发方式下，测试初期探索性测试在较短时间内能发现较多的软件缺陷，例如在前两轮测试周期中脚本化测试与探索性测试所发现的缺陷数目分别为14与21。脚本化测试所发现的缺陷大都集中在有限的迭代测试阶段(如第2轮、第3轮与第4轮)，而探索性测试所发现的缺陷相对较平均地分布在每次迭代测试阶段中。

表1 迭代开发模式下两种测试方法发现缺陷数目

2 探索性测试设计方法

需求分析阶段为了更好地了解产品，更周密地测试，测试人员会将被测对象所包含的功能进行逐一分解来制定相应测试设计方法。探索性测试作为一种测试思想或思考风格，需要在一些典型的测试输入设计技术中(如黑盒测试技术中的等价类划分，边界值分析等)融入相应的探索式的测试输入组合与变化，以便测试人员快速探索与掌握并且设计出测试范围内的关键测试点。作者在结合文献[24-26]的基础上分别从被测对象的单个功能特性、多个功能交互特性、与基于系统功能交互特性三个方面从探索性测试输入设计的角度总结出相应的测试设计方法。

2.1 单个功能特性的测试设计方法

2.1.1联想测试设计方法

适用于对被测对象的单一功能点进行探索性测试的输入设计。测试人员在无法全面了解被测对象的功能需求的环境下，探索使用的软件产品，发现与记录所遇到的缺陷，通过测试输出进一步补充与完善后续的测试设计活动。方法的核心是基于黑盒测试中的等价类划分测试技术，归纳出的联想测试设计方法如表2所示。

2.1.2互联网测试设计方法

互联网测试设计方法是基于互联网环境下针对以网页页面形式所呈现的单个功能点，以用户操作视角主要从互联网页面的可用性与安全性两个方面启发测试设计思路，进行探索性的测试设计，学习与理解易遗漏的测试情景与异常流程。

表2 联想测试设计方法

(注：① 无特定格式或含义，开发人员计划中的或真实用户使用的输入值；② 测试输入界面所提供的默认值，如某一正常值、0值、空值、NULL等；③ 某些特殊情况下，或由某机缘巧合产生的输入值：如字符A通过Shift+a输入，变成了两个输入字符，可能与测试需求不符而发生测试异常；④ 测试输入界面提供列表框或下拉列表框环境下，测试合法的输入选项以及是否可以选定非法输入选项；⑤ 用类似选择-判断结构实现的语句体，用来判断接受输入值合法；⑥ 位于程序结尾处或某单独文件中，检测与处理整个程序所发生的任何一个错误的代码段。)

2.1.3单个特性漫游测试设计方法

漫游探索性测试方法最早由James A. Whittaker提出，其最主要优点是启发与探索范围更广泛的测试设计思路，带来更多的测试变化。作者在结合文献[24,27]的基础上从测试设计描述与实际测试意义(价值)两个方面对单个被测特性归纳出多种漫游探索性测试设计方法，为新入职的测试人员与具备一定测试经验的测试人员启发探索性测试思路，归纳后如表5所示。

2.2 基于多个功能交互特性测试设计方法

2.2.1场景探索测试设计方法

场景即从软件需求分析中提炼出描述被测软件功能及特性去实现用户实际操作行为的问题，从而由各种行为的不同组合来生成相应的测试用例及其集合[28]。由于场景一般包含多个测试用例来描述用户完成某一任务的条件、步骤与结果，用户为完成某一场景中的任务需要进行几个单一功能的交互操作，所以场景探索测试设计方法适合对被测对象的交互特性的测试设计，测试人员尝试对场景的前提条件或实现步骤做添增、删除、重复、修改等相应变化来探索发现更多缺陷。

基于交互特性的场景测试设计方法思想,是根据用户在实际中往往很少按照开发人员事先设计好的场景中所描述的步骤或方法使用软件，通过为已知或基本场景注入相应变化进行的探索测试手段。作者从探索场景变化方案、测试设计变化内容、测试设计描述与测试意义(价值)四个方面较详细归纳出具体的基于场景的探索性测试方法，归纳后如表3所示。

表3 基于交互特性的场景测试设计方法

2.2.2交互特性的漫游测试设计方法

基于交互特性的漫游探索测试设计方法的思路是在基础测试场景的基础上，探索被测任务可能产生的逻辑分支的步骤，先测试各个分支路径(方向)，然后再回到场景描述的路径(方向)测试。该测试设计思路适合指导在软件需求细节未明确的情况下有效开展探索性测试过程，弥补前期在需求测试与需求评审的不足，在一定程度上快速保证了测试质量与覆盖率。作者同样在文献[24-25]的基础上就从测试设计描述与实际测试意义(价值)两个方面对被测对象交互特性列出了以下漫游探索性测试设计方法。

2.3 基于系统功能交互特性的测试设计方法

2.3.1通用功能性与稳定性的测试设计方法

通用功能性与稳定性的测试设计方法主要围绕被测对象的使用目的、核心功能与潜在的不稳定区域进行的探索性测试设计方法。其专注于软件核心任务的功能性和稳定性。

该方法认为产品的某些隐藏性功能在仅仅考虑测试与用户交互情景,而忽视与系统服务、其它程序、文件系统的交互过程是无法被识别出的，测试人员在产品界面上也不能直接观察出某些隐藏性功能的作用。基于此，首先，把被测产品的功能在此测试设计方法中分为主要功能与贡献性功能两大类别。主要功能即从普通用户的角度来看是否达到使用产品的主要目的；贡献性功能即为使产品在使用上所具有相关实用性或易用性，提高用户使用兴趣的一些辅助性功能、增值服务类等隐藏性功能[24]。测试人员需要与软件开发人员及产品经理密切合作，重视与挖掘被测产品中的贡献性功能。其次，测试人员还需要关注威胁产品稳定性运行的若干潜在的不稳定因素：例如被测产品与操作系统交互紧密的功能；涉及到多线程操作的功能；与其它产品进行交互的功能等。具有资深测试经验的工程师可以就不稳定因素参考与借鉴文献[24]中表4所示的一些具有挑战性的测试内容及测试想法。

测试人员在了解产品目的，确定产品功能与识别产品运行不稳定因素区域后，探索性设计每个被测功能点的测试用例，实施测试并记录所发现问题。

2.3.2漫游地图测试设计方法

漫游地图测试设计思想[29,30]是在被测系统主要功能测试完毕之后，采用“漫游”方法探索测试某些易忽视功能与特性。其趣味性体现在将被测软件比喻成一个城市，把一些易于忽视的功能需求划分成“观光特点”不同的“旅游区域”。测试人员需要从整体上分析与把握被测系统的需求与目的，详细了解其需求说明文档及架构设计文档，把被测系统功能需求划分为“商业区”、“娱乐区”、“旅馆区”、“破旧区”、“历史区”、“旅游区”共六个测试着眼点不同的逻辑区域，在每一个区域内确定出需要测试的单个特性或交互特性，运用前文所介绍的单个特性与交互特性的探索性测试设计方法进行测试设计与执行。与指导旅游者游玩城市不同区域所借助的城市旅行指南类似，漫游地图对被测系统区域的划分从逻辑上划分了产品的“非主要”特性，可以有效帮助测试人员探索出某些容易被忽视的测试范围，制定出相应的测试设计方法。同样作者在文献[24-30]的基础上归纳出如表5所示的漫游地图测试设计方法。

表4 不稳定因素中挑战性的测试内容与测试想法

3 探索性测试应用现状

探索性测试拥有其独特的测试思考风格及测试设计方法，但重要的是如何把该方法应用到实际测试过程或测试技术中。本节就当前国内外有关探索性测试在实际测试活动中的应用现状作介绍。

3.1 引入探索性测试流程模型

3.1.1X模型

传统的X模型的亮点是引入了探索性测试流程，旨在无需通过制定复杂的测试计划和设计大量测试用例来发现更多的缺陷。由于X模型关注的是程序的低级别测试行为，同样对于引入的探索性测试流程缺乏指明其所需要进行相应的测试设计活动及测试内容的描述，也无明确的需求角色活动。

3.1.2X改进模型

汕头大学熊智等人在文献[31]中对X模型进行改进，在遵循原模型框架基础上，对左右两半部分内部的测试活动的执行次序进行相应调整，增加了迭代测试与回归测试。并且在X改进模型的左半部分(模块单元测试活动)与右半部分(模块间的不断交接，逐步进行集成测试)中的回归测试阶段之前都增添了探索性测试活动，并指定由测试经验丰富的测试组长担当。图1所示。

表5 漫游地图测试设计方法

图1 X改进模型

可是该应用只是把探索性测试安插在系统模块的单元测试与集成测试过程中，随机进行测试，成为回归测试的一附带补充测试。作为引入到模型中的一条简单笼统的测试流程，同样缺少对采用探索性测试设计和测试输入设计过程，对具体测试内容缺少细致分析，未形成完整的测试过程体系。

3.2 纯自由的探索性测试

纯自由的探索性测试即在常规测试中选取任意测试输入数据以任意方式组合来测试应用程序的功能[32]。与随机测试一样，不遵循任何测试技术及相应的测试计划。测试前测试人员无需学习测试对象，也无需具备测试经验或技能来完成“探索”测试过程。鉴于自由探索性测试中的“过分自由”测试特点，在实际情况下更多采取与脚本化测试方法相结合共同完成测试活动。

文献[24]认为纯自由的探索性测试方法应该在常规测试中的第二轮测试结束后介入迭代测试环节较为合适。因为被测模块中大部分危害程度较高的缺陷可能第一轮常规测试后被修复，第二轮测试将完成对修复后的缺陷的验证，且被测对象的测试免疫性大幅度提高。测试人员通过前两轮测试对测试需求已较为熟悉，从第三轮测试起通过对前面测试中所发现问题制定探索性测试计划，通过尽可能多的改变各种随机测试手段侧重探索隐藏的错误或异常流程可能触发的问题。此种介入自由探索性测试有助于提高测试差异性，解决测试疲劳现象，发现较多的用户界面错误或软件页面元素显示错误方面危害程度不是太高的隐藏缺陷。

3.3 探索性与脚本化相结合的测试

该测试方式采用以脚本化测试作为项目测试过程的主导，从测试过程整体层面来看需要设计详细的测试用例并依据测试用例文档执行测试，从执行文档化测试用例的局部层面上，开展探索性测试，由被测产品的输出,设计与执行更多的测试用例。尽管该测试方式的核心仍然是以脚本化测试为主、探索性测试为辅，但是充分利用了脚本化测试与探索性测试的部分特点。既保证了测试用例的详实性与传承性，也提高了测试的多样性，有效保证产品质量的可控性。

当然，探索性测试在软件生命周期中处于什么样的地位，何时介入脚本化测试进程中等问题，在不同的测试团队以及不同的测试项目中存在不同的定位。文献[18,24]认为详细测试用例的执行在脚本化测试初期与中期阶段可以发现并修复验证产品重要功能及主要流程上所存在的绝大多数缺陷，在测试后期(如用户验收测试、β测试)阶段由于被测产品的免疫性会逐步提高，致使事先编写好的固定的测试用例集无法适应产品的变化，存在测试盲点，所遗漏的缺陷会大都出现在用户使用方面比较特殊的场景中。所以要求测试人员借助已有测试用例的标题扩展测试思路，或利用前文所介绍的单个特性与交互特性的探索性测试设计方法启发新的测试思路，通过交叉测试策略[33](例如，测试前、中期，测试人员A与B分别测试与验证C模块与D模块；测试后期，测试人员A与B互换测试各自先前的测试模块)开展探索性测试活动。同时文献[24]给出了一个以脚本化测试为主、探索性测试为辅的流程图，如图2所示。

图2 脚本化测试为主、探索性测试为辅的测试流程图

探索性测试计划1用来确定实施探索性测试的功能模块，为确定与细化测试任务做准备。测试任务并非详细的测试计划，而是建议即将测试的内容以及测试的思路、策略，可以是对已有测试用例标题的一段简单描述[34]。文献[35]给出了一个基于模块功能领域用到的探索性测试任务模板，如表6所示。探索性测试计划2中主要依据被测模块的特点制定出相应的探索性测试设计方法，并对每个测试任务分配测试时间、人员等相关测试资源。实验数据表明了尽管测试后期实施探索性测试时间较短，但是可以发现较多的危害程度不是太高的软件易用性方面的缺陷。缺陷发现率尽管小于脚本化测试前期阶段，但却高于测试中期缺陷率30%以上。

表6 探索性测试任务模板

3.4 基于探索性测试思想的测试用例生成系统的设计

北京交通大学练荣政在文献[36]中运用探索性测试思想结合软件测试中问题模板(Q-Patterns，将一组相关问题归纳到一起而形成的测试问题组，提供作为用户或软件某类方面的问题的统一测试方法，或对同一问题提供多种测试方法[36-37]。由模板名、内容简介、测试问题摘要、适用测试例子与特别说明几部分组成)技术与测试发现缺陷历史记录信息，设计并实现了一基于探索性软件测试思想的测试用例生成系统，达到高效及精确的定位出被测软件中的缺陷信息的目的。该系统功能实现模型如图3所示。

图3 问题模板结合缺陷历史统计信息的探索性测试模型

模型主要由执行测试，测试设计与测试计划三部分组成，从对开发人员和被测软件两个方面同时进行测试任务的探索。前者体现在模型中的补充与参考“开发人员缺陷历史记录”方面，通过细致分析开发人员在软件设计中的其思维定势、编程风格等主观因素而导致可能存在的软件设计方面的缺陷，探索其编写软件模块中所隐藏的错误。后者即通过对问题模板的问题域学习和对每次探索性测试执行结果的分析，探索对象是对被测软件的设计及相关文档、软件代码。此外，问题模板中的问题域与相应的测试用例紧密关联。最后该文献提供了两个测试组在为期15天的三个测试周期内分别用传统的脚本化测试方法与问题模板结合缺陷历史统计信息的探索性测试方法相比较的测试实验数据。如表7和表8所示。

表7 两种测试方法人均发现缺陷数目比较

表8 两种测试方法对测试用例发现缺陷效率比较 %

3.5 基于规则的图形用户界面的探索性测试流程

软件图形用户界面(GUI)的测试是近年来软件测试的热门研究方向。软件中60%的缺陷来源于被测软件系统的图形用户界面，其中65%的有关图形用户界面方面的缺陷将直接导致软件功能失效[38-39]。但是被测软件的图形用户界面以手工测试方式在限定的时间内仅仅满足测试出少部分功能。即使引入探索性测试策略，但是图形用户界面的构成元素(如按钮、下拉框、下拉菜单等)较为复杂加之探索性测试具有一定的随机性，导致引导测试方向上存在困难。自动化测试在发现与重现软件低层次的代码层缺陷方面富有成效，可是测试人员通过专门的测试工具往往更多地关注对软件内部功能的测试而忽视了软件较高应用层次的图形用户界面。由于交互界面构成要素复杂且相互影响因素错综繁琐，以致设计其测试用例及维护过程困难[40-41]。基于此，Theodore D. Hellmann等人在文献[41]中结合了自动化测试与手工探索性测试方法，设计出一种基于规则的图形用户界面的探索性测试流程结构，如图4所示。测试者凭借自身测试经验自定义相应的探索性测试规则来执行利用脚本捕获/回放工具所创造的脚本测试活动，从而较好的解决图形用户界面测试所发现的异常问题。

图4 基于规则的用户界面探索性测试流程结构图

3.6 探索性测试思想在遗传算法中的应用

谢经纬等人把探索性测试思想与遗传算法[42]相结合并进行了实际运用。在面向软件故障测试的框架下对测试过程进行量化处理，提取出一系列指标与效应函数作为采用的用于遗传算法中的迭代条件，寻找出有限测试成本下最佳检查点组合[43]。

文献中采用PC-link代码检测工具针对约2万行代码的程序进行普通测试与采用有限测试成本下最佳检查点组合方法的两组测试实验，验证针对非法测试故障在基于探索性测试方法下减少测试成本的有效性。把遗传算法与探索性测试思想相结合在实际中通过测试工具对软件故障测试过程进行改进与优化，实现以测试低代价找出高覆盖的测试组合，减少测试成本。

4 总结与展望

4.1 探索性测试应用总结

前文对当前探索性测试的进展及运用现状进行了综述。探讨了其定义、特点、实施过程、测试设计方法的分类及所发现缺陷的特征状况等。此外，还简要介绍了探索性测试在实际项目中的应用现状、实验数据比较及尚存的不足之处。

探索性测试在当前实际运用中，主要还是仅以一种探索的测试设计思想或策略被引用到具体的测试项目中，其自身缺乏形成一套完整的探索性测试过程体系以及与探索性测试思想相匹配的相关测试工具的开发。在文献[24,31]中只是把探索性测试作为一条测试流程引入测试改进模型里或脚本化测试后期阶段的迭代过程中，还是以脚本化测试为主导,测试人员凭借经验去探索测试认为有疑惑的地方，均未能设计出以探索性测试为主导的完整的过程模型或体系结构。探索性测试往往会受到被测对象功能特性、测试任务、测试时间、测试经验等诸多因素的影响，测试结果不能追踪，测试经验无法传承，这需要进一步探索。文献[36,41,43]分别也只是在软件用户图形界面测试中提出了创建探索性思想的测试规则流程来指导测试，利用探索性测试思想设计测试用例生成系统，以及把探索性测试思想简单的运用到遗传算法中去。以上应用即缺少对探索性测试过程的具体构成内容作明确定义，也无有效的与开发过程交互而形成完整的测试过程模型来指导具体测试项目。总之，目前国内、外对有关探索性测试以及在实际项目中的应用研究还只是停留在理论层面上，已有的研究成果也仅局限于在常规脚本化测试中通过引入探索性测试设计(思想)的方法或技巧，来提供新的测试思路。并未阐明探索性测试从测试计划、分析(探索性测试准备)到设计、执行的一套完整测试过程，以及如何进行探索性测试管理、如何有效控制探索性测试所带来的潜在风险等问题。

4.2 未来的展望

虽然国内外专家学者在探索性测试研究方面已取得一定进展，但是仍有一些潜在的亟待研究解决的问题，下面分别予以阐述。

4.2.1构建以探索性测试为主的测试过程

探索性测试为主、脚本化测试为辅的测试方法的思想核心即测试人员借助简约的脚本用例或通过加入包含脚本化测试特点的测试思路列表来取代编写详细测试用例的环节来指导测试全过程，按照探索性测试思路与方法执行测试，发挥更多自由空间探索被测软件。该测试方法旨在尽量减少文档编写时间，而增加测试执行时学习产品的时间，拓展测试思路。

该方法中尽管不会要求设计与编写详细的测试用例过程，但是借助简约的测试脚本通过对测试对象的测试思维架构图[44](思维导图)的逐层分析而产生探索性测试列表的设计过程是该方法中探索性测试设计的关键。文献[24]中也给出一个由对测试对象的测试思维导图所产生的测试列表的探索性测试设计流程图，图5所示。

图5 探索性测试设计流程图

测试人员由测试任务对每一个测试功能点或特性进行细致分析，由最初需求规格评审阶段所得出的最重要的用例场景与主要功能的用例场景作为第一层思维导图(思维导图一)，在用例评审阶段所衍生的次要功能及功能细节用例场景以及在系统设计评审阶段补充可能遗漏的异常场景及详细校验点作为第二层思维导图(思维导图二)。测试执行中因需求变更或测试灵感的迸发对其完善与优化，形成思维导图三。测试思路由思维导图形成，内容可以包括各种探索性测试设计方法。

测试设计阶段测试者还需要将被测对象的隐性需求(如同类软件特点或在被测软件以前版本中所发现的缺陷反馈信息，不同用户可能使用到的风格及用户接口标准等)不断完善到测试思路列表中并保持优化。测试执行阶段根据测试思路列表探索性的测试同时，记录下被测对象行为的可疑之处为下一步的探索提供测试思路。但是如何在测试设计过程中明确定义测试思路列表中的构成元素而形成规范的模版体系，如何把被测对象的思维导图结合隐性需求转化为具体测试思路列表的详细过程及所使用到方法、工具等问题需要未来继续探索与实验。

4.2.2可复用探索性测试用例的设计方法

迭代设计与复用执行测试用例，并把已执行的测试用例不同程度的多次应用于该软件新的测试或同类软件的测试过程中去可以缩短测试周期，减轻测试工作量，提高测试效率[45,46]。凭借测试经验如何对已知测试场景有系统的进行输入选择、数据使用及环境条件的变化而设计出具有探索性思想的测试用例来完成测试复用过程也将成为探索性测试在实际运用中的关键之处。

目前大量文献资料都已进行详细的定义与描述，并通过实际项目建立起一系列有效的测试用例复用模型[47,48]。但是如何把相应的探索性测试设计方法中的各种探索测试变化策略描述加入到可复用测试用例设计的组成要素中，同时形成规范的标准化文档模版并实施有效测试用例复用管理过程也是一个潜在的值得研究的方向。

4.2.3探索性测试中的文档标准化管理过程

软件文档作为软件产品的伴生物，记录着软件产品从诞生之前到开发完全过程的相关信息，可具有固定不变的形式[49,50]。从测试文档的角度来看，测试过程是一测试相关文档编写与执行的过程。测试过程中的每项工作(如编写测试规格说明书、测试计划、测试场景与测试用例、缺陷统计报告、测试评审等)均需要形成相应的测试文档，包括测试相关的资源及其使用情况。作为测试过程的一部分，测试文档的编写和管理在测试中占有突出地位和相当大的工作量。高质量的编制、变更、修正、管理和维护文档，对于提高测试质量和客户满意度有着重要的现实意义[50]。

5 结 语

探索性测试作为一种不依赖于具体测试技术的测试思想或测试思考风格，是对常规脚本化测试的有益补充，但是不能完全取而代之。测试人员需要具备良好的测试素养与主观测试能动性，结合实际测试项目与测试环境合理应用探索性测试方法。作为一种前沿测试理论，探索性测试还需要作进一步的研究与探索，这对软件测试的发展具有深远意义。

[1] Cem Kaner, James Bach. The Nature of Exploratory Testing[DB/OL]. 2009. http://www.testingeducation.org.

[2] Juha Itkonen, Kristian Rautiainen. Exploratory Testing A Multiple Case Study[C]//Proceedings of International Symposium on Empirical Software Engineering,2005 Helsinki:IEEE, 2005：84-85.

[3] IEEE, Guide to the Software Engineering Body of Knowledge[S]. IEEE.Tech.Rep. IEEE-2008 Version, 2008.

[4] 余久久.张佑生.软件测试改进模型研究进展[J].计算机应用与软件, 2012,29(11):201-204.

YU Jiu-jiu, ZHANG You-sheng.Research Process of Improved Software Testing Model[J].Journal of Computer Applications and Software, 2012,29(11):201-204.

[5] 林 炜.两种软件测试方法的比较和改进[J].信息网络安全，2012(7):58-60,73.

LIN Wei. The Research and Improvement of Software Testing Methods[J].Journal of Netinfo Security,2012(7):58-60,73.

[6] 蒋方纯. 软件测试设计与实施[M].北京：北京大学出版社，2010.

[7] Torens C, Ebrecht L, Lemmer K. Starting Model-Based Testing Based on Existing Test Cases Used for Model Creation: Computer and Information Technology,2011[C]//Cyprus: IEEE, 2011:320-327.

[8] 刘 海，郝克刚.软件缺陷原因分析方法[J].计算机科学，2009，36(1):242-243.

LIU Hai,HAO Ke-gang.Cause Analysis Method of Software Defect[J].Journal of Computer Science,2009，36(1):242-243.

[9] Claudia Dencker. Test Case Maps In Support of Exploratory Testing: Annual Pacific Northwest Software Quality Conference, 2006[C]//Portland: PNSQC, 2006:357-366.

[10] Taobao QA Team.测试手段之探索性测试[DB/OL].2010. http://www.51testing.com.

[11] Sundmark, D.,Petersen, K.,Larsson, S. An exploratory case study of testing in an automotive electrical system release process:Industrial Embedded Systems (SIES), 2011[C]//Vasteras: 6th IEEE International Symposium,2011:166-170.

[12] Juha Itkonen，Mika V. Mantyla，Casper Lassenius .How Do Testers Do It? An Exploratory Study on Manual Testing Practices: Empirical Software Engineering and Measurement, 2009[C]//Lake Buena Vista: 3rd International Symposium on, 2009：494-496．

[13] Cem Kaner. A Tutorial in Exploratory Testing[DB/OL]. 2010. http://www.sast.se/q-moten.

[14] Lozina Shoaib, Aamer Nadeem,Aisha Akbar. An Empirical Evaluation of the Influence of Human Personality on Exploratory Software Testing: Multitopic Conference, 2009[C]//Islamabad: IEEE, 2009:235-237.

[15] 李军锋，栾 静.探索性软件测试解析[J].计算机与数字工程，2011, 39(8):39-42.

LI Jun-feng, LUAN Jing.Research and Analysis of Exploratory Software Testing[J].Journal of Computer and Digital Engineering,2011, 39(8):39-42.

[16] 聂长海.关于软件测试的几点思考[J].计算机科学, 2011,38(2):1-2.

NIE Chang-hai.Thoughts on Software Testing[J].Journal of Computer Science, 2011,38(2):1-2.

[17] L.Copeland. A Practitioner’s Guide to Software Test Design[M]. Boston:ArtechHouse Publishers, 2007.

[18] 马均飞，郑文强.软件测试设计[M].北京：电子工业出版社，2011.

[19] Alistair Cockburn. Agile Software Development[M]. Addison-Wesley Professional, 2007.

[20] 朱昭俊，苏 赛.探索性测试方法分析[J].计算机光盘软件与应用，2012(19):66-67.

ZHU Zhao-jun, SU Sai.The Analysis of Exploratory testing method[J].Journal of Computer CD Software and Applications, 2012(19):66-67.

[21] Juha Itkonen, Mika V.Mantyla, Casper Lassenius. Defect Detection Efficiency Test Case Based vs. Exploratory Testing: Empirical Software Engineering and Measurement, 2007[C]//Madrid: First International Symposium on, 2007:61-70.

[22] Atif M. Memon. Automatically Repairing Event Sequence-Based GUI Test Suites for Regression Testing[J]. ACM Transactions on Software Engineering and Methodology, 2008,18(2): 19-36.

[23] Prakash V, Gopalakrishnan S.Testing efficiency exploited Scripted versus Exploratory testing: Electronics Computer Technology (ICECT),2011[C]//Kanyakumari: 3rd International Conference on, 2011:168-172.

[24] 史 亮，高 翔. 探索式软件测试实践之路[M].北京：电子工业出版社，2012.

[25] James A.Whittaker. 探索式软件测试[M]. 方 毅，张 胜，钟颂东 等译.北京：清华大学出版社，2010.

[26] James A. Whittaker. Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design[M]. Addison-Wesley Professional, 2009.

[27] James A. Whittaker. Bugs, Patterns, Automation: Thoughts on More Effective Testing[DB/OL]. 2011.http://www.51testing.com.

[28] 陆永忠，宋骏礼，谷希谦. 基于行为的软件测试过程模型及其应用研究[J].计算机应用.2007，27(5):1238-1239.

LU Yong-zhong, SONG Jun-li, GU Xi-qian. Behavior-based software testing process model and its application[J].Journal of Computer Applications, 2007,27(5):1238-1239.

[29] Jon Bach，James Bach. Dynamics of Exploratory Testing: Annual Pacific Northwest Software Quality Conference, 2006[C]//Portland: PNSQC, 2006:459-462.

[30] Sven Sambaer. Exploratory Testing: Evolution or Revolution[DB/OL]. 2009. http://www.51testing.com.

[31] 熊 智，刘 莉，雷钰锋，等. X测试模型的改进与应用[J].计算机工程与设计，2011,32(8):2748-2751.

XIONG Zhi, LIU Li, LEI Yu-feng,etal.Improvement and application of X test model[J].Journal of Computer Engineering and Design, 2011,32(8):2748-2751.

[32] Sam.探索式软件测试的四个类型[DB/OL].2012. http://www.Smart Testing.com.

[33] 朱少民.软件测试[M].北京：人民邮电出版社，2009.

[34] Paul Carvalho. SBTM is not ET[DB/OL].2010. http://www.swtester.biogspot.com.

[35] Anders Classon. How to perform Exploratory Testing by using Test Charters[DB/OL]. 2009. http://www.sast.se/q-moten.

[36] 练荣政.一个基于探索性软件测试理论的测试用例生成系统的研究与实现[D].北京:北京交通大学，2008.

[37] Vipul Kocher. Insight into reusable test cases using Questioning Patterns[DB/OL]. 2009. http://www.whatistesting.com.

[38] B.Robinson,P. Brooks. An Initial Study of Customer-Reported GUI Defects: IEEE International Conference on Software Testing, 2009[C]//Verification and Validation Workshops, 2009: 267-274.

[39] Emelie Engstrom, Per Runeson, Andreas Ljung. Improving Regression Testing Transparency and Efficiency with History-Based Prioritization-an Industrial Case Study: The Fourth IEEE International Conference on Software Testing, Verification and Validation, 2011[C]//Berlin:IEEE,2011：367-370．

[40] Micah Garrison，Morris Cox，Brad Clarkson. Reinventing Deepwater Exploratory Testing: Offshore Technology Conference,2011[C].Houston: IEEE,2011:2-6．

[41] Theodore D. Hellmann, Frank Maurer. Rule-Based Exploratory Testing of Graphical User Interfaces: Agile Conference,2011[C]//Salt Lake City: IEEE,2011：107-111．

[42] 顾泽元，刘文强. 数据结构[M].北京：北京航空航天大学出版社，2011.

[43] 谢经纬，吴 昊. 探索性方法在面向故障软件测试中的应用[J].微计算机信息，2010，26(9-1):145-146.

XIE Jing-wei,WU Hao. The application of exploratory method in fault oriented software testing[J].Journal of Control & Automation, 2010，26(9-1):145-146.

[44] 陈 欣，蓝国兴，段 枫, 等. 基于思维导图的仿真实验方法研究[J]. 兵工学报，2013(3):346-352.

CHEN Xin, LANG Guo-xing, DUAN Feng etc.Design of Simulation Experiment Based on the Mind Map[J].Journal of Acta Armamentarii,2013(3):346-352.

[45] 楼 芳，李 亮，何志强. 基于本体的渗透测试用例复用模型[J].计算机工程与科学，2011, 33(2):23-26.

LOU Fang, LI Liang, HE Zhi-qiang. An Ontology Based Testing Case Reuse Model for Penetration Testing[J].Journal of Computer Engineering and Science,2011, 33(2):23-26.

[46] 卜国峰，孙志刚，丁小良. 软件测试用例的复用研究[J].四川兵工学报，2009, 30(5):124-126.

PU Guo-feng, SUN Zhi-gang, DING Xiao-liang. The reuse of software test case study[J].Journal of Acta Armamentarii of Sichuan, 2009, 30(5):124-126.

[47] 张玉彬，谢康林. 测试用例的设计和复用[J].计算机应用与软件，2008，25(1):23-24.

ZHANG Yu-bin, XIE Kang-lin. Test Case Design and Reuse Technology[J].Journal of Computer Applications and Software, 2008，25(1):23-24.

[48] 尹 平.可复用测试用例研究[J].计算机应用，2010, 30(5):1309-1311.

YIN Ping. Study on reusable test case[J].Journal of Computer Applications, 2010, 30(5):1309-1311.

[49] 季超英，宋晓秋.软件文档质量的度量方法研究[J]. 计算机工程与设计，2007，28(17)：4068-4071.

JI Chao-ying, SONG Xiao-qiu. Research on measurement of method of software documents quality[J].Journal of Computer Engineering and Design, 2007，28(17)：4068-4071.

[50] 马 平，黄冬梅.软件文档写作教程[M].北京：电子工业出版社, 2010.