测试工程师如何帮助开发域的质量变好

1、SonarQube的技术债务

SonarQube扫描出来Gitlab的repo的技术债务需要清零，在迭代过程中，团队需要持续关注技术债，保持技术债稳定下降的趋势，建立修复技术债的技术故事卡（举例如下），在对应的提交中需要将代码提交的commit message中的需求id填写该技术故事卡的ID。

2、单元测试

单元测试的两种实践：

• 普通的开发模式实现开发实现故事卡的逻辑代码，然后再根据写好的代码编写单元测试，对单元模块进行测试。
• 采用测试驱动开发的开发人员，根据用户故事中的AC或测试用例，先进行测试用例的编写，再进行功能模块的开发。

单元测试的一些规则：

• 被测函数的外部函数调用，外部服务调用，都需要解耦（java推荐mockito）。
• 被测试函数访问数据库、消息中间件、redis等中间件的，都需要解耦。
• 测试类在test目录下所在的路径应与被测试的类在src/main/java下的路径保持一致。通过约定的规则，测试类和被测试类相对应，方便查看和定位。
• 测试类的命名和被测试类保持一致，后缀加上Test。
• 测试用例的命名应该采用should_get_when的方式:should_get_number_when_score_given_equal_60()。
• 每一个测试用例必须有断言，用断言验证测试结果。
• 单元测试代码和被测试业务逻辑代码最好再一次commit中提交，如果分开，也建议前后2-3个commit中提交，避免先写完逻辑代码，批量补单元测试的情况。

3、CodeReview

代码评审比较常用的有：

• 基于Gitlab的Merge Request，相关评审人员走查通过后，代码合并到release分支中
• 集体代码走查，在开发人员提交测试前，组织团队成员进行集体评审。目前组织级的实践要求通过Gitlab进行代码评审，各团队可以自行选择是否开展集体代码走查，并制定执行集体代码走查的条件和规则
  两种实践可以混合使用。

3.1 基于Merge Request的评审

• 1. 开发人员在feature开发分支上完成代码提交，并推送到gitlab服务器
• 1. 开发人员在Gitlab上发起Merge Request，目标分支为release分支。选择Assignee（指定Reviewer），选择审核人（approvers）及最小批准人数（Approvals required）。根据描述模板中的内容检查代码状况，然后进行提交。

• 1. 代码审核人员审查提交的Merge Request，评审时为存疑的代码片段添加注释comments，MR的创建者应对相应的注释及时解答。
• 1. 审核通过，可以提交Merge，将代码合并到目标分支。

3.2 集体代码走查

3.2.1 集体代码走查的意义

• 1. 传播知识，避免对特定模块/特定人员的依赖。
• 1. 达成共识，避免重复，改善设计。
• 1. 让新人从讨论中学习到解决问题的思路和技术要点。
• 1. 培养新人的最直接和最有效的途径，对已有代码的讨论，既实例化，又能直接提升质量。

3.2.2 集体代码走查的频次

频率建议一开始每天做一次代码走查。如果大家时间很难协调， 也要保证每周两到三次。时长根据团队大小决定，如果小团队(2~3人)，时间控制在半小时以内。如果团队人员较多，1小时为宜。根据发现问题的情况，及时调整评审的范围和时长。频率和时⻓可以根据团队情况不断调整，最终找到最合适你团队的实践。

3.2.3 评审议程

• 1. 检查上次代码走查所记录的改进点是否已经修复，更新记录表
• 1. 代码作者简要介绍所走查的代码的业务上下文和开卡验卡验收条件
• 1. 展示代码规范标准工具扫描结果
• 1. 作者展示所修改的代码，参与者提问，作者答疑
• 1. 作者记录改进点