柳　溪

(南京電子技術研究所,　南京 210039)

?

·測試技術·

探索式測試在雷達軟件中的應用研究

柳溪

(南京電子技術研究所,南京 210039)

雷達軟件測試中常會遇到測試周期短、軟件文檔滯后甚至缺失等問題。在這種情況下，由于探索式測試方法強調了測試設計和執(zhí)行的同時性，并弱化了對軟件文檔的要求，因而能夠發(fā)揮靈活、快速的優(yōu)勢。文中針對探索式測試和傳統(tǒng)腳本測試的優(yōu)缺點，將會話機制和漫游方法等探索式測試成功實踐與經典的腳本式測試流程結合，提出了腳本會話測試模型。通過復用對應類型雷達軟件測試歷史項目的測試設計，在經典軟件測試流程中引入會話機制和漫游方法，并充分利用資深測試人員的經驗和組織資產，降低軟件需求、設計文檔以及測試人員經驗和能力對測試的影響，增強測試的適應性，提高測試的效率和質量。

軟件測試；雷達；探索式測試；基于會話的測試管理；測試復用

0　引　言

隨著用戶對軟件質量要求的提升，軟件測試已成為雷達軟件交付前的必要環(huán)節(jié)。軟件測試的質量也是影響雷達軟件的重要因素。由于雷達軟件開發(fā)周期受限，軟件需求和設計規(guī)約很可能在測試開展之前不能完善提供，且軟件測試的資源充分性也不能保證。在這種情況下，傳統(tǒng)的軟件測試方法不能發(fā)揮出最好的效果，需要研究如何借助探索式測試的方法以提高雷達軟件測試的效率和質量。

經典的測試方法要求依據(jù)軟件需求和設計文檔，遵循測試需求分析、測試策劃、測試設計、測試執(zhí)行和測試總結的流程，嚴格按照預先設計的測試“腳本”開展。因此，經典測試方法也稱為腳本測試(script testing)。腳本測試具有測試文檔全面、測試覆蓋率易度量、測試流程管理規(guī)范等優(yōu)勢。然而，隨著軟件迭代的加速，給軟件測試留出時間逐漸減少。雷達軟件測試呈現(xiàn)出一些新特點，包括軟件需求變化快、軟件文檔缺乏、軟件測試周期短、測試時間不足等，在這些情況下采用傳統(tǒng)腳本測試方法的軟件測試往往無法有效開展。

與腳本測試不同的探索式測試(exploratory testing)作為一種敏捷測試方法，不區(qū)分測試階段，測試設計、執(zhí)行和總結同時進行，依靠測試人員的經驗和主動性對被測軟件進行分析測試。探索式測試具有在時間短和文檔不完善的情況下，充分發(fā)揮測試人員的經驗和能力，快速、高質量完成軟件測試等優(yōu)點。目前，已有基于會話的測試管理模型，以及漫游法等探索式測試管理方法[1-2]。雷達產品的軟件測試往往需要完整的測試文檔，并要求能夠有效控制測試流程和測試結果以保證測試質量，探索式測試由于弱化了對文檔、測試階段劃分和測試充分性度量的要求，使之不宜直接用于雷達軟件測試。

在測試時間短、文檔不充分的情況下，如何結合經典腳本測試流程與探索式測試方法，是一個值得研究的問題。本文針對這一問題，我們提出了腳本會話測試模型，將會話和漫游等探索式測試方法融合到經典腳本測試流程中，以提升雷達軟件測試的效率和質量。

1　研究背景

1.1經典的腳本測試模型

腳本測試按照測試需求分析、測試策劃、測試設計、測試執(zhí)行和測試總結的流程進行，如圖1所示[3-4]。測試需求分析以軟件需求規(guī)格說明或設計文檔為輸入，提取測試需求，構造測試項(每個測試項對應一個測試需求)，并形成測試需求說明文檔;測試策劃以測試需求分析為基礎，對測試活動進行計劃，形成測試計劃文檔;測試設計則根據(jù)軟件需求和設計文檔，為每個測試項設計測試用例，形成測試說明文檔。測試執(zhí)行人員按照測試用例的測試步驟，測試被測軟件，記錄其結果以發(fā)現(xiàn)缺陷。最后，所有用例執(zhí)行完畢后開展測試總結，對測試執(zhí)行結果以及缺陷進行匯總，形成測試報告文檔。

圖1　經典腳本測試流程

腳本測試能夠保障測試過程對待測軟件各項屬性的覆蓋。上一階段制品可以指導下一階段測試活動。測試成本易于分析，測試過程嚴格、可控。腳本測試對軟件需求、設計和編碼要求較高，例如:要求軟件需求和設計文檔能夠詳細、準確描述待測軟件的各項指標和操作。同時，腳本測試中測試需求分析和設計階段用時較長。此外，若軟件設計和編碼發(fā)生較大變動時，腳本測試無法快速適應變化，需重新進行測試策劃、設計等工作。

1.2探索式測試原理

探索式測試是一種敏捷測試方法，強調經驗的重要性，以及在測試中同時開展測試需求分析、測試設計、測試執(zhí)行和測試結果評估等活動，持續(xù)優(yōu)化測試工作。其主要特點是：(1)強調測試設計和執(zhí)行的同時性；(2)適用于在短時間內發(fā)現(xiàn)被測軟件一些重要缺陷或事先沒有能夠進行詳細測試設計的情況；(3)通過測試來不斷學習被測系統(tǒng)；(4)快速實驗、隨時調整。作為一種敏捷軟件測試方法，探索式測試相應弱化了對軟件文檔的要求，并更關注測試本身，在保證軟件測試質量的同時縮短軟件測試周期，尤其是測試設計階段占用的時間。一般更適用于人工測試或需要大量人工分析的自動化測試。

探索式測試的主要優(yōu)點在于：(1)充分利用測試人員經驗；(2)適用于需要學習的系統(tǒng)、有時間約束、補充測試等情況；(3)適應性強，尤其是需求變化、規(guī)約不明確情況；(4)測試對開發(fā)的反饋較快；(5)能夠發(fā)揮創(chuàng)造性，降低“殺蟲劑”效應[5-7]。同時，探索式測試也體現(xiàn)出測試文檔不完善和測試覆蓋率不易直接度量等不足[8]。

2　相關工作比較

雖然“探索式測試”一詞在1983年提出[8]，但其軟件測試方法一直在熟練的軟件測試人員中使用。 Whittaker[2]還進一步擴展了探索式測試的概念和方法，總結了微軟開展探索式軟件測試的經驗，并提出了漫游方法。Itkonen[9]等人的研究表明，探索式測試比傳統(tǒng)方法的缺陷誤報率更低，發(fā)現(xiàn)缺陷數(shù)量更多，如在用戶界面測試中多發(fā)現(xiàn)了43%的缺陷。在微軟Windows 2000兼容性認證中也采用了探索式測試方法。Nassar[5]等人還統(tǒng)計了探索式測試方法在瑞典軟件公司測試活動中的使用情況。探索式測試在互聯(lián)網(wǎng)、醫(yī)療、信息系統(tǒng)等各類型軟件測試中也都有運用[10-11]。

目前，探索式測試的開展方法有：“漫游法”“捕獲-重放”等方法[2,12]。對探索式測試的管理方法已形成以“基于會話的測試管理”為代表的管理模式[1]。漫游法是對微軟在進行探索式測試實踐的經驗總結，這個方法描述了如何開展“探索”，從而盡可能充分的探索被測軟件、發(fā)現(xiàn)隱藏缺陷[2]。捕獲-重放的方法主要用來記錄探索式測試的過程，從而提高探索式測試的可重復性，并為確認缺陷保存依據(jù)，同時縮短回歸測試時間[12]。在管理模式方面，基于會話的測試管理(SBTM)是探索式測試管理模型中最常見的一種，其中的測試活動通過基于時間片段限定的測試會話來計劃和控制，以迭代的方式推進[1]。基于線索的測試管理(TBTM)是對SBTM的發(fā)展，是以問題和目標為中心的更為松散的方式管理測試過程。Lyndsay[13]等人還進一步提出了測試點的概念，并在會話上增加了風險等級的概念。

