驗證與確認示例
在軟體測試中,驗證和確認有什麼區別?
術語“驗證”和“確認”經常在測試環境中使用。大多數情況下,我們會錯誤地混淆這兩個詞,儘管它們實際上截然不同。
V&V(驗證與確認)任務分為兩類:
符合規範(生產者對質量的看法)
適合使用(消費者對質量的看法)
簡而言之,開發人員對完成產品的印象被稱為**生產者對質量的看法**。
使用者對完成產品的看法被稱為**消費者對質量的感知**。
在執行V&V任務時,我們必須牢記這兩種質量視角。
讓我們首先定義驗證和確認,然後我們將看一些例子來幫助我們理解這些詞。
**注意** - 這些定義來自QAI的CSTE CBOK(檢視此連結以瞭解更多關於CSTE的資訊)。
什麼是驗證以及它是如何工作的?
驗證是審查軟體開發生命週期中的中間工作產品以確保我們正朝著完成最終結果的方向前進的過程。
換句話說,驗證是評估軟體中間產品以檢視它們是否滿足在階段開始時設定的要求的過程。
現在的問題是,什麼是 *確切的* 中間產品?
這些可能包括文件,例如需求規格說明、設計文件、資料庫表設計、ER圖、測試用例、可追溯性矩陣等等,這些文件是在開發階段建立的。
我們經常忽略審查這些文件的必要性,但我們應該記住,審查可能會發現許多隱藏的缺陷,如果在開發週期的後期發現或解決這些缺陷,可能會非常昂貴。
驗證使用審查或非可執行技術來確保系統(軟體、硬體、文件和人員)符合組織的標準和程式。
驗證發生在哪裡?
以下是IT專案中進行驗證的一些領域(我必須強調這不是一個詳盡的列表)。
| 驗證情況 | 參與者 | 定義 | 輸出 |
|---|---|---|---|
| 業務/功能需求 | 與開發團隊和客戶一起審查業務需求。 | 這是一個關鍵步驟,以確保需求已被獲取和/或準確,以及確定它們是否現實。 | 這些需求已最終確定,並準備被下一個階段——設計所採用。 |
| 設計評審 | 開發團隊 | 設計建立後,開發團隊會對其進行全面評估,以確保可以使用所呈現的設計滿足功能需求。 | 該設計已準備好整合到IT系統中。 |
| 程式碼走查 | 個體開發者 | 程式碼編寫後,會檢查是否存在任何語法錯誤。這是一項更非正式的任務,由個體開發人員對其自己的程式碼執行。 | 現在可以使用此程式碼進行單元測試。 |
| 程式碼審查 | 開發團隊 | 這是一個更正式的配置。主題專家和開發人員審查程式碼,以確保它符合軟體的商業和功能目標。 | 該程式碼現在可用於測試。 |
| 測試計劃評審(QA團隊內部) | QA團隊 | QA團隊內部審查測試計劃,以確保其正確且全面。 | 可以與其他團隊(專案管理、業務分析、開發、環境、客戶等)共享的測試計劃文件。 |
| 測試計劃(外部) | 專案經理、業務分析師和開發人員 | 對測試計劃文件進行正式審查,以確保QA團隊的時間表和其他因素與其他團隊和整個專案保持同步。 | 簽署或授權的測試計劃文件將用於執行測試活動。 |
| 測試文件評審 | QA團隊 | 同行評審是指團隊成員互相檢查彼此的工作,以確保文件中沒有錯誤。 | 測試文件已完成,並準備與其他團隊共享。 |
| 測試文件最終評審 | 業務分析師和開發團隊 | 審查測試文件,以確保測試用例涵蓋了系統的所有業務情況和功能特性。 | 測試文件已完成並準備執行。 |
什麼是確認以及它是如何工作的?
確認是評估完成的產品以檢視它是否符合業務需求的過程。換句話說,我們每天進行的測試執行本質上是一項確認活動,包括冒煙測試、功能測試、迴歸測試、系統測試等等。
確認包括所有型別的測試,這些測試都包含與產品互動並對其進行測試。
以下是確認程式:
- 單元測試
- 整合測試
- 系統測試
- 使用者驗收測試
確認透過執行一系列可以檢視和評估的測試來驗證系統是否遵循計劃。
驗證和確認的例子
現實生活中考慮這種情況:你去餐館點藍莓煎餅。當服務員端上食物時,你如何確定端上來的食物是你點的嗎?
當我們看它的時候,首先注意到的是:
- 食物是你期望煎餅的樣子嗎?
- 周圍有藍莓嗎?
- 它們有正確的味道嗎?
可能更多,但你明白了。
另一方面,如果你需要確定這道菜正是你預期的,你必須吃它。
當你還沒有吃,但想透過回顧主題來仔細檢查一些事情時,驗證是可行的方法。當你驗證產品時,你實際上會食用它以驗證它是否正確。
開發過程各個階段的V&V
在開發生命週期的每個步驟中,都會進行驗證和確認。
讓我們仔細看看它們。
V和V任務 - 計劃階段
- 合同驗證。
- 概念文件評估。
- 進行風險評估
需求階段 – V & V任務
- 評估軟體需求。
- 評估和分析介面。
- 建立系統測試計劃。
- 建立驗收測試策略。
設計階段V&V任務
- 軟體設計評估。
- 介面(UI)的評估/分析。
- 建立整合測試計劃。
- 建立元件測試計劃。
- 建立測試設計。
V&V任務 - 實現階段
- 原始碼評估。
- 文件評估。
- 建立測試用例。
- 建立測試過程。
- 執行元件測試用例。
V&V任務 - 測試階段
- 執行系統測試用例。
- 執行驗收測試用例。
- 更新可追溯性指標。
- 風險評估
V&V任務 - 安裝和檢查階段
- 安裝和配置稽核。
- 安裝候選版本的最終測試。
- 建立最終測試報告。
V&V任務 - 操作階段
- 評估新的約束條件。
- 評估擬議的修改。
V&V任務 - 維護階段
- 評估異常情況。
- 遷移評估。
- 評估重試特性。
- 評估擬議的修改
- 驗證生產中的問題。
確認和驗證的區別
| 驗證 | 確認 |
|---|---|
| 檢查中間產品以檢視它們是否滿足該階段的特定要求。 | 檢查最終產品以檢視它是否滿足公司的要求。 |
| 檢查產品是否根據要求和設計規範構建。 | 它評估軟體是否適合使用並滿足公司的要求。 |
| 檢查“我們是否正在正確地建立產品?”。 | 檢查“我們是否正在開發正確的產品?”。 |
| 這是在不執行程式的情況下完成的。 | 透過軟體的執行完成。 |
| 包括所有靜態測試方法。 | 包括所有動態測試方法。 |
| 審查、檢查和走查只是一些例子。 | 各種測試,例如冒煙測試、迴歸測試、功能測試、系統測試和UAT,都是例子。 |
何時應該使用驗證和確認?
這些是獨立的流程,應該協同使用,以確保系統或應用程式滿足要求和規範,並實現其預期目的。兩者都是質量管理體系的關鍵要素。
產品透過驗證步驟但未能透過驗證階段的情況並不少見。然而,儘管它滿足了書面的標準和規範,但這些標準卻無法滿足使用者的需求。因此,必須對這兩個類別進行測試,以確保整體質量。
在開發、規模化或生產中,驗證可以用作內部程式。另一方面,驗證應作為外部程式使用,以獲得利益相關者對適用性的批准。
使用者驗收測試 (UAT) 是驗證還是確認?
驗證應包括 UAT(使用者驗收測試)。它是系統或應用程式的現實世界驗證,由實際使用者執行,以確定系統是否“適用”。
結論
V&V 流程評估特定活動的產品是否符合標準並適合其預期用途。
最後,需要記住以下幾點:
為避免任何誤解,請記住,驗證是指審查活動或靜態測試方法,而驗證是指實際測試執行活動或動態測試方法。
驗證過程中可以使用或不使用產品。驗證肯定需要產品。有時可以在反映最終系統的文件上進行驗證。
測試人員不必完成所有驗證和確認工作。正如本文前面提到的,其中一些工作由開發人員和其他團隊處理。
資料結構
網路
關係資料庫管理系統 (RDBMS)
作業系統
Java
iOS
HTML
CSS
Android
Python
C語言程式設計
C++
C#
MongoDB
MySQL
Javascript
PHP