提
对系统结构、数据流完整的了解;对业务需求的了解;对该需求的设计实现了解。
目标
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 等文件夹的修改)
-
接口改动的兼容性问题
-
引用资源是否已经发布
-
业务逻辑必须明确阐述,并说明影响