軟件在嵌入式系統(tǒng)中的作用越來越大。軟件的質(zhì)量不僅直接影響任務(wù)的成敗，也關(guān)系著設(shè)備甚至人員的安全。隨著用戶對嵌入式系統(tǒng)軟件質(zhì)量要求的提升，軟件測試已成為嵌入式系統(tǒng)交付前必不可少的環(huán)節(jié)。

　　《軟件世界》軟件技術(shù)期刊，創(chuàng)刊于1984年，由中國電子信息產(chǎn)業(yè)發(fā)展研究院、北京中電報科技發(fā)展有限公司主辦。計算機(jī)科學(xué)技術(shù)刊物。旨在推動計算機(jī)在我國的應(yīng)用，推動我國軟件產(chǎn)業(yè)的建立和發(fā)展，促進(jìn)軟件應(yīng)用社會化、軟件開發(fā)工程化、軟件成果商品化和軟件經(jīng)營企業(yè)化等方面的工作更好開展。

　　經(jīng)典的測試方法要求依據(jù)軟件需求和設(shè)計文檔，遵循既定的測試流程，嚴(yán)格按照預(yù)先設(shè)計的“腳本”開展。因此經(jīng)典測試方法也稱為腳本測試(Script Testing)。隨著嵌入式軟件迭代的加速，給軟件測試留出時間逐漸減少。嵌入式系統(tǒng)軟件測試呈現(xiàn)出一些新特點，包括軟件需求變化快、軟件文檔缺乏、軟件測試周期短、測試時間不足等。

　　探索性測試(Exploratory Testing)具有在時間短和文檔不完善的情況下，充分發(fā)揮測試人員的經(jīng)驗和能力，快速、高質(zhì)量完成軟件測試等優(yōu)點。已形成了一套管理方法和應(yīng)用模型[2?3]，并在微軟等多個企業(yè)開展了成功的實踐[3?5]。探索性測試方法關(guān)注于實用，對它的研究也多數(shù)集中在實際應(yīng)用方法而不是理論研究上[3，6?8]。

　　探索性測試是解決嵌入式系統(tǒng)軟件測試需求變化快、軟件文檔缺乏、測試周期短等現(xiàn)實問題的可行手段之一。為了恰當(dāng)運(yùn)用，需要總結(jié)探索性測試的一般性應(yīng)用方法體系，并探討其與嵌入式系統(tǒng)軟件測試體系的聯(lián)系和沖突。在此基礎(chǔ)上提出適用于嵌入式系統(tǒng)軟件測試的探索性測試應(yīng)用模型。

　　1 探索性軟件測試的基本原理

　　探索性測試的概念形成較早，經(jīng)過隨后的發(fā)展已形成了一定的應(yīng)用體系。

　　1.1 探索性軟件測試的概念

　　傳統(tǒng)的軟件測試分為測試需求分析、測試策劃、測試用例設(shè)計、測試執(zhí)行和測試總結(jié)等主要階段，依次開展[1]。傳統(tǒng)軟件測試流程依賴于完整、詳實的軟件需求和設(shè)計文檔作為輸入。而在現(xiàn)實的測試任務(wù)中，軟件需求和設(shè)計文檔往往有誤或不完備，這導(dǎo)致腳本測試活動無法正常有效開展。

　　“探索性測試是同時進(jìn)行學(xué)習(xí)、測試設(shè)計和測試執(zhí)行的一種測試方法;也就是說，測試沒有事先通過確定的測試計劃定義，而是動態(tài)地被設(shè)計、執(zhí)行和修改”[9]。探索性測試(也稱為探索式測試)最早于1983年提出，并在實踐中發(fā)展 [1011]。與傳統(tǒng)腳本測試相比，探索性測試具有以下技術(shù)特點：

　　(1) 測試活動的同時性。鼓勵在測試執(zhí)行的過程中，同時進(jìn)行對被測軟件的學(xué)習(xí)和測試設(shè)計。

　　(2) 關(guān)注測試任務(wù)。更關(guān)注于被測軟件本身和需要測試的問題。

　　(3) 測試中的演繹推理。通過前一個測試活動的結(jié)果來指向后期測試的開展。

　　(4) 利用人的優(yōu)勢。關(guān)注于人本身的優(yōu)勢，如判斷、分析、應(yīng)變和協(xié)作的能力。

