关于微服务测试的思考

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

微服务的特点：

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

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

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

 

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

转载于:https://my.oschina.net/u/4004947/blog/3078804