檢查問題報告

開篇：寫作不僅是一種記錄，更是一種創造，它讓我們能夠捕捉那些稍縱即逝的靈感，將它們永久地定格在紙上。下面是小編精心整理的12篇檢查問題報告，希望這些內容能成為您創作過程中的良師益友，陪伴您不斷探索和進步。

第1篇

關鍵詞：軟件代碼審查；代碼審查過程；代碼審查問題

中圖分類號：TP311.52文獻標識碼：A文章編號：1007-9599 (2012) 03-0000-02

Discussion on the Code Review of Software Static Testing

Yuan Zhengjiang

(Jiangnan Institute of Electrical and Mechanical Design,Guiyang550009,China)

Abstract:This paper describes the software code to examine the role,content,code review process,and lists some common problems of code review.

Keywords:Software code review;Code review process;Code review problem

一、引言

軟件測試常用方法可分為動態測試和靜態測試，只有動態測試和靜態測試有效結合，才能更好的完成軟件測試工作。代碼審查是軟件靜態測試中常用的軟件測試方法之一，代碼審查時，只要測試人員方法得當、足夠細心，往往能夠產生意想不到的效果。

二、代碼審查的作用

代碼審查是在不執行軟件的條件下有條理的仔細審查軟件代碼，從而找出軟件缺陷的過程。

代碼審查可以找出動態測試難以發現或隔離的軟件缺陷。在開發過程初期讓測試人員集中精力進行軟件代碼審查非常有價值：可以提高代碼質量；在項目的早期發現缺陷，將損失降至最低；促進團隊溝通、促進知識共享、共同提高。

代碼審查還可以為動態測試時設計和執行測試用例提供思路。通過代碼審查，可以確定有問題或者容易產生軟件缺陷的特性范圍。

三、代碼審查的過程

代碼審查過程可分為：代碼審查策劃階段、代碼審查實施階段以及代碼審查總結階段。

（一）代碼審查策劃階段

1.項目負責人分配代碼審查任務；

2.確定代碼審查策略：依據軟件開發文檔，確定軟件關鍵模塊，作為代碼審點；將復雜度高的模塊也作為代碼審查的重點；

3.項目負責人確定代碼審查單，審查內容一般可包括：

（1）可追溯性：

――代碼是否遵循詳細設計？

――代碼是否與需求一致？

（2）邏輯：

――表示優先級的括號用法是否正確？

――代碼是否依賴賦值順序？

――“if…else”和“switch”使用是否正確清晰？

――循環能否結束？

――復合語句是否正確地被花括號括起來？

――case語句是否所有可能出現的情況均已考慮？

――“goto”是否使用？

（3）數據：

――變量在使用前是否已初始化？

――變量的聲明是否按組劃分為外部的和內部的？

――除最明顯的聲明外，是否所有聲明都有注釋？

――每個命名是否僅用于一個用途？

――常量名是否都大寫？

――常量是否都是通過“#define”定義的？

――用于多個文件中的常量是否在一個頭文件中定義？

――頭文件中是否存在可執行的代碼？

――定義為指針的變量是否作為指針使用（而不是作為整數）？

――指針是否初始化？

――釋放內存后是否將指針立即設置為NULL（或0）？

――傳遞指針到另一個函數的代碼是否首先檢查了指針的有效性？

――通過指針寫入動態分配內存的代碼是否首先檢查了指針的有效性？

――宏的命名是否都大寫？

――數組是否越界？

（4）接口：

――在所有的函數及過程調用中，參數的個數都正確嗎？

――形參與實參類型匹配嗎？

――參數順序正確嗎？

――如果訪問共享內存，是否具有相同的共享內存結構模式？

（5）文檔：

――軟件文檔是否與代碼一致？

（6）注釋：

――注釋與代碼是否一致？

――用于理解代碼的注釋是否提供了必要的信息？

――是否對數組和變量的作用進行了描述？

（7）異常處理：

――是否所有可能的錯誤都已加以考慮？

（8）內存：

――在向動態分配的內存寫入之前是否檢查了內存申請是否成功？

――若采用動態分配內存，內存空間分配是否正確？

――當內存空間不再需要時，是否被明確的釋放？

（9）其它：

――是否檢查了函數調用返回值？

――所有的輸入變量都用到了嗎？

――所有的輸出變量在輸出前都已賦值了嗎？

4.確定代碼審查進度安排，項目負責人負責安排代碼審查的進度。

（二）代碼審查實施階段

1.代碼講解：軟件開發人員詳細向測試人員講解如何以及為何這樣實現，測試人員提出問題和建議。通過代碼講解，測試人員對被審查的軟件有了一個全面的認識，為后續代碼審查打下良好的基礎。

