微服务应用程序的并行开发带来了管理上的挑战

菏泽炫佑科技

微服务应用程序的并行开发带来了管理上的挑战

微服务应用程序的另一个好处是它们更新更快、更容易。 当开发人员对传统的整体应用程序进行更改时自动化软件开发，他们必须进行详细的 QA 测试，以确保更改不会影响其他特性或功能。 但通过微服务，开发人员可以更新应用程序的各个组件。

微服务在带来好处的同时，也带来了挑战，可以概括如下。

从单体应用过渡到微服务架构时，需要添加更多的隔离组件，而这些组件的添加必然会带来更多的依赖。 即，复杂度变高。 这也给测试带来了相应的复杂性。 原本只需要从接口层开始的测试突然有了更多的深度依赖，测试工作量也呈指数级增长。

我们以一个应用程序中有 10 个接口的项目为例。 原本测试只需要测试这10个接口。 但使用微服务构建后，接口数量明显增加，每个接口派生出的新接口都需要测试。 测试一下，这可能是多重关系。 因此，微服务的接口抽象和体验非常重要。

接口数量的增加也会带来一个问题，就是原本由一个团队维护的项目拆分后可能会由两个或更多团队维护。 当需求发生变化时，接口的改变可能会引起连锁反应。 当其中一个接口出现延迟时，整个测试计划就很难保证。 团队需要等待其他团队并行开发完整的相关微服务。 微服务数量越多，需要考虑的对象就越广泛，这意味着并行开发和发布新功能变得更加困难。 因此，微服务的并行开发也带来了管理挑战。

对于单个应用程序，所有依赖项都可以在一台机器上模拟。 然而，在微服务场景中，由于往往存在很多依赖的服务，因此构建一个完整的环境是非常困难的。

微服务迁移的另一个主要负面影响是产生大量独立故障点。

对于测试来说，微服务方式意味着需要交互和沟通的人数必然会增加，因为普通团队很难在需求和实现之间进行高效的沟通。 沟通成本的增加可能会导致重要的功能点不先测试，而不重要的功能点先测试，从而导致整个项目进度的延误。

微服务测试

在微服务中，测试是一个非常重要的环节。 与常见的三层测试金字塔相比，在微服务场景中，这一层可以扩展到五层，如下图所示。

与测试金字塔相同的基本原理：

UI/UE测试

需要测试的方面有很多，包括功能测试、兼容性测试、安装卸载测试等。一般是根据业务模型编写测试用例，然后根据测试用例来判断结果的正确性。 当然还包括测试用户界面的风格是否符合客户要求、文字是否正确、页面美工是否美观、文字与图片的结合是否完美、背景是否美观、操作是否流畅等。 UI测试还确保UI中的对象按预期运行并符合公司或行业标准，包括用户友好性、人性化和可操作性测试。 UI测试比较主观，与测试人员的偏好有关。 例如，页面的色调和颜色令人眼花缭乱、用户登录页面难以找到、文本中出现错别字、页面图像范围过宽等。 这些都是UI测试中的缺陷。 严格来说，所有测试都包括UI/UE测试，而不仅仅是微服务测试。

端到端测试

除了测试服务之外，测试人员还需要确保应用程序实现业务目标，无论使用何种架构构建它，我们还测试集成系统操作的完整性。 因此，端到端测试在微服务测试解决方案中发挥着重要作用。 此外，考虑到微服务架构中存在一些可移动的部分执行相同的行为，端到端测试需要识别覆盖范围差距并确保架构重构时业务功能不受影响。

API测试

API（简称API），又称应用程序编程接口，是连接软件系统不同组件的协议。

API测试是对系统提供的API的各个方面进行验证。 API 功能测试与 UI 功能测试类似。 在知道输入内容和预期结果的前提下，使用该函数/调用该接口，验证是否可以返回预期结果。 不同的是，API测试是在返回结果呈现给客户之前完成的，因此对测试环境的依赖会更少。

API功能测试的主要方法是使用工具/软件调用被测API，然后验证其是否返回预期结果。 这通常可能是：

组件接口测试

虽然单独测试模块很重要，但测试各个模块是否正确交互以及测试它们作为子系统的交互性以查看接口缺陷也同样重要，这可以通过集成测试来完成。 集成测试的目的是检查集成模块的路径是否顺畅，以确认模块与外部组件之间的交互。 执行网关集成测试和持续集成测试可确保在发现外部组件之间的逻辑回归和中断时快速反馈，有助于评估各个模块中包含的逻辑的正确性。

单元测试

单元测试的范围在服务范围内，并围绕一组相关案例编写。 由于单元测试数量众多，理论上它们应该以自动化的方式执行。 在微服务中进行单元测试时，必须将协作单元测试（Unit）与隔离单元测试（Unit）结合起来，通过观察其状态变化来检查模块行为，并查看对象及其依赖关系之间的交互条件。 然而，测试人员需要确保在单元测试中，当单元“行为”受到限制时，“实现”不受测试限制——这可以通过不断比较单元测试的价值与维护成本/成本来完成执行此操作的限制性实施。

单元测试

单元测试是编写测试代码来检测特定的、具体的、细粒度的功能。 单元测试不仅用于保证当前代码的正确性微服务应用程序的并行开发带来了管理上的挑战，更重要的是保证代码修复、改进或重构后的正确性。

一个好的单元测试包含三个步骤：

在做单元测试时，代码覆盖率常常被用来作为衡量测试质量的指标。 代码覆盖率甚至用于评估测试任务的完成情况。 例如，代码覆盖率必须达到80%或90%。

那么一般代码覆盖率包括哪些内容呢？ 通常的评价指标如下：