本文提出的腳本會話測試模型對會話進行了擴充，并將會話、漫游方法與經典的腳本測試方法相結合，以使得腳本測試流程與探索式測試的優(yōu)勢互補，從而發(fā)揮更好的效果。

3　腳本會話測試模型

由于雷達軟件開發(fā)周期受限，軟件需求和設計規(guī)約很可能在測試開展之前不能完善提供，且軟件測試的資源充分性也不能保證。雷達軟件的系統(tǒng)和配置項級測試仍以人工測試為主。應用探索式測試方法是提高雷達軟件測試效率，充分發(fā)揮測試人員的經驗和能力，在測試文檔不全的情況下開展軟件測試的必要選擇。然而，雷達產品軟件測試通常需要滿足特定的標準和規(guī)范的約束，以有效控制測試流程和測試充分性度量，同時還要提供完整的測試文檔，并保證測試質量。利用探索式測試策略可以縮短測試周期，但探索式測試不易直接度量測試充分性，且弱化了測試文檔。而文檔、測試流程管理和充分性度量則正是經典腳本測試的優(yōu)勢。因此，腳本會話測試模型將探索式測試與經典腳本測試結合，以借助經典腳本測試成熟的管理流程和探索式測試的高效、適應性強等優(yōu)勢。

3.1腳本會話模型整體流程

腳本會話模型整體流程，如圖2所示。其遵循經典的腳本測試流程，將測試過程劃分為測試需求分析策劃和設計、測試執(zhí)行以及測試總結的步驟開展。但在測試需求分析策劃和設計階段，利用同譜系雷達軟件相似性較大的特點，根據(jù)當前產品需求，將測試項和測試用例大量的從歷史典型數(shù)據(jù)中復用。同時，在測試執(zhí)行過程中采用擴展的探索式測試方法，通過基于會話方式開展，會話執(zhí)行時借助漫游測試法[2]探索軟件特性，并根據(jù)實際情況補充調整測試用例。測試總結報告借助會話記錄單進行整理，并將本產品測試數(shù)據(jù)重新整理后納入復用庫。具體包含以下步驟：

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

1) 測試需求分析、策劃和設計階段:借助測試設計輔助工具從雷達軟件測試典型數(shù)據(jù)復用庫復用測試項和用例，降低對軟件需求和設計文檔的依賴，初步完成測試需求的提取和測試用例的設計，產生第一版測試需求規(guī)格說明、測試計劃和測試說明文檔。

2) 測試執(zhí)行階段：測試執(zhí)行以基于會話的方式開展，并對一般會話進行擴展。根據(jù)測試設計和計劃，確定每個會話的主旨、用例和測試方法。測試人員在每一次會話中，根據(jù)設計階段確定的漫游策略，針對一個測試項進行“探索”，補充測試用例。測試人員在會話結束后整理會話記錄單。根據(jù)本輪會話執(zhí)行情況，記錄缺陷、改善測試設計，并準備下一輪會話。如此迭代直到測試結束條件滿足，測試執(zhí)行結束。隨后更新測試需求規(guī)格說明、測試計劃和測試說明文檔。

3) 測試總結階段：借助測試執(zhí)行中各個會話報告單，總結缺陷，產生測試報告；并對本產品測試數(shù)據(jù)進行抽象和優(yōu)化，納入雷達軟件測試典型數(shù)據(jù)復用庫中。

需要注意的是，由于雷達基本原理相同，并且同譜系不同雷達相似度較高，在測試需求分析、策劃和設計階段，即使軟件文檔不充分，雷達軟件測試人員依然可以根據(jù)經驗及測試典型數(shù)據(jù)復用庫，完成初步的測試設計。在測試執(zhí)行階段，對于軟件文檔中未詳細說明的產品新特性，可以借助漫游測試法[2]探索軟件特性，并結合用戶溝通和測試人員對各譜系雷達功能的經驗，在測試中學習被測軟件、補充和優(yōu)化測試設計。

3.2測試經驗的固化和利用

