在日常測試時，我們在執行用例的過程中經常會遇見這樣的問題：當一條用例執行后，我們會發現后續的一些用例是冗余的，並不需要執行。例如對於“用戶只准中獎一次”的規則，我們設計用例“今天中獎后當日再次抽獎不中獎”以及“今天抽獎后明天允許抽獎但不中獎”，很明顯，我們的校驗點很簡單，就是驗證“用戶只准中獎一次”這個功能點。但是為什么我們在后期用例執行的過程中才會發現我們設計的用例存在冗余呢？
我想，造成這樣的原因之一是因為對於功能點的理解過於表面。也許遇到這個校驗點時，從用例完善的角度出發，我們很容易想到上述兩條用例，但是到測試階段的后期，我們會發現就開發的實現方式而言，后述的用例成為了冗余，因為開發根本就沒有關注過時間這樣的字段，程序的實現過程關心的只是是否有插入過一條中獎數據而已。
在日常過程中我們應該多關心功能點的背后的真諦，而不是盲目的根據需求文檔和UC去編寫功能測試用例，這一點就我自身的感受而言覺得相當重要。
其次，我認為思維定勢也會對我們的用例編寫產生一定的影響。從自身所在的會員產品線出發，目前會員的等級分為普通會員、榮譽會員、VIP1、VIP2、VIP3五個等級，在會員信息表中存在一個標志位通過依次連續的數值來分別予以標記。我們的慣性思維是當涉及到等級的相關業務時，我們會驗證每一個等級的情況，例如某項功能暫時開放給VIP3用戶使用，由於情況本身是可以列舉的，這種功能性測試我們可能習慣性的去驗證對於每一類型的會員否會打開這個功能的入口。而事實上根據邊界值分析法，在這個功能點上我們只需要執行兩條用例即可。
當然這里只是給大家一種用例編寫的思路，而不是說一定要大家不把用例寫得冗余，冗余的用例也是測試人員的一顆定心丸。在我們不了解程序內部實現的情況下，把用例設計的越發完備也是有必要的。畢竟，發現測試用例冗余的過程往往伴隨在我們執行測試的過程中，基於測試過程對應用更加了解的情形下才會意識到的。能夠把用例設計的恰如其分也需要一定經驗的積累。
還記得在一開始寫測試用例的時候，自己設想測試的粒度要越細越好，而時間久了就很容易導致一個極端—用例的過度設計，這也是自己為什么會寫這篇文章的原因，主要是啟發自己在以后測試用例的設計中多一些思考。當我們更深入的探究這個話題的時候，這就成了一個測試策略的問題，而這又會引發更多的思考，諸如用例是否容易轉換為自動化腳本等。
總而言之，一個優秀的測試策略需要我們在平時的工作中多一些積極的思考，如何做好取舍，如何量體裁衣，如何發揮測試工程師的最大價值，都要求我們從經驗中去潛心汲取、慢慢累積。