微服务开发环境下的自动化测试技术?
发布网友
发布时间：2023-04-03 22:33
共1个回答
热心网友
时间：2024-08-19 15:54
随着互联网的不断发展，自动化测试成为了新的一种软件功能测试方法。今天，电脑培训就一起来了解一下，在微服务开发环境下的自动化测试设计。
被忽视的软件工程环节—DEVTESTOPS
我们有没有发现一个现象，在整个软件过程里，测试这个环节容易被忽视。任何一种软件工程模型都有QA环节，但是这个环节似乎很薄很弱，目前我们绝大多数工程师、架构师都严重低估了这个环节的力量和价值，还停留在无技术含量，手动功能测试低级效率印象里。
这主要是测试这个角色整个技术体系、工程化能力偏弱，一部分是客观大环境问题，还有一部分自身问题，没有让自己走出去，多去学习整个工程化的技术，多去了解开发的技术，生产上的物理架构，这会有助于测试放大自己的声音。
导致测试环节在国内整个设计创新薄弱的原因还有一个主要原因就是，开发工程师普遍没有完整的工程基础。在国外IT发达国家，日本、美国等，一个合格的开发工程师、测试工程师都是边界模糊的，自己开发产品自己测试，这需要切换思维模式，需要同时具备这两种能力，但是这才是整个软件工程的完整流程。
我们有没有想过一个问题，为什么现在大家都在谈论DevOps，而不是DevTestOps，为什么偏偏跳过测试这个环节，难道开发的系统需要具备良好的可运维性就不需要可测试性吗，开发需要具备运维能力，运维需要具备开发能力，为什么测试环节忽略了。
我们对QA环节的轻视，对测试角色的不重视其实带来的副作用是非常大的。
微服务架构下测试复杂度和效率问题
微服务的拆分粒度要比SOA细了很多，从容器化镜像自动部署来衡量，是拆小了之后很方便，但是拆小了之后会给整个开发、测试环节增加很大的复杂度和效率问题。
在SOA时期，契约驱动这个原则在微服务里也一样适用，跨部门需求定义好契约你就可以先开发上线了。但是这个里面大的问题就是当前系统的部分连调问题和自动化回归问题，如果是新系统上线还需要做性能压测，这外部的依赖如何解决。
也许我们会说，不是应该依赖方先ready，然后我们紧接着进行测试、发布吗。如果是业务、架构合理的情况下，这种场景大的问题就是我们的项目容易被依赖方牵制，这会带来很多问题，比如，研发人员需要切换出来做其他事情，branch一直挂着，不知道哪天突然来找你说可以对接了，也许这已经过去一个月或者更久，这种方式一旦养成习惯性研发流程就很容易产生线上BUG。
