最近在看《不测的秘密 - 精准测试之路》，里面的这个问题引起我的思考，同时希望可以从大家了解一些不同的想法。
就后端代码而言，我的识别方式是：
1、了解需求&系分 大概明白功能实现的思路。
2、阅读开发代码，提交的代码如果是围绕功能的实现可以认为是和需求有明确关联的。
3、对于其他隐约成系统的改动（围绕某个接口、功能（看起来和本次需求么有直接关联））则需要进一步了解这些改动是否影响本次的需求。
4、其他零碎的改动需要找开发看是否为一些已有功能的修复或搭车。
也是类似的方式，用 MR 看改动的代码改动列表。会先看 commit message ，相比看具体代码会简单快捷一些。
看到这个问题我觉得很奇怪。
还是得从工具的思路来去解决这个问题，人工识别的效率太低了。
首先，需求和代码版本不能搞错。
然后就是了解具体微服务工程承担的职责。
再了解开发的代码结构，通过提交记录查看改动范围（message 备注还得正确，符合规范）
最后就是查看具体改动点，确定影响范围。
每一步走错，最后结果都不准， 而且这个准确性是建立在开发遵守规则的前提下。 最后能通过代码走读，短时间内完成测试范围的评估。
好家伙，压根不是人干的事~~~
可以在提交的 message 中添加 jira id
规范下开发提交的信息，一般 gitlab 都有钩子脚本，修改下脚本就可以强制提交信息格式，这样就可以和 jira id 挂钩了