探索式测试在雷达软件中的应用研究

柳　溪

(南京电子技术研究所,　南京 210039)



·测试技术·

探索式测试在雷达软件中的应用研究

柳溪

(南京电子技术研究所,南京 210039)

雷达软件测试中常会遇到测试周期短、软件文档滞后甚至缺失等问题。在这种情况下，由于探索式测试方法强调了测试设计和执行的同时性，并弱化了对软件文档的要求，因而能够发挥灵活、快速的优势。文中针对探索式测试和传统脚本测试的优缺点，将会话机制和漫游方法等探索式测试成功实践与经典的脚本式测试流程结合，提出了脚本会话测试模型。通过复用对应类型雷达软件测试历史项目的测试设计，在经典软件测试流程中引入会话机制和漫游方法，并充分利用资深测试人员的经验和组织资产，降低软件需求、设计文档以及测试人员经验和能力对测试的影响，增强测试的适应性，提高测试的效率和质量。

软件测试；雷达；探索式测试；基于会话的测试管理；测试复用

0　引　言

随着用户对软件质量要求的提升，软件测试已成为雷达软件交付前的必要环节。软件测试的质量也是影响雷达软件的重要因素。由于雷达软件开发周期受限，软件需求和设计规约很可能在测试开展之前不能完善提供，且软件测试的资源充分性也不能保证。在这种情况下，传统的软件测试方法不能发挥出最好的效果，需要研究如何借助探索式测试的方法以提高雷达软件测试的效率和质量。

经典的测试方法要求依据软件需求和设计文档，遵循测试需求分析、测试策划、测试设计、测试执行和测试总结的流程，严格按照预先设计的测试“脚本”开展。因此，经典测试方法也称为脚本测试(script testing)。脚本测试具有测试文档全面、测试覆盖率易度量、测试流程管理规范等优势。然而，随着软件迭代的加速，给软件测试留出时间逐渐减少。雷达软件测试呈现出一些新特点，包括软件需求变化快、软件文档缺乏、软件测试周期短、测试时间不足等，在这些情况下采用传统脚本测试方法的软件测试往往无法有效开展。

与脚本测试不同的探索式测试(exploratory testing)作为一种敏捷测试方法，不区分测试阶段，测试设计、执行和总结同时进行，依靠测试人员的经验和主动性对被测软件进行分析测试。探索式测试具有在时间短和文档不完善的情况下，充分发挥测试人员的经验和能力，快速、高质量完成软件测试等优点。目前，已有基于会话的测试管理模型，以及漫游法等探索式测试管理方法[1-2]。雷达产品的软件测试往往需要完整的测试文档，并要求能够有效控制测试流程和测试结果以保证测试质量，探索式测试由于弱化了对文档、测试阶段划分和测试充分性度量的要求，使之不宜直接用于雷达软件测试。

在测试时间短、文档不充分的情况下，如何结合经典脚本测试流程与探索式测试方法，是一个值得研究的问题。本文针对这一问题，我们提出了脚本会话测试模型，将会话和漫游等探索式测试方法融合到经典脚本测试流程中，以提升雷达软件测试的效率和质量。

1　研究背景

1.1经典的脚本测试模型

脚本测试按照测试需求分析、测试策划、测试设计、测试执行和测试总结的流程进行，如图1所示[3-4]。测试需求分析以软件需求规格说明或设计文档为输入，提取测试需求，构造测试项(每个测试项对应一个测试需求)，并形成测试需求说明文档;测试策划以测试需求分析为基础，对测试活动进行计划，形成测试计划文档;测试设计则根据软件需求和设计文档，为每个测试项设计测试用例，形成测试说明文档。测试执行人员按照测试用例的测试步骤，测试被测软件，记录其结果以发现缺陷。最后，所有用例执行完毕后开展测试总结，对测试执行结果以及缺陷进行汇总，形成测试报告文档。

图1　经典脚本测试流程

