探索性软件测试方法及其在嵌入式系统中的应用

摘 要： 探索性软件测试发挥测试人员经验和创造性，强调软件测试各阶段的同时性，并利用测试学习被测系统，已形成应用体系并在工业界成功运用。将探索性测试技术应用于嵌入式系统软件测试，是解决测试时间紧、任务重、软件文档不完备等现实问题的有吸引力的方法。然而，嵌入式系统测试要求严格的软件测试管理流程和文档，并需对测试执行进行有效评价，这些要求在探索性测试中被弱化。调研和综述探索性测试技术，分析探索性测试技术与嵌入式系统软件测试体系的关联和冲突，是将探索性测试在嵌入式软件测试中的恰当运用的关键。以此为基础，对探索性测试在嵌入式系统软件测试中的应用模型提出了建议，并对应用中的问题和后续研究进行了讨论和展望。

关键词： 探索性软件测试； 嵌入式系统软件测试； 基于会话的测试管理； 敏捷测试

中图分类号： TN911?34； TP311.5 文献标识码： A 文章编号： 1004?373X（2014）20?0074?06

Exploratory software testing approaches and their application in embedded systems

LIU Xi

（Nanjing Research Institute of Electronics Technology， Nanjing 210039， China）

Abstract： To apply the exploratory testing technology to the software testing of embedded systems is one of the promising ways to solve the problems including tight schedule， heavy tasks and incomplete software documentations. Rigorous testing management process and documentation are usually required for testing embedded systems， which is however weakened in exploratory testing. In order to guide proper application of exploratory testing in embedded system software testing， it is necessary to survey and review exploratory testing technology， analyze the correlation and conflict between exploratory testing technology and software testing system of embedded systems. Based on the survey， some suggestions are given on the application model in software testing of embedded systems. The problems andfollow?up study concerning the application are also discussed.

Keywords： exploratory software testing； embedded system software testing； session?based testing management； agile testing

0 引 言

软件在嵌入式系统中的作用越来越大。软件的质量不仅直接影响任务的成败，也关系着设备甚至人员的安全。随着用户对嵌入式系统软件质量要求的提升，软件测试已成为嵌入式系统交付前必不可少的环节[1]。

经典的测试方法要求依据软件需求和设计文档，遵循既定的测试流程，严格按照预先设计的“脚本”开展。因此经典测试方法也称为脚本测试（Script Testing）。随着嵌入式软件迭代的加速，给软件测试留出时间逐渐减少。嵌入式系统软件测试呈现出一些新特点，包括软件需求变化快、软件文档缺乏、软件测试周期短、测试时间不足等。

探索性测试（Exploratory Testing）具有在时间短和文档不完善的情况下，充分发挥测试人员的经验和能力，快速、高质量完成软件测试等优点。已形成了一套管理方法和应用模型[2?3]，并在微软等多个企业开展了成功的实践[3?5]。探索性测试方法关注于实用，对它的研究也多数集中在实际应用方法而不是理论研究上[3，6?8]。

探索性测试是解决嵌入式系统软件测试需求变化快、软件文档缺乏、测试周期短等现实问题的可行手段之一。为了恰当运用，需要总结探索性测试的一般性应用方法体系，并探讨其与嵌入式系统软件测试体系的联系和冲突。在此基础上提出适用于嵌入式系统软件测试的探索性测试应用模型。

1 探索性软件测试的基本原理

探索性测试的概念形成较早，经过随后的发展已形成了一定的应用体系。

1.1 探索性软件测试的概念

传统的软件测试分为测试需求分析、测试策划、测试用例设计、测试执行和测试总结等主要阶段，依次开展[1]。传统软件测试流程依赖于完整、详实的软件需求和设计文档作为输入。而在现实的测试任务中，软件需求和设计文档往往有误或不完备，这导致脚本测试活动无法正常有效开展。

“探索性测试是同时进行学习、测试设计和测试执行的一种测试方法；也就是说，测试没有事先通过确定的测试计划定义，而是动态地被设计、执行和修改”[9]。探索性测试（也称为探索式测试）最早于1983年提出，并在实践中发展 [10?11]。与传统脚本测试相比，探索性测试具有以下技术特点：

（1） 测试活动的同时性。鼓励在测试执行的过程中，同时进行对被测软件的学习和测试设计。

