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

羅文兵 徐海波 符號

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

關鍵詞：代碼;文檔;提取測試需求

一、研究問題的提出

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

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

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

二、研究思路及解決方法

（一）思路

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

（二） 方法

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

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

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

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

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

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

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

（三） 實踐

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

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

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

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

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

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

（四） 拓展

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

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

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

三、結束語

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

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

參? 考? 文? 獻

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

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

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

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

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

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