在测试的后期，代码和功能已基本稳定的时候，给测试带来一个很大的问题是，每次重新构建修改的问题都不大，影响的范围也很小，有时候后期改了大量代码，但基本也是编码、界面规范的问题。但是测试往往还是要做全版本回归，很大程度上影响了测试的时间长度。或者有时测试只对开发人员的告知的功能点进行测试，在一定程度上是有风险的。这时候除了参看开发人员的测试范围建议外，测试人员最好自己也对测试范围做好把关，比较有效的方法就是进行代码比较，利用CC查看每次构建的变更集，对变更集内的文件进行代码比较，这样能较好的定位测试范围。因为有时候开发人员在修改bug或看代码的过程中，认为某个地方是测试没有发现的隐藏问题，之后可能自己都忘了修改了哪些地方的代码，这时候如果只对bug影响范围的功能进行测试，会有很大的风险。通过查看变更集可以很好的了解开发过程中修改的详细内容。代码比较同时对后期编码规范的代码变动也有很大好处。如编码规范中变量大小写问题，如果通过代码比较发现代码内容的变动都是这类问题（测试人员绝对不能只依据开发人员的口头描述说这次只是编码规范的修改，而不进行回归测试），就不需要对该部分进行回归测试，极大的节省了测试的时间。
数据库脚本的一些问题也可以通过文件比较来节省部署时间。新一轮部署过程中发现脚本的修改只是对表的某个字段属性进行了修改，这时候其实是可以不重新运行所有数据库脚本的，可以通过手动修改数据库或运行部分脚本（有时候完全重新搭建数据库是很费时间的）。同样测试人员也不能单单依据开发人员的说法，通过文件比较确认开发人员的说法，这样能很好的规避风险。（尽管可以使用此方法缩短测试时间，但是数据库脚本的完整重新执行在发版前还是必须做的，有时候会由于数据库不是最新的而遗漏了一些bug。如某功能判定标志id为1的数据不允许用户修改，这个功能其实是不需要的，但是如果不重新执行数据库脚本是发现不了的，因为由于测试的进行，标志id为1的数据我们是产生不了了，只有建表后加入的第一条数据的标志id才会是1）
当然在使用代码比较来缩小测试范围等时，必须有一定的编程、数据库能力，因为通过代码比较来确定影响范围同样也是有风险的。这时候就需要对各种风险进行权衡考虑了。
