【正文】 函數(shù)頭部 的注釋 90 對變量、常量的注釋 94 對代碼的功能、意圖進(jìn)行注釋 95 標(biāo)識符 96 標(biāo)識符的命名 96 變量的命名 96 標(biāo)識符的命名 100 不要使用難懂的語句 101 明確公共變量與操作此公共變量的函數(shù)或過程的關(guān)系 102 使用嚴(yán)格形式定義的、可移植的數(shù)據(jù)類型 102 不要設(shè)計(jì)面面俱到、非常靈活的數(shù)據(jù)結(jié)構(gòu) 103 結(jié)構(gòu)中元素的個(gè)數(shù)應(yīng)適中 106 減少沒有必要的數(shù)據(jù)類型默認(rèn)轉(zhuǎn)換與強(qiáng)制轉(zhuǎn)換 106 合理地設(shè)計(jì)數(shù)據(jù)并使用 自定義數(shù)據(jù)類型 107 使用函數(shù)的錯(cuò)誤返回碼 108 防止將函數(shù)的 參數(shù)作為工作變量 112 函數(shù)名應(yīng)準(zhǔn)確描述函數(shù)的功能 114 減少函數(shù)本身或函數(shù)間 的遞歸調(diào)用 115 改進(jìn)模塊中函數(shù)的結(jié)構(gòu)，降低函數(shù)間的耦合度 115 注意函數(shù)可重入性的構(gòu)造 117 使用 斷言來發(fā)現(xiàn)軟件問題 117 使用斷言檢查非法情況 118 用斷言對程序開發(fā)環(huán)境的假設(shè)進(jìn)行檢查 123 留心代碼效率 123 提高空間效率 124 盡量減少循環(huán)嵌套層次 126 將宏所定義的多條表達(dá)式放在大括號中 128 內(nèi)存的釋放 131 不要濫用 goto 語句。131 提高軟件的可移植性和可重用性 132 精心構(gòu)造算法，并對其性能、效率進(jìn)行測試 132 使用變量時(shí)要注意其邊界值的情況 134 代碼編輯、編譯、審查 134 對代碼進(jìn)行檢查 134 對代碼進(jìn)行抽查及評審 134 慎重使用塊拷貝功能編程 135 合理地設(shè)計(jì)軟件系統(tǒng)目錄 135 對告警信息的處理 135 對代碼進(jìn)行審查 136 清理、整理或優(yōu)化后的代碼要經(jīng)過審查及測試 136 使用工具軟件對代碼版本進(jìn)行維護(hù) 136 正式版本上軟件的任何修改都應(yīng)有詳細(xì)的文檔記錄 136 發(fā)現(xiàn)錯(cuò)誤立即修改，并且要記錄下來 137 軟件測試技術(shù)與質(zhì)量保證 10 第一章 軟件測試技術(shù) 為了保證軟件的質(zhì)量和可靠性，人們力求在分析、設(shè)計(jì)等各個(gè)開發(fā)階段結(jié)束之前，對軟件進(jìn)行嚴(yán)格的技術(shù)評審。但到那時(shí)，不僅改正這些錯(cuò)誤的大家更高，而且往往造成很惡劣的后果。 軟件測試在軟件生存期中橫跨兩個(gè)階段：通常在編寫出每一個(gè)模塊之后就對它作單元測試。顯然，我們應(yīng)該站在用戶的角度，替他們設(shè)想，就應(yīng)當(dāng)把測試活動(dòng)的目標(biāo)對準(zhǔn)揭露程序中存在的錯(cuò)誤。 這幾句話的意思就是說，設(shè)計(jì)測試的目標(biāo)是以最少的時(shí)間和人力系統(tǒng)地找出軟件中潛在的各種錯(cuò)誤和缺陷。這里，特別需要說明的是，測試不能表明軟件中不存在錯(cuò)誤，它只能說明軟件中存在錯(cuò)誤。 2．測試用例應(yīng)由測試輸入數(shù)據(jù)和與之對應(yīng)的預(yù)期輸出結(jié)果這兩部分組成。（注意不是指對程序的調(diào)試） 程序員應(yīng)盡可能避免測試自己編寫的程序，程序開發(fā)小組也應(yīng)盡可能避免測試本小組開發(fā)的程序。另外，程序員對軟件規(guī)格說明理解錯(cuò)誤而引入的錯(cuò)誤則更難發(fā)現(xiàn)。 所謂合理的輸入條件是指能驗(yàn)證程序正確的輸入條件，而不合理的輸入條件是指異常的、臨界的、可能引起問題變異的輸入條件。 5．充分注意測試中的群集現(xiàn)象。 軟件測試技術(shù)與質(zhì)量保證 12 6．嚴(yán)格執(zhí)行測試計(jì)劃，排除測 試的隨意性。所以必須對預(yù)期的輸出結(jié)果明確定義，對實(shí)測的結(jié)果仔細(xì)分析檢查，抓住征兆，暴露錯(cuò)誤。 ? 白盒測試： 已知產(chǎn)品的內(nèi)部工作過程，可以通過測試來證明每種內(nèi)部操作是否符合設(shè)計(jì)規(guī)格要求，所有內(nèi)部成分是否已經(jīng)過檢查。 黑盒測試主要是為了發(fā)現(xiàn)以下幾類錯(cuò)誤： ? 是否有不正確或遺漏的功能？ ? 在接口上，輸入是否能正確的接受？能否輸出正確的結(jié)果？ ? 否有數(shù)據(jù) 結(jié)構(gòu)錯(cuò)誤或外部信息（例如數(shù)據(jù)文件）訪問錯(cuò)誤？ ? 能上是否能夠滿足要求？ ? 否有初始化或終止性錯(cuò)誤？ 軟件的白盒測試是對軟件的過程性細(xì)節(jié)做細(xì)致的檢查。 白盒測試主要是想對程序模塊進(jìn)行如下檢查： ? 對程序模塊的所有獨(dú)立的執(zhí)行路徑至少測試一遍。 以上事實(shí)說明，軟件測試有一個(gè)致命的缺陷，即測試的不完全、不徹底性。因此，大型軟件系統(tǒng)的測試基本上由下述 4個(gè)步驟組成：單元測試、集成測試、 確認(rèn)測試和系統(tǒng)測試。 1．目的與任務(wù) 目的：通過對象模塊的靜態(tài)分析與動(dòng)態(tài)測試，使其代碼達(dá)到模塊說明書的需求。接下來的兩步仍 然是靜態(tài)分析，不過檢查對象已從語法錯(cuò)誤改變?yōu)橐越Y(jié)構(gòu)性錯(cuò)誤為主的其他錯(cuò)誤。 20世紀(jì) 70年代以來，已有許多靜態(tài)分析器投入使用，并獲得成功。根據(jù)程序的實(shí)際情況，可采用白盒測試或黑盒測試方法。 3．代碼評審 如前所述，代碼評審在編 譯之后，動(dòng)態(tài)測試以前進(jìn)行。眾所周知，動(dòng)態(tài)測試僅能發(fā)現(xiàn)錯(cuò)誤的癥狀，而代碼評審一旦發(fā)現(xiàn)錯(cuò)誤，就同時(shí)確定了錯(cuò)誤的位置。另一類以小組會的方式進(jìn)行，又可分“走查（ Walk Through）”和“代碼會審（ Code Inspection）”兩種，適用于各種規(guī)模的程序，具體作法不再贅述，有興趣者可參看有關(guān)書籍。代替上級模塊的稱為測試驅(qū)動(dòng)模塊（ Test Driver），代替下級模塊的稱為測試樁模塊（ Test Stub）。在組裝過程中進(jìn)行的測試，就稱為集成測試或組裝測試。 ? 多模塊程序中各模塊之間，可能有比較復(fù)雜的接 口，稍有疏忽就易出錯(cuò)。 軟件測試技術(shù)與質(zhì)量保證 15 1．目的與任務(wù) 目的： 將經(jīng)過單元測試的模塊逐步組裝成具有良好一致性的完整程序。二者的選擇，應(yīng)有利于揭露在接口關(guān)系、訪問全局性數(shù)據(jù)（包括公用文件與數(shù)據(jù)結(jié)構(gòu)）、模塊調(diào)用序列和出錯(cuò)處理等方面存在的隱患。它通常是已經(jīng)進(jìn)行過的測試的一個(gè)子集。按照移動(dòng)路線的差異，又可區(qū)分兩種不同的實(shí)施步驟。圖 配置情況。其典型步驟可以描述為： ① 從下層模塊中找出一個(gè)沒有下級模塊的模塊，由下向上地逐步添加新模塊，組成程序中的一個(gè)子系統(tǒng)或模塊群； ② 從另一子系統(tǒng)或群中選出另一個(gè)無下級模塊的模塊，仿照前一步組成又一 M2 M3 M4 M5 M6 M8 M7 M1 軟件測試技術(shù)與質(zhì)量保證 16 個(gè)子系統(tǒng)； ③ 重復(fù)上一步，直到得出所有的子系統(tǒng)，把它們組裝 為完整的程序。 為了保證測試的質(zhì)量，集成測試應(yīng)由獨(dú)立于開發(fā)人員的測試小組負(fù)責(zé)實(shí)施。由底向上測試從下層模塊開始，設(shè)計(jì)測試用 例比較容易，但是在測試的早期不能顯示出程序的輪廓。 確認(rèn)測試 1．有效性測試（黑盒測試）和配置復(fù)審 確認(rèn)測試?yán)^集成測試之后進(jìn)行，其目的在于確認(rèn)組裝完畢的程序是否滿足軟件需求規(guī)格說明書（ SRS）的要求。 確認(rèn)測試是由軟件開發(fā)單位組織實(shí)施的最后一項(xiàng)開發(fā)活動(dòng)。 2．驗(yàn)收測試 如果軟件是給一個(gè)客戶開發(fā)的，需要進(jìn)行一系列的驗(yàn)收測試來保證滿足客戶所有的需求。 Alpha測試是在一個(gè)受控的環(huán)境下，由用戶在開發(fā)者的“指導(dǎo)”下進(jìn)行的測試，由開發(fā)者負(fù)責(zé)紀(jì)錄錯(cuò)誤和使用中出現(xiàn)的問題。除被測程序外，系統(tǒng)還可能包括硬件和原來就有的其它軟件。 終止測試的標(biāo)準(zhǔn) 黑盒測試和白盒測試都是選擇測試，不可能徹底發(fā)現(xiàn)程序的所有錯(cuò)誤。滿足了這些條件就可終止測試。例如，假定被測程序是一個(gè)約有 10000行的管理信息系統(tǒng)，根據(jù)以往的經(jīng)驗(yàn)，這么多行的程序約有 300個(gè)設(shè)計(jì)錯(cuò)誤和 200個(gè)代碼與結(jié)構(gòu)錯(cuò)誤。 1．等價(jià)分類法 所謂等價(jià)分類，就是把輸入數(shù)據(jù)的可能值劃分為若干等價(jià)類，使每類中的任何一個(gè)測試用例，都能代表同一等價(jià)類中的其他測試用例。 2．邊界值分析法 實(shí)踐表明，程序員在處理邊界情況時(shí)，很容易因疏忽或考慮不周發(fā)生編碼錯(cuò)誤