同意一楼的回复，
我们这边把回归范围包含两部分，本身修改部分 + 受影响部分。

黑盒测试，确实只能通过需求文档和设计文档评估范围，但这个不太准确，时不时会有遗漏。

目前精准测试还在构建中，调用链路分析没搞定之前，貌似也起不了啥作用。

如果人为去 code diff 代码行，除了对测试人员代码能力要求较高以外，花费的时间估计也不少。
可能折中一下会好一些，还是以黑盒评估为主。在代码提交以后，git diff 获取修改代码的文件，根据文件判断大致涉及功能，然后反馈黑盒，确认是否有测试范围遗漏。 不过这个方法还没实践过，楼主可以参考下

如果是黑盒测试，回归范围是不能确定的。

有的迭代会改

每次迭代都会修改 DB？
这系统设计不咋滴啊～

比较常规的如一楼所说，测试先划定一个，再找研发评估对齐。
引入其他依据的话，可以是基于代码调用链上下游各 N 层来评估测试范围，这个评估步骤可以是人来做，也可以做成自动化。

我们以前一般会根据自己的经验罗列一个影响范围，再找开发要一个影响范围，结合这个拉出一批测试用例。（当然这个范围是要项目组同学共同认可的，后面有其他歧义的时候再做查缺补漏）
如果要再细的话，就做代码版本 diff，但一般来讲没有这个必要，这个阶段进度就比较靠后了。