就像小說里那些早慧的少年，很早就嘗試過用例驅動的需求文案，結果與客戶，一個愁默默，一個恨綿綿。
最狂熱的用例編寫者也承認，用例對客戶與需求人員都是一種heavy的相互折磨。
客戶看用例時總要收攝心神來閱讀整個交互的流程，還有那些該死的擴展流異常流，沒經過程序員專業抽象訓練的客戶，對著這些偽代碼一般的情景腳本，剛開始的一兩個還好，看多了，就是白天也能睡去�？蛻糁皇强炊既绱肆�，負責寫的人當然也不會好過。
但heavy的工作總有heavy的好處，否則早被唾棄于舞臺的背面。
在用戶的角度，用例比模棱兩可的功能點描述要清晰，也更直白于系統的價值。
在開發團隊角度，RUP的核心方法論之一---用例驅動的口號，明白人自然明白它的妙用。
設計人員的新設計手段：“用時序圖分析用例的實現，在描述過程中確定構件或類，分配它們的職責和方法”，通過對用例覆蓋率的追蹤，需求與設計之間的信息損耗這個famous problem大大降低。
測試人員和文檔人員，更可以直接把系統用例笑納為《測試用例》和《用戶手冊》。
來到億迅后，被這里的用例文明給震住了，每個項目的軟件規格說明都是屯門清一色的幾百頁的前景，用例規約，業務規則，詞匯表，補充規約組成.......難得有情郎啊。
昨天又看到了一批新的用例誕生，但實在有好些明顯的不足啊，忍不住舊事重提的記下一批經典的錯誤。不過.....只要能和客戶達成需求共識，就是一份好的用例了，也不用花太多時間在學術性的討論上。
1.客戶沒有能力閱讀用例
如果客戶實在沒辦法撐住困意看完用例的細節，即使草草簽了名，得不到用戶真正確認的用例，依然無法用來驅動設計和測試。
解決方法：放棄編寫用例，改回用戶容易看的傳統方式。
2.團隊沒有能力實現用例驅動
如果開發團隊在設計與測試時，根本不依照用例細節驅動，那用例對開發團隊就只是個擺設，花瓶。
解決方法：對設計、測試人員進行用例驅動的培訓，如果事不可為就干脆放棄，怎么省事怎么做。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
