测试用例设计的方法有很多:1. 等价类;2. 边界值;3. 错误推测法;4.因果图法;5.判断表驱动法 等等
这些方法都没问题,都是为了解决测试用例场景的覆盖率的问题;个人任务这些方法最佳应用场景有哪些:
1. 指导新手去思考,去发散,去了解场景和需求;
2. 在资源足够的情况去尽可能的覆盖场景;
除了这两个,我实在想不到其他的场景,但是对于现实工作的项目,往往会出现无法应用的情况:
1. 需求都还没弄清楚,前提都没有,你怎么应用方法论;
2. 时间仓促,没时间应用方法论去设计覆盖率高的场景;
3. 开发先行,功能变化很快,即使你按照方法论设计出来,修改和维护会要老命;
4. 重要一点,项目时间的压缩,即使你有很好的测试用例,你有时间执行吗?
说了这么多,就是想说明一点:在现在紧迫的项目中,方法论只能指导测试用例设计,不要想去应用方法论。
那么如果项目紧张,如何去设计测试用例呢?
1. 按照既有的需求,去设计粗略的测试用例,然后逐步去按照细化的需求去完善;
2. 用例的设计方法可以采用正向和方向的设计原则,正向为主,反向为辅,需要3-4步异常造成的用例先放弃;
3. 用例的设计方法采用流程的驱动,根据实际的业务流程,特别是高频的业务场景,重点针对于这些场景;
4. 用例设计中,对于基础数据类的设计,用例要偏多,因为基础打牢才能盖大楼,而这些用例后期基本不会变动或是执行
上述几点可能有纰漏,以后想到了再修正。
本文的结论就是:测试用例的那些理论,不需要应用,那些理论只是打开思维的几个砖头了,思维开放了,根据实际情况调整即可