探索式測試方法強調測試人員的經驗。由于歷史測試項目中的測試信息經過了實際項目的檢驗，是重要的組織資產，也是資深測試人員經驗的外在表現(xiàn)。測試復用是利用測試人員經驗的有效手段。

不同雷達產品其基本工作原理都是相同的，雷達操控手操作方式接近，從而使得各個雷達系統(tǒng)軟件測試需求結構相似，構成了雷達軟件測試復用的基礎。通過分析，三年內同譜系雷達各產品功能需求差異一般不超過25%；同時，為保障技術穩(wěn)定性，各譜系內部軟件繼承性較大，同譜系雷達軟件代碼復用率可達70%以上，部分較為成熟的產品其代碼復用率甚至可達到80%。因此，同譜系不同產品測試用例有較多可以復用。

我們按照雷達產品類型，將歷史測試數(shù)據(jù)按照產品類型進行歸納和整理，形成雷達軟件測試典型數(shù)據(jù)復用庫，從而降低軟件需求和設計文檔質量以及測試人員的經驗和能力對雷達軟件測試設計質量的影響。復用庫的整理遵照如圖3的流程：首先，對各產品測試項目進行抽象，取出產品具體指標和操作特征；其次，提取同類產品測試數(shù)據(jù)的相似性，合并各產品測試需求和測試用例；然后，補充各產品特性測試數(shù)據(jù)；最后，去除冗余并規(guī)范文字描述。當新產品測試結束后，新產品的測試數(shù)據(jù)再次進行抽象，并按照上述相似的過程，納入復用庫中，為下次復用做準備。在從測試復用庫中復用測試數(shù)據(jù)時，需要根據(jù)產品特性補充產品具體信息。由于雷達對外數(shù)據(jù)交互依據(jù)通用軍/民用標準，數(shù)據(jù)報文格式已經標準化。因此，復用庫在整理時只需對具體數(shù)值進行“參數(shù)化”，并在復用時根據(jù)具體產品坐標、范圍、頻段等信息，對復用庫測試用例中的“參數(shù)”進行實例化。

圖3　測試典型數(shù)據(jù)復用庫整理流程

由于各類型雷達軟件測試典型數(shù)據(jù)復用庫信息量大，從復用庫中提取必要的測試數(shù)據(jù)需要借助計算機工具輔助。我們開發(fā)了基于復用的測試設計輔助工具，以幫助測試人員從復用庫中查詢和復用相關測試項和測試用例。測試人員可根據(jù)具體產品特性，復用的測試用例進行修改和編輯，添加和補充具體數(shù)值和信息，完成對復用測試用例的實例化。

3.3基于會話的測試執(zhí)行

探索式測試需要在良好管理下才能發(fā)揮效果?；跁挼臏y試管理(SBTM)，是探索式測試領域中最常用的管理實踐[1]。腳本會話測試模型中，針對雷達軟件測試的特性，參考TBTM和文獻[13]，對會話進行了擴展，包含以下六點：

1)主旨(charter)：測試項(對應一個測試需求)。

2)人員：一個會話指定一個測試人員。

3)優(yōu)先級：根據(jù)會話主旨對應的軟件特性的重要性級別確定。

4)先決條件：對測試環(huán)境和待測軟件的要求。

5)測試方法：測試用例集和漫游測試方法。

6)會話記錄單(session sheet)。

其中，會話記錄單記錄了會話的執(zhí)行信息：主旨、測試人、優(yōu)先級、實際用時(包括會話準備時間、會話執(zhí)行時間、缺陷發(fā)現(xiàn)和報告時間)、測試用例集的實際執(zhí)行情況(包括測試用例是否通過、實際執(zhí)行截圖等信息)、發(fā)現(xiàn)的缺陷(包括缺陷嚴重程度、缺陷關聯(lián)用例)、遇到的問題(包括可能解決方法)、對其他會話和后續(xù)測試的影響和注釋等。

傳統(tǒng)會話機制中，每個會話關注一個軟件功能點[1]；而我們提出的擴展會話中一個會話則關注軟件功能點分解出的測試項，會話粒度更細，執(zhí)行時間更短，對測試資源需求更少。同時，擴展會話引入了測試優(yōu)先級和先決條件等信息，測試負責人和測試工程師可根據(jù)實際情況快速調整測試資源的分配，并將傳統(tǒng)會話關注時間因素轉移為關注待測試的具體問題。

