许多测试类的书籍都有大幅篇章介绍用例的设计方法，如等价类划分，边界值，错误推断，因果图，判定表等。但实际应用中这些理论却不能给我们很明确的行为指导，尤其是业务复杂，关联模块紧密，输入标准和输出结果间路径众多时，完全的遵循这些方法只能让我们在心理上得到一种满足，而无法真正有效的提高测试效率，并且我们也没有足够的时间和资源编写完备的用例。通常我们只能依靠以前项目的用例编写经验(或习惯)，希望能在这一个项目中更加规范，但多数情况下我们规范的只是“书写的规范”，在用例设计上以前存在的问题现在依旧。

　　当好不容易用例基本完成，我们却发现面对随之而来的众多地区特性和新增需求，测试用例突然处于一种十分尴尬的境地：

　　事实上我们在测试用例编写和设计上遇到的一系列问题只是一种表面的呈现，究其原因我认为有如下几点：

　　每一个测试工程师在进入这个职业的初期都会了解一些测试上的概念和术语，进入公司或项目组后也会进一步学习相应的文档，例如怎样规范编写，怎样定义bug级别，软件实现的主要业务等。但当测试经理开始给我们分配某一模块的用例编写时，又有多少人知道该怎样去写，怎样写算是好?

　　在测试论坛中常能看到介绍用例编写方法的帖子，而迷茫于怎样应用到实践的回复也不为少数。为何我们无法在公司和项目组内找到明确且适合的规范?于是我们只得选择从书本或之前的用例中复制，不管是结构还是方式都依赖于以往的经验，我并不是说这样是错误的，但不能总结成文的经验无法给予测试更多帮助。我们有太多经验，但却没有形成适合的规范。

　　2、功能与业务的分离

　　我们知道怎样列举一个输入框的用例，但却很少考虑说明这个输入框是用来做什么的，如果仔细分析不难发现，用例中这种功能与业务的分离越来越普遍也越来越明显。

　　边界值、等价类划分、因果图，这些用例方法是一种高度提纯的方法，本身很偏向于功能及代码，所以怎样编写业务的用例我们从理论上失去了参考。

　　复杂的业务会贯穿于整个软件，涉及众多功能点，里面组合的分支更不可胜数。测试用例务求简洁、明确，这一点也与业务“格格不入”。功能用例依赖程序界面，业务描述依赖需求文档。于是我们更偏向于根据已实现的界面编写功能用例，列举出众多的边界值、等价类。流程的操作只有凭借经验和理解，这时测试出的bug是多的，但我们却无法使这个bug对应到一个用例中(点击一个按钮报出的错误有时原因并不在这个按钮或按钮所在的窗体)，只能自己添加note向开发人员指出可能出错的源头。正因为我们没有很好的积累业务上的用例，才使得我们感到执行用例时发现的bug不多。