MILY: '宋體'; mso-spacerun: 'yes'">軟件測試用例的粒度的討論
測試用例的粒度：每個測試用例所覆蓋的測試范圍或者期望結果的多少。
================================================
也談測試用例的粒度
1.看項目Schedule：在項目時間緊張的情況下，往往留給測試人員的時間很有限，測試工作的重點就是多測試，早發現問題，這時候我認為測試用例的粒度是可以放粗一些的，但是“粗”不代表隨意，雖然可以放“粗”一些，但是要能明確測試要點，分清主次。而在項目時間寬裕的情況下，我還是希望能盡量將測試用例寫細一些，因為在寫測試用例的同時，也能加深對產品的理解。此外，測試用例的粒度寫的細，也能為后期的測試執行提供很大的幫助，為后期確定測試退出提供一定的數據支撐。
2.看項目人員情況：在項目實施過程中，測試用例通常是由具有較豐富測試經驗的人來負責并主導編寫的。對于測試新人，測試用例往往對新人更快更好的理解產品并完成測試任務提供了非常大的幫助。因此，對于測試新人，希望測試用例粒度細點是可以理解并認可的。而對于測試老鳥，很多時候他們既是測試用例的編寫者，同時也是測試用例的執行者，他們往往會有這樣一種認知：既然測試用例都是我來執行，我為什么要寫的那么細呢?我自己知道不就可以了嗎?編寫測試用例只是從流程上保證項目質量的手段之一，只要我能將把好質量關，又何必苛求于測試用例的粗細?重要的是測試的思想，而不是測試用例的粗細，測試用例粒度寫的太細會占用太多的時間，我為什么不把時間投入到如何提高測試效率等更有價值的事情上去?測試新人有測試新人的道理，而測試老鳥的認知也有其道理，因此，在一個項目組中，如果測試新人所占比例較大，對測試用例的粒度要求還是要盡可能細些，這樣可以幫助新人更好的適應項目角色，而對測試老鳥來說，一起教總比一個個教來得更有效率。
3.看客戶需求：有些客戶，在驗收產品的時候，會要求一并提供測試用例以及其執行情況，這種情況下，無論項目Schedule是否緊張，都需要按照客戶的要求來完成，因為這也是一項需求。
4.看項目本身是否具有延續性：隨著產品的多元化，產品的升級換代速度是很快的，換個UI，換個組織架構，或者重新包裝一下就是一個新的產品。這種情況下，總會有些功能模塊是一致的，測試用例也是可以復用的。因此，對于一些具有延續性的項目，個人還是認為測試用例的粒度可以盡量細一些，這樣有利于知識的傳承。而對于那些一次性的項目，測試用例粒度稍微粗些也沒關系，只要不影響項目質量就好。
總的來說，個人認為測試用例的粒度并沒有特定的標準，要依據項目實際情況而定。測試用例粒度當然是越細越好，但這僅是理想上的，實際上可操作性還是一個大大的問號。在實際執行中，要依據項目的實際情況和公司的相關制度而定，適用的才是最好的，畢竟項目的質量好壞才是最終的目標，如果因為糾結于過程而影響到最終的結果恐怕就不好了，過程是為了服務于結果，可不要陷入為了過程而過程的怪圈。
=======================================================
實際上測試用例的粒度主要考慮下面幾個因素：
復用情況：如果隨著產品不停得升級，需要設計的詳細些，追求一勞永逸，反之僅使用一兩次，則沒有必要設計的過于詳細；
項目進度：項目時間如果允許可以設計的詳細些，反之則能執行即可；
使用對象：測試用例如果供多人使用，尤其讓后參加測試的工程師來執行，則需要設計的詳細些。
為了方便理解，我們可以先看一下下面的例子。
拿我們常見的財務軟件來說，當添加一張會計憑證時，通常是需要填寫會計科目，在使用計算機完成工作時，我們可以利用軟件的功能，從很多備選科目中選擇一個自己需要的科目，或者通過科目代碼來輸入科目。這項功能很有可能會作為一個特性要求出現在軟件需求規格說明書中，那么這個科目的選擇或輸入是不是一個有效功能呢？讓我們試著用上面規則來衡量一下。
首先，這個功能在用戶手工業務處理過程中是存在的，不同的是這項功能是在用戶填寫憑證時，在自己的大腦中完成的——用戶會根據需要，在自己記憶的科目中選擇合適的填寫上去，這項功能節省了用戶在記憶大量會計科目時付出的額外勞動。我們可以認為這個功能是為用戶原來的工作提供了一種簡便的、變通的方法。
那么這項功能的完成對于用戶來說意味著什么呢？我們從上面的描述中可以看到，用戶希望軟件提供的是可以添加一張完整的憑證這樣的功能，而不僅僅是方便填寫會計科目。填寫會計科目只是用戶在添加憑證時的一個步驟，單獨把這個功能提取出來對用戶來說沒有任何實際意義。對于業務流程下游的用戶，需要的也不僅僅只是一個會計科目的信息，而是一張包含了會計科目以及其他會計信息的完整的會計憑證，否則就無法進行下面的工作。這樣看來，這個功能并不是一個有效的功能，我們可以把它最為需要測試的特性在測試需求中進行描述，卻不應該作為一個單獨的測試用例出現在我們的測試用例集中。而我們在測試用例中真正關注的，應該是添加會計憑證這個具有實際意義的功能。
另外，我們還需要關注如何將多個相互之間存在依賴關系的功能區分為單個的有效功能。例如，現在有A、B、C三個功能，其中B功能的開始必須依賴于A功能的完成，而且A功能如果出現不同的完成狀態，B功能也會做出不同的反應；C功能對B功能的依賴也是如此。那么這時候，我們是否應當將三個相互依賴的功能包含在一個測試用例中呢？這樣的做法也不是不可以，但是我們也可以先判斷一下，這三個功能是否都是有效功能（您可以使用前面提到的方法來試著評判一下）？如果A、B、C都是獨立的有效功能，那么我們可以從上面的描述中發現，它們之間存在的依賴性，可以理解為是一種狀態或者說數據的依賴性。后一個功能關心的，是前一個功能最終提供給它的是什么樣的“輸入”，而不是前一個功能到底作了些什么。這樣看來，我們完全可以將它們分別包含在幾個獨立的測試用例中，而在每個測試用例的開始，把不同的輸入作為不同前置條件來描述。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