目前很多公司已经意识到单元测试的重要性，但国内坚持编写单元测试的团队并不多。 难点之一是没有考虑而未能做好单元测试覆盖率检测。

API测试

对于API测试，根据不同团队的不同情况，如果测试人员编码能力较强，建议采用编码方式，方便与持续集成系统集成。 但目前能达到这个水平的测试很少，所以测试一般都是使用工具来完成。

*基本的功能就是发送HTTP请求，支持GET/PUT/POST/等多种HTTP方法。

你可以通过填写URL、body等来发送请求，这足以让我们做一些简单的测试。

每次配置请求时，您都可以将其保存到集合中。 这样下次测试就可以直接从集合中找到想要执行的测试了。

集合不仅具有分类和存储功能，还支持--key在整个集合内运行测试。

当然，也可以使用。 它是一个开源的API测试工具，支持数据对比、压力测试、上传脚本定制请求。 它可以轻松地在本地部署并与团队成员一起管理 API。

A/B 测试

A/B测试，也称为对比测试，类似于客户焦点小组，在一定的基准范围内比较一系列内容的变化。 A/B 测试来自电子邮件推广。 发送者将相同目的内容的不同版本邮寄给目标组以测量响应率。 根据这些数据，商家可以相应修改未来直邮的内容，改进为回复率更高的版本。

A/B测试的核心思想是：

事实上，你可以设计多种测试计划，例如ABC测试。 “AB测试”这个名字只是一个习惯名称。 A/B测试需要向不同的用户展示多个不同的版本，这就需要一个“导流”环节。 卸载可以在客户端或服务器端完成。 传统的AB测试通常卸载在服务器端，即基于后端的A/B测试（Back-end AB test）。 当用户的请求到达服务器时，服务器按照一定的规则返回不同的版本给不同的用户。 同时，记录数据的工作也是在服务器端完成的。

基于前端的A/B测试的监控粒度更细，可以定位到特定用户。 采用前端方式，在客户端引流。 同时，用户的鼠标行为甚至键盘行为都可以被记录并直接发送到相应的管理服务器。 这样做的好处是不需要技术部门的参与（如果前端工程师和后端工程师属于不同的部门），并且可以更准确地记录用户在页面上的每一个行为，甚至包括后端方法难以记录的无效点击。 。

对于大多数需求，我们希望每个版本的访问者数量均匀分布。 解决方案有很多，比如按照某个ID来划分用户。 这就需要为每个用户植入一个全球唯一的ID。 因为规则是自定义的，所以可以根据规则进行流量划分。 例如奇数显示A版本，偶数显示B版本。由于ID设置后一般不易更改，缺点是如果用户的浏览器不支持，则导流无法正常进行。 不过现代浏览器默认支持它，所以如果出现这种小概率，我们在处理样本时可以忽略它。

另外需要注意的是，A/B测试页面必须有较高的UV，即独立访客数，因为分布具有一定的随机性。 如果页面UV太小，分配到每个版本的人数就会较少，结果很可能会受到一些偶然因素的影响。 当UV较大时，根据大数定理，我们得到的结果将接近真实数据。

对于微服务场景，我们可以使用网关进行分流。 卸载后，我们就可以有针对性地收集所需的数据。 采集的数据根据​​业务分析的需要，包括用户的浏览器版本、点击事件上架、点击时间、访问的URL信息等。将采集到的数据存储在大数据平台中，供需要分析的部门进行二次处理和分析。

静态代码分析

在软件开发过程中，开发团队常常花费大量的时间和精力去发现和修改代码缺陷。 静态代码分析（代码）工具可以帮助开发人员在代码构建过程中快速有效地定位代码缺陷并及时纠正这些问题。 他们只是通过分析或检查源程序的语法、结构、流程、接口等来检查程序的正确性。 ，发现代码中隐藏的错误和缺陷，例如参数不匹配、嵌套语句不明确、不正确的递归、非法计算、可能的空指针引用等。这大大提高了软件的可靠性，节省了软件开发和测试成本。

常用的分析工具有、、PMD等，下面我们一起来认识一下这些工具。

质量控制

Sonar ( ) 是一个用于管理源代码质量的开源平台。 Sonar不仅是一个质量数据报告工具，也是一个代码质量管理平台。 通过插件机制，Sonar可以集成不同的测试工具、代码分析工具、持续集成工具。

与持续集成工具（例如/等）不同，Sonar并不是简单地将不同代码检查工具（例如PMD等）的结果直接直接显示在Web页面上，而是通过不同的插件对这些结果进行重新处理。 处理、定量测量代码质量的变化，从而可以轻松地针对不同规模和类型的项目进行代码质量管理。

在对其他工具的支持方面，Sonar不仅提供了对IDE的支持，可以在IDEA等工具中在线查看结果； 同时Sonar提供了大量持续集成工具的接口支持，可以方便地用于持续集成。 声纳。

此外，Sonar()插件还可以提供对Java以外的其他编程语言的支持，并且对国际化和报告文档也有良好的支持。 支持的语言包括Java、PHP、C#、C、Cobol、PL/SQL、Flex等等。

代码质量可以从多个维度来检测，包括以下几个维度。

后记

无论是自动化测试还是质量管理，都只是一种实现手段； 它们的真正价值在于提高代码质量和提高产品的持续交付能力。

在当前的软件开发过程中，能够实现测试和质量管理的自动化是非常重要的。 不仅节省了测试和质量管理人员的成本，还提高了整体软件构建的速度。 在人工智能逐渐普及的今天，它必将成为微服务生态闭环中非常重要的一环。

炫佑科技专注互联网开发小程序开发-app开发-软件开发-网站制作等