拿我們常見的財務軟件來說，當添加一張會計憑證時，通常是需要填寫會計科目，在使用計算機完成工作時，我們可以利用軟件的功能，從很多備選科目中選擇一個自己需要的科目，或者通過科目代碼來輸入科目。這項功能很有可能會作為一個特性要求出現在軟件需求規格說明書中，那么這個科目的選擇或輸入是不是一個有效功能呢?讓我們試著用上面規則來衡量一下。
首先，這個功能在用戶手工業務處理過程中是存在的，不同的是這項功能是在用戶填寫憑證時，在自己的大腦中完成的——用戶會根據需要，在自己記憶的科目中選擇合適的填寫上去，這項功能節省了用戶在記憶大量會計科目時付出的額外勞動。我們可以認為這個功能是為用戶原來的工作提供了一種簡便的、變通的方法。
那么這項功能的完成對于用戶來說意味著什么呢?我們從上面的描述中可以看到，用戶希望軟件提供的是可以添加一張完整的憑證這樣的功能，而不僅僅是方便填寫會計科目。填寫會計科目只是用戶在添加憑證時的一個步驟，單獨把這個功能提取出來對用戶來說沒有任何實際意義。對于業務流程下游的用戶，需要的也不僅僅只是一個會計科目的信息，而是一張包含了會計科目以及其他會計信息的完整的會計憑證，否則就無法進行下面的工作。這樣看來，這個功能并不是一個有效的功能，我們可以把它最為需要測試的特性在測試需求中進行描述，卻不應該作為一個單獨的測試用例出現在我們的測試用例集中。而我們在測試用例中真正關注的，應該是添加會計憑證這個具有實際意義的功能。
另外，我們還需要關注如何將多個相互之間存在依賴關系的功能區分為單個的有效功能。例如，現在有A、B、C三個功能，其中B功能的開始必須依賴于A功能的完成，而且A功能如果出現不同的完成狀態，B功能也會做出不同的反應;C功能對B功能的依賴也是如此。那么這時候，我們是否應當將三個相互依賴的功能包含在一個測試用例中呢?這樣的做法也不是不可以，但是我們也可以先判斷一下，這三個功能是否都是有效功能(您可以使用前面提到的方法來試著評判一下)?如果A、B、C都是獨立的有效功能，那么我們可以從上面的描述中發現，它們之間存在的依賴性，可以理解為是一種狀態或者說數據的依賴性。后一個功能關心的，是前一個功能最終提供給它的是什么樣的“輸入”，而不是前一個功能到底作了些什么。這樣看來，我們完全可以將它們分別包含在幾個獨立的測試用例中，而在每個測試用例的開始，把不同的輸入作為不同前置條件來描述。
測試用例是否應該包含所有的細節?
這是在網絡上聽到訴苦最多的又一個熱點問題：公司要求按照一個嚴格的規范來開展測試工作，必須書寫所有的測試用例文檔，要求文檔的書寫一定要具體，并在執行測試時要參考測試用例文檔來進行。如果測試用例文檔寫的過于簡略，則會被領導斥為偷懶。但是，如果文檔中的對操作步驟描述的過于具體，像下面這樣：
01. 在“用戶名”項中輸入“user”;
02. 在“密碼”項中輸入“password”;
03. 點擊“確定”按鈕。
這樣的描述方式表面看起來可操作性似乎是增強了，任何人拿到這個文檔都可以充當測
試人員，檢查一下這個功能是否存在缺陷。但是我們不要忘記，在開發過程中，變更的存在是必然的。一旦需求、設計或者應用程序中的某些細節發生了變化，比如“用戶名”變成了“操作員”，“密碼”變成了“口令”，“確定”變成了“登錄”，或者輸入項所接受的數據類型發生了變化，那么同這部分內容相關的所有的測試用例都需要修改。否則，我們憑什么可以保證這些描述不同的測試用例說的是同一樣東西?如果我們只有這么一個測試用例，也許一切都不是問題，但是對于一個業務復雜、功能完整的系統，如果按照這樣的方法描述測試用例，最終要么產生大量的測試用例文檔，要么產生過長的單個文檔。無論是那一種，如果發生了類似于上面說的變化，維護文檔都將變成一次地獄式的體驗。
這也是為什么在網絡上頻頻出現的這個問題，而且每次出現都會受到測試同行們的關注的原因。那么這個問題應該任何解決呢?測試用例是不是把所有的流程寫出來就可以了呢?如何在減少測試用例文檔中包含過多瑣碎的細節的同時保證測試用例的可操作性呢?又有什么方法可以提高我們維護測試用例文檔的效率呢?
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