脚本测试能够保障测试过程对待测软件各项属性的覆盖。上一阶段制品可以指导下一阶段测试活动。测试成本易于分析，测试过程严格、可控。脚本测试对软件需求、设计和编码要求较高，例如:要求软件需求和设计文档能够详细、准确描述待测软件的各项指标和操作。同时，脚本测试中测试需求分析和设计阶段用时较长。此外，若软件设计和编码发生较大变动时，脚本测试无法快速适应变化，需重新进行测试策划、设计等工作。

1.2探索式测试原理

探索式测试是一种敏捷测试方法，强调经验的重要性，以及在测试中同时开展测试需求分析、测试设计、测试执行和测试结果评估等活动，持续优化测试工作。其主要特点是：(1)强调测试设计和执行的同时性；(2)适用于在短时间内发现被测软件一些重要缺陷或事先没有能够进行详细测试设计的情况；(3)通过测试来不断学习被测系统；(4)快速实验、随时调整。作为一种敏捷软件测试方法，探索式测试相应弱化了对软件文档的要求，并更关注测试本身，在保证软件测试质量的同时缩短软件测试周期，尤其是测试设计阶段占用的时间。一般更适用于人工测试或需要大量人工分析的自动化测试。

探索式测试的主要优点在于：(1)充分利用测试人员经验；(2)适用于需要学习的系统、有时间约束、补充测试等情况；(3)适应性强，尤其是需求变化、规约不明确情况；(4)测试对开发的反馈较快；(5)能够发挥创造性，降低“杀虫剂”效应[5-7]。同时，探索式测试也体现出测试文档不完善和测试覆盖率不易直接度量等不足[8]。

2　相关工作比较

虽然“探索式测试”一词在1983年提出[8]，但其软件测试方法一直在熟练的软件测试人员中使用。 Whittaker[2]还进一步扩展了探索式测试的概念和方法，总结了微软开展探索式软件测试的经验，并提出了漫游方法。Itkonen[9]等人的研究表明，探索式测试比传统方法的缺陷误报率更低，发现缺陷数量更多，如在用户界面测试中多发现了43%的缺陷。在微软Windows 2000兼容性认证中也采用了探索式测试方法。Nassar[5]等人还统计了探索式测试方法在瑞典软件公司测试活动中的使用情况。探索式测试在互联网、医疗、信息系统等各类型软件测试中也都有运用[10-11]。

目前，探索式测试的开展方法有：“漫游法”“捕获-重放”等方法[2,12]。对探索式测试的管理方法已形成以“基于会话的测试管理”为代表的管理模式[1]。漫游法是对微软在进行探索式测试实践的经验总结，这个方法描述了如何开展“探索”，从而尽可能充分的探索被测软件、发现隐藏缺陷[2]。捕获-重放的方法主要用来记录探索式测试的过程，从而提高探索式测试的可重复性，并为确认缺陷保存依据，同时缩短回归测试时间[12]。在管理模式方面，基于会话的测试管理(SBTM)是探索式测试管理模型中最常见的一种，其中的测试活动通过基于时间片段限定的测试会话来计划和控制，以迭代的方式推进[1]。基于线索的测试管理(TBTM)是对SBTM的发展，是以问题和目标为中心的更为松散的方式管理测试过程。Lyndsay[13]等人还进一步提出了测试点的概念，并在会话上增加了风险等级的概念。

本文提出的脚本会话测试模型对会话进行了扩充，并将会话、漫游方法与经典的脚本测试方法相结合，以使得脚本测试流程与探索式测试的优势互补，从而发挥更好的效果。

3　脚本会话测试模型

由于雷达软件开发周期受限，软件需求和设计规约很可能在测试开展之前不能完善提供，且软件测试的资源充分性也不能保证。雷达软件的系统和配置项级测试仍以人工测试为主。应用探索式测试方法是提高雷达软件测试效率，充分发挥测试人员的经验和能力，在测试文档不全的情况下开展软件测试的必要选择。然而，雷达产品软件测试通常需要满足特定的标准和规范的约束，以有效控制测试流程和测试充分性度量，同时还要提供完整的测试文档，并保证测试质量。利用探索式测试策略可以缩短测试周期，但探索式测试不易直接度量测试充分性，且弱化了测试文档。而文档、测试流程管理和充分性度量则正是经典脚本测试的优势。因此，脚本会话测试模型将探索式测试与经典脚本测试结合，以借助经典脚本测试成熟的管理流程和探索式测试的高效、适应性强等优势。

