軟件在嵌入式系統中的作用越來越大。軟件的質量不僅直接影響任務的成敗，也關系著設備甚至人員的安全。隨著用戶對嵌入式系統軟件質量要求的提升，軟件測試已成為嵌入式系統交付前必不可少的環節。

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

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

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

　　探索性測試是解決嵌入式系統軟件測試需求變化快、軟件文檔缺乏、測試周期短等現實問題的可行手段之一。為了恰當運用，需要總結探索性測試的一般性應用方法體系，并探討其與嵌入式系統軟件測試體系的聯系和沖突。在此基礎上提出適用于嵌入式系統軟件測試的探索性測試應用模型。

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

　　探索性測試的概念形成較早，經過隨后的發展已形成了一定的應用體系。

　　1.1 探索性軟件測試的概念

　　傳統的軟件測試分為測試需求分析、測試策劃、測試用例設計、測試執行和測試總結等主要階段，依次開展[1]。傳統軟件測試流程依賴于完整、詳實的軟件需求和設計文檔作為輸入。而在現實的測試任務中，軟件需求和設計文檔往往有誤或不完備，這導致腳本測試活動無法正常有效開展。

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

　　(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)、用戶預期(User’s 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].

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