相信大家已經看到，在我們的例子中，測試需求同測試用例之間并非是一一對應的關系因為一條測試需求未必是明確的對應到一個有效功能的(其實測試需求本身同軟件需求和用例之間也未必是一一對應的)。而我們的測試用例所關注的，應該是一個有效功能。不過您不用擔心，這種情況并不會增加您管理測試需求和測試用例的成本，現在市面上提供的測試工具中已經有些是專門用來維護軟件需求、測試需求同測試用例之間的關系的，并且它們提供的強大的視圖功能還可以讓您很容易的查看到測試用例對測試需求的覆蓋情況。
對于例子中的測試用例文檔，已經被分成了兩個部分，一部分是描述了測試用例執行者所應遵循的操作過程，一部分則是在操作中需要使用到的測試數據。這樣做的原因是在我們的實際工作中，尤其是在進行功能測試時，很多時候都是使用雷同的操作過程和不同的測試數據來進行的。而使用上面的方法，可以不用再對原本在多個用例中重復出現的操作過程再次描述，而可以把更多的精力放到測試數據的設計和準備上。這樣作帶來的副產品，就是提高了測試用例的可維護性。
怎么?還有人對筆者的觀點持懷疑態度?那好吧，那么我們來嘗試著證明一下。
我們的郵遞員要在5個城市內奔波，并且每個城市都有些郵件需要投遞，他需要找到可以一次走遍5個城市的所有路線。這聽起來似乎并不是太復雜，利用我們已有的數學知識，很容易就可以得到答案。但是對于我們要測試的內容，通常都會包含更多復雜的規則。
例如，我們有三個文本框，每個文本框每次都只能輸入一個英文大寫字母，允許輸入的值只包括：A、B、C三個字母，當三個文本框輸入不同的值的時候，我們不知道會發生什么，也不知道它們之間是否會互相影響，所以需要您來設計可以覆蓋所有輸入情況的測試用例來測試它。
瞧，這很簡單不是嗎?如果我們希望每個測試用例在執行時一旦出現缺陷都可以很快的找到導致缺陷的原因，那么最好的辦法就是每個測試用例只包括一個同其他測試用例不同的輸入值。那么可供我們輸入的值都有哪些呢?嗯，對于每個文本框，都至少有A、B、C三種已經聲明的不同的值，另外，我們還要考慮當文本框為空、輸入空格、輸入非英文字符以及輸入A、B、C之外的英文字符的情況。那么按照上面的方法，我們會有多少測試用例呢?答案是343個。這只是一個很簡單的例子，我們工作中遇到的軟件的業務規則和特性決不會比這少的，那會有多少個測試用例呢?God knows. 不過至少有一點可以肯定，我們無法在原有業務規則發生變化時高效的、無差錯的維護完343個測試用例。
但是如果使用我們前面所描述的方法，對于操作過程的改變，您只需要重新維護一次，而對測試數據的維護，也同樣是非常簡單的，而且并不會因為連續大量修改時出現的錯誤導致測試用例本身出現歧意。
在將主要精力從“設計”操作步驟轉移到設計測試數據之后，我們還將從這種方法中獲得更大的益處——通過“逆向測試數據分析”來提高測試工作的整體效率。
這種“逆向測試數據分析”的方法，是假設軟件中存在多個互相依賴的功能，而且這些功能中包含在“依賴鏈”最末端，并且不再被其他功能依賴的功能。
在我們準備測試數據時，首先從這個“依賴鏈”最末端的功能開始，分析這個功能會對不同的輸入產生哪些不同的結果。然后將所有的輸入進行整理，分清哪些輸入是來源于其前一個功能的輸出。之后，對該功能的上一個功能進行同樣的分析，整理出所有的輸入和輸出，但是這個功能的輸出至少應該包含“依賴鏈”最末端功能接收到的全部輸入。
繼續按照這樣的思路循環向上，直到到達“依賴鏈”開始端的功能。
不知道您在工作中有沒有遇到這樣的情況：在對那些“依賴鏈”上的功能進行測試時，一開始并沒有嚴格的規范測試數據的使用，結果前一個功能測試時產生的數據根本無法在下面的工作中被很好的利用起來，反而因為大量無效數據增加了后面功能的測試難度。最終不得不對每一個功能重新準備測試數據。大量的時間，浪費在了這些重復而低效的勞動上。
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
