柳　溪

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

?

·測試技術(shù)·

探索式測試在雷達(dá)軟件中的應(yīng)用研究

柳溪

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

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

軟件測試；雷達(dá)；探索式測試；基于會話的測試管理；測試復(fù)用

0　引　言

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

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

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

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

1　研究背景

1.1經(jīng)典的腳本測試模型

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

圖1　經(jīng)典腳本測試流程

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

1.2探索式測試原理

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

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

2　相關(guān)工作比較

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

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

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

3　腳本會話測試模型

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

3.1腳本會話模型整體流程

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

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

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

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

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

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

3.2測試經(jīng)驗的固化和利用

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖4　基于會話的測試流程

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

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

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

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

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

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

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

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

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

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

3.4實驗結(jié)果

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

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

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

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

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

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

4　結(jié)束語

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

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

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

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

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

[3]孫俊若, 席曉強, 葉波, 等. 記載雷達(dá)軟件開發(fā)全周期測試技術(shù)研究[J]. 現(xiàn)代雷達(dá), 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]李昊. 雷達(dá)軟件測試用例復(fù)用技術(shù)研究[J]. 現(xiàn)代雷達(dá), 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)中的應(yīng)用[J]. 現(xiàn)代電子技術(shù), 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]柳溪, 馬康, 劉智. 融合探索性與腳本方法的第三方軟件測試模型及其應(yīng)用[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年生，工程師，工學(xué)博士。研究方向為軟件工程、嵌入式和信息系統(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