羅文兵 徐海波 符號(hào)

摘要：測(cè)試工程師在開展測(cè)試工作時(shí)，對(duì)于專業(yè)背景強(qiáng)，規(guī)模大且復(fù)雜度高，文檔質(zhì)量參差不齊的被測(cè)軟件，會(huì)出現(xiàn)對(duì)需求理解不準(zhǔn)確、不全面、不深入等問(wèn)題，導(dǎo)致測(cè)試效果差。文章闡述了通過(guò)閱讀代碼結(jié)合需求文檔提取測(cè)試需求的方法，經(jīng)過(guò)實(shí)踐，能夠有效提高測(cè)試工程師分析測(cè)試需求和發(fā)現(xiàn)問(wèn)題的能力，把控軟件測(cè)試質(zhì)量。

關(guān)鍵詞：代碼;文檔;提取測(cè)試需求

一、研究問(wèn)題的提出

隨著軟件測(cè)試涉及的領(lǐng)域越來(lái)越廣泛，對(duì)測(cè)試質(zhì)量的要求逐步提高，測(cè)試過(guò)程需要更加注重測(cè)試發(fā)現(xiàn)問(wèn)題的質(zhì)量和測(cè)試用例的全面性與嚴(yán)謹(jǐn)性。部分測(cè)試機(jī)構(gòu)因?yàn)轫?xiàng)目領(lǐng)域廣泛，項(xiàng)目數(shù)量多且項(xiàng)目周期短，測(cè)試工作經(jīng)常采用短平快的策略來(lái)開展。但是面對(duì)核心項(xiàng)目的測(cè)試，當(dāng)前粗放式的測(cè)試模式已不適用。核心項(xiàng)目的特點(diǎn)往往是專業(yè)背景強(qiáng)，軟件規(guī)模大且復(fù)雜度高，涉及的算法多，對(duì)測(cè)試工程師來(lái)說(shuō)理解需求及開展測(cè)試工作更為困難。面對(duì)多場(chǎng)景多流程的核心軟件，測(cè)試工程師經(jīng)常會(huì)出現(xiàn)對(duì)需求理解不準(zhǔn)確、不全面、不深入的問(wèn)題，由于對(duì)需求理解不到位繼而導(dǎo)致測(cè)試內(nèi)容及方法設(shè)計(jì)不合理、不充分、不規(guī)范、不易理解、缺乏可操作性，最終測(cè)試過(guò)程只能浮于表面，發(fā)現(xiàn)不了軟件缺陷。

測(cè)試需求主要依賴輸入文檔，面對(duì)簡(jiǎn)單的軟件，通過(guò)閱讀輸入文檔基本能夠理解軟件的需求。面對(duì)核心軟件，僅僅依靠非偽代碼形式的輸入文檔中的文字信息，已不能覆蓋復(fù)雜且專業(yè)的核心軟件需求。同時(shí)委托方日益增長(zhǎng)的軟件質(zhì)量要求與軟件測(cè)試能力越來(lái)越不匹配。核心軟件的共同特點(diǎn)為承擔(dān)核心任務(wù)或關(guān)乎人員生命安全，對(duì)安全性可靠性要求極高。大多數(shù)核心軟件是嵌入式軟件且為C/C++語(yǔ)言編寫。例如航天領(lǐng)域的衛(wèi)星姿態(tài)與軌道控制軟件、星務(wù)軟件、飛行控制軟件、導(dǎo)航軟件等;航空領(lǐng)域的光雷系統(tǒng)控制軟件、火控計(jì)算軟件、HUD控制管理軟件、AMFD主控軟件等。這類軟件通常沒(méi)有人機(jī)交互和直觀的屏幕輸出，接口多樣化并且與硬件關(guān)系緊密，時(shí)序要求高且存在多模式切換需求。當(dāng)前在航空航天領(lǐng)域常用的1553B總線、CAN總線，F(xiàn)C網(wǎng)絡(luò)、1394網(wǎng)絡(luò)、RapidIO網(wǎng)絡(luò)、PCIE網(wǎng)絡(luò)等，都是專用的芯片和接口，需要用專業(yè)的仿真工具和方法進(jìn)行測(cè)試。這些因素共同提升了軟件測(cè)試的困難程度。