（2） 关注测试任务。更关注于被测软件本身和需要测试的问题。

（3） 测试中的演绎推理。通过前一个测试活动的结果来指导后期测试的开展。

（4） 利用人的优势。关注于人本身的优势，如判断、分析、应变和协作的能力。

作为一种敏捷软件测试方法，探索性测试弱化了对测试的预先设计和测试流程的严格要求，而强调测试的同时性以及人的经验和创造性，关注于发现软件缺陷，持续优化测试工作[12?13]。测试人员在测试?理解?再细化测试的迭代中，通过测试活动本身不断深入学习被测软件，从而能够缩减测试准备时间，发现更多缺陷，并使得软件测试可以在被测软件说明或文档不齐全的情况下开展[14]。

1.2 探索性软件测试的主要方法

探索性测试的概念提出后，经过工业界和学术界人士的工作，已初步形成包含经验运用、执行策略、管理模型的体系。

1.2.1 探索方法

探索性测试强调对测试人员的知识和经验的运用。这些经验和知识可分为领域知识、系统知识和一般的软件工程知识[15]。领域知识指领域规则、客户流程和操作场景等，包括用户使用和具体应用领域知识。系统知识是关于待测软件的特性和技术细节的具体知识，包括系统级的交互以及个体功能细节。一般的软件工程知识即不需要对被测软件系统和应用领域的具体知识。

丰富的知识和经验是对探索性测试人员的基本要求，以此为基础，探索性测试的发挥人的创造性，并由此增强了测试过程的适用性。从工程应用的实践中，已总结出了一些有用的启发式方法。运用这些策略和启发式方法，可以帮助软件测试人员在具备了基本的知识和经验的情况下，尽快熟悉被测系统，并在测试过程中充分运用经验和创造性。

在开展具体的测试活动时，测试人员则可以借助一些启发式方法在测试活动中“探索”被测软件。这些启发式的方法是测试中为了发现可能的缺陷，测试人员常用的一些技巧 [16]。这其中典型的有Hendrickson的检查单[17]以及Whittaker的漫游方法[3]。这些方法的共同特性是提醒测试人员：

（1） 应关注软件最主要的功能，并在测试的过程中对软件的行为进行联想、质疑并发散，充分利用逆向输入、边界情况、近似值、错误输入和特殊值（如0），通过软件行为的原因、表现等举一反三；

（2） 应刻意构造一些特殊的行为，如尝试遍历所有输出、尝试最长操作路径、尝试关注关键数据的演化、打散或集中事物、长时间运行软件等；

（3） 应构造测试检查软件主要功能往往不关注的情景，例如启动和退出、全选、空值、资源过量和紧张、取消操作、重复、同时运行等。

传统方法假设软件文档中说明了软件的各种预期行为，因而可以通过分析文档来提取测试预期（Test Oracles）。然而，在软件信息不完备的情况下，测试预期则无法提前预知。HICCUPPS的启发式方法，从历史（History）信息、顾客形象（Image）在软件中的恰当映射、类似软件的对照（Comparable Products）、与软件和商业声明（Claims）、用户预期（Users Expectations）、同类产品本身（the Product itself）、明显的意图（Purpose）和法律规章（Statutes）等角度，帮助测试人员在判定测试是否通过[14]。

1.2.2 管理模型

良好的测试管理模型是保证测试质量、提高测试效率的必要保障。基于会话的测试管理（SBTM）是探索性测试领域中最常用的管理实践。SBTM将软件测试活动分解为若干会话（Session）[2]。会话特征如下：

会话围绕主旨（Charter）开展：即待测试的任务和目标；会话时间较短：时间长度在90 min左右；会话需要记录：借助会话记录单；每轮会话需要计划和总结：一轮会话执行通常是一天，其中包含若干个会话测试。

基于会话的测试过程如图1所示。当接到测试任务时，测试小组通过对测试任务进行分析讨论，确定各会话的主旨。会话主旨包含被测软件的主题、测试人员的角色、目的、条件、优先级、参考文档、数据、思路、预期等信息[18]。测试项目负责人分配各会话测试人员，随后开展首轮会话执行。一轮会话执行通常为一天。每轮会话执行结束后，需组织会话总结，主要借助以下维度进行：会话执行情况、笔记、缺陷、问题、数据、时间分解、人员安排等。通过总结确定下一轮会话、资源分配。下一轮会话执行按照相似的方式开展。在测试达到预期时间和充分度要求后，测试结束，并根据每轮会话报告单整理测试报告。

