一个测试老手对用例设计的疑惑
虽然做测试很久了，用例设计做的也很多，但是仔细想一下写用例的方式，基本上就是先划分模块，再针对每个模块的不同功能，按照等价类边界值的方法去设计用例。基本上没有用过因果图这些复杂的设计方法。
这种方式个人也觉得不严谨。大家做真实的用例设计时，是什么情况，一起交流下。 其实也就是你提到的几种。因果图较为复杂，在项目很紧或者业务很复杂的情况，用这些复杂的测试用例，不易判断。测试用例有些是公开给别人看的，简单明了更容易理解吧 方法论是死的，业务是活的，人也是活的，问这个问题就要想想：我们为什么设计测试用例？再次回归测试用例的核心价值是什么？
设计用例之前包括过程中，包括执行用例都是测试不断思考的过程，我们会做测试分析，会筛选出范围，依赖影响，挖出隐藏需求，包括各种风险，这个过程很重要，然而你采用什么样的形式根本没人关心，我觉得测试的价值体现就在于你交出去的东西能让别人用的爽，容易高潮;P;P;P;P
新人，才会跟大家讨论具体用什么方法设计测试用例。
对于从业多年，用例设计方法是融入整体用例设计过程中，综合运用各种设计方法。
对于 错误推测、 场景法 ，基本上随处可见。
是的，刚入门的小伙伴会很纠结，时间久了之后，用的多的就是经验论。可以总结是从各种方法中提炼出来的精华。;P joykao 发表于 2017-7-13 13:29
方法论是死的，业务是活的，人也是活的，问这个问题就要想想：我们为什么设计测试用例？再次回归测试用例的 ...
"我们会做测试分析，会筛选出范围，依赖影响，挖出隐藏需求，包括各种风险",
这段个人觉得挺好的，跳出了单独一模块，从整体出发，更全面也容易发现问题。 xuquan 发表于 2017-7-13 13:46
新人，才会跟大家讨论具体用什么方法设计测试用例。
对于从业多年，用例设计方法是融入整体用例设计 ...
同感。
刚入行测试的时候，根本不懂什么方法，想的也就是测试全面些，跌跌撞撞也走过去了。
但是现在了解了这些方法，回过头去想把它们跟实际结合起来时，就有了前面提到的困惑，就是理论和实践的差距，单纯几个设计方法无法保证你的软件是经过完全测试的。
页:
[1]
