1. 程式人生 > >測試工作量的評估方法

測試工作量的評估方法

緊急 實現 類型 margin 自己 版本 不同 效率 例如

測試排期是整個測試過程非常重要的環節,關乎項目整體的上線計劃及版本節奏。測試排期首先要評估測試的工作量。所以測試工作量評估的越準確,對項目整體節奏的把握更有利。 工作量評估得過多影響上線節奏,人員工作強度變低影響效率,工作量評估過少,造成的影響更大,如果可以通過加班消化還好,如果消化不了項目會延期,錯過活動等等,對測試口碑的影響將是毀滅性的。尤其是一些緊急的需求,要求快速上線,更有可能開發的改動方案要參考測試的工作量,如果測試回歸工作量過大,為了滿足上線要求開發有可能會更換開發方案。此時如果測試工作量評估不準,開發方案的選擇就會發生變差,對上線的影響就會更大。

實際項目測試中,工作量評估會受很多因素的影響,開發的實現方案,開發的能力水平,測試範圍的評估,測試類型的選擇,測試深度,是否需要增加專項測試,質量要求,等都會產生幹擾,因此準確評估工作量確實很難。

尤其是當功能還沒有開發的時候去評估工作量,不確定性更大,開發是重構代碼還是微調,是否需要做性能評測等等都會對最終工作量評估產生很大影響。

那麽怎麽做才能更加準確的評估測試工作量呢?

首先我們先要了解測試工作量都包含哪些部分,測試工作量是對測試過程時間消耗的評估,那麽測試過程都包含哪些呢? 我們可以從測試流程角度來分析,首先是需求理解,然後是和開發的技術溝通測試範圍評估,測試用例的編寫,專項測試方案準備,測試環境/測試數據準備,測試用例執行,專項測試執行,回歸用例執行,上報bug以及bug驗證,以及上線前的測試驗那麽測試工作量就應該是以上過程時間消耗的總和一眼望去,過程好多,每個過程貌似都又有不確定性,例如bug上報和驗證的時間直接受bug數量和開發修改bug改動大小的影響,用例執行不同功能的case執行時間可能又是不一樣的,萬一遇到阻塞問題,時間就更沒法評估了。

這些過程並不是每個版本都會。


接下來我們逐一來分析一下每個過程如何精準評估工作量:

需求理解

需求理解一般是通過需求文檔或需求討論會來完成,這個過程通常會比較提前,例如需求文檔都會提前發出事先可以去熟悉,工作量評估一般不包含這部分內容。

技術細節了解

技術細節的了解取決於了解的程度,這部分可能更多的需要根據以往的經驗來評估,所以平時對於技術細節了解時間的留意很重要。

用例設計

這部分應該會比較耗時,時間的評估首先要評估用例的數量,評估用例的數量首先要把測試對象按功能切分,再由功能切分成測試點,針對每個測試點去評估用例數量。優秀的測試工程師對每個測試點大概有多少條用例需要做到心中有數,例如測試一個按鈕的用例條數,下拉菜單的用例條數。這部分比較依賴平時的積累,能否把常見的測試點總結成公共用例,例如http的公共用例,地址欄公共用例,菜單的公共用例,如果公共用例比較齊備,會比較容易評估用例條數,而且也可以大大縮短用例設計的時間。用例設計過程中或多或少的會出現需求不清需要溝通確認,技術細節不了解需要溝通或調研的事情,這部分也需要根據之前的經驗來判斷。

專項測試方案設計

首先要評估是否需要進行專項測試,如果需要則要評估專項測試方案修改已有的還是要從頭來設計。 一般情況下一份專項測試方案設計時間不超過4h。如果涉及到工具的開發則需要另行評估。

測試環境/測試數據準備

首先要評估是否需要這方面的準備,這個過程往往會比較忽略,測試過程中再去準備回比較被動和耗時,測試環境和測試數據往往是由測試開發或者開發準備,作為測試工程師重要的是及時提出需求來,並及時和開發方溝通工作量和完成時間點。

用例執行

這部分應該是整個測試過程最耗時的部分,用例執行的時間應該依賴於用例的數量和用例執行速度,之前我們已經評估了用例的數量,如何評估用例執行速度呢?首先不同功能的用例執行的難以程度不一樣,純黑盒的用例一般執行速度回比較快,例如UI的檢查。偏邏輯層面的用例執行起來會慢一些,需要準備環境,或者通過工具驗證結果等等。測試工程師需要有意識的去統計不同難度用例的執行時間,例如黑盒偏UI層面的用例一個合格的測試工程師一天可以執行200-300條用例等。偏邏輯驗證的大概每天可以執行100條,大量需要環境準備和數據準備的每天30-50條等。

專項測試實施

專項測試每輪的測試時間相對固定,執行一次大概1小時,2小時等等,比較難評估的是如果測試出現問題開發可能會調優,執行多少次才能達到預期可能不太能評估。從以往經驗來看一般2-3次基本可以完成,專項測試執行的時間可以按照兩倍或者三倍時間去評估。

上報bug和驗證bug的時間

這部分時間是最難評估的,無法按照數量來評估,bug都是在測試執行過程中產生的,一般會通過用例執行時間乘以一個系數來評估,這部分比較靠以往版本的經驗,以往bug比較多或者修改起來連帶bug比較多可以適當提高這個系數比例。例如項目裏開發bug比較多,我們可以把這個系數提高到0.3,如果用例執行時間是3天,bug相關的處理時間可以按照一天計算。

測試工作量的評估是一個通過一定方法和測試經驗不斷積累來優化的過程,以上是小編我根據自己的總結和測試經驗形成的方法,不同的項目不同的團隊狀態工作量評估的方法可能有比較大的差別,但要找到適合自己項目的評估方法需要大家不斷的思考總結和積累經驗。

軟件測試qq群:507088

測試工作量的評估方法