—微服务架构自动化测试全链路设计背景从 SOA 架构到现在大行其道的微服务架构，系统越拆越小，整体架构的复杂度也是直线上升，我们一直老生常谈的微服务架构下的技术难点及解决方案也日渐成熟（包括典型的数据一致性,系统调用带来的一致性问题,还是跨节点跨机房复制带来的一致性问题都有了很多解决方案），但是有一个环节我们明显忽略了。在现在的微服务架构趋势下，微服务在运维层面和自动化部署方面基本上是比较完善了。从我个人经验来看,上层的开发、测试对微服务架构带来的巨大变化还在反应和学习中。开发层面讨论微服务的更多是框架、治理、性能等，但是从完整的软件工程来看我们严重缺失分析、设计知识，这也是我们现在的工程师普遍缺乏的技术。我们常常会发现一旦你想重构点东西是多么的艰难，就是因为在初期构造这栋建筑的时候严重缺失了通盘的分析、设计,最终导致这个建筑慢慢僵化最后人见人怕，因为他逐渐变成一个怪物。（比如，开发很少写 unitTest ,我们总是忽视单元测试背后产生的软件工程的价值。）被忽视的软件工程环节 — DEVTESTOPS我们有没有发现一个现象，在整个软件过程里，测试这个环节容易被忽视。任何一种软件工程模型都有 QA 环节，但是这个环节似乎很薄很弱，目前我们绝大多数工程师、架构师都严重低估了这个环节的力量和价值，还停留在无技术含量,手动功能测试低级效率印象里。这主要是测试这个角色整个技术体系、工程化能力偏弱，一部分是客观大环境问题，还有一部分自身问题，没有让自己走出去，多去学习整个工程化的技术，多去了解开发的技术，生产上的物理架构,这会有助于测试放大自己的声音。导致测试环节在国内整个设计创新薄弱的原因还有一个主要原因就是，开发工程师普遍没有完整的工程基础.在国外 IT 发达国家,日本、美国等,一个合格的开发工程师、测试工程师都是边界模糊的，自己开发产品自己测试，这需要切换思维模式，需要同时具备这两种能力，但是这才是整个软件工程的完整流程.我们有没有想过一个问题，为什么现在大家都在谈论 DevOps，而不是 DevTestOps,为什么偏偏跳过测试这个环节，难道开发的系统需要具备良好的可运维性就不需要可测试性吗，开发需要具备运维能力,运维需要具备开发能力，为什么测试环节忽略了.我们对 QA 环节的轻视，对测试角色的不重视其实带来的副作用是非常大的。微服务架构下测试复杂度和效率问题微服务的拆分粒度要比 SOA 细了很多,从容器化镜像自动部署来衡量...
