定義測試案例

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

使用案例

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

詳細需求規格

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

測試應明確定義:

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

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

手動測試與自動測試

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

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

測試特定方面

在測試AEM時,會特別關注一些特定細節:

作者和發佈環境

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

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

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

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

雖然軟體與之相同,但它們:

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

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

個性化

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

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

The Dispatcher

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

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


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


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


  • ClustersClusters用於提供:


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

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

測試協力廠商軟體

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

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

本頁內容