从测试用例的问题浅谈软件测试

一.对于一个测试人来说，设计和编写测试用例是必须的。但是有效的设计和熟练的编写是一项非常复杂的技术，需要你从业务和功能上对整个软件有一个清晰的把握。如何系统化、结构化地标准化用例，将直接影响后续测试。同时，测试用例也将用于控制软件的整体执行覆盖，并对最终的测试结果给出一个量化的评估标准。

测试相关的很多书都有大段章节介绍用例的设计方法，比如等价类划分、边界值、错误推断、因果图、决策表等等。但是这些理论在实际应用中并不能给我们很精准的行为指导，尤其是当业务复杂、相关模块紧密、输入标准和输出结果之间存在多条路径时，完全遵循这些方法的唯一左右是让我们内心得到满足，并不能真正提高测试水平，也没有足够的时间和资源去编写完整的用例。通常我们只能依靠以前项目中使用案例写作的经验(或者习惯)，希望在这个项目中更加规范。然而，在大多数情况下，我们标准化的是“书面上的标准”，这样只会导致一个结果，那就是以前使用案例设计的问题仍然存在。

当用例基本完成后，我们发现测试用例在面对许多地域特性和新需求时，突然处于非常尴尬的境地：

此后几乎没有再被执行过
已与程序的实现相冲突(界面变更、功能变更)
执行时发现的bug少得可怜
没有时间为新的功能需求增添用例
就算有时间补充，但是用例结构愈发混乱

特性用例和一般用例之间的联系不明确(所有涉及的变更都以新需求为主线列出，但特性和流量之间的数据或业务联系在用例中逐渐淡化

知道怎样执行这个用例，但