按照目前通行的測(cè)試模式，通過(guò)對(duì)任務(wù)書和設(shè)計(jì)文檔、需求說(shuō)明的分析之后開始編寫測(cè)試大綱，接著設(shè)計(jì)測(cè)試用例，執(zhí)行靜態(tài)分析，最后進(jìn)行動(dòng)態(tài)測(cè)試和回歸測(cè)試。這種模式的確可以完成兩個(gè)輸出成果物：測(cè)試大綱和測(cè)試報(bào)告，但測(cè)試內(nèi)容也僅限包含需求和任務(wù)書中的內(nèi)容。實(shí)際上因研制周期需要，目前有一部分軟件的研發(fā)過(guò)程并不是嚴(yán)格按照軟件工程化要求進(jìn)行的。有的軟件需求說(shuō)明、設(shè)計(jì)說(shuō)明等文檔是在程序編碼完成之后才匆匆按編程思路補(bǔ)充完成的，其準(zhǔn)確性和全面性都較差。如果軟件需求中漏寫了某些功能，測(cè)試工程師通過(guò)測(cè)試發(fā)現(xiàn)的可能性較小，測(cè)試過(guò)程中有很大概率被遺漏。稍好一些的軟件需求也僅描述了與該軟件相關(guān)的指標(biāo)及要求，具體的實(shí)現(xiàn)方式和細(xì)節(jié)并未表述清晰，測(cè)試工程師閱讀后也是一知半解。如果遇上邏輯不清晰或文字功底不強(qiáng)的研發(fā)人員，軟件需求中則會(huì)存在錯(cuò)誤、歧義甚至誤導(dǎo)，導(dǎo)致如果測(cè)試工程師不與研發(fā)人員進(jìn)行深入交流很難理解正確的需求。項(xiàng)目任務(wù)書或者研制合同雖然準(zhǔn)確性較高，但顆粒度很大，不足以支撐測(cè)試工程師提煉測(cè)試項(xiàng)。如果測(cè)試工程師基于這種劣質(zhì)的基線去編寫測(cè)試大綱必然是不準(zhǔn)確和不全面的，更不可能深入，在后續(xù)的測(cè)試過(guò)程極有可能會(huì)發(fā)現(xiàn)理解的需求和實(shí)際情況相差甚遠(yuǎn)，再回過(guò)頭去修改則費(fèi)工又費(fèi)時(shí)。很多情況下這些錯(cuò)誤往往不會(huì)被及時(shí)修正，甚至?xí)霈F(xiàn)誤改軟件的情況。

二、研究思路及解決方法

（一）思路

針對(duì)提出的問(wèn)題，解決思路是對(duì)核心軟件引入代碼結(jié)合文檔提取測(cè)試需求方法。既然通過(guò)軟件需求很難準(zhǔn)確、全面、深入地進(jìn)行需求分析，可以嘗試通過(guò)結(jié)合代碼直接去分析，尋找。根據(jù)軟件文檔進(jìn)行需求分析就像醫(yī)生給病人看病，如果病人本身就諱疾忌醫(yī)，不把癥狀告訴醫(yī)生，并不是每個(gè)醫(yī)生都能準(zhǔn)確找到病因。而結(jié)合代碼進(jìn)行需求分析就像法醫(yī)尸檢，不需要被檢測(cè)方的配合，方法科學(xué)加上認(rèn)真仔細(xì)即能找到死因。目前先進(jìn)的測(cè)試機(jī)構(gòu)均已初步開展文檔結(jié)合代碼進(jìn)行需求分析的方法提取測(cè)試需求，這種方法的好處是在閱讀需求時(shí)可以檢查對(duì)應(yīng)的功能在代碼中是否都有支撐，代碼實(shí)現(xiàn)的功能是否正確;在閱讀代碼時(shí)可以檢查文檔是否描述全面，需求描述是否準(zhǔn)確，需求中描述不到的細(xì)節(jié)可以通過(guò)閱讀代碼去補(bǔ)充。通過(guò)參閱并結(jié)合二者即可以檢查出需求和代碼實(shí)現(xiàn)不一致的地方，在無(wú)需研制人員配合的情況下準(zhǔn)確定位問(wèn)題所在。在閱讀代碼的同時(shí)可以更深入地了解軟件功能點(diǎn)，順著程序邏輯時(shí)序更能了解軟件流程，從而達(dá)到準(zhǔn)確全面深入了解軟件需求的目的，同時(shí)還能夠發(fā)現(xiàn)一部分軟件問(wèn)題。

