20210401 微服务测试

微服务测试
微服务架构对测试人员意味着什么
   1.每个服务承担一定的职责，服务尽可能地小，但是还需要达到一定的规模。对于项目做出向微服务转变的决策时，测试人员要勇于提出质疑，要不要做这样的转变。
   2.微服务之间通常通过REST API连接。
   3.每种服务不一定提供界面。对测试人员意味着不一定能够从UI对系统进行完整测试， 这就对API级别的集成化测试提出了要求。
   4.微服务通常还可以划分为更小的模块，在对微服务进行测试时，可以从不同的模块着手，进行相应的模块测试。
第一个需要关注的是 微服务测试对于测试人员意味着什么。每一个服务都会承担一定的职责，都有自己的业务逻辑，如何把原来单体式架构的服务 转变为 一个一个的小服务呢。服务划分的原则是 规模要 尽可能的小，但是又要达到一定的规模，每个服务至少能为其余的 2 个服务 提供支持。如果划分的服务 只能够给 另外的一个 服务提供支持，这个划分就太小了；这就是 单体式架构向微服务架构转变时的 功能切分原则
微服务的本质是 解决 系统里面的耦合，需要解耦，将耦合度变小，服务内部是高耦合的，服务和服务之间是低耦合的
开发团队在转向时，这个地方经常会出现问题，并没有达到真正的解耦作用，这就会造成产品维护和测试成本的增加

所以测试团队需要在会议中提出这样的问题，就是我们的项目有没有必要转变成微服务，需要提出这样的质疑，因为微服务随着服务的增加，管理成本一定会提升，而测试人员在企业里担当着产品质量把关人的角色
所以，提出这样问题的目标是 让企业决策人员意识到这种转型的潜在成本，千万不能做无用功，这也算是测试团队的职责所在

另外服务和服务之间一般是通过 Restful api 实现分割的，一般的操作包括 pause？提供增加资源的操作 get？获取资源  put？更新资源 delete 删除资源。在这里还有一个常用的 pach？也是更新资源，是对局部资源的更新，而 put 是全部资源的更新；无论发送还是接收，都是 json 的数据

标签：服务,20210401,测试人员,测试,一定,架构,资源
来源： https://blog.51cto.com/15149862/2678945