⑴ 軟體測試中代碼走讀是什麼意思
呼嚕抄King同志說的屬於一種「代碼走讀」的形式，但是更靠近「同行評審」。
實際上代碼走讀，沒有特別強的「細讀」或「詳解」的意思，主要是梗概性地過一遍代碼，主要檢查的內容包括：邏輯結構嵌套深度、注釋完整度、變數引用情況、程序的框架規范性、介面函數使用方式、代碼可測試性等，需要得到的結果就是：得到盡量符合組織定義的軟體開發規范的清晰代碼。
比如出現msgbox(dbgrid1.getstring(integer(myfunc1(sle_1.text))))之類的危險調用。
⑵ 優秀源代碼審核工具具有哪些特點
一.可理解性：
可理解性表明人們通過閱讀源代碼和相關文檔，了解程序功能及其如何運行的容易程度。
二.可靠性：
可靠性表明一個程序按照用戶的要求和設計目標，在給定的一段時間內正確執行的概率。
三.可測試性
可測試性表明論證程序正確性的容易程度。程序越簡單，證明其正確性就越容易。而且設計合用的測試用例，取決於對程序的全面理解。
一個可測試的程序應當是可理解的，可靠的，簡單的。
用於可測試性度量的檢查項目如下：
程序是否模塊化? 結構是否良好?
程序是否可理解? 程序是否可靠?
程序是否能顯示任意中間結果?
程序是否能以清楚的方式描述它的輸出?
程序是否能及時地按照要求顯示所有的輸入?
程序是否有跟蹤及顯示邏輯控制流程的能力?
程序是否能從檢查點再啟動?
程序是否能顯示帶說明的錯誤信息?
四.可修改性
可修改性表明程序容易修改的程度。
五.可移植性
可移植性表明程序轉移到一個新的計算環境的可能性的大小。或者它表明程序可以容易地、有效地在各種各樣的計算環境中運行的容易程度。
一個可移植的程序應具有結構良好、靈活、不依賴於某一具體計算機或操作系統的性能。
用於可移植性度量的檢查項目如下：
1.是否是用高級的獨立於機器的語言來編寫程序?
2.是否使用廣泛使用的標准化的程序設計語言來編寫程序? 是否僅使用了這種語言的標准版本和特性?
3.程序中是否使用了標準的普遍使用的庫功能和子程序?
4.程序中是否極少使用或根本不使用操作系統的功能?
六.效率
效率表明一個程序能執行預定功能而又不浪費機器資源的程度。
這些機器資源包括內存容量、外存容量、通道容量和執行時間。
用於效率度量的檢查項目如下：
程序是否模塊化? 結構是否良好?
是否消除了無用的標號與表達式，以充分發揮編譯器優化作用?
七.可使用性
從用戶觀點出發，可使用性定義為程序方便、實用、及易於使用的程度。一個可使用的程序應是易於使用的、能允許用戶出錯和改變，並盡可能不使用戶陷入混亂狀態的程序。
⑶ 如何編寫代碼才能使效率提高
一、排版：
1.關鍵詞和操作符之間加適當的空格。
2.相對獨立的程序塊與塊之間加空行
3.較長的語句、表達式等要分成多行書寫。
4.劃分出的新行要進行適應的縮進，使排版整齊，語句可讀。
5.長表達式要在低優先順序操作符處劃分新行，操作符放在新行之首。
6.循環、判斷等語句中若有較長的表達式或語句，則要進行適應的劃分。
7.若函數或過程中的參數較長，則要進行適當的劃分。
8.不允許把多個短語句寫在一行中，即一行只寫一條語句。
9.函數或過程的開始、結構的定義及循環、判斷等語句中的代碼都要採用縮進風格。
10.C/C++語言是用大括弧『{』和『}』界定一段程序塊的，編寫程序塊時『{』和
『}』應各獨佔一行並且位於同一列，同時與引用它們的語句左對齊。在函數體
的開始、類的定義、結構的定義、枚舉的定義以及if、for、do、while、
switch、case語句中的程序都要採用如上的縮進方式。
二、注釋
1.注釋要簡單明了。
2.邊寫代碼邊注釋，修改代碼同時修改相應的注釋，以保證注釋與代碼的一致性。
3.在必要的地方注釋，注釋量要適中。注釋的內容要清楚、明了，含義准確，防止
注釋二義性。保持注釋與其描述的代碼相鄰，即注釋的就近原則。
4.對代碼的注釋應放在其上方相鄰位置，不可放在下面。
5.對數據結構的注釋應放在其上方相鄰位置，不可放在下面；對結構中的每個域
的注釋應放在此域的右方；同一結構中不同域的注釋要對齊。
6.變數、常量的注釋應放在其上方相鄰位置或右方。
7.全局變數要有較詳細的注釋，包括對其功能、取值范圍、哪些函數或過程存取它
以及存取時注意事項等的說明。
8.在每個源文件的頭部要有必要的注釋信息，包括：文件名；版本號；作者；生成
日期；模塊功能描述（如功能、主要演算法、內部各部分之間的關系、該文件與其
它文件關系等）；主要函數或過程清單及本文件歷史修改記錄等。
9.在每個函數或過程的前面要有必要的注釋信息，包括：函數或過程名稱；功能描
述；輸入、輸出及返回值說明；調用關系及被調用關系說明等。
三、命名
1.較短的單詞可通過去掉「母音」形成縮寫；
2.較長的單詞可取單詞的頭幾發符的優先順序，並用括弧明確表達式的操作順序，避
免使用默認優先順序。
3.使用匈牙利表示法
四、可讀性
1.避免使用不易理解的數字，用有意義的標識來替代。
2.不要使用難懂的技巧性很高的語句。
3.源程序中關系較為緊密的代碼應盡可能相鄰。
五、變數
1.去掉沒必要的公共變數。
2.構造僅有一個模塊或函數可以修改、創建，而其餘有關模塊或函數只訪問的公共
變數，防止多個不同模塊或函數都可以修改、創建同一公共變數的現象。
3.仔細定義並明確公共變數的含義、作用、取值范圍及公共變數間的關系。
4.明確公共變數與操作此公共變數的函數或過程的關系，如訪問、修改及創建等。
5.當向公共變數傳遞數據時，要十分小心，防止賦與不合理的值或越界等現象發生。
6.防止局部變數與公共變數同名。
7.仔細設計結構中元素的布局與排列順序，使結構容易理解、節省佔用空間，並減
少引起誤用現象。
8.結構的設計要盡量考慮向前兼容和以後的版本升級，並為某些未來可能的應用保
留餘地（如預留一些空間等）。
9.留心具體語言及編譯器處理不同數據類型的原則及有關細節。
10.嚴禁使用未經初始化的變數。聲明變數的同時對變數進行初始化。
11.編程時，要注意數據類型的強制轉換。
六、函數、過程
1.函數的規模盡量限制在200行以內。
2.一個函數最好僅完成一件功能。
3.為簡單功能編寫函數。
4.函數的功能應該是可以預測的，也就是只要輸入數據相同就應產生同樣的輸出。
5.盡量不要編寫依賴於其他函數內部實現的函數。
6.避免設計多參數函數，不使用的參數從介面中去掉。
7.用注釋詳細說明每個參數的作用、取值范圍及參數間的關系。
8.檢查函數所有參數輸入的有效性。
9.檢查函數所有非參數輸入的有效性，如數據文件、公共變數等。
10.函數名應准確描述函數的功能。
11.避免使用無意義或含義不清的動詞為函數命名
12.函數的返回值要清楚、明了，讓使用者不容易忽視錯誤情況。
13/明確函數功能，精確（而不是近似）地實現函數設計。
14.減少函數本身或函數間的遞歸調用。
15.編寫可重入函數時，若使用全局變數，則應通過關中斷、信號量（即P、V操作）
等手段對其加以保護。
七、可測性
1.在編寫代碼之前，應預先設計好程序調試與測試的方法和手段，並設計好各種調
測開關及相應測試代碼如列印函數等。
2.在進行集成測試/系統聯調之前，要構造好測試環境、測試項目及測試用例，同時
仔細分析並優化測試用例，以提高測試效率。
八、程序效率
1.編程時要經常注意代碼的效率。
2.在保證軟體系統的正確性、穩定性、可讀性及可測性的前提下，提高代碼效率。
3.不能一味地追求代碼效率，而對軟體的正確性、穩定性、可讀性及可測性造成影
響。
4.編程時，要隨時留心代碼效率；優化代碼時，要考慮周全。
5.要仔細地構造或直接用匯編編寫調用頻繁或性能要求極高的函數。
6.通過對系統數據結構劃分與組織的改進，以及對程序演算法的優化來提高空間效率。
7.在多重循環中，應將最忙的循環放在最內層。
8.盡量減少循環嵌套層次。
9.避免循環體內含判斷語句，應將循環語句置於判斷語句的代碼塊之中。
10.盡量用乘法或其它方法代替除法，特別是浮點運算中的除法。
九、質量保證
1.在軟體設計過程中構築軟體質量。
代碼質量保證優先原則
（1）正確性，指程序要實現設計要求的功能。
（2）穩定性、安全性，指程序穩定、可靠、安全。
（3）可測試性，指程序要具有良好的可測試性。
（4）規范/可讀性，指程序書寫風格、命名規則等要符合規范。
（5）全局效率，指軟體系統的整體效率。
（6）局部效率，指某個模塊/子模塊/函數的本身效率。
（7）個人表達方式/個人方便性，指個人編程習慣。
2.只引用屬於自己的存貯空間。
3.防止引用已經釋放的內存空間。
4.過程/函數中分配的內存，在過程/函數退出之前要釋放。
5.過程/函數中申請的（為打開文件而使用的）文件句柄，在過程/函數退出前要關閉。
6.防止內存操作越界。
7.時刻注意表達式是否會上溢、下溢。
8.認真處理程序所能遇到的各種出錯情況。
9.系統運行之初，要初始化有關變數及運行環境，防止未經初始化的變數被引用。
10.系統運行之初，要對載入到系統中的數據進行一致性檢查。
11.嚴禁隨意更改其它模塊或系統的有關設置和配置。
12.不能隨意改變與其它模塊的介面。
13.充分了解系統的介面之後，再使用系統提供的功能。
14.要時刻注意易混淆的操作符。當編完程序後，應從頭至尾檢查一遍這些操作符。
15.不使用與硬體或操作系統關系很大的語句，而使用建議的標准語句。
16.建議：使用第三方提供的軟體開發工具包或控制項時，要注意以下幾點：
（1）充分了解應用介面、使用環境及使用時注意事項。
（2）不能過分相信其正確性。
（3）除非必要，不要使用不熟悉的第三方工具包與控制項。
十、代碼編譯
1.編寫代碼時要注意隨時保存，並定期備份，防止由於斷電、硬碟損壞等原因造成
代碼丟失。
2.同一項目組內，最好使用相同的編輯器，並使用相同的設置選項。
3.合理地設計軟體系統目錄，方便開發人員使用。
4.打開編譯器的所有告警開關對程序進行編譯。
5.在同一項目組或產品組中，要統一編譯開關選項。
6.使用工具軟體（如Visual SourceSafe）對代碼版本進行維護。
十一、代碼測試、維護
1.單元測試要求至少達到語句覆蓋。
2.單元測試開始要跟蹤每一條語句，並觀察數據流及變數的變化。
3.清理、整理或優化後的代碼要經過審查及測試。
4.代碼版本升級要經過嚴格測試。