程式碼品質測試 code-quality-testing

了解管道程式碼品質測試如何運作及如何提高部署品質。

簡介 introduction

在管道執行期間，軟體會擷取許多指標。然後，將這些指標與企業主定義的關鍵績效指標 (KPI) 進行比較。或者，將這些與 Adobe Managed Services 制定的標準進行比較。

這些結果會使用三層級評等系統報告。

三層級評等 three-tiered-ratings

在管道內有三個閘道：

對於這些閘道中的每一個，閘道識別的問題都有一個三層結構。

程式碼品質測試 code-quality-testing-step

此測試步驟會評估應用程式程式碼的品質，這也是程式碼品質管道的主要目的。在所有生產和非生產管道中的建置步驟之後立即執行。若要了解更多詳細資訊，請前往設定非生產管道。

程式碼品質測試會掃描原始程式碼以確保其符合特定的品質標準。

軟體會使用 SonarQube 分析、使用 OakPAL 的內容套件層級檢查和使用 Dispatcher 最佳化工具的 Dispatcher 驗證的組合來實施。

有超過 100 條規則結合通用 Java 規則和 AEM 特定規則。部分 AEM 特定規則是根據 AEM 工程團隊的最佳做法來建立，並稱為自訂程式碼品質規則。

程式碼品質測試的結果會以此表格中總結的評分提供。

處理誤判 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 在建立或編輯程式時便已設定。

根據已定義的 KPI，最多可啟動 10 個模擬實際使用者的容器。為了進行測試所選取的頁面將被分割並分配給每個虛擬使用者。

編目程式 crawler

在 30 分鐘測試期開始之前，Cloud Manager 使用客戶成功工程師設定的一組一或多個 seed URL 來耙梳中繼環境。從這些 URL 開始，請檢查每個頁面的 HTML，並以廣度優先方式點選所有連結。

用於測試的頁面集 page-sets

三個頁面集選取頁面。Cloud Manager 會使用來自生產和中繼環境中的 AEM 執行個體的存取紀錄來決定以下貯體。

跨所選頁面集的流量分佈 distribution-of-traffic

您可以在管道設定的​ 測試 ​索引標籤上，在一組到全部三組中進行選擇。流量的分佈是根據所選的組數。也就是說，如果將全部三組都選取，則會將總頁面檢視次數的 33% 分配到每組。如果選取兩組，則 50% 流向每組。如果選取了一組，則 100% 的流量將流向該組。

讓我們考慮以下範例。

超過 30 分鐘測試期：

測試和報告 testing-reporting

Cloud Manager 會在中繼發佈伺服器上以預設的未經驗證使用者的身分來請求頁面，從而執行 AEM Sites 方案的效能測試，測試期為 30 分鐘。它測量每個頁面的虛擬使用者產生的指標 (回應時間、錯誤率、每分鐘檢視次數等)，以及所有實例的各種系統級別指標 (CPU、記憶體、網路資料)。

下表會概述使用三層級閘道系統的效能測試矩陣。

如需對 Sites 和資產使用基本驗證進行效能測試的更多詳細資訊，請參閱「已驗證的效能測試」。

已驗證的效能測試 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 每 30 分鐘會重複上傳資產，以執行 AEM Assets 方案的效能測試。

上線要求 onboarding-requirement

對於資產效能測試，您的客戶成功工程師在作者加入中繼環境期間建立cloudmanager使用者名稱和密碼。效能測試步驟需要名為 cloudmanager 的使用者以及由您的 CSE 設定的相關密碼。

此方法應保留在作者實例中，且其權限不變。更改或刪除可能會導致資產效能測試失敗。

用於測試的影像和資產 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 設定的使用者名稱和密碼在作者執行個體上建立一個檔案夾。然後使用開放原始程式碼資料庫將資產上傳到檔案夾。資產測試步驟執行的測試會使用開放原始程式碼資料庫編寫。在 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 中。