共计 2366 个字符，预计需要花费 6 分钟才能阅读完成。
背景
随着 Agile 和 DevOps 的继续推动，开发人员取得了软件服务交付更多的势力，交付速度越来越快。
在这种继续变更的事实中，随着交付速度的晋升和云原生架构的广泛应用，更多的微服务意味着更多的危险。
因为继续且频繁的变更自身就有危险，只不过单次的危险比以前降落了，但因为服务依赖的复杂性带来更辣手的牵一动员全身的级联危险。
有句技术黑话：
新技术的利用，往往是把一个空间的问题转移到了另一个空间。前一个空间已有的问题看似不存在了，不过是以一种新的模式呈现在后一个空间，有待解决。
云原生利用测试的窘境
单体利用的测试思路
过来，开发人员着重在单体利用上，这意味着变更的范畴和速率更易于治理。这始终属于继续集成 / 继续交付 (CI/CD) 的范畴，即测试是在实现开发之后以及开始部署之前要做的事件。
下图形容的是常见的测试金字塔，阐明了咱们应该编写哪种测试以及在什么水平上进行测试。能够看到，在测试场景中，向上挪动的越多，付出的致力，工夫和老本就越多。
如果开发人员很分明软件的预期状态，他们只有通过单元测试和集成测试验证更改的中央即可。
微服务利用的测试难度
然而，在将单体利用合成为较小的微服务之后，这种传统的测试定义不再成立。
我常常听到有许多公司试图在开发人员的本地环境上复制整个利用拓扑。以前咱们用的是 vagrant up，当初可能是 docker compose。
开发人员应该可能在本地运行整个环境。
人们开始以繁多的思维形式来构建微服务，逾越泛滥服务的大规模集成测试是一种反模式。
转向微服务还意味着应用正确的工具和技术。
如果我的利用由 100 个微服务组成，CI/CD 根本无法同时构建和测试（真有公司这么做，其复杂程度令人惊悚）。
新性能公布时，因为微服务的颗粒度很小，只有个别微服务通过 CI/CD 从新公布，而且其余大多数微服务将会在生产上持续运行。
在这种状况下，以前单体利用开发人员对软件状态的现实预设，在这里就成幻象。
微服务之间的级联依赖和继续的增量变更，很可能导致整体利用的状态难于预测。
这就好比，时速 120 公里的轿车和时速 300 公里以上的 F1 赛车，两者的安全措施齐全不是一回事。
因而，咱们须要新的测试模式。
故障产生是新常态
依据谷歌云 2019 年的 DevOps 现状报告，变更故障次数最高能占到所有新代码公布次数的 60%，因为是工程师问卷反馈的统计，理论的失败率很可能更高。
- https://services.google.com/f…
云原生时代，咱们心中松耦合的微服务架构可能长这个样子：
但在理论的生产中，上面这张图更靠近于现状：
- 负载均衡器 ELB 不晓得所有的网关实例，或者因为防火墙规定而无奈在网络中找到它们。
- 好几个服务实例已死，然而服务发现并没有留神到这个状况。
- 服务发现的节点之间无奈同步，产生了网络分区，数据一致性被毁坏。
- 因为只有一个网关实例，因而无奈调配负载，导致该节点上的负载继续减少。
当咱们解决多达几十个实例的小型零碎时，100%的衰弱运行通常是失常状态，故障则是一种非凡状况。然而，在解决大规模分布式系统时，即 100%的衰弱运行简直是不可能实现的。
此时，咱们必须承受故障产生是新常态的事实。
大家深有体会，咱们不能再等了！
须要一条新的前途
可观测性令测试右移
分布式追踪联合传统的指标和日志监控，随着可观测性技术的呈现，将代码推入生产并察看服务接口的错误率，成为一种合乎事实的策略。
如果其余微服务呈现问题，接口错误率就会很快显现出来，此时能够抉择修复或回滚。这基本上就是在让可观测性零碎承当回归测试的性能和原先 CI/CD 所表演的角色。
不过，开发人员视生产神圣不可进犯，对雷同的制品仅在类生产中进行验证。这是他们从职业生涯开始就已扎根于心的货色，而对实时流量进行监控和追踪，这是运维工程师要做的事。
因而，咱们须要思维形式的转变，迎接“测试右移”，接收可观测性技术，向在生产中测试挺进！
探索性测试焕发新生
探索性测试（Exploratory Testing）是由 Cem Caner 首次提出，80 年代就始终存在的测试方法，2011 年 James Whittaker 出版《摸索式软件测试》后，在业内引起宽泛关注。
探索性测试能够说是一种测试思维技术，次要由经验丰富的测试人员施行。该办法可能基于已有的常识、启发式的理念和危险畛域在无限的工夫内挖掘出更有附加值的问题。
Netflix 提出了混沌工程
Netflix 在十年之前，承受了故障产生是新常态的事实，在摸索云原生的过程中，奇妙地将探索性测试方法和可观测性技术联合在一起，以生产试验的模式，随机注入故障，通过可观测性技术，探查零碎行为变动，冲破人对系统的认知盲点。
只有人对其研发的零碎有更加深刻的意识，能力真正进步零碎自身的韧性。
结束语
本文从云原生利用测试的窘境登程，借以单体利用的测试思路，掂量微服务利用测试的误区和难度，表明了咱们须要扭转对测试固有思维模式的信心。关上视线，承受故障产生是新常态的事实，迎接云原生利用测试新的前途。
有意思的事，近年来可观测性技术突飞猛进，给云原生利用在生产中进行测试提供了极佳的事实撑持。开发人员要扭转固有的思维模式，不能满足于仅在类生产中测试的现状，要推动测试右移，利用可观测性技术，在生产中进行探索性试验。
Netflix 是最早吃螃蟹的，第一个提出了混沌工程的理念和办法，将探索性测试方法和可观测性技术联合在一起，助力开发人员在生产中进行试验，最终的目标还是为了加深开发人员对于零碎行为的意识，促成零碎架构的韧性。
起源：混沌工程实际
作者：龙坞道长
5 月每周四晚 8 点，【冬哥有话说】品质与测试专场。公众号留言“品质”可获取地址
- 0506 朱少民《如何最大化软件测试效力》
- 0513 陈琦《数据驱动测试》
- 0520 陈霁《没错，去 QA 是提高质量最无效的办法！》
- 0527 施慧斌《DevOps 实际之继续测试》
