QA diff代码

最新推荐文章于 2024-04-27 23:23:24 发布

大熊AI

最新推荐文章于 2024-04-27 23:23:24 发布

阅读量115

点赞数

分类专栏： Test # 单元测试文章标签： git github java

原文链接：https://blog.csdn.net/js779727785/article/details/99860309

版权

Test 同时被 2 个专栏收录

46 篇文章 5 订阅 ¥99.90 ¥99.00

订阅专栏

超级会员免费看

单元测试

1 篇文章 0 订阅

订阅专栏

前提

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

目标

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处理时间过长。