在大家的常识中，回归测试在范围的选择上，有如下四种方法：

　　1、测试全部用例——选择基线测试用例库中的全部测试用例，这是一种比较安全的方法，再测试全部用例具有低的遗漏回归错误的风险，但测试成本高；

　　2、基于风险选择测试——可以基于一定的风险标准来从基线测试用例库中选择回归测试；

　　3、基于操作剖面选择测试——如果基线测试用例库的测试用例是基于软件操作剖面开发的，回归测试可以优先选择那些针对重要或频繁使用功能的测试用例，释放和缓解高级别的风险，有助于尽早发现那些对可靠性有大影响的故障；

　　4、再测试修改的部分——当测试者对修改的局部化有足够的信心时，可以通过相依性分析识别软件的修改情况并分析修改的影响，将回归测试局限于被改变的模块和它的接口上。

　　我前一段时间在微博里发了一个号称“回归测试用例自动生成器”的设计图（如下），核心思路是通过配置管理工具对版本差异的扫描来获取改动的文件，通过用代码扫描工具对改动文件的扫描得到改动的内容，再通过这些改动的内容扫描出关键字：

　　SP：cursor、function、procedure……

　　JAVA：method、interface、class、DAO、DTO……

　　后通过这些关键字和系统功能点、回归测试用例库中的测试用例，这三者的映射关系来精确的找到每次移交之后所要进行的关联测试。其实后来经过大家的讨论，发现这种构思叫“回归测试范围界定选择器”更加合适，用“生成”二字有点歧义。我自己也没有想清楚到底如何实现，需要关注哪些问题，但是我做这种设想的理由很简单：

　　1、我厌倦了每次版本后一次移交之后都需要的全面回归测试，这是一种无耻的浪费；

　　2、我厌倦了这种“瞎蒙”式的回归测试，不精确，而且所谓的全面回归也无法避免测试遗漏；

　　3、我不相信在没有足够的时间的情况下，所谓的回归测试剪裁，所谓基于风险的评估是无法保证规避一些重要的测试遗漏的；

　　4、我不相信coder兄弟们告诉我的，他们基于本次版本所有需求所修改的内容，因为他们其中个别人往往会稍带着做一些自认为“无伤大雅的优化”；

　　5、我憎恨任何一个把前期测试没有尽力却在出了测试遗漏的时候把责任推给回归测试的人，开发人员也好、测试人员也罢；

　　当然，这些只是我个人主观上的认知倾向，貌似我应该用更有说服力的数据来说明我这么思考和想做这件事情的理由，那么不妨让我算一笔账给大家看看：

　　1、前提：自动化开发和维护的成本撇开不算，因为有没有这个构思，自动化测试开发和维护都必须要做；

　　2、按照目前Selenium/WebDriver的自动化回归测试脚本的粒度算，假设一个系统平均Web页面回归测试用例1000个，其中80%是自动化的，20%是手动的；