1. 测试是海上的航标
项目越复杂、规模越大，越能体现测试的价值和重要性。测试保证了方向的正确性。就像航行时，海上出现的航标，可以用来检验、纠正路线。便于掌舵人，随时了解动态，做出调整。测试决定了迭代的速度。随着 Scrum 等敏捷开发方法的实践，交付的节奏在加快。测试是交付质量的保障，如果测试跟不上，敏捷将无法落地。测试很重要，但却是一本经济账。太少，不足以保障质量；太多，维护成本又很高。卡住关键点位，才能获得高的性价比。再来看看需要测试的产品。KubeSphere 很小，却又很大。说它很小，是因为只是 Kubernetes 上的应用负载，并不对原生的 Kubernetes 进行改造。说它很大，是因为集成了很多可选的组件，提供了整套的解决方案。在日常的开发过程中，有两个地方汇聚了高密度的价值: 主仓库和安装程序。主仓库，汇聚了开发者的每次变更；安装程序，汇聚了各个组件在用户安装时的行为。比较之下，我认为安装更加需要额外的自动化测试，而且也更好测试。安装是用户体验的第一印象，更加贴近用户端。下面来看看，我在测试安装程序上做的工作吧。
2. 使用 KubeSphere 测试 KubeSphere
这是一个有趣的做法，使用 KubeSphere 创建新的 KubeSphere ，并实现自测。听起来有点像自举，自己创建自己，自己测试自己。这样就有了安装程序的第一版自动化测试。每天对单节点、多节点、高可用三种安装方式进行自动化测试。安装之后，也会做一些 API 和 UI 层的测试，可以参考文档 《基于 Kubernetes 和 Jenkins 搭建自动化测试系统》 ，还有一些拨测用来实时验证线上服务是否正常，《使用 Jenkins 进行服务拨测》 。下面说一下测试流程:
创建一条创建集群的流水线
运行 API 自动化测试
运行 UI 自动化测试，在新机器上创建一条创建集群的流水线。
每次合并 PR 执行一次
一个防火墙
一个防火墙规则
一个云主机
一个安装资源
初始化 IaaS 秘钥
Terraform 创建资源
安装 KubeSphere 并检测是否符合预期
Terraform 销毁资源
Slack 发送通知
进入新建的 Slack App ，点击 【Incoming Webhooks】添加 Webhook 之后，就可以获取到 Webhook URL 。
4. 总结
目前测试 Case 相对单一，后续需要继续扩充。考虑不同维度选项的组合，通过 matrix 批量组合执行。其实，Terraform 和 GitHub Actions 的方式也不是最优的。GitHub Actions 支持运行 Kind (使用一个 Docker 容器运行 Kubernetes)。如果能对接上 Kind ，完全使用 GitHub Actions 进行自动化测试会更好。另外就是可以引入 Chaos 类型的工具，在系统健壮性、高可用方面进行测试。
