閆復(fù)利

摘要：多年的數(shù)字對(duì)講機(jī)測(cè)試經(jīng)驗(yàn)總結(jié)出一種“總分總”軟件測(cè)試法（又稱三步測(cè)試法），該測(cè)試方法基于傳統(tǒng)軟件測(cè)試過程V模型的右方集成測(cè)試、系統(tǒng)測(cè)試、驗(yàn)收測(cè)試階段，結(jié)合現(xiàn)代軟件測(cè)試過程，綜合運(yùn)用黑盒測(cè)試法、灰盒測(cè)試法、冒煙測(cè)試法、回歸測(cè)試法、探索性測(cè)試法，并進(jìn)一步嘗試發(fā)散性思維測(cè)試。

關(guān)鍵詞：數(shù)字對(duì)講機(jī)；軟件測(cè)試；總分總測(cè)試法；三步測(cè)試法；BUG抓取

中圖分類號(hào)：TP311 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1009-3044（2016）24-0093-02

Abstract： Years of experience in digital radio test come to the conclusion that a "general-devide-gendral" software testing method （also called three-step testing method）， the test method is based on traditional V model of software testing process to the right integration testing， system testing and acceptance testing， combined with modern software testing process， the integrated use of black box testing method， the grey box testing method， smoke test method and regression method， the exploratory testing method， and further attempts to divergent thinking test.

Key words： digital radio； software testing； general-devide-general testing； three-step testing； BUG capture

自從工信部2009年666號(hào)文件《工業(yè)和信息化部關(guān)于150MHz 400MHz頻段專用對(duì)講機(jī)頻率規(guī)劃和使用管理有關(guān)事宜的通知》頒布拉開了對(duì)講機(jī)模轉(zhuǎn)數(shù)的序幕，國內(nèi)企業(yè)經(jīng)過幾年的模轉(zhuǎn)數(shù)的技術(shù)積累和產(chǎn)業(yè)結(jié)構(gòu)調(diào)整，已有能力批量生產(chǎn)制造數(shù)字對(duì)講機(jī)。隨著微電子技術(shù)的發(fā)展，數(shù)字對(duì)講機(jī)的集成度高，大多廠家采用3片制方案，由基帶芯片、射頻收發(fā)芯片、微處理器芯片以及射頻放大電路和外圍輔助電路組成，硬件部分調(diào)試復(fù)雜度低，可靠性高。數(shù)字對(duì)講機(jī)與模擬對(duì)講機(jī)相比，話音質(zhì)量好、頻譜利用率高、省電節(jié)能、保密性好、業(yè)務(wù)功能豐富。業(yè)務(wù)功能豐富意味著數(shù)字對(duì)講機(jī)軟件開發(fā)工作量大且邏輯關(guān)系復(fù)雜，目前數(shù)字對(duì)講機(jī)制式不統(tǒng)一，僅僅國內(nèi)數(shù)字對(duì)講機(jī)標(biāo)準(zhǔn)（征求意見稿）就有四種制式[1]，面對(duì)多制式且功能豐富的數(shù)字對(duì)講機(jī)軟件開發(fā)，需要一套行之有效的測(cè)試方法進(jìn)行功能驗(yàn)證和性能測(cè)試，盡早發(fā)現(xiàn)程序的錯(cuò)誤、缺陷和不足，及時(shí)修正，防止錯(cuò)誤積累影響開發(fā)進(jìn)度乃至開發(fā)失敗。目前關(guān)于數(shù)字對(duì)講機(jī)軟件測(cè)試研究還處于萌芽狀態(tài)，行業(yè)中關(guān)于數(shù)字對(duì)講機(jī)的軟件測(cè)試指導(dǎo)也近似空白。作者結(jié)合自己實(shí)踐數(shù)字對(duì)講機(jī)軟件測(cè)試經(jīng)驗(yàn)，總結(jié)出“總分總”測(cè)試法。利用“總分總”測(cè)試思想測(cè)試的數(shù)字對(duì)講機(jī)從開發(fā)到投放市場情況反饋看，功能滿足要求，性能穩(wěn)定可靠，降低開發(fā)成本，提高開發(fā)效率有積極作用。

1 數(shù)字對(duì)講機(jī)軟件“總分總”測(cè)試法思想