3.1脚本会话模型整体流程

脚本会话模型整体流程，如图2所示。其遵循经典的脚本测试流程，将测试过程划分为测试需求分析策划和设计、测试执行以及测试总结的步骤开展。但在测试需求分析策划和设计阶段，利用同谱系雷达软件相似性较大的特点，根据当前产品需求，将测试项和测试用例大量的从历史典型数据中复用。同时，在测试执行过程中采用扩展的探索式测试方法，通过基于会话方式开展，会话执行时借助漫游测试法[2]探索软件特性，并根据实际情况补充调整测试用例。测试总结报告借助会话记录单进行整理，并将本产品测试数据重新整理后纳入复用库。具体包含以下步骤：

图2　脚本会话测试模型流程框架

1) 测试需求分析、策划和设计阶段:借助测试设计辅助工具从雷达软件测试典型数据复用库复用测试项和用例，降低对软件需求和设计文档的依赖，初步完成测试需求的提取和测试用例的设计，产生第一版测试需求规格说明、测试计划和测试说明文档。

2) 测试执行阶段：测试执行以基于会话的方式开展，并对一般会话进行扩展。根据测试设计和计划，确定每个会话的主旨、用例和测试方法。测试人员在每一次会话中，根据设计阶段确定的漫游策略，针对一个测试项进行“探索”，补充测试用例。测试人员在会话结束后整理会话记录单。根据本轮会话执行情况，记录缺陷、改善测试设计，并准备下一轮会话。如此迭代直到测试结束条件满足，测试执行结束。随后更新测试需求规格说明、测试计划和测试说明文档。

3) 测试总结阶段：借助测试执行中各个会话报告单，总结缺陷，产生测试报告；并对本产品测试数据进行抽象和优化，纳入雷达软件测试典型数据复用库中。

需要注意的是，由于雷达基本原理相同，并且同谱系不同雷达相似度较高，在测试需求分析、策划和设计阶段，即使软件文档不充分，雷达软件测试人员依然可以根据经验及测试典型数据复用库，完成初步的测试设计。在测试执行阶段，对于软件文档中未详细说明的产品新特性，可以借助漫游测试法[2]探索软件特性，并结合用户沟通和测试人员对各谱系雷达功能的经验，在测试中学习被测软件、补充和优化测试设计。

3.2测试经验的固化和利用

探索式测试方法强调测试人员的经验。由于历史测试项目中的测试信息经过了实际项目的检验，是重要的组织资产，也是资深测试人员经验的外在表现。测试复用是利用测试人员经验的有效手段。

不同雷达产品其基本工作原理都是相同的，雷达操控手操作方式接近，从而使得各个雷达系统软件测试需求结构相似，构成了雷达软件测试复用的基础。通过分析，三年内同谱系雷达各产品功能需求差异一般不超过25%；同时，为保障技术稳定性，各谱系内部软件继承性较大，同谱系雷达软件代码复用率可达70%以上，部分较为成熟的产品其代码复用率甚至可达到80%。因此，同谱系不同产品测试用例有较多可以复用。

我们按照雷达产品类型，将历史测试数据按照产品类型进行归纳和整理，形成雷达软件测试典型数据复用库，从而降低软件需求和设计文档质量以及测试人员的经验和能力对雷达软件测试设计质量的影响。复用库的整理遵照如图3的流程：首先，对各产品测试项目进行抽象，取出产品具体指标和操作特征；其次，提取同类产品测试数据的相似性，合并各产品测试需求和测试用例；然后，补充各产品特性测试数据；最后，去除冗余并规范文字描述。当新产品测试结束后，新产品的测试数据再次进行抽象，并按照上述相似的过程，纳入复用库中，为下次复用做准备。在从测试复用库中复用测试数据时，需要根据产品特性补充产品具体信息。由于雷达对外数据交互依据通用军/民用标准，数据报文格式已经标准化。因此，复用库在整理时只需对具体数值进行“参数化”，并在复用时根据具体产品坐标、范围、频段等信息，对复用库测试用例中的“参数”进行实例化。

