定義測試案例 defining-your-test-cases

您的測試案例應該以下列專案為基礎:

使用案例

  • 這些會根據參與者(啟動特定動作的角色)與系統之間的互動來定義所需的功能。
  • 使用案例應由客戶定義。

詳細需求規格

  • 所有功能和效能需求都應進行測試。

測試應清楚定義:

  • 先決條件;這些可能涵蓋特定系統、設定或測試者體驗。
  • 需遵循的步驟;以適當的詳細資訊層級。
  • 預期結果。
  • 清除通過或失敗的准則。

自動化測試案例的前景很有吸引力,因為它消除了重複性的工作。

手動與自動化測試 manual-versus-automated-tests

然而,自動化測試案例是一項相當可觀的投資,因此需考量以下特定方面:

  • 設定和設定需要時間、精力和經驗。
  • 如果是基於瀏覽器,安裝瀏覽器更新時問題的風險會增加;需要更多時間才能更正。
  • 僅適用於大型專案。
  • 當針對測試或長期發行計畫產生多個發行時良好。

測試特定方面 testing-specific-aspects

在測試AEM時,有一些特別令人感興趣的特定細節:

作者和Publish環境

雖然環境已涵蓋這些環境,但值得強調的是AEM在測試方面的決定性因素。

將AEM視為兩個應用程式:

  • 作者 環境
    此例項可讓作者輸入及發佈內容。
    這擁有一小部分可預測的使用者,對他們來說,特定的功能和效能至關重要。

  • Publish 環境
    此執行個體會以已發佈的形式顯示網站,以供訪客存取。
    這通常會有較大型的使用者集,其流量並非總是100%可預測。 效能仍然至關重要 — 在回應請求時。 也請考量快取和負載平衡。

雖然是相同的軟體,但它們:

  • 用途不同
  • 功能與效能需求不同
  • 的設定方式不同
  • 已分別調整
  • 每個都有各自的驗收測試集

換言之,這些模組必須分別測試,並使用不同的測試案例。

Personalization

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

同時檢查快取是否有正確行為。

Dispatcher

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

測試很困難(快取會在不同的層級和位置進行),因此必須以黑匣子方式進行。 要測試的主要方面為:

  • 準確度
    確保網站訪客可看見內容更新。

  • 連續性
    請確定當伺服器關閉時,網站仍然可用。

  • 個叢集
    用於提供下列專案:

    • 容錯移轉
      如果一個伺服器發生故障,則叢集中的其他伺服器將會接管處理作業。

    • 效能
      使用完整容錯移轉的負載平衡可提升叢集的效能。
      用於客戶專案時,必須測試叢集以確認設定的正確操作。

測試協力廠商軟體 testing-third-party-software

任何連線至AEM的協力廠商軟體,均可在「詳細需求規格」中參照。

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

recommendation-more-help
19ffd973-7af2-44d0-84b5-d547b0dffee2