軟件測(cè)試分為靜態(tài)測(cè)試和動(dòng)態(tài)測(cè)試[2]。靜態(tài)測(cè)試可以盡早發(fā)現(xiàn)邏輯錯(cuò)誤和編碼缺陷，靜態(tài)測(cè)試需要測(cè)試人員深入了解對(duì)講機(jī)制式以及協(xié)議且有讀懂代碼分析代碼的能力，對(duì)人員業(yè)務(wù)素質(zhì)要求較高，不適合目前數(shù)字對(duì)講機(jī)行業(yè)的現(xiàn)實(shí)情況。動(dòng)態(tài)測(cè)試發(fā)現(xiàn)錯(cuò)誤和缺陷晚于靜態(tài)測(cè)試，動(dòng)態(tài)測(cè)試結(jié)合手工測(cè)試目前仍然是發(fā)現(xiàn)錯(cuò)誤的最有效的方法。自動(dòng)測(cè)試雖然可以提高效率，實(shí)現(xiàn)自動(dòng)測(cè)試編寫腳本和維護(hù)腳本的資源和技能成本比較高，數(shù)字對(duì)講機(jī)軟件回歸測(cè)試不是很大，綜合考慮自動(dòng)測(cè)試的產(chǎn)出比，選定手工測(cè)試作為測(cè)試的方式。總分總測(cè)試的總體思路如下：1）軟件開發(fā)人員提供一版可供測(cè)試的軟件，軟件測(cè)試人員按照設(shè)計(jì)要求或開發(fā)規(guī)格書全面仔細(xì)做一遍測(cè)試，測(cè)試的準(zhǔn)確性要有保證，并把發(fā)現(xiàn)的問題和現(xiàn)象反饋給開發(fā)人員；2）開發(fā)人員修正更新軟件版本，測(cè)試人員有針對(duì)性的測(cè)試項(xiàng)目，把已發(fā)現(xiàn)的問題和現(xiàn)象逐個(gè)測(cè)試是否修正。如有沒有修正的，再次反饋給開發(fā)人員修正，如此反復(fù)迭代更新軟件版本，直到第一遍完整測(cè)試發(fā)現(xiàn)的問題現(xiàn)象都得到解決和滿足設(shè)計(jì)要求；3）把反復(fù)迭代后的最新軟件版本再次做一次完整全面的測(cè)試，如滿足設(shè)計(jì)要求則可以發(fā)布beta版本。如不滿足要求再次進(jìn)行版本迭代直到無問題，再做完整全面測(cè)試；4）在已發(fā)布beta版本的基礎(chǔ)上，再做隨機(jī)性測(cè)試和探索性測(cè)試以及非常規(guī)測(cè)試，如發(fā)現(xiàn)問題則返回2），如未發(fā)現(xiàn)問題則作為正式版本發(fā)布。該測(cè)試方法是黑盒測(cè)試法，灰盒測(cè)試法，冒煙測(cè)試法、回歸測(cè)試法、隨機(jī)測(cè)試法[3-4]的綜合運(yùn)用，“總分總”測(cè)試法流程如圖1所示。

2 數(shù)字對(duì)講機(jī)軟件“總分總”測(cè)試法的具體運(yùn)用

2.1 第一階段測(cè)試

