回归测试怎么做？回归测试什么时候做？

---

前言

有效的回归测试
①最有效的回归测试方法应该建立在开发测试库的基础上;
②开发在创建测试库，每次生成程序的新版本时都可以运行这些用例；
③只有有效的从源头避免风险才能有效的进行回归测试；
④强调单元测试时加强回归测试，引入代码评审，引入自动测试;
⑤集成和系统级的测试时，加强测试用例评审，回归测试用例的选择;
⑥开发设计测试用例时制定优先级，如高，中，低，方便以后自动化或是策略选择;
⑦配置管理时，引入测试用例基线管理，有效管理测试用例;
⑧定期维护测试用例增，删，保持最新状态。

测试工作中，新人对于测试流程、测试方法都有可以直接拿来用的教材，但是对于回归测试中的bug处理的细节，往往需要我们更多的经历才能更好的完成自己的工作，下面我们来谈一谈回归测试bug的处理中需要关注的点：

一、什么是回归测试？

回归测试是指在发生修改之后重新测试先前的测试以保证修改的正确性。理论上，对软件的任何新版本，都需要进行回归测试。

验证以前发现和修复的错误是否在新软件版本上再现，并确认曾经通过的功能不会出现问题。

二、回归测试做多少次？

很多资料都有具体指定回归的次数，在我看来，回归测试不能确却的给出一个项目具体做多少轮回归测试，因为，版本不可控的因素太多了，需求的更改、人员的流动。

开发的编码甚至还有很多其它市场因素都会造成版本的变动与推迟，只要有新版本势必就会做回归测试，因此在一开始规定回归测试的次数这是不可取的。

一般只要出新版本就会有回归测试，极少的情况在没有新版本的情况下，为了快速检验版本质量，也会根据补丁进行回归测试（不推荐）。

三、回归测试做什么？

很多人在做回归测试的时候，都是原原本本的按bug步骤进行验证。事实上，这样做的回归测试是远远不够的。做回归时，不光要验证bug中的内容 ，还要对bug中所有相关业务都要做基本的验证。

另外，bug中如果只提到一个导致bug的入口（举例：修改项目中某个人的信息，一定会存在新建与修改并存的地方，也会在其它地方可进行修改），那么在验证的时候也应该将所有入口都验证到。

这在要求测试人员对测试业务非常熟悉的同时，还要求懂点代码，会根据开发的修改方案在代码上与业务上都进行回归。事实上，当每轮的bug都有根据业务的扩展与涉及来进行了验证的话，在回归测试里可以将冒烟完成大部分（具体依bug的数量与模块决定 ）。

四、回归测试何时结束？

回归测试的结束应该从以下两方面阐述：

1）一个bug的关闭

当验证bug可以正常关闭时，应该在关闭bug的时候备注以下几点：

回归版本：验证的版本号

回归步骤：回归bug的步骤

回归结论：是否回归通过。如果通过就可以直接关闭，如果验证过程中还有其它问题，就要进行二次回归，就需要在回归结论里进行阐述还存在的问题现象及场景，并再次激活指派给开发。

2）一轮回归的结束

新版本出来后，会存在一些无法重现、评审通过此版本先不解决的、出版本之际由于时间安排推迟到下一个版本的bug，针对这些特殊情况的bug进行特殊处理后，所有bug都进行了回归 ，那么一轮的回归测试就算结束了

五、回归测试里我们还可以做什么？

在做回归时，有些bug会转为需求，也会因为一些bug在业务上有大小的变动，一轮回归下来，除了将bug都进行回归外，还会根据bug的性质对用例进行相对的增加与修改，相对应的应该根据实际情况对用例进行新增与修改。

同样的，一轮测试下来，做测试总结的时候，也会得出在业务上的薄弱点，这个时候也应该对用例库进行整理，对不受控与存在冗余、或是由于新增导致变动的用例都相应的进行修改。

回归测试虽然做的事情比较单一，但是实际过程中，只要好好把握这个过程，不仅可以对业务的熟悉有大的提升，还可以借此整理用例库从而更好的通过用例测出高质量的bug，对于想通过bug来找点测试思路甚至作为熟悉业务也不失为一种好方式。

六、总结

生活可以是甜的，也可以是苦的，但不能是没味的。你可以胜利，也可以失败，但你不能屈服。

目标的坚定是性格中最必要的力量源泉之一，也是成功的利器之一。没有它，天才会在矛盾无定的迷径中徒劳无功。

过所爱的生活，爱所过的生活，快乐的生活，才能生活快乐，快乐的工作，才有快乐人生，生活的理想其实就是理想的生活!