定義測試案例 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