一些典型的測試方面的誤解

測試的角色

• 認為測試小組應負責保證產品的質量

－這是經常被開發人員和管理人員濫用的一句話。經常出現在出現問題時，對測試小組的指責中。就是由于這個觀念的存在，導致很多問題在開發晚期或測試后期才發現，可能需要大量的返工甚至拖延了產品的發布時間。其實在開發過程中的每一人都有可能影響產品的質量。這就像建房子一樣，房子出現問題了，只是檢查人員的問題嗎？我想如果每一個人都心懷以“質量為中心”，小心謹慎的做好自己的工作，產品的質量會上一個很多的臺階。

• 認為測試就是為了發現錯誤

－在很多“軟件測試”的定義中，都提到類似“軟件測試是為了發現錯誤”的話。其實這個觀點是提醒人們在測試過程要以查找錯誤為中心，而不是證明軟件的正確功能。但是很多人僅憑著字面的意思就認為發現錯誤是測試的唯一目的，那些找不出任何錯誤或很少錯誤的測試都不是成功的測試，這是錯誤的。

其實測試不僅僅只是為了發現錯誤，還需要分析錯誤產生的原因和其分布情況，為開發人員，管理層提供參考，指出產品或開發過程中存在的主要問題。而且隨著人們對產品質量的要求的提高，出現了多樣的測試類型。象易用性測試，性能測試，覆蓋率測試，恢復性測試，完整性測試等，這些測試都不是完全為了發現錯誤，而是找出和預期標準不同的問題。

所以個人認為還是IEEE在1983年提出的:“使用人工或自動手段來運行或測定某個系統的過程，其目的在于檢驗它是否滿足規定的需求或是弄清預期結果與實際結果之間的差別。”比較權威。

• 認為測試不能發現重要的錯誤

－有些開發人員認為單純的手工測試只是發現系統的一些皮毛問題，因此從心里看低測試人員。但有過經驗的開發人員知道，測試人員也發現了很多重要的問題。我曾經看過一些在開發小組中特別有權威的測試人員，他們雖然也只作黑盒測試，但他們發現的錯誤都是重量級的。

• 認為測試小組沒有提交可用性方面的問題
• 沒有集中精力評估產品的質量
• 提交錯誤數據的同時，但沒有把數據放入錯誤發生的背景里

－有些測試人員認為我發現錯誤了，就成功了。在錯誤報告中，只是提及錯誤的情況和數據，但卻沒有提及錯誤發生的背景或是步驟。造成開發人員很難重現并修改錯誤。

• 很晚才開始測試（只是發現錯誤，而不是減少錯誤）

－這個很顯而易見。但不幸的是，我參與過的很多項目測試小組都是在很晚才開始測試的。由于公司在成本上的考慮，導致了在開發后期或系統測試時才開始測試。出現了開發人員在項目晚期還在加班改bug的情況，甚至由于錯誤太多拖延了交付時間。在其中，還有可能發現整體設計和構架上的缺陷，導致明知會有很嚴重的后果都不敢改動代碼的事情。

 計劃完成的測試工作量

• 測試的工作量和功能測試有偏離
• 低估了配置測試
• 把壓力和負載測試放在最后進行
• 不測試文檔
• 不測試安裝過程
• 過分依賴beta測試
• 在轉移到下一個任務之前必須完成現在的測試任務
• 未能正確地識別風險區域
• 固執地遵從測試計劃

 人員問題

• 利用測試作為新開發人員的過渡工作
• 從不合格的程序員中招募測試人員
• 測試人員不需要是領域專家
• 不從客戶服務人員或技術文檔人員中挑選測試人員
• 堅持測試人員必須能夠編程
• 缺乏多樣性的測試小組
• 認為測試和開發人員有本質的區別
• 相信開發人員不能夠測試他們自己的代碼
• 開發人員既沒有受過培訓，也沒有激情測試

 工作中的測試人員

• 比設計測試更注重運行測試
• 不審核測試設計
• 非常詳細地描述測試的輸入和過程
• 沒有注意并探測到“不相關的”怪事
• 檢查產品應該執行的和期望的一樣，但沒有檢查它不應該執行的是期望不應該執行的一樣
• 測試套件只有他們的作者才可以理解
• 只通過用戶可見的界面測試
• 拙劣的錯誤報告
• 當發現錯誤后，只是增加了回歸測試
• 沒有為下一此測試工作量做筆記

 測試自動化

• 嘗試自動化所有的測試
• 可以立即減少工作量或人力
• 期望重新運行手工測試
• 使用GUI捕獲/回放工具以減少創建測試的成本
• 期望回歸測試可以發現更多的新錯誤

測試覆蓋

• 只是追求一個簡單的關于測試覆蓋率的數據
• 只是因為有些測試不能增加覆蓋率，就把它們從回歸測試包中移除掉
• 把覆蓋率作為測試人員的績效目標
• 徹底地放棄覆蓋率

原文轉自：http://www.anti-gravitydesign.com