第一次總體完整測(cè)試旨在綜合運(yùn)用冒煙測(cè)試法、黑盒測(cè)試法、手工測(cè)試法進(jìn)行功能性測(cè)試，主要測(cè)試開發(fā)的軟件是否實(shí)現(xiàn)了設(shè)計(jì)要求或開發(fā)規(guī)格的項(xiàng)目。第一次完整測(cè)試至關(guān)重要，該階段是發(fā)現(xiàn)問題最早的階段，該階段抓住的軟件問題和軟件BUG越多，越有利于提高開發(fā)效率，降低開發(fā)成本。該階段運(yùn)用黑盒測(cè)試法，主要是避免測(cè)試人員形成代碼定性思維，完全根據(jù)設(shè)計(jì)要求或開發(fā)規(guī)格進(jìn)行驗(yàn)證測(cè)試。在測(cè)試時(shí)運(yùn)用冒煙測(cè)試法，把設(shè)計(jì)要求或開發(fā)規(guī)格的各個(gè)項(xiàng)目分為若干優(yōu)先級(jí)，越是主要重要的功能，優(yōu)先級(jí)越高，優(yōu)先測(cè)試優(yōu)先級(jí)高的項(xiàng)目，再測(cè)試優(yōu)先級(jí)低的項(xiàng)目，直至所有項(xiàng)目驗(yàn)證測(cè)試完畢，形成固件軟件反饋文檔給開發(fā)設(shè)計(jì)人員。根據(jù)不同的機(jī)型和產(chǎn)品定義，功能測(cè)試的細(xì)節(jié)有所不同，總體上說有以下幾方面：寫頻軟件兼容不同操作系統(tǒng)測(cè)試，寫頻軟件安裝測(cè)試以及界面評(píng)估易用評(píng)估，對(duì)講機(jī)各項(xiàng)功能測(cè)試，對(duì)講機(jī)互操作性測(cè)試，中繼測(cè)試以及集群測(cè)試。在第一次總體完整測(cè)試時(shí)，同步建立對(duì)講機(jī)各項(xiàng)功能測(cè)試用例，對(duì)講機(jī)互操作性測(cè)試用例，中繼測(cè)試以及集群測(cè)試用例，這些測(cè)試用例的建立和設(shè)計(jì)，是為第二階段的軟件版本迭代測(cè)試，逐個(gè)驗(yàn)證第一階段發(fā)現(xiàn)的問題準(zhǔn)備的，也為第三階段的總體完整性測(cè)試做了準(zhǔn)備，第一階段建立的測(cè)試用例節(jié)約了第二三階段再次建立測(cè)試用例的時(shí)間。第一階段建立的測(cè)試用例根據(jù)功能項(xiàng)目命名保存于計(jì)算機(jī)中，第二三階段直接調(diào)取使用。如果第二三階段發(fā)現(xiàn)測(cè)試用例還不完善，繼續(xù)完善測(cè)試用例。

2.2 第二階段測(cè)試

軟件版本迭代測(cè)試，本階段是持續(xù)發(fā)現(xiàn)問題分析問題解決問題的關(guān)鍵階段。該階段綜合運(yùn)用了回歸測(cè)試法和灰盒測(cè)試法，防止解決了舊問題引入新問題，測(cè)試人員可以和開發(fā)人員溝通代碼修改后的關(guān)聯(lián)影響，從而制定適當(dāng)范圍的測(cè)試策略。灰盒測(cè)試法的效率在黑盒法和白盒測(cè)試法之間，非常適合該階段的測(cè)試，并滿足效率要求，也一定程度上關(guān)注了代碼內(nèi)部的正確性。軟件開發(fā)人員跟進(jìn)測(cè)試人員反饋的問題和優(yōu)先級(jí)，復(fù)現(xiàn)并分析問題，修改代碼，為了提高開發(fā)效率，軟件開發(fā)人員修改一定的問題后，更新版本并版本號(hào)自動(dòng)升級(jí)發(fā)給測(cè)試人員測(cè)試，同步更新軟件問題反饋表，在表中描述修改的問題的原因和方法，并用不同顏色標(biāo)注（例如綠色表示更新解決，黃色表示待處理，紅色表示未解決，藍(lán)色表示代碼更新未解決），測(cè)試人員收到反饋表一目了然測(cè)試驗(yàn)證代碼已更新解決的問題。測(cè)試驗(yàn)證滿足要求不再反饋，維持綠色標(biāo)注。測(cè)試人員發(fā)現(xiàn)問題仍舊存在則標(biāo)注藍(lán)色，以表示代碼更新未解決，軟件開發(fā)人員看到藍(lán)色標(biāo)注則繼續(xù)分析修改代碼解決。在軟件代碼反復(fù)迭代測(cè)試階段，軟件更新和測(cè)試都以較快的步伐進(jìn)行，軟件反饋表只是反饋了問題和現(xiàn)象，針對(duì)個(gè)別疑難問題不易描述清晰明了，測(cè)試人員和開發(fā)人員可以面對(duì)面或電話或QQ或微信等一切可以利用的通信工具和手段快速溝通，快速讓開發(fā)人員發(fā)現(xiàn)問題。根據(jù)不同機(jī)型和項(xiàng)目要求，軟件復(fù)雜度不同，首次軟件版本完整度不同，軟件迭代測(cè)試的測(cè)試量可能很大，工作量占到軟件開發(fā)和測(cè)試的一半以上。

