以系統測試發現缺陷的數量來衡量測試人員的系統測試效率，就好像拿開發人員的**行數衡量開發人員的開發效率一樣，無法客觀有效的反映測試人員的工作質量和工作效率。
優點：以bug數量為基礎，有乙個明確而清晰的度量標準
缺點：欠缺力度和有效尺度，不能真正反映當前系統的質量狀況
>>原因：
1）乙個點型的例子，主業務流程和非主業務流程中的乙個c類bug，或是主業務流程中c類bug和非主業務流程中的a類bug，或是經常出現的bug和偶爾出現的bug。
（對主業務流程的解釋：需求提出的，包括明確的或是隱式的，反之則為非主業務流程。可以按此區分問題的優先順序）
2）開發質量：測試乙個高質量的程式和測試乙個低質量程式所發現的bug的數量肯定不一樣
>>引出問題：
1）這兩種型別的bug是否有可比性，是否可以說同時發現的兩種c類bug的測試人員的工作效率就一樣高呢？或是發現非主業務流程中a類bug的測試人員的測試效率要比發現主業務流程中c類bug的測試效率高呢？或是發現經常出現的bug的測試效率就高過發現偶爾出現bug的效率就高呢？
2）對於不同開發質量的程式，以bug數量做評價標準，誰碰到了開發質量不高的程式，那他的測試效率一定高（如果他是個合格的測試的話 ：））
>>root cause：二者沒有直接的可比性，需要乙個中間變數：權重
1）bug的權重
2）開發人員的能力
解決方案：
1）針對bug按照實際的需求進行權重劃分（主流程按1.0，非主流程按<1.0，具體的劃分方式需要參考以前的測試標準得出乙個合理的度量資料）
2）針對bug對系統的影響程度進行權得劃分（系統崩潰：1.5，嚴重：1.0，一般：0.8等等進行劃分）
3）針對開發人員能力，取開發人員的平均開發能力，以此為標準確定bug發現的權重。大於開發能力的，其bug的權重就應當》1.0，反之則應<1.0。
4）針對每乙個測試版本做相應統計，進行曲線比較，如果是上竄下跳，而且沒有理由，測試效率是高是低一目了然
5）加強測試過程控制，必免不合格測試版本的出現，否則得出來的再高的測試效率也是沒有價值的。
注：1）所有的權重評估資料都是在前期資料基礎之上進行的，也就是說需要設定乙個基礎的度量值，隨著整體開發和測試的質量的提高，或是整體系統的開發難度和業務熟悉度的變化，這個值是動態變化的。
2）有時也會將測試人員的經驗和測試水平加權做評估，個人認為意義不大，因為不同型別的測試人員發現問題的型別，方法和敏感度不盡相同。建議此指標只做為參考。
演算法效率的衡量
假設對於同一問題，我們給出了兩種解決演算法，在兩種演算法的實現中，我們對程式執行的時間進行了測算，發現兩段程式執行的時間相差懸殊，由此我們可以得出結論 實現演算法程式的執行時間可以反應出演算法的效率，即演算法的優劣。單靠時間值絕對可信嗎？假設我們將第二次嘗試的演算法程式執行在一台配置古老效能低下的計...
演算法的效率衡量
演算法效率衡量 先來看一道題 如果 a b c 1000，且 a 2 b 2 c 2 a,b,c 為自然數 如何求出所有a b c可能的組合?執行時間反應演算法效率 對於同一問題，我們給出了兩種解決演算法，在兩種演算法的實現中，我們對程式執行的時間進行了測算，發現兩段程式執行的時間相差懸殊 214....
如何提高測試效率
1.盡早參與到專案中 測試盡早介入專案詳細了解專案的業務需求，做好測試的前期準備 目前來說，可能大家都有類似的感受，接觸到的大多數的專案，都是測試週期比較短，開發人員耽誤了時間，為了不拖延專案進度，留給測試人員做測試的時間都非常緊張。如果專案測試的前期了解業務需求 了解產品屬性和準備測試資料不充分，...