2.靜態分析：一般采用靜態分析工具進行，主要分析軟件的代碼規模、模塊數、模塊調用關系、扇入、扇出、圈復雜度、注釋率等軟件質量度量元。靜態分析在代碼審查時應優先進行，有利于軟件測試人員在后續代碼審查時對軟件建立宏觀上認識，在審查中容易做到有的放矢，更易于發現軟件代碼中的缺陷。

3.規則檢查：采用靜態分析工具對源程序進行編碼規則檢查，對于工具報出的問題再由人工進行進一步的分析以確認軟件問題，是一種比較有效的方法。

4.正式代碼審查：代碼審查可分兩步進行：獨立審查和會議審查。根據情況，這兩步可以反復進行多次。

（1）獨立審查：測試人員根據項目負責人的工作分配，獨自對自己負責的軟件模塊進行代碼審查。測試人員根據代碼審查單，對相關代碼進行閱讀、理解和分析后，記錄發現的錯誤和疑問。

（2）會議審查：項目負責人主持召開會議，測試人員和開發人員參加；測試人員就獨立審查發現的問題和疑問與開發人員溝通，并討論形成一致意見；對發現的問題匯總，填寫軟件問題報告單，提交開發人員處理。

5.更改確認：開發人員對問題進行處理，代碼審查人員對軟件的處理情況進行確認，驗證更改的正確性，并防止出現新的問題。

（三）代碼審查總結階段

代碼審查工作結束后，項目負責人總結代碼審查結果；編寫測試報告，對軟件代碼質量進行評估，給出合理建議。

把代碼審查提出的所有問題、亮點及最終結論詳細的記錄下來，供其他軟件項目代碼審查借鑒。必要時，可建立常見軟件代碼缺陷數據庫，為軟件代碼審查人員培訓和執行代碼審查提供數據支持，也可以為軟件編碼規則制定規范提供實踐依據。

四、代碼審查中的常見問題

如果軟件測試人員熟悉常見的軟件代碼審查問題，對代碼審查效率是很有幫助的。筆者根據自己的應驗，列舉部分常見軟件代碼審查問題如下（僅供參考）：

（1）浮點數相等比較：可能造成程序未按設計的路徑執行；

（2）因設計原因導致某些代碼不能執行：如邏輯表達式永遠為真（或假）造成某分支不能執行、代碼前面有return語句、某模塊從未被調用等；

（3）switch語句沒有break語句（有意如此設計時除外）；

（4）數組越界使用：數組越界容易發生在數組下標是計算得到的情況下，而且審查時很難發現這種代碼缺陷，應加以重視；

（5）變量未初始化就使用或者是條件賦值就使用；

（6）程序中存在未使用的多余變量；

（7）復合邏輯表達式沒有使用括號造成運算順序錯誤；

（8）有返回值的函數中return沒有帶返回值；

（9）邏輯判別的表達式不是邏輯表達式；

（10）動態分配的內存沒有及時釋放：忘記寫內存釋放代碼或由于其它邏輯缺陷導致內存釋放代碼未得到執行；

（11）沒有對緩沖區溢出進行必要的防護；

（12）訪問空指針，即指針未初始化就使用；

（13）指針指向的內存釋放后，未將指針置為NULL：其它函數訪問該指針時，判斷指針不為空，當作有效指針使用，會造成內存訪問錯誤；

（14）注釋說明與程序代碼實現不一致，甚至相反；

（15）循環存在不能跳出的可能，程序中沒有相應的保護機制。

五、結束語

第2篇

[關鍵詞]項目管理軟件需求開發進度成本質量管理模型

一、引言

軟件需求開發是軟件工程的一個重要環節，在軟件生命周期中的需求、設計、編碼、測試和維護等各個階段中，需求開發處于軟件工程的開始部分，它提供構建軟件項目的根基，決定軟件開發成果滿足客戶需求的匹配程度。軟件需求開發環節的失誤會隨著開發進度的擴大而蔓延，資料表明，軟件項目中由于需求開發管理混亂而造成的返工開銷幾乎占了總開發的50％。本文應用項目管理理論分析軟件需求開發階段的系統構成，并設計管理模型來提高軟件需求開發的管理效率。

二、軟件需求開發管理過程

由于計算機技術的迅速發展，使得軟件需求具有模糊性、不確定性、變化性、主觀性等特點，并帶來軟件需求開發管理的復雜性。軟件需求開發是一定的組織利用有限的資源在規定的時間內完成，可以作為項目來進行管理，其管理過程由需求獲取、需求分析、編寫軟件需求規格和需求驗證四個階段構成。

1.需求獲取

