定義測試案例

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

使用案例

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

詳細需求規格

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

測試應明確定義：

• 先決條件；這些可能涵蓋特定系統、組態或測試者的使用經驗。
• 應採取的步驟；以適當的細節。
• 預期結果。
• 清除通過或失敗的標準。

自動化測試案例的前景顯然十分誘人，因為它可以消除重複性任務。

手動測試與自動測試

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

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

測試特定方面

在測試AEM時，會特別關注一些特定細節：

作者和發佈環境

雖然Environments中涵蓋了AEM在測試方面的決定性因素，但值得強調。

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

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

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

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

• 用於不同的用途
• 在功能和效能方面有不同的要求
• 以不同的方式設定
• 分別調諧
• 每個人都有自己的一套驗收測試

換言之，它們必須個別測試，並使用不同的測試案例。

個性化

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

此外，還必須檢查快取是否正確行為。

The Dispatcher

大多數項目將安裝Dispatcher以進行快取和負載平衡。

測試十分困難（快取會在不同層級和不同位置進行），而且必須使用黑匣子進行。 測試的主要方面包括：

• 確
  保網站訪客可檢視內容更新。

• 繼
  續確保當一台伺服器關閉時，網站仍然可用。

• Clusters
  Clusters用於提供：

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

  • PerformanceLoad
    平衡與完全故障切換可提高群集的效能。當用於客戶項目時，必須測試群集以確認配置的正確操作。

測試協力廠商軟體

所有與AEM介接的協力廠商軟體，都將在詳細需求規格中加以參考。

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