图1 基于会话的测试管理示意图

会话还可以根据需要进行扩展，例如可以包含对会话的风险评估和资源统计[4]，也可以将会话延伸为对特定问题的关注，形成测试的线索[19]。

1.3 探索性测试工具

探索性测试的有效开展同时依赖于工具的辅助。已有一些探索性测试的工具可供参考，例如Microsoft Test Manager（与Visual Studio组件），BBTestAssistant、TestExplorer，Session Tester，Rapid Reporter，Wink。这些工具通过基于录制回放、截屏和辅助文字信息的方式帮助测试人员记录探索性测试的执行过程，其中Session Tester、Rapid Reporter和Wink是免费的，Session Tester和Rapid Reporter则专门针对会话机制进行了设计和优化。

虽然这些基于录制回放原理的工具能够辅助测试人员整理测试报告，但是却缺少对测试人员运用其知识和经验的指导，对探索性测试的执行也缺少引导作用。目前没有专门的探索性测试流程管理工具，不能起到控制测试流程的作用。有必要针对具体应用研发相应的辅助工具。

2 探索性测试的应用及其效果

经过发展，探索性测试已在多个企业运用。人们对探索性测试方法的优缺点也有了更加明确的认识。

2.1 探索性测试在工业界的应用

微软是较早实践探索性测试方法的软件企业。微软在Windows 2000系统徽标认证、必应搜索引擎和地图、Visual Studio、Windows Media Player等系统、网络和桌面应用中广泛使用了探索性测试的技巧和方法，尤其是漫游探索法[3，7，20?21]。在其他公司，探索性测试也成功的运用于互联网应用行业以及信息系统的软件测试中。这些测试任务往往在软件文档不全、测试时间紧、企业对采用传统的脚本测试流程不满意的背景下开展，通过运用基于会话的方法，测试团队都能够高效的完成测试任务，甚至发现了采用传统方法在类似项目中遗漏的缺陷，在系统上线后也没有发生重大问题，软件项目组对测试团队的满意度有提升[22?24]。

虽然可能没有直接说明采用探索性测试，开源软件的测试往往具有探索性测试的特点。这些测试往往在没有详细的软件文档和测试用例设计的基础上，利用志愿测试人员的经验和兴趣开展 [25]。在敏捷软件研发团队中，探索性测试的方法也多有运用[26]。成功案例包括与XP和Scrum敏捷软件开发的结合[5，27]。

除了在工业界的运用，也有学者对敏捷软件测试的应用进行了系统的研究和讨论。Itkonen等人在芬兰多个软件公司中研究了测试人员对探索性测试的使用方法、效果和评价[28]，对探索性测试的优缺点、应用条件合场景以及推荐的方法进行了总结[29]；通过研究和实验，发现了探索性测试在缺陷检测能力上能达到甚至超过传统脚本测试的水平[6]。Naseer，史亮和高翔也总结了探索性软件测试在瑞典软件公司、国内的微软和淘宝等企业运用的经验，对探索性测试的活动进行了总结[8，10]。Bach等人还成立了公司专门从事测试方面的研究和推广。另外，也有一些研究将探索性测试思想与测试自动化方法结合[30]，或利用探索性测试的思想提高测试效率和质量的工作[5]。

从目前的应用情况来看，探索性测试技术多数是在桌面应用、B/S架构信息系统等领域的应用，在嵌入式系统软件测试中的应用较少。

2.2 探索性测试的优缺点

经过实践，总结上述对探索性测试的应用，能够发现，探索性测试尤其适用于要求在短时间内发现被测软件一些重要缺陷或事先没有能够进行详细测试设计的情况；但也具有测试过程不易控制、测试文档不全等问题。因此，在具体领域中运用探索性测试技术时，有必要根据领域特性，设计适合的测试流程，扬长避短。

一般认为探索性测试的主要优点和缺点如下：

优点：便于利用人员经验；适合于从用户角度的测试；适用于缺少软件文档、测试时间紧情况；灵活且适应性强；对测试人员和开发人员的反馈较快；能够为测试带来新内容，降低“杀虫剂”效应。

缺点：缺少足够的文档，不易度量覆盖率；测试统计数据不足，不利于决策；对测试人员经验要求较高；在测试人员经验不足、管理不严格的情况下，可能会影响测试质量；如缺少恰当工具，则不利于缺陷复现。

3 探索性测试在嵌入式系统中的应用

探索性测试技术却是能够应对嵌入式系统软件测试中软件需求变化快、测试周期短、软件文档不全等现实问题的可行方法之一。本文首先分析探索性测试在嵌入式软件测试中应用的需求和困难，然后探讨探索性测试技术与嵌入式系统软件测试体系的结合方法，对应用模型提出建议，并对应用中可能的问题和后续研究进行讨论和展望。

3.1 探索性测试一般性方法的适用性

随着IT技术的发展和各国在国防、智能电网、物联网、智能手机等行业投入的加大，嵌入式软件产品越来越多，测试任务越来越重，往往难以保证充裕的测试时间。软件需求和开发文档存在不准确、不完备的情况。而同时，嵌入式软件的测试具有较强的领域特性，领域内测试人员对被测系统的经验比较丰富。因此，需要也有条件在嵌入式系统软件中开展探索性测试，以降低对软件需求和设计规约的依赖、发挥探索性测试对软件变化的适应性和充分利用测试人员经验的优势。

然而，探索性测试技术在嵌入式领域中的应用却较少。探索性测试的通用方法没有直接用于嵌入式系统软件测试的原因主要是 [1，31?33]：

（1） 软件测试文档：探索性测试不鼓励测试花费精力在策划和准备上，而测试执行记录风格随意性较大，不利于形成统一、完备的测试文档；这与按照国标和军标中对完整的软件测试文档的要求冲突。

（2） 软件测试充分性度量：不易度量测试覆盖率，不易评价测试质量。

（3） 软件测试过程控制：缺少对配置和测试流程的系统性管理，可能造成测试过程失控。

3.2 探索性测试应用模型探讨

为了解决嵌入式系统测试中软件需求变化快、测试周期短、软件文档不完备等现实问题，有必借鉴探索性测试技术在信息系统、网络应用、操作系统等方面的成功经验，将其融入嵌入式系统软件测试体系中来[24，34]。为了与相应的软件测评体系和标准匹配，必须对探索性测试通用方法进行调整，设计探索性测试在嵌入式系统软件测试的应用模型。

一种可参考的“脚本会话模型”如图2所示，是以探索性测试一般性理论、探索性测试各特性在各型产品软件的适用性研究为基础，将探索性测试与传统脚本测试相结合的软件测试模型。为充分利用两者的优势，脚本会话模型的整体仍以传统脚本方法为基础，从而利用脚本测试管理中测试文档完备和过程管理控制完善等优点，而在测试执行过程中充分发挥探索性测试的灵活、高效优点，引入会话、漫游测试法等探索性测试等方法，同时借助嵌入式系统软件测试典型数据复用库来实现对测试人员经验的固化和复用。

图2 嵌入式系统软件脚本会话测试模型

如图3所示，脚本会话模型整体流程遵循经典的脚本测试流程，但发挥了探索性测试对经验的利用和灵活性的特点。

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

包含以下步骤：

（1） 测试策划和设计阶段；借助领域软件测试典型数据复用库（测试人员经验的固化体现）形成测试项、构造测试用例，降低对软件需求和设计文档的依赖，初步完成测试需求的提取和测试用例的设计。

（2） 测试执行阶段：测试执行以基于会话的方式开展，并对一般会话进行扩展。根据测试设计和计划，确定每个会话的主旨、用例和测试方法。在每一次会话中，测试人员可以结对开展测试执行，根据预先指定的漫游策略和启发式方法，针对一个测试项进行探索，并补充测试用例。测试人员在会话结束后整理会话记录单。根据本轮会话执行情况，记录缺陷、改善测试设计，并准备下一轮会话。如此迭代直到测试结束条件满足，测试执行结束[35]。

（3） 测试总结阶段：借助测试执行中各个会话报告单，总结和报告缺陷。

3.3 讨论和展望

探索性测试在互联网和桌面应用已经成功实践[34]，而在嵌入式领域应用仍然较少。在嵌入式系统软件测试中运用诸如脚本会话模型的探索性测试技术时，应注意以下三点问题：

（1） 测试过程管理和文档。必须重视探索性测试的过程管理以保证测试过程受控。同时在适当的阶段应编写相应文档作为测试阶段性成果，并在测试执行完成后更新相应文档。

（2） 结合具体领域。具体领域的软件测试典型数据复用库可以看作是对该领域软件测试人员测试经验的固化，是软件测试团队的组织资产，有助于团队新成员快速熟悉被测系统，提高探索性测试的效率。

（3） 针对测试团队和项目制定具体策略。制定探索性测试中的典型方法的应用策略，并注意收集反馈，在实践中持续改进。

探索性测试作为一种在互联网、操作系统等领域成功运用多年的测试技术和理念，可以与其他软件测试技术结合，共同推进嵌入式软件测试质量的提升。可能的结合方向包括（但不限于）：

（1） 基于模型的测试和验证。借助软件模型可发现隐藏在软件界面和正常使用流程下的交互，其中可能隐藏了大量的缺陷；借助模型检验工具提供的反例[36]，测试人员还可以对软件进行更加深入的探索；

（2） 测试自动化。嵌入式系统软件需要处理传感器送来的大量数据，采用自动化方法能够有效减少测试人员的工作量；结合探索性测试的技术，也能够为测试用例约简和测试预期问题提供解决途径[34，37?39]；

基于剖面的测试：构造嵌入式系统的操作剖面和用户剖面，辅助测试人员能有选择性地对系统进行探索[40??41]。

4 结 语

探索性测试技术经过研究和发展，已形成了一套可行的体系。探索性测试在嵌入式系统软件测试中的应用还较少。经过对探索性测试体系的全面研究，能够更好的理解这种方法在嵌入式系统软件测试中的适用性，并为融合探索性测试与传统嵌入式软件测试方法，形成适用于嵌入式系统软件测试的探索性测试应用模型提供思路和方向。

参考文献

[1] 康一梅，张永革，李志军，等.嵌入式软件测试[M].北京：机械工业出版社，2008.

[2] BACH J. Session?based test management [J]. Software Testing and Quality Engineering， 2000， 2（6）： 1?4.

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

[4] LYNDSAY J， VAN EEDEN N. Adventures in session?based testing [EB/OL]. [2002?08?02]. http：//www.stickyminds.com/articl.

[5] TUOMIKOSKI J， TERVONEN I. Absorbing software testing into the scrum method [J]. Lecture Notes in Business Information Processing， 2009， 32： 199?215.

[6] 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 （ESEM）. [S.l.]： [s.n.]， 2007： 61?70.

[7] BACH J. General functionality and stability test procedure for certified for Microsoft Windows logo [R/OL]. [1999?08?22]. http：//www.satisfice.com/tools/procedure.pdf.

[8] NASEER A， ZULFIQAR M. Investigating exploratory testing in industrial practice [D]. Ronneby： Blekinge Institute of Technology， 2010.

[9] BOURQUE P， FAIRLEY R E. Guide to the software engineering body of knowledge， version 3.0 [R/OL]. [2013?03?13].. http：//www. doc88.com/p?1714.

[10] KANER C， FALK J， NGUYEN H Q. Testing computer software， second edition [M]. New York： John Wiley & Sons， Inc.， 1999.

[11] KANER C， BACH J， PETTICHORD B. Lessons learned in software testing[M]. New York： John Wiley & Sons， Inc.， 2002.

[12] FOWLER M， HIGHSMITH J. The agile manifesto [J]. Software Development， 2001， 9（8）： 28?32.

[13] COCKBURN A. Agile software development [M]. [S.l.]： Addison?Wesley， 2002.

[14] BOLTON M. Testing without a map [J/OL]. [2011?07?18]. http：//www. blog.itpub.net/1137978.

[15] ITKONEN J， MANTYLA M V， LASSENIUS C. The role of the tester's knowledge in exploratory software testing [J]. IEEE Transactions on Software Engineering， 2013， 39（5）： 707?724.

[16] KANER C. A Tutorial in exploratory testing [R]. Chicago： QAI QUEST Conference， 2008.

[17] HENDRICKSON E. Explore It！： Reduce risk and increase confidence with exploratory testing [M]. [S.l.]： The Pragmatic Programmers， 2013.