2.3 第三階段

在第二階段反復(fù)迭代測(cè)試未發(fā)現(xiàn)問題的基礎(chǔ)上進(jìn)入該階段測(cè)試，第二階段未發(fā)現(xiàn)問題，軟件問題基本已解決80%以上了，基本滿足設(shè)計(jì)要求和開發(fā)規(guī)格。該階段總體完整測(cè)試一遍的目的是再次利用回歸測(cè)試法驗(yàn)證軟件功能，規(guī)避第二階段高效測(cè)試時(shí)回歸的不徹底不全面。由于測(cè)試用例經(jīng)過前述兩階段的完善已比較成熟，可以直接使用，該階段測(cè)試如未發(fā)現(xiàn)問題，則可以發(fā)布beta版本給產(chǎn)線生產(chǎn)以及客戶試用。如發(fā)現(xiàn)了問題則返回到第二階段繼續(xù)軟件版本迭代測(cè)試無問題后，再次進(jìn)入第三階段總體完整測(cè)試，直至第三階段總體完整測(cè)試無問題再發(fā)布beta版本。

探索測(cè)試階段，探索測(cè)試階段對(duì)測(cè)試人員業(yè)務(wù)素質(zhì)要求較高，沒有現(xiàn)成的測(cè)試用例、測(cè)試方法、測(cè)試技術(shù)、測(cè)試工具可用，依靠測(cè)試人員的思維和主觀能動(dòng)性進(jìn)行測(cè)試，需要經(jīng)常性改變測(cè)試策略。探索測(cè)試需要測(cè)試人員對(duì)軟件設(shè)計(jì)要求和開發(fā)規(guī)格的項(xiàng)目有較深的理解，也是未來測(cè)試領(lǐng)域的發(fā)展方向。結(jié)合數(shù)字對(duì)講機(jī)的實(shí)際情況，行業(yè)內(nèi)人士可以采用探索性測(cè)試，在該測(cè)試階段綜合運(yùn)用“無招勝有招”非常規(guī)輸入以及使用的非常規(guī)測(cè)試，可以發(fā)現(xiàn)軟件的可靠性和穩(wěn)定性的問題。

3 數(shù)字對(duì)講機(jī)軟件測(cè)試實(shí)例

