关于回归用例和回归用例自动化的实施思路

最近在整理一个项目上线后回归测试用例，顺便理一下我所理解的回归测试，包括如何整理回归测试用例，回归用例自动化的思路等先抛开自动化，精准测试等先进的回归方法，仅讨论回归用例的范围划定和案例等级划分。回归用例范围划定的太大，会导致每次回归时间的增加，造成人力成本的浪费。回归用例范围划定的太小，会导致覆盖范围不全，最终并不能达到真正的回归目的。所以究竟该如何划定回归测试范围，才能做到有效全面呢？我个人的浅见理解，回归用例要按照几个重要的维度划分出用例等级，根据版本的大小和重要程度，分别执行不同等级的回归用例。 

案例等级划分的依据：我的方法就是掐头去尾法，掐头就是找出最重要的功能点，去尾就是去掉最不常用的功能点。 

1、 1级 - 重要的功能点 

    a、使用频次最高的功能点，比如登录，以及登录后显示给用户的首页等 

    b、基础功能 

    c、出问题会死人的功能，往往是一些核心功能或跟数值相关的功能

    d、跟外围下游系统有交互的功能 

2、3级 - 最不常使用的功能点 

3、2级 - 理出剩余的功能点 

根据发布版本的不同，划定回归用例的范围：

一、线上修复：跟本次修改相关的1级别的用例 

二、小版本发布：1级+跟本次相关的2级别的用例+本次发版新功能产生的回归用例 

三、比较大的版本发布：1+2+跟本次相关的3级别的用例+本次发版新功能产生的回归用例 

四、大版本发布：1+2+3+新功能产生的回归用例 

关于回归自动化的实现： 

 回归自动化在案例等级的基础上又会有两个不同维度： 

1、 功能是否稳定

2、 实现容易程度 

回归自动化最大的人力消耗来自于每次发版后的脚本维护，回归自动化存在的首要意义就是释放人力，如果因为要维护自动化脚本，或者因为自动化运行的成功率不高等原因要占用大量的人力的话，不但自动化做不好，功能测试也无法得到保证。要保证一个等式成立：维护自动化的耗费的人力<自动化替代的人力所以首选的自动化的功能模块一定是可以预见性的比较稳定的模块，其次是挑选比较容易实现自动化的案例。 

结合案例的等级，实现的顺序应该是： 

第一阶段: 较稳定的功能模块的1级>2级>3级 

第二阶段： 易实现的功能模块的1级>2级>3级 

第三阶段： 线上出现过问题的案例 

第四阶段： 其他 

其中第四阶段的实现要这个视情况而定，要保证维护自动化的耗费的人力<自动化替代的人力的前提下去实施