亡羊補牢爲時不晚
— 筆記整理自 北京理工大學 計算機學院
不容忽視的測試
- 亡羊補牢
- 測試不簡單, 工作量很大，很累，很複雜
- 測試自動化是必由之路
- 軟件產品質量不能只靠測試
軟件測試基本原則
- 程序員應避免測試自己編寫的程序; (這樣是測不出來什麼的)
- 測試用例的設計必須包括預期的輸出結果;
- 測試用例應包括有效的和期望的輸入情況，也要包括無效的和不期望的輸入情況;
- 只檢查程序是否做了它應該做的事這僅完成了測試工作的一半，另一半則是要檢查程序是否做了它不該做的事;(後門)
- 徹底檢查每個測試結果;
- 避免不可重複的即興測試，保留全部測試用例;
- 一段程序中存在錯誤的概率與在這段程序中已發現的錯誤數成比例;
- 測試是一項非常複雜的、創造性的和需要高度智慧的挑戰性任務;
- 不能爲了便於測試擅自修改程序;(一定要區分開發環境,測試環境,上線環境,代碼版本一定要明確,責任一定要明確)
- 測試工作必須有明確的目標;
- 儘早地和不斷地進行軟件測試。
有關測試的幾個誤區
- 測試範圍: 代碼、文檔
- 代碼 + 文檔
- 維護代碼和文檔之間正確的對應關係
- 測試簡單?
- 測試活動已經變成了一項新的軟件開發項目，很複雜
- 測試本身就是一項新的開發，對測試用例的開發
- 什麼時候開始測試?
- 測試用例
- 測試用例的編寫應該在需求明確之後開始
- 測試可以驅動開發
- 不再是亡羊補牢式的工作
- TDD(Test- Driven Developement)
- 可以引導代碼的編寫
疲於奔命捉Bug
- 編碼隨意 -> 編碼規範
- Quickly and Ugly -> 重構 + 單元測試
- 只顧編碼，不顧文檔 -> 隨時註釋 + 文檔自動化
捉Bug有組織有紀律
無規矩，不成方圓
- 有組織：分測試組，測試組長，測試工程師
- 有目的：壓力測試還是集成測試
- 有計劃：什麼時候測，哪些人，哪些資源
- 有範圍：測試範圍是什麼，哪些模塊，模塊之間的接口等
- 有接口：研發提供給測試接口文檔
- 有數據：模擬數據，區分線上數據
- 有維護：測試腳本的維護
自動化捉Bug
- 有人提出可以用一種自動化的方式殺死蟑螂:
- 讓蟑螂靜止站立在砧板中間，如何做？最難的問題
- 用蟑螂拍對準蟑螂猛拍一下
- 把砧板、蟑螂拍上的髒東西洗乾淨
CASE
- CASE工具由三個步驟組成:
- 分析並設計出明確的需求規格說明書
- 建立功能點和源代碼(及文檔)一一對應的數據字典
- 將需求規格說明書轉化爲源代碼和文檔
測試工具
- 隨着軟件測試的地位逐步提高，測試的重要性逐步顯現，測試工具的應用已經成爲了普遍的趨勢
- 目前用於測試的工具一般可分爲
- 用於測試管理(測試流程管理、缺陷跟蹤管理、測試用例管理)的工具
- 白盒測試工具
- 黑盒測試工具
- 性能測試工具
應用測試工具的目的
- 提高測試質量
- 減少測試過程中的重複勞動，提高效率
- 實現測試自動化
日益強大的測試工具
- WinRunner：模擬用戶點擊操作
- LoadRunner：模擬成千上萬客戶端對服務器進行測試
- Jmeter：基於Java的壓力測試工具
- 等等
提高軟件質量的方法
- 提高產品質量是一個終極目標
- 捉Bug不是唯一的辦法
- 提高分析水平，設計水平，編碼水平
- 提高管理水平和團隊協作能力
- 提高軟件開發過程開發、管理和優化
- 引入軟件質量保證: SQA
第三方軟件評測
- 國家級和省級軟件評測中心
- 致力於軟件工程、質量管理、軟件系統測試、信息系統集成資質認證、ISO9000認證諮詢、CMMI認證諮詢、信息系統工程監理、信息系統驗收評估等領域的研究與實踐
- 示例:上海市軟件評測中心進行軟件產品登記測試
備註：圖片託管於github，請確保網絡的可訪問性