CodeDiff手册

2019独角兽企业重金招聘Python工程师标准>>>

一 前提：

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

    对业务需求的了解；

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

二 目标：

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

转载于:https://my.oschina.net/ocean870227/blog/1522803