代码质量测试 code-quality-testing

了解管道代码质量测试的工作方式以及其提高部署质量的方式。

简介 introduction

在管道执行期间，将捕获大量量度，并将这些量度与业务负责人定义的关键绩效指标 (KPI) 或 Adobe Managed Services 设置的标准进行比较。

将使用三层评级系统进行报告。

三层评级 three-tiered-ratings

管道中有三项审核：

对于这三项审核中的每项审核，审核所确定的问题具有一个三层结构。

代码质量测试 code-quality-testing-step

此步骤将评估应用程序代码的质量，它是仅代码质量管道的主要用途，并且紧随所有非生产和生产管道中的构建步骤执行。请参阅配置非生产管道文档以了解更多信息。

代码质量测试将扫描源代码以确保它符合特定的质量标准。通过将 SonarQube 分析、使用 OakPAL 的内容包级别检查和使用 Dispatcher 优化工具的 Dispatcher 验证配合使用来实现这一点。

有 100 多条规则结合了通用 Java 规则和特定于 AEM 的规则。一些特定于 AEM 的规则基于来自 AEM Engineering 的最佳实践而创建，这些规则称作自定义代码质量规则。

代码质量测试的结果按此表中汇总的评级交付。

处理误报 dealing-with-false-positives

质量扫描过程并不完善，有时会错误地识别出实际上并不是问题的问题。这种情况称作误报。

在这些情况下，可以使用标准 Java @SuppressWarnings 注释为源代码添加注释，并将规则 ID 指定为注释属性。例如，一种常见误报是用于检测硬编码密码的 SonarQube 规则可能会妨碍识别硬编码密码的方式。

以下代码在 AEM 项目中相当常见，其中包含用于连接到某些外部服务的代码。

@Property(label = "Service Password")
private static final String PROP_SERVICE_PASSWORD = "password";

之后，SonarQube 将引发阻断漏洞。 不过，在查看代码后，您会发现这并不是漏洞，并且可以使用适当的规则 ID 注释代码。

@SuppressWarnings("squid:S2068")
@Property(label = "Service Password")
private static final String PROP_SERVICE_PASSWORD = "password";

然而，如果代码的实际情况如此：

@Property(label = "Service Password", value = "mysecretpassword")
private static final String PROP_SERVICE_PASSWORD = "password";

那么，正确的解决方案是移除硬编码密码。

安全性测试 security-testing

Cloud Manager 会在部署后在暂存环境上运行现有的 AEM 安全运行状况检查，并通过 UI 报告状态。结果是由环境中的所有 AEM 实例汇总而成。

可以随时通过 Web 控制台或操作仪表板执行这些相同的运行状况检查。

如果任一实例报告未通过给定的运行状况检查，则整个环境将无法通过此运行状况检查。与代码质量和性能测试一样，这些运行状况检查将分成多个类别并通过三层审核系统进行报告。唯一的区别是，安全性测试中没有阈值。运行状况检查要么全部通过，要么全部未通过。

下表列出了运行状况检查。

性能测试 performance-testing

AEM Sites aem-sites

Cloud Manager 对 AEM Sites 项目执行性能测试。性能测试通过启动虚拟用户（容器）来运行大约 30 分钟，这将模拟实际用户访问暂存环境中的页面来模拟流量。这些页面是使用爬网程序找到的。

虚拟用户 virtual-users

Cloud Manager 启动的虚拟用户或容器的数量由具有​ 业务负责人 ​角色的用户在创建或编辑项目时定义的 KPI（响应时间和页面查看次数/分钟）驱动。根据定义的 KPI，将启动多达 10 个模拟实际用户的容器。选择进行测试的页面将被拆分并分配给每个虚拟用户。

爬网程序 crawler

在 30 分钟的测试期开始之前，Cloud Manager 将使用由客户成功工程师配置的一组种子 URL（包含一个或多个种子 URL）来对暂存环境进行爬网。从这些 URL 开始，检查每个页面的 HTML，并以广度优先的方式遍历链接。

用于测试的页面集 page-sets

按三个页面集选择页面。Cloud Manager 使用来自生产环境和暂存环境中的 AEM 实例的访问日志来确定以下存储桶。

跨所选页面集的流量分配 distribution-of-traffic

您可以在管道配置的​ 测试 ​选项卡上，从一到三个页面集中选择任一页面集。流量分配基于所选页面集数。也就是说，如果选定所有三个页面集，则每个页面集的查看次数占总页面查看次数的 33%。如果选定两个页面集，则每个页面集的查看次数占总页面查看次数的 50%。如果选定一个页面集，则该页面集的查看次数占总页面查看次数的 100%。

我们来看看以下示例。

在 30 分钟的测试期间：

测试和报告 testing-reporting