　　作為一種敏捷軟件測試方法，探索性測試弱化了對測試的預(yù)先設(shè)計和測試流程的嚴(yán)格要求，而強(qiáng)調(diào)測試的同時性以及人的經(jīng)驗和創(chuàng)造性，關(guān)注于發(fā)現(xiàn)軟件缺陷，持續(xù)優(yōu)化測試工作[12?13]。測試人員在測試?理解?再細(xì)化測試的迭代中，通過測試活動本身不斷深入學(xué)習(xí)被測軟件，從而能夠縮減測試準(zhǔn)備時間，發(fā)現(xiàn)更多缺陷，并使得軟件測試可以在被測軟件說明或文檔不齊全的情況下開展[14]。

　　1.2 探索性軟件測試的主要方法

　　探索性測試的概念提出后，經(jīng)過工業(yè)界和學(xué)術(shù)界人士的工作，已初步形成包含經(jīng)驗運(yùn)用、執(zhí)行策略、管理模型的體系。

　　1.2.1 探索方法

　　探索性測試強(qiáng)調(diào)對測試人員的知識和經(jīng)驗的運(yùn)用。這些經(jīng)驗和知識可分為領(lǐng)域知識、系統(tǒng)知識和一般的軟件工程知識[15]。領(lǐng)域知識指領(lǐng)域規(guī)則、客戶流程和操作場景等，包括用戶使用和具體應(yīng)用領(lǐng)域知識。系統(tǒng)知識是關(guān)于待測軟件的特性和技術(shù)細(xì)節(jié)的具體知識，包括系統(tǒng)級的交互以及個體功能細(xì)節(jié)。一般的軟件工程知識即不需要對被測軟件系統(tǒng)和應(yīng)用領(lǐng)域的具體知識。

　　豐富的知識和經(jīng)驗是對探索性測試人員的基本要求，以此為基礎(chǔ)，探索性測試的發(fā)揮人的創(chuàng)造性，并由此增強(qiáng)了測試過程的適用性。從工程應(yīng)用的實踐中，已總結(jié)出了一些有用的啟發(fā)式方法。運(yùn)用這些策略和啟發(fā)式方法，可以幫助軟件測試人員在具備了基本的知識和經(jīng)驗的情況下，盡快熟悉被測系統(tǒng)，并在測試過程中充分運(yùn)用經(jīng)驗和創(chuàng)造性。

　　在開展具體的測試活動時，測試人員則可以借助一些啟發(fā)式方法在測試活動中“探索”被測軟件。這些啟發(fā)式的方法是測試中為了發(fā)現(xiàn)可能的缺陷，測試人員常用的一些技巧 [16]。這其中典型的有Hendrickson的檢查單[17]以及Whittaker的漫游方法[3]。這些方法的共同特性是提醒測試人員：

　　(1) 應(yīng)關(guān)注軟件最主要的功能，并在測試的過程中對軟件的行為進(jìn)行聯(lián)想、質(zhì)疑并發(fā)散，充分利用逆向輸入、邊界情況、近似值、錯誤輸入和特殊值(如0)，通過軟件行為的原因、表現(xiàn)等舉一反三;

　　(2) 應(yīng)刻意構(gòu)造一些特殊的行為，如嘗試遍歷所有輸出、嘗試最長操作路徑、嘗試關(guān)注關(guān)鍵數(shù)據(jù)的演化、打散或集中事物、長時間運(yùn)行軟件等;

　　(3) 應(yīng)構(gòu)造測試檢查軟件主要功能往往不關(guān)注的情景，例如啟動和退出、全選、空值、資源過量和緊張、取消操作、重復(fù)、同時運(yùn)行等。

　　傳統(tǒng)方法假設(shè)軟件文檔中說明了軟件的各種預(yù)期行為，因而可以通過分析文檔來提取測試預(yù)期(Test Oracles)。然而，在軟件信息不完備的情況下，測試預(yù)期則無法提前預(yù)知。HICCUPPS的啟發(fā)式方法，從歷史(History)信息、顧客形象(Image)在軟件中的恰當(dāng)映射、類似軟件的對照(Comparable Products)、與軟件和商業(yè)聲明(Claims)、用戶預(yù)期(User’s Expectations)、同類產(chǎn)品本身(the Product itself)、明顯的意圖(Purpose)和法律規(guī)章(Statutes)等角度，幫助測試人員在判定測試是否通過[14]。

