关于微服务测试的思考

相信在互联网领域的公司，对于微服务应该一点不陌生，愈来愈多的公司会采起这样的一种架构

微服务的特色：

•     业务拆成独立的系统，可单独发布，部署。
•     适合水平扩展，同时也成熟配套的服务治理
•     系统复杂度增高，端到端的一个业务可能调用十几个甚至几十个系统。调试和测试包括环境复杂度增，Debug问题难度加大。

那么测试活动相比传统行业须要作出一些调整，你可能会面临

• 快速的建立一套稳定的测试环境（保证全部服务的联通性，全部数据库的数据是最新产线的，对于使用场景你能够须要区分是单组件，仍是几个组件，仍是集成环境的几种模式，不一样环境对于系统的一些配置多是不一样的。）  
• 测试策略的识别：哪些需求是单个组件就能够完成，哪些需求是须要组件与组件以前的连调，哪些是须要端到端的测试
• 测试工具的配套，单组件测试的状况下你须要对上下游系统的MOCK，这种MOCK分为有逻辑的MOCK（简单模拟该系统逻辑）， 和无逻辑的MOCK（只有作response的挡板），有些多是JAVA RPC程序调用，有些是简单HTTP应用调用，须要在正在开始测试前准备好
• 微服务下系统非功能测试的考虑：
  • 联通性
  • 数据一致性（分布式事务的保证或者业务间数据一致性， 如商品支付了你得给人加积分啊这样的）
  • 服务容错性（当某服务不可用是是否作了服务降级）
  • 服务调用性能（是否会由于某个系统处理慢出现超时）
  • 还有一些不肯定的问题（基于使用的技术作积累发现的一些问题
• 当前不管是传统All In One的仍是微服务的都须要有自动化测试的回归，都知道自动化测试也是分层的，可是作的好的稳定的我以为并很少，我司也只是作了接口驱动业务的主流程测试（没有专业的自动化团队每一个人都须要参与自动化，作对于团队最有价值的事，保证系统主要业务功能）
  • 单元测试（能多作固然最好，可是实际并无多少公司有，或者也很少）
  • API测试（这里主要讲的是业务驱动）
  • 契约测试（只是为了保证接口与相应是咱们以前约定的，契约测试是一种方法，可是不非得就要作，保证的方法能够是其余）
  • 集成测试（有条件的，作几个冒烟的用例就好了，毕竟集成后，环境复杂自动化的稳定性未必高）
  • UI测试（我一直不怎么建议作这个，你们随意，我这里指的是WEB非APP）

 

这里只是简单的分享了一下对于微服务下的测试的须要考虑的问题，对于须要转型微服服的小伙伴有一些帮助。