灌水 回归测试 大家都用什么办法来做的

徐旻 · 2018年03月05日 · 最后由 daivd 回复于 2018年03月08日 · 2276 次阅读

作为现在开发流程比较高效的敏捷开发流程,大家都是怎么做回归测试的。

方案一,每次手动进行一下必要的简单回归,但是随着迭代内容越来越多,就算是简单的回归测试的时间也会慢慢的增加。
方案二,自动化一些回归测试,那么就是需要编写脚本的时间,并且写的脚本质量要高,不然维护成本就会很大。
方案三,半手动,半自动。
方案四,通过精准测试定位出对本次代码修改需要测试内容,对这些内容进行回归。(问题是有没有开源的工具可以用?另外还有一些 bug 不是代码本身造成的,比如第三方接口进行了修改,这种 bug 是精准测试找不到的。)

谁还有好的解决方案,求指点~

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 5 条回复 时间 点赞

精准回归一直是大问题

恒温 回复

最近在尝试的是精准回归除了基于代码与业务的对应关系(代码覆盖情况)之外,是不是可以从业务角度,梳理产品的业务节点,然后将产品目前的业务流程通过业务节点串起来,之后的工作就是不断丰富和调整业务节点和业务流。理想的展现形式应该是类似火车路线图,然后根据站点的调整选择测试经过这个节点的路线。但在做的过程中发现业务节点的梳理特别困难,大神能否给点建议?这种思路是否可行,或者业界是否有类似的方案?

AngryTester 回复

我也不懂,但是总觉得应该做剪法

恒温 回复

嗯 这种确实感觉越做越复杂……

尝试过用外包来做回归,时效性比较差。自己做回归梳理完业务,做了一半

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册