需求獲取是在問題和最終解決方案之間架設橋梁，其主要任務是和用戶方的領導層、業務層人員進行溝通，獲取用戶的具體需求，并了解用戶的組織架構、業務流程、硬件環境、軟件環境、現有的運行系統等具體情況，同用戶建立起良好的溝通渠道和方式。軟件需求獲取的方法有：與用戶交談，向用戶提問題；參觀用戶的工作流程，觀察用戶的操作；用戶工作的情景分析；現有系統的問題報告和改進要求，事件和響應；市場調查和向用戶群體發調查問卷；與同行、專家交談，聽取他們的意見；分析已經存在的同類軟件產品，提取需求；從現有產品或競爭產品的文檔中提取需求；從行業標準、規則中提取需求；從Internet上搜查相關資料等。

2.需求分析

需求分析主要通過建立業務模型的方式來描述用戶的功能需求，為客戶、用戶、開發方等不同參與者提供一個交流的渠道。業務模型可以映射出軟件產品的核心需求，即功能需求。功能需求應描述軟件提供的功能和服務、對輸入的響應，并描述特定條件下的系統構成等。軟件產品本身可能還存在與業務無直接關系的非功能需求，具體與系統的總體特性有關，如可靠性、響應時間、存儲空間等。非功能需求定義系統提供服務或功能的約束，包括時間約束、空間約束、開發過程約束及應遵循的標準等。通常這兩類需求構成軟件需求的總集。

3.編制軟件需求規格

軟件需求規格的編制是為了使用戶和軟件開發者雙方對該軟件的初始規定有一個共同的理解，使之成為整個開發工作的基礎，需求分析完成的標志就是提交一份完整的軟件需求規格說明書。軟件需求規格說明書以一種開發人員可用的技術形式闡述軟件必須提供的功能和具備的性能，以及必須考慮的限制條件。軟件項目客戶通過軟件需求規格了解軟件項目能夠提供的軟件產品，檢查軟件需求是否滿足需要；項目管理人員根據軟件需求規格制定項目的開發計劃和管理過程；軟件開發人員通過軟件需求規格理解要開發的產品及具體要開發的內容；軟件測試人員通過軟件需求規格驗證軟件。

4.需求評審

編寫的軟件需求規格說明書還應當進行需求評審，確保需求確定的科學性。可采用下列指標進行評審：(1)正確性:每條需求都正確代表構建軟件系統所要完成的事情。(2)無歧義:每條需求只有一種解釋。(3)完備性:需求不能發生遺漏，應全面考慮相關問題。(4)一致性:用戶需求必須和業務需求一致，功能需求必須和用戶需求一致。(5)重要性和穩定性分級:現有資源不足以實現所有需求時，可以根據級別的高低決定實現的先后，舍棄一些級別低的需求以保證項目的按期交付。(6)可驗證性:需求分析是可測試的，只有系統的所有需求都是可以被測試的，才能夠保證軟件始終圍繞著用戶的需要，保證軟件系統是成功的。(7)可修改性:每一條需求都易于完整一致的進行變更，且不改變需求集的結構和風格。(8)可跟蹤性:每條需求都是可溯源的，且存在一種機制使得在以后的工作中引用需求是可行的。(9)可理解性:用戶和開發人員都完全理解需求集的整體行為、所提供的功能及其中的每條需求的含義。

三、軟件需求開發管理模型

1.軟件需求開發管理模型構建原則

軟件需求開發是一項復雜的系統工程，管理模型的構建應遵循下列原則:(1)程序性原則：軟件需求開發管理應遵循固定的業務流程，可將其劃分為需求獲取、需求分析、編寫軟件需求規格和需求驗證四個階段，前一階段的工作完成后才能進入下一階段。(2)系統性原則：軟件需求開發要在限定的時間、成本條件約束下達到一定的質量，實現軟件系統的最優，要求管理遵循系統管理原則，實現目標最優。(3)簡化性原則：化繁為簡，將模糊的、潛在的復雜問題明確化，以圖表的形式表示出，并以簡化的解決方案解決問題，便于項目管理。(4)平衡性原則：管理軟件需求開發的具體事務要有一定的側重。對于需求開發過程事項，應根據影響大小分清主次，關鍵的事項或者事項里的某個多發問題點，著重管理，達到在管理上的主次平衡。(5)高效性原則:模型的設計必須以促進需求開發目標的實現為前提，提供給相關人員一個展示需求開發管理和有效解決方案的平臺。（6）時時控制性原則:及時控制需求開發過程中影響進度、成本、質量等問題，及時發現解決沖突事件，做到事前、事中、事后控制，保證項目按時保質保量完成。(7)動態性原則:開發中應關注信息技術的發展，將先進的技術應用到軟件需求開發中，并學習借鑒相關軟件需求開發的成果。