图3　测试典型数据复用库整理流程

由于各类型雷达软件测试典型数据复用库信息量大，从复用库中提取必要的测试数据需要借助计算机工具辅助。我们开发了基于复用的测试设计辅助工具，以帮助测试人员从复用库中查询和复用相关测试项和测试用例。测试人员可根据具体产品特性，复用的测试用例进行修改和编辑，添加和补充具体数值和信息，完成对复用测试用例的实例化。

3.3基于会话的测试执行

探索式测试需要在良好管理下才能发挥效果。基于会话的测试管理(SBTM)，是探索式测试领域中最常用的管理实践[1]。脚本会话测试模型中，针对雷达软件测试的特性，参考TBTM和文献[13]，对会话进行了扩展，包含以下六点：

1)主旨(charter)：测试项(对应一个测试需求)。

2)人员：一个会话指定一个测试人员。

3)优先级：根据会话主旨对应的软件特性的重要性级别确定。

4)先决条件：对测试环境和待测软件的要求。

5)测试方法：测试用例集和漫游测试方法。

6)会话记录单(session sheet)。

其中，会话记录单记录了会话的执行信息：主旨、测试人、优先级、实际用时(包括会话准备时间、会话执行时间、缺陷发现和报告时间)、测试用例集的实际执行情况(包括测试用例是否通过、实际执行截图等信息)、发现的缺陷(包括缺陷严重程度、缺陷关联用例)、遇到的问题(包括可能解决方法)、对其他会话和后续测试的影响和注释等。

传统会话机制中，每个会话关注一个软件功能点[1]；而我们提出的扩展会话中一个会话则关注软件功能点分解出的测试项，会话粒度更细，执行时间更短，对测试资源需求更少。同时，扩展会话引入了测试优先级和先决条件等信息，测试负责人和测试工程师可根据实际情况快速调整测试资源的分配，并将传统会话关注时间因素转移为关注待测试的具体问题。

测试执行管理模型，如图4所示。测试负责人在测试开始时初始化各个会话，并分配测试任务。测试执行过程分为若干轮进行，每轮为一天。每轮执行中，测试负责人选定本轮要进行的会话，并跟踪测试人员的会话执行。测试人员在每个会话中按照预先指定的测试方法探索被测软件，并将执行过程记录在会话记录单中；同时分析当前会话是否对后续的其他会话的影响，例如，是否需要修正后续某会话的主旨或会话划分应重新制定。在本轮会话执行结束后，测试负责人召集会话总结会，测试人员汇报测试执行情况并记录缺陷，测试负责人评审会话记录单和测试结果。根据测试情况反馈判定测试是否达到预定结束条件：若是，则进入测试总结阶段；否则，修改完善测试设计和会话，开始下一轮测试。

图4　基于会话的测试流程

探索式测试对测试人员创造性的发挥主要体现在脚本会话测试模型中的测试执行阶段。测试人员借助对被测雷达产品软件的经验，充分发挥其创造性，分析被测软件特性，借助启发式方法，根据被测软件实际实例化测试用例，同时补充测试用例，对软件进行深度测试。为了有效管理测试执行过程，提高会话效率，每轮会话开始之前，测试团队针对各会话对应测试项的特性，为各会话选定若干漫游方法。

漫游探索法是对测试人员在进行整体测试时最常使用的启发式方法的总结，包括以下六类：

1)商业区漫游。关注测试用户使用软件主要特性，包括指南测试、卖点测试、地标测试、极限测试、快递测试、深夜测试和垃圾车测试等方法。

2)历史区漫游。关注测试遗留组件，包括近邻测试、博物馆测试、上一版测试等方法。

3)娱乐区漫游。关注测试辅助功能，包括配角测试、深巷测试、通宵测试等方法。

4)旅游区漫游。通过遍历软件各项功能进行测试，包括收藏家测试、长路径测试、超模测试、多拷贝测试、偏远酒吧测试等方法。

5)旅馆区漫游。关注常被忽视或次要的功能测试，包括取消测试、懒汉测试等方法。

6)破旧区漫游。尝试恶意甚至有害操作进行测试，包括破坏测试、反叛测试、强迫症测试等方法，详见文献[2]。