測試執(zhí)行管理模型，如圖4所示。測試負責人在測試開始時初始化各個會話，并分配測試任務。測試執(zhí)行過程分為若干輪進行，每輪為一天。每輪執(zhí)行中，測試負責人選定本輪要進行的會話，并跟蹤測試人員的會話執(zhí)行。測試人員在每個會話中按照預先指定的測試方法探索被測軟件，并將執(zhí)行過程記錄在會話記錄單中；同時分析當前會話是否對后續(xù)的其他會話的影響，例如，是否需要修正后續(xù)某會話的主旨或會話劃分應重新制定。在本輪會話執(zhí)行結束后，測試負責人召集會話總結會，測試人員匯報測試執(zhí)行情況并記錄缺陷，測試負責人評審會話記錄單和測試結果。根據(jù)測試情況反饋判定測試是否達到預定結束條件：若是，則進入測試總結階段；否則，修改完善測試設計和會話，開始下一輪測試。

圖4　基于會話的測試流程

探索式測試對測試人員創(chuàng)造性的發(fā)揮主要體現(xiàn)在腳本會話測試模型中的測試執(zhí)行階段。測試人員借助對被測雷達產品軟件的經驗，充分發(fā)揮其創(chuàng)造性，分析被測軟件特性，借助啟發(fā)式方法，根據(jù)被測軟件實際實例化測試用例，同時補充測試用例，對軟件進行深度測試。為了有效管理測試執(zhí)行過程，提高會話效率，每輪會話開始之前，測試團隊針對各會話對應測試項的特性，為各會話選定若干漫游方法。

漫游探索法是對測試人員在進行整體測試時最常使用的啟發(fā)式方法的總結，包括以下六類：

1)商業(yè)區(qū)漫游。關注測試用戶使用軟件主要特性，包括指南測試、賣點測試、地標測試、極限測試、快遞測試、深夜測試和垃圾車測試等方法。

2)歷史區(qū)漫游。關注測試遺留組件，包括近鄰測試、博物館測試、上一版測試等方法。

3)娛樂區(qū)漫游。關注測試輔助功能，包括配角測試、深巷測試、通宵測試等方法。

4)旅游區(qū)漫游。通過遍歷軟件各項功能進行測試，包括收藏家測試、長路徑測試、超模測試、多拷貝測試、偏遠酒吧測試等方法。

5)旅館區(qū)漫游。關注常被忽視或次要的功能測試，包括取消測試、懶漢測試等方法。

6)破舊區(qū)漫游。嘗試惡意甚至有害操作進行測試，包括破壞測試、反叛測試、強迫癥測試等方法，詳見文獻[2]。

測試人員在會話執(zhí)行中，依據(jù)測試用例和指定漫游方法，測試被測軟件，并根據(jù)實際測試情況反饋補充測試用例。

根據(jù)我們的調研和試驗，建議雷達軟件測試時優(yōu)先選擇指南測試、極限測試、取消測試、懶漢測試、破壞測試和強迫癥測試。在具有用戶手冊等文檔時，選用賣點測試、地標測試；在已知某模塊問題較多時，使用近鄰測試；在需要涉及系統(tǒng)啟動關閉、長時間運行的情況下，采用通宵測試、深夜測試等方法。

3.4實驗結果

為了驗證腳本會話模型，我們將腳本會話測試模型在測控類雷達軟件測試項目中進行實驗。測控類雷達軟件研制過程較為穩(wěn)定，適合在實驗中開展對照。此外，測控類雷達產品研制任務增長多(2013～2015年該譜系新增產品數(shù)占新增產品總數(shù)的33%)，測試資源較為緊張，需要運用腳本會話模型。目前測控類雷達軟件測試典型數(shù)據(jù)復用庫已完成整理。從近3年5個項目全部1 062個測試項和6 432個測試用例中，經過篩選、合并和抽象化，共收錄了828個測試項和3 413個測試用例。經驗和積累適合于應用腳本會話模型。

