資料結構
網路
關係資料庫管理系統（RDBMS）
作業系統
Java
MS Excel
iOS
HTML
CSS
Android
Python
C 程式設計
C++
C#
MongoDB
MySQL
Javascript
PHP
物理學
化學
生物學
數學
英語
經濟學
心理學
社會學
服裝設計
法律研究估算技術指南（軟體測試）
對於任何專案的完成，測試的估算和正確的執行與開發週期一樣重要。為了與客戶建立良好的聲譽，堅持估算經驗在估算“軟體測試工作量”方面起著重要作用。參與各種專案有助於我們對測試周期進行準確的估算。
顯然，人們不能簡單地為任何測試活動輸入幾天的時間。測試估算應該既實用又精確。
本文將介紹一些重要的提示，這些提示對於以非常直接的方法準備適當的測試估算非常有用。
測試估算的過程
它是找出估計值或近似值的過程，這是一個可能用於某些目的的數字，即使輸入資料不完整、模糊或不穩定。[來源：維基百科]
作為專業人士，我們都會遇到各種工作、義務和截止日期；如今，有兩種方法可以解決問題。
第一種方法是反應性策略，在這種策略中，我們只在問題發生後才嘗試尋找解決方案。
在第二種方法中，稱為主動方法，我們首先在問題出現之前很久就利用我們以前的經驗做好準備，然後我們利用過去的經驗來嘗試在問題出現時找到解決方案。
因此，可以將估算視為在對問題採取主動方法時使用的一種方法。
因此，可以使用估算來估算完成特定工作需要多少時間和金錢方面的努力。一旦測試團隊對眼前的問題有了近似瞭解，他們就能更容易地提出一個最適合當前情況的解決方案。
因此，可以更正式地將估算定義為對勞動成本的可能近似值
先決條件基礎
以下是測試估算過程的基本要素。
從以往經驗中獲得的見解：通常最好花一些時間反思以前遇到過類似於當前問題的困難的專案。
可訪問的文件或工件：在這種情況下，測試管理儲存庫解決方案很有用，因為它們儲存了需求和澄清文件。測試團隊可以參考這些文件來正確描述專案的範圍。
關於工作性質的假設：以前的工作經驗有助於建立專案假設。在這種情況下，聘用經驗豐富的專家至關重要。測試經理可以選擇這些人來進行頭腦風暴，以產生所需的結果。
潛在危險和威脅的計算：測試團隊還必須設想團隊將來可能面臨的潛在風險、威脅和陷阱。
確定文件是否已建立基線：測試團隊還必須評估需求是否已建立基線。如果文件尚未建立基線，則必須確定更改的頻率。
所有職責和依賴關係都必須明確定義 - 組織必須確定所有將進行估算過程的人員的角色和責任。
評估記錄的文件並遵循：所有與估算過程相關的資訊都應記錄下來。
在測試估算過程中要完成的任務 -
組建一個團隊來進行估算。
將專案分解為專案階段和組成活動。
根據以前的專案和專業知識進行估算。
確定潛在的風險並制定策略來最大程度地降低這些風險。
檢查並記錄工作的相關部分。
將工作傳送給相應的利益相關者。
最流行的測試估算技術
一些最重要的測試估算方法包括 -
- 測試點的估算
- 基於工作階段的估算
- 利用用例點估算
我們在哪裡以及如何使用這些技術？
測試點估算是一種基本且易於理解的估算方法，廣泛應用於軟體測試行業。這種方法最重要的特徵是其迭代階段和簡單性。
基於工作階段的估算是一種估算方法，在這種方法中，對某個階段（通常是最短和最簡單的階段）進行粗略估算，然後測試團隊逐漸將其他階段新增到原始估算中，以達到可接受的估算。
用例點估算方法用於使用未調整的參與者權重和未調整的用例權重來估算用例上的軟體測試。
測試估算示例
讓我們嘗試在另一種情況下使用上述概念。
假設我們有一個測試需求，需要測試五個測試場景。
假設測試場景 1 有 5 個預期結果，測試場景 2 有 6 個測試預期結果，測試場景 3 只有 2 個測試預期結果，測試場景 4 有 9 個測試預期結果，測試場景 5 同樣有 9 個測試預期結果。
根據每個場景中預期結果的總數，我們將測試場景分為三個類別：困難、簡單和中等。
複雜類將具有超過 7 個預期結果，而基本類將具有少於 5 個預期結果，中間情況將具有 4 到 7 個預期結果。
因此，我們將測試場景 1 和 2 分類為中等，場景 5 和 6 分類為困難，測試場景 3 分類為基本。
現在所有這些場景都將進行測試點估算。我們對複雜類使用了 5 個測試點，對中等類使用了 3 個測試點，對基本情況使用了 2 個測試點。
在每個測試場景中，我們將假設的測試點乘以預期結果的總數。因此，我們得出以下近似值 -
場景 1：3 個測試點 * 5 個預期測試結果 = 25 個調整後的測試點
場景 2：3 個測試點 * 6 個預期測試結果 = 30 個調整後的測試點
場景 3：2 個測試點 * 2 個預期測試結果 = 4 個調整後的測試點
場景 4：5 個測試點 * 9 個預期測試結果 = 45 個調整後的測試點
場景 5：5 個測試點 * 9 個預期測試結果 = 45 個調整後的測試點
因此，假設我們需要為每個修改後的測試點申請 5 個工時，我們得到以下近似值。
測試場景 1：25 個修改後的測試點乘以 5 個工時為 125 個工時。
場景 2：30 個修改後的測試點乘以 5 個工時等於 150 個工時。
場景 3：4 個修改後的測試點 * 5 個工時等於 20 個工時
場景 4：45 個調整後的測試點乘以 5 個工時為 225 個工時。
場景 5：45 個調整後的測試點乘以 5 個工時為 225 個工時。
因此，估計的總工時為：745 個工時
用例點估算方法
這裡給出了用例點估算過程的詳細過程 -
將通用需求分解為用例，更準確地說是分解為參與者
計算所有用例中使用的用例參與者的總數
根據用例參與者數量將需求分類為負面、正面和例外
根據每個用例參與者的類別為每個用例參與者分配一個未處理的參與者權重
重複此過程，直到我們獲得所有參與者的未處理參與者權重
使用未調整的用例權重和未調整的參與者權重獲得未處理的用例點
將未處理的用例點乘以預定義的常數以獲得真實的用例點估算
例如，在某個需求中，我們有 5 個用例，用例 1、用例 2 和用例 5。假設用例 1 有 6 個參與者，用例 2 有 15 個參與者，用例 3、4 和 5 分別有 3 個、4 個和 5 個參與者。
任何參與者總數少於 5 的用例都被視為負面用例，任何參與者總數等於或大於 5 且小於或等於 10 的用例都被視為正面用例，任何參與者總數超過 10 的用例都被視為例外用例。
我們選擇為例外用例分配 2 分，為正面用例分配 1 分，為負面用例分配 1 分。
根據我們的假設，我們將用例 1 和 5 分類為正面，用例 2 分類為例外，用例 3 和 4 分類為負面。
因此，未處理的參與者權重 = 用例 1 =（參與者總數）5 * 1（分配的點數）= 5。類似地
案例 2 = 15 * 2 = 30。
對其餘用例重複此過程，得到未處理的參與者權重 = 33。
未處理的用例權重 = 用例總數乘以 5
未處理的用例點數 = 未調整的參與者權重加上未調整的用例權重 = 33 + 5 = 38
處理後的用例點數 = 38 * [0.65 + (0.01 * 50] = 26.7 或大約 28 人時
工作階段分解法
工作階段分解法在以下階段進行解釋。
將整個專案劃分為多個階段。
從最簡單的步驟開始，併為其提供一個估算值。
然後，在完成此階段後，確定可能開始的下一個潛在步驟。
確定可能應用於此階段的一組潛在近似值，並從近似值列表中選擇最大值。
將當前階段的工時估算值新增到先前存在的估算值中，以獲得近似估算值。
重複步驟 3-5，直到第一步中指示的所有階段都已完成。
接受最終的近似估算值作為最終結果。
假設一個需求中有五個必要的階段。在第一階段，我們假設所需的總工作量為 35 人時，然後我們繼續進入第二階段，在第二階段我們有四個比較假設分別為 35、45、55 和 65。
這裡我們考慮最大值 65 人時。階段 3 和 4 的估算分別為 (12, 33, 43, 54)、(15, 10, 7, 8) 和 (2, 16, 5, 13)。使用上述概念，我們得到 185 人時。
結論
軟體測試估算需要熟練專家的參與，以及使用行業最佳實踐，例如測試用例點數和用例點數技術。
在定製必要的程式時，保持開放的心態也至關重要。有效地應用這些程式可以提高整個測試過程。
160 次檢視