2．軟件需求開發管理模型

基于以上分析，本文構建了軟件需求開發管理模型，見下圖：

該模型遵循了軟件需求開發的管理流程。啟動階段，軟件開發進行了可行性研究，軟件項目已立項，項目正式啟動。軟件需求開發管理階段是模型的主要部分，按照項目流程，依次劃分為需求獲取、需求分析、編寫軟件需求規格和需求驗證四個階段。總結階段，對軟件需求開發管理進行總結，并進入到軟件程序設計階段。模型的核心部分是應用項目管理的進度管理、成本管理、質量管理，對軟件需求開發進行動態管理。進度管理就是制定出經濟合理的進度計劃，然后在計劃執行過程中，檢查實際進度與計劃進度之間的差異，并及時找出出現差異的原因，采取有效的補救措施，以確保項目按時按質完成。進度管理應加強溝通，掌握可能延誤進度的環節，并嚴格控制進度變更。成本管理就是對項目所需的成本情況進行詳細地分析和估算，編制資源需求計劃，并編制項目所需的成本估算和預算，在執行過程中，采取相應的措施對項目成本進行控制。成本管理應嚴格控制加班、浪費等額外支出。質量管理是為了保證項目的可交付成果能夠滿足客戶的需求，圍繞項目質量而進行的計劃、協調和控制等活動，其具體內容涉及質量規劃、實施質量保證和質量控制。通過進度管理、成本管理和質量管理，使軟件需求開發成為進度快、成本低和質量合格的有機統一體。

該模型規范了軟件需求開發的業務流程，并在整個軟件需求開發的不同環節之間建立聯系，明確需求開發過程與自身各任務項之間以及項目其余環節所存在的各種聯系。模型各環節間的相關性、可追溯性保證了軟件項目需求開發過程，可以遵循統一的管理模式。該模型具備可配置性。每個軟件項目，都具有個性化管理需求，在進度管理、成本管理、質量管理等方面有不同的要求，可以針對具體的開發團隊，項目要求，管理側重點，擴增相應的管理模塊，將此模型推廣到任何一個軟件需求開發項目。

3.模型應用

由于軟件需求開發具有復雜性，其主要表現為需求描述問題，明確表達需求較難確定，并且難以統一；需求完備問題，需求沒有遺漏，難以準確劃定系統范圍；需求的變更問題，需求變化是永恒，需求不可能是完備。模型應用需做好以下工作：（1）文檔化管理。需求必須有文檔來記錄，該文檔必須是正確的，是經過驗證的，是在受控的狀態下變更的。開發或管理人員常常會在含糊的情況下把認為是相對簡單的需求忽視而省略文檔記錄，其實未必簡單，只有想清楚、寫清楚、說清楚才說明已經真正把需求整理清楚了，同時方便日后維護工作的展開。需求含糊的情況下要進行會議形式處理，并邀請相關人員參加進行需求澄清及確定，需求在進行多方確定后進行歸檔。同時軟件需求的復用率也是相當高的，可以避免升級時重新將需求再次獲取，只需要在原來的基礎上作為文擋需求復用升級處理。（2）審核評估需求變更，減少變更的影響。在管理軟件開發過程中，需求漸變是必然的，無論需求變化的程度如何，只要需求變更就必須進行評估。在需求變更之前必須由項目管理人員審核，再傳給開發人員進行評估等工作。管理人員必需依據對整套系統的了解程度分析需求變更過程中可能受影響的系統及受關聯的功能模塊，并制定積極應對措施。(3)整體管理。應識別、確定、結合、統一與協調軟件需求開發管理過程中所需要進行的各種過程和活動，保證進度、成本、質量等各要素的相互協調。

四、結語

軟件需求開發在軟件項目管理中具有重要地位。本文應用項目管理理論，設計了軟件需求開發管理模型。該模型遵循項目管理流程，將軟件需求開發劃分啟動、需求開發過程、總結三個階段，并將軟件需求開發過程劃分為需求獲取、需求分析、編寫軟件需求規格和需求驗證四個階段，模型應用項目管理的進度管理、成本管理、質量管理，對軟件需求開發進行動態管理，實現軟件需求開發項目目標最優。該模型能夠提高軟件需求開發管理效率，確保軟件開發能夠按進度，低成本，高質量地完成。

參考文獻：

[1]景慎艷:軟件項目需求管理的探索與實踐[J].電腦知識與技術，2008（27）

[2]左懷遠:軟件項目中的風險管理研究[J].世界科技研究與發展，2008（3）

[3]孫琦龍:加強軟件項目管理的實踐模式[J].科技信息，2008（7）