什么樣的測試用例才是好的測試用例?
測試用例如何覆蓋測試需求?測試需求和測試用例的關系是什么?
怎么樣保證測試需求的整理和測試用例的設計不會浪費太多的人力或其他資源?
……
這些問題可謂是老生常談了，在論壇上、MSN上，或者郵件中，也經常會有朋友問到筆者一些這方面的問題。相信不管是測試新手，還是從事測試工作有一段時間的朋友，都會在工作中不得不經常的要考慮，這些問題到底有沒有一個相對明確的答案呢?
相信看到這里，已經有些朋友在想：這些問題也不是很難啊，在RUP對測試過程的描述中都已經說的很明白了啊。軟件測試工作必須要通過計劃測試、設計測試、實現測試、執行測試、評估測試幾個階段來完成。其中計劃測試階段需要制定測試計劃、整理測試需求;設計測試階段要設計測試用例和測試過程，要保證測試用例完全覆蓋測試需求;實現測試階段要根據測試用例實現具體的自動化腳本或者手工的操作步驟;執行測試階段則通過自動化測試工具或人手工來執行那些自動化或手工腳本;最后的評估階段則要對軟件的質量和測試工作自身的質量做出一個客觀的評價。RUP中還有詳細的工作指南和文檔模板呢!
對，上面所說的這些都沒有錯，RUP中對于軟件測試過程的描述要比筆者上面這段文字詳細也生動得多。但是，我們同時也可以看到，RUP中描述到的，更多的是關注于過程的管理，或者更準確的說，RUP是在為我們提供一個大的方向，是一個穩定的、具有指導作用的框架，而不是一些具體的、涉及到操作細節的方法。這也是為什么很多朋友通讀了RUP中關于軟件測試的部分，但是一旦實際應用仍然找不準方向的原因。筆者今天希望同大家討論的，則恰恰是這樣一些在實踐RUP測試過程時，從實際工作中總結出來的工作方法和經驗。
對于測試過程方面的規范和一些基本概念，RUP中已經講的很詳細了，筆者在此也就不再贅述，有需要的讀者請參照RUP中的相關部分。本文中所關注的內容包括：
1. 在計劃測試時，如何確定測試工作的范圍和如何整理測試需求;
2. 設計測試用例時，應該如何把握測試用例的粒度;
3. 如何平衡測試用例的可用性和可維護性;
4. 如何通過逆向的測試數據分析方法來保證測試用例的有效性和減少測試工作中資源的浪費;
5. 一個簡單的但有實際意義的例子將展示如何將筆者的方法應用到測試過程中。
這里要事先聲明一下，筆者工作三年來，不管是開發還是測試，工作內容始終是圍繞著信息管理系統相關業務展開的，而對于測試工作，也一直局限于在系統測試階段通過手工方法和簡單的利用一些測試工具特性進行黑盒測試。因此，在本文下面描述的內容中，難免受到客觀環境和筆者個人經驗的影響。也正因為如此，筆者不保證本文中方法和觀點適合于所有組織和個人的軟件開發過程。只是希望能夠借此為大家提供一種思路，幫助更多人進行個性化的RUP測試過程實踐，共同提高軟件測試行業的水平。
另外，本文中使用到的例子，均為筆者的一些假設，如果侵害到任何第三方組織或個人的利益，實屬巧合，請通過E-Mail通知筆者，筆者將在今后再次發布本文時做出相應的調整。
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
