資料結構
網路
關係型資料庫管理系統
作業系統
Java
MS Excel
iOS
HTML
CSS
Android
Python
C 程式設計
C++
C#
MongoDB
MySQL
Javascript
PHP
物理學
化學
生物學
數學
英語
經濟學
心理學
社會學
時尚研究
法律研究端到端測試教程：什麼是 E2E 測試以及示例
端到端測試
端到端測試是一種軟體測試方法，它從頭到尾驗證整個軟體，包括其與外部介面的互動。端到端測試檢查整個軟體的依賴關係、資料完整性和與其他系統、介面和資料庫的連線性，以模擬完整的生產環境。
除了軟體系統之外，它還檢查來自各種上游/下游系統的批處理/資料處理。因此，創造了“端到端”一詞。端到端測試通常在完成功能測試和系統測試之後進行。它透過使用真實世界的資料和測試環境來模擬即時條件。端到端測試的另一個名稱是鏈式測試。
端到端測試的目的是什麼？
端到端測試評估整個系統流程並透過發現錯誤和提高子系統測試覆蓋率來增強信心。現代軟體系統複雜且相互關聯，具有各種子系統，這些子系統可能與當今使用的子系統不同。任何子系統的故障都可能導致整個系統崩潰，這是一個可以透過端到端測試避免的重大風險。
端到端測試流程
下圖顯示了端到端測試過程。
需求 -
需求捕獲
文件編制
E2E 設計 -
元件設計
E2E 設計
元件設計 -
元件設計和測試
開發 -
開發編碼和設計
E2E 測試 -
端到端設定的環境設定
測試設計和執行
端到端測試中涉及的操作
以下是端到端測試中涉及的主要操作：
對端到端測試需求的審查
配置測試環境和硬體/軟體需求
描述所有系統及其子系統的流程。
描述所有系統的角色和職責。
測試的方法和標準
端到端需求跟蹤和測試用例設計
每個系統的輸入和輸出資料
開發端到端測試用例的最佳方法是什麼？
端到端測試設計框架包含三個方面。
建立使用者定義函式
構建條件
建立測試用例
讓我們仔細看看它們：
構建使用者函式
作為構建使用者函式的一部分，應完成以下操作
列出系統特性及其關聯元件。
對於每個特性或功能，列出輸入資料、操作和輸出資料。
確定函式之間的相互關係。
確定函式是可重用還是獨立的。
考慮以下場景：您登入您的銀行賬戶，並將資金從另一個銀行賬戶轉到您自己的賬戶（第三方子系統）
要使用銀行系統，您必須首先登入。
檢查賬戶餘額以檢視賬戶中剩餘多少資金。
將資金從您的賬戶轉到另一個銀行賬戶（第三方子系統）
檢查您最新的賬戶餘額。
關閉應用程式。
根據使用者的角色建立條件。
作為構建條件的一部分，執行以下操作：
為每個定義的使用者函式建立一組標準
條件的示例包括順序、時間和資料條件。
檢查其他標準，例如：
登入頁面
密碼和使用者名稱均無效。
驗證登入名和密碼
檢查密碼強度
錯誤訊息檢查
餘額
24 小時後檢查當前餘額。（如果轉賬到另一個銀行）
如果轉賬金額大於現有餘額，則查詢錯誤通知。
構建測試場景
為指定的使用者函式建立測試場景
在這種情況下，
在系統中註冊。
檢查您的銀行賬戶餘額。
將資金轉到您的銀行賬戶。
建立多個測試場景
為每個場景建立一個或多個測試用例。每個條件都可能包含在單獨的測試用例中。
端到端測試指標
下面列出的指標只是端到端測試中使用的眾多指標中的一小部分。
**測試用例準備狀態** - 它顯示測試用例準備的進度與計劃相比。
**每週測試進度** - 顯示每週測試完成百分比，包括針對計劃執行測試的失敗、未執行和已完成。
**故障狀態和詳細資訊** - 此報告顯示每週開放和關閉缺陷的百分比。此外，根據嚴重性和優先順序每週故障分佈
**環境可用性** - 每天“正常執行”的小時總數 / 計劃測試的小時總數
系統測試與端到端測試
下表重點介紹了系統測試和端到端測試之間的主要區別：
| 端到端測試 | 系統測試 |
|---|---|
| 驗證軟體系統及其關聯子系統。 | 僅根據標準驗證軟體系統。 |
| 它檢查從頭到尾的整個流程。 | 它檢查系統的功能和特性。 |
| 將測試所有使用者介面和後端系統。 | 測試將包括功能測試和非功能測試。 |
| 它在完成系統測試後執行。 | 它在以下整合測試之後進行。 |
| 外部介面可能是難以自動化的端到端測試的一部分。因此，手動測試是首選。 | 系統測試可以手動或自動執行。 |
E2E 測試有多種形式
手動 E2E 測試和自動化 E2E 測試是兩種基本形式。
為了評估是否符合應用程式要求，業務測試人員會假裝自己是使用者（在他可以訪問的儘可能多的裝置和螢幕尺寸上）。例如，從電子商務商店購買商品。
測試人員將像普通使用者一樣購買產品：點選“新增到購物車”按鈕，開啟購物車，繼續到購買介面並付款。
測試人員的目標是檢視流程的任何步驟是否已損壞。
自動化 E2E 測試具有相同的目的。只是自動化測試提供了人類測試人員可能無法提供的更高階的功能。各種測試自動化系統提供自動化測試服務以及可以進行測試的各種裝置（稱為“裝置實驗室”）。
自動化測試與手動測試
如前所述，手動測試涉及測試人員手動執行測試。人為錯誤可能導致測試不佳。在自動化測試中，測試會自動進行。因此，在許多情況下，自動化測試可能更準確。
手動測試更容易設定和理解。自動化測試通常難以設定。自動化測試通常具有更陡峭的學習曲線。
手動測試需要較低的初始成本和資源投入。雖然自動化測試需要更高的初始成本，但隨著測試流程的增長和發展，它會帶來巨大的投資回報。因此，在選擇自動化測試解決方案時需要考慮這一點。
透過手動測試更容易重現生產環境。但是，某些自動化技術使該過程變得更加困難。在功能之前手動檢查是否滿足某些要求很容易，但是自動化測試方法可能難以設定。
E2E 測試清單
因為使用者介面由許多元素組成，所以 E2E 不僅限於測試使用者介面。
對於部落格網站，可以使用 API 從資料庫中訪問內容。在這種情況下，很明顯，前端設計、資料庫和 API 都必須獨立且聯合地進行測試。
在 E2E 測試期間應遵循的清單如下：
**資料庫** - 您需要測試系統正在使用的資料庫。您可以執行測試以檢查資料是否正確儲存、結構化、讀取和更新。
**效能** - 雖然網頁可能導航良好，但使用者體驗受其速度影響。因此，評估頁面或功能的效能至關重要。
**安全** - Web 應用程式的安全級別決定了它對使用者和公司的安全性。在這種情況下，漏洞測試工具非常關鍵。
**功能** - 測試的首要目的是確保產品正常工作。所有功能都必須按預期工作。單元測試也可以在這種情況下使用。
**可用性** - 元件應該是可用的，因為它們正在執行。使用者與工具一樣重要，因此測試必須包括專案上的事件（例如點選）以及正確的導航。
E2E 測試示例
在此示例中，我們將使用 Perfecto Scriptless（一個可用於端到端介面測試的無程式碼測試平臺）來測試 Twitter 登入流程。
在我們開始構建測試之前，讓我們建立一個測試流程。
訪問 twitter.com 瞭解更多資訊。
要登入，請點選登入按鈕。
如果任何輸入為空，請確保登入按鈕不執行任何操作。
當輸入不為空時，透過點選按鈕提交詳細資訊（我們將使用錯誤資訊進行測試）。
錯誤提示顯示“您提供的使用者名稱和密碼與我們的記錄不匹配”。請仔細檢查您的輸入，然後重試。）以紅色顯示。
測試應儲存。
如果憑據正確，使用者將被髮送到其帳戶（這可以是另一個測試）。
結論
端到端測試是在軟體工程中檢查軟體系統及其子系統的過程。此測試最困難的部分是需要對整個系統以及相關子系統有足夠的瞭解。
1K+ 次檢視
