軟件測試資料

1 目錄 一 軟件測試 從零開始 . 6 1 1 引言 . 6 1 2 測試準(zhǔn)備工作 . 6 1 2 1 向有經(jīng)驗(yàn)的測試人員學(xué)習(xí) . 6 1 2 2 閱讀軟件測試的相關(guān)書籍 . 7 1 2 3 走讀缺陷跟蹤庫中的問題報(bào)告單 . 7 1 2 4 走讀相關(guān)產(chǎn)品的歷史測試用例 . 7 1 2 5 學(xué)習(xí)產(chǎn)品相關(guān)的業(yè)務(wù)知識 . 7 1 3 識別測試需求 . 8 1 3 1 主動(dòng)獲取需求 . 8 1 3 2 確認(rèn)需求 的優(yōu)先級 . 9 1 3 3 加入開發(fā)小組的郵件群組 . 9 1 3 4 與開發(fā)人員為鄰 . 9 1 4 測試用例設(shè)計(jì) . 9 1 4 1 測試用例的基本格式 . 9 1 4 2 重用同類型項(xiàng)目的測試用例 . 10 1 4 3 利用已有的軟件 Checklist . 10 1 4 4 加強(qiáng)測試用例的評審 . 11 1 4 5 定義測試用例的執(zhí)行順序 . 11 1 5 測試用例執(zhí)行 . 11 1 5 1 搭建軟件測試環(huán)境，執(zhí)行測試用例 . 11 1 5 2 測試執(zhí)行過程應(yīng)注意的問題 . 12 1 5 3 及時(shí)更新測試用例 . 12 1 5 4 提交一份優(yōu)秀的問題報(bào)告單 . 13 1 6 測試結(jié)果分析 . 13 1 7 總結(jié) . 14 二 軟件測試的常識 . 14 2 1 引言 . 14 2 2 軟件測試常識 . 14 2 2 1 測試是不完全的（測試不完全） . 14 2 2 2 測試具有免疫性（軟件缺陷免疫性） . 15 2 2 3 測試是 “ 泛型概念 ” （全程測試） . 15 2 2 4 80-20 原則 . 15 2 2 5 為效益而測試 . 16 2 2 6 缺陷的必然性 . 16 2 2 7 軟件測試必須有預(yù)期結(jié)果 . 16 2 2 8 軟件測試的意義 - 事后分析 . 16 2 2 9 結(jié)論： . 16 三 淺談軟件開發(fā)中的注意事項(xiàng) . 17 3 1 項(xiàng)目設(shè)計(jì) . 17 3 2 設(shè)計(jì)變化和需求變化 . 17 3 3 代碼編寫 . 18 2 3 3 1 源程序文件結(jié)構(gòu) . 18 3 3 2 界面設(shè)計(jì)風(fēng)格的一致性 . 18 3 3 3 編輯風(fēng)格 . 18 3 3 4 命名規(guī)范 . 19 3 4 BUG修補(bǔ) . 19 3 5 開發(fā)人員的測試 . 19 四 軟件測試的若干問題 . 20 4 1 前言 . 20 4 2 博弈的各方 . 20 4 3 測試的過程 . 21 4 4 測試所具備的素質(zhì) . 21 4 5 自動(dòng)化測試 . 21 4 6 測試的誤區(qū) . 22 五 淺談功能測試用例模板設(shè)計(jì) . 22 5 1 Excel 模版 . 22 5 2 測試用例狀態(tài)轉(zhuǎn)換分析 . 24 六 如何提高軟件 質(zhì)量 . 24 6 1 什么是質(zhì)量 . 25 6 2 流程對質(zhì)量的貢獻(xiàn) . 26 6 3 流程與技術(shù) . 28 6 4 全面質(zhì)量管理 . 29 6 5 關(guān)注測試 . 30 6 6 成功的鐵三角 . 31 6 7 國際上流行的質(zhì)量標(biāo)準(zhǔn) . 31 6 8 如何起步 . 33 七 ISO和 CMM，我們該選擇誰 . 33 7 1 管理水平的適用性 . 34 7 2 復(fù)雜度的適用性 . 34 7 2 1何謂研發(fā)過程復(fù)雜度 . 35 7 2 2 何謂組織機(jī)構(gòu)復(fù)雜度 . 35 7 3 量化管理的適用性上 . 36 7 4 結(jié)論 . 37 八 如何做好單元測試 . 37 8 1 前言 . 37 8 2 組織結(jié)構(gòu)應(yīng)該保證測試組參與單元測試 . 37 8 3 加強(qiáng)單元測試流程規(guī)范性 . 38 8 3 1 制訂單元測試的過程定義 . 38 8 3 2 單元測試工作產(chǎn)品必須納入配置管理 . 39 8 3 3 必須制訂覆蓋率指標(biāo)和質(zhì)量目標(biāo)來指導(dǎo)和驗(yàn)收單元測試 . 39 8 3 4 加強(qiáng)詳細(xì)設(shè)計(jì)文檔評審 . 40 8 4 單元測試者技能的提高 . 40 8 4 1 加強(qiáng)對單元測試人員的技能培訓(xùn) . 40 8 4 2 必須引入工具進(jìn)行輔助 . 41 8 4 3 單元測試者加強(qiáng)對被測軟件的全面了解 . 41 3 8 5 結(jié)尾 . 41 九 漫談人機(jī)界面測試 . 42 9 1 一致性測試 . 42 9 2 信息反饋測試 . 43 9 3 界面簡潔性測試 . 43 9 4 界面美觀度測試 . 43 9 5 用戶動(dòng)作性測試 . 44 9 6 行業(yè)標(biāo)準(zhǔn)測試 . 44 9 7 小結(jié) . 45 十 基于 Web 的系統(tǒng)測試方法 . 45 10 1 功能測試 . 46 10 1 1 鏈接測試 . 46 10 1 2 表單測試 . 46 10 1 3 Cookies測試 . 46 10 1 4 設(shè)計(jì)語言測試 . 46 10 1 5 數(shù)據(jù)庫測試 . 47 10 2 性能測試 . 47 10 2 1 連接速度測試 . 47 10 2 2 負(fù)載測試 . 47 10 2 3 壓力測試 . 47 10 3 可用性測試 . 48 10 3 1 導(dǎo)航測試 . 48 10 3 2 圖形測試 . 48 10 3 3 內(nèi)容測試 . 48 10 3 4 整體界面測試 . 48 10 4 客戶端兼容性測試 . 49 10 4 1 平臺 測試 . 49 10 4 2 瀏覽器測試 . 49 10 5 安全性測試 . 49 10 6 總結(jié) . 50 十一 為盈利而測試 . 50 11 1 引言 . 50 11 2 什么是軟件測試 . 51 11 3 六個(gè)誤區(qū) . 51 11 3 1 誤區(qū)一：忽視對正常輸入的測試 . 51 11 3 2 誤區(qū)二：忽視設(shè)計(jì)階段的參與與評估 . 51 11 3 3 誤區(qū)三：忽視測試計(jì)劃與測試文檔的建立及維護(hù) . 52 11 3 4 誤區(qū)四：忽視缺陷的分析，報(bào)告及跟蹤 . 52 11 3 5 誤區(qū)五：錯(cuò)誤的測試目標(biāo)及測試終止條件 . 52 11 3 6 誤區(qū)六：不懂得合理調(diào)配使用測試人員的知識技能結(jié)構(gòu) . 52 11 4 軟件質(zhì)量與軟件測試 . 53 11 5 軟件測 試的經(jīng)濟(jì)目的 . 55 11 5 1 滿足用戶需求，提高產(chǎn)品的競爭力，最終提高產(chǎn)品的銷售量 . 55 11 5 2 盡早發(fā)現(xiàn)缺陷，降低后繼質(zhì)量成本 . 55 4 11 6 何時(shí)應(yīng)當(dāng)停止測試 . 57 十二 整體性能測試剖析 . 58 十三 性能測試工具之研究 . 63 13 1 性能測試的意義 . 63 13 2 性能測試工具綜述 . 64 13 3 性能測試工具的體系架構(gòu) . 65 13 4 虛擬用戶產(chǎn)生器 Vugen . 66 13 5 Proxy 二次捕獲的問題 . 68 13 6 關(guān)聯(lián)的問題 . 69 13 7 腳本的問題 . 71 13 8 Conductor 和 Player 部分 . 72 13 9 Conductor 和 Player 的技術(shù)要點(diǎn) . 73 13 10 數(shù)據(jù)分析工具 Analysis . 73 13 11 結(jié)束語 . 73 十四 性能測試原理及性能測試實(shí)例分析 . 74 14 1 軟件測試中的性能測試 . 74 14 1 1 性能測試的含義 . 74 14 1 2 性能測試的分解 . 74 14 2 一個(gè)性能測試實(shí)例 . 75 14 2 1 被測系統(tǒng) . 75 14 2 2 對被測系統(tǒng)進(jìn)行性能測試 . 76 14 5 總結(jié) . 81 十五 軟件 GUI測試中的關(guān)注點(diǎn) . 81 15 1 不能不說的二個(gè)問題 . 82 15 1 1 軟件測試中的 “ 二八 ” 原則 . 82 15 1 2 軟件黑盒測試解決的問題 . 82 15 2 軟件黑盒測試常見錯(cuò)誤類型及說明 . 82 15 2 1 用戶界面 錯(cuò)誤 . 82 15 2 2 功能性 . 82 15 2 3 人機(jī)交互 . 83 15 3 命令結(jié)構(gòu)和錄入 . 88 15 3 1 不一致性 . 88 15 3 2 “ 最優(yōu)化 ” . 88 15 3 3 菜單 . 90 15 4 遺漏的命令 . 91 15 4 1 狀態(tài)轉(zhuǎn)換 . 91 15 4 2 危機(jī)預(yù)防 . 91 15 4 3 由用戶進(jìn)行的錯(cuò)誤處理 . 92 15 4 4 其他問題 . 92 15 5 程序僵化 . 93 15 5 1 用戶可調(diào)整性 . 93 15 5 2 控制方式 . 94 15 6 性能 . 95 15 6 1 降低程序速度 . 95 5 15 6 2 緩慢回應(yīng) . 95 15 6 3 如何減少用戶吞吐量 . 95 15 6 4 反應(yīng)拙劣 . 95 15 6 5 沒有提前輸入 . 96 15 6 6 沒有給出某個(gè)操作會(huì)花很長時(shí)間的警告 . 96 15 6 7 程序太多提示和詢問 . 96 15 6 8 盡量使用簡單命令和提示 . 96 15 7 輸出 . 96 15 7 1 不能輸出某種數(shù)據(jù) . 96 15 7 2 不能重定向輸出 . 96 15 7 3 與一個(gè) 后續(xù)過程不兼容的格式 . 97 15 7 4 必須輸出的很少或很多 . 97 15 7 5 不能控制輸出布局 . 97 15 7 6 荒謬的精度輸出級別 . 97 15 7 7 不能控制表或圖的標(biāo)記 . 97 15 7 8 不能控制圖形的縮放比例 . 97 15 8 錯(cuò)誤處理 . 97 15 8 1 錯(cuò)誤預(yù)防 . 97 15 8 2 錯(cuò)誤檢測 . 98 15 8 3 錯(cuò)誤恢復(fù) . 99 15 8 4 邊界相關(guān)的錯(cuò)誤 . 100 15 8 5 計(jì)算錯(cuò)誤 . 101 15 9 小結(jié) . 101 十六 軟件測試技術(shù) . 101 16.1 軟件測試基礎(chǔ) . 102 16.1.1 測試目標(biāo) . 102 16.1.2 測試原則 . 102 16.1.3 可測試性 . 103 16.2 測試用例設(shè)計(jì) . 105 16.3 白盒測試 . 105 16.4 基本路徑測試 . 106 16.4.1 流圖符號 . 106 16.4.2 環(huán)形復(fù)雜性 . 107 16.4.3 導(dǎo)出測試用例 . 107 16.4.4 圖矩陣 . 109 16.5 控制結(jié)構(gòu)測試 . 109 16.5.1 條件測試 . 109 16.5.2 數(shù)據(jù)流測試 . 111 16.5.3 循環(huán)測試 . 112 16.6 黑盒測試 . 113 6 一 軟件測試 從零開始 【摘要】本文面向軟件測試新手，從測試前的準(zhǔn)備工作、測試需求收集、測試用例設(shè)計(jì)、測試用例執(zhí)行、測試結(jié)果分析幾個(gè)方面給出建議和方法。鑒于國內(nèi)的軟件開發(fā)、測試不規(guī)范的現(xiàn)狀，本文為軟件測試新手提供了若干個(gè)軟 件測試的關(guān)注點(diǎn)。 【關(guān)鍵詞】軟件測試、測試用例、測試需求、測試結(jié)果分析 1 1 引言 幾年前，從學(xué)校畢業(yè)后，第一份工作就是軟件測試。那時(shí)候，國內(nèi)的軟件企業(yè)大多對軟件測試還沒有什么概念，書店里除了鄭人杰編寫的計(jì)算機(jī)軟件測試技術(shù)之外，幾乎沒有其它的軟件測試相關(guān)書籍，軟件測試僅僅在軟件工程的教材中作為一個(gè)章節(jié)列出來，因此，我對軟件測試一無所知。不過，在正式走上工作崗位之前，公司提供了為期兩周的系統(tǒng)的軟件測試技術(shù)專題培訓(xùn)，對接下來的軟件測試工作有很大的指導(dǎo)意義?，F(xiàn)在，我繼續(xù)從事軟件測試的培訓(xùn)與咨詢服務(wù)，在 這個(gè)過程中，親眼目睹了很多軟件測試新手面對的困惑，他們初涉軟件測試行業(yè)，沒有接受系統(tǒng)的培訓(xùn)，對軟件測試一無所知，既不知道該測試什么，也不知道如何開始測試。下面針對上述情況，給出若干解決辦法。 1 2 測試準(zhǔn)備工作 在測試工作伊始，軟件測試工程師應(yīng)該搞清楚軟件測試工作的目的是什么。如果你把這個(gè)問題提給項(xiàng)目經(jīng)理，他往往會(huì)這樣回答： “ 發(fā)現(xiàn)我們產(chǎn)品里面的所有 BUG ，這就是你的工作目的 ” 。作為一名軟件測試新手，如何才能發(fā)現(xiàn)所有的 BUG ？如何開始測試工作？即便面對的是一個(gè)很小的軟件項(xiàng)目，測試需要考 慮的問題也是方方面面的，包括硬件環(huán)境、操作系統(tǒng)、產(chǎn)品的軟件配置環(huán)境、產(chǎn)品相關(guān)的業(yè)務(wù)流程、用戶的并發(fā)容量等等。該從何處下手呢？ 1 2 1 向有經(jīng)驗(yàn)的測試人員學(xué)習(xí) 如果你進(jìn)入的是一家運(yùn)作規(guī)范的軟件公司，有獨(dú)立的軟件測試部門、規(guī)范的軟件測試流程、軟件測試技術(shù)有一定的積累，那么，恭喜你！你可以請求測試經(jīng)理委派有經(jīng)驗(yàn)的測試人員作為你工作上的業(yè)務(wù)導(dǎo)師，由他列出軟件測試技術(shù)相關(guān)書籍目錄、軟件測試流程相關(guān)文檔目錄、產(chǎn)品業(yè)務(wù)相關(guān)的文檔目錄，在業(yè)務(wù)導(dǎo)師的指導(dǎo)下逐步熟悉軟件測試的相關(guān)工作。其實(shí)，在很多運(yùn)作規(guī)范的軟件公司，已 經(jīng)把上述的師父帶徒弟的方式固化到流程中。 7 如果你進(jìn)入的是一個(gè)軟件測試一片空白的軟件企業(yè)，那么，也恭喜你！你可以在這里開創(chuàng)一片自己的軟件測試事業(yè)，當(dāng)然，前提是老板確實(shí)認(rèn)識到軟件測試的重要性，實(shí)實(shí)在在需要提高產(chǎn)品的質(zhì)量。這時(shí)候，可以到國內(nèi)的軟件測試論壇和相關(guān)網(wǎng)站上尋找軟件測試資源，這種情況下，自學(xué)能力和對技術(shù)的悟性就至關(guān)重要了。 1 2 2 閱讀軟件測試的相關(guān)書籍 現(xiàn)在，中文版的軟件測試書籍越來越多，有的是國人自己寫的，有的是翻譯國外經(jīng)典之作。可以到 或者 等網(wǎng)絡(luò)購書的站點(diǎn)查找軟件測試相關(guān)的書籍。目前，從國外引入的軟件測試書籍有很多經(jīng)典之作，但是，翻譯成中文后，翻譯質(zhì)量對閱讀效果有很大的影響。 1 2 3 走讀缺陷跟蹤庫中的問題報(bào)告單 如果您所在的公司已經(jīng)有軟件缺陷跟蹤庫了，無論采用的是商用工具，如 ClearQuest 、 TestDirecter 等工具，還是采用 的 Bugzilla 、 Mantis 等開源工具，這都無關(guān)緊要，缺陷跟蹤庫中的缺陷報(bào)告單才是有價(jià)值的。缺陷跟蹤庫中的問題報(bào)告單是軟件測試工程師工作績效的集中體現(xiàn)，同時(shí)也是軟件產(chǎn)品問題的集中體現(xiàn)。一般來說，缺陷報(bào)告單中最關(guān)鍵的幾個(gè)部分包括：第一部分是發(fā)現(xiàn)缺陷的環(huán)境，包括軟件環(huán)境、硬件環(huán)境等；第二部分是缺陷的基本描述；第三部分是開發(fā)人員對缺陷的解決方法。通過對上述缺陷報(bào)告單的三個(gè)部分作仔細(xì)分析，不知不覺你已經(jīng)吸收了其他軟件測試人員的工作經(jīng)驗(yàn)，并掌握了軟件產(chǎn)品常見的基本問題。這是迅速提高軟件測試經(jīng)驗(yàn)的好方法。 1 2 4 走讀相關(guān)產(chǎn)品的歷史測試用例 如果你所在的公司有測試用例管理系統(tǒng)，那么，走讀相關(guān)產(chǎn)品的軟件測試用例是迅速提高測試用例設(shè)計(jì)水平的一條捷徑。走讀測試用例也是有技巧的。測試用例寫作一般會(huì)包括測試用例項(xiàng)和根據(jù)測試用例項(xiàng)細(xì)化的測試用例，下面舉例說明。 “ 測試用戶登錄的功能 ” 是一個(gè)測試項(xiàng)，該測試項(xiàng)的目的是測試用戶登錄功能是否正確，是否能夠完成正常的登錄功能，是否能夠?qū)Ψ欠ㄓ脩裘兔艽a做異常處理等等。因此，根據(jù)該用例項(xiàng)，可以設(shè)計(jì)出若干個(gè)測試用例，大多數(shù)情況下，測試用例項(xiàng)和測試用例是一對多的關(guān)系。 通過走讀測試用例項(xiàng)目，你可以掌握應(yīng)該從哪些功能點(diǎn)著手未來的測試工作；通過走讀軟件測試用例，你可以了解如何根據(jù)被測試的功能點(diǎn)開展軟件測試用例的設(shè)計(jì)工作，包括如何確定測試用例的輸入、測試用例的操作步驟和測試用例的輸出結(jié)果等。 總之，走讀其他軟件測試人員設(shè)計(jì)的優(yōu)秀軟件測試用例，是提高自身用例設(shè)計(jì)水平的好方法。 1 2 5 學(xué)習(xí)產(chǎn)品相關(guān)的業(yè)務(wù)知識 8 軟件測試人員不僅要掌握軟件測試技術(shù)相關(guān)知識，對產(chǎn)品相關(guān)的業(yè)務(wù)知識也要學(xué)習(xí)。這很好理解，如果從事財(cái)務(wù)軟件的測試工作，一定要學(xué)習(xí)財(cái)務(wù)知識；如果從事通訊產(chǎn)品測試工作，那 么相關(guān)的通訊理論知識也是必須的；如果從事銀行軟件的測試，銀行的業(yè)務(wù)流程也是不可或缺的知識點(diǎn)。 因此，在學(xué)習(xí)軟件測試技術(shù)的同時(shí)，千萬不要忽略產(chǎn)品相關(guān)業(yè)務(wù)知識的學(xué)習(xí)。如果你是一個(gè)軟件測試技術(shù)專家，但是對產(chǎn)品業(yè)務(wù)知識一無所知，那么也只能測試出來純粹的軟件缺陷，而面對眼前出現(xiàn)的產(chǎn)品業(yè)務(wù)相關(guān)的缺陷，很可能是視而不見，如此這般，軟件測試的效果會(huì)大打折扣。 1 3 識別測試需求 識別測試需求是軟件測試的第一步。如果開發(fā)人員能夠提供完整的需求文檔和接口文檔，那固然好?？梢愿鶕?jù)需求文檔中描述的每個(gè)功能項(xiàng)目的輸入、處理 過程和輸出，來設(shè)計(jì)測試用例。如果開發(fā)人員沒有提供軟件需求文檔，那該如何是好？下面給出幾個(gè)有效的方法： 1 3 1 主動(dòng)獲取需求 開發(fā)人員通常不會(huì)更好地考慮軟件測試，如果沒有開發(fā)流程的強(qiáng)制規(guī)定，他們通常是不愿意提供任何開發(fā)文檔，即便有強(qiáng)制規(guī)定，需求文檔也未必能夠真正指導(dǎo)軟件系統(tǒng)測試工作。因此，需要測試人員發(fā)揮主觀能動(dòng)性，與相關(guān)的軟件開發(fā)項(xiàng)目經(jīng)理和軟件開發(fā)人員保持溝通，了解軟件實(shí)現(xiàn)的主要功能是什么，并記錄得收集到的信息。一般來說，開發(fā)人員即便沒有提供相關(guān)需求文檔，也會(huì)保存一些簡單的過程文檔，主動(dòng)向開發(fā)人員 索要這些文檔，可以作為測試的參考。此外，可以與公司的技術(shù)支持人員交流，技術(shù)支持人員是最貼近用戶的人，因此，通過交流可以獲取第一手的用戶使用感受，在測試的過程中會(huì)更加貼近用戶。 當(dāng)拿到相關(guān)的資料后，從哪些方面分析需求？如何與開發(fā)人員交流需求？其實(shí)，只要把握需求分析的幾個(gè)關(guān)鍵的點(diǎn)就可以解決問題：輸入、處理過程、輸出、性能要求、運(yùn)行環(huán)境，下面針對每一個(gè)項(xiàng)目逐一分析： 軟件輸入： 與該需求相關(guān)的一切可能輸入，可以從這幾方面考慮，輸入來源、輸入?yún)?shù)的數(shù)量、輸入?yún)?shù)的度量單位、輸入?yún)?shù)的時(shí)間要求、輸入?yún)?shù)的精度和輸 入?yún)?shù)的有效輸入范圍。在測試用例設(shè)計(jì)中，這部分內(nèi)容作為測試用例輸入的依據(jù)。 處理過程： 描述對輸入數(shù)據(jù)所執(zhí)行的所有操作和如何獲得輸出的過程。測試人員了解處理過程即可，在測試過程中發(fā)現(xiàn) BUG 時(shí)候，如果對處理過程了解的深入，對定位問題根源有很大的幫助。 軟件輸出： 描述每個(gè)需求的輸出結(jié)果，包括輸出的位置（如計(jì)算機(jī)顯示器、打印機(jī)，文件），輸出參數(shù)的數(shù)量、輸出參數(shù)的度量單位、輸出參數(shù)的時(shí)序、輸出參數(shù)精確度、輸出參數(shù)的有效輸出范圍、錯(cuò)誤消息。在測試用例設(shè)計(jì)中，這部分內(nèi)容作為測試用例的預(yù)期輸出。 9 性能要求： 與該需求相關(guān)的性能要求，比如 “ 插入 ATM 取款卡后， 3 秒鐘內(nèi)彈出提示用戶取款的圖形界面 ” 。 3 秒鐘這一限制，就是對需求的基本性能要求。 運(yùn)行環(huán)境： 軟件的運(yùn)行所需的環(huán)境，包括硬件平臺的要求、操作系統(tǒng)的要求、數(shù)據(jù)庫的要求，以及其它相關(guān)支撐軟件的要求。 1 3 2 確認(rèn)需求的優(yōu)先級 確認(rèn)需求的優(yōu)先級是很必要的，如果在產(chǎn)品進(jìn)度比較緊的情況下，測試人員可以考慮優(yōu)先測試優(yōu)先級高的需求項(xiàng)，如果進(jìn)度允許，那么在測試優(yōu)先級低的需求項(xiàng)，如果進(jìn)度不允許，那么就放棄測試優(yōu)先級低的需求項(xiàng)。如果軟件公司有規(guī)范 的流程支撐，開發(fā)人員在提供軟件需求文檔的時(shí)候，應(yīng)該在文檔中確定需求的優(yōu)先級。但是，如果開發(fā)人員連基本的軟件需求文檔都沒有提供，又怎能指望他們確定軟件需求的優(yōu)先級？如果是這樣，需求的優(yōu)先級只能由測試人員完成了。 1 3 3 加入開發(fā)小組的郵件群組 測試人員需要通曉被測試產(chǎn)品，但是，產(chǎn)品在開發(fā)的過程中往往是不斷變化的。如果軟件開發(fā)團(tuán)隊(duì)有一套變更控制流程，測試人員會(huì)對產(chǎn)品的變更了如指掌。如果沒有變更控制，那就要采用其他的土方法了。如果公司里面有自動(dòng)化辦公系統(tǒng)，也許采用的是 Lotus Notes 系統(tǒng)，也許 使用的是 E-mail 系統(tǒng)，測試人員應(yīng)該加入到開發(fā)人員的郵件群組中。當(dāng)開發(fā)人員通過郵件討論問題、通知召開技術(shù)會(huì)議的時(shí)候，測試人員可以及時(shí)知曉，如果必要，可以參加開發(fā)人員的技術(shù)會(huì)議。即便公司里面有了軟件變更控制流程，加入到開發(fā)郵件群組也是一個(gè)很好的習(xí)慣。 1 3 4 與開發(fā)人員為鄰 建議測試人員與開發(fā)人員為鄰。我所在的測試組曾經(jīng)與開發(fā)組是在相鄰的寫字間里，開發(fā)人員與測試人員的關(guān)系非常融洽，拋去同事關(guān)系，大家還是不錯(cuò)的朋友。不管開發(fā)人員有什么樣的活動(dòng)，測試人員都能第一時(shí)間獲得信息。無論從事軟件測試工作， 還是從事其它的工作，與工作中上下游環(huán)節(jié)的同事保持良好的個(gè)人關(guān)系對工作有很大便利。一般的公司內(nèi)部都存在部門墻，良好的人際關(guān)系是打通部門墻的手段之一。向領(lǐng)導(dǎo)建議測試人員與開發(fā)人員為鄰，這很必要。 1 4 測試用例設(shè)計(jì) 測試需求收集完畢后，開始測試設(shè)計(jì)。測試用例是什么？測試用例就是一個(gè)文檔，描述輸入、動(dòng)作、或者時(shí)間和一個(gè)期望的結(jié)果，其目的是確定應(yīng)用程序的某個(gè)特性是否正常的工作。設(shè)計(jì)測試用例需要考慮以下問題： 1 4 1 測試用例的基本格式 10 軟件測試用例的基本要素包括測試用例編號、測試標(biāo)題、重要級別、 測試輸入、操作步驟、預(yù)期結(jié)果，下面逐一介紹。 用例編號： 測試用例的編號有一定的規(guī)則，比如系統(tǒng)測試用例的編號這樣定義規(guī)則： PROJECT1-ST-001 ，命名規(guī)則是項(xiàng)目名稱測試階段類型（系統(tǒng)測試階段）編號。定義測試用例編號，便于查找測試用例，便于測試用例的跟蹤。 測試標(biāo)題： 對測試用例的描述，測試用例標(biāo)題應(yīng)該清楚表達(dá)測試用例的用途。比如 “ 測試用戶登錄時(shí)輸入錯(cuò)誤密碼時(shí)，軟件的響應(yīng)情況 ” 。 重要級別： 定義測試用例的優(yōu)先級別，可以籠統(tǒng)的分為 “ 高 ” 和 “ 低 ” 兩個(gè)級別。一般來說， 如果軟件需求的優(yōu)先級為 “ 高 ” ，那么針對該需求的測試用例優(yōu)先級也為 “ 高 ” ；反之亦然， 測試輸入： 提供測試執(zhí)行中的各種輸入條件。根據(jù)需求中的輸入條件，確定測試用例的輸入。測試用例的輸入對軟件需求當(dāng)中的輸入有很大的依賴性，如果軟件需求中沒有很好的定義需求的輸入，那么測試用例設(shè)計(jì)中會(huì)遇到很大的障礙。 操作步驟： 提供測試執(zhí)行過程的步驟。對于復(fù)雜的測試用例，測試用例的輸入需要分為幾個(gè)步驟完成，這部分內(nèi)容在操作步驟中詳細(xì)列出。 預(yù)期結(jié)果： 提供測試執(zhí)行的預(yù)期結(jié)果，預(yù)期結(jié)果應(yīng)該根據(jù)軟件需求中的輸出 得出。如果在實(shí)際測試過程中，得到的實(shí)際測試結(jié)果與預(yù)期結(jié)果不符，那么測試不通過；反之則測試通過。 軟件測試用例的設(shè)計(jì)主要從上述 6 個(gè)域考慮，結(jié)合相應(yīng)的軟件需求文檔，在掌握一定測試用例設(shè)計(jì)方法的基礎(chǔ)上，可以設(shè)計(jì)出比較全面、合理的測試用例。具體的測試用例設(shè)計(jì)方法可以參見相關(guān)的測試書籍，白盒測試方法和黑盒測試方法在絕大多數(shù)的軟件測試書籍中都有詳細(xì)的介紹，這里不作贅述。 1 4 2 重用同類型項(xiàng)目的測試用例 如果我看得遠(yuǎn)，那是因?yàn)槲艺驹诰奕说募缟?牛頓。 一般來說，每個(gè)軟件公司的項(xiàng)目可以分為固定的幾大 類?？梢园礃I(yè)務(wù)類型劃分，比如 ERP 軟件、產(chǎn)品數(shù)據(jù)管理軟件、通信軟件、地理信息系統(tǒng)軟件等等；可以按軟件結(jié)構(gòu)來劃分，比如 B/S 架構(gòu)的軟件、 C/S 架構(gòu)的軟件、嵌入式軟件等等。參考同類別軟件的測試用例，會(huì)有很大的借鑒意義。如果，公司中有同類別的軟件系統(tǒng)，千萬別忘記把相關(guān)的測試用例拿來參考。如果，系統(tǒng)非常接近，甚至經(jīng)過對測試用例簡單修改就可以應(yīng)用到當(dāng)前被測試的軟件。 “ 拿來主義 ” 可以極大的開闊測試用例設(shè)計(jì)思路，也可以節(jié)省大量的測試用例設(shè)計(jì)時(shí)間。 1 4 3 利用已有的軟件 Checklist 在上面一個(gè)小節(jié)中，按照不同的規(guī)則劃分了不同的軟件類型。每種類型的軟件都有一定的測試規(guī)范，比如， WEB 軟件系統(tǒng)在系統(tǒng)測試過程中，會(huì)有一系列的范式，比如針對 Cookie 11 就會(huì)有很多測試點(diǎn)。在設(shè)計(jì)測試用例的時(shí)候，不妨到網(wǎng)上去搜索相關(guān)的 Checklist ，不過國內(nèi)外的網(wǎng)站很少有這方面的資料，即便有，也不是特別系統(tǒng)。可以先找一份粗糙的 Checklist ，然后，在設(shè)計(jì)測試用例的時(shí)候不斷的去完善它，以作為下次測試用例設(shè)計(jì)的基礎(chǔ)。 1 4 4 加強(qiáng)測試用例的評審 測試用例設(shè)計(jì)完畢后，最好能夠增加評審過程 。同行評審是 CMM3 級的一個(gè) KPA ，如果因?yàn)楣緵]有通過 CMM3 級，就不開展同行評審是不恰當(dāng)?shù)摹y試用例應(yīng)該由產(chǎn)品相關(guān)的軟件測試人員和軟件開發(fā)人員評審，提交評審意見，然后根據(jù)評審意見更新測試用例。 如果認(rèn)真操作這個(gè)環(huán)節(jié)，測試用例中的很多問題都會(huì)暴露出來，比如用例設(shè)計(jì)錯(cuò)誤、用例設(shè)計(jì)遺漏、用例設(shè)計(jì)冗余、用例設(shè)計(jì)不充分等等；如果同行評審不充分，那么，在測試執(zhí)行的過程中，上述本應(yīng)在評審階段發(fā)現(xiàn)的測試用例相關(guān)問題，會(huì)給測試執(zhí)行帶來大麻煩，甚至導(dǎo)致測試執(zhí)行掛起。 1 4 5 定義測試用例的執(zhí)行順序 在 測試用例執(zhí)行過程中，你會(huì)發(fā)現(xiàn)每個(gè)測試用例都對測試環(huán)境有特殊的要求，或者對測試環(huán)境有特殊的影響。因此，定義測試用例的執(zhí)行順序，對測試的執(zhí)行效率影響非常大。比如某些異常測試用例會(huì)導(dǎo)致服務(wù)器頻繁重新啟動(dòng)，服務(wù)器的每次重新啟動(dòng)都會(huì)消耗大量的時(shí)間，導(dǎo)致這部分測試用例執(zhí)行也消耗很多的時(shí)間。那么在編排測試用例執(zhí)行順序的時(shí)候，應(yīng)該考慮把這部分測試用例放在最后執(zhí)行，如果在測試進(jìn)度很緊張的情況下，如果優(yōu)先執(zhí)行這部分消耗時(shí)間的異常測試用例，那么在測試執(zhí)行時(shí)間過了大半的時(shí)候，測試用例執(zhí)行的進(jìn)度依然是緩慢的，這會(huì)影響到測試人員的心情 ，進(jìn)而導(dǎo)致匆忙地測試后面的測試用例，這樣測試用例的漏測、誤測就不可避免，嚴(yán)重影響了軟件測試效果和進(jìn)度。因而，合理地定義測試用例的執(zhí)行順序是很有必要的。 1 5 測試用例執(zhí)行 測試用例設(shè)計(jì)完畢后，接下來的工作是測試執(zhí)行，測試執(zhí)行中應(yīng)該注意以下幾個(gè)問題： 1 5 1 搭建軟件測試環(huán)境，執(zhí)行測試用例 測試用例執(zhí)行過程中，搭建測試環(huán)境是第一步。一般來說，軟件產(chǎn)品提交測試后，開發(fā)人員應(yīng)該提交一份產(chǎn)品安裝指導(dǎo)書，在指導(dǎo)書中詳細(xì)指明軟件產(chǎn)品運(yùn)行的軟硬件環(huán)境，比如要求操作系統(tǒng)系統(tǒng)是 Windows 2000 pack4 版本，數(shù)據(jù)庫是 Sql Server 2000 等等，此外，應(yīng)該給出被測試軟件產(chǎn)品的詳細(xì)安裝指導(dǎo)書，包括安裝的操作步驟、相關(guān)配置文件的配置方法等等。對于復(fù)雜的軟件產(chǎn)品，尤其是軟件項(xiàng)目，如果沒有安裝指導(dǎo)書作為參考，在搭建測試環(huán)境過程中會(huì)遇到種種問題。 12 如果開發(fā)人員拒絕提供相關(guān)的安裝指導(dǎo)書，搭建測試中遇到問題的時(shí)候，測試人員可以要求開發(fā)人員協(xié)助，這時(shí)候，一定要把開發(fā)人員解決問題的方法記錄下來，避免同樣的問題再次請教開發(fā)人員，這樣會(huì)招致開發(fā)人員的反感，也降低了開發(fā)人員對測試人員的認(rèn)可程度。 1 5 2 測試執(zhí)行過程應(yīng)注意的問題 測試環(huán)境搭建之后，根據(jù)定義的測試用例執(zhí)行順序，逐個(gè)執(zhí)行測試用例。在測試執(zhí)行中需要注意以下幾個(gè)問題： 全方位的觀察測試用例執(zhí)行結(jié)果： 測試執(zhí)行過程中，當(dāng)測試的實(shí)際輸出結(jié)果與測試用例中的預(yù)期輸出結(jié)果一致的時(shí)候，是否可以認(rèn)為測試用例執(zhí)行成功了？答案是否定的，即便實(shí)際測試結(jié)果與測試的預(yù)期結(jié)果一致，也要查看軟件產(chǎn)品的操作日志、系統(tǒng)運(yùn)行日志和系統(tǒng)資源使用情況，來判斷測試用例是否執(zhí)行成功了。全方位觀察軟件產(chǎn)品的輸出可以發(fā)現(xiàn)很多隱蔽的問題。以前，我在測試嵌入式系統(tǒng)軟件的時(shí)候，執(zhí)行某測試用 例后，測試用例的實(shí)際輸出與預(yù)期輸出完全一致，不過在查詢 CPU 占用率地時(shí)候，發(fā)現(xiàn) CPU 占用率高達(dá) 90 ，后來經(jīng)過分析，軟件運(yùn)行的時(shí)候啟動(dòng)了若干個(gè) 1ms 的定時(shí)器，大量的消耗的 CPU 資源，后來通過把定時(shí)器調(diào)整到 10ms ， CPU 的占用率降為 7 。如果觀察點(diǎn)單一，這個(gè)嚴(yán)重消耗資源的問題就無從發(fā)現(xiàn)了。 加強(qiáng)測試過程記錄： 測試執(zhí)行過程中，一定要加強(qiáng)測試過程記錄。如果測試執(zhí)行步驟與測試用例中描述的有差異，一定要記錄下來，作為日后更新測試用例的依據(jù)；如果軟件產(chǎn)品提供了日志功能，比如有軟件運(yùn) 行日志、用戶操作日志，一定在每個(gè)測試用例執(zhí)行后記錄相關(guān)的日志文件，作為測試過程記錄，一旦日后發(fā)現(xiàn)問題，開發(fā)人員可以通過這些測試記錄方便的定位問題。而不用測試人員重新搭建測試環(huán)境，為開發(fā)人員重現(xiàn)問題。 及時(shí)確認(rèn)發(fā)現(xiàn)的問題： 測試執(zhí)行過程中，如果確認(rèn)發(fā)現(xiàn)了軟件的缺陷，那么可以毫不猶豫的提交問題報(bào)告單。如果發(fā)現(xiàn)了可疑問題，又無法定位是否為軟件缺陷，那么一定要保留現(xiàn)場，然后知會(huì)相關(guān)開發(fā)人員到現(xiàn)場定位問題。如果開發(fā)人員在短時(shí)間內(nèi)可以確認(rèn)是否為軟件缺陷，測試人員給予配合；如果開發(fā)人員定位問題需要花費(fèi)很長的時(shí)間，測試人 員千萬不要因此耽誤自己寶貴的測試執(zhí)行時(shí)間，可以讓開發(fā)人員記錄重新問題的測試環(huán)境配置，然后，回到自己的開發(fā)環(huán)境上重現(xiàn)問題，繼續(xù)定位問題。 與開發(fā)人員良好的溝通： 測試執(zhí)行過程中，當(dāng)你提交了問題報(bào)告單，可能被開發(fā)人員無情駁回，拒絕修改。這時(shí)候，只能對開發(fā)人員曉之以理，做到有理、有據(jù)，有說服力。首先，要定義軟件缺陷的標(biāo)準(zhǔn)原則，這個(gè)原則應(yīng)該是開發(fā)人員和測試人員都認(rèn)可的，如果沒有共同認(rèn)可的原則，那么開發(fā)人員與測試人員對問題的爭執(zhí)就不可避免了。此外，測試人員打算說服開發(fā)人員之前，考慮是否能夠先說服自己，在保證可以說服 自己的前提下，再開始與開發(fā)人員交流。 1 5 3 及時(shí)更新測試用例 測試執(zhí)行過程中，應(yīng)該注意及時(shí)更新測試用例。往往在測試執(zhí)行過程中，才發(fā)現(xiàn)遺漏了一些測試用例，這時(shí)候應(yīng)該及時(shí)的補(bǔ)充；往往也會(huì)發(fā)現(xiàn)有些測試用例在具體的執(zhí)行過程中根本無 13 法操作，這時(shí)候應(yīng)該刪除這部分用例；也會(huì)發(fā)現(xiàn)若干個(gè)冗余的測試用例完全可以由某一個(gè)測試用例替代，那么刪除冗余的測試用例。 總之，測試執(zhí)行的過程中及時(shí)地更新測試用例是很好的習(xí)慣。不要打算在測試執(zhí)行結(jié)束后，統(tǒng)一更新測試用例，如果這樣，往往會(huì)遺漏很多本應(yīng)該更新的測試用例。 1 5 4 提交一份優(yōu)秀的問題報(bào)告單 軟件測試提交的問題報(bào)告單和測試日報(bào)一樣，都是軟件測試人員的工作輸出，是測試人員績效的集中體現(xiàn)。因此，提交一份優(yōu)秀的問題報(bào)告單是很重要的。軟件測試報(bào)告單最關(guān)鍵的域就是 “ 問題描述 ” ，這是開發(fā)人員重現(xiàn)問題，定位問題的依據(jù)。問題描述應(yīng)該包括以下幾部分內(nèi)容：軟件配置、硬件配置、測試用例輸入、操作步驟、輸出、當(dāng)時(shí)輸出設(shè)備的相關(guān)輸出信息和相關(guān)的日志等。 軟件配置： 包括操作系統(tǒng)類型版本和補(bǔ)丁版本、當(dāng)前被測試軟件的版本和補(bǔ)丁版本、相關(guān)支撐軟件，比如數(shù)據(jù)庫軟件的版本和補(bǔ)丁版本等。 硬件配置： 計(jì)算機(jī)的配置情況，主要包括 CPU 、內(nèi)存和硬盤的相關(guān)參數(shù)，其它硬件參數(shù)根據(jù)測試用例的實(shí)際情況添加。如果測試中使用網(wǎng)絡(luò)，那么網(wǎng)絡(luò)的組網(wǎng)情況，網(wǎng)絡(luò)的容量、流量等情況。硬件配置情況與被測試產(chǎn)品類型密切相關(guān)，需要根據(jù)當(dāng)時(shí)的情況，準(zhǔn)確翔實(shí)的記錄硬件配置情況。 測試用例輸入 操作步驟 輸出： 這部分內(nèi)容可以根據(jù)測試用例的描述和測試用例的實(shí)際執(zhí)行情況如實(shí)填寫。 輸出設(shè)備的相關(guān)輸出信息： 輸出設(shè)備包括計(jì)算機(jī)顯示器、打印機(jī)、磁帶等等輸出設(shè)備，如果是顯示器可以采用抓屏的方式獲取當(dāng)時(shí)的截圖，其他的輸出設(shè) 備可以采用其它方法獲取相關(guān)的輸出，在問題報(bào)告單中提供描述。 日志信息： 規(guī)范的軟件產(chǎn)品都會(huì)提供軟件的運(yùn)行日志和用戶、管理員的操作日志，測試人員應(yīng)該把測試用例執(zhí)行后的軟件產(chǎn)品運(yùn)行日志和操作日志作為附件，提交到問題報(bào)告單中。 根據(jù)被測試軟件產(chǎn)品的不同，需要在 “ 問題描述 ” 中增加相應(yīng)的描述內(nèi)容，這需要具體問題具體分析。 1 6 測試結(jié)果分析 軟件測試執(zhí)行結(jié)束后，測試活動(dòng)還沒有結(jié)束。測試結(jié)果分析是必不可少的重要環(huán)節(jié)， “ 編筐編簍，全在收口 ” ，測試結(jié)果的分析對下一輪測試工作的開展有很大的借鑒意義 。前面的 “ 測試準(zhǔn)備工作 ” 中，建議測試人員走讀缺陷跟蹤庫，查閱其他測試人員發(fā)現(xiàn)的軟件缺陷。測試結(jié)束后，也應(yīng)該分析自己發(fā)現(xiàn)的軟件缺陷，對發(fā)現(xiàn)的缺陷分類，你會(huì)發(fā)現(xiàn)自己提交的問題只有固定的幾個(gè)類別；然后，再把一起完成測試執(zhí)行工作的其他測試人員發(fā)現(xiàn)的問題也匯總起來，你會(huì)發(fā)現(xiàn)，你所提交問題的類別與他們有差異。這很正常，人的思維是有局限 14 性，在測試的過程中，每個(gè)測試人員都有自己思考問題的盲區(qū)和測試執(zhí)行的盲區(qū)，有效的自我分析和分析其他測試人員，你會(huì)發(fā)現(xiàn)自己的盲區(qū)，有針對性的分析盲區(qū)，必定會(huì)在下一輪測試用避免盲區(qū)。 1 7 總結(jié) 限于文章的篇幅，本文不可能給出一個(gè)類似于 checklist 的指導(dǎo)性的軟件測試新手入門。無論從事軟件測試還是從事其它的工作，技術(shù)上的和技巧上的問題都可以通過查詢相關(guān)的軟件測試技術(shù)書籍獲取，掌握一套基本的方法論是最重要的。以上文字，都是作者從事軟件測試工作積累的經(jīng)驗(yàn)之談，如發(fā)現(xiàn)謬誤之處請不吝指出。 二 軟件測試的常識 2 1 引言 軟件開發(fā)和使用的歷史已經(jīng)留給了我們很多由于軟件缺陷而導(dǎo)致的巨大財(cái)力、物力損失的經(jīng)驗(yàn)教訓(xùn)。這些經(jīng)驗(yàn)教訓(xùn)迫使我們這些測試工程師們必須采取強(qiáng)有力的檢測措施來檢測未 發(fā)現(xiàn)的隱藏的軟件缺陷。 生產(chǎn)軟件的最終目的是為了滿足客戶需求，我們以客戶需求作為評判軟件質(zhì)量的標(biāo)準(zhǔn)，認(rèn)為軟件缺陷（ Software Bug ）的具體含義包括下面幾個(gè)因素： 軟件未達(dá)到客戶需求的功能和性能； 軟件超出客戶需求的范圍； 軟件出現(xiàn)客戶需求不能容忍的錯(cuò)誤； 軟件的使用未能符合客戶的習(xí)慣和工作環(huán)境。 考慮到設(shè)計(jì)等方面的因素，我們還可以認(rèn)為軟件缺陷還可以包括軟件設(shè)計(jì)不符合規(guī)范，未能在特定的條件（資金、范圍等）達(dá)到最佳等?？上У氖?，我們中的很多人更傾向于把軟件缺陷看成 運(yùn)行時(shí)出現(xiàn)問題上來，認(rèn)為軟件測試僅限于程序提交之后。 在目前的國內(nèi)環(huán)境下，我們幾乎看不到完整準(zhǔn)確的客戶需求說明書，加以客戶的需求時(shí)時(shí)在變，追求完美的測試變得不太可能。因此作為一個(gè)優(yōu)異的測試人員，追求軟件質(zhì)量的完美固然是我們的宗旨，但是明確軟件測試現(xiàn)實(shí)與理想的差距，在軟件測試中學(xué)會(huì)取舍和讓步，對軟件測試是有百益而無一弊的。 2 2 軟件測試常識 下面是一些軟件測試的常識，對這些常識的理解和運(yùn)用將有助于我們在進(jìn)行軟件測試時(shí)能夠更好的把握軟件測試的尺度。 2 2 1 測試是不完全的（測試不完全） 很 顯然，由于軟件需求的不完整性、軟件邏輯路徑的組合性、輸入數(shù)據(jù)的大量性及結(jié)果多樣 15 性等因素，哪怕是一個(gè)極其簡單的程序，要想窮盡所有邏輯路徑，所有輸入數(shù)據(jù)和驗(yàn)證所有結(jié)果是非常困難的一件事情。我們舉一個(gè)簡單的例子，比如說求兩個(gè)整數(shù)的最大公約數(shù)。其輸入信息為兩個(gè)正整數(shù)。但是如果我們將整個(gè)正整數(shù)域的數(shù)字進(jìn)行一番測試的話，從其數(shù)目的無限性我們便可證明是這樣的測試在實(shí)際生活中是行不通的，即便某一天我們能夠窮盡該程序，只怕我們乃至我們的子孫都早已作古了。為此作為軟件測試，我們一般采用等價(jià)類和邊界值分析等措施來進(jìn)行實(shí)際的軟件測 試，尋找最小用例集合成為我們精簡測試復(fù)雜性的一條必經(jīng)之道。 2 2 2 測試具有免疫性（軟件缺陷免疫性） 軟件缺陷與病毒一樣具有可怕的 “ 免疫性 ” ，測試人員對其采用的測試越多，其免疫能力就越強(qiáng)，尋找更多軟件缺陷就更加困難。由數(shù)學(xué)上的概率論我們可以推出這一結(jié)論。假設(shè)一個(gè) 50000 行的程序中有 500 個(gè)軟件缺陷并且這些軟件錯(cuò)誤分布時(shí)均勻的，則每 100 行可以找到一個(gè)軟件缺陷。我們假設(shè)測試人員用某種方法花在查找軟件缺陷的精力為 X 小時(shí) /100 行。照此推算，軟件存在 500 個(gè)缺陷時(shí)，我們 查找一個(gè)軟件缺陷需要 X 小時(shí)，當(dāng)軟件只存在 5 個(gè)錯(cuò)誤時(shí)，我們每查找一個(gè)軟件缺陷需要 100X 小時(shí)。實(shí)踐證明，實(shí)際的測試過程比上面的假設(shè)更為苛刻，為此我們必須更換不同的測試方式和測試數(shù)據(jù)。該例子還說明了在軟件測試中采用單一的方法不能高效和完全的針對所有軟件缺陷，因此軟件測試應(yīng)該盡可能的多采用多種途徑進(jìn)行測試。 2 2 3 測試是 “ 泛型概念 ” （全程測試） 我一直反對軟件測試僅存在于程序完成之后。如果單純的只將程序設(shè)計(jì)階段后的階段稱之為軟件測試的話，需求階段和設(shè)計(jì)階段的缺陷產(chǎn)生的放大效 應(yīng)會(huì)加 大。這非常不利于保證軟件質(zhì)量。需求缺陷、設(shè)計(jì)缺陷也是軟件缺陷，記住 “ 軟件缺陷具有生育能力 ” 。軟件測試應(yīng)該跨越整個(gè)軟件開發(fā)流程。需求驗(yàn)證（自檢）和設(shè)計(jì)驗(yàn)證（自檢）也可以算作軟件測試（建議稱為：需求測試和設(shè)計(jì)測試）的一種。軟件測試應(yīng)該是一個(gè)泛型概念，涵蓋整個(gè)軟件生命周期，這樣才能確保周期的每個(gè)階段禁得起考驗(yàn)。同時(shí)測試本身也需要有第三者進(jìn)行評估（信息系統(tǒng)審計(jì)和軟件工程監(jiān)理），即測試本身也應(yīng)當(dāng)被測試，從而確保測試自身的可靠性和高效性。否則自身不正，難以服人。 另外還需指出的是軟件測試是提高軟件產(chǎn)品質(zhì)量的必 要條件而非充分條件，軟件測試是提高產(chǎn)品質(zhì)量最直接、最快捷的手段，但決不是一個(gè)根本手段。 2 2 4 80-20 原則 80% 的軟件缺陷常常生存在軟件 20% 的空間里。這個(gè)原則告訴我們，如果你想使軟件測試有效地話，記住常常光臨其高危多發(fā) “ 地段 ” 。在那里發(fā)現(xiàn)軟件缺陷的可能性會(huì)大的多。這一原則對于軟件測試人員提高測試效率及缺陷發(fā)現(xiàn)率有著重大的意義。聰明的測試人員會(huì)根據(jù)這個(gè)原則很快找出較多的缺陷而愚蠢的測試人員卻仍在漫無目的地到處搜尋。 80-20 原則的另外一種情況是，我們在系統(tǒng)分析、系統(tǒng)設(shè)計(jì) 、系統(tǒng)實(shí)現(xiàn)階段的復(fù)審，測試工作中能夠發(fā)現(xiàn)和避免 80% 的軟件缺陷，此后的系統(tǒng)測試能夠幫助我們找出剩余缺陷中的 80% ，最后的 5% 的軟件缺陷可能只有在系統(tǒng)交付使用后用戶經(jīng)過大范圍、長時(shí)間使用后 16 才會(huì)曝露出來。因?yàn)檐浖y試只能夠保證盡可能多地發(fā)現(xiàn)軟件缺陷，卻無法保證能夠發(fā)現(xiàn)所有的軟件缺陷。 80-20 原則還能反映到軟件測試的自動(dòng)化方面上來，實(shí)踐證明 80% 的軟件缺陷可以借助人工測試而發(fā)現(xiàn)， 20% 的軟件缺陷可以借助自動(dòng)化測試能夠得以發(fā)現(xiàn)。由于這二者間具有交叉的部分，因此尚有 5% 左右的軟件缺陷需 要通過其他方式進(jìn)行發(fā)現(xiàn)和修正。 2 2 5 為效益而測試 為什么我們要實(shí)施軟件測試，是為了提高項(xiàng)目的質(zhì)量效益最終以提高項(xiàng)目的總體效益。為此我們不難得出我們在實(shí)施軟件測試應(yīng)該掌握的度。軟件測試應(yīng)該在軟件測試成本和軟件質(zhì)量效益兩者間找到一個(gè)平衡點(diǎn)。這個(gè)平衡點(diǎn)就是我們在實(shí)施軟件測試時(shí)應(yīng)該遵守的度。單方面的追求都必然損害軟件測試存在的價(jià)值和意義。一般說來，在軟件測試中我們應(yīng)該盡量地保持軟件測試簡單性，切勿將軟件測試過度復(fù)雜化，拿物理學(xué)家愛因斯坦的話說就是： Keep it simple but not too simple 。 2 2 6 缺陷的必然性 軟件測試中，由于錯(cuò)誤的關(guān)聯(lián)性，并不是所有的軟件缺陷都能夠得以修復(fù)。某些軟件缺陷雖然能夠得以修復(fù)但在修復(fù)的過程中我們會(huì)難免引入新的軟件缺陷。很多軟件缺陷之間是相互矛盾的，一個(gè)矛盾的消失必然會(huì)引發(fā)另外一個(gè)矛盾的產(chǎn)生。比如我們在解決通用性的缺陷后往往會(huì)帶來執(zhí)行效率上的缺陷。更何況在缺陷的修復(fù)過程中，我們常常還會(huì)受時(shí)間、成本等方面的限制因此無法有效、完整地修復(fù)所有的軟件缺陷。因此評估軟件缺陷的重要度、影響范圍，選擇一個(gè)折中的方案或是從非軟件的因素（比如提升硬件性能 ）考慮軟件缺陷成為我們在面對軟件缺陷時(shí)一個(gè)必須直面的事實(shí)。 2 2 7 軟件測試必須有預(yù)期結(jié)果 沒有預(yù)期結(jié)果的測試是不可理喻的。軟件缺陷是經(jīng)過對比而得出來的。這正如沒有標(biāo)準(zhǔn)無法進(jìn)行度量一樣。如果我們事先不知道或是無法肯定預(yù)期的結(jié)果，我們必然無法了解測試正確性。這很容易然人感覺如盲人摸象一般，不少測試人員常常憑借自身的感覺去評判軟件缺陷的發(fā)生，其結(jié)果往往是把似是而非的東西作為正確的結(jié)果來判斷，因此常常出現(xiàn)誤測的現(xiàn)象。 2 2 8 軟件測試的意義 - 事后分析 軟件測試的目的單單是發(fā)現(xiàn)缺陷這么簡單嗎？ 如果是 “ 是 ” 的話，我敢保證，類似的軟件缺陷在下一次新項(xiàng)目的軟件測試中還會(huì)發(fā)生。古語說得好， “ 不知道歷史的人必然會(huì)重蹈覆轍 ” 。沒有對軟件測試結(jié)果進(jìn)行認(rèn)真的分析，我們就無法了解缺陷發(fā)生的原因和應(yīng)對措施，結(jié)果是我們不得不耗費(fèi)的大量的人力和物力來再次查找軟件缺陷。很可惜，目前大多測試團(tuán)隊(duì)都沒有意識到這一點(diǎn)，測試報(bào)告中缺乏測試結(jié)果分析這一環(huán)節(jié)。 2 2 9 結(jié)論： 17 軟件測試是一個(gè)需要 “ 自覺 ” 的過程，作為一個(gè)測試人員，遇事沉著，把持尺度，從根本上應(yīng)對軟件測試有著正確的認(rèn)識，希望本文對讀者對 軟件測試的認(rèn)識有所幫助。 三 淺談軟件開發(fā)中的注意事項(xiàng) 本人從事了四年左右的軟件開發(fā)工作，曾參與開發(fā)過多個(gè)大型項(xiàng)目，對于整個(gè)項(xiàng)目開發(fā)中我覺得有很多地方都應(yīng)該應(yīng)當(dāng)值得注意，特寫如下觀點(diǎn)和各位看客共同探討！ 3 1 項(xiàng)目設(shè)計(jì) 項(xiàng)目設(shè)計(jì)的主導(dǎo)思想，我覺得可以理解為兩種，一種是完全設(shè)計(jì)，一個(gè)是簡單設(shè)計(jì)。 完全設(shè)計(jì)是指在具體編寫代碼之前對軟件的各種方面都調(diào)查好，做好詳細(xì)的需求分析、編寫好全部的開發(fā)文檔，設(shè)計(jì)出程序全部流程后再開始寫代碼。 換句話說，就是全部的計(jì)劃好了，能看到最終的樣子，再開戰(zhàn)。這好像也是很多 “軟 件工程 ”書里要求的那樣。開始的時(shí)候，我覺得這種方法不錯(cuò)也。什么都計(jì)劃好了，照著做就是了。不過這里有個(gè)明顯的問題，就是誰來做這個(gè)完美的計(jì)劃？估計(jì)只有及其 BT 的人了，但是大部分人的想要完全設(shè)計(jì)，并且沒有錯(cuò)誤，或者已經(jīng)有幾種后備的容錯(cuò)方案，并能準(zhǔn)確無誤的推行。以達(dá)到最終目標(biāo)。這樣的境界，沒有很多年的工作經(jīng)歷是不可能的。我也沒有這樣的本事，所以我也就放棄了這種想法。 簡單設(shè)計(jì)：簡單設(shè)計(jì)一種概念，一種可以接受的簡單的設(shè)計(jì)，最起碼數(shù)據(jù)庫已經(jīng)定下來，基本流程已經(jīng)確定的方案，來作為程序設(shè)計(jì)的開始，并隨時(shí)根據(jù)實(shí)際情況的進(jìn)展來 修正具體的功能設(shè)計(jì)，但這種功能修改不能是修改數(shù)據(jù)庫結(jié)構(gòu)。也就是說數(shù)據(jù)庫結(jié)構(gòu)是在編程之前經(jīng)過反復(fù)論證的。這種方法減少了前期設(shè)計(jì)的時(shí)間，把代碼編寫工作和部分設(shè)計(jì)工作放在了一起，實(shí)際縮短了項(xiàng)目開發(fā)的時(shí)間。如果說完全設(shè)計(jì)方法要求有很厲害的前期設(shè)計(jì)人員，那么簡單設(shè)計(jì)要求有很有設(shè)計(jì)頭腦的編程人員。編程人員不僅僅是 K 代碼的人而且要負(fù)責(zé)程序架構(gòu)的設(shè)計(jì)。所以對程序員的要求就很高了。 簡單設(shè)計(jì)的成功的一個(gè)基點(diǎn)是編程人員設(shè)計(jì)的邏輯結(jié)構(gòu)簡單并能根據(jù)需要來調(diào)整其邏輯結(jié)構(gòu)，就是代碼結(jié)構(gòu)靈活，簡單設(shè)計(jì)帶來的另外一個(gè)變化就是會(huì)議會(huì)比較多， 編程人員之間的交流就變的很重要?，F(xiàn)在一般的中小型軟件公司基本上都是采用簡單設(shè)計(jì)的，除非那些很大型的軟件公司。 總結(jié)，簡單設(shè)計(jì)考驗(yàn)的是開發(fā)人員的能力。完全設(shè)計(jì)考驗(yàn)的是前期設(shè)計(jì)人員和整個(gè)項(xiàng)目組完整能力。 (各種文檔的編寫，開發(fā)人員一定會(huì)要寫一部分的。 ) 3 2 設(shè)計(jì)變化和需求變化 開發(fā)人員最怕的是什么呢？設(shè)計(jì)變化，還是需求變化？我覺得需求變化是最最致命的。當(dāng)你的一個(gè)項(xiàng)目數(shù)據(jù)庫都定下來后，而且已經(jīng)開發(fā)了若干個(gè)工作日，突然接到甲方公司提出，某個(gè)功能要改變，原先的需求分析要重新改，如果這個(gè)修改是涉及的數(shù)據(jù)庫的表結(jié)構(gòu)更 改的話，那真是最致命的。這就意味著項(xiàng)目的某些部分得重新推倒重來，如果這個(gè)部分跟已完成的多個(gè)部分有牽連的話，那就后果更可怕了。所以當(dāng)碰到這種情況發(fā)生，作為項(xiàng)目經(jīng)理的你就應(yīng)該考慮先查責(zé)任人，究竟是自己的需求分析做的不夠好，還是客戶在認(rèn)同了需求分析后做出 18 的修改，如果是后者的話，你完全可以要求客戶對他的這個(gè)修改負(fù)責(zé)任！那么，呵呵，客戶先生，對不起了，本次新增加的需求將歸入另外一個(gè)版本。如果是改變前面某個(gè)需求的定義，那么說不定就要推倒重來了，不過這個(gè)時(shí)候到不用太在意，畢竟錯(cuò)的是客戶。 (項(xiàng)目正式開始前沒有沒有說清楚其需 求 )。所以，各位看客，在需求分析做好后，在開工之前一定要叫客戶認(rèn)可簽字，并且在合同上要注明，當(dāng)由客戶原因引起的需求改變而造成開發(fā)成本的增加，客戶要為此買單地。 如果在需求不變的情況之下，設(shè)計(jì)發(fā)生了變化，這個(gè)僅僅是我們內(nèi)部之間的矛盾，商量一下就能解決。在簡單設(shè)計(jì)中，因?yàn)榍捌诘脑O(shè)計(jì)是不完整的，那么當(dāng)進(jìn)入任何一個(gè)新的模塊進(jìn)行開發(fā)時(shí)，都有可能引起設(shè)計(jì)的變化。開發(fā)人員的水平的高低就基本上決定了軟件的好壞。 3 3 代碼編寫 當(dāng)需求定下來數(shù)據(jù)庫也定下來后， 其實(shí)我們就可以進(jìn)行實(shí)質(zhì)性的編碼了，按照我的看法，一個(gè)人單獨(dú)編 程最好，能隨時(shí)偷懶。 (上網(wǎng)，和 MM 聊聊 )，但是現(xiàn)在的軟件項(xiàng)目越來越大，工期也越來越緊，事實(shí)上我們一個(gè)小組里面，一般有 3-5 程序員，所以我們要強(qiáng)調(diào)團(tuán)隊(duì)合作性。那么你寫的代碼使得別人要能夠看懂，我們必須在實(shí)際的編寫代碼過程中要有詳細(xì)的編碼規(guī)范，編碼規(guī)范在很多書籍里面都提到過。 但最起碼以下的一些規(guī)范是我們必須要遵守的： 3 3 1 源程序文件結(jié)構(gòu) 每個(gè)程序文件應(yīng)由標(biāo)題、內(nèi)容和附加說明三部分組成。 （ 1）標(biāo)題：文件最前面的注釋說明，其內(nèi)容主要包括：程序名，作者，版權(quán)信息，簡要說明 等，必要時(shí)應(yīng)有更詳盡的說明（ 將以此部分以空行隔開單獨(dú)注釋）。 （ 2）內(nèi)容控件注冊等函數(shù)應(yīng)放在內(nèi)容部分的最后，類 的定義按 private 、 protected 、 pubilic 、 _pubished 的順序，并盡量保持每一部分只有一個(gè)，各部分中按數(shù)據(jù)、函數(shù)、屬性、事件的順序。 （ 3）附加說明：文件末尾的補(bǔ)充說明，如參考資料等，若內(nèi)容不多也可放在標(biāo)題部分的最后。 3 3 2 界面設(shè)計(jì)風(fēng)格的一致性 由于采用可視化編程，所有的界面均與 Win32 方式類似，相應(yīng)采用的控件等也大都為Windows 操作系統(tǒng)下的標(biāo)準(zhǔn)控件，而且參考了其他一 些市面上相關(guān)的企業(yè)內(nèi)部管理的應(yīng)用軟件。 基于簡單易操作的原則，貼近用戶考慮，用戶界面采用 Windows 風(fēng)格的標(biāo)準(zhǔn)界面，操作方式亦同 Windows 風(fēng)格，這樣在實(shí)施過程，可以降低對客戶的培訓(xùn)，也可以使用戶容易上手，簡單易學(xué)。 3 3 3 編輯風(fēng)格 19 （ 1）縮進(jìn)：縮進(jìn)以 Tab 為單位，一個(gè) Tab 為四個(gè)空格大小。全局?jǐn)?shù)據(jù)、函數(shù) 原型、標(biāo)題、附加說明、函數(shù)說明、標(biāo)號等均頂格書寫。 （ 2）空格：數(shù)據(jù)和函數(shù)在其類型，修飾（如 _fastcall 等）名稱之間適當(dāng)空格并據(jù)情況對 齊。關(guān)鍵字原則上空一格，不論是否有 括號，對語句行后加的注釋應(yīng)用適當(dāng)空格與語句隔開并盡可能對齊。 （ 3）對齊：原則上關(guān)系密切的行應(yīng)對齊，對齊包括類型、修飾、名稱、參數(shù)等各部分對齊。 另每一行的長度不應(yīng)超過屏幕太多，必要時(shí)適當(dāng)換行。 （ 4）空行：程序文件結(jié)構(gòu)各部分之間空兩行，若不必要也可只空一行，各函數(shù)實(shí)現(xiàn)之間一般空兩行。 （ 5）注釋：對注釋有以下三點(diǎn)要求： A、必須是有意義； B、必須正確的描述了程序； C、必須是最新的。 注釋必不可少，但也不應(yīng)過多，以下是四種必要的注釋： 標(biāo)題、附加說明； 函數(shù)說明：對幾乎每個(gè)函數(shù)都應(yīng)有適當(dāng)?shù)?說明，通常加在函數(shù)實(shí)現(xiàn)之前，在沒有函數(shù)實(shí)現(xiàn)部分的情況下則加在函數(shù)原型前，其內(nèi)容主要是函數(shù)的功能、目的、算法等說明，參數(shù)說明、返回 值說明等，必要時(shí)還要有一些如特別的軟硬件要求等說明； 在代碼不明晰或不可移植處應(yīng)有少量說明； 及少量的其它注釋。 3 3 4 命名規(guī)范 堅(jiān)持采用匈牙利變量命名慣例，所有標(biāo)識符一律用英文或英文縮寫，杜絕采用拼音，標(biāo)識符中每個(gè)單詞首字母大寫，縮寫詞匯一般全部大寫，只在必要時(shí)加 “_”間隔詞匯。 3 4 BUG 修補(bǔ) 程序出現(xiàn)了 BUG 誰來修補(bǔ)呢？ 最好的辦法是誰編寫誰修補(bǔ)，誰改壞 誰修補(bǔ)。一個(gè)人改壞的代碼一人去修。兩個(gè)人一起改壞的代碼兩人一起修。 3 5 開發(fā)人員的測試 開發(fā)人員的測試是保證代碼能正常運(yùn)行，在開發(fā)時(shí)候發(fā)現(xiàn)的錯(cuò)誤往往比較容易修正。 (另外一個(gè)好處就是沒有人來罵你。因?yàn)橹挥心阕约褐?)。但是一旦軟件到了測試小組那里出了問題，那么就多了很多時(shí)間來修正 BUG，如果到了客戶哪里才發(fā)現(xiàn)的 BUG，那么時(shí)間就更長了，開發(fā)人員本身受到的壓力也是到了最大話了?？蛻?-公司 -測試小組 -開發(fā)人員。 這個(gè)完全是倒金字塔型的，承受能力差的一環(huán)很容易出事情的。 另外開發(fā)人員的測試除了保證代碼能 正常運(yùn)行以外，還有一個(gè)很重要的方面就是要保證上次能正常運(yùn)行的代碼，這次還是能正常運(yùn)行。如果做不到這點(diǎn)，那么 BUG 就不斷的會(huì)出現(xiàn)，很多 BUG 也會(huì)反復(fù)出現(xiàn)。于是軟件看上去就有修補(bǔ)不完的 BUG 了。如果出現(xiàn)這種情況， 20 那么開發(fā)人員有必要再教育。一般公司教育的方式有四種。第一種，扣工資，第二種，加班，反復(fù)加班 +精神攻擊。 第三種，開除。第四種，調(diào)動(dòng)人員來幫助那個(gè)出了麻煩的家伙。 但愿看這個(gè)文章的人不要受到前面三種教育。 四 軟件測試的若干問題 【摘要】本文針對測試的過程、測試所具備的素質(zhì)、自動(dòng)化測試、測試的誤區(qū)等進(jìn) 行了簡單的探討，希望能給大家以啟示。 【關(guān)鍵詞】測試策略測試計(jì)劃自動(dòng)化測試 30年前，人月神話中說道 “ 不為系統(tǒng)測試安排足夠的時(shí)間簡直就是一場災(zāi)難 ” 10年前，中國的軟件公司大部分只有測試工作而沒有測試人員 5年前，中國的軟件公司開始讓 “ 老弱病殘 ” 做專門的軟件測試 1 年前， 很多中國的軟件公司發(fā)現(xiàn)，沒有通過專業(yè)測試人員測試過的軟件根本不敢給客戶看 4 1 前言 我發(fā)現(xiàn)有一期申江服務(wù)導(dǎo)報(bào)上列舉的最新職業(yè)中，其中有一項(xiàng)是 “ 軟件測試人員 ” ，看到這條消息我感到由衷的欣慰，欣慰之中包含了太多的辛酸和無奈。 時(shí)至今日，我想不管是做測試的還是看測試的，都已經(jīng)有一套理論了。所以本文，我就著重寫點(diǎn)我自己從事測試工作的一些感受。 4 2 博弈的各方 選擇意味著痛苦，這個(gè)世界上沒有選擇，可能生活會(huì)很簡單。人是如此，公司亦然。自從公司內(nèi)部多了一群專職做測試的人或者部門。管理人員發(fā)現(xiàn)，整個(gè)管理的對象中又多了一種人 軟件測試人員。從此項(xiàng)目經(jīng)理、業(yè)務(wù)分析人員、設(shè)計(jì)人員、程序開發(fā)人員、測試人員之間開始溝通了。下面，我個(gè)人對各種角色按照普遍的概念對其做一個(gè)簡單描述： 項(xiàng)目經(jīng)理 ：對項(xiàng)目的所有問題負(fù)責(zé)； 業(yè)務(wù)分析人員 ：清楚的了 解客戶的需求并以文檔形式及時(shí)傳遞給每一個(gè)角色； 設(shè)計(jì)人員 ：根據(jù)需求文檔做概要設(shè)計(jì)（或詳細(xì)設(shè)計(jì)） 程序開發(fā)人員 ：根據(jù)設(shè)計(jì)文檔（可能是自己寫的）開發(fā)軟件； 測試人員 ：根據(jù)需求文檔（或設(shè)計(jì)文檔）設(shè)計(jì)測試用例，并對開發(fā)人員提交的軟件進(jìn)行測試； 問題： 21 如果軟件提交到客戶那邊出現(xiàn)無數(shù)個(gè) Bug，那么是誰的問題？ 我們是否有一套指標(biāo)體系來判斷在哪個(gè)環(huán)節(jié)就已經(jīng)出現(xiàn)問題了？ 測試人員應(yīng)該從哪個(gè)環(huán)節(jié)開始降低風(fēng)險(xiǎn)？ 測試人員被授權(quán)到什么程度？ 測試人員的能力是通過什么被認(rèn)可的？ 老板會(huì)相信誰？ 筆者認(rèn)為，在任 何一個(gè)公司做測試工作首先要搞清楚以上問題?；卮鸷蒙鲜鰡栴}那么測試工作基本上算入門了；能妥善的協(xié)調(diào)上面的問題那么就可以獨(dú)當(dāng)一面了； 4 3 測試的過程 如果拉住一個(gè)測試負(fù)責(zé)人一問，軟件測試的過程是怎么樣的，應(yīng)該會(huì)從計(jì)劃說到發(fā)布。實(shí)際上各個(gè)項(xiàng)目在開展測試的時(shí)候： 1、各個(gè)階段劃分的不會(huì)太明顯； 2、某些階段的功能會(huì)弱化，某些階段的功能會(huì)延伸； 下面我指出目前測試工作中基本上做的不足的或者比較常見的問題（有則改之、無則加勉）： 測試策略文檔的普遍缺失； 測試范圍的確認(rèn)經(jīng)常被其他文檔或經(jīng)驗(yàn)所取代； 測試計(jì)劃受制 于開發(fā)計(jì)劃； 測試任務(wù)應(yīng)該像 BUG一樣有明確的分級，不同類型的測試應(yīng)該有相應(yīng)的測試用例集合與之對應(yīng)； 關(guān)鍵路徑概念在測試規(guī)劃時(shí)容易被項(xiàng)目經(jīng)理弱化。 4 4 測試所具備的素質(zhì) 很多人都在問我，如果我去做測試需要學(xué)一些什么東西比較好。我的答案是，大學(xué)學(xué)了四年，有多少是工作中直接用到的？對工作有指導(dǎo)意義的往往是當(dāng)年根本不當(dāng)一回事的那些知識。 其實(shí)，對于多數(shù)工作，短期內(nèi)能提高的只是方法和技巧?；镜乃刭|(zhì)決定了你人生最終能走多遠(yuǎn)，而方法和技巧必須要到實(shí)際的工作中去摸索。我的建議是： 不要去做自己內(nèi)心就抵制的 工作； 不要首先給自己下一個(gè)定義， “ 我適合做什么 ” ； 在中國很少有人把自己的工作當(dāng)作自己的樂趣，如果你是這樣，那么放下這篇文章，去工作吧； 我們在做一件必須要做的事情時(shí)，不管你喜歡不喜歡，先把它做好； 4 5 自動(dòng)化測試 這是一個(gè)不得不提的話題。 沒有做過自動(dòng)化測試的人，都夢想能精通一個(gè)自動(dòng)化工具，期望以此來提高自己的江湖地位，并解決手工測試帶來的痛苦； 正在做自動(dòng)化測試的人，都很清楚自動(dòng)化往往是一個(gè)大麻煩，老板總認(rèn)為自動(dòng)化上來了（當(dāng)然是盜版的）就能解決所有的問題，堵槍眼就靠他了； 其實(shí)，自 動(dòng)化測試是一個(gè)很廣泛的概念，目的不同需要的工具也不一樣，每種工具都有自己 22 獨(dú)特的屬性，在做一般功能測試的時(shí)候往往覺得所有的工具都差不多，當(dāng)自動(dòng)化測試開展到一定精細(xì)程度的時(shí)候，就會(huì)發(fā)現(xiàn)最初選擇工具的重要性了。 開展自動(dòng)化測試必須要做的兩件事情： 1、首先需要判斷所測試的軟件是否合適做自動(dòng)化測試； 2、選擇一個(gè)合適的工具； 4 6 測試的誤區(qū) 作為測試人員我們一定要搞清楚一點(diǎn)：我們不是救世主 軟件開發(fā)是一個(gè)系統(tǒng)工程，決定一個(gè)項(xiàng)目（產(chǎn)品）的成敗是所有環(huán)節(jié)和參與人員的合力的結(jié)果，在整個(gè)過程中的任何一個(gè)環(huán)節(jié)出現(xiàn)問題都 可能導(dǎo)致最終的客戶滿意度的下降。問題往往暴露在測試這個(gè)階段，即使很多企業(yè)號稱全面質(zhì)量管理，往往也是如此。 并不是有了測試人員軟件質(zhì)量就有了保障。目前所有有測試人員的公司都或多或少的有一種傾向：有了測試人員那么質(zhì)量就有保障了，這句話反過來理解就是，如果軟件質(zhì)量出了問題那么就是測試人員的問題。如果這種觀點(diǎn)是正確的話，那么沒有測試人員參與的產(chǎn)品質(zhì)量就應(yīng)該是最好的，而事實(shí)上并非如此。 五 淺談功能測試用例模板設(shè)計(jì) 【摘要】 本文介紹測試用例一般要素 以及 如何根據(jù)項(xiàng)目特點(diǎn)設(shè)計(jì)測試用例模板， 用以 提高測試用例設(shè) 計(jì)效率和實(shí)現(xiàn)測試用例執(zhí)行結(jié)果報(bào)告的自動(dòng)化計(jì)算，分析測試用例覆蓋率。 【關(guān)鍵字】 測試用例 模板 測試覆蓋率 測試用例設(shè)計(jì)和執(zhí)行是測試工作的核心，也是工作量最大的任務(wù)之一，設(shè)計(jì)良好的測試用例模板能提高測試用例的設(shè)計(jì)質(zhì)量，便于跟蹤測試用例的執(zhí)行結(jié)果，自動(dòng)生成測試用例覆蓋率報(bào)告。這幾年測試技術(shù)和理論有了長足的發(fā)展，就功能測試用例設(shè)計(jì)要素而言，樣式上均大同小異，一般都包含主題、前置條件、執(zhí)行步驟、期望結(jié)果等。 測試用例可以用數(shù)據(jù)庫、 Word 、 Excel 、 xml 等格式進(jìn)行管理，市面亦有成熟的商業(yè)軟件工具和 開源工具等，對于一般中小軟件企業(yè)，使用文檔來管理測試用例是較為方便、經(jīng)濟(jì)的途徑。 Word 格式的文檔可以滿足設(shè)計(jì)需要，但不利于跟蹤和自動(dòng)統(tǒng)計(jì)執(zhí)行結(jié)果報(bào)告。 5 1 Excel 模版 下面我將介紹自己在多個(gè)項(xiàng)目中設(shè)計(jì)和改進(jìn)的 Excel 模版，它可以方便地設(shè)計(jì)測試用例，記錄執(zhí)行結(jié)果并自動(dòng)統(tǒng)計(jì)測試用例覆蓋率。圖 -1 為 Excel 模板。具體細(xì)目說明如下： 23 圖 -1 Excel 模板 測試用例 ID 用于唯一標(biāo)識測試用例號，可根據(jù)自身需要定義規(guī)則，最好易于跟蹤和維護(hù)； 測試前置條件 如果有則描述之； 測試用例等級 根據(jù)需求重要性區(qū)分測試用例等級，測試執(zhí)行階段可以根據(jù)測試用例等級安排測試任務(wù)，分為四級： 冒煙測試，即版本確認(rèn)測試，每個(gè)測試版本需通過所有該級測試用例，否則拒絕繼續(xù)測試； 關(guān)鍵路徑測試，每個(gè)測試版本需執(zhí)行該級測試用例，若該級測試用例均通過，意味著軟件功能趨于穩(wěn)定； 可接受級測試，該級測試用例只要執(zhí)行一次通過即可，該級測試用例通過意味著可以準(zhǔn)備發(fā)布了； 建議執(zhí)行的用例，如果有時(shí)間，最好執(zhí)行該級測試用例，但不作為發(fā)布的必要條件。 測試用例執(zhí)行步驟、期望結(jié)果； 測試用例執(zhí)行結(jié)果 執(zhí)行時(shí)填寫，分為通過、失敗、警告、阻塞、忽略。 通過開發(fā) VBA 腳本，可以自動(dòng)統(tǒng)計(jì)每輪測試用例執(zhí)行結(jié)果，如圖 -2 所示，得到測試用例覆蓋率結(jié)果報(bào)告，用于分析測試結(jié)果。 圖 -2 測試用例覆蓋率分析報(bào)告 24 5 2 測試用例狀態(tài)轉(zhuǎn)換分析 圖 -3 顯示了一個(gè)典型測試用例的生命周期，依據(jù)不同類型和規(guī)模的項(xiàng)目可以自行定制。 圖 -3 測試用例生命周期 隊(duì)列中（ In Queue ） - 測試用例在排隊(duì)等待 中； 進(jìn)程中（ In Progress ） - 表示測試正在進(jìn)行，并且可能會(huì)持續(xù)一段時(shí)間，如果一個(gè)測試花費(fèi)的時(shí)間少于一天或兩天，只需將它顯示在處于排隊(duì)狀態(tài)； 阻塞（ Block ） - 一些外部條件 如缺少部分功能 將無法執(zhí)行測試； 忽略（ Skip ） - 已經(jīng)決定（或被告知）跳過這個(gè)測試用例； 通過（ Pass ） - 終點(diǎn)狀態(tài)，沒問題； 失?。?Fail ） - 測試用例執(zhí)行出錯(cuò)； 警告（ Warn ） - 結(jié)果處于 Pass 和 Fail 之間，錯(cuò)誤嚴(yán)重性等級較輕，不 影響功能和性能； 關(guān)閉（ Closed ） - 以前識別出的錯(cuò)誤都已經(jīng)被修正。 實(shí)際項(xiàng)目中，一個(gè)測試用例有多個(gè)執(zhí)行步驟，每個(gè)步驟可能有不同結(jié)果，如步驟 1 通過，步驟 2 失敗，步驟 3 被步驟 2 中的失敗所阻塞，那么該測試狀態(tài)如何？單純指出這個(gè)測試用例阻塞或失敗都將遺漏重要的信息。因此必須指定雙重狀態(tài)，如 Block/Fail ， Block/Warn ， Skip/Pass ， Skip/Closed 等。然而，如果顯示十幾個(gè)狀態(tài)，則測試結(jié)果可能更難以解釋。如何使結(jié)果明了又能精確反映實(shí)際結(jié)果，需 要精明選擇包括哪些狀態(tài)。 使用該模板優(yōu)點(diǎn)：使用維護(hù)簡便，方便測試任務(wù)分配，易于與項(xiàng)目組其他角色交流，結(jié)果報(bào)告自動(dòng)生成。 不足之處：測試變更跟蹤不方便，每個(gè)測試用例的規(guī)模不等，所以測試覆蓋率結(jié)果只是作為參考，結(jié)果百分比不能精確反映工作量，需要具體分析項(xiàng)目情況。這個(gè)模版沒有跟蹤統(tǒng)計(jì)缺陷，同時(shí)考慮是否使用加權(quán)評估缺陷嚴(yán)重性，一個(gè)測試用例往往對應(yīng)幾個(gè)缺陷的統(tǒng)計(jì)分析。 結(jié)論：在實(shí)際項(xiàng)目中，應(yīng)該根據(jù)項(xiàng)目特點(diǎn)和開發(fā)流程定義測試用例各項(xiàng)。在精確和簡單兩個(gè)特性相對立時(shí)，需要好好權(quán)衡。如果您有好的解決方案，我將很樂意知道 。 六 如何提高軟件質(zhì)量 【摘要】 軟件質(zhì)量是軟件產(chǎn)品的靈魂。本文全面介紹了質(zhì)量的概念，提出了從流程、技術(shù)、 25 組織管理、人員技能發(fā)展等多個(gè)角度提高軟件質(zhì)量的重要性；并對目前國際上流行的 CMM 標(biāo)準(zhǔn)進(jìn)行了介紹，提出了使用 PSP 和 TSP 來實(shí)現(xiàn) CMM 的方法。本文最后還給出了中小型軟件公司在提高軟件質(zhì)量方面的一個(gè)初步思路。 【關(guān)鍵字】 質(zhì)量管理，軟件開發(fā)過程模型，軟件分析和設(shè)計(jì)方法，軟件測試， CMM 如何提高軟件的質(zhì)量已經(jīng)不是一個(gè)純粹的技術(shù)問題，而是一個(gè)工程的問題。自從計(jì)算機(jī)誕生以來，相應(yīng)的軟件 開發(fā)就存在了。由于早期的計(jì)算機(jī)運(yùn)行性能較低，軟件的可編程范圍也較狹窄，因此質(zhì)量問題就沒有那么突出。 50 年代后期到 60 年代，高級語言的相繼誕生并得到了廣泛的應(yīng)用，隨之而來的是軟件規(guī)模也越來越龐大，越來越復(fù)雜。伴隨著軟件應(yīng)用的越來越廣泛，軟件的質(zhì)量問題就變得越來越突出。根據(jù)美國國家宇航局 NASA 的統(tǒng)計(jì)，在 80 年代初，軟件引起的故障與硬件引起的故障，其比率約為 1.1:1.0 ，到了 80 年代末，這一比率已達(dá)到 2.5:1.0 。因此如何提高軟件的質(zhì)量成為軟件工程研究的一個(gè)重點(diǎn)。自從軟件危機(jī)產(chǎn)生 以來，出現(xiàn)了很多提高產(chǎn)品質(zhì)量的理論和方法，有的從技術(shù)角度出發(fā)，例如：面向?qū)ο蠹夹g(shù)的產(chǎn)生和推廣，第四代語言的誕生等等；有的從自動(dòng)化工具入手，例如： CASE 工具、過程控制軟件、自動(dòng)化管理平臺等；有的從過程模型角度出發(fā)，例如：迭代模型、螺旋模型、 RUP 、 IPD 、凈室軟件工程等；也有從管理角度出發(fā)的，例如：團(tuán)隊(duì)管理、績效管理、 PSP 、 TSP 等；也有從測試角度出發(fā)的，例如：加強(qiáng)全流程的測試等；一些相應(yīng)的規(guī)范和標(biāo)準(zhǔn)也孕育而生，例如： ISO9000 系列、 CMM 、 QMS 等。然而每一種技術(shù)都不 是絕對的，軟件質(zhì)量的提高應(yīng)該是一個(gè)綜合的因素，需要從每個(gè)方面進(jìn)行改進(jìn)，同時(shí)還需要兼顧成本和進(jìn)度。 6 1 什么是質(zhì)量 作為軟件產(chǎn)品的銷售人員，市場人員或維護(hù)人員經(jīng)常會(huì)受到客戶這樣那樣的指責(zé)或抱怨，客戶說：你們產(chǎn)品的質(zhì)量太差，不穩(wěn)定等等。那么什么是質(zhì)量呢？我們該如何來衡量質(zhì)量呢？ 質(zhì)量具有三個(gè)維度： 符合目標(biāo)。目標(biāo)是客戶所定義的，符合目標(biāo)即判斷我們是不是在做需要做的事情。 符合需求。即產(chǎn)品是不是在做讓它做的事情。 符合實(shí)際需求。實(shí)際的需求包括用戶明確說明的和隱含的需求。 ISO 關(guān)于質(zhì)量的定義表示如下： “ 一個(gè)實(shí)體（產(chǎn)品或服務(wù)）的所有特性，基于這些特性可以滿足明顯的或隱含的需要。 ” 注意，在這個(gè)定義中包含明顯的需求和隱含的需求。而往往我們會(huì)忽略隱含的需求。因此在控制一個(gè)產(chǎn)品的質(zhì)量的過程中必須關(guān)注這些隱含的需求，并給予應(yīng)有的驗(yàn)證。 另一方面因?yàn)槲覀兊漠a(chǎn)品是為客戶提供服務(wù)的，因此凡是不滿足客戶需求的，我們都認(rèn)為是一個(gè)失效（ failure ）。所以我們的產(chǎn)品必須始終圍繞著客戶的需求進(jìn)行開發(fā)和驗(yàn)證。 這里我們談到客戶，其實(shí)在一個(gè)軟件的需求收集過程中需要關(guān)注客戶和用戶。而我 們經(jīng)常會(huì)忽略客戶與用戶之間的區(qū)別。那么誰是客戶？誰是用戶呢？簡單的來說，客戶是真正能夠決定是否購買你軟件的人，而用戶是實(shí)際使用軟件的人。了解了這個(gè)區(qū)別，對于你在分析需求的重要性的時(shí)候就可以進(jìn)行參考。同時(shí)在產(chǎn)品質(zhì)量驗(yàn)證的時(shí)候也可以做出不同的權(quán)衡。另一方面我們在考慮我們用戶需求的時(shí)候，往往只考慮了實(shí)際使用軟件的人員，而忽略了其它一些人員對軟件的要求或?qū)浖斐傻臐撛诟偁帲@包括維護(hù)人員的要求、系統(tǒng)管理人員的要求、軟件上下游人員的要求、先前版本的情況、市場上競爭對手的軟件情況等。 每個(gè)人提到質(zhì)量的時(shí)候，經(jīng)常會(huì)遇 到下列矛盾，在這些矛盾中隱含著對質(zhì)量的承諾【 5 】： 質(zhì)量需要一個(gè)承諾，尤其是高層管理者的承諾。但為了得到質(zhì)量，高層管理者必須和其雇用的員工進(jìn)行緊密合作； 許多人相信沒有缺陷的產(chǎn)品和服務(wù)是不可能的。但是控制在一定級別的缺陷數(shù)是正常并 26 可接受的； 質(zhì)量經(jīng)常是和成本緊密聯(lián)系在一起，一個(gè)高質(zhì)量的產(chǎn)品同時(shí)也意味著高投入。這是設(shè)計(jì)的質(zhì)量和一致性質(zhì)量的一個(gè)矛盾； 一個(gè)高的質(zhì)量要求需求規(guī)格說明書足夠詳細(xì)，以便產(chǎn)品可以根據(jù)這些規(guī)格說明書進(jìn)行定量的分析。然而許多組織沒有能力或者不愿意產(chǎn)生如此詳 細(xì)程度的規(guī)格說明書； 技術(shù)人員經(jīng)常相信規(guī)范和標(biāo)準(zhǔn)會(huì)束縛他們的創(chuàng)造力，因此就不遵照標(biāo)準(zhǔn)做事。然而如果要得到高質(zhì)量的產(chǎn)品，就必須遵循良好定義的標(biāo)準(zhǔn)和過程。 6 2 流程對質(zhì)量的貢獻(xiàn) 好了，既然已經(jīng)了解了什么是質(zhì)量，那么怎么才能改進(jìn)軟件產(chǎn)品的質(zhì)量呢？從一個(gè)企業(yè)的長遠(yuǎn)發(fā)展來看，首先應(yīng)當(dāng)從流程抓起，規(guī)范軟件產(chǎn)品的開發(fā)過程。這是一個(gè)軟件企業(yè)從小作坊的生產(chǎn)方式向集成化、規(guī)范化的大公司邁進(jìn)的必經(jīng)之路，也是從根本上解決質(zhì)量問題，提高工作效率的一個(gè)關(guān)鍵手段。 軟件產(chǎn)品的開發(fā)同其它產(chǎn)品（如汽車）的生產(chǎn)有著共同特性 ，即需要按一定的過程來進(jìn)行生產(chǎn)。在工業(yè)界，流水線生產(chǎn)方式被證明是一種高效且能夠比較穩(wěn)定地保證產(chǎn)品質(zhì)量的一種方式。通過這種方式，不同的人員被安排在流程的不同位置，最終為著一個(gè)目標(biāo)共同努力，這樣可以防止人員工作間的內(nèi)耗，極大的提高工作效率。并且由于其過程來源于成功的實(shí)例，因此其最終的產(chǎn)品質(zhì)量能夠滿足過程所設(shè)定的范圍要求。軟件工程在軟件的發(fā)展過程中吸取了這個(gè)經(jīng)驗(yàn)并把它應(yīng)用到了軟件開發(fā)中，這就形成了軟件工程過程，簡單的說就是開發(fā)流程。 無論做什么事情，都有一個(gè)循序漸進(jìn)的過程，從計(jì)劃到策略再到實(shí)現(xiàn)。軟件流程就是按照 這種思維來定義開發(fā)過程，它根據(jù)不同的產(chǎn)品特點(diǎn)和以往的成功經(jīng)驗(yàn)，定義了從需求到最終產(chǎn)品交付的一整套流程。流程告訴我們該怎么一步一步去實(shí)現(xiàn)產(chǎn)品，可能會(huì)有那些風(fēng)險(xiǎn)，如何去避免風(fēng)險(xiǎn)等等。由于流程來源于成功的經(jīng)驗(yàn)，因此，按照流程進(jìn)行開發(fā)可以使得我們少走彎路，并有效的提高產(chǎn)品質(zhì)量，提高用戶的滿意度。 目前流行的流程方法有很多種，不同的過程模型適合于不同類型的項(xiàng)目。瀑布模型是應(yīng)用的最為廣泛的一種模型，也是最容易理解和掌握的模型，然而它的缺陷也是顯而易見的。遺漏的需求或者不斷變更的需求會(huì)使得該模型無所適從。然而，對于那些 容易理解但很復(fù)雜的項(xiàng)目，采用瀑布模型會(huì)是比較適合的，因?yàn)槟憧梢园床烤桶嗟娜ヌ幚韽?fù)雜的問題。在質(zhì)量要求高于成本和進(jìn)度要求的時(shí)候，該模型表現(xiàn)的尤其突出。 螺旋模型是也是一個(gè)經(jīng)典模型，它關(guān)注于發(fā)現(xiàn)和降低項(xiàng)目的風(fēng)險(xiǎn)【 8 】。螺旋型項(xiàng)目從小的規(guī)模開始，然后探測風(fēng)險(xiǎn)，制定風(fēng)險(xiǎn)控制計(jì)劃，接著確定下一步項(xiàng)目是否還要繼續(xù)，然后進(jìn)行下一個(gè)螺旋的反復(fù)。該模型的最大優(yōu)點(diǎn)就是隨著成本的增加，風(fēng)險(xiǎn)程度隨之降低。然而螺旋模型的缺點(diǎn)是比較復(fù)雜，且需要管理人員有責(zé)任心，專注以及有管理方面經(jīng)驗(yàn)。 RUP （ Rational Unified Process ）是 Rational 公司提出的一套開發(fā)過程模型，它是一個(gè)面向?qū)ο筌浖こ痰耐ㄓ脴I(yè)務(wù)流程【 9 】。它描述了一系列相關(guān)的軟件工程流程，它們具有相同的結(jié)構(gòu)，即相同的流程構(gòu)架。 RUP 為在開發(fā)組織中分配任務(wù)和職責(zé)提供了一種規(guī)范方法，其目標(biāo)是確保在可預(yù)計(jì)的時(shí)間安排和預(yù)算內(nèi)開發(fā)出滿足最終用戶需求的高品質(zhì)的軟件。 RUP 具有兩個(gè)軸，一個(gè)是時(shí)間軸，這是動(dòng)態(tài)的。另一個(gè)是工作流軸，這是靜態(tài)的。在時(shí)間軸上， RUP 劃分了四個(gè)階段：初始階段、細(xì)化階段、構(gòu)造階段和發(fā)布階段。每個(gè)階段都使用了迭代的概念 。在工作流軸上， RUP 設(shè)計(jì)了六個(gè)核心工作流程和三個(gè)核心支撐工作流程，核心工作流軸包括：業(yè)務(wù)建模工作流、需求工作流、分析設(shè)計(jì)工作流、實(shí)現(xiàn)工作流、測試工作流和發(fā)布工作流。核心支撐工作流包括：環(huán)境工作流、項(xiàng)目管理工作流和配置與變更管理工作流。具體可以參考圖 1 。 RUP 匯集現(xiàn)代軟件開發(fā)中多方面的最佳經(jīng)驗(yàn)，并為適 27 應(yīng)各種項(xiàng)目及組織的需要提供了靈活的形式。作為一個(gè)商業(yè)模型，它具有非常詳細(xì)的過程指導(dǎo)和模板。但是同樣由于該模型比較復(fù)雜，因此在模型的掌握上需要花費(fèi)比較大的成本。尤其對項(xiàng)目管理者提出了比較高的要求。 圖 1 RUP 工作流程示意圖 IPD （ Integrated Product Development ）流程是由 IBM 提出來的一套集成產(chǎn)品開發(fā)流程，非常適合于復(fù)雜的大型開發(fā)項(xiàng)目，尤其涉及到軟硬件結(jié)合的項(xiàng)目。 IPD 從整個(gè)產(chǎn)品角度出發(fā)，流程綜合考慮了從系統(tǒng)工程、研發(fā)（硬件、軟件、結(jié)構(gòu)工業(yè)設(shè)計(jì)、測試、資料開發(fā)等）、 制造、財(cái)務(wù)到市場、采購、技術(shù)支援等所有流程。是一個(gè)端到端的流程。在 IPD 流程中總共劃分了六個(gè)階段（概念階段、計(jì)劃階段、開發(fā)階段、驗(yàn)證階段、發(fā)布階段和生命周期階段），四個(gè)個(gè)決策評審點(diǎn)（概念階段決策評審點(diǎn)、計(jì)劃階段決策評審點(diǎn)、可獲得性決策評審點(diǎn)和生命周期終止決策評審點(diǎn)）以及六個(gè)技術(shù)評審點(diǎn)，具體可以參考圖 2 。 IPD 流程是一個(gè)階段性模型，具有瀑布模型的影子。該模型通過使用全面而又復(fù)雜的流程來把一個(gè)龐大而又復(fù)雜的系統(tǒng)進(jìn)行分解并降低風(fēng)險(xiǎn)。一定程度上，該模型是通過流程成本來提高整個(gè)產(chǎn)品的質(zhì)量并獲得市場的占有。 由于該流程沒有定義如何進(jìn)行流程回退的機(jī)制，因此對于需求經(jīng)常變動(dòng)的項(xiàng)目該流程就顯得不大適合了。并且對于一些小的項(xiàng)目，也不是非常適合使用該流程。 28 圖 2 IPD 流程示意圖 6 3 流程與技術(shù) 流程和成功不是等價(jià)的。沒有流程就成功是不可能得到保證，但有了流程并不意味著肯定能夠成功。這恐怕是很多迷信于流程的人所不能接受的 。但這的確是個(gè)事實(shí)。記得有個(gè)做了將近 30 多年的需求分析專家說過：即使是一個(gè)已經(jīng)達(dá)到 CMM4 級的公司，也完全有可能做不好需求分析。為什么？技術(shù)，技術(shù)是成功的另外一個(gè)必要條件。就好比現(xiàn)在你要從上海到北京去，流程給你指出了最短的路徑，技術(shù)提供給你最快的交通工具。兩者結(jié)合就是完美。 對于軟件開發(fā)來說，要保證軟件的質(zhì)量，需要掌握多方面的技術(shù)，包括分析技術(shù)、設(shè)計(jì)技術(shù)、編碼技術(shù)和測試技術(shù)等等。在國內(nèi)有一個(gè)普遍的非正?，F(xiàn)象，就是大家覺得只有編程能力才是玩電腦的真正技能。就好像造一套房子，其它都不重要，只要磚瓦匠有 高超的技能就行了。盡管這個(gè)比喻會(huì)打擊很多程序員的自尊心，但這的確是一個(gè)事實(shí)。我們?nèi)鄙傧到y(tǒng)級的工程師，在分析和設(shè)計(jì)方面的工作做得很不扎實(shí)。 需求是一個(gè)項(xiàng)目的靈魂。模棱兩可的需求帶來不可避免的后果便是返工 重做一些你認(rèn)為已做好的事情。返工會(huì)耗費(fèi)開發(fā)總費(fèi)用的 4 0 % ，而 7 0 % 8 5 % 的重做是由于需求方面的錯(cuò)誤所導(dǎo)致的（ l e ff i n g w e l l1 9 9 7 ）【 10 】。想像一下如果你能減少一半的返工會(huì)是怎樣的情況？你能更快地開發(fā)出產(chǎn)品，在同樣的時(shí)間內(nèi)開發(fā)更多、更 好的產(chǎn)品，甚至能偶爾回家休息休息。在軟件需求一書中關(guān)于如何進(jìn)行需求分析給出了比較詳細(xì)的介紹【 7 】， RUP 中關(guān)于需求的指導(dǎo)也是很實(shí)用的。 設(shè)計(jì)是最能體現(xiàn)一個(gè)工程師能力和水平的環(huán)節(jié)。一個(gè)好的設(shè)計(jì)基本上決定了產(chǎn)品的最終質(zhì)量。設(shè)計(jì)是把需求轉(zhuǎn)換成系統(tǒng)的一個(gè)關(guān)鍵步驟，它需要從自然語言描述的需求中尋找出設(shè)計(jì)的基礎(chǔ)單元，構(gòu)建出整個(gè)系統(tǒng)的構(gòu)架。在 RUP 中關(guān)于系統(tǒng)構(gòu)架師和設(shè)計(jì)師的定位是相當(dāng)高的。關(guān)于設(shè)計(jì)方面的技能涉及面是很廣的，包括傳統(tǒng)的結(jié)構(gòu)化設(shè)計(jì)到面向?qū)ο笤O(shè)計(jì)。設(shè)計(jì)人員需要掌握一定的建模技術(shù)。 UML 是國 際上比較流行的一種建模語言【 11 】。在嵌入式 29 方面， SDL 也是一種非常好的選擇。設(shè)計(jì)模式是在設(shè)計(jì)思想方面總結(jié)的非常出色的一本書【 6 】，作為一名設(shè)計(jì)人員（尤其是面向?qū)ο笤O(shè)計(jì)人員）必須要好好研究一下。但是對這些模式的應(yīng)用應(yīng)當(dāng)講究一種自然的應(yīng)用，千萬不要因?yàn)槟Ｊ蕉ピO(shè)計(jì)模式，否則會(huì)適得其反。 現(xiàn)在的程序員熱中于掌握多種編程語言，或者講究語言的過分技巧化，而往往忽略了編程語言的規(guī)范化。不規(guī)范的語言應(yīng)用給程序的可理解性、可維護(hù)性以及可測試性帶來了大的傷害，進(jìn)而損害了產(chǎn)品的質(zhì)量。某公司曾對中國程序員和印 度程序員做過一個(gè)測驗(yàn)，這個(gè)測驗(yàn)要求參加者對一組數(shù)進(jìn)行排序。測試結(jié)果發(fā)現(xiàn)，印度程序員設(shè)計(jì)的程序使用的算法并不是最優(yōu)，但卻是最不容易出錯(cuò)的，并且?guī)讉€(gè)程序員寫出來的代碼如出一轍。而幾個(gè)中國程序員寫出的代碼，有的非常漂亮，很精練，效率很高；有的卻很冗雜，還有錯(cuò)誤。如果大家是在做研究性的項(xiàng)目或純粹興趣性的項(xiàng)目，那么充分發(fā)揮自己的編程天才也無可厚非。然而，對于一個(gè)軟件公司，產(chǎn)品最終是要交給用戶的，需要遵循的是一個(gè)軟件產(chǎn)品的開發(fā)工程。因此這類軟件的開發(fā)需要遵循一定的編程規(guī)范，畢竟開發(fā)的軟件不是自己用，還需要和別人的集成， 還需要給以后版本重用和維護(hù)。 測試的技術(shù)將在第五節(jié)進(jìn)行闡述?？傊鞒毯荜P(guān)鍵，技術(shù)也很重要，我的觀點(diǎn)是：魚和熊掌，兩者都不能放。 6 4 全面質(zhì)量管理 自從 Deming 的全面質(zhì)量管理（ TQM ）原則在日本工業(yè)界獲得了巨大成功之后，這個(gè)原則迅速被傳播到了世界各個(gè)地方，同樣，全面質(zhì)量管理原則也被應(yīng)用到了軟件開發(fā)當(dāng)中。如前面提到的，軟件開發(fā)也是一個(gè)工程性的工作，因此必須提高整個(gè)工程的質(zhì)量。 產(chǎn)業(yè)界的大量研究（ TRW 、 Nippon Electric 和 Mitre Corp. 以及其它一些公司）表 明設(shè)計(jì)活動(dòng)引入的錯(cuò)誤占軟件過程中出現(xiàn)所有錯(cuò)誤（和最終的缺陷）數(shù)量的 50 到 65 。根據(jù) IBM 的研究表明，假定在分析階段發(fā)現(xiàn)的錯(cuò)誤其改正成本為 1 個(gè)單位的話，那么在測試之前（設(shè)計(jì)編碼階段）發(fā)現(xiàn)一個(gè)錯(cuò)誤的修改成本約為 6.5 個(gè)貨幣單位，在測試時(shí)（集成測試，系統(tǒng)測試和驗(yàn)收測試）發(fā)現(xiàn)一個(gè)錯(cuò)誤的修改成本約為 15 個(gè)貨幣單位，而在發(fā)布之后（已經(jīng)交到用戶手上）發(fā)現(xiàn)一個(gè)錯(cuò)誤的修改成本約為 60 到 100 個(gè)貨幣單位。同樣該比例也適用用于發(fā)現(xiàn)一個(gè)錯(cuò)誤需要的時(shí)間。我們可以看下面兩條曲線圖： 30 圖 3 缺陷代價(jià)曲線 為了提高產(chǎn)品質(zhì)量，縮短產(chǎn)品開發(fā)進(jìn)度，節(jié)約產(chǎn)品開發(fā)成本，必須盡早的進(jìn)行產(chǎn)品質(zhì)量控制。全面質(zhì)量控制要求在過程的每個(gè)階段每個(gè)步驟上都要進(jìn)行嚴(yán)格的驗(yàn)證和確認(rèn)活動(dòng)。 什么是驗(yàn)證？ 驗(yàn)證 就是要用數(shù)據(jù)證明我們是不是在正確的制造產(chǎn)品。注意這里強(qiáng)調(diào)的是過程的正確行【 12 】。 什么是確認(rèn)？ 確認(rèn) 就是要用數(shù)據(jù)證明我們是不 是制造了正確的產(chǎn)品。注意這里強(qiáng)調(diào)的是結(jié)果的正確性。 IEEE 給出的驗(yàn)證和確認(rèn)過程可以用下圖來表示。驗(yàn)證和確認(rèn)是一個(gè)廣泛的概念，感興趣的讀者可以參考 IEEE Std 1012-1998 。 圖 4 驗(yàn)證和確認(rèn)模型 6 5 關(guān)注測試 軟件測試是軟件質(zhì)量控制中的關(guān)鍵活動(dòng)。業(yè)界的統(tǒng)計(jì)數(shù)據(jù)表明，測試的成本大約占軟件 開發(fā)總成本的 50 左右。 軟件測試的目的是要發(fā)現(xiàn)軟件中的錯(cuò)誤。一個(gè)好的測試是發(fā)現(xiàn)至今沒有被發(fā)現(xiàn)的錯(cuò)誤。傳統(tǒng)的軟件測試專注于動(dòng)態(tài)測試范疇，如：單元測試，集成測試和系統(tǒng)測試。而測試工程的發(fā)展已經(jīng)進(jìn)入到了全流程的測試，包括開發(fā)過程前期的靜態(tài)測試。 一般我們可以把測試分為白盒測試和黑盒測試。 白盒測試 ：顧名思義，白盒測試應(yīng)當(dāng)是透明的。的確，該類測試是根據(jù)程序代碼的內(nèi)部邏輯結(jié)構(gòu)來設(shè)計(jì)測試用例進(jìn)行測試。那么什么是測試用例？ 一個(gè) 測試用例 就是一個(gè)文檔，描述輸入、動(dòng)作、或者時(shí)間和一個(gè)期望的結(jié)果，其目的是確定 應(yīng)用程序的某個(gè)特性是否正常的工作。 黑盒測試 ：看了白盒測試的解釋，我想你很快就能猜出黑盒測試是不考慮程序內(nèi)部結(jié)構(gòu)情 31 況的。事實(shí)上也是這樣。黑盒測試是根據(jù)規(guī)格說明書進(jìn)行的測試。 規(guī)格說明書 記錄了用戶的需求。比如用戶希望在編輯器中增加查找功能，那么我們把該需求寫入規(guī)格說明書，根據(jù)該項(xiàng)要求，直接調(diào)用應(yīng)用程序的該項(xiàng)功能進(jìn)行測試，而不管其內(nèi)部是用什么算法實(shí)現(xiàn)的。 白盒和黑盒這兩類測試是從完全不同的出發(fā)點(diǎn)，并且是兩個(gè)完全對立點(diǎn)，反映了事物的兩個(gè)極端，兩種方法各有側(cè)重，不能替代。但是在現(xiàn)代測試?yán)砟钪校@兩種測試往往 不是決然分開的，一般在白盒測試中交叉使用黑盒測試的方法，在黑盒測試中交叉使用白盒測試的方法。 常見的白盒測試是單元測試。 單元測試 是測試中最小單位的測試。簡而言之，就是拿一個(gè)函數(shù)出來，加上驅(qū)動(dòng)模塊，樁模塊，讓它能夠運(yùn)行起來，然后設(shè)計(jì)一些用例測試其內(nèi)部的控制點(diǎn)（如：條件判斷點(diǎn)，循環(huán)點(diǎn)，選擇分支點(diǎn)等）。 驅(qū)動(dòng)模塊 是模擬調(diào)用被測函數(shù)的函數(shù)。 樁函數(shù) 是模擬當(dāng)前測試函數(shù)所調(diào)用的函數(shù)。 常見的黑盒測試包括：集成測試，系統(tǒng)測試。 集成測試 是在單元測試的基礎(chǔ)上，將所有模塊按照設(shè)計(jì)要求（如根據(jù)結(jié)構(gòu)圖）組裝成為子系 統(tǒng)或系統(tǒng)，進(jìn)行集成測試。實(shí)踐表明，一些模塊雖然能夠單獨(dú)地工作，但并不能保證連接起來也能正常的工作。程序在某些局部反映不出來的問題，在全局上很可能暴露出來，影響功能的實(shí)現(xiàn)。 系統(tǒng)測試 的目的在于通過與系統(tǒng)的需求定義作比較，發(fā)現(xiàn)軟件與系統(tǒng)定義不符合或與之矛盾的地方。系統(tǒng)測試的測試用例應(yīng)根據(jù)需求分析說明書來設(shè)計(jì)，并在實(shí)際使用環(huán)境下來運(yùn)行。系統(tǒng)測試的內(nèi)容極其廣泛，包括功能測試、協(xié)議測試、性能測試、壓力測試、容量測試等等。有關(guān)測試方面的概念可以參考本人已出版的軟件測試技術(shù)概論。 軟件測試是產(chǎn)品最終交付到用戶之 前的最后一道防線，有著舉足輕重的地位。然而，做好軟件測試卻是不容易的，一方面你需要同時(shí)掌握軟件開發(fā)的技能和軟件測試方面的技能；另一方面產(chǎn)品必須給予測試充分的獨(dú)立性和資源保證。 6 6 成功的鐵三角 在一個(gè)軟件企業(yè)中，如果能夠良性的發(fā)展，必須關(guān)注組織，流程和人三者之間的關(guān)系。組織是流程成功實(shí)施的保障，好的組織結(jié)構(gòu)能夠有效的促進(jìn)流程的實(shí)施；流程對于產(chǎn)品的成功有著關(guān)鍵的作用，一個(gè)適合于組織特點(diǎn)和產(chǎn)品特點(diǎn)的流程能夠極大的提高產(chǎn)品開發(fā)的效率和產(chǎn)品質(zhì)量，反之則會(huì)拖延產(chǎn)品開發(fā)進(jìn)度，并且質(zhì)量也無法得到保證；對企業(yè)來說 ，人是最寶貴的財(cái)富，它們是技術(shù)的載體。對于一個(gè)軟件公司來說，無論是開發(fā)人員還是測試人員，都非常關(guān)心其今后的發(fā)展通道，如果有一條清晰的技術(shù)發(fā)展線為其指明今后的職業(yè)發(fā)展方向的話，這可以大大激勵(lì)員工的士氣和工作積極性。另外技術(shù)發(fā)展的方向應(yīng)該與現(xiàn)在的開發(fā)流程和規(guī)范相結(jié)合，這樣有利于專業(yè)技能的提高。 總之，組織，流程和人這三者是一個(gè)企業(yè)成功的鐵三角，理想的情況下它們彼此促進(jìn)，糟糕的情況下它們彼此制約。 6 7 國際上流行的質(zhì)量標(biāo)準(zhǔn) 最早進(jìn)入國內(nèi)的質(zhì)量標(biāo)準(zhǔn)是 ISO 系列。在軟件方面主要使用 ISO9000 系 列標(biāo)準(zhǔn)。 ISO9000 是一個(gè)非常完整的標(biāo)準(zhǔn)，并且定義了供應(yīng)商設(shè)計(jì)和交付一個(gè)有質(zhì)量產(chǎn)品的能力所需要的所有元素。 ISO9002 涵蓋了對供應(yīng)商控制設(shè)計(jì)和開發(fā)活動(dòng)所認(rèn)為重要的質(zhì)量標(biāo)準(zhǔn)。 ISO9003 用于證明供應(yīng)商在檢視和測試期間檢測和控制產(chǎn)品不一致性的能力。 ISO9004 描述和 ISO9001 、 ISO9002 和 ISO9003 相關(guān)的質(zhì)量標(biāo)準(zhǔn)，并提供了一個(gè)完整的質(zhì)量查檢表。 軟件能力成熟度模型是目前國內(nèi)軟件企業(yè)中非常受歡迎的一個(gè)質(zhì)量標(biāo)準(zhǔn)。并且該標(biāo)準(zhǔn)已經(jīng)成 32 為業(yè)界一個(gè)事實(shí)上的標(biāo)準(zhǔn)。 CMM 為軟 件組織提供了一個(gè)指導(dǎo)性的管理框架。在這個(gè)框架的指導(dǎo)下： 軟件組織可以對其軟件開發(fā)、維護(hù)過程獲得控制。 軟件組織可以推進(jìn)其軟件工程更為科學(xué)、推進(jìn)軟件過程管理更為卓越。 CMM 通過確定當(dāng)前軟件過程管理的成熟度，通過標(biāo)識軟件的質(zhì)量和過程改進(jìn)中關(guān)鍵的、要害的問題，可以指導(dǎo)軟件組織選擇正確的軟件過程改進(jìn)策略。 CMM 將其焦點(diǎn)，聚焦在一系列具體的軟件過程活動(dòng)上，并以侵略方式（ Aggressively ）達(dá)到這些活動(dòng)。一個(gè)軟件組織就可以穩(wěn)定地、持續(xù)地改進(jìn)其整個(gè)軟件組織過程，使得其軟件過程管理能力取得持續(xù)地、持久地不斷爭長提高。 在 CMM 中，把軟件工廠分為五個(gè)等級：初始級、可重復(fù)級、已定義級、管理級和優(yōu)化級。其中： 初始級 ：軟件過程是未加定義的隨意過程，項(xiàng)目的執(zhí)行是隨意甚至是混亂的。也許，有些企業(yè)制定了一些軟件工程規(guī)范，但若這些規(guī)范未能覆蓋基本的關(guān)鍵過程要求，且執(zhí)行沒有政策、資源等方面的保證時(shí)，那么它仍然被視為初始級。 可重復(fù)級 ：人們根據(jù)多年的經(jīng)驗(yàn)和教訓(xùn)，總結(jié)出軟件開發(fā)的首要問題不是技術(shù)問題而是管理問題。因此，第二級的焦點(diǎn)集中在軟件管理過程上。一個(gè)可管理的過程則是一個(gè)可重復(fù) 的過程，可重復(fù)的過程才能逐漸改進(jìn)和成熟?？芍貜?fù)級的管理過程包括了需求管理、項(xiàng)目管理、質(zhì)量管理、配置管理和子合同管理五個(gè)方面；其中項(xiàng)目管理過程又分為計(jì)劃過程和跟蹤與監(jiān)控過程。通過實(shí)施這些過程，從管理角度可以看到一個(gè)按計(jì)劃執(zhí)行的且階段可控的軟件開發(fā)過程。 已定義級： 要求制定企業(yè)范圍的工程化標(biāo)準(zhǔn)，并將這些標(biāo)準(zhǔn)集成到企業(yè)軟件開發(fā)標(biāo)準(zhǔn)過程中去。所有開發(fā)的項(xiàng)目需根據(jù)這個(gè)標(biāo)準(zhǔn)過程裁剪出與項(xiàng)目適宜的過程，并且按照過程執(zhí)行。過程的裁剪不是隨意的，在使用前必須經(jīng)過企業(yè)有關(guān)人員的批準(zhǔn)。 管理級 ：所有過程需建立相應(yīng)的度量方 式，所有產(chǎn)品的質(zhì)量（包括工作產(chǎn)品和提交給用戶的最終產(chǎn)品）需要有明確的度量指標(biāo)。這些度量應(yīng)是詳盡的，且可用于理解和控制軟件過程和產(chǎn)品。量化控制將使軟件開發(fā)真正成為一種工業(yè)生產(chǎn)活動(dòng)。 優(yōu)化級： 的目標(biāo)是達(dá)到一個(gè)持續(xù)改善的境界。所謂持續(xù)改善是指可以根據(jù)過程執(zhí)行的反饋信息來改善下一步的執(zhí)行過程，即優(yōu)化執(zhí)行步驟。如果企業(yè)達(dá)到了第五級，就表明該企業(yè)能夠根據(jù)實(shí)際的項(xiàng)目性質(zhì)、技術(shù)等因素，不斷調(diào)整軟件生產(chǎn)過程以求達(dá)到最佳。 美國國防部規(guī)定，重要性級別高的軟件應(yīng)該由質(zhì)量級別高的企業(yè)承擔(dān)。不同等級的軟件公司提交的軟件，其軟件 質(zhì)量也相差很大，國外的一份統(tǒng)計(jì)資料如下： 表 1 、 CMM 級別與軟件質(zhì)量關(guān)系表格 每千行軟件的缺陷數(shù)目 軟件過程成熟度等級 軟件準(zhǔn)時(shí)提交的百分比 每人每月生產(chǎn)的程序行數(shù) 軟件需要返工的百分比 平均軟件失效時(shí)間（近似） 大于 10 初始級 =45 2 到 60 分鐘 小于 10 可重復(fù)級 90 1.5Z 20 1-160 小時(shí) 小于 1 已定義級 99 2.5Z 10 不確定 小于 0.1 管理級 降低開發(fā)時(shí)間到 1/2 5 Z 5 不確定 小于 0.01 優(yōu)化級 降低開發(fā)時(shí)間到 1/4 10Z 事業(yè)部總經(jīng)理 部門經(jīng)理 員工）。按照本文定義的復(fù)雜度含義可以斷言，該公司的組織結(jié)構(gòu)復(fù)雜度較高（四層管理、 1000 人以上規(guī)模），但其研發(fā)過程復(fù)雜度較低（單個(gè)項(xiàng)目投入人數(shù)在 10 人內(nèi)）。 為了更好的對比分析請看下面的統(tǒng)計(jì)數(shù)據(jù)： 到 1999 年止，全球范圍內(nèi)共進(jìn)行了 1330 次 CMM 評測，總計(jì)評測項(xiàng)目有 5452 項(xiàng)，參加評測的機(jī)構(gòu)逐年攀升，其中有 7.2% 是海外項(xiàng)目，參加國別有 34 個(gè)，參加機(jī)構(gòu)類型，商業(yè)機(jī)構(gòu)占 56.1% ，美國國防部供應(yīng)商占 29.8% ，軍方和政府機(jī)構(gòu)占 10.5% 。其中，初始級機(jī)構(gòu)占 總評估數(shù)的 43.2% ，可重復(fù)級占 34.2% ，定義級占 17.3% ，管理級占 4% ，優(yōu)化級占 1.4% 。第二級（可重復(fù)級）比例最高的為 25 人到 100 人的機(jī)構(gòu)，第三級（定義級）所占比例最高的為 1000 到 2000 人的企 業(yè)，第五級（優(yōu)化級）所占比例最高的為 2000 人以上的企業(yè)。 于是乎國內(nèi)各咨詢機(jī)構(gòu)和各有意使企業(yè)通過認(rèn)證的管理者得出結(jié)論，國內(nèi)的企業(yè)可以以上述統(tǒng)計(jì)數(shù)據(jù)為參照，選擇適合自己的認(rèn)證目標(biāo)。各位看官請?jiān)囅胍幌拢阂粋€(gè)由眾多獨(dú)立核算的事業(yè)部或子公司粘合而成的一個(gè) 1000 多 人的公司，分各個(gè)業(yè)務(wù)方向從事著眾多 30 人月（ 3 5 個(gè)人， 6 10 個(gè)月）上下規(guī)模的項(xiàng)目，其研發(fā)過程復(fù)雜度顯然是不高的，其研發(fā)過程的可視性相對來說比較容易達(dá)到。此時(shí)組織的主要焦點(diǎn)在于如何降低其組織的管理復(fù)雜度，提高管理過程的可視性。如果此時(shí)嚴(yán)格照搬適合大團(tuán)隊(duì)研發(fā)過程管理的過程管理體系，到頭來肯定是過程監(jiān)控與研發(fā)實(shí)施活動(dòng)成為脫節(jié)的兩張皮，為了達(dá)到體系的要求去補(bǔ)大量的記錄，為了真正不受羈絆的去更好的實(shí)施項(xiàng)目跨過很多死板過程的羈絆。個(gè)人傾向類似情況的組織（公司）真正從整理業(yè)務(wù)流程入手，建立一套著眼 點(diǎn)在提高組織管理過程可視性的管理體系，不妨老老實(shí)實(shí)的按照 ISO 體系的要求，建立自己的質(zhì)量管理體系。 對應(yīng)的例子是一個(gè) 100 多人的公司，其 100 多人的開發(fā)團(tuán)隊(duì)投入其核心產(chǎn)品的開發(fā)，所有組織活動(dòng)都是圍繞這個(gè)產(chǎn)品開發(fā)過程展開的。此時(shí)組織的質(zhì)量瓶頸在于如何提高研發(fā)過程的可視性。此類組織我傾向于采用 CMM 建立逐步完善的研發(fā)過程質(zhì)量監(jiān)控體系。 綜上所述，從復(fù)雜度與質(zhì)量管理體系選擇上，可以得到下表的對應(yīng)關(guān)系： 組織機(jī)構(gòu)復(fù)雜度 研發(fā)過程復(fù)雜度 關(guān)鍵問題 選擇體系 高 高 管理過程可視性 ISO 36 高 低 研發(fā)過程可視性 CMM 低 高 管理過程可視性 ISO 低 低 研發(fā)過程可視性 CMM 7 3 量化管理的適用性上 CMM 和 ISO 9000 都強(qiáng)調(diào)過程改進(jìn)。如果組織還沒有一個(gè)文檔化的研發(fā)過程，則首要任務(wù)是對當(dāng)前的研發(fā)過程進(jìn)行抽象、分析、整理并文檔化，從而制定出一個(gè)符合本組織研發(fā)實(shí)際的研發(fā)過程規(guī)范，并從制度上確保研發(fā)過程規(guī)范的執(zhí)行。 如果已經(jīng)具備了相對陳述的研發(fā)過程規(guī)范，組織需要做的是對這個(gè)研發(fā)過程規(guī)范在實(shí)際研發(fā)活動(dòng)中的表現(xiàn)進(jìn)行持續(xù)的評估，找出問題，然后對過程規(guī)范本身進(jìn)行補(bǔ)充 修訂，然后找項(xiàng)目試點(diǎn)，最終推廣應(yīng)用。這也就是我們通常所說的持續(xù)改進(jìn)。 在闡述量化管理的適用性前，先來探討一下為什么要進(jìn)行量化管理？ 隨著組織的質(zhì)量管理水平和質(zhì)量意識的提高，越來越多的過程質(zhì)量問題的不是可以通過直接的外在表現(xiàn)可以觀察出來的。 隨著組織的質(zhì)量管理水平和質(zhì)量意識的提高，越來越多的過程質(zhì)量問題的定位越來越難以通過其直接的外在表現(xiàn)進(jìn)行判斷。 如何發(fā)現(xiàn)過程質(zhì)量問題？如何定位過程質(zhì)量問題的根源所在？ CMM L4 的 “ 定量過程管理 ” 、 CMMI L3 的 “ 決策分析和決定 ” 和 CMMI L2 的 “ 測量和分析 ”KPA 很好的回答了這個(gè)問題：我們通過收集、整理和分析過程數(shù)據(jù)，并運(yùn)用系統(tǒng)的決策方法從中得出分析結(jié)論，尋求問題的解決方法。 請看下例： 某組織最高管理者 2004 年以來，接到客戶持續(xù)不斷的抱怨，說系統(tǒng)穩(wěn)定性差？當(dāng)最高管理者在向產(chǎn)品線反饋該問題時(shí)，產(chǎn)品線說，我們的產(chǎn)品越來越穩(wěn)定，去年的外部故障是 15 個(gè)，今年的外部故障只有 13 個(gè)。一切都那么的 OK ，為啥客戶的抱怨卻與日俱增呢？問題到底出現(xiàn)在哪里？該如何去糾正？ 產(chǎn)品線成立了專門小組尋找問題所在及解決 之道。在收集數(shù)據(jù)的過程中，他們關(guān)注到這樣一個(gè)現(xiàn)象， 2003 年產(chǎn)品售出 256 套（ 25 個(gè)客戶）， 2004 年度產(chǎn)品一下子售出 6000 套（ 300 個(gè)客戶）。雖然報(bào)出的外部故障只有 13 個(gè)，比去年的 15 個(gè)有了減少，但其波及的范圍（客戶數(shù)）卻成 10 倍的增加。 問題癥結(jié)終于找到了，我們產(chǎn)品質(zhì)量的提高沒有跟上我們市場擴(kuò)張的速度。我們需要解決的最關(guān)鍵的問題是徹底解決現(xiàn)有故障，并作充分的測試，提高我們發(fā)布產(chǎn)品的穩(wěn)定性。 過程管理的核心是使過程狀態(tài)可見并使過程可控；量化管理的目標(biāo)是如何使前者更 加精準(zhǔn)。 ISO9000 雖然也強(qiáng)調(diào)以事實(shí)為依據(jù)的科學(xué)決策和 SPC ，并要求組織有這方面文檔化的指南與要求，但它沒有進(jìn)一步說明從哪些關(guān)鍵點(diǎn)上去入手，而且它的 SPC 更多的是針對制造業(yè)的不良品而考慮的。 CMM/CMMI-SW 是專門為軟件研發(fā)過程管理設(shè)計(jì)的，它在各相關(guān) KPA/PA 中蘊(yùn)涵的量化管理的關(guān)鍵實(shí)踐更具針對性、更細(xì)致、也更全面。 CMMI L4 更是明確要求： “ 對各個(gè)過程運(yùn)用統(tǒng)計(jì)技術(shù)和其他定量技術(shù)對各個(gè)過程實(shí)施控制，建立了關(guān)于產(chǎn)品質(zhì)量、服務(wù)質(zhì)量以及過程性能的定量目標(biāo)，并且把這些定量目標(biāo)作 為管理過程的準(zhǔn)則。在過程的整個(gè)生存周期中，對產(chǎn)品質(zhì)量、服務(wù)質(zhì)量和過程性能都進(jìn)行統(tǒng)計(jì)管理。 ” 在第 4 級上，對過程的性能是以統(tǒng)計(jì)技術(shù)或其他定量技術(shù)進(jìn)行控制。并且從統(tǒng)計(jì)意義上說是可預(yù)見的。 可見，在具有一定質(zhì)量管理基礎(chǔ)的組織內(nèi)，可以參照 CMM/SMMI-SW 相關(guān) KPA/PA 的要求， 37 建立自己的研發(fā)過程度量體系，逐步推進(jìn)量化管理。 7 4 結(jié)論 組織在建立質(zhì)量管理體系時(shí)，可結(jié)合本組織的管理水平、組織機(jī)構(gòu)復(fù)雜度、研發(fā)過程復(fù)雜度的現(xiàn)狀綜合考慮，選擇適合本組織的模型和體系。并可以在過程中參照 CMM/CMM-SW/SE 的要求，提高組織的量化管理水平。 八 如何做好單元測試 【摘要】 單元測試是軟件開發(fā)過程中重要的質(zhì)量保證活動(dòng)，單元測試的質(zhì)量將很大程度上影響軟件產(chǎn)品的最終質(zhì)量。本文從組織、流程和技術(shù)三個(gè)方面來闡述了做好單元測試的一些關(guān)鍵因素，可以作為軟件企業(yè)開展單元測試活動(dòng)的參考。 【關(guān)鍵字】 單元測試，組織，流程，技術(shù) 8 1 前言 單元測試是對軟件基本組成單元進(jìn)行的測試，是屬于白盒測試的范疇，它主要通過對代碼的邏輯結(jié)構(gòu)進(jìn)行分析來設(shè)計(jì)測試用例。在動(dòng)態(tài)測試手段中，單元測試是一種非常高效的測 試方法，并且是軟件測試周期中第一個(gè)進(jìn)行的測試。從成本角度考慮，缺陷發(fā)現(xiàn)越早越好，加強(qiáng)單元測試力度有利于降低缺陷定位和修復(fù)難度，從而降低缺陷解決成本，同時(shí)加強(qiáng)單元測試也減輕了后續(xù)集成測試和系統(tǒng)測試的負(fù)擔(dān)。根據(jù)業(yè)界的統(tǒng)計(jì)，一個(gè) BUG 在單元測試階段發(fā)現(xiàn)花費(fèi)是 1 的話，到集成測試就變?yōu)?10 ，到系統(tǒng)測試就高達(dá) 100 ，到實(shí)際推向市場量產(chǎn)后就高達(dá) 1000 。但單元測試在目前國內(nèi)軟件企業(yè)中開展得并不好，一方面是由于對單元測試重視程度不夠，測試投入不足，另一方面是由于在單元測試實(shí)踐方面積累得也不夠，單元測試處 于一種摸索狀態(tài)。 軟件的質(zhì)量由組織、流程和技術(shù)三個(gè)維度來決定，任何一個(gè)維度都不能單獨(dú)決定軟件的質(zhì)量。好的組織結(jié)構(gòu)可以保證流程的順利實(shí)施，好的流程能提高軟件開發(fā)的規(guī)范性和可控性，從而提高軟件開發(fā)的效率和質(zhì)量，而采用了好的技術(shù)和有好的技術(shù)的載體 人，則從根本上保證了軟件的質(zhì)量。 總而言之，組織、流程和技術(shù)是軟件質(zhì)量三角，本文將從這三個(gè)方面對如何做好單元測試進(jìn)行論述。 8 2 組織結(jié)構(gòu)應(yīng)該保證測試組參與單元測試 目前無論是工業(yè)界還是學(xué)術(shù)界都認(rèn)為單元測試應(yīng)該由開發(fā)人員開展，這是因?yàn)閺膯卧獪y試的過程看 ，單元測試普遍采用白盒測試的方法，離不開深入被測對象的代碼，同時(shí)還需要構(gòu)造驅(qū)動(dòng)模塊、樁函數(shù)，因此開展單元測試需要較好的開發(fā)知識。從人員的知識結(jié)構(gòu)、對代碼的熟悉程度考慮，開發(fā)人員具有一定的優(yōu)勢。 單元測試由開發(fā)人員進(jìn)行能帶來一些特別的收益。我們知道，在實(shí)踐中開發(fā)人員進(jìn)行單元測 38 試一般推薦采用交叉測試的方法，例如由被測單元的調(diào)用方進(jìn)行該單元的測試，即盡量避免對自己的代碼進(jìn)行單元測試。這種交叉的測試安排可以避免測試受開發(fā)思路影響太大，局限于原來的思路不容易發(fā)現(xiàn)開發(fā)過程中制造的問題；二來也達(dá)到一個(gè)技術(shù)備份或充分交流 的目的，這對組織非常有利。即使不采用交叉測試的方法，而安排單元的生產(chǎn)者自行開展單元測試，也是有很大的優(yōu)越性的，其最大的優(yōu)點(diǎn)是快速，且能更好的實(shí)現(xiàn) “ 預(yù)防錯(cuò)誤 ” 。在人員緊張的情況下這種自行測試的安排也是不錯(cuò)的選擇。 從經(jīng)驗(yàn)值來看，單元測試投入和編碼投入相比基本上是一比一，如果由專職測試隊(duì)伍來進(jìn)行單元測試，維持這樣龐大的單一任務(wù)隊(duì)伍顯然是不合適的。 以上談的是由開發(fā)人員進(jìn)行單元測試的優(yōu)點(diǎn)，其中主要是從單元測試的效率角度來考慮。但是從單元測試效果的角度考慮，必須從組織結(jié)構(gòu)上保證測試組參與單元測試，這是因 為： 首先，從目前國內(nèi)企業(yè)普遍現(xiàn)狀來看，測試人員質(zhì)量意識要高于開發(fā)人員，測試人員參與單元測試能夠提高測試質(zhì)量。 其次，對被測系統(tǒng)越了解，測試才有可能越深入，測試人員參與單元測試，將使得測試人員能夠從代碼級熟悉被測系統(tǒng)，這對測試組后期集成測試和系統(tǒng)測試活動(dòng)非常有幫助，會(huì)很大的提升集成測試和系統(tǒng)測試質(zhì)量。 測試組以何種方式參與單元測試，應(yīng)該結(jié)合軟件組織的實(shí)際情況來定。如果軟件組織測試資源充分，測試人員對開發(fā)人員的比例較高，那么可以由測試人員獨(dú)立承擔(dān)部分重要模塊的單元測試工作；如果測試資源不足，測試人員對開 發(fā)人員的比例較低，那么可以采取由測試人員進(jìn)行單元測試計(jì)劃、單元測試設(shè)計(jì)的工作，而單元測試的實(shí)現(xiàn)和執(zhí)行由開發(fā)人員來完成；而如果測試資源非常缺乏，連單元測試計(jì)劃、單元測試設(shè)計(jì)都無法承擔(dān)，那么測試組至少應(yīng)該參與開發(fā)組的各相關(guān)單元測試文檔、單元測試報(bào)告的評審，保證單元測試的質(zhì)量。 8 3 加強(qiáng)單元測試流程規(guī)范性 8 3 1 制訂單元測試的過程定義 軟件質(zhì)量的提高需要規(guī)范的流程，對軟件開發(fā)過程進(jìn)行管理也需要依據(jù)規(guī)范的過程定義。過程定義包含階段的劃分、階段的入口 / 出口準(zhǔn)則、階段的輸入 / 輸出、角色和職責(zé) 、模板和查檢表等等。將單元測試劃分為幾個(gè)階段便于對單元測試過程進(jìn)行控制，體現(xiàn)軟件測試可控性。要提高單元測試的質(zhì)量，首先要制定規(guī)范的單元測試過程，開發(fā)組、測試組、 SCM 組、 SQA 組等可以依據(jù)單元測試過程定義開展各自的工作，共同保證單元測試的質(zhì)量。 單元測試過程的定義需要參照企業(yè)的實(shí)際情況，例如階段劃分可以分為四個(gè)階段：計(jì)劃、設(shè)計(jì)、實(shí)現(xiàn)、執(zhí)行。其中計(jì)劃階段應(yīng)當(dāng)考慮整個(gè)單元測試過程的時(shí)間表，工作量，任務(wù)的劃分情況，人員和資源的安排情況，需要的測試工具和測試方法，單元測試結(jié)束的標(biāo)準(zhǔn)及驗(yàn)收的標(biāo)準(zhǔn)等，同時(shí)還應(yīng) 當(dāng)考慮可能存在的風(fēng)險(xiǎn)，以及針對這些風(fēng)險(xiǎn)的具體處理辦法，并輸出單元測試計(jì)劃文檔，作為整個(gè)單元測試過程的指導(dǎo)。設(shè)計(jì)階段需要具體考慮對哪些單元進(jìn)行測試，被測單元之間的關(guān)系以及同其他模塊之間單元的關(guān)系，具體測試的策略采用哪一種、如何進(jìn)行單元測試用例的設(shè)計(jì)、如何進(jìn)行單元測試代碼設(shè)計(jì)、采用何種工具等，并輸出單元測試方案文檔，用來指導(dǎo)具體的單元測試操作。實(shí)現(xiàn)階段需要完成單元測試用例設(shè)計(jì)、腳本的編寫，測試驅(qū)動(dòng)模塊的編寫，測試樁模塊的編寫工作，輸出單元測試用例文檔、相關(guān)測試代碼。執(zhí)行階段的主要工作是搭建單元測試環(huán) 境，執(zhí)行測試腳本，記錄測試結(jié)果，如果發(fā)現(xiàn)錯(cuò)誤，開發(fā)人員需要負(fù)責(zé)錯(cuò)誤的修改，同時(shí)進(jìn)行回歸測試，該階段結(jié)束需要提交單元測試報(bào)告。 39 具體進(jìn)行單元測試過程定義的時(shí)候，可以進(jìn)行一定的裁減，例如可以裁減為設(shè)計(jì)和執(zhí)行兩個(gè)階段，將單元測試方案和單元測試用例合二為一。 8 3 2 單元測試工作產(chǎn)品必須納入配置管理 單元測試工作產(chǎn)品指單元測試完成后應(yīng)交付的測試文檔、測試代碼及測試工具等，一般包括但不限于如下工作產(chǎn)品，可以根據(jù)實(shí)際情況進(jìn)行適當(dāng)裁剪： 單元測試計(jì)劃 單元測試方案 單元測試 用例 單元測試規(guī)程 單元測試日報(bào) 單元測試問題單 單元測試報(bào)告 單元測試輸入及輸出數(shù)據(jù) 單元測試工具 單元測試代碼及設(shè)計(jì)文檔 為了保證單元測試工作產(chǎn)品的準(zhǔn)確性，需要對測試代碼和腳本進(jìn)行走讀或檢視，對測試文檔進(jìn)行評審。這些工作產(chǎn)品應(yīng)該納入到配置管理，對于其修改要走配置變更流程，并及時(shí)發(fā)布其配置狀態(tài)，這樣可以保持單元測試工作產(chǎn)品的一致性和可回溯性。 8 3 3 必須制訂覆蓋率指標(biāo)和質(zhì)量目標(biāo)來指導(dǎo)和驗(yàn)收單元測試 單元測試必須制訂一定的覆蓋率指標(biāo)和質(zhì)量 目標(biāo)，來指導(dǎo)單元測試設(shè)計(jì)和執(zhí)行，同時(shí)作為單元測試驗(yàn)收的標(biāo)準(zhǔn)。設(shè)計(jì)用例時(shí)，可針對要達(dá)到的覆蓋率指標(biāo)來設(shè)計(jì)用例，而在測試執(zhí)行時(shí)，可以依據(jù)覆蓋率分析工具分析測試是否達(dá)到了覆蓋率指標(biāo)，如果沒達(dá)到，需要分析哪些部分沒有覆蓋到，從而補(bǔ)充用例來達(dá)到覆蓋率指標(biāo)。而單元測試質(zhì)量目標(biāo)的制訂，需要符合軟件企業(yè)的實(shí)際過程能力，這依賴于軟件企業(yè)以前單元測試過程度量數(shù)據(jù)的積累，不能憑空制造出來。有了以前度量數(shù)據(jù)的積累，完全可以了解當(dāng)前組織的單元測試能力，例如單元測試每千行代碼發(fā)現(xiàn)的缺陷數(shù)是多少。如果單元測試統(tǒng)計(jì)結(jié)果沒有落到這個(gè)質(zhì)量目標(biāo) 范圍內(nèi)，說明單元測試過程中某些方面存在一些問題，需要對過程進(jìn)行審計(jì)后找出問題原因進(jìn)行改進(jìn)。 這些指標(biāo)確定下來后，一定要嚴(yán)格推行。會(huì)有一些測試人員找出各種理由證明覆蓋率指標(biāo)達(dá)不到等等，這需要 QA 根據(jù)實(shí)際情況分析指標(biāo)是否合理。實(shí)際證明有一個(gè)相對簡單的標(biāo)準(zhǔn)也比沒有標(biāo)準(zhǔn)要好得多，我們的實(shí)踐發(fā)現(xiàn)，通過推行硬性指標(biāo)，單元測試發(fā)現(xiàn)的問題數(shù)目比沒有標(biāo)準(zhǔn)前至少增加了 2 倍。 下面是印度 SASKEN 公司的質(zhì)量目標(biāo)： 印度 SASKEN公司質(zhì)量目標(biāo) 階段 組織目標(biāo) 目標(biāo)上限 目標(biāo)下限 HLD （概要設(shè)計(jì)） 50 Major Defects / 100 pages 55 Major Defects/100 pages 45 Major Defects /100 pages LLD（詳細(xì)設(shè)計(jì)） 40 Major Defects / 100 pages 44 Major Defects/100 pages 36 Major Defects / 100 pages Unit Test Plan 25 Major Defects / 27.5 Major Defects 22.5 Major Defects / 100 40 （單元測試計(jì)劃） 100 pages /100 pages pages Code Review （代碼走讀） 20 Major Defects / KLOC 22 Major Defects / KLOC 18 Major Defects / KLOC Defects during Unit test（單元測試） 15 Major Defects / KLOC 16.5 Major Defects / KLOC 13.5 Major Defects / KLOC Defects during Integration test（集成測試） 6 Major Defects / KLOC 6.6 Major Defects / KLOC 5.4 Major Defects / KLOC 8 3 4 加強(qiáng)詳細(xì)設(shè)計(jì)文檔評審 詳細(xì)設(shè)計(jì)是單元測試的主要輸入，詳細(xì)設(shè)計(jì)文檔的質(zhì)量將直接影響到單元測試的質(zhì)量，所以一定要加強(qiáng)詳細(xì)設(shè)計(jì)文檔的評審，特別是要寫相關(guān)測試方案和進(jìn)行測試用例設(shè)計(jì)的人員，一定要從寫測試用例的角度看這個(gè)詳設(shè)是否符合要求，否則后期進(jìn)行單元測試設(shè) 計(jì)時(shí)會(huì)發(fā)現(xiàn)無法依據(jù)詳細(xì)設(shè)計(jì)進(jìn)行單元測試設(shè)計(jì)。軟件組織可以將詳細(xì)設(shè)計(jì)評審的要點(diǎn)以查檢表的形式固化下來，這樣在詳細(xì)設(shè)計(jì)評審的時(shí)候依據(jù)查檢表一項(xiàng)項(xiàng)檢查，既提高了評審效率，也能保證評審效果。評審流程需要確定如果不滿足查檢表 n% 以上的條件，被評審詳細(xì)設(shè)計(jì)文檔就不能通過，需要重新設(shè)計(jì)。 通常詳細(xì)設(shè)計(jì)文檔有兩種形式，一種是流程圖的形式，另一種是偽碼的形式。用流程圖表達(dá)的優(yōu)點(diǎn)是直觀，利于單元測試用例設(shè)計(jì)，缺點(diǎn)是描述性比較差，文檔寫作麻煩，不利于文檔的變更和修改；偽碼的方式可能正好相反，文檔變更修改簡單，可以方便地在任 何地方增加文字說明，而且翻譯成代碼更加便捷，但不直觀，不利于進(jìn)行單元測試用例設(shè)計(jì)。 詳細(xì)設(shè)計(jì)和單元測試設(shè)計(jì)一定要分離。如果單元測試由測試人員承擔(dān)，這一點(diǎn)不會(huì)有什么問題；如果單元測試由開發(fā)人員承擔(dān)，那么實(shí)際操作時(shí)可以讓項(xiàng)目組內(nèi)做相同或者相近任務(wù)的成員相互交換，根據(jù)對方的詳設(shè)設(shè)計(jì)對方的單元測試。這樣在單元測試開始之前的詳細(xì)設(shè)計(jì)評審階段就要考慮到后面的分工，安排相關(guān)的單元測試設(shè)計(jì)人員參與相關(guān)詳細(xì)設(shè)計(jì)的評審。 如果代碼沒有對應(yīng)的經(jīng)過評審后的詳細(xì)設(shè)計(jì)文檔，建議不進(jìn)行單元測試，而是用代碼審查替代單元測試。 開發(fā)人 員在編碼的過程中，可能會(huì)發(fā)現(xiàn)詳設(shè)中的問題，并對代碼進(jìn)行修改，這種修改應(yīng)該回溯到詳設(shè)，并對詳設(shè)進(jìn)行相應(yīng)的修改，否則到單元測試執(zhí)行的時(shí)候，會(huì)發(fā)現(xiàn)代碼和詳設(shè)根本對不上，無法執(zhí)行下去。詳設(shè)的修改要受控制，要走變更控制流程，它的變更也要經(jīng)過評審。因?yàn)閱卧獪y試是詳細(xì)設(shè)計(jì)的下游活動(dòng)，如果詳細(xì)設(shè)計(jì)隨意更改，單元測試文檔很難和其保持一致，這樣單元測試也就失去了依據(jù)和意義。只有詳設(shè)也納入配置管理，才能保證單元測試和詳設(shè)的一致性。 8 4 單元測試者技能的提高 8 4 1 加強(qiáng)對單元測試人員的技能培訓(xùn) 單元測試的質(zhì)量很 大程度上決定于進(jìn)行單元測試的人的技術(shù)水平。如果測試者不具備單元測試的知識，那么應(yīng)該對測試者進(jìn)行相關(guān)的培訓(xùn)。一個(gè)沒有做過單元測試人，不經(jīng)過培訓(xùn)初次是很難做好單元測試的。單元測試在詳設(shè)階段結(jié)束時(shí)開始，但是單元測試相關(guān)培訓(xùn)應(yīng)該盡早 41 準(zhǔn)備和計(jì)劃，培訓(xùn)可以分兩個(gè)階段，每個(gè)階段的內(nèi)容類似。第一階段是寫單元測試方案前，培訓(xùn)對象為測試方案的寫作者和詳設(shè)的寫作者，這樣可以在設(shè)計(jì)時(shí)多考慮可測試性，培訓(xùn)的內(nèi)容為單元測試基本概念、單元測試分析方法、單元測試用例的寫作、單元測試標(biāo)準(zhǔn)的明確；第二階段為單元測試執(zhí)行前，對象為測試執(zhí)行者，培 訓(xùn)內(nèi)容為具體單元測試的執(zhí)行，包括驅(qū)動(dòng)函數(shù)、樁函數(shù)的構(gòu)造、覆蓋率測試工具的使用（ TrueCoverage 、 Logiscope 等）、利用自動(dòng)化單元測試框架構(gòu)造單元測試自動(dòng)化（ TCL 、 CppUnit 、 JUnit 等）。培訓(xùn)過程中最好結(jié)合實(shí)例穿插其中，會(huì)比較生動(dòng)，而且增強(qiáng)理解。 通過以上的系統(tǒng)培訓(xùn)，可以統(tǒng)一單元測試方法、明確單元測試的標(biāo)準(zhǔn)、掌握單元測試基本技能，為后期單元測試的順利開展掃平道路。 8 4 2 必須引入工具進(jìn)行輔助 單元測試非常需要工具的幫助，特別是覆蓋率工具不能缺少，否則用 例執(zhí)行后無法得到測試質(zhì)量如語句覆蓋、路徑覆蓋等情況，也就無法對被測對象進(jìn)行進(jìn)一步的分析。應(yīng)用較廣的分析覆蓋率的工具有 Logiscope 、 TrueCoverage 、 PureCoverage 等，它們的功能有強(qiáng)有弱，可以根據(jù)實(shí)際情況采用。 為了提高單元測試的效率，特別是提高進(jìn)行回歸測試時(shí)的效率，需要在單元測試中引入自動(dòng)化。目前常用的方法是采用 TCL 語言編寫擴(kuò)展指令，構(gòu)造自己的單元測試自動(dòng)化。也可以直接采用開源的自動(dòng)化測試框架如 CppUnit 、 JUnit 等。 此外，在單元測試之前，還需要 利用 PC_Lint 對被測代碼進(jìn)行檢查，排除代碼語法錯(cuò)誤，確保進(jìn)行單元測試的代碼已經(jīng)具備了基本質(zhì)量，保證單元測試能夠順利進(jìn)行，提高單元測試執(zhí)行效率。 8 4 3 單元測試者加強(qiáng)對被測軟件的全面了解 單元測試的目的除了要發(fā)現(xiàn)編碼中引入的錯(cuò)誤和發(fā)現(xiàn)代碼與詳細(xì)設(shè)計(jì)不一致的地方之外，還有一個(gè)目的是為了保證詳細(xì)設(shè)計(jì)的質(zhì)量。因?yàn)闇y試分析和測試用例設(shè)計(jì)需要依據(jù)詳細(xì)設(shè)計(jì)來進(jìn)行，這個(gè)過程實(shí)際上是對詳細(xì)設(shè)計(jì)的重新檢視，在這個(gè)過程中會(huì)發(fā)現(xiàn)以前評審中沒有發(fā)現(xiàn)的問題。 無論是在單元測試的設(shè)計(jì)活動(dòng)中還是在單元測試的執(zhí)行過程中 ，都需要測試者了解軟件的需求和概要，加強(qiáng)對被測軟件的全面了解。否則對被測對象了解不深，只能就被測單元的流程而測流程，而對于該流程是否正確就無法保證了。 測試者要注重與開發(fā)的交流，這樣能對被測單元有更深的了解；同時(shí)因?yàn)檫M(jìn)度的原因，包括詳設(shè)在內(nèi)的文檔往往來不及更新，所以最新最正確的思想往往存在于開發(fā)人員的腦袋里，及時(shí)與他們交流才會(huì)獲得最及時(shí)的信息，減少將來更新用例的工作量。 8 5 結(jié)尾 單元測試是軟件開發(fā)過程中非常重要的質(zhì)量保證手段，加強(qiáng)單元測試對提高軟件質(zhì)量具有非常重要的意義。而做好單元測試不是只要 掌握單元測試方法就可以了的，這需要從組織、流程和技術(shù)三個(gè)方面來保證。 42 九 漫談人機(jī)界面測試 【正文】 本文列數(shù)了軟件黑盒測試過程中，在被測試軟件中可能存在的常見軟件問題。本文不會(huì)詳細(xì)討論基本的軟件測試思想與常用技術(shù)，僅針對在軟件黑盒測試過程中若干的問題做描述，并提供個(gè)人的參考測試意見與防范意見，希望可以為初學(xué)者提供些許幫助。 俗話說 “ 人靠衣裳馬靠鞍 ” ，良好的外觀往往能夠吸引眼球，激發(fā)顧客（用戶）的購買欲望，最終達(dá)成商業(yè)利益的實(shí)現(xiàn)。軟件的設(shè)計(jì)亦如此， Window XP 在商業(yè)上的巨大成功很大一方面來自于 它一改往日呆板，以突出 “ 應(yīng)用 ” 的灰色界面，從 “ 用戶體驗(yàn) ” 角度來設(shè)計(jì)界面，使界面具有較大的親和力。就目前的軟件設(shè)計(jì)的發(fā)展趨勢來說，良好的人機(jī)界面設(shè)計(jì)越來越受到系統(tǒng)分析、設(shè)計(jì)人員的重視。但是如何對設(shè)計(jì)的人機(jī)界面（包括幫助等）進(jìn)行測試，給出客觀、公正的評價(jià)，卻鮮見于報(bào)端。本文試從共性分析和個(gè)性分析的角度，給出一些測試意見和原則，簡單且易于上手。起到一個(gè)拋磚引玉的目的、以饗讀者。 我們知道： “ 不立規(guī)矩?zé)o以成方圓 ” 。在軟件界面設(shè)計(jì)強(qiáng)調(diào)張揚(yáng)個(gè)性的同時(shí)，我們不能忘記軟件界面的設(shè)計(jì)先要講求規(guī)矩簡潔、一致、易用，這是一切軟 件界面設(shè)計(jì)和測試的必循之道，是軟件人機(jī)界面在突出自我時(shí)的群體定位。美觀、規(guī)整的軟件人機(jī)界面破除新用戶對軟件的生疏感，使老用戶更易于上手、充分重用已有使用經(jīng)驗(yàn)，并盡量少犯錯(cuò)誤。由此我們在對軟件人機(jī)界面進(jìn)行測試時(shí)（設(shè)計(jì)評審階段和系統(tǒng)測試階段結(jié)合進(jìn)行），不妨從下列一些角度測試軟件的人機(jī)界面。 9 1 一致性測試 一致性使軟件人機(jī)界面的一個(gè)基本要求。目的是使用戶在使用時(shí)，很快熟悉軟件的操作環(huán)境，同時(shí)避免對相關(guān)軟件操作發(fā)生理解歧義。這要求我們在進(jìn)行測試時(shí)，需要判斷軟件的人機(jī)界面是否可以作為一個(gè)整體而存在。下面是進(jìn)行 一致性測試的一些參考意見： 提示的格式是否一致 菜單的格式是否一致 幫助的格式是否一致 提示、菜單、幫助中的術(shù)語是否一致 各個(gè)控件之間的對齊方式是否一致 輸入界面和輸出界面在外觀、布局、交互方式上是否一致 命令語言的語法是否一致 功能類似的相關(guān)界面是否在在外觀、布局、交互方式上是否一致（比如商品代碼檢索和商品名稱檢索） 存在同一產(chǎn)品族的時(shí)候，是否與其他產(chǎn)品在外觀、布局、交互方式上是否一致（例： Office產(chǎn)品族） 同一層次的文字在同一種提示場合（一般情況、突顯、警告等 ）在文字大小、字體、顏色、對齊方式方面是否一致 多個(gè)連續(xù)界面依次出現(xiàn)的情況下，界面的外觀、操作方式是否一致（當(dāng)然可能會(huì)有例外，比如操作結(jié)束的界面） 43 9 2 信息反饋測試 假設(shè)系統(tǒng)的使用者是一個(gè)初出茅廬的生手，你能指望她（他）在進(jìn)行操作不出錯(cuò)嗎？但這還不是問題的所在，問題的所在在于我們都會(huì)犯錯(cuò)誤，我們都有自己不了解的東西。如何避免，這要求我們的人機(jī)界面有足夠的輸入檢查和錯(cuò)誤提示功能。通過信息反饋，用戶得到出錯(cuò)提示或是任務(wù)完成的贊許之語。但有些不幸的是，我們很多系統(tǒng)都在此方面做的不盡人意。下面是這類測試的 一些參考意見： 系統(tǒng)是否接受客戶的正確輸入并做出提示（例：鼠標(biāo)焦點(diǎn)跳轉(zhuǎn)）； 系統(tǒng)是否拒絕客戶的錯(cuò)誤輸入并做出提示（例：彈出警告框，聲響）； 系統(tǒng)顯示用戶的錯(cuò)誤輸入的提示是否正確，淺顯易懂（例： “ERR004” 這樣的提示讓人不知所云）； 系統(tǒng)是否在用戶輸入前給出用戶具體輸入方式的提示（例：網(wǎng)站注冊程序）； 系統(tǒng)提示所用的圖標(biāo)或圖形是否具有代表性和警示性； 系統(tǒng)提示用語是否按警告級別和完成程度進(jìn)行分級（若非某些破壞性操作，請對用戶溫和一些）； 系統(tǒng)在界面（主要是菜單、工具條）上是否提 供突顯功能（比如鼠標(biāo)移動(dòng)到控件時(shí)，控件圖標(biāo)變大或顏色變化至與背景有較大反差，當(dāng)移動(dòng)開后恢復(fù)原狀）； 系統(tǒng)是否在用戶完成操作時(shí)給出操作成功的提示（很多系統(tǒng)都缺少這一步，使用戶毫無成就感）。 9 3 界面簡潔性測試 你的人機(jī)界面像你的臉一樣對稱、干凈嗎？我們往往看到的使很多系統(tǒng)在人機(jī)界面設(shè)計(jì)上就像長了天花的病人。因此我們不得不對其進(jìn)行美容前的檢查，下面是一些供檢查的建議條款。 用戶界面是否存在空白空間（沒有空白空間的界面是雜亂無章的，易用性極差）； 各個(gè)控件之間的間隔是否一致； 各個(gè)控件在垂直 和水平方向上是否對齊； 菜單深度是否在三層以內(nèi)（建議不要超出三層，大家可以參考微軟的例子）； 界面控件分布是否按照功能分組（菜單、工具欄、單選框組、復(fù)選框組、 Frame 等）； 界面控件本身是否需要通過滑動(dòng)條的滑動(dòng)來顯示數(shù)據(jù)（建議采用分頁顯示并提供數(shù)據(jù)排序顯示功能）； 實(shí)際上，一個(gè)處理該類測試的原則性的東西就是：干掉多余的東西，盡可能分組。 9 4 界面美觀度測試 你的界面美觀嗎？試想一個(gè)服裝模特穿一身不得體的衣服其展示效果會(huì)如何？我至今還記得在學(xué)習(xí)美學(xué)時(shí)老師講過的一句話：美是對比的產(chǎn)物。在軟件界面 的美觀度測試上，我們不得不注意下面的一些建議。 前景與背景色搭配是否反差過大； 前景與背景色是否采用較為清淡的色調(diào)而不是深色（比如用天藍(lán)色而不用深藍(lán)色和墨綠色）； 系統(tǒng)界面是否采用了超過三種的基本色（一般情況下不要超過三種）； 44 字體大小是否與界面的大小比例協(xié)調(diào)（一般中文采用宋體 9-12，英文采用 Arial或 Times New Roman，日文采用 SimSun或明朝）； 按鈕較多的界面是否禁止縮放（一般情況下不宜縮放，最好禁止最大、最小化按鈕）； 系統(tǒng)是否提供用戶界面風(fēng)格自定義功能，滿 足用戶個(gè)人偏好； 9 5 用戶動(dòng)作性測試 “ 科學(xué)是懶人的哲學(xué) ” ，這是我大學(xué)專業(yè)老師的一個(gè)觀點(diǎn)。我們的計(jì)算機(jī)系統(tǒng)也不例外。我們的系統(tǒng)能讓用戶盡可能地偷懶嗎（少動(dòng)手肘，少記命令等），從這個(gè)角度出發(fā)，相信你會(huì)對用戶動(dòng)作性測試的本質(zhì)有較深的體會(huì)。我相信沒有一個(gè)測試員愿意做的多而收獲的少。此外用戶從某種角度上是心懷不測的挑釁者和肇事者。他們很少有太多的耐心來對待他們寄以很大期望的系統(tǒng)。下面是一些判斷用戶是否能夠 “ 偷懶 ” 和 “ 發(fā)泄防止 ” 的測試建議。 是否存在用戶頻繁操作的快捷鍵； 是否允許動(dòng)作的可逆性（ Undo， Redo）； 界面是否有對用戶的記憶要求； 系統(tǒng)的反應(yīng)速度是否符合用戶的期望值； 是否存在更便捷、直觀的方式來取代當(dāng)前的界面的顯示方式；（比如用菜單界面代替命令語言界面） 用戶在使用時(shí)任何時(shí)候是否能開啟幫助文檔（ F1）； 系統(tǒng)是否提供模糊查詢機(jī)制和關(guān)鍵字提示機(jī)制減少用戶的記憶負(fù)擔(dān)（比如清華紫光輸入法的模糊音設(shè)定）； 是否對可能造成長時(shí)間等待的操作提供操作取消功能； 是否支持對錯(cuò)誤操作進(jìn)行可逆性處理，返回原有狀態(tài)； 是否采用相關(guān)控件（如：日歷，計(jì)算器等）替代用戶手工鍵盤輸入； 選項(xiàng)過多的情況下是否采用下拉列表或者關(guān)鍵字檢索的方式共用戶選擇； 系統(tǒng)出錯(cuò)是是否存在恢復(fù)機(jī)制使用戶返回出錯(cuò)前狀態(tài)（如： Office XP的文件恢復(fù)）； 在用戶輸入數(shù)據(jù)之前，用戶輸入數(shù)據(jù)后才能執(zhí)行的操作是否被禁止（如特定的按鈕變灰）； 系統(tǒng)是否提供 “ 所見即所得（ WYIWG） ” 或 “ 下一步提示 ” 的功能（比如預(yù)覽）； 9 6 行業(yè)標(biāo)準(zhǔn)測試 每個(gè)行業(yè)都有自己的一套標(biāo)識體系。請盡可能不要與其 “ 撞車 ” 。這就需要我們的人機(jī)界面測試人員對軟件行業(yè)的符號體系有所了解，否則將很難擔(dān)此大任。 界面使用的圖符 、聲音是否符合軟件所面向領(lǐng)域的行業(yè)符號體系標(biāo)準(zhǔn)； 界面說使用的術(shù)語是否符合軟件所面向領(lǐng)域的行業(yè)命名標(biāo)準(zhǔn)； 界面的顏色是否與行業(yè)代表色彩較為相近； 界面的背景是否能夠反映行業(yè)相關(guān)主題（比如：反映環(huán)保的背景一般采用自然風(fēng)光作為背景）； 界面的設(shè)計(jì)是否反映行業(yè)最新的理念和大眾趨勢； 當(dāng)然、每一個(gè)軟件也應(yīng)當(dāng)具有自己的一些個(gè)性，這些個(gè)性是體現(xiàn)軟件開發(fā)商和所面向的用戶領(lǐng)域的特定需要的。比如微軟的啟動(dòng)界面和蘋果的啟動(dòng)界面就完全是兩碼事。一個(gè)不失個(gè)性的軟件，其本身就是軟件制作商的 “ 廣告代言人 ” 。既要突出制作 商，又不能喧賓奪主。下 45 面我們給出一些常見的軟件個(gè)性測試原則。 軟件的安裝界面是否有單位介紹或產(chǎn)品介紹，并擁有自己的圖標(biāo)； 軟件的安裝界面是否在界面上不同于通用的安裝工具生成的界面（比如：金山快譯的安裝界面就比較有特色）； 主界面的圖標(biāo)是否為制作商的圖標(biāo)； 系統(tǒng)啟動(dòng)需要長時(shí)間等待時(shí)，是否存在 Splash界面，它是否包含或反映制作者信息； 軟件是否有版本查看機(jī)制，版本說明上是否有制作者或是用戶的標(biāo)識； 軟件的界面的色彩、背景、布置是否與同類產(chǎn)品有不同之處，如果有，是否更為簡潔、美觀； 軟件界面操作與同類產(chǎn)品相比，是否能夠減少用戶輸入的頻繁度； 軟件界面操作與同類產(chǎn)品相比，是否在出錯(cuò)預(yù)防機(jī)制和提示上更為直觀、醒目； 軟件界面是否為特殊群體或是特殊的應(yīng)用提供相應(yīng)的操作機(jī)制（比如 Windows 的放大鏡）； 9 7 小結(jié) 總而言之，軟件人機(jī)界面的測試需要一個(gè)立足 “ 共性 ” 但又要強(qiáng)調(diào) “ 個(gè)性 ” 的測試思路，軟件人機(jī)界面的測試與其他類型測試不同，更加強(qiáng)調(diào)從用戶的角度、審美觀去看待待測軟件。既不能過于 “ 大俗 ” ，又不能過于 “ 大雅 ” 。很多時(shí)候，需要在強(qiáng)調(diào)規(guī)整和強(qiáng)調(diào)個(gè)性間進(jìn)行權(quán)衡。這迫切需要我們的界面 測試人員用大腦去思考，用心去體會(huì)。這對人機(jī)界面測試人員在審美觀上也是一個(gè)極大的挑戰(zhàn)。 十 基于 Web 的系統(tǒng)測試方法 基于 Web 的系統(tǒng)測試與傳統(tǒng)的軟件測試既有相同之處，也有不同的地方，對軟件測試提出了新的挑戰(zhàn)?；?Web 的系統(tǒng)測試不但需要檢查和驗(yàn)證是否按照設(shè)計(jì)的要求運(yùn)行，而且還要評價(jià)系統(tǒng)在不同用戶的瀏覽器端的顯示是否合適。重要的是，還要從最終用戶的角度進(jìn)行安全性和可用性測試。 本文從功能、性能、可用性、客戶端兼容性、安全性等方面討論了基于 Web 的系統(tǒng)測試方法。 隨著 Internet 和 Intranet/Extranet 的快速增長， Web 已經(jīng)對商業(yè)、工業(yè)、銀行、財(cái)政、教育、政府和娛樂及我們的工作和生活產(chǎn)生了深遠(yuǎn)的影響。許多傳統(tǒng)的信息和數(shù)據(jù)庫系統(tǒng)正在被移植到互聯(lián)網(wǎng)上，電子商務(wù)迅速增長，早已超過了國界。范圍廣泛的、復(fù)雜的分布式應(yīng)用正在 Web 環(huán)境中出現(xiàn)。 Web 的流行和無所不在，是因?yàn)樗芴峁┲С炙蓄愋蛢?nèi)容連接的信息發(fā)布，容易為最終用戶存取。 Yogesh Deshpande 和 Steve Hansen 在 1998 年就提出了 Web 工程的概念。 Web 工程作為一門新興的學(xué)科，提倡使用一個(gè)過程和系統(tǒng)的方法 來開發(fā)高質(zhì)量的基于 Web 的系統(tǒng)。它 使用合理的、科學(xué)的工程和管理原則，用嚴(yán)密的和系統(tǒng)的方法來開發(fā)、發(fā)布和維護(hù)基于 Web的系統(tǒng) 。目前，對于 web 工程的研究主要是在國外開展的，國內(nèi)還剛剛起步。 在基于 Web 的系統(tǒng)開發(fā)中，如果缺乏嚴(yán)格的過程，我們在開發(fā)、發(fā)布、實(shí)施和維護(hù) Web的過程中，可能就會(huì)碰到一些嚴(yán)重的問題，失敗的可能性很大。而且，隨著基于 Web 的系統(tǒng)變得越來越復(fù)雜，一個(gè)項(xiàng)目的失敗將可能導(dǎo)致很多問題。當(dāng)這種情況發(fā)生時(shí)，我們對 Web 46 和 Internet 的信心可能會(huì)無法挽救地動(dòng)搖，從而引起 Web 危機(jī)。并且， Web 危機(jī)可能會(huì)比軟件開發(fā)人員所面對的軟件危機(jī)更加嚴(yán)重、更加廣泛。 在 Web 工程過程中，基于 Web 系統(tǒng)的測試、確認(rèn)和驗(yàn)收是一項(xiàng)重要而富有挑戰(zhàn)性的工作?；?Web 的系統(tǒng)測試與傳統(tǒng)的軟件測試不同，它不但需要檢查和驗(yàn)證是否按照設(shè)計(jì)的要求運(yùn)行，而且還要測試系統(tǒng)在不同用戶的瀏覽器端的顯示是否合適。重要的是，還要從最終用戶的角度進(jìn)行安全性和可用性測試。然而， Internet 和 Web 媒體的不可預(yù)見性使測試基于 Web 的系統(tǒng)變得困難。因此，我們必須為測試和評估復(fù)雜的基于 Web 的系統(tǒng)研究新的方法和技術(shù)。 一般軟件的 發(fā)布周期以月或以年計(jì)算，而 Web 應(yīng)用的發(fā)布周期以天計(jì)算甚至以小時(shí)計(jì)算。 Web 測試人員必須處理更短的發(fā)布周期，測試人員和測試管理人員面臨著從測試傳統(tǒng)的 C/S 結(jié)構(gòu)和框架環(huán)境到測試快速改變的 Web 應(yīng)用系統(tǒng)的轉(zhuǎn)變。 10 1 功能測試 10 1 1 鏈接測試 鏈接是 Web 應(yīng)用系統(tǒng)的一個(gè)主要特征，它是在頁面之間切換和指導(dǎo)用戶去一些不知道地址的頁面的主要手段。鏈接測試可分為三個(gè)方面。首先，測試所有鏈接是否按指示的那樣確實(shí)鏈接到了該鏈接的頁面；其次，測試所鏈接的頁面是否存在；最后，保證 Web 應(yīng)用系統(tǒng)上沒有孤 立的頁面，所謂孤立頁面是指沒有鏈接指向該頁面，只有知道正確的 URL 地址才能訪問。 鏈接測試可以自動(dòng)進(jìn)行，現(xiàn)在已經(jīng)有許多工具可以采用。鏈接測試必須在集成測試階段完成，也就是說，在整個(gè) Web 應(yīng)用系統(tǒng)的所有頁面開發(fā)完成之后進(jìn)行鏈接測試。 10 1 2 表單測試 當(dāng)用戶給 Web 應(yīng)用系統(tǒng)管理員提交信息時(shí)，就需要使用表單操作，例如用戶注冊、登陸、信息提交等。在這種情況下，我們必須測試提交操作的完整性，以校驗(yàn)提交給服務(wù)器的信息的正確性。例如：用戶填寫的出生日期與職業(yè)是否恰當(dāng)，填寫的所屬省份與所在城市是否匹 配等。如果使用了默認(rèn)值，還要檢驗(yàn)?zāi)J(rèn)值的正確性。如果表單只能接受指定的某些值，則也要進(jìn)行測試。例如：只能接受某些字符，測試時(shí)可以跳過這些字符，看系統(tǒng)是否會(huì)報(bào)錯(cuò)。 10 1 3 Cookies 測試 Cookies 通常用來存儲用戶信息和用戶在某應(yīng)用系統(tǒng)的操作，當(dāng)一個(gè)用戶使用 Cookies訪問了某一個(gè)應(yīng)用系統(tǒng)時(shí)， Web 服務(wù)器將發(fā)送關(guān)于用戶的信息，把該信息以 Cookies 的形式存儲在客戶端計(jì)算機(jī)上，這可用來創(chuàng)建動(dòng)態(tài)和自定義頁面或者存儲登陸等信息。 如果 Web 應(yīng)用系統(tǒng)使用了 Cookies，就必須檢查 Cookies 是否能正常工作。測試的內(nèi)容可包括 Cookies 是否起作用，是否按預(yù)定的時(shí)間進(jìn)行保存，刷新對 Cookies 有什么影響等。 10 1 4 設(shè)計(jì)語言測試 47 Web 設(shè)計(jì)語言版本的差異可以引起客戶端或服務(wù)器端嚴(yán)重的問題，例如使用哪種版本的 HTML 等。當(dāng)在分布式環(huán)境中開發(fā)時(shí)，開發(fā)人員都不在一起，這個(gè)問題就顯得尤為重要。除了 HTML 的版本問題外，不同的腳本語言，例如 Java、 javascript、 ActiveX、 VBScript或 Perl 等也要進(jìn)行驗(yàn)證。 10 1 5 數(shù)據(jù)庫測試 在 Web 應(yīng)用技術(shù)中，數(shù)據(jù)庫起著重要的作用，數(shù)據(jù)庫為 Web 應(yīng)用系統(tǒng)的管理、運(yùn)行、查詢和實(shí)現(xiàn)用戶對數(shù)據(jù)存儲的請求等提供空間。在 Web 應(yīng)用中，最常用的數(shù)據(jù)庫類型是關(guān)系型數(shù)據(jù)庫，可以使用 SQL 對信息進(jìn)行處理。 在使用了數(shù)據(jù)庫的 W