Dev的质量保障

Posted 2022-02-03 orangleliu

当前的团队中有产品和开发，只有产品验收环节，并没有专门的QA来做测试保障。开发同学自测的质量就非常重要了，公司中有些自动化的测试工具，因为工具更多的是面向业务产品，所以能利用的也是有限，更多是需要开发同学自己想办法提高测试效率。

背景是后端开发同学，服务Http居多

需求阶段

• 一定要跟产品同学对明白需求，可能需要来回往复几次沟通
  • RDQA
  • 开发中 （对开发细节有疑问，及时找产品沟通，有时候可能就是逻辑遗漏或者细节处不合理）
  • 开发完成（简单的对下验收测case）
• 可以自己简单整理核心的流程，关键case最好能记录下来

开发阶段

• 尽量走方案评审，让有了解系统和有设计经验的同学把把关
• 善于使用公司内部的CI工具，sonar检查，code review等，如果公司内有自动化回归工具，积极接入，减少回归成本
• 尽量本地开发，加快自测的反馈
• 本地开发的手段
  • 流量劫持 http（通过whistle 或者 charles等代理工具把流量劫持到本地来测试服务）
  • 功能触发（页面上的功能可以手工触发，然后通过浏览器copy(chrome的web控制台有copy选项)请求在Postman重放）
• 如果功能比较复杂可以通过 脑图来管理case，xmind，mindnode，幕布等都可以
• 对于非暴露出的接口，可以用UnitTest工具来完成程序内部入口的测试
  • 纯函数测试
  • 有依赖测试，可以用mock工具，也可以用真实的db或者外部依赖
• 如果是涉及多个服务同时开发，预先定义接口，使用外部mock工具也比较有用
• 跟交互上下游系统的开发同学确认接口定义，一定要到每个字段类型，边界情况，否则联调时候都是坑

联调阶段

• 排期对齐 （最好是开发和联调正好是在连续的时间交叉点，等待太久可能需求都淡忘了，测试效率很低）
• 一方问题太多的情况下，减少其他人在复现和回归上的陪伴，流量录制回放可能是一种方案

上线阶段

• 上线和回滚步骤梳理，记录文档
• 复杂需求上线前周知，相关的人知道有变更更容易处理故障
• 上线后回归功能，观察一段时间，有线上回归自动化测试更好