【测试用例设计】真的需要用那些理论吗？

测试用例设计的方法有很多：1. 等价类；2. 边界值；3. 错误推测法；4.因果图法；5.判断表驱动法 等等

这些方法都没问题，都是为了解决测试用例场景的覆盖率的问题；个人任务这些方法最佳应用场景有哪些：

1. 指导新手去思考，去发散，去了解场景和需求；

2. 在资源足够的情况去尽可能的覆盖场景；

除了这两个，我实在想不到其他的场景，但是对于现实工作的项目，往往会出现无法应用的情况：

1. 需求都还没弄清楚，前提都没有，你怎么应用方法论；

2. 时间仓促，没时间应用方法论去设计覆盖率高的场景；

3. 开发先行，功能变化很快，即使你按照方法论设计出来，修改和维护会要老命；

4. 重要一点，项目时间的压缩，即使你有很好的测试用例，你有时间执行吗？

说了这么多，就是想说明一点：在现在紧迫的项目中，方法论只能指导测试用例设计，不要想去应用方法论。

那么如果项目紧张，如何去设计测试用例呢？

1. 按照既有的需求，去设计粗略的测试用例，然后逐步去按照细化的需求去完善；

2. 用例的设计方法可以采用正向和方向的设计原则，正向为主，反向为辅，需要3-4步异常造成的用例先放弃；

3. 用例的设计方法采用流程的驱动，根据实际的业务流程，特别是高频的业务场景，重点针对于这些场景；

4. 用例设计中，对于基础数据类的设计，用例要偏多，因为基础打牢才能盖大楼，而这些用例后期基本不会变动或是执行

上述几点可能有纰漏，以后想到了再修正。

本文的结论就是：测试用例的那些理论，不需要应用，那些理论只是打开思维的几个砖头了，思维开放了，根据实际情况调整即可