實驗在近期開展的測控類雷達軟件測試項目中隨機選擇了三個項目的軟件系統(tǒng)測試上開展。在測試之前對這3個項目的軟件文檔編寫、研發(fā)和第三方測試過程中均未做新的要求或進行干預，程序及文檔的質量與歷史項目水平相近。實驗中，測試人員在設計階段通過從復用庫中復用測試用例，執(zhí)行階段運用漫游探索法開展探索式測試執(zhí)行并記錄會話記錄單輔助測試總結。實驗統(tǒng)計了運用本文提出的腳本會話測試模型時測試時間和缺陷數(shù)量，包括遺留到第三方測試時才發(fā)現(xiàn)的缺陷數(shù)量。

試點結果統(tǒng)計數(shù)據(jù)，如表1所示(項目名稱和代號未顯示)。這三個項目的測試用例平均復用率約為72%。結果顯示，借助雷達軟件測試典型數(shù)據(jù)復用以實現(xiàn)將測試人員經驗運用于軟件測試設計中，相比采用傳統(tǒng)腳本測試方法的平均用時，整個測試流程總共節(jié)省時間約30%；尤其是對于雷達產品測試設計，平均每個用例的設計時間可以節(jié)省約45%左右。通過測試復用，還可以減少用于溝通和軟件文檔更新的時間。此外，借助會話記錄和各輪會話對測試活動的反饋，測試執(zhí)行階段測試過程記錄更為詳細、測試人員對軟件及缺陷的理解更為清晰，測試總結中與用戶/開發(fā)方的缺陷交流時間和測試報告編寫時間下降，按照缺陷數(shù)量平均，測試總結階段節(jié)省時間14%左右。同時，遺留到第三方測試才發(fā)現(xiàn)的缺陷個數(shù)比歷史平均下降，遺留缺陷率由19%左右下降到8%(三項目平均)，驗證了軟件測試質量的提升。但需要注意，由于腳本會話模型中測試執(zhí)行需要增加會話總結會和討論，平均每個用例的測試執(zhí)行時間增加了約9%(項目A和項目B平均)。

表1腳本會話測試模型試點統(tǒng)計h

項目測試用例個數(shù)測試設計耗時測試執(zhí)行耗時測試總結耗時發(fā)現(xiàn)的缺陷數(shù)遺留缺陷數(shù)歷史平均128777225713013025項目A114529025611013812項目B13793193171231459項目C12042882651081358

鑒于不同類型的產品歷史數(shù)據(jù)積累充分程度不同，并考慮產品的發(fā)展和我們預期，在保證測試質量的同時，應用腳本會話測試模型，能夠節(jié)省雷達軟件測試整個流程20%～30%的時間開銷，其中測試需求分析、策劃和測試設計階段節(jié)省用時可達40%～50%。但同時需要注意控制會話總結和討論對測試時間開銷的影響。

4　結束語

腳本會話模型將探索式測試方法與傳統(tǒng)的腳本測試流程結合。在雷達軟件測試時間短、任務重以及軟件需求和設計文檔往往滯后或不完備的情況下，在保證測試質量的同時，能夠縮短測試時間，產生齊備的軟件測試文檔，并確保測試流程可控。

在今后的工作中，我們會將腳本會話測試應用在更多雷達產品軟件測試中，并繼續(xù)整理其它類型雷達軟件測試典型數(shù)據(jù)復用庫。同時也將通過實際工程試用，不斷改進相關的測試管理方法和測試技術。

[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]孫俊若, 席曉強, 葉波, 等. 記載雷達軟件開發(fā)全周期測試技術研究[J]. 現(xiàn)代雷達, 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]. 現(xiàn)代雷達, 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]柳溪. 探索性軟件測試方法及其在嵌入式系統(tǒng)中的應用[J]. 現(xiàn)代電子技術, 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年生，工程師，工學博士。研究方向為軟件工程、嵌入式和信息系統(tǒng)軟件的測試自動化、基于模型的測試和驗證、安全性和可靠性測試和驗證等。

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