现状原因：
- 复杂的业务会贯穿于整个软件，涉及众多功能点，里面组合的分支更不可胜数。
- 功能用例依赖程序界面，业务描述依赖需求文档。（功能与业务的分离的缺点）
- 没有很好的积累业务上的用例，才使得执行用例时发现的bug不多。
如何解决以上涉及测试用例中遇到的问题：
- 测试驱动开发（TDD）。其基本思想是：在开发功能代码之前，先编写测试代码。
- 为用例标明时间（版本）和优先级。标明时间或版本可以起到一种基准的作用，标明项目进度过程中的每个阶段，使用例直接和需求基线、软件版本对应。同样这需要规范流程，也是对变更的一种确认和控制。或者可以为用例增加一个状态，致命这个用例目前是否与程序冲突，当程序变更时改变用例的状态，并更新用例版本。
为测试用例标明优先级可以指出软件的测试重点、用例编写的重点，减少用例回归的时间，增加重点用例执行的次数，帮助项目组新人尽快了解需求，在自动化测试的初期也可以参考这个优先级录制脚本。
3.功能用例与业务用例分开组织。将功能用例和业务用例分来组织，按照不同关注点列举执行路径。业务用例应在开发前或同期编写，帮助测试人员和开发人员明确业务，了解正确流程和错误流程。功能用例更依赖于程序界面的描述，但功能用例并不等于使用说明。对某些模块的等价类、边界值测试会发现很多严重的bug，也许与业务无关，但用户往往很容易这样操作（例如登录名，你是否考虑到很长的名字，或者用户的键盘有问题，总是敲入n多空格在里面，这与业务无关，但程序将会怎样处理？）。
