传统意义上的测试是足球场上的守门员，互联网下的测试提倡更多的左移，类似保健医生，云原生下的测试应该怎么努力呢？个人觉得纵向深入专项测试和右移 OPS 可能是一个方向。

什么是云原生？

概述：在动态、开放的生态环境中构建和运行弹性服务。代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。

以下是 CNCF 对云原生的重新定义（中英对照）：

loud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。

These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone.

云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。

云原生带来的机遇与挑战

个人理解该体系的出现促进业务应用更快捷的迭代、运维 (发布、维护、监控)，进一步促成云端 Devops。在互联网唯快不破的势头下，快速上线是很多产品抢占市场和生存的制胜法宝。

所以，当云原生这个体系出现的时候，很多搞云的大厂迅速加入云原生的队伍，推出众多云原生服务组件，网易云也不例外，除了服务网格、CI&CD、分布式事务等，也开始了中间件 Operator 的研发。云原生下面已经衍生出很多标准体系，并且有很多工具提升研发效率。

但除了机遇，也有一定的挑战，如对 kubernets 特性和配置的应用和了解如何？底座是否稳定？研发是否吃得透这些开源组件？开源组件版本如何管理，如何与社区版本进行同步？出现问题是否能快速定位并解决？这都是我们传统测试思维会想到的。下面看一下云原生的思考方式，这对于我们构建自己的测试思维比较有帮助：

云原生下对我们 QA 同学的现实冲击

我们传统互联网领导的 QA 职责包括：

需求分析
设计分析
测试分析
自动化或性能等测试
质量风险管理等

而在云原生背景下，更快的开发节奏，对测试要求会更高。如，传统的 paas 服务新版本上线需要 3 个月的时间，但是云原生的 paas 服务新版本上线时间按照业界标准只需要 1-1.5 个月（paas 研发时间主要节省在资源调度和管理上，这部分功能都由强大的 kubernetes 提供）。3 月或 1.5 个月这个时间都是包含测试时间的，但是测试工具或体系在云原生下并没有出现特别的一站式解决方案。

如何更快的更好的保障质量是我们面临的挑战，挑战来自多方便，如 paas 研发和 QA 对 kubernetes 底座的了解有限，kubernetes 自身版本升级和运维操作较频繁，对内核和 docker 版本有依赖，会出现内核等 bug。底座的问题还是需要上层服务不断实践和测试去发现。

目前，我简单的总结了 QA 在 service mesh 和 paas on k8s 系统里可以参与到前期设计和测试发力的内容有：

1.设计考虑：

高可用设计
故障自愈设计 (包括依赖的 k8s 各组件)
可扩展和弹性设计
可管理资源与实例设计
可监控与遥测设计
运维操作 (频繁或高影响操作)

2.测试考虑

管控与数据面功能自动化
故障自愈自动化 (在 k8s 体系下更为重要)
长稳（动态环境）压测（包括依赖的各组件)
纵向单级和多级的混沌故障测试
全链路性能压测
运维操作自动化测试
api 层面的模糊测试，保障系统 api 健壮性

我们团队 QA 的发展方向

1. 专项测试专家：18 年 Q4 我们进行了团队转型，QA 重点负责专项测试设计和执行。

经过 1 年多的实践，利用这个工具或平台，云计算 2.0 的项目基本经过我们高频的折腾，稳定性基本达标。19 年下半年业务重点逐步转到云原生之后，我们接触了很多开源系统和组件，如 istio、enovy 等，这些系统有的提供了单元测试和 e2e 测试用例，如何利用这些基础的测试，系统化的保障云原生服务的质量是我们要努力的方向。

初步是设想是研发负责功能测试，维护功能 checklist，保障各功能测试百分百覆盖，输出完整用例集（交付使用）；

QA 负责持续集成建设和非功能质量建设。简单举例，如 QA 提供持续集成建设方案和实施，实现代码自动卡点与上述场景自动化、故障自愈自动化，检测测试代码覆盖率；非功能测试方面加大故障测试投入，利用大组平台或开源工具，深入组件和网络异常，将故障测试频率加大。

拉齐非功能测试基线如：

故障自愈 - 关注是否自愈和自愈时长
性能测试基线
组件或 OS 兼容性

目前，轻舟或云的解决方案多样性或交付还不是很多，如果这块的需求增多，则需要有单独的环境进行解决方案集成测试。

2. 效能专项组：理想情况下，需要有持续集成和专项提效组，所有的同学都投身于业务测试中，小的改进也来自问题反馈后集体的头脑风暴。

先说下必要性：为了提升测试执行或测试设计的效率，离不开测试沉淀和好的测试工具。效能组的同学需要调研或自研优秀的测试工具，为专项测试执行同学输出便利。专项测试同学与效能同学需要有密切的合作和沟通，工作上也要相辅相成，有能力的同学，可以适当相互轮岗。

总而言之，质量保障是充满艰辛和挑战的一条路，没有放之四海而皆准的准则。在复杂的系统中，更没有通过一种技术就可以解决所有的质量问题，我们必须不断实践，按照云原生契约精神踏踏实实的探索混沌测试，完善质量体系，才能更好的保障系统的稳定性和健壮性。

参考资料：

云原生定义

云原生设计哲学

创作场景

聊聊云原生时代的测试