　　1.2.2 管理模型

　　良好的測試管理模型是保證測試質(zhì)量、提高測試效率的必要保障。基于會話的測試管理(SBTM)是探索性測試領(lǐng)域中最常用的管理實踐。SBTM將軟件測試活動分解為若干會話(Session)[2]。會話特征如下：

　　會話圍繞主旨(Charter)開展：即待測試的任務(wù)和目標(biāo);會話時間較短：時間長度在90 min左右;會話需要記錄：借助會話記錄單;每輪會話需要計劃和總結(jié)：一輪會話執(zhí)行通常是一天，其中包含若干個會話測試。

　　基于會話的測試過程如圖1所示。當(dāng)接到測試任務(wù)時，測試小組通過對測試任務(wù)進(jìn)行分析討論，確定各會話的主旨。會話主旨包含被測軟件的主題、測試人員的角色、目的、條件、優(yōu)先級、參考文檔、數(shù)據(jù)、思路、預(yù)期等信息[18]。測試項目負(fù)責(zé)人分配各會話測試人員，隨后開展首輪會話執(zhí)行。一輪會話執(zhí)行通常為一天。每輪會話執(zhí)行結(jié)束后，需組織會話總結(jié)，主要借助以下維度進(jìn)行：會話執(zhí)行情況、筆記、缺陷、問題、數(shù)據(jù)、時間分解、人員安排等。通過總結(jié)確定下一輪會話、資源分配。下一輪會話執(zhí)行按照相似的方式開展。在測試達(dá)到預(yù)期時間和充分度要求后，測試結(jié)束，并根據(jù)每輪會話報告單整理測試報告。

　　圖1 基于會話的測試管理示意圖

　　會話還可以根據(jù)需要進(jìn)行擴(kuò)展，例如可以包含對會話的風(fēng)險評估和資源統(tǒng)計[4]，也可以將會話延伸為對特定問題的關(guān)注，形成測試的線索[19]。

　　1.3 探索性測試工具

　　探索性測試的有效開展同時依賴于工具的輔助。已有一些探索性測試的工具可供參考，例如Microsoft Test Manager(與Visual Studio組件)，BBTestAssistant、TestExplorer，Session Tester，Rapid Reporter，Wink。這些工具通過基于錄制回放、截屏和輔助文字信息的方式幫助測試人員記錄探索性測試的執(zhí)行過程，其中Session Tester、Rapid Reporter和Wink是免費(fèi)的，Session Tester和Rapid Reporter則專門針對會話機(jī)制進(jìn)行了設(shè)計和優(yōu)化。

　　雖然這些基于錄制回放原理的工具能夠輔助測試人員整理測試報告，但是卻缺少對測試人員運(yùn)用其知識和經(jīng)驗的指向，對探索性測試的執(zhí)行也缺少引導(dǎo)作用。目前沒有專門的探索性測試流程管理工具，不能起到控制測試流程的作用。有必要針對具體應(yīng)用研發(fā)相應(yīng)的輔助工具。

　　2 探索性測試的應(yīng)用及其效果

　　經(jīng)過發(fā)展，探索性測試已在多個企業(yè)運(yùn)用。人們對探索性測試方法的優(yōu)缺點也有了更加明確的認(rèn)識。

　　2.1 探索性測試在工業(yè)界的應(yīng)用

　　微軟是較早實踐探索性測試方法的軟件企業(yè)。微軟在Windows 2000系統(tǒng)徽標(biāo)認(rèn)證、必應(yīng)搜索引擎和地圖、Visual Studio、Windows Media Player等系統(tǒng)、網(wǎng)絡(luò)和桌面應(yīng)用中廣泛使用了探索性測試的技巧和方法，尤其是漫游探索法[3，7，20?21]。在其他公司，探索性測試也成功的運(yùn)用于互聯(lián)網(wǎng)應(yīng)用行業(yè)以及信息系統(tǒng)的軟件測試中。這些測試任務(wù)往往在軟件文檔不全、測試時間緊、企業(yè)對采用傳統(tǒng)的腳本測試流程不滿意的背景下開展，通過運(yùn)用基于會話的方法，測試團(tuán)隊都能夠高效的完成測試任務(wù)，甚至發(fā)現(xiàn)了采用傳統(tǒng)方法在類似項目中遺漏的缺陷，在系統(tǒng)上線后也沒有發(fā)生重大問題，軟件項目組對測試團(tuán)隊的滿意度有提升[22?24]。

