軟件測試資料

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