資料結構
網路
關係資料庫管理系統 (RDBMS)
作業系統
Java
MS Excel
iOS
HTML
CSS
Android
Python
C語言程式設計
C++
C#
MongoDB
MySQL
Javascript
PHP
物理學
化學
生物學
數學
英語
經濟學
心理學
社會學
時尚研究
法學研究什麼是使用者驗收測試 (UAT)？
什麼是使用者驗收測試以及它是如何工作的？
測試是眾所周知的，而驗收表示批准或同意。在軟體產品的背景下，使用者要麼是程式的消費者，要麼是要求為其製作程式的人（客戶）。
使用者驗收測試 (UAT)，通常稱為 Beta 測試或終端使用者評估，是使用者或客戶測試軟體以檢視是否可以接受的過程。這是在完成功能測試、系統測試和迴歸測試後的最後階段的測試。
此測試的主要目標是確保軟體滿足公司的需求。需要熟悉業務需求的終端使用者來進行此驗證。
何時執行？
這通常是產品上線之前或產品獲准分發之前的最後階段。在產品經過廣泛測試後進行此操作（即系統測試之後）。
誰負責 UAT？
使用者或客戶——這可能是購買產品的人（對於商業軟體而言），也可能是讓軟體服務提供商定製軟體的人，或者如果程式提前提供給終端使用者並請求他們的意見，則是終端使用者。
團隊可能由 Beta 測試人員組成，或者客戶可以選擇公司內部的 UAT 成員，以確保徹底測試每一個使用者角色。
需要使用者驗收測試
開發人員和功能測試人員是確保程式滿足功能需求的技術人員。他們利用他們的專業知識來理解需求並開發/測試程式（這就是領域知識的重要性）。
儘管此程式符合功能要求，但仍會忽略或誤讀許多隻有終端使用者才能理解的業務需求和流程。
此測試對於確定在程式釋出供一般使用之前是否已滿足所有業務標準至關重要。此測試是釋出週期中必不可少的組成部分，因為它使用實際資料和實際用例。
許多因釋出後問題而遭受重大損失的公司都瞭解成功的使用者驗收測試的價值。釋出後解決缺陷的成本是釋出前修復缺陷成本的幾倍。
使用者驗收測試流程
理解此流程的最佳方法是將其視為一個獨立的測試專案，包括規劃、設計和執行階段。
在開始規劃階段之前，必須滿足以下先決條件：
1. 編譯最重要的驗收標準列表
簡單來說，驗收標準是在接受產品之前將要評估的專案列表。
這有兩種型別：
應用程式的功能或與業務相關的問題——理想情況下，將測試每個關鍵業務功能，但由於各種因素（包括時間限制），這是不可行的。因此，與將參與測試的客戶或使用者進行一兩次會議可能會讓我們瞭解將進行多少測試以及將檢查哪些部分。
合同的——我們不會討論這個，QA 團隊在此中的作用很小。評估最初的合同（在 SDLC 開始之前寫出），並決定是否已履行合同的所有組成部分。
我們將只關注應用程式的功能。
2. 定義質量保證參與的範圍
QA 團隊的工作是以下之一：
不參與——這非常罕見。
協助測試——這是最常見的選擇。在這種情況下，我們的參與可能包括教 UAT 使用者如何使用應用程式，並在整個測試過程中隨時待命，以確保我們可以在使用者遇到任何問題時提供幫助。在其他情況下，除了待命和提供幫助外，我們還可以共享他們的回覆並記錄結果、記錄問題等等，而使用者則執行實際測試。
進行 UAT 並交付結果——在這種情況下，使用者將指示他們希望檢查 AUT 的哪些方面，而 QA 團隊將進行評估。然後將結果提供給客戶/使用者，他們必須決定他們擁有的結果是否足夠並滿足他們的期望，以便採用 AUT。QA 團隊永遠不會做出最終決定。
我們根據具體情況選擇合適的方法。
規劃 UAT 測試
在系統階段，該過程幾乎與標準測試計劃相同。
在大多數專案中，最常見的方法是同時為系統和 UAT 測試階段做準備。有關更多資訊和 UAT 測試計劃示例，請參閱隨附的測試計劃文件中的 UAT 部分。
計劃使用者驗收測試
UAT 測試計劃包含日期、環境、參與者（誰）、溝通協議、角色和責任、模板、結果及其分析過程、進入退出標準以及其他重要內容。
我們有責任為這一階段做好準備，並確保一切都被考慮在內，無論 QA 團隊在此測試中是否完全參與、部分參與或根本不參與。
測試執行
如果可能，驗收測試會在會議室或作戰室環境中進行，使用者、專案經理和 QA 團隊成員都會聚在一起一兩天，並完成所有驗收測試用例。
如果 QA 團隊正在執行測試，我們將對 AUT 執行測試用例。
完成所有測試並收到結果後，將做出驗收決定。此決定也稱為“Go/No-Go”決定。如果消費者滿意，則為 Go；否則為 No-go。
此步驟通常以驗收決定結束。
方法和工具
通常，此測試階段使用的軟體工具與功能測試階段使用的軟體工具相同。
工具
因為此步驟涉及測試應用程式的整個端到端流程，所以使用單個工具來徹底自動化此驗證可能很成問題。但是，我們將能夠在一定程度上使用在系統測試期間構建的自動化指令碼。
使用者將像使用系統測試一樣使用測試管理和缺陷管理工具，例如 QC、JIRA 等。可以設定這些工具來收集使用者驗收階段的資訊。
方法
儘管傳統方法（例如專門的業務使用者對產品的 UAT）仍然適用，但在當今真正全球化的世界中，使用者驗收測試可能需要根據產品包含來自不同國家的各種消費者。
例如，來自世界各地的客戶可能會使用電子商務網站。在這種情況下，眾測將是最實用的方法。
眾測是一種方法，來自世界各地的人們可以參與並驗證產品的用途，同時還可以提供評論和建議。
許多公司已經構建並正在使用眾測系統。該平臺託管一個網站或一個需要進行眾測的產品，使用者可以自薦進行驗證。然後檢查並確定提供的輸入的優先順序。
眾測已被證明更有效，因為可以輕鬆瞭解世界各地客戶的脈搏。
敏捷環境中的 UAT
敏捷環境本質上更具動態性。在敏捷世界中，業務使用者將在整個專案衝刺中參與，並且專案將根據他們的反饋迴圈進行改進。
專案初期，主要利益相關者將是業務使用者，他們負責提供需求並更新產品待辦事項列表。業務使用者將在每個衝刺結束時參加衝刺演示，並準備好提供任何意見。
此外，在衝刺結束之前，將安排使用者驗收測試 (UAT) 階段，在此期間，業務使用者將進行驗證。
在衝刺演示和衝刺UAT期間獲得的輸入將被編譯並新增到產品待辦事項列表中，該列表將定期進行評估和優先順序排序。因此，在敏捷環境中，業務客戶更貼近專案，並更定期地審查其效用，這與傳統的瀑布式專案形成對比。
結論
使用者驗收測試並非針對網站、表單或按鈕。甚至在測試開始之前，我們都預設所有基本元件都經過徹底檢查並且執行良好。如果人們發現像這樣的簡單缺陷，這對QA團隊來說是個壞訊息。
此測試的重點是作為業務最重要組成部分的實體。
UAT 本質上是一種測試，這意味著在此階段也極有可能發現一些缺陷。這種情況時有發生。除了給QA團隊帶來巨大的升級壓力外，UAT問題通常需要召開會議來討論如何解決，因為在此測試之後通常沒有時間進行糾正和重新測試。
676 次瀏覽
