代碼結(jié)合文檔提取測試需求方法的研究

羅文兵 徐海波 符號

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

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

一、研究問題的提出

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

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

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

二、研究思路及解決方法

（一）思路

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

（二） 方法

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

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

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

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

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

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

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

（三） 實踐

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

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

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

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

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

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

（四） 拓展

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

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

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

三、結(jié)束語

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

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

參? 考? 文? 獻

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

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

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

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

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

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