面向微服务的自动化测试框架
如果你是一名测试工程师，你可能在过去一年左右听到了更多关于微服务的信息。这并不奇怪，因为许多软件公司也正在转向更“微服务”的创建软件的方式。这不可避免地带来了很多挑战，特别是如何在微服务世界中实现自动化测试。
“微服务”是软件架构中增加的另一个术语。微服务架构风格涉及开发单个应用程序，这些应用程序可以作为一套小型服务一起工作，每个应用程序都运行在其单个进程中，并与轻量级机制（如HTTP资源API）进行通信。这些服务需要最低限度的集中管理，使用不同的数据存储技术，并且可以用不同的编程语言编写。这些围绕业务功能构建的服务也可以由支持全自动部署的机器独立部署。
SOA与微服务
典型的面向服务的架构（SOA）模型通常具有依赖的企业服务总线（ESB），微服务使用更快的消息传递机制。虽然SOA专注于命令式编程，但微服务架构使用的编程风格主要以响应式角色为基础。虽然SOA模型通常具有过大的RDBMS，但微服务经常使用可连接到传统数据库的NoSQL或micro-SQL等数据库。也就是说，真正的区别在于用于创建一整套服务的体系结构方法。
用于微服务体系结构的实践是基于开发人员为大型企业组织创建软件应用程序所遵循的实践而创建的。开发人员的经验非常便于了解当前最终用户的期望，并有助于在各种设备上创建一致而动态的体验。对可访问性，适应性强，模块化和可扩展性的基于云的应用程序需求量很大。这导致许多开发人员改变他们的方法。
微服务微服务体系结构包含专注于创建完整应用程序或任务的小型服务。微服务的每个实例都代表您的应用程序中的单一责任。真正的好处是，这些服务是相互独立的，这使得它们可以独立部署和测试。
了解微服务
在我们处理如何开始测试微服务之前，让我们定义微服务。最常见的开发风格称为单片设计。
单片应用程序“紧密结合”，或者用一组相互高度依赖的类编写。例如，如果您有两个类（X和Y）并且对X进行了更改，那么这种更改很可能会对Y类产生影响。这是一个简单的示例，大多数单一应用程序由一组类组成相互依赖。如果对这种类型的应用程序进行更改，通常会需要构建和部署整个应用程序的新版本。
相比之下，微服务体系结构由非常小的，非常专注的服务组成，它们在一起时构成最终完整的应用程序或任务。微服务的每个实例代表您的应用程序中的单一责任。
这些服务彼此独立，这使得它们可以独立部署和测试。以下介绍一下如何进行自动化测试的一些方法。
- 单元测试
微服务结构复杂，因为你有许多独立的服务以很多方式与其他独立服务进行通信。开始测试自动化工作的好地方是直接单独测试特定微服务的功能。通常这很容易通过使用REST API与您的服务进行交谈以及某种模拟来让您单独测试服务，而无需与其他服务进行任何类型的集成。
单元测试的范围是服务的内部。就测试量而言，它们是最多的。理想情况下，单元测试应该是自动的，取决于开发语言和服务框架。但是当您更改和部署服务X时会发生什么？它将如何影响Y或A的服务？你怎么知道你没有破坏什么？您不仅应该确保您的服务本身在运行，还需要确保其他正在使用您的服务的人员不会受到您的更改的影响。 - 合同测试
合同测试应将每项服务视为一个黑匣子，所有服务必须独立调用，并且必须验证其响应。该服务的任何依赖关系必须是允许该服务运行但不与任何其他服务交互的存根。这有助于避免可能由外部调用导致的任何复杂行为，并将重点放在对单个服务执行测试上。即使服务发生变化，每个消费者也必须从服务中获得相同的结果。应该可以灵活地在后面添加更多的功能。但是，这些添加不能破坏服务功能。如果服务是以这种方式设计的，它将在更长的时间内保持健壮，并且消费者不需要修改他们的代码以考虑稍后做出的改变。 - 端到端测试
由于我们知道每个微服务都是独立的，并且可以通过多种方式独立使用，所以“应用程序”的概念几乎成为这种环境中的幻想。因此，采用典型的端到端测试自动化策略并不像其他软件架构那样有效。
因此，提出一种涵盖真实用户可能执行的所有可能工作流程的传统端到端测试方法并不真正奏效。您可以使用80/20规则来确定您认为常见的核心旅程，但您可能不希望花费精力试图在此级别考虑所有端到端可能性。
端到端测试验证整个过程流程是否正常工作，包括所有服务和数据库集成。彻底测试影响多种服务的操作可确保系统作为一个整体协同工作并满足所有需求。多种行为驱动框架可以通过抽取用户故事并验证系统的行为如预期来帮助实现功能测试的自动化。
实践中不可能知道用户使用你的服务的所有方式。使用用户驱动的合同模型，用户有责任提供一套测试，指定需要什么类型的交互以及以何种格式。然后，您的服务将同意这份合同并确保它没有损坏。这消除了对其他服务的依赖。这种方法还使您能够验证合同是否在交付时完成。 - 用户界面UI/功能测试
用户界面测试是用户使用角度最高级别的测试，这个级别的测试必须像用户试图与系统进行交互。所有数据库，接口，内部和第三方服务必须无缝协作才能产生预期结果。
在微服务世界中，需要能够在运行时快速响应并且及时处理生产环境暴露的问题。因此，建立一个关键的监控和警报系统并对生产进行追踪至关重要。如果其中一项服务出现故障或无响应，您需要立即知道。通过在监控的帮助下发现生产期间的问题，您通常可以在用户甚至知道存在问题之前自动回滚到服务的最后一个已知的良好版本。
微服务自动化测试实践
互联网金融企业业务场景复杂，功能点分布广度及深度数量级庞大，为了解决众多业务模块之间的相互调用，保证业务场景链路的完整性及健壮性，企业运用了dubbo技术对各个微服务的接口提供了完整解决方案。
企业的质量控制部门如何去管控每一个微服务的质量，从而形成每一条测试链路的闭环呢？从测试角度来看，企业需要一个针对微服务的测试框架，测试工程师们在框架内实施多种纬度及类型的测试方案，确保测试的可控性，标准化，可持续性。
下面一起探讨一下在工作中使用的一套标准化测试框架。
根据已有情况，我们测试技术支撑团队研发的一款基于Spring & TestNG的Java测试自动化代码开发框架，可测试范围覆盖dubbo service、restful api、数据库(MySQL)、缓存(Cache/Memcached)、消息框架(Kafka/Rabbitmq)、Zookeeper等方面的内容，其目标是构建互联网公司通用的高可用、高扩展测试基础组件。特点概述：
功能丰富 ：以Spring开源框架为平台，构建互联网Java后端测试技术栈的通用测试组件框架。
其核心组件包括：测试基础框架、代码生成工具、服务化(SOA)测试框架、restful测试框架、
数据库框架、缓存(redis/memcached)框架、Zookeeoper客户端框架、配置管理框架、
开关框架、消息队列(kafka/rabbitmq)框架等方面的内容；
得心应手 ：代码生成工具直接生成自成一套的代码风格，一套基于Java & Spring & TestNG + Maven技术栈的dubbo、restful api测试框架，测试人员只需要编写业务逻辑测试代码&测试数据即可，方便高效快捷；
深度整合 ：封装多种数据驱动(TestNG DataProvider)模型，支持多种测试用例管理平台，支持测试结果持久化到db并上报测试数据中心。
其主要模块如下：
- core : 核心基础框架，包含上下文Context, Exception等.
- config :配置框架，制定classpath下的配置文件读取规范。
- tools： 代码生成工具，一键生成基于gradle/maven的测试代码框架。
- http： http服务接口测试框架。
- rpc： dubbo服务接口测试框架。
- db： 数据库(MySQL)客户端框架。
- cache： 缓存(redis/memcached)客户端框架。
- test： 基于TestNG二次开发的测试框架，并与测试用例平台相结合。
- zkclient： 基于开源Curator Framework的Zookeeper客户端框架。
- logger： 统一日志框架，集成logback, log4j, slf4j等。
- mq : 基于kafka/rabbitmq中间件的消息队列客户端
- plugin : 基于Spring schema扩展特性的测试插件，提供环境/系统变量前置等功能。
- mocker: mocker service平台的java sdk.
- atpclient: 自动化测试平台java sdk。
项目实践
接下来使用该框架对其中一个微服务实施测试。
第一步，生成maven测试项目模板
1.首先，从git仓库将代码clone到工作环境。
2.解压配置项目信息，打开并编辑项目目录下的 “/bin/config.property”文件
3.运行run.cmd文件,在project.exportPath目录下生成maven的测试项目
4. 将生成好的Maven项目导入你的IDEA中。第二步 编写测试脚本
在第一步生成好的maven测试项目模板中，可以根据生产的demo示例文件来定制你的测试。其中DemoTest.java文件如下：
public class DemoTest extends TestNGBaseTest {
// Get your dubbo service from Spring Ioc container.
// Note that your service should be avaliable in current environmnet, otherwise, it will get nothing.
private IDemoService iDemoService = BeanUtil.getBean("iDemoService");
@Test(dataProvider = "ExcelDataProvider"/* , testName="id" */)
public void doDemoServiceTest(Map testData) throws Exception {
// Get Java Bean Model from excel & json
DemoRequestDTO demoRequestDTO = buildJavaBeanModel(DemoRequestDTO.class, testData, this);
DemoResponseDTO expectedDemoResponseDTO = buildJavaBeanModel(DemoResponseDTO.class, testData, this);
// invode dubbo service
Result result = iDemoService.doD0emoService(demoRequestDTO);
// Assert
Assert.assertTrue(result.isSuccess());
Assert.assertEquals(result.getResult().getId(), expectedDemoResponseDTO.getId());
Assert.assertEquals(result.getResult().getName(), expectedDemoResponseDTO.getName());
}
}
1.测试类DemoTest一定要extends TestNGBaseTest。
2.并且@Test(dataProvider = “ExcelDataProvider”)是选择使用test的数据驱动ExcelDataProvider。
3.此外，如果需要关联testlink中的某一个测试用例，此处需要填写testcase的Id。
4.通过private IDemoService iDemoService = BeanUtil.getBean(“iDemoService”);可以获取到dubbo service的bean defination。
5.当需要Java的实体类DemoRequestDTO的实例时，可以通过调用DemoRequestDTO demoRequestDTO = buildJavaBeanModel(DemoRequestDTO.class, testData, this);来获取。测试数据来源是data-excel下面，与测试类同名的excel文件src/test/resources/data-excel/DemoTest.xlsx，测试方法名字匹配excel中的sheet name。
6.如果excel中出现了某一个变量类型，即${ }中定义的类型，它需要匹配data-json中对应目录下的json文件，该json文件即为该实体类实例的数据信息。
7.通过Result result = iDemoService.doDemoService(demoRequestDTO);调用dubbo service.
8.对实际返回的result， 同期望返回的数据做断言
第三步 执行测试用例及测试报告。
完成编写测试用例后，将用例放入集成环境调度执行。
使用Jenkins可以对测试用例执行进行更好的调度管理，并对运行状态和返回结果进行查看。
同时框架还公布了外部API，以供对接其他平台进行结果展示。使用者可以根据自己的需求自定义自己的报告展示模块。
以上，就是针对dubbo的微服务测试框架。
在Jenkins上我们可以看到历史的执行结果。
作者简介：
就职于甜橙金融信息技术部，质量平台资深开发，致力于用最新的技术开发最好的工具。
欢迎关注公众号，和我一起成长！