（二） 方法

在了解了結(jié)合代碼進(jìn)行需求分析的解決思路后，如何結(jié)合代碼進(jìn)行需求分析？經(jīng)過(guò)研究及通過(guò)案例實(shí)踐，大體可以分為以下幾個(gè)步驟，如下圖所示。

圖1? ? 結(jié)合代碼進(jìn)行需求分析的步驟

1.測(cè)試工程師取得軟件需求和代碼之后，首先仔細(xì)閱讀軟件任務(wù)書和需求說(shuō)明等文檔，把軟件按照功能模塊進(jìn)行劃分，同時(shí)梳理出軟件內(nèi)部模塊間的關(guān)系、與外部的接口關(guān)系圖，對(duì)整體結(jié)構(gòu)能夠有一個(gè)直觀的認(rèn)識(shí)。

2.在關(guān)系圖上進(jìn)一步標(biāo)出所有的輸入輸出流，可以有效幫助測(cè)試工程師把握整體的數(shù)據(jù)流向。然后再進(jìn)一步確認(rèn)輸入和輸出的觸發(fā)條件，是周期性的還是偶發(fā)的或者條件控制的。

3.以關(guān)系圖為參考，使用源代碼閱讀工具打開工程代碼進(jìn)行代碼閱讀。

第一遍進(jìn)行粗讀，如果是單任務(wù)類的軟件則從main函數(shù)入手，首先找到初始化部分然后找到主循環(huán)，順著主循環(huán)中的順序一路梳理到每個(gè)函數(shù)，知道每個(gè)函數(shù)的功能是什么，對(duì)應(yīng)之前梳理好的功能模塊是什么，直到整個(gè)主循環(huán)結(jié)束。然后找到各個(gè)中斷，再?gòu)闹袛嗪瘮?shù)入口開始依次梳理，同樣知道每個(gè)函數(shù)的功能與需求文檔的對(duì)應(yīng)關(guān)系。粗讀完之后會(huì)對(duì)整個(gè)程序架構(gòu)有一個(gè)較為完整的認(rèn)識(shí)，趁此時(shí)機(jī)梳理一下輸入流是從哪個(gè)函數(shù)開始接收或采集的，輸出流是從哪個(gè)函數(shù)最終發(fā)出去或設(shè)置的。如果是多任務(wù)類的軟件則需要從主線程開始梳理，方法同單任務(wù)，但在梳理完一個(gè)任務(wù)之后需要依次梳理其他線程，最后梳理線程間的消息通訊。第一遍粗讀完之后會(huì)對(duì)軟件有一個(gè)較完整的認(rèn)識(shí)，相當(dāng)于摸清了一棵大樹的樹干和樹枝。第二遍進(jìn)行精讀，即仔細(xì)閱讀每一個(gè)函數(shù)，對(duì)應(yīng)每個(gè)功能模塊中具體的功能點(diǎn)，分析代碼實(shí)現(xiàn)功能是否跟需求描述的一致。然后分析接口部分相關(guān)代碼中輸入流的接收處理是否跟協(xié)議中的規(guī)定格式一致，內(nèi)容是否按照協(xié)議的約定進(jìn)行排列。輸出流的組幀方式、填寫的內(nèi)容是否跟協(xié)議中的規(guī)定一致。兩遍閱讀完成后對(duì)軟件會(huì)有一個(gè)清晰的認(rèn)識(shí)，豐富了整棵大樹的樹葉和花果。

