谈一谈回归测试的场景

草帽路飞UU

回归测试是指修改了源代码后，重新测试以确认修改有没有引入新的错误或导致其他代码产生错误。



　　现在的软件开发都是并行化的，一个RD（指研发，下同）小组负责几个功能，多个RD小组负责整个App从前端到后端和服务端的功能开发。

　　当把多个小组代码进行merge的时候，需要确认这些小组内实现的几个功能，以及小组间实现的若干功能不会产生相互影响，程序的业务逻辑能够正常进行下去，这时候进行的测试就被称作回归测试。
　　回归测试很多时候面对的是薛定谔的bug，就是回归测试很大程度上可能不会发现bug，但这部分测试工作又不能被省略掉，因为一旦存在bug，bug的严重程度可能会很高。

　　回归测试的场景

　　开发修改完bug之后。

　　验证其他和此bug有依赖关系的场景用例是否正常。

　　回归测试是软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。

　　因此回归测试的自动化将能够大幅度降低系统测试、维护升级的成本。

　　回归测试用例抽取技巧

　　如果系统目前为止已经比较稳定，那么可以根据8/2（80%的缺陷出现在20%的模块中）的原则来挑选回归测试的用例。

　　针对问题较多的模块进行执行用例，其他模块仅对缺陷相应的功能点执行用例。

　　业务程度比较复杂的情况下，对用户频繁使用的功能模块进行回归测试。

　　开发对某个模块的功能进行来小规模的修改时，也需要进行回归测试。

oliver.tang