测试人员在会话执行中，依据测试用例和指定漫游方法，测试被测软件，并根据实际测试情况反馈补充测试用例。

根据我们的调研和试验，建议雷达软件测试时优先选择指南测试、极限测试、取消测试、懒汉测试、破坏测试和强迫症测试。在具有用户手册等文档时，选用卖点测试、地标测试；在已知某模块问题较多时，使用近邻测试；在需要涉及系统启动关闭、长时间运行的情况下，采用通宵测试、深夜测试等方法。

3.4实验结果

为了验证脚本会话模型，我们将脚本会话测试模型在测控类雷达软件测试项目中进行实验。测控类雷达软件研制过程较为稳定，适合在实验中开展对照。此外，测控类雷达产品研制任务增长多(2013～2015年该谱系新增产品数占新增产品总数的33%)，测试资源较为紧张，需要运用脚本会话模型。目前测控类雷达软件测试典型数据复用库已完成整理。从近3年5个项目全部1 062个测试项和6 432个测试用例中，经过筛选、合并和抽象化，共收录了828个测试项和3 413个测试用例。经验和积累适合于应用脚本会话模型。

实验在近期开展的测控类雷达软件测试项目中随机选择了三个项目的软件系统测试上开展。在测试之前对这3个项目的软件文档编写、研发和第三方测试过程中均未做新的要求或进行干预，程序及文档的质量与历史项目水平相近。实验中，测试人员在设计阶段通过从复用库中复用测试用例，执行阶段运用漫游探索法开展探索式测试执行并记录会话记录单辅助测试总结。实验统计了运用本文提出的脚本会话测试模型时测试时间和缺陷数量，包括遗留到第三方测试时才发现的缺陷数量。

试点结果统计数据，如表1所示(项目名称和代号未显示)。这三个项目的测试用例平均复用率约为72%。结果显示，借助雷达软件测试典型数据复用以实现将测试人员经验运用于软件测试设计中，相比采用传统脚本测试方法的平均用时，整个测试流程总共节省时间约30%；尤其是对于雷达产品测试设计，平均每个用例的设计时间可以节省约45%左右。通过测试复用，还可以减少用于沟通和软件文档更新的时间。此外，借助会话记录和各轮会话对测试活动的反馈，测试执行阶段测试过程记录更为详细、测试人员对软件及缺陷的理解更为清晰，测试总结中与用户/开发方的缺陷交流时间和测试报告编写时间下降，按照缺陷数量平均，测试总结阶段节省时间14%左右。同时，遗留到第三方测试才发现的缺陷个数比历史平均下降，遗留缺陷率由19%左右下降到8%(三项目平均)，验证了软件测试质量的提升。但需要注意，由于脚本会话模型中测试执行需要增加会话总结会和讨论，平均每个用例的测试执行时间增加了约9%(项目A和项目B平均)。

表1脚本会话测试模型试点统计h

项目测试用例个数测试设计耗时测试执行耗时测试总结耗时发现的缺陷数遗留缺陷数历史平均128777225713013025项目A114529025611013812项目B13793193171231459项目C12042882651081358

鉴于不同类型的产品历史数据积累充分程度不同，并考虑产品的发展和我们预期，在保证测试质量的同时，应用脚本会话测试模型，能够节省雷达软件测试整个流程20%～30%的时间开销，其中测试需求分析、策划和测试设计阶段节省用时可达40%～50%。但同时需要注意控制会话总结和讨论对测试时间开销的影响。

4　结束语

脚本会话模型将探索式测试方法与传统的脚本测试流程结合。在雷达软件测试时间短、任务重以及软件需求和设计文档往往滞后或不完备的情况下，在保证测试质量的同时，能够缩短测试时间，产生齐备的软件测试文档，并确保测试流程可控。

在今后的工作中，我们会将脚本会话测试应用在更多雷达产品软件测试中，并继续整理其它类型雷达软件测试典型数据复用库。同时也将通过实际工程试用，不断改进相关的测试管理方法和测试技术。

[1]BACH J. Session-based test management[J]. Software Testing and Quality Engineering, 2000, 2(6): 1-10.