[18] CLAESSON A. How to perform exploratory testing by using test charters [R]. Swedish： Swedish Association for Software Testing （SAST）， 2007.

[19] BACH J. Introducing thread?based test management [R/OL]. [2010?11?26]. http：//www.satisfice.com/blog/archives/503.

[20] ROBINSON H. Explorer test automation [C]// Proceedings of the Conference for the Advancement of Science Teaching （CAST）. [S.l.]： [s.n.]， 2010： 11?21.

[21] ROBINSON H. Using simple automation to test complex software [C]// Proceedings of Annual Pacific NW Software Quality Conference. [S.l.]： PNSQC， 2010： 123?132.

[22] V?GA J， AMLAND S. Managing high?speed web testing [C]// Software Quality and Software Testing in Internet Times. [S.l.]： Springer?Verlag， 2002： 23?30.

[23] WOOD B， JAMES D. Applying session?based testing to medical software [J]. Medical Device & Diagnostic Industry， 2003， 25（5）： 90?96.

[24] 柳溪，马康，刘智.融合探索性与脚本方法的第三方软件测试模型及其应用[J].信息化研究，2013，39（6）：43?48.

[25] ABERDOUR M. Achieving quality in open source software [J]. IEEE Software， 2007， 24（1）： 58?64.

[26] KASURINEN J， TAIPALE O， SMOLANDER K. Test case selection and prioritization： risk?based or design?based？ [C]// Proceedings of the International Symposium on Empirical Software Engineering and Measurement. [S.l.]： [s.n.]， 2010： 234?242.

[27] MARTIN D， ROOKSBY J， ROUNCEFIELD M， et al. Good' organisational reasons for 'bad' software testing： an ethnographic study of testing in a small software company [C]// Proceedings of International Conference on Software Engineering. [S.l.]： ICSE）， 2007： 602?611.

[28] ITKONEN J， RAUTIAINEN K. Exploratory testing： a multiple case study [C]// Proceedings of International Symposium on Empirical Software Engineering. [S.l.]： [s.n.]， 2005： 1?8.

[29] ITKONEN J， MANTYLA M V， LASSENIUS C. How do testers do it？ An exploratory study on manual testing practices [C]// Proceedings of the International Symposium on Empirical Software Engineering and Measurement. [S.l.]： ESEM， 2009： 494?497.

[30] HELLMANN T D， MAURER F. Rule?based exploratory testing of graphical user interfaces [C]// Proceedings of Agile Conference. [S.l.]： AGILE， 2011： 107?116.

[31] 中华人民共和国国家质量监督检验检疫总局.GB/T 25000.51?2010软件工程 软件产品质量要求与评价（SQuaRE）SQuaRE指南[S].北京：中国标准出版社，2010.

[32] 中华人民共和国国家质量监督检验检疫总局.GB/T 8567?2006计算机软件文档编制规范[S].北京：中国标准出版社， 2006.

[33] 中华人民共和国国家质量监督检验检疫总局.GB/T 9386?2008 计算机软件测试文档编制规范[S].北京：中国标准出版社，2006.

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

[35] KANER C， BACH J. Exploratory testing in pairs [R/OL]. [2001?08?22]. http：//www.testingeducation.org/a/pairs.pdf.

[36] CLARKE E M， GRUMBERG O， PELED D A. Model checking [M]. [S.l.]： The MIT Press， 2000.

[37] DUSTIN E， RASHKA J， PAUL J. Automated software testing [M]. [S.l.]： Addison?Wesley Professional， 1999.

[38] FEWSTER M， GRAHAM D. Software test automation [M]. [S.l.]： Addison?Wesley Professional， 1999.

[39] KANER C. Architectures of test automation [R/OL]. [2000?09?28]. http：//www.kaner.com/pdfs/testarch.pdf.

[40] BUWALDA H. Soap opera testing [J/OL]. [2011?04?11]. http：//www.wenku.baidu.com/link？u...

[41] 陆民燕.软件可靠性工程[M].北京：国防工业出版社，2011.

[42] MUSA J D. Software reliability engineering [M]. [S.l.]： Author House， 2004.

[28] ITKONEN J， RAUTIAINEN K. Exploratory testing： a multiple case study [C]// Proceedings of International Symposium on Empirical Software Engineering. [S.l.]： [s.n.]， 2005： 1?8.

