一、问题：
许多测试类书籍中都有大幅的篇章介绍用例的设计方法，如等价类划分，边界值，错误推断，因果图等。但实际应用中这些理论却不能给我们很明确的行为指导，尤其是业务复杂，关联模块紧密，输入标准和输出结果间路径众多时，完全的遵循这些方法只能让我们在心理上得到一种满足，而无法有效的提高测试效率。有时我们只有依靠以前项目的用例编写经验（或习惯），希望能在这一个项目中更加规范，但多数情况下我们规范的只是“书写的规范”，在用例设计上以前存在的问题现在依旧。
当好不容易用例基本完成，我们却发现面对随之而来的众多地区特性和新增需求，测试用例突然处于一种十分尴尬的境地：
从此几乎很少被执行
已经与程序的实现发生了冲突（界面变动，功能变动）
执行用例发现的bug很少
根本没有时间为新的功能需求增补用例
有时间补充，但用例结构越来越乱，
特性的用例与通性用例之间联系不明确（以新增需求为主线列出所有涉及到的更改，但特性与通行之间的数据或业务联系在用例中逐渐淡化）
知道怎样执行这个用例，但它要说明什么呢？（多数用例给我们的感觉是只见树木，不见森林，只对某一功能，无法串起）
通过上面的一系列问题可以看到，似乎测试用例给我们带来的问题远多于益处，也正是因为在实际过程中遇到的问题积累，导致我们有很充分的理由忽视或拒绝用例的应用。
但没有用例或简略用例的编写我们又会舒服很多么？不言自明，谁也不想倒退发展吧。
二、原因：
事实上我们在测试用例编写和设计上遇到的一系列问题只是一种表面的呈现，究其原因我认为有如下几点：
1、没有适合的规范
“适合的规范”或称“本地化的规范”。这是我们在测试过程中遇到的第一个问题，通常也是很容易习惯且淡忘的。我们拥有相当多的流程文档、书本上的定义，但它适合我们当前的项目么？
每一个测试工程师在进入这个职业的初期都会了解一些测试上的概念和术语，进入公司或项目组后也会进一步学习相应的文档，例如怎样规范编写，怎样定义bug级别，软件实现的主要业务等。但当测试经理开始给我们分配某一模块的用例编写时，又有多少人知道该怎样去写，怎样写算是好？
在测试论坛中常能看到介绍用例编写方法的帖子，而迷茫于怎样应用到实践的回复也不为少数。为何我们无法在公司和项目组内找到明确且适合的规范？于是我们只得选择从书本或之前的用例中复制，不管是结构还是方式都依赖于以往•的经验，我并不是说这样就是错误的，但不能总结成文的经验无法给予测试更多帮助。
我们有太多经验，但却没有形成适合的规范。
2、功能与业务的分离
我们知道怎样列举一个输入框的用例，但却很少考虑说明这个输入框是用来做什么的，如果仔细分析不难发现，用例中这种功能与业务的分离越来越普遍也越来越明显。
边界值、等价类划分、因果图，这些用例方法是一种高度提纯的方法，本身就很偏向于功能及代码，所以怎样编写业务的用例我们就从理论上失去了参考。
软件测试技术: 软件测试工程师 测试用例 功能测试 测试管理 缺陷管理 手机测试 自动测试 单元测试 性能测试 安全测试 软件测试环境 Windows Unix 网络知识 服务器 开源测试: 开源功能测试 开源性能测试 开源缺陷管理 开源配置管理 开源解决方案 测试开发: JAVA .net UML 脚本语言 数据库 中间件 测试资料 商业测试工具 开源测试工具 软件测试教程 质量保证 项目管理 需求管理 软件度量 项目估算 质量模型 解决方案 测试工具 Mercury测试工具 Rational测试工具 Silk测试工具 其它
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/