[2]WHITTAKER J A. 探索式软件测试[M]. 北京: 清华大学出版社, 2010.

WHITTAKER J A. Exploratory testing[M]. Beijing: Tsinghua University Press, 2010.

[3]孙俊若, 席晓强, 叶波, 等. 记载雷达软件开发全周期测试技术研究[J]. 现代雷达, 2010, 32(1): 85-89.

SUN Junruo, XI Xiaoqiang, YE Bo, et al. A study on whole cycle test technology in airborne radar sofware development[J]. Modern Radar, 2010, 32(1): 85-89.

[4]李昊. 雷达软件测试用例复用技术研究[J]. 现代雷达, 2012, 34(3): 78-82.

LI Hao. A study on the resuse of radar software testing cases[J]. Modern Radar, 2012, 34(3): 78-82.

[5]NASEER A, ZULFIQAR M. Investigating exploratory testing in industrial practice[D]. Ronneby: Blekinge Institute of Technology, 2010.

[6]ITKONEN J, RAUTIAINEN K. Exploratory testing: a multiple case study[C]// 2005 International Symposium on Empirical Software Engineering. Los Alamitos: IEEE Press, 2005: 82-91.

[7]ITKONEN J, MANTYLA M V, LASSENIUS C. How do testers do it? An exploratory study on manual testing practices[C]// 2009 3rd International Symposium on Empirical Software Engineering and Measurement. Washington DC: IEEE Press, 2009: 494-497.

[8]KANER C, FALK J, NGUYEN H Q. Testing computer software second edition[M]. [S.l.]: Dreamtech Press, 2000.

[9]ITKONEN J, MANTYLA M V, LASSENIUS C. Defect detection efficiency: test case based vs. exploratory testing[C]// Proceedings of International Symposium on Empirical Software Engineering and Measurement. Madrid: IEEE Press, 61-70.

[10]柳溪. 探索性软件测试方法及其在嵌入式系统中的应用[J]. 现代电子技术, 2014, 37(20): 74-79.

LIU Xi. Exploratory software testing approaches and their application in embedded systems[J]. Modern Electronics Technique, 2014,37(20): 74-79.

[11]柳溪, 马康, 刘智. 融合探索性与脚本方法的第三方软件测试模型及其应用[J]. 信息化研究, 2013,39(6): 43-48.

LIU Xi, MA Kang, LIU Zhi. Research and application of the third-party software testing model combining exploratory and script testing techiques[J]. Information Research, 2013,39(6): 43-48.

[12]HELLMANN T D, MAURER F. Rule-based exploratory testing of graphical user interfaces[C]// Proceedings of Agile Conference.[S.l.] : IEEE Press, 2011:107-116.

[13]LYNDSAY J V, EEDEN N. Adventures in session-based testing[J]. Workroom Productions Ltd., 2003,27(5): 1-17.

柳溪男，1984年生，工程师，工学博士。研究方向为软件工程、嵌入式和信息系统软件的测试自动化、基于模型的测试和验证、安全性和可靠性测试和验证等。

Application of Exploratory Testing on Radar Software

LIU Xi

(Nanjing Research Institute of Electronics Technology, Nanjing 210039, China)

Radar software testing suffers from insufficient time allocation and incomplete or out-of-date software specifications. In such case, exploratory testing can help to achieve more adaptive and efficient testing, because it emphasizes parallel testing design and execution, and lowers the requirement on software specifications. It is an interesting question how to incorporate exploratory testing techniques into radar software testing. According to the pros and cons of exploratory testing and classical script software testing approach, the session-script testing model is proposed which combines sessions and test tours with classical script testing process. By reusing from past radar software testing design, and incorporating sessions and test tours in classic software testing process, current testing project may take advantage of expert radar software testers' experience and organization assets, and there is less affect from software specifications to software testing quality. As a result, high quality radar software testing becomes more adaptive and efficient.

software testing; radar; exploratory testing; session-based testing management; test reuse

10.16592/ j.cnki.1004-7859.2016.09.018

柳溪Email：williamxliu@qq.com

2016-04-26

2016-06-28

TP311.5

A

1004-7859(2016)09-0086-06