作者使用“總分總”測(cè)試法測(cè)試過DMR、DPMR、企業(yè)自定義制式數(shù)字對(duì)講機(jī)，以及這些制式的中繼臺(tái)達(dá)幾十款系列產(chǎn)品，達(dá)到了預(yù)期的測(cè)試效果。在某型號(hào)數(shù)字對(duì)講機(jī)開發(fā)階段，運(yùn)用第一階段測(cè)試出色碼3與33與63不能區(qū)分，不同機(jī)型加密通信問題，不同機(jī)型報(bào)警系統(tǒng)兼容性問題，不同廠家短信兼容性問題，強(qiáng)插強(qiáng)拆問題，模擬模式的亞音誤解率高以及模擬亞音不同機(jī)型兼容問題， DTMF兼容性問題，盡早發(fā)現(xiàn)并及時(shí)反饋問題，提高了開發(fā)效率。運(yùn)用第二階段測(cè)試出代碼更新后帶來的數(shù)字亂碼嘯叫問題以及死機(jī)和重啟問題，結(jié)合灰盒測(cè)試法分析，與開發(fā)人員一起查找修改代碼引起這些問題的原因，并及時(shí)根據(jù)代碼關(guān)聯(lián)性預(yù)估可能影響的功能，及時(shí)修改測(cè)試策略并擴(kuò)大測(cè)試范圍，及時(shí)測(cè)試出旋轉(zhuǎn)信道偶爾會(huì)亂碼嘯叫問題，錄音模式影響模擬信道出現(xiàn)亂碼嘯叫問題。運(yùn)用第三階段探索性測(cè)試，采用非常規(guī)測(cè)試法測(cè)試出雙時(shí)隙模式死機(jī)問題，大聲講話數(shù)字對(duì)講機(jī)語音變小且不能在一PTT周期內(nèi)恢復(fù)問題，運(yùn)用第三階段的探索測(cè)試測(cè)出了非常規(guī)的問題，這些問題在正常使用不會(huì)出現(xiàn)問題，但是在特定場合特定行業(yè)應(yīng)用中則會(huì)造成不良影響和客戶對(duì)產(chǎn)品穩(wěn)定性產(chǎn)生懷疑，雖然第三階段可以發(fā)現(xiàn)的問題有的目前業(yè)界暫時(shí)無法解決，但為今后的技術(shù)演進(jìn)和產(chǎn)品設(shè)計(jì)提供了一定的參考。運(yùn)用該測(cè)試法形成的軟件測(cè)試反饋更新情況表如圖2所示，讀者可以結(jié)合項(xiàng)目實(shí)際情況作為參考。在狀態(tài)列可以清楚地看到哪些問題解決了，在軟件版本列可以清楚地看到在哪個(gè)版本解決問題了，哪些問題已修改代碼還未解決，哪些問題初始版本發(fā)現(xiàn)未解決和未處理，哪些軟件迭代版本出現(xiàn)了新問題。在這個(gè)表格中軟件開發(fā)人員和測(cè)試人員可以很清晰明了的了解現(xiàn)階段的軟件反饋更新情況。軟件開發(fā)人員可以在軟件版本列加上版本發(fā)布時(shí)間，在解決情況列加上解決時(shí)間和解決方法，測(cè)試人員可以在對(duì)應(yīng)的版本列和問題行交叉的CELL內(nèi)填寫驗(yàn)證情況和日期，以備今后查驗(yàn)以及項(xiàng)目總結(jié)作為分析和改進(jìn)的參考，軟件版本更新可以持續(xù)在右側(cè)添加軟件版本列，問題增加可以在末行持續(xù)增加行，直至該軟件穩(wěn)定可靠運(yùn)行發(fā)布。后續(xù)因工程應(yīng)用和產(chǎn)品升級(jí)也可以在該表格上繼續(xù)增加版本和問題，產(chǎn)品的軟件功能演進(jìn)也明確體現(xiàn)了。

4 結(jié)束語

總結(jié)了數(shù)字對(duì)講機(jī)軟件測(cè)試經(jīng)驗(yàn)，形成一種數(shù)字對(duì)講機(jī)功能測(cè)試與軟件BUG抓取方法，該方法采用類似議論文總分總的格式，故名曰“總分總”測(cè)試法，從測(cè)試階段劃分也稱三步測(cè)試法。從幾年的測(cè)試結(jié)果可以得出，該測(cè)試方法是高效可行的，行之有效的，測(cè)試出軟件的問題在覆蓋率、深度性、可靠性、容錯(cuò)性、穩(wěn)定性、前沿性都表現(xiàn)良好。采用該方法測(cè)試可以發(fā)現(xiàn)軟件絕大部分的問題和BUG，還有5%左右的問題和BUG可以在個(gè)別工程應(yīng)用和極限條件下發(fā)現(xiàn)，根據(jù)實(shí)際情況Update軟件。探索性測(cè)試可以發(fā)現(xiàn)前沿性的問題和穩(wěn)定性、容錯(cuò)性問題，作者進(jìn)一步關(guān)注與研究，并嘗試發(fā)散性思維測(cè)試在實(shí)踐中運(yùn)用。該測(cè)試方法在其他行業(yè)軟件測(cè)試有一定借鑒意義和參考價(jià)值。

參考文獻(xiàn)：

[1] 李進(jìn)良. 數(shù)字對(duì)講機(jī)標(biāo)準(zhǔn)（征求意見稿）存在的嚴(yán)重問題剖析[J]. 移動(dòng)通信， 2013（11）： 49-51.

[2] 張軍峰. 如何使軟件測(cè)試更有效[J]. 電腦知識(shí)與技術(shù)， 2005（2）： 70-72.

[3] 張新華， 何永前. 軟件測(cè)試方法概述[J]. 科技視界， 2012（4）： 35-37.

[4] 蟲師. 軟件測(cè)試分類[EB/OL]. [2016-08-13].http：//www.cnblogs.com/fnng/archive/2012/10/24/2737972.html.