指揮信息系統(tǒng)軟件探索式測試應(yīng)用研究

◆施青青

?

指揮信息系統(tǒng)軟件探索式測試應(yīng)用研究

◆施青青

（中國電子科技集團(tuán)公司第二十八研究所 江蘇 210000）

本文通過分析探索式軟件測試的優(yōu)缺點和指揮信息系統(tǒng)軟件測試現(xiàn)狀，設(shè)計了適用于指揮信息系統(tǒng)軟件測試的探索式測試過程的具體方法，并設(shè)計了相應(yīng)的測試流程。通過使用基于簡單腳本的探索式測試方法，在發(fā)揮了探索式測試的優(yōu)點的同時避免了相應(yīng)的缺點，適應(yīng)了指揮信息系統(tǒng)軟件測試的需要，同時滿足了軍工軟件的管理要求。

探索式軟件測試；指揮信息系統(tǒng)；手工測試；測試流程

０引言

隨著指揮信息系統(tǒng)軟件功能越來越復(fù)雜和規(guī)模越來越龐大，用戶的需求變更也越發(fā)頻繁，軟件開發(fā)模式也在由傳統(tǒng)的瀑布模型向更高效的敏捷模式轉(zhuǎn)變，相應(yīng)的軟件測試模式也需要隨之轉(zhuǎn)變。而探索式測試（Exploratory Testing）方法具有敏捷測試的特點，能夠在時間短和文檔不完善的情況下，充分發(fā)揮測試人員的經(jīng)驗和能力，快速、高質(zhì)量完成軟件測試[1]。比較適用于測試需求變化快，事先無法詳細(xì)設(shè)計測試過程，并且需要大量手工測試的軟件項目。利用探索式測試，能夠顯著提高軟件測試的效率。因此研究探索式測試方法在指揮信息系統(tǒng)軟件測試中的應(yīng)用具有重要的現(xiàn)實意義。

1 探索式測試

探索式測試方法最早是由美國測試專家Cem Kaner博士在1983年提出的，它產(chǎn)生之初便贏得了大量的認(rèn)同，并且廣受推崇[2]。2010年測試專家James A. Whittaker根據(jù)其在微軟、谷歌等知名企業(yè)的工作經(jīng)歷和個人的經(jīng)驗積累，撰寫了《Exploratory Software Testing》（《探索式軟件測試》）一書。在書中，他對探索式測試的概念以及測試方法作了更進(jìn)一步的擴(kuò)展，他根據(jù)自己的研究，創(chuàng)新性地提出了全局、局部和混合式等具體的探索式測試方法，將探索式測試方法的實踐應(yīng)用拓展到更多的領(lǐng)域[3]。經(jīng)過二十多年的發(fā)展，探索式測試方法已經(jīng)逐步成型，并且在越來越多的軟件測試項目中發(fā)揮了應(yīng)有的作用。

探索性測試的主要優(yōu)點在于：充分利用人員經(jīng)驗；適用于需要學(xué)習(xí)的系統(tǒng)、有時間約束、補(bǔ)充測試等情況；適應(yīng)性強(qiáng)，尤其是需求變化、規(guī)約不明確情況；對測試人員和開發(fā)人員的反饋較快；能夠為測試帶來新內(nèi)容，降低“殺蟲劑”效應(yīng)影響[4]。探索式測試是強(qiáng)調(diào)個人自由與責(zé)任的測試方法，讓測試人員可以通過不斷學(xué)習(xí)來改善測試規(guī)劃和測試執(zhí)行，而測試執(zhí)行過程中收集到的信息也可以讓測試人員改善測試方法效果。

1.1 探索式測試與手工測試

手工測試（Manual Testing），通常會使用預(yù)先編寫好的測試用例。在測試用例中，會預(yù)先設(shè)定好測試執(zhí)行環(huán)境，并指定好各種各樣的測試輸入值，同時測試用例還會定義各類輸入值情況下的預(yù)期測試輸出結(jié)果。測試將會通過比對實際結(jié)測試果與預(yù)期結(jié)果是否存在差異，來判斷功能是否實現(xiàn)或者是否存在缺陷。不同的測試執(zhí)行人員，使用相同測試用例，很有可能將會得到一樣的測試結(jié)果，也因此很可能會導(dǎo)致有問題被遺漏。

Whittaker認(rèn)為探索式測試是手工測試領(lǐng)域里目前最好的測試技術(shù)[3]。它具備了很多手工測試的特點，但是探索式測試可以完全拋開事先設(shè)定好的測試用例，測試人員可以自由地進(jìn)行測試，不受任何約束地去探索軟件程序的各種功能[5]。探索式測試并不是說不寫文檔，測試結(jié)果、測試用例和測試設(shè)計等文檔，都會在測試執(zhí)行的同時創(chuàng)建。

1.2 探索式測試與自動化測試