　　雖然可能沒有直接說明采用探索性測試，開源軟件的測試往往具有探索性測試的特點。這些測試往往在沒有詳細(xì)的軟件文檔和測試用例設(shè)計的基礎(chǔ)上，利用志愿測試人員的經(jīng)驗和興趣開展 [25]。在敏捷軟件研發(fā)團(tuán)隊中，探索性測試的方法也多有運(yùn)用[26]。成功案例包括與XP和Scrum敏捷軟件開發(fā)的結(jié)合[5，27]。

　　除了在工業(yè)界的運(yùn)用，也有學(xué)者對敏捷軟件測試的應(yīng)用進(jìn)行了系統(tǒng)的研究和討論。Itkonen等人在芬蘭多個軟件公司中研究了測試人員對探索性測試的使用方法、效果和評價[28]，對探索性測試的優(yōu)缺點、應(yīng)用條件合場景以及推薦的方法進(jìn)行了總結(jié)[29];通過研究和實驗，發(fā)現(xiàn)了探索性測試在缺陷檢測能力上能達(dá)到甚至超過傳統(tǒng)腳本測試的水平[6]。Naseer，史亮和高翔也總結(jié)了探索性軟件測試在瑞典軟件公司、國內(nèi)的微軟和淘寶等企業(yè)運(yùn)用的經(jīng)驗，對探索性測試的活動進(jìn)行了總結(jié)[8，10]。Bach等人還成立了公司專門從事測試方面的研究和推廣。另外，也有一些研究將探索性測試思想與測試自動化方法結(jié)合[30]，或利用探索性測試的思想提高測試效率和質(zhì)量的工作[5]。

　　從目前的應(yīng)用情況來看，探索性測試技術(shù)多數(shù)是在桌面應(yīng)用、B/S架構(gòu)信息系統(tǒng)等領(lǐng)域的應(yīng)用，在嵌入式系統(tǒng)軟件測試中的應(yīng)用較少。

　　2.2 探索性測試的優(yōu)缺點

　　經(jīng)過實踐，總結(jié)上述對探索性測試的應(yīng)用，能夠發(fā)現(xiàn)，探索性測試尤其適用于要求在短時間內(nèi)發(fā)現(xiàn)被測軟件一些重要缺陷或事先沒有能夠進(jìn)行詳細(xì)測試設(shè)計的情況;但也具有測試過程不易控制、測試文檔不全等問題。因此，在具體領(lǐng)域中運(yùn)用探索性測試技術(shù)時，有必要根據(jù)領(lǐng)域特性，設(shè)計適合的測試流程，揚(yáng)長避短。

　　一般認(rèn)為探索性測試的主要優(yōu)點和缺點如下：

　　優(yōu)點：便于利用人員經(jīng)驗;適合于從用戶角度的測試;適用于缺少軟件文檔、測試時間緊情況;靈活且適應(yīng)性強(qiáng);對測試人員和開發(fā)人員的反饋較快;能夠為測試帶來新內(nèi)容，降低“殺蟲劑”效應(yīng)。

　　缺點：缺少足夠的文檔，不易度量覆蓋率;測試統(tǒng)計數(shù)據(jù)不足，不利于決策;對測試人員經(jīng)驗要求較高;在測試人員經(jīng)驗不足、管理不嚴(yán)格的情況下，可能會影響測試質(zhì)量;如缺少恰當(dāng)工具，則不利于缺陷復(fù)現(xiàn)。

　　3 探索性測試在嵌入式系統(tǒng)中的應(yīng)用

　　探索性測試技術(shù)卻是能夠應(yīng)對嵌入式系統(tǒng)軟件測試中軟件需求變化快、測試周期短、軟件文檔不全等現(xiàn)實問題的可行方法之一。本文首先分析探索性測試在嵌入式軟件測試中應(yīng)用的需求和困難，然后探討探索性測試技術(shù)與嵌入式系統(tǒng)軟件測試體系的結(jié)合方法，對應(yīng)用模型提出建議，并對應(yīng)用中可能的問題和后續(xù)研究進(jìn)行討論和展望。

