QA 代码DIFF注意事项

提

对系统结构、数据流完整的了解；对业务需求的了解；对该需求的设计实现了解。

目标

1.找出测试功能点，评估影响范围

2.发现业务漏洞

3.发布步骤

4.补充checklist

5.给出改进方案

6.确认发布时间点，是否需要在低谷时间段进行发布，是否需要关闭某些开关

7.测试手段方法

8.评估需求合理性

时间点

测试阶段，可自行控制

diff工具

分支与master分支diff

1.IDEA ：切到需求分支，在工程右键 Git ->Compare With Branch -> 找到origin/master 即可diff

2.Git网页： https://git.benmu-health.org/ 点击分支 -> 点击compare标签，可看到会默认选中master与该分支对比，点击compare按钮即可

3.使用 tortoiseGit：进入本地工程目录，右键选择tortoiseGit->revision grap 选择要比较的分支和master，再右键选择compare可查看不同

4.其他文件diff工具，eg. BeyondCompare

关注点

业务层面

• 1.代码实现与需求文档的描述是否一致，是否只改动了需求里描述的逻辑，有没有改其他业务逻辑

• 2.业务逻辑是否是完整闭合的，通过代码分析业务（即：所有异常的处理，或者是否缺少else条件）

系统管理层面

• 1.监控： 监控通常分为系统监控和业务监控，在diff时需要与参与diff的开发充分讨论哪些事件发生是需要技术/运营 实时知道或每隔一段时间都需要了解状态的

• 1.1 系统监控：通常虚机提供时，ops就已经将常用系统监控加上了----cpu、load、内存、流量等

• 1.2 业务监控：通常在关键业务节点上添加，比如常见的接口调用次数、响应时长、任务成功/失败监控 等

• 2.日志

• 1.1 业务日志：可以在考虑为了验证系统的功能模块是否正常而添加只在debug和测试环境在输出的日志；线上日志需要考虑写入数据量、保留/清理时间、磁盘io问题

• 1.2 异常日志：需要在diff过程中明确catch住可能存在异常的部分；如果是正常业务的异常分支，那么就需要有明确的业务输出或记录，而不是抛出exception

代码层面

• 代码是否格式化

• 有没有改动非本次需求代码，比如：把别人代码merge丢了，有没有搭车改其他功能

• sql改了，有哪些功能受影响？修改sql需要克隆线上非敏感数据进行验证。

• 某个类中的方法改了，需要确认该类的方法在 当前工程中被调用的地方，一层一层直到找到对应可进行验证的UI或系统功能。

• 如果是Provider服务改了，无论是否接口发生变更，必须找到对应的消费方，并通知相关部门人员找出调用该服务的代码、业务场景，并给出测试结果。尤其是若接口的参数或返回值发生了改变

• 某个数据对象改了， 需要找到该数据对象被用在哪些地方，验证其展示、存储、对对外接口的影响；尤其考虑模块下游是否有影响，是否也应该做相应的变更。

• 对某个数据对象进行处理，需要考虑数据对象的来源是哪里，数据包含哪些类型和信息，从中选取各种数据类型进行测试,避免测试遗漏。

• 对于部分更改，也许在功能中无法/不方便实际验证（比如异常处理），至少需要知道逻辑是正确的，以及建议单元测试 或在开发本地通过设置断点更改输入项的方式进行验证。如：线程是否回收了？链接是否因为数据量过大会释放？

• 提示语、邮件内容、短信内容 等文案的更改，需要根据需求进行比对文字，并通读文字是否畅通 及包含错别字；需要考虑是否更改完整了，有没有可能其他提示语也应当更改但是 需求没提 或开发漏改了，一定确认是否需要进行模板的修改

• js/css改了，需要在工程中找到被引用的页面，需要在多浏览器进行验证

• for，while循环，要检查好退出条件，避免死循环，检查好循环内是否有调用方法，评估调用外部系统的性能。 代码的基本规范是否满足.比如：日志规范、db连接、 前端调用的域名,代码对异常、超时相关的处理，是否输出相关日志

• 新写代码是否重复实现，是否有必要重写 比如：common包里已有工具类等

• 关注代码中出现的注释，注释中可能会提到特殊的测试场景、遗留bug等，涉及对应逻辑修改时要有对应的case回归测试

• 是否存在资源文件，访问资源文件的线上地址，是否影响流量

• 使用的变量是否对为空的情况做了判断处理，线上比较常见出现问题的异常就是空指针异常

• 若diff代码的过程中发现有枚举，一定要关注是否会反序列化失败

兼容问题

• 1.发布是否兼容

• 2.新旧数据是否兼容

• 3.浏览器兼容

• 4.各个手机机型、系统兼容

DB层面

• a. 字段、索引的设计（要确认属性设计是否合理，新增的“非空字段”需要确认默认值以及跟写入该表有关的业务回归），如字段长度是否足够实际使用

• b. 新旧数据的处理、兼容

• c. 大表的查询，是否走了索引，这样加索引是否正确

• d. 数据库的表结构能承受多大的数据库？

• e. 对于sql的变化，需要比对字段顺序、where 条件等，需要考虑sql执行时间、执行数量

• f. 合并一些相同的sql语句，提高执行效率已经减少锁表次数，如：对同一个表的多个字段修改可以合并为一条sql，不要写成多个sql，这样可以减少锁表次数和提高执行效率.但同时可能造成sql处理时间过长。

配置文件

• 包括config配置、duboo、schedule、ng等beta与线上的配置

• 配置文件是否生效，例如配置开关等

• 线上与beta配置是否分离

• 所有配置需要写入发布步骤里

系统结构层面

• 性能

• 并发问题

• 缓存

• 容灾

• 调用外部接口异常的处理：超时、异常、重试次数

• 前端

• 公共底层代码改动的影响范围（如：common、utils、config 等文件夹的修改）

• 接口改动的兼容性问题

• 引用资源是否已经发布

• 业务逻辑必须明确阐述，并说明影响