自動化測試通過編寫代碼來測試軟件，自動化測試的根本目的是自動地對軟件產(chǎn)品在各種環(huán)境和狀態(tài)下的執(zhí)行進(jìn)行測試，排除影響測試的人為因素，從而降低花費在測試的開銷。自動化測試可以解決手工測試中重復(fù)、機(jī)械的勞動，發(fā)現(xiàn)手工測試難以發(fā)現(xiàn)的極端情況下的問題。

但是自動化測試不能解決所有問題，自動化測試有其適用的場景，適用于軟件界面和需求變化較小，需要重復(fù)執(zhí)行的測試活動，此外對于性能等需要在極端情況下進(jìn)行測試，自動化測試更具有優(yōu)勢。而對于目前敏捷開發(fā)模式，需求和軟件變化頻繁的開發(fā)模式則會使測試成本和時間陡增，并且對于與業(yè)務(wù)邏輯相關(guān)的缺陷，手工測試也更具優(yōu)勢。

1.3 探索式測試與腳本測試

腳本測試（Scripted Testing）是一種常用的測試組織方法。應(yīng)用腳本測試的測試設(shè)計人員需要事先編寫測試腳本，記錄所有的測試用例，而后測試執(zhí)行人員手工或者使用自動化測試工具執(zhí)行腳本，完成測試任務(wù)[6]。腳本測試按照測試需求分析、測試策劃、測試設(shè)計、測試執(zhí)行和測試總結(jié)的流程進(jìn)行。

相比腳本測試，探索式測試顯得更自由一些，它允許測試人員臨場發(fā)揮，鼓勵測試人員盡可能地發(fā)現(xiàn)程序缺陷。探索式測試與腳本測試并非對立，探索式測試可以和腳本測試很好地結(jié)合起來。使用正式的腳本可以為探索式測試提供一個明確的框架范圍，探索式測試可以提高腳本測試的有效性。

1.4 探索式測試方法的優(yōu)勢與不足

探索式測試方法的優(yōu)勢顯而易見。它比傳統(tǒng)手工測試更加的高效，也減少了隨機(jī)測試的盲目性。探索式測試可以充分發(fā)揮測試人員的能動性，將測試工作變被動為主動，探索式測試有利于發(fā)現(xiàn)與業(yè)務(wù)邏輯相關(guān)的缺陷。同時，探索式測試方法更適應(yīng)敏捷開發(fā)模式下的需求和軟件本身的頻繁變更，同時這也讓探索式測試看起來更有技術(shù)含量從而深受測試人員的歡迎，并且比較容易推廣。

探索式測試方法的主要缺點有：探索式測試運用不當(dāng)容易陷入漫無目的的陷阱變成盲目測試和隨機(jī)測試；測試文檔和測試記錄的缺乏容易導(dǎo)致對測試用例的重用性降低和測試過程的遺漏或重復(fù)；難以確定回歸測試的方式。

2 指揮信息系統(tǒng)軟件測試現(xiàn)狀分析

2.1 現(xiàn)狀測試流程

目前指揮信息系統(tǒng)軟測試一般采用W模型（如圖1所示），在W模型中，對軟件項目從開始到結(jié)束的各個階段都有驗證與測試環(huán)節(jié)，測試的對象不再僅僅是程序本身，而是擴(kuò)展到需求、功能和設(shè)計。只要完成對應(yīng)的開發(fā)活動，就可以執(zhí)行相應(yīng)的測試，可以盡早地發(fā)現(xiàn)問題。W 模型也存在一定的局限性。因為軟件開發(fā)和測試是一種線性的前后關(guān)系，需要遵從上個階段明確完成，下一個階段才能啟動的原則。這樣就無法支持迭代、自發(fā)性和變更調(diào)整，而這些恰好是目前指揮信息系統(tǒng)開發(fā)模型轉(zhuǎn)向敏捷模式需要解決的問題。

圖1 W模型

2.2 存在的主要問題

目前大部分的指揮信息系統(tǒng)軟件測試過程，都使用了W模型。該模型在規(guī)范軟件測試過程方面發(fā)揮了重要的作用，但是該模型也存在一定的問題。對目前指揮信息系統(tǒng)軟件測試流程中的主要問題分析如下：

( 1 ) 由于指揮信息系統(tǒng)龐大而且復(fù)雜，采用傳統(tǒng)的測試模型不容易分清楚測試重點；

( 2 ) 測試周期長，文檔要求高，難以適應(yīng)敏捷模式下的需求和軟件的頻繁變更；

( 3 ) 測試前需要事先花費大量時間編寫測試用例和相關(guān)文檔，測試時間和人力成本高。而且一旦測試需求和測試內(nèi)容變化，測試工作中測試用例的實際執(zhí)行覆蓋率偏低，測試用例的作用不大；

( 4 ) 缺陷提交和修復(fù)的時間周期長，缺陷問題會大量堆積，不利于缺陷問題的修復(fù)和測試流程的運轉(zhuǎn)，導(dǎo)致最終缺陷修復(fù)率偏低。

3 探索式測試在指揮信息系統(tǒng)測試中應(yīng)用

