定義您的測試案例

您的測試案例應以下列項目為基礎：

使用案例

• 這些功能在行為者（啟動某些動作的角色）與系統之間的互動中定義了所需的功能。
• 使用案例應由客戶定義。

詳細需求規格

• 應測試所有功能和效能要求。

測試應明確界定：

• 先決條件；這些內容可能涵蓋特定系統、配置或測試體驗。
• 應採取的步驟；詳細程度。
• 預期結果。
• 清除通過或失敗的標準。

自動化測試用例的前景顯然很有吸引力，因為它可以消除重複性任務。

手動測試與自動測試

不過，自動化測試案例是一項重大投資，因此應考慮某些方面：

• 設定和設定需要時間、精力和體驗。
• 如果以瀏覽器為基礎，則安裝瀏覽器更新時，問題的風險會增加；需要更多時間來修正。
• 只有大項目才真正可行。
• 當為測試或長期發行計畫產生多個發行時即適用。

測試特定方面

在測試AEM時，需特別注意一些特定詳細資訊：

製作和發佈環境

不過，在Environments中，值得強調AEM在測試方面的決定因素。

您必須將AEM視為兩個應用程式：

• 作者環境
  此例項可讓作者輸入及發佈內容。
  這有一小組(er)可預測的用戶，對於這些用戶，特定功能和效能至關重要。

• 發佈環境
  此例項以發佈的形式呈現網站，供訪客存取。
  這通常會有較大的使用者集，其中流量並不總是100%可預測。 效能仍至關重要 — 在回應請求時。 還必須考慮快取和負載平衡。

雖然軟體與此相同，但它們：

• 不同用途
• 對功能和效能有不同的要求
• 設定不同
• 單獨調諧
• 每人都有自己的一套驗收測試

換句話說，它們必須分別測試，並搭配不同的測試案例。

個性化

測試個人化時，應使用多個使用者帳戶重複每個個別使用案例，以證明行為。

還必須檢查快取以檢查正確行為。

Dispatcher

大部分的專案都會安裝Dispatcher以進行快取和負載平衡。

測試很困難（快取會發生在不同層級和不同位置），且必須使用黑盒機制。 要測試的關鍵方面包括：

• ​
  請務必確保網站訪客看到內容更新。

• ​
  持續確保一個伺服器關閉時該網站仍然可用。

• ​
  ClustersClusters用於提供：

  • ​
    故障轉移如果一台伺服器出現故障，群集中的其他伺服器將接管處理。

  • ​
    採用完全故障轉移的效能負載平衡提高了群集的效能。當用於客戶項目時，必須測試群集以確認配置的正確操作。

測試第三方軟體

任何與AEM介面的第三方軟體都將在詳細需求規格中參考。

必須分析所需的任何測試（取決於定義的範圍）並獲得乾淨的測試。