[29] ITKONEN J， MANTYLA M V， LASSENIUS C. How do testers do it？ An exploratory study on manual testing practices [C]// Proceedings of the International Symposium on Empirical Software Engineering and Measurement. [S.l.]： ESEM， 2009： 494?497.

[30] HELLMANN T D， MAURER F. Rule?based exploratory testing of graphical user interfaces [C]// Proceedings of Agile Conference. [S.l.]： AGILE， 2011： 107?116.

[31] 中华人民共和国国家质量监督检验检疫总局.GB/T 25000.51?2010软件工程 软件产品质量要求与评价（SQuaRE）SQuaRE指南[S].北京：中国标准出版社，2010.

[32] 中华人民共和国国家质量监督检验检疫总局.GB/T 8567?2006计算机软件文档编制规范[S].北京：中国标准出版社， 2006.

[33] 中华人民共和国国家质量监督检验检疫总局.GB/T 9386?2008 计算机软件测试文档编制规范[S].北京：中国标准出版社，2006.

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

[35] KANER C， BACH J. Exploratory testing in pairs [R/OL]. [2001?08?22]. http：//www.testingeducation.org/a/pairs.pdf.

[36] CLARKE E M， GRUMBERG O， PELED D A. Model checking [M]. [S.l.]： The MIT Press， 2000.

[37] DUSTIN E， RASHKA J， PAUL J. Automated software testing [M]. [S.l.]： Addison?Wesley Professional， 1999.

[38] FEWSTER M， GRAHAM D. Software test automation [M]. [S.l.]： Addison?Wesley Professional， 1999.

[39] KANER C. Architectures of test automation [R/OL]. [2000?09?28]. http：//www.kaner.com/pdfs/testarch.pdf.

[40] BUWALDA H. Soap opera testing [J/OL]. [2011?04?11]. http：//www.wenku.baidu.com/link？u...

[41] 陆民燕.软件可靠性工程[M].北京：国防工业出版社，2011.

[42] MUSA J D. Software reliability engineering [M]. [S.l.]： Author House， 2004.

[28] ITKONEN J， RAUTIAINEN K. Exploratory testing： a multiple case study [C]// Proceedings of International Symposium on Empirical Software Engineering. [S.l.]： [s.n.]， 2005： 1?8.

[29] ITKONEN J， MANTYLA M V， LASSENIUS C. How do testers do it？ An exploratory study on manual testing practices [C]// Proceedings of the International Symposium on Empirical Software Engineering and Measurement. [S.l.]： ESEM， 2009： 494?497.

[30] HELLMANN T D， MAURER F. Rule?based exploratory testing of graphical user interfaces [C]// Proceedings of Agile Conference. [S.l.]： AGILE， 2011： 107?116.

[31] 中华人民共和国国家质量监督检验检疫总局.GB/T 25000.51?2010软件工程 软件产品质量要求与评价（SQuaRE）SQuaRE指南[S].北京：中国标准出版社，2010.

[32] 中华人民共和国国家质量监督检验检疫总局.GB/T 8567?2006计算机软件文档编制规范[S].北京：中国标准出版社， 2006.

[33] 中华人民共和国国家质量监督检验检疫总局.GB/T 9386?2008 计算机软件测试文档编制规范[S].北京：中国标准出版社，2006.

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

[35] KANER C， BACH J. Exploratory testing in pairs [R/OL]. [2001?08?22]. http：//www.testingeducation.org/a/pairs.pdf.

[36] CLARKE E M， GRUMBERG O， PELED D A. Model checking [M]. [S.l.]： The MIT Press， 2000.

[37] DUSTIN E， RASHKA J， PAUL J. Automated software testing [M]. [S.l.]： Addison?Wesley Professional， 1999.

[38] FEWSTER M， GRAHAM D. Software test automation [M]. [S.l.]： Addison?Wesley Professional， 1999.

[39] KANER C. Architectures of test automation [R/OL]. [2000?09?28]. http：//www.kaner.com/pdfs/testarch.pdf.

[40] BUWALDA H. Soap opera testing [J/OL]. [2011?04?11]. http：//www.wenku.baidu.com/link？u...

[41] 陆民燕.软件可靠性工程[M].北京：国防工业出版社，2011.

[42] MUSA J D. Software reliability engineering [M]. [S.l.]： Author House， 2004.