Cloud Manager 通过在暂存发布服务器上以未经身份验证的用户身份（默认情况下）请求页面，来对 AEM Sites 项目执行性能测试，测试期间为 30 分钟。它测量每个页面的虚拟用户生成的量度（响应时间、错误率、每分钟查看次数等）以及所有实例的各种系统级量度（CPU、内存、联网数据）。

下表总结了使用三层审核系统的性能测试矩阵。

请参阅经过身份验证的性能测试部分，了解有关将基本身份验证用于 Sites 和 Assets 的性能测试的更多详细信息。

经过身份验证的性能测试 authenticated-performance-testing

如有必要，拥有认证站点的 AMS 客户可以指定一个用户名和密码，Cloud Manager 将在站点性能测试期间使用该用户名和密码访问网站。

用户名和密码将指定为名为 CM_PERF_TEST_BASIC_USERNAME 和 CM_PERF_TEST_BASIC_PASSWORD 的管道变量。

用户名应存储在 string 变量中，密码应存储在 secretString 变量中。如果同时指定这两个变量，则每个来自性能测试爬网程序和测试虚拟用户的请求都将包含这些凭据作为 HTTP 基本身份验证。

要使用 Cloud Manager CLI 设置这些变量，请运行：

$ aio cloudmanager:set-pipeline-variables <pipeline id> --variable CM_PERF_TEST_BASIC_USERNAME <username> --secret CM_PERF_TEST_BASIC_PASSWORD <password>

请参阅补丁用户管道变量 API 文档了解如何使用 API。

AEM Assets aem-assets

Cloud Manager 通过反复上传资产来对 AEM Assets 项目执行性能测试，测试时间为 30 分钟。

新用户引导要求 onboarding-requirement

对于 Assets 性能测试，您的客户成功工程师将在暂存环境中引导作者期间创建 cloudmanager 用户和密码。性能测试步骤需要一个名为 cloudmanager 的用户和由 CSE 设置的相关密码。这既不应从创作实例中移除，也不应更改其权限。这样做可能会导致 Assets 性能测试失败。

用于测试的图像和资产 assets-for-testing

客户可以上传自己的资产进行测试。可以从​ 管道设置 ​或​ 编辑 ​屏幕执行此操作。支持 JPEG、PNG、GIF 和 BMP 等常见图像格式以及 Photoshop、Illustrator 和 Postscript 文件。

如果未上传图像，Cloud Manager 将使用默认图像和 PDF 文档进行测试。

用于测试的资产的分配 distribution-of-assets

在​ 管道设置 ​或​ 编辑 ​屏幕中设置每分钟上传的每种类型资产数量。

例如，如果使用 70/30 拆分，则每分钟将上传 10 个资产，其中包括 7 个图像和 3 个文档。

测试和报告 testing-and-reporting

Cloud Manager 将使用 CSE 设置的用户名和密码在创作实例上创建一个文件夹。之后，使用开源库将资产上传到该文件夹中。使用开源库编写按 Assets 测试步骤运行的测试。每个资产的处理时间以及各种系统级量度都会在 30 分钟的测试持续时间内测量。此功能可以上传图像和 PDF 文档。

性能测试结果图表 performance-testing-results-graphs

“性能测试”对话框 ​中提供了许多量度

可以展开量度面板来显示图表和/或提供下载链接。

此功能适用于以下量度。

内容包扫描优化 content-package-scanning-optimization

在质量分析过程中，Cloud Manager 会对 Maven 构建生成的内容包进行分析。 Cloud Manager 提供优化功能以加速此过程，当遵守某些打包限制时，这些优化功能将生效。 最重要的是对输出单个内容包（通常称为“所有”包）的项目执行的优化，其中包含构建生成的大量其他内容包（这些内容包标记为已跳过）。 当 Cloud Manager 检测到此情况时，它不会解压缩“所有”包，而是直接扫描各个内容包并根据依赖关系对它们进行排序。 例如，考虑以下构建输出。

如果 myco-all-1.0.0-SNAPSHOT.zip 中的唯一项目是两个跳过的内容包，则将扫描两个嵌入包而不是“所有”内容包。

对于产生数十个嵌入包的项目，此优化已被证明可将每次管道执行时间节省 10 分钟以上。

当“所有”内容包包含跳过的内容包和 OSGi 捆绑包的组合时，可能会出现特殊情况。 例如，如果 myco-all-1.0.0-SNAPSHOT.zip 包含前面提到的两个嵌入式包以及一个或多个 OSGi 捆绑包，则仅使用 OSGi 捆绑包构建一个新的最小内容包。 此包始终名为 cloudmanager-synthetic-jar-package，并且包含的捆绑包将放置在 /apps/cloudmanager-synthetic-installer/install 中。