　　3.1 探索性測試一般性方法的適用性

　　隨著IT技術(shù)的發(fā)展和各國在國防、智能電網(wǎng)、物聯(lián)網(wǎng)、智能手機(jī)等行業(yè)投入的加大，嵌入式軟件產(chǎn)品越來越多，測試任務(wù)越來越重，往往難以保證充裕的測試時間。軟件需求和開發(fā)文檔存在不準(zhǔn)確、不完備的情況。而同時，嵌入式軟件的測試具有較強(qiáng)的領(lǐng)域特性，領(lǐng)域內(nèi)測試人員對被測系統(tǒng)的經(jīng)驗比較豐富。因此，需要也有條件在嵌入式系統(tǒng)軟件中開展探索性測試，以降低對軟件需求和設(shè)計規(guī)約的依賴、發(fā)揮探索性測試對軟件變化的適應(yīng)性和充分利用測試人員經(jīng)驗的優(yōu)勢。

　　然而，探索性測試技術(shù)在嵌入式領(lǐng)域中的應(yīng)用卻較少。探索性測試的通用方法沒有直接用于嵌入式系統(tǒng)軟件測試的原因主要是 [1，31?33]：

　　(1) 軟件測試文檔：探索性測試不鼓勵測試花費(fèi)精力在策劃和準(zhǔn)備上，而測試執(zhí)行記錄風(fēng)格隨意性較大，不利于形成統(tǒng)一、完備的測試文檔;這與按照國標(biāo)和軍標(biāo)中對完整的軟件測試文檔的要求沖突。

　　(2) 軟件測試充分性度量：不易度量測試覆蓋率，不易評價測試質(zhì)量。

　　(3) 軟件測試過程控制：缺少對配置和測試流程的系統(tǒng)性管理，可能造成測試過程失控。

　　3.2 探索性測試應(yīng)用模型探討

　　為了解決嵌入式系統(tǒng)測試中軟件需求變化快、測試周期短、軟件文檔不完備等現(xiàn)實問題，有必借鑒探索性測試技術(shù)在信息系統(tǒng)、網(wǎng)絡(luò)應(yīng)用、操作系統(tǒng)等方面的成功經(jīng)驗，將其融入嵌入式系統(tǒng)軟件測試體系中來[24，34]。為了與相應(yīng)的軟件測評體系和標(biāo)準(zhǔn)匹配，必須對探索性測試通用方法進(jìn)行調(diào)整，設(shè)計探索性測試在嵌入式系統(tǒng)軟件測試的應(yīng)用模型。

　　一種可參考的“腳本會話模型”如圖2所示，是以探索性測試一般性理論、探索性測試各特性在各型產(chǎn)品軟件的適用性研究為基礎(chǔ)，將探索性測試與傳統(tǒng)腳本測試相結(jié)合的軟件測試模型。為充分利用兩者的優(yōu)勢，腳本會話模型的整體仍以傳統(tǒng)腳本方法為基礎(chǔ)，從而利用腳本測試管理中測試文檔完備和過程管理控制完善等優(yōu)點，而在測試執(zhí)行過程中充分發(fā)揮探索性測試的靈活、高效優(yōu)點，引入會話、漫游測試法等探索性測試等方法，同時借助嵌入式系統(tǒng)軟件測試典型數(shù)據(jù)復(fù)用庫來實現(xiàn)對測試人員經(jīng)驗的固化和復(fù)用。

　　圖2 嵌入式系統(tǒng)軟件腳本會話測試模型

　　如圖3所示，腳本會話模型整體流程遵循經(jīng)典的腳本測試流程，但發(fā)揮了探索性測試對經(jīng)驗的利用和靈活性的特點。

　　圖3 腳本會話測試模型流程框架

　　包含以下步驟：

　　(1) 測試策劃和設(shè)計階段;借助領(lǐng)域軟件測試典型數(shù)據(jù)復(fù)用庫(測試人員經(jīng)驗的固化體現(xiàn))形成測試項、構(gòu)造測試用例，降低對軟件需求和設(shè)計文檔的依賴，初步完成測試需求的提取和測試用例的設(shè)計。