4.通過(guò)以上結(jié)合文檔閱讀代碼的過(guò)程，作為測(cè)試工程師，應(yīng)該已經(jīng)知道軟件的實(shí)際需求是怎樣的，如何實(shí)現(xiàn)的，包括對(duì)數(shù)據(jù)的來(lái)龍去脈也已經(jīng)了如指掌，在此基礎(chǔ)上提取測(cè)試需求和測(cè)試重點(diǎn)編寫測(cè)試項(xiàng)則水到渠成，一般不會(huì)出現(xiàn)大的出入和理解上的偏差，更不會(huì)出現(xiàn)丟項(xiàng)漏項(xiàng)的情況。反過(guò)來(lái)還能給軟件需求提出很多改進(jìn)意見，這些意見是基于軟件實(shí)際提出來(lái)的，而不是通過(guò)需求猜出來(lái)的，更有說(shuō)服力也更具高級(jí)感。

（三） 實(shí)踐

將研究成果在多個(gè)項(xiàng)目中實(shí)踐，項(xiàng)目負(fù)責(zé)人或項(xiàng)目經(jīng)理在開展測(cè)試初期，拿到被測(cè)件后可以采用此方法對(duì)軟件實(shí)施分析，將軟件真正的需求吃透后給測(cè)試工程師講解，可以幫助測(cè)試工程師更好的理解軟件，為后續(xù)編寫測(cè)試大綱、測(cè)試用例提供很大幫助，整體提高軟件測(cè)試質(zhì)量。

例1，在某商用航天控制軟件測(cè)試過(guò)程中，測(cè)試工程師在編寫完測(cè)試大綱后，代碼走查人員在檢查時(shí)發(fā)現(xiàn)該軟件最重要最核心的火箭點(diǎn)火功能和點(diǎn)火時(shí)序都沒(méi)有測(cè)到，找漏測(cè)原因時(shí)發(fā)現(xiàn)軟件需求中沒(méi)有寫明，僅在任務(wù)書中體現(xiàn)，故測(cè)試工程師遺漏了。后期通過(guò)代碼閱讀發(fā)現(xiàn)程序中存在多個(gè)函數(shù)對(duì)應(yīng)火箭點(diǎn)火處理和時(shí)序處理功能，很容易就發(fā)現(xiàn)測(cè)試功能項(xiàng)缺失的問(wèn)題。

例2，在某通信系統(tǒng)綜合控制器軟件的需求中漏寫了代號(hào)設(shè)置等多項(xiàng)指令設(shè)置功能，在初期測(cè)試需求中也自然遺漏了這些功能，但通過(guò)結(jié)合文檔進(jìn)行代碼閱讀最終發(fā)現(xiàn)了遺漏項(xiàng)并進(jìn)行了補(bǔ)充。

這樣的案例還有很多，包括需求描述不準(zhǔn)確或需求與程序?qū)崿F(xiàn)不一致等等問(wèn)題，通過(guò)閱讀代碼的方法很容易就能準(zhǔn)確找到。代碼粗讀的時(shí)間成本并不大，磨刀不誤砍柴工，5000行左右的代碼對(duì)于成熟的測(cè)試工程師來(lái)說(shuō)粗讀需要的時(shí)間也就1天，但可以節(jié)省下很多猜測(cè)需求實(shí)質(zhì)，咨詢需求如何實(shí)現(xiàn)，反復(fù)修改測(cè)試需求的時(shí)間。

測(cè)試工程師在軟件需求文檔質(zhì)量差或需求不易理解的情況下，也可以通過(guò)代碼結(jié)合文檔的方法引導(dǎo)進(jìn)行測(cè)試。針對(duì)核心軟件，研制人員在軟件開發(fā)過(guò)程中一般都比較謹(jǐn)慎，軟件質(zhì)量較高，且經(jīng)過(guò)研制方的內(nèi)審和所檢等多輪內(nèi)部測(cè)試后才會(huì)交由專業(yè)測(cè)試機(jī)構(gòu)進(jìn)行測(cè)試。測(cè)試工程師在不深入了解軟件的情況下很難發(fā)現(xiàn)問(wèn)題，在動(dòng)態(tài)測(cè)試效果不佳時(shí)，可以采用代碼精讀法，從代碼結(jié)合需求的角度進(jìn)行突破。代碼精讀的時(shí)間成本雖然相對(duì)較高，但是會(huì)對(duì)軟件測(cè)試質(zhì)量有一個(gè)質(zhì)的提升，面對(duì)核心軟件還是應(yīng)當(dāng)把質(zhì)量放在第一位，時(shí)間上的付出也是值得的。

