一 前提:
对系统结构、数据流完整的了解;
对业务需求的了解;
对该需求的设计实现了解。
二 目标:
1.找出测试功能点
2.发现业务漏洞
3.发布步骤
三 注意事项:
1. 业务是否如实在代码中实现(不管对错)
a. 是否符合设计,代码改多了?改少了?有捎带手更改其他功能的?
b. 逻辑是否都是完整闭合的(即,能按照完整流程图实施,考虑所有异常分支,要多想else是否缺了)
c. 需要考虑下是否需要增加部分业务监控 (通常不方便进行测试的业务场景,除了添加监控也需要想想如何执行测试)
2. 日志、业务监控的添加是否完整
a. 监控通常分为系统监控和业务监控,在diff时需要与参与diff的开发充分讨论哪些事件发生是需要技术/运营 实时知道或每隔一段时间都需要了解状态的
a.1 系统监控:通常虚机提供时,op就已经将常用系统监控加上了----cpu、load、内存、流量等
a.2 业务监控:通常在关键业务节点上添加,比如常见的接口调用次数、响应时长、任务成功/失败监控 等
b. 日志分为不同级别:(这是上线前和上线后都必须看的)
b.1 业务日志:可以在考虑为了验证系统的功能模块是否正常而添加只在debug和测试环境在输出的日志;线上日志需要考虑写入数据量、保留/清理时间、磁盘io问题
b.2 异常日志:需要在diff过程中明确catch住可能存在异常的部分;如果是正常业务的异常分支,那么就需要有明确的业务输出或记录,而不是抛出exception
3. 代码层面
. sql改了,有哪些功能受影响?修改sql需要克隆线上非敏感数据进行验证。
. 某个类中的方法改了,需要确认该类的方法在 当前工程中被调用的地方,一层一层直到找到对应可进行验证的UI或系统功能。
. 如果是Provider服务改了,无论是否接口发生变更,必须要到tc的服务治理平台上找到对应的消费方,并通知相关部门人员找出调用该服务的代码、业务场景,并给出测试结果。
. 某个数据对象改了, 需要找到该数据对象被用在哪些地方,验证其展示、存储、对对外接口的影响;尤其考虑模块下游是否有影响,是否也应该做相应的变更。
. 对某个数据对象进行处理,需要考虑数据对象的来源是哪里,数据包含哪些类型和信息,从中选取各种数据类型进行测试,避免测试遗漏。
. 对于部分更改,也许在功能中无法/不方便实际验证(比如异常处理),至少需要知道逻辑是正确的,以及建议单元测试 或在开发本地通过设置断点更改输入项的方式进行验证。如:链接是否因为数据量过大会释放?
. 提示语、邮件内容、短信内容 等文案的更改,需要根据需求进行比对文字,并通读文字是否畅通 及包含错别字;需要考虑是否更改完整了,有没有可能其他提示语也应当更改但是 需求没提 或开发漏改了
. js/css改了,需要在工程中找到被引用的页面,需要在多浏览器进行验证
. 模板(页面、短信、邮件)改了,需要知道是否需要重新生成旧页面以替换线上页面,需要多浏览器验证
. for,while循环,要检查好退出条件,避免死循环,检查好循环内是否有调用方法,评估调用外部系统的性能。
. 代码的基本规范是否满足.比如:日志规范、db连接、 前端调用的域名,代码对异常、超时相关的处理,是否输出相关日志
. 新写代码是否重复造轮,是否有必要重写
. 关注代码中出现的注释,注释中可能会提到特殊的测试场景、遗留bug等,涉及对应逻辑修改时要有对应的case回归测试
....请大家补充....
4. DB设计是否合理
0. 所有数据库操作都需要加try catch对异常捕捉。
a. 字段、索引的设计(要确认属性设计是否合理,新增的“非空字段”需要确认默认值以及跟写入该表有关的业务回归),如字段长度是否足够实际使用
b. 新旧数据的处理、兼容
c. 大表的查询,是否走了索引,这样加索引是否正确
d. 数据库的表结构能承受多大的数据库?
e. 对于sql的变化,需要比对字段顺序、where 条件等,需要考虑sql执行时间、执行数量
f. 合并一些相同的sql语句,提高执行效率已经减少锁表次数,如:对同一个表的多个字段修改可以合并为一条sql,不要写成多个sql,这样可以减少锁表次数和提高执行效率.但同时可能造成sql处理时间过长。
5. 配置相关测试
a.线上线下环境是否不一样?
6. 对系统结构的测试
a.缓存有效性:将缓存服务器清楚掉的处理,
b.容灾
c.外部系统调用常见处理:超时、异常、retry 次数
d.被调用的外部接口是否可用?该接口wiki地址?
7. 对于无法测试执行的中间数据,如何添加测试方法
8.数据和代码匹配
a.代码使用的数据有两种典型来源,接口和DB,仅仅从代码层面去code diff往往看不到问题,需要把实际数据拿出来看,都有哪些组合类型
b.从数据不同去做等价划分,结合代码的分支,可以给我们更加全面的产出
四 diff要产出的东西:
a. 测试范围/checklist
b. 违反规范的bug
c. 系统改进建议
d. 明确测试方法/测试手段
e. 确认发布步骤是否正确
注: diff过程中可以边diff 边进行测试执行,diff完成时,项目测试也执行完成相当一部分了。