　　(2) 測試執(zhí)行階段：測試執(zhí)行以基于會話的方式開展，并對一般會話進(jìn)行擴(kuò)展。根據(jù)測試設(shè)計和計劃，確定每個會話的主旨、用例和測試方法。在每一次會話中，測試人員可以結(jié)對開展測試執(zhí)行，根據(jù)預(yù)先指定的漫游策略和啟發(fā)式方法，針對一個測試項進(jìn)行探索，并補(bǔ)充測試用例。測試人員在會話結(jié)束后整理會話記錄單。根據(jù)本輪會話執(zhí)行情況，記錄缺陷、改善測試設(shè)計，并準(zhǔn)備下一輪會話。如此迭代直到測試結(jié)束條件滿足，測試執(zhí)行結(jié)束[35]。

　　(3) 測試總結(jié)階段：借助測試執(zhí)行中各個會話報告單，總結(jié)和報告缺陷。

　　3.3 討論和展望

　　探索性測試在互聯(lián)網(wǎng)和桌面應(yīng)用已經(jīng)成功實踐[34]，而在嵌入式領(lǐng)域應(yīng)用仍然較少。在嵌入式系統(tǒng)軟件測試中運(yùn)用諸如腳本會話模型的探索性測試技術(shù)時，應(yīng)注意以下三點問題：

　　(1) 測試過程管理和文檔。必須重視探索性測試的過程管理以保證測試過程受控。同時在適當(dāng)?shù)碾A段應(yīng)編寫相應(yīng)文檔作為測試階段性成果，并在測試執(zhí)行完成后更新相應(yīng)文檔。

　　(2) 結(jié)合具體領(lǐng)域。具體領(lǐng)域的軟件測試典型數(shù)據(jù)復(fù)用庫可以看作是對該領(lǐng)域軟件測試人員測試經(jīng)驗的固化，是軟件測試團(tuán)隊的組織資產(chǎn)，有助于團(tuán)隊新成員快速熟悉被測系統(tǒng)，提高探索性測試的效率。

　　(3) 針對測試團(tuán)隊和項目制定具體策略。制定探索性測試中的典型方法的應(yīng)用策略，并注意收集反饋，在實踐中持續(xù)改進(jìn)。

　　探索性測試作為一種在互聯(lián)網(wǎng)、操作系統(tǒng)等領(lǐng)域成功運(yùn)用多年的測試技術(shù)和理念，可以與其他軟件測試技術(shù)結(jié)合，共同推進(jìn)嵌入式軟件測試質(zhì)量的提升。可能的結(jié)合方向包括(但不限于)：

　　(1) 基于模型的測試和驗證。借助軟件模型可發(fā)現(xiàn)隱藏在軟件界面和正常使用流程下的交互，其中可能隱藏了大量的缺陷;借助模型檢驗工具提供的反例[36]，測試人員還可以對軟件進(jìn)行更加深入的探索;

　　(2) 測試自動化。嵌入式系統(tǒng)軟件需要處理傳感器送來的大量數(shù)據(jù)，采用自動化方法能夠有效減少測試人員的工作量;結(jié)合探索性測試的技術(shù)，也能夠為測試用例約簡和測試預(yù)期問題提供解決途徑[34，37?39];

　　基于剖面的測試：構(gòu)造嵌入式系統(tǒng)的操作剖面和用戶剖面，輔助測試人員能有選擇性地對系統(tǒng)進(jìn)行探索[40??41]。

　　4 結(jié) 語

　　探索性測試技術(shù)經(jīng)過研究和發(fā)展，已形成了一套可行的體系。探索性測試在嵌入式系統(tǒng)軟件測試中的應(yīng)用還較少。經(jīng)過對探索性測試體系的全面研究，能夠更好的理解這種方法在嵌入式系統(tǒng)軟件測試中的適用性，并為融合探索性測試與傳統(tǒng)嵌入式軟件測試方法，形成適用于嵌入式系統(tǒng)軟件測試的探索性測試應(yīng)用模型提供思路和方向。

　　參考文獻(xiàn)

　　[1] 康一梅，張永革，李志軍，等.嵌入式軟件測試[M].北京：機(jī)械工業(yè)出版社，2008.

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

　　[3] WHITTAKER J A.探索式軟件測試[M].北京：清華大學(xué)出版社，2010.

　　[4] LYNDSAY J， VAN EEDEN N. Adventures in session?based testing [EB/OL]. [2002?08?02].

　　[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].

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