最近在整理一个项目上线后回归测试用例，顺便理一下我所理解的回归测试，包括如何整理回归测试用例，回归用例自动化的思路等先抛开自动化，精准测试等先进的回归方法，仅讨论回归用例的范围划定和案例等级划分。回归用例范围划定的太大，会导致每次回归时间的增加，造成人力成本的浪费。回归用例范围划定的太小，会导致覆盖范围不全，最终并不能达到真正的回归目的。所以究竟该如何划定回归测试范围，才能做到有效全面呢？我个人的浅见理解，回归用例要按照几个重要的维度划分出用例等级，根据版本的大小和重要程度，分别执行不同等级的回归用例，做到投入产出比最大化，以下是具体实施思路。
案例等级划分的依据：我的方法是按照重要程度和使用频率去划分案例等级。
1、 1级 - 重要且使用频繁的功能点
a、使用频次最高的功能点，比如登录，以及登录后显示给用户的首页等
b、基础功能
c、出问题会死人的功能，往往是一些核心功能或跟数值相关的功能
d、跟外围下游系统有交互的功能
2、2级 - 重要但使用不频繁的功能点，比如修改密码、重置密码等功能。
3、3级 - 不重要但是使用频繁的功能点，比如首页的banner位，启屏页面的跳转页面等。
4、4级 - 不重要并且使用不频繁的功能点，比如检查版本更新等。
根据发布版本的不同，划定回归用例的范围：
一、线上修复：跟本次修改相关的1级别的用例
二、小版本发布：1级+跟本次相关的2级别的用例+本次发版新功能产生的回归用例
三、比较大的版本发布：1+2+跟本次相关的3级别的用例+本次发版新功能产生的回归用例
四、大版本发布（系统重构、app页面大升级等）：1+2+3+4+新功能产生的回归用例
几个手动回归的小tips:
交替机制：
1. 包括功能模块的owner执行交替负责执行其他模块的回归案例
2. app测试的，要定期交换手机执行回归案例
