就像小说里那些早慧的少年，很早就尝试过用例驱动的需求文案，结果与客户，一个愁默默，一个恨绵绵。
最狂热的用例编写者也承认，用例对客户与需求人员都是一种heavy的相互折磨。
客户看用例时总要收摄心神来阅读整个交互的流程，还有那些该死的扩展流异常流，没经过程序员专业抽象训练的客户，对着这些伪代码一般的情景脚本，刚开始的一两个还好，看多了，就是白天也能睡去。客户只是看都如此了，负责写的人当然也不会好过。
但heavy的工作总有heavy的好处，否则早被唾弃于舞台的背面。
在用户的角度，用例比模棱两可的功能点描述要清晰，也更直白于系统的价值。
在开发团队角度，RUP的核心方法论之一---用例驱动的口号，明白人自然明白它的妙用。
设计人员的新设计手段：“用时序图分析用例的实现，在描述过程中确定构件或类，分配它们的职责和方法”，通过对用例覆盖率的追踪，需求与设计之间的信息损耗这个famous problem大大降低。
测试人员和文档人员，更可以直接把系统用例笑纳为《测试用例》和《用户手册》。
来到亿迅后，被这里的用例文明给震住了，每个项目的软件规格说明都是屯门清一色的几百页的前景，用例规约，业务规则，词汇表，补充规约组成.......难得有情郎啊。
昨天又看到了一批新的用例诞生，但实在有好些明显的不足啊，忍不住旧事重提的记下一批经典的错误。不过.....只要能和客户达成需求共识，就是一份好的用例了，也不用花太多时间在学术性的讨论上。
1.客户没有能力阅读用例
如果客户实在没办法撑住困意看完用例的细节，即使草草签了名，得不到用户真正确认的用例，依然无法用来驱动设计和测试。
解决方法：放弃编写用例，改回用户容易看的传统方式。
2.团队没有能力实现用例驱动
如果开发团队在设计与测试时，根本不依照用例细节驱动，那用例对开发团队就只是个摆设，花瓶。
解决方法：对设计、测试人员进行用例驱动的培训，如果事不可为就干脆放弃，怎么省事怎么做。
文章来源于领测软件测试网 https://www.ltesting.net/
