定義您的測試案例

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

使用案例

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

詳細需求規格

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

測試應明確界定:

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

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

手動測試與自動測試

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

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

測試特定方面

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

製作和發佈環境

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

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

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

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

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

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

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

個性化

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

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

Dispatcher

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

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


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


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


  • ClustersClusters用於提供:


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


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

測試第三方軟體

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

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

本頁內容