通過(guò)研究和實(shí)踐，采用代碼結(jié)合文檔提取測(cè)試需求的方法實(shí)現(xiàn)代碼粗讀和精讀后，能夠更容易發(fā)現(xiàn)軟件設(shè)計(jì)上的漏洞和深層次問(wèn)題，可以提高測(cè)評(píng)機(jī)構(gòu)在同行業(yè)內(nèi)的核心競(jìng)爭(zhēng)力。

（四） 拓展

測(cè)試機(jī)構(gòu)及測(cè)試團(tuán)隊(duì)需要在內(nèi)部審核過(guò)程中增加項(xiàng)目負(fù)責(zé)人或項(xiàng)目經(jīng)理把關(guān)的環(huán)節(jié)，項(xiàng)目負(fù)責(zé)人和項(xiàng)目經(jīng)理在拿到被測(cè)軟件后采用代碼結(jié)合需求的方法對(duì)軟件實(shí)施分析，迅速對(duì)軟件有一個(gè)高度的認(rèn)識(shí)和深入的理解，在此基礎(chǔ)上不僅可以在各測(cè)試階段指導(dǎo)測(cè)試工程師實(shí)施測(cè)試工作，同時(shí)也更有能力對(duì)測(cè)試本身的質(zhì)量（解決需求理解不準(zhǔn)確、不全面、不深入的問(wèn)題）進(jìn)行把控，對(duì)測(cè)試文檔中的缺失、描述不準(zhǔn)確、方法不恰當(dāng)、理解有歧義之處很容易能夠指出來(lái)，避免帶著問(wèn)題層層闖關(guān)。

如果被測(cè)軟件專業(yè)程度高，需要測(cè)試工程師提前做好基礎(chǔ)性研究工作，取得軟件需求后對(duì)軟件服務(wù)領(lǐng)域中的專業(yè)術(shù)語(yǔ)，不理解的應(yīng)提前學(xué)習(xí)，查不到的先請(qǐng)教領(lǐng)導(dǎo)或同事，實(shí)在找不到相關(guān)資料地再請(qǐng)教研制人員，不要上來(lái)就向研制方詢問(wèn)。比如測(cè)某個(gè)專業(yè)性強(qiáng)的軟件，詢問(wèn)研制人員某個(gè)非?；A(chǔ)的術(shù)語(yǔ)會(huì)讓委托方認(rèn)為測(cè)試工程師是外行，引起研制方的輕視和反感，心理上對(duì)測(cè)試方的專業(yè)性和能力表示懷疑，行為上表現(xiàn)為不配合，為后續(xù)測(cè)試設(shè)置了障礙。反之，測(cè)試工程師提前通過(guò)代碼閱讀結(jié)合文檔的方法可以更快更深入地了解專業(yè)軟件，一旦研制方發(fā)現(xiàn)測(cè)試工程師具備行業(yè)領(lǐng)域知識(shí)，并能從專業(yè)的角度提出了正確的建議，會(huì)從心理肯定測(cè)試工程師的能力，對(duì)測(cè)試工程師尊重與認(rèn)可，在此基礎(chǔ)上進(jìn)行的合作也是愉快的。很多經(jīng)驗(yàn)豐富的測(cè)試工程師在項(xiàng)目實(shí)施過(guò)程中通過(guò)代碼結(jié)合文檔的方法能夠做到比研制人員還熟悉軟件，原因是測(cè)試工程師不僅了解了軟件的各個(gè)細(xì)節(jié)，更能夠結(jié)合豐富的測(cè)試經(jīng)驗(yàn)從測(cè)試的角度去分析軟件，為軟件質(zhì)量的提升提出了中肯的建議。

