CodeDiff手册
CodeDiff手册
AwesomeQA 发表于4个月前
CodeDiff手册
  • 发表于 4个月前
  • 阅读 17
  • 收藏 0
  • 点赞 0
  • 评论 0

腾讯云 新注册用户 域名抢购1元起>>>   

一 前提:

    对系统结构、数据流完整的了解;

    对业务需求的了解;

    对该需求的设计实现了解。

二 目标:

    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完成时,项目测试也执行完成相当一部分了。

共有 人打赏支持
粉丝 5
博文 67
码字总数 52972
×
AwesomeQA
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: