同样是登录对于IM的聊天业务影响，有些人认为这个影响非常大，需要对聊天业务的所有用例进行回归测试；有些人则觉得这个影响不是很大，只要测试聊天功能的BVT、高两个级别的用例就可以了。到底是改如何选取呢？是考验我们应用测试用例分级的是否成功的一个重要的标准。
经过不断实践，总结出一套行之有效的回归测试方案，具体是用例分级为基础，以功能影响分析为选择测试用例的主要依据；结合历史测试情况和线上问题反馈调整用例范围；通过用例评审和功能覆盖表为补充测试用例；辅助以测试过程动态监控进行实时调整测试范围。
1.测试用例分级
测试用例分级在《全面的质量保障体系之测试用例分级》有全面的介绍，有兴趣的同学可以点击阅读。
2.功能影响分析
在测试范围评估的过程中，最重要是进行功能影响分析，功能影响分析的结果直接影响测试质量的好坏。在工作中不断梳理功能影响并建立功能影响分析表。如下图所示，表头分成两部分，列表示基本功能点，横表示列中所示功能变更后会影响到的功能；其中用四种颜色标识出列功能对横功能的影响重要程度，其中影响程度分为四级，为非常高、高、中、低。
通过上述功能影响分析，可以建立简单的功能影响分析矩阵，如下图所示，其中功能重要程度分为四个等级非常高、高、中、低，横坐标标识上图中的列功能重要程度，纵坐标标识影响功能的影响程度（如上图中的对钩对应的颜色）。通过功能影响矩阵对应的值可以直观的看到功能与功能影响密切度。如图中所示：
登录功能变更影响最大的是个人资料，联系人、查看心情短语；
登录时IM核心功能，对于的值4，个人资料对于的值是4；查看心情短语是扩展功能，对应的值是1
这样在功能影响分析表中，对于的值分别是16,16,和4
下图中描述了功能失效影响，其中竖坐标表示变更功能的重要程度，横坐标表示上图分析的结果，即功能与功能影响密切程度。通过功能失效影响矩阵对于的值就可以选择对于的测试用例的范围。
继续以登录为例：登录是竖坐标表示的功能，登录的重要程度是4；登录对个人资料功能的影响值是最高（上图计算结果是16），换算到本图中是4。通过分析登录功能的变更后，对个人资料的影响值为红色区域（12或者16），这样就可以根据策略选择出个人资料回归的测试用例需要选择用例级别为BVT、高、中、低四个级别的所有用例。
如果某个功能在失效影响分析表中的值是黄色区域选择用例就可以是非常高、高、中三个级别。以此类推。
3.历史测试情况和线上问题反馈
在早期实践时，只使用功能影响分析表选择用例，但使用后总会出现一些莫名其妙的问题，比如
为什么有些模块重点测试了还是出现5级量化？
为什么有些bug线上重复出现？
Bug扎堆（连续几个版本bug该模块bug都比较多）？
通过不断总结发现，这些问题很多时候是因为没有对测试历史情况和线上反馈跟踪分析导致。通过对历史测试情况分析和线上反馈持续跟踪优化实践如下：
历史情况分析
模块缺陷率：模块缺陷率较高的模块（大于平均值）测试时重点关注，并适当提高测试覆盖率（原则缺陷率前三的模块用例覆盖增加一个级别）。
缺陷稳定率：统计近6次模块版本测试缺陷稳定度，稳定度较差的模块组讨论是否增加用例覆盖。
版本模块趋势图：跟踪模块bug趋势是否正常预测区间，超出区间值，重点关注并适时调整用例覆盖（结合bug日执行监控）。
线上持续反馈跟踪优化
五级故障总共5件，A业务3件，B业务1件，C业务1件；主要问题是对业务逻辑了解不清楚。
策略：所有涉及A业务模块的测试全量回归，B、C业务的重点关注。
D业务bug比较多，但投诉较低，有资源的情况下加强测试，A业务业务bug少，但造成五级量化，重点测试并监控。
策略：对于线上产生的bug模块，在以后回归时，全部纳入测试范围。
4.用例评审和功能覆盖表确认
用例评审每个公司都在做，这个不在阐述。简单说下功能影响覆盖表签字确认。功能影响覆盖表记录本次回归测试所涉及功能列表，及需要回归的测试的范围，一般不超过一页纸。每次在测试前进行确认签字，其目的不是签字，而是确保范围覆盖到位。
5.测试过程动态监控
在测试过程中动态监控缺陷确实，和发现缺陷的验证程度，然后动态调整测试范围。具体实践如下。
bug级别：五级bug上报项目组，四级bug上班测试组，分别有项目组和测试组讨论bug影响，动态调整测试用例范围。
模块bug趋势：参考历史版本情况，由测试组决定是否调整测试用例范围。
回归测试策略选择是一个非常难的事情，本文提供一些简单的实践经验供大家参考借鉴。如有不同建议或者想法欢迎多多交流与留言。
