程式碼品質測試 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 執行個體彙總而成。

上述相同的健康情況檢查可隨時透過網頁控制台或操作儀表板執行。

如果任何執行個體報告指定的健康狀態檢查失敗，則整個環境將無法通過該健康狀態檢查。 和程式碼品質和效能測試一樣，這些健康情況檢查會被歸類並使用三層級閘道系統進行報告。 唯一的區別是安全性測試沒有臨界值。 所有的健康情況檢查結果都會是成功或失敗。

下表為健康情況檢查的清單。

效能測試 performance-testing

AEM Sites aem-sites

Cloud Manager 會執行 AEM Sites 的效能測試。 效能測試會透過建立虛擬使用者（容器）來執行30分鐘，這些虛擬使用者（容器）會模擬實際使用者來存取中繼環境中的頁面以模擬流量。 這些頁面是使用爬蟲找到的。

虛擬使用者 virtual-users

Cloud Manager會根據​ 企業所有者 ​角色所設定的KPI （回應時間和每分鐘的頁面檢視次數），建立虛擬使用者或容器。 這些 KPI 在建立或編輯程式時便已設定。

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

編目程式 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和Adobe格式。

若未上傳任何影像，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 中。