做專案的資料採集，效率是繞不開的乙個資料需求。我們一般都會用生產率來衡量專案的效率，如編碼的生產率，測試用例設計的生產率，測試執行的生產率。生產率的標準定義是：
生產率是衡量每單位投入的產出量，是用來表示產出與
投入比率
的術語。
但是，在軟體專案中，計算生產率會遇到乙個問題——產出量的衡量方法。對於開發，**量是最直觀的乙個產出衡量度量，可是，我們知道，每行**的難易度不一樣。兩個專案，即使它們的生產率都是
0.8kloc/pm
，它們的效率也可能大相徑庭。用
function point
，cocomo
則能在一定程度上避免這個問題。
在測試專案中，也有同樣的問題。一般情況下我們會用單位時間執行的測試用例數量來度量測試執行效率。
測試執行生產率
=被執行的測試用例總數÷執行測試用例的總時間
可是，有些測試用例的執行時間只需要幾秒鐘，有些測試用例的執行時間需要幾分鐘甚至幾十分鐘。兩個專案，即使第乙個專案
1小時執行
100個測試用例，另乙個專案
1小時只執行
10個測試用例，我們也不能說第二個專案比第乙個專案效率低。於是，用標準的生產率來衡量測試執行效率，無法進行專案之間的橫向比較和借鑑。歷史資料的作用也就大打折扣。
為了解決這個問題，乙個方法是測試用例設計工程師在設計測試用例時，就估算並記錄每個測試用例所需的執行時間，我們將這個時間值稱之為測試用例的消化點數（如乙個測試用例需用
5分鐘執行，則它的消化點數是
5）。然後用被執行的測試用例的消化點總和來度量產出的規模。
測試執行生產率
=∑被執行的測試用例消化點÷執行測試用例的總時間
它的單位是消化點
/人時。
這樣計算得到的生產率就解決了測試用例大小不同的問題，可以用來在不同的業務線，不同的專案之間比較效率和作為估算依據了。
不過，由於專案背景和要求不一樣，在我的公司，大部分專案還是沒有在設計時就估算每個測試用例所需的執行時間。考慮到一條產品線的測試用例還是有一定的穩定性（粒度大小），我對上面的計算做了如下改進。在一段時間裡，使用被執行的測試用例數和這些測試用例的純執行時間總和來計算平均的測試用例消化點數。然後用這個平均消化點數乘以測試用例數來計算消化工數總和，從而得到測試執行生產率。
我們一般會用該產品線的1～
2個專案來計算該產品線的平均消化點數。這裡，純測試執行工數的定義是直接執行測試用例的工數；執行測試用例的總工數則包括測試準備工數，純測試執行工數，登入和對應
bug的工數，
q&a的工數。
下面是某個業務中多個產品線的生產率，第二列是用消化點計算的生產率，第三列是用測試用例數計算的生產率。從歸一化後的方差來看，使用消化點計算的生產率明顯比用測試用例個數來計算的生產率要更能真實反映不同專案效率的差異。這樣的資料也才更有橫向比較和參考的價值。
專案代號
消化點/ph
use case/ph a
41.4
4.7 b
27.6
1.8 c
43.2
5.1 d
43.8
4.3 e
50.4
6.6 f
53.4
6.5 g
26.4
1.8 h
425.1 i
49.2
5.3平均值
41.9
4.6歸一化後方差
0.05
0.15
c 呼叫lua指令碼測試執行效率
include extern c pragma comment lib,lua51.lib 載入lua鏈結庫 lua state l 建立全域性lua物件指標 long long use lua fun lua state l,const char funname,int a,int b long ...
軟體測試基礎知識 測試執行
定義 根據編寫的測試用例，按照用例步驟進行執行，檢視預期結果和實際結果是否一致，如果不一致則為bug 執行人 軟體測試工程師 開始時間 測試用例編寫完成並且通過評審，且達到測試執行的啟動條件 時間週期 佔整個測試流程的40 的時間 測試用例執行結果狀態 測試執行中的注意事項 搭建軟體測試環境 測試用...
軟體外包專案測試 測試執行篇
軟體外包專案測試 測試執行篇 經過5個月的努力，我們和 大型國企 亞洲最賺錢的公司 軟體系統的第三方測試終於告乙個段落。本次測試由於整個團隊的不懈努力，贏得了客戶很高的滿意度。本次測試中我們經歷前期的洽談專案 設計方案 熟悉需求 更新方案 測試計畫 測試用例設計 以及測試執行 回歸測試 測試總結等階...