針對(duì)專業(yè)程度高的軟件，對(duì)于測(cè)試工程師及團(tuán)隊(duì)、機(jī)構(gòu)還可以分類進(jìn)行技術(shù)積累，在使用代碼結(jié)合文檔提取測(cè)試需求方法吃透并完成一個(gè)行業(yè)領(lǐng)域的測(cè)試項(xiàng)目后，應(yīng)及時(shí)反思測(cè)試過(guò)程中遇到的坑，總結(jié)避坑經(jīng)驗(yàn)，總結(jié)測(cè)試心得和針對(duì)此類軟件的測(cè)試方法，下次再遇到此類軟件時(shí)可以少走彎路，也可以給其他測(cè)試工程師啟發(fā)。在遇到典型問(wèn)題時(shí)及時(shí)總結(jié)編寫案例，同樣可以給自己和他人啟發(fā)，舉一反三。長(zhǎng)久下來(lái)形成技術(shù)經(jīng)驗(yàn)總結(jié)、典型案例總結(jié)兩大資產(chǎn)庫(kù)。這也是一個(gè)評(píng)測(cè)機(jī)構(gòu)的技術(shù)積累和文化沉淀。

三、結(jié)束語(yǔ)

通過(guò)代碼結(jié)合文檔的方式不僅可以解決需求理解不準(zhǔn)確、不全面、不深入的問(wèn)題，再進(jìn)一步可以解決發(fā)現(xiàn)不了問(wèn)題或發(fā)現(xiàn)不了高級(jí)問(wèn)題的困擾。通過(guò)代碼走查，在粗讀、精讀兩級(jí)代碼閱讀的基礎(chǔ)上，再進(jìn)行變量分析和邏輯分析等方法可以進(jìn)一步提高軟件測(cè)試質(zhì)量，有效提高測(cè)試工程師發(fā)現(xiàn)問(wèn)題的能力，拓寬測(cè)試思路?；谝陨涎芯?，綜合項(xiàng)目實(shí)施過(guò)程中的方法和經(jīng)驗(yàn)，已將研究成果在多個(gè)項(xiàng)目中進(jìn)行了實(shí)踐，能夠有效改善軟件需求理解不準(zhǔn)確、不全面、不深入的問(wèn)題，減少測(cè)試內(nèi)容及方法設(shè)計(jì)不合理、不充分、不規(guī)范、不易理解、缺乏可操作性的問(wèn)題。減少反復(fù)修改，把控軟件測(cè)試質(zhì)量。進(jìn)一步發(fā)現(xiàn)更多的軟件問(wèn)題和深層次問(wèn)題。后續(xù)，筆者將繼續(xù)補(bǔ)充及改進(jìn)其中不完善之處，共同優(yōu)化軟件測(cè)試技術(shù)，提高測(cè)試質(zhì)量，增強(qiáng)核心競(jìng)爭(zhēng)力。

作者單位：羅文兵? ? 徐海波? ? 符號(hào)? ? 北京賽迪軟件測(cè)評(píng)工程技術(shù)中心有限公司

參? 考? 文? 獻(xiàn)

[1] 梅爾斯，張曉明.黃琳譯，軟件測(cè)試的藝術(shù) 第三版 [M]. 機(jī)械工業(yè)出版社，2018-08-01.

[2] 斯平內(nèi)利斯.趙學(xué)良譯，代碼閱讀方法與實(shí)踐[M]. 清華大學(xué)出版社，2010-01-01.

[3] 宮云戰(zhàn)，邢穎，肖慶.源代碼分析 [M].科學(xué)出版社，2022-01-01.

[4] 麥斯阿塞克，馬素霞譯.需求分析與系統(tǒng)設(shè)計(jì)[M] .機(jī)械工業(yè)出版社，2020-01-01.

[5] 黃震宇.軍用軟件工程 [M]. 電子工業(yè)出版社，2020-04-01.

[6] 李學(xué)仁.軍用軟件質(zhì)量管理學(xué) [M].國(guó)防工業(yè)出版社，2022-2-13.