java微服务测试
对于经常在网上阅读文章的开发人员来说，许多组织都希望从当前的整体Java应用程序应用程序迁移（或扩充），这不足为奇。 对与错，微服务架构已经成为实现基于Web的应用程序的事实上的最佳样式。 但是，微服务提供的“巨大力量”带来了巨大的责任和挑战。
确实，关于实现基于微服务的体系结构 ，对数据建模以及运营 （和组织）方面的挑战已经写了很多文章。 但是，除了Toby Clemson的出色文章“微服务体系结构中的测试策略 ”外，关于用这种新的体系结构样式进行测试所面临的挑战的文献很少。 本文旨在增加有关测试基于Java的微服务的讨论。
作为我与SpectoLabs和OpenCredo一起工作的一部分，我们已帮助多个组织构建和部署基于微服务的应用程序，包括绿地原型，棕地集成和迁移。 我们在此过程中学到了很多东西，今天我们渴望分享我们在如何设计，构建和测试基于微服务的系统方面的发现：
设计系统：确定服务边界
- 确定现有（或新）系统中业务功能的范围。 我们通常将这些领域定义为领域驱动设计（DDD） “ 有限上下文 ”。
- 此步骤可能需要一些时间（并且还将是迭代的），但是输出通常是一个上下文映射 ，该上下文映射表示定义应用程序服务边界时的第一遍。
设计服务API：确定服务功能
- 与相关的企业所有者，领域专家和开发团队合作，以定义服务功能和API。
- 使用行为驱动设计（BDD）技术的“ 三个朋友 ”。
- 此步骤的典型输出包括：
- 一系列BDD样式的验收测试，它们声明组件（单个微服务）级别的要求，例如Cucumber Gherkin语法验收测试脚本；
- 测试脚本将针对的API规范，例如Swagger或RAML文件。
由内而外建立服务
- 现在我们有了我们的API规范和相关的（服务级别）业务需求，我们可以开始从内而外构建服务功能！
- 继Toby Clemson撰写的关于微服务测试的出色文章之后，我们在这里同时使用集成测试和单元测试（社交测试和单独测试），并且经常使用双循环TDD方法。
- 我们经常使用JUnit ， Lambda-behave ， Mockito和Hoverfly Java进行基础单元测试。
组件测试
- 结合从内到外构建服务，我们还致力于组件级测试。 这与上面提到的集成测试不同，因为组件测试通过公共API运行，并测试整个业务功能。
- 通常，第一波组件测试使用我们在2.3中定义的验收测试脚本，并且这些脚本断言我们已经在此服务中正确实现了业务功能。
- 我们在这里喜欢的工具包括REST保证的和Spring Boot测试功能 。
- 测试非功能需求（NFR）。 示例包括：
- 对服务提供的一系列核心快乐路径进行性能测试，例如JMeter （通常通过Jenkins Performance Plugin触发）或Gatling （通常通过Flood.io运行）。
- 使用诸如Continuum Security的bdd-security之类的框架进行基本的安全测试，其中包括出色的 OWASP ZAP。
- 容错测试，我们使用Hoverfly和相关的中间件 （过去是Saboteur ）确定性地模拟故障。
- 可见性测试，它断言该服务为度量标准和运行状况检查提供了预期的端点。
合同测试–验证组件交互
- 验证组件之间建议的交互。
- 在微服务领域中，一种流行的方法是使用消费者驱动的合同 ，并且可以使用诸如Spring Cloud Contract ， Pact-JVM或Pacto之类的框架来实现。
端到端（E2E）测试：声明系统级业务功能和NFR
- E2E自动化测试从本质上断言了核心用户旅程和应用程序功能（并还防止了退化）。
- 测试非功能性/跨功能性需求，例如，断言所有关键业务流程都在工作，在一定时间内做出响应并且是安全的。
- 当E2E测试不可用的触摸系统时，请使用Hoverfly之类的工具来模拟API。 可以通过Hoverfly中间件注入延迟或失败。
- 该过程的此步骤的输出应包括：
- 一个功能正常且功能强大的系统；
- 系统的自动验证；
- 客户满意！
最后的话
如果您喜欢阅读本文，那么可以在specto.io上找到更全面的版本：“ 设计，构建和测试微服务的建议食谱 ”。
该文章最初发表于2017年1月的Eclipse Newsletter：Exploring New Technologies
有关更多信息和文章，请查阅Eclipse Newsletter 。
Daniel Bryant博士将在JAX DevOps上发表两个演讲：
翻译自: https://jaxenter.com/testing-java-microservices-not-big-problem-131651.html
java微服务测试
124
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
