认识达内从这里开始

随着互联网的不断发展，自动化测试成为了新的一种软件功能测试方法。今天，我们就一起来了解一下，在微服务开发环境下的自动化测试设计。

被忽视的软件工程环节—DEVTESTOPS

我们有没有发现一个现象，在整个软件过程里，测试这个环节容易被忽视。任何一种软件工程模型都有QA环节，但是这个环节似乎很薄很弱，目前我们绝大多数工程师、架构师都严重低估了这个环节的力量和价值，还停留在无技术含量，手动功能测试低级效率印象里。

这主要是测试这个角色整个技术体系、工程化能力偏弱，一部分是客观大环境问题，还有一部分自身问题，没有让自己走出去，多去学习整个工程化的技术，多去了解开发的技术，生产上的物理架构，这会有助于测试放大自己的声音。

导致测试环节在国内整个设计创新薄弱的原因还有一个主要原因就是，开发工程师普遍没有完整的工程基础。在国外IT发达国家，日本、美国等，一个合格的开发工程师、测试工程师都是边界模糊的，自己开发产品自己测试，这需要切换思维模式，需要同时具备这两种能力，但是这才是整个软件工程的完整流程。

我们有没有想过一个问题，为什么现在大家都在谈论DevOps，而不是DevTestOps，为什么偏偏跳过测试这个环节，难道开发的系统需要具备良好的可运维性就不需要可测试性吗，开发需要具备运维能力，运维需要具备开发能力，为什么测试环节忽略了。

我们对QA环节的轻视，对测试角色的不重视其实带来的副作用是非常大的。

微服务架构下测试复杂度和效率问题

微服务的拆分粒度要比SOA细了很多，从容器化镜像自动部署来衡量，是拆小了之后很方便，但是拆小了之后会给整个开发、测试环节增加很大的复杂度和效率问题。

在SOA时期，契约驱动这个原则在微服务里也一样适用，跨部门需求定义好契约你就可以先开发上线了。但是这个里面大的问题就是当前系统的部分连调问题和自动化回归问题，如果是新系统上线还需要做性能压测，这外部的依赖如何解决。

也许我们会说，不是应该依赖方先ready，然后我们紧接着进行测试、发布吗。如果是业务、架构合理的情况下，这种场景大的问题就是我们的项目容易被依赖方牵制，这会带来很多问题，比如，研发人员需要切换出来做其他事情，branch一直挂着，不知道哪天突然来找你说可以对接了，也许这已经过去一个月或者更久，这种方式一旦养成习惯性研发流程就很容易产生线上BUG。

还有一种情况也是合理的情况就是平台提供方需要调用业务方的接口，这里面有一般调用的callback接口、交易链路上的marketing接口、配送routing接口等。

这里给大家分享我们目前正在进行中的marketing-cloud(营销云)规则引擎项目。

marketing-cloud提供了一些营销类业务，有团购、优惠券、促销等，但是我们的业务方需要有自己个性化的营销活动玩法，我们需要在marketing-cloud规则引擎中抽象出业务方营销活动的返回信息，同时打通个性化营销活动与公共交易、结算环节，形成一个完整的业务流。

节选：测试窝

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!