从软件测试用例看测试的问题及变化 软件测试

　　对于一个测试人员来说测试用例的设计与编写是一项必须掌握的能力。但有效的设计和熟练的编写却是一个十分复杂的技术，它需要你对整个软件不管从业务还是功能上都有一个明晰的把握。如何系统、结构的对用例加以规范将直接影响到其后的测试效率和效果，同时测试用例也将用来控制软件的整体执行覆盖，对最后的测试结果给出一种量化的评估标准。

　　一、问题：

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

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

　　* 从此几乎很少被执行

　　* 已经与程序的实现发生了冲突(界面变动，功能变动)

　　* 执行用例发现的bug很少

　　* 根本没有时间为新的功能需求增补用例

　　* 有时间补充，但用例结构越来越乱

　　* 特性的用例与通性用例之间联系不明确(以新增需求为主线列出所有涉及到的更改，但特性与通行之间的数据或业务联系在用例中逐渐淡化)

　　知道怎样执行这个用例，但它要说明什么呢?(多数用例给我们的感觉是只见树木，不见森林，只说明某一功能的实现，无法串起)

　　通过上面的一系列问题可以看到，似乎测试用例给我们带来的问题远多于益处，也正是因为在实际过程中遇到的问题积累，导致我们有很充分的理由忽视或拒绝用例的应用。

　　但没有用例或简略用例的编写我们又会舒服很多么?不言自明，谁也不想倒退发展。