由于手工測試依然在指揮信息系統(tǒng)軟件測試中占有重要的地位，因此，如何避免在應(yīng)用探索式測試方法過程中的盲目性和隨機(jī)性，提高探索式測試的覆蓋率和重用率；如何提升軟件缺陷問題的修復(fù)率；如何在實現(xiàn)快速測試的同時保證測試的高效率。這些都是在指揮信息系統(tǒng)軟件測試過程應(yīng)用探索式測試方法需要研究和解決的問題。

3.1 基于簡單腳本的探索式測試的應(yīng)用

正如Whittaker在其書中提出：沒有必要把探索式測試與使用腳本的測試對立起來，也沒有必要認(rèn)為兩者不能共存[3]。同時使用兩種方法時可以正式腳本開始，然后再使用探索式測試法在腳本中加入各種各樣的變化。這樣，單一地測試腳本會演化出很多探索式測試用例?；谶@樣的理論和指揮信息系統(tǒng)軟件測試的實踐，設(shè)計了將探索式測試和簡單腳本相結(jié)合的實踐方法。從而達(dá)到結(jié)合兩種方法優(yōu)勢并且避免缺點的目的。

對于簡單腳本可以使用表格或思維導(dǎo)圖工具來描述測試的指導(dǎo)思想。思維導(dǎo)圖是英國心理學(xué)家東尼博贊在20世紀(jì)60年代發(fā)明的思維工具，是為了改進(jìn)線性筆記的不足而發(fā)明的一種非線性思維工具[7]。思維導(dǎo)圖工具適合用來表達(dá)發(fā)散性思維，將發(fā)散性思維形象化，XMind是目前比較流行的思維導(dǎo)圖工具。具體實踐中可以使用XMind工具在局部探索式測試時，思考需要測試的內(nèi)容并且適當(dāng)記錄測試結(jié)果，可以避免測試重復(fù)和遺漏，如圖2。

使用基于場景的混合測試時，可以使用XMind工具設(shè)計場景，并適當(dāng)記錄測試結(jié)果。圖3列舉了一個在指揮信息系統(tǒng)測試中應(yīng)用。

圖2 局部探索式測試

圖3 基于場景的探索式測試

3.2 實施探索式測試的流程

針對指揮信息系統(tǒng)軟件測試的特點和探索式軟件測試的特點，設(shè)計了探索式測試實施的流程如圖4所示。

圖4 探索式測試實施流程

在測試開始階段先明確測試目標(biāo)，決定何時測試和需求測試什么，然后進(jìn)行簡單腳本設(shè)計決定如何測試，根據(jù)測試目標(biāo)和簡單腳本進(jìn)行測試執(zhí)行，完成測試執(zhí)行后進(jìn)行測試分析，同時待開發(fā)人員完成缺陷修改后進(jìn)行回歸測試，完成回歸測試后完成本輪測試。然后進(jìn)入下一輪迭代。該測試流程有利于達(dá)成既定的測試目標(biāo)，同時能夠盡可能發(fā)現(xiàn)問題，并適應(yīng)敏捷開發(fā)的流程。同時由于有簡單的腳本設(shè)計和測試記錄，也便于測試完成后相應(yīng)測試文檔的編寫，以滿足軍工軟件相關(guān)標(biāo)準(zhǔn)對文檔的要求。

4 結(jié)論

通過在指揮信息系統(tǒng)測試中使用探索式測試方法的實踐，在測試中引入了簡單腳本并使用思維導(dǎo)圖工具作為輔助，避免了探索式測試中的無目的性和盲目性，同時能夠滿足相關(guān)軍工軟件的相關(guān)管理的要求，有利于提高測試效率進(jìn)而使測試人員發(fā)現(xiàn)更多測試問題，同時也適應(yīng)了當(dāng)前指揮信息系統(tǒng)軟件從傳統(tǒng)開發(fā)模式轉(zhuǎn)向敏捷模式的趨勢。

[1]柳溪.探索式測試在雷達(dá)軟件中的應(yīng)用研究[J].現(xiàn)代雷達(dá)，2016，38(9)：86-91.

[2]林煒.兩種軟件測試方法的比較和改進(jìn)[J].信息網(wǎng)絡(luò)安全，2012(7)：58-60.

[3]James A. Whittaker著，方敏等譯，探索式軟件測試[M].清華大學(xué)出版社，2010.

[4]柳溪，馬康，劉智.融合探索性與腳本方法的第三方軟件測試模型及其應(yīng)用[J].信息化研究，2013，39(6)：43-48.

[5]王志森.探索式測試方法在網(wǎng)絡(luò)游戲軟件測試中的應(yīng)用[D].上海：上海交通大學(xué)，2011.

[6]楊曉光.探索式測試在敏捷軟件項目安全性測試中的應(yīng)用研究[D].天津：天津工業(yè)大學(xué)，2015.

[7]尚潔，李春雷.快速迭代開發(fā)模式下系統(tǒng)測試方法[J].指揮信息系統(tǒng)與技術(shù)，2017，8（3）：93-98.