前言
前面在如何负责一个项目的质量保证工作一文中，笔者将质量保障划分为三个阶段，研发质量，上线质量和线上质量。其中针对上线流程，特别提到灰度阶段，QA应该提供相应的验收机制。今天来具体说说
，针对分布式程序如何打造一个方便好用的灰度验收工具。
我们知道，绝大多数分布式程序天然的支持灰度迭代，通过有序的, 分批次的迭代上线，能够有效的控制故障规模，起到发布中验收的效果。但即使这样，如果基础设施不够完善，还是没办法做到无损灰度的。出了问题，实际仍然是有用户感知，只不过范围较小而已。
线上发布，多数是SRE运维同学操作，他们很有可能不清楚业务细节，比较欠缺验收手段。多数情况下，发布部署的同学主要依靠查看日志和监控告警手段来验收发布。但其实这样非常的被动, 如果是监控告警触发报障，情况可能还好，运维同学会很快感知，快速止损。但如果是客户报障，一来一去时间上就会很长，如果稍微影响的客户多些，就是一例事故。
举个极端例子，比如一个面向用户的接口，因为bug导致用户正常请求在特定场合会返回4xx。如果带着这种bug去灰度，很有可能监控告警层面不会感知，因为4xx在HTTP协议中属于客户端问题，运维同学一般会排除此类code的告警。而客户遇到此类问题，也有可能会首先怀疑自己的行为是否正确，所以到爆发时，影响面可能就比较大。
然而针对这种用户场景的测试，QA是有验收手段的。
在实际业务迭代中，QA一般都会产出自动化测试，所以就可以通过这些自动化用例，单独对灰度的实例进行验收，确保发布符合预期。
然而理想很丰满，现实却骨感。实际上多数自动化测试用例并不是那么方便的，去交付别人去使用。它有其复杂性，比如：
- 服务端的产品，测试框架多数是基于配置文件来适配不同的测试环境，不同的测试账号。日记月累下，测试配置有可能会比较复杂。而让不懂这块的人去改这些配置，心智成本较高。
- 测试框架为满足多样性的需求，会越做越复杂，比如golang领域的ginkgo，功能很丰富，支持并发的跑用例，focus or skip的组合，递归遍历等，对不熟悉的使用者来讲会造成困扰。
- QA的测试用例可能包含多种层次类型，比如集成，e2e，或者破坏性的。而破坏性的用例，必须确保不能在线上执行，这点很重要。
- 测试数据如何方便的快捷准备，也是需要考量的.
除了测试用例本身的复杂性之外，还需要考虑用例的更新机制，以及分发机制。
所以若想将测试用例交付部署人员来使用，必须解决其易用性,安全性问题,降低使用者的心智负担。
Interface for Tests Execution
一个可行的方案就是构建一个interface程序，专门用于运行测试用例，将所有的复杂性问题都封装起来，做到对使用者友好：
- 比如可以内置所有配置到二进制程序中，并能让使用者方便的选择使用范围
- 还要能提供简单方式，其使用者指定灰度服务的IP地址，做到针对性测试
- 一键准备测试数据，最好让使用者无感知
- 固定使用姿势，不给使用者犯错的机会
- 工具要有清晰的help文档，随用随学
至于分发问题，就可以将程序托管在公有云存储上，通过shell脚本，一键下载。这种方案会极大的降低使用者的心智负担，对测试服务的推广非常有益。
kubernetes test infra中的Kubetest也是这种思想的的典型代表。
Test as a Service
业界，大家一直在探寻QA的转型之路，不管是左移还是右移，或者是工程效率层面，测试服务的输出都是其中非常有价值的topic。笔者认为，QA不光要拥有业务质量的全局视角，还要能发现业务痛点，然后围绕质量方向，打造高价值产品或平台，以此来输出质量保障服务。测试不在于人，而在于服务。测试服务不是测试同学的玩物，应该是围绕解决如何保证业务质量的难题。同时，单个人，或者单个组织来做质量保证必有其局限性，质量全员建设才是王道。
提供这种灰度验收的工具，其实也是对QA的测试用例提出了更高要求，只有持续保障其稳定，高效，才能不断产生价值。
Contact me ?
Email: [email protected]
Blog: http://www.cnblogs.com/jinsdu/
Github: https://github.com/CarlJi