标签：服务 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

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。