什么是测试金字塔

开发者测试是现代软件工程中非常重要的一环，敏捷开发、主干开发这些先进的项目管理方法和流程都基于完善的开发者测试。当每个月甚至每周都要交付一个版本时，不可能投入大量的测试工程师来进行大规模的系统级别测试，这时候就需要把整个测试金字塔中的绝大部分测试通过自动化来完成。


unit Test： 单元测试(最容易被忽略，也是最重要的，核心业务逻辑一定要写完善的单测用例，非核心业务看你心情吧)
API Test：比如测试商品查询接口（yapi 点一点，或者写个http代码工具，或者写个grpc的client脚本）
集成测试：下单接口除了需要数据写入以外还需要查询商品，查询用户等大量接口(这是集成， 一般也可以写一些脚本)
UI测试： 简单暴力的人工点击查看(有条件的写selenium脚本去检测页面元素和值, 一般只针对稳定的业务)

在糙快猛的开发模式下，我们一般都只做：

  1. API级别的测试（通过yapi进行接口测试） 
  1. 页面上点几下(UI Test)

实际上很多隐含的问题需要在 unit Test下进行， 也就是单元测试，单元测试能发现90%的问题，这些问题有一部分在api级别很难发现。

上线前的准备工作(CI)

每次上线，是不是心惊胆战：

1. 我的新功能不会有bug吧
2. 我改的代码不会影响原来的正常业务吧(这个是最怕的)

谁来帮你保证原来的业务逻辑没有问题： 当然是你以前写过的测试用例，不管是单元测试还是集成测试，所以上线前你要经历测试用例跑一遍，但是跑用例也分两种情况：
跑部分用例还是所有用例都跑一遍。所有用例都跑一遍是 “回归测试”，但是跑一遍费时费力，所以具体情况要具体分析，开发人员得自己评估

代码上线需要经过一系列的CI工作
代码分析:
golangci-lint
go format 代码格式化
data race检查
代码测试
单测代码跑一下
集成测试跑一下
回归测试跑一下
自动生成一份测试报告
比如测试用例没有通过，代码覆盖率不足等都可以打回不跑接下里的逻辑
打镜像：
通过docker file生成镜像

开发者测试“利在当下”，“赢得未来”

很多人都认为底层的开发者测试，花了大量的时间，写了大量的代码，然后来保证功能的正确性，但是每次代码功能或者结构的的变更都要修改测试代码。而我手动调试和验证效率更高，甚至一些开发者测试更多的是为了指标。实际上通过UT，API测试来调试代码与自己手动运行调试区别不大，但是通过开发者测试对代码进行调试，从而保证当前项目迭代的质量；但是其更重要的作用不是这个。通常在我们bug分类中有这样一些名词 : Build Regression Bug， Release Regression Bug。

• Build Regression Bug ： 开发中同样的功能在新版本出现一个bug，但是在之前的版本没有这个问题，我们叫做Build Regression Bug.
• Release Regression Bug : 产线上同样的功能在新版本出现一个bug，但是在之前的版本没有这个问题，我们叫做Release Regression Bug.

我们聚焦在如何写好单元测试