軟件測試度量的切身體會

控制限36的制定遵守是切比雪夫不等式，具體見筆記和書。有了理論基礎。
有一個想法，X的平均值不按照樹上的求發，完全按照概率的算法，算出來的結果式不是更科學。即，按照概率書上直接求數學期望和方差的方法。不知道能不能算先進。理論依據到是有的，就是也還是大數定理。

度量中遇到的問題：
1. 收集測試用例文檔頁數不科學。因為在測試小組編寫測試用例是在Excel下面，基本上一個用例的編寫占用一格。因此，考察測試文檔的有效性跟測試用例的有效性雷同，所以文檔的數量度量不再考慮。

開題報告中的問題：
1.偏題。論文研究的主要目的是促進研發。方法，找測試、開發、產品質量的關系。從測試度量角度，度量測試，度量開發，度量產品質量。
 
實施度量活動的一些經驗教訓：
1.必須獲得高層領導的支持，這是實施度量計劃的基礎
2.成立專門的數據分析小組，成立可以由組織層的數據分析人員和項目經理構成
3.在度量開展之前必須定義度量目標
4.3級中，由于大量文檔的使用，軟件工程室個人的效率會有比較大的下降。因此，充分利用工具來減輕手工勞動強度將有利于軟件開發過程的運用于推廣。
5.度量系統的能力，是和組織軟件過程成熟度關系密切。因此，在軟件過程還不成熟、混亂的情況下，需要制定簡單可行的度量計劃。隨著軟件過程的逐步成熟，再根據需要逐步提高質量系統的能力。
6.長期來看，必須把過程管理建立在數據的基礎上，即使對于CMM2級來說，盡早的積累數據，也是非常有用的。

一點想法，可以將度量分析出來的穩定可控的數據作為評測工作的標準。

實際操作步驟
1.確定當前的評審數據值在控制圖上的位置。
2.如果缺陷密度出于UCL和LCL之內，這就意味著被評審對象的質量可以被接受，修改后可以進入下游活動
3.如果缺陷密度高于UCL，這就意味著被評審的對象的質量不能被接受，采取的措施是修改后重新評審
4.如果缺陷密度低于LCL，這就意味著被評審對象中發現了過少的缺陷，這有兩種可能：
（1）評審效率太低，需要重新評審；
（2）被評審的質量可能由于某種原因，特別高，這種情況下就不必再評審了。
在第四中情況下，評審小組需要結合自己的經驗來判斷是否需要重新評審。
在執行過程改進之后，比如開展同行評審主席培訓，可以使用一個過程改進因子，比如開展這項培訓可以提高同行評審對象質量20％。這樣，就可以獲得新的過程能力：
均值（新）＝均值（舊）×（1－20％）
UCL（新）＝UCL（舊）×（1－20％）
LCL（新）＝LCL（舊）×（1－20％）
然后，將培訓后開展的培訓數據點，打在新的控制圖上，觀察點的位置。如果大量點落在均值之上，說明培訓的效果沒有達到預計的提高20％的目標，即高估了培訓的效果。這時就要根據新的數據來重新獲得過程能力。如果大量點落在均值之下，說明培訓的效果達到并超過預計的提高20％的目標，即低估了培訓效果，這時也要根據新的數據點來重新獲得過程能力?？傊?，只要新的數據點出現明顯異?；蛘吣撤N模態，就說明過程處于失去控制狀態，需要做進一步的調查來了解實事和真相。

軟件過程模型和標準

1.目標/問題/度量模型GQM(Goal/Question/Metric)
2.統計過程控制模型SPC(Statistical Process Control)
3.ISO/IEC 15939 是一個有關軟件度量過程的國際標準
4.實用軟件度量模型PSM(Practical Software Measurement)是對ISO/IEC 15939的具體實現。其描述了2個模型：度量過程模型MPM(Measurement Process Model)和度量信息模型MIM(Measurement Information Model)
<I-C-M模型>，模型基于"Plan-Do-Check-Act"管理方式
軟件度量概念從1968年被正式。軟件度量的實質是將軟件的屬性數量化。
軟件度量的主要建模方法：其中統計方法類中主要是回歸分析（以多元線性回歸較常用）
Basili所提出的目標/問題/度量(Goal/Question/Metrics,G/Q/M)模型，針對性強靈活性好，且更為重要的是，它可以從小型開始(Start Small),這樣成本不高但見效很快，從而贏得開發人員和管理人員的支持。不過該方法缺乏系統性，需要組織本身來提出一整套系統的、適合于組織自身實際的度量指標體系。
估計與度量的差別：估計是事前預測；而度量則是進行事中相關數據收集和事后分析并采取相應措施。
開展軟件度量活動需要注意的事項：首先，度量要爭取得到高層支持；其次，度量總的宗旨是理解，而非評估，所以度量決不能針對個人，應針對過程；再次，度量時要做到目標明確、方法得當，度量計劃要明確、完整；最后，切記使得過程度量制度官僚化。
隨著軟件過程概念的提出，軟件工程從以產品為中心過渡到以過程為中心?；诤玫能浖^程可以獲得搞質量的軟件產品這一假設，通過實施軟件過程改進來不斷提高軟件質量已成為軟件工程領域公認的準則。
國內中小軟件企業特點(1)人員少(2)資金不足(3)軟件過程不明顯，甚至沒有明確定義的軟件過程(4)企業從事的軟件生產呈現明顯的領域特征(5)人員間的溝通方便。

如果你是在做管理或曾經做過測試管理，那么你會發現流程的把握公司只會前期很短的耐心時間等待你，實際公司原有的產品質量在你測試后是否能有期望中的提高，是否達到減少成本目的是公司最終衡量你的標準。
      當只有存在一個達到了一定戰績和明顯改善了公司產品質量的測試團隊時，新成員的考核可以建立在此基礎上。但新成員演變成了熟練技術員，衡量他的將是出去的產品用戶反饋回的BUG幼稚程度。

呵呵，說到同感處，又情不禁再發表一點自己的觀點：
      測試大家都可以認同的一點是在成品測試階段遺留的bug測試工作如果理想應該做到“查找到這些BUG的80%”，而且產品交付后再默許遺留的20%以下的BUG顯然級別較高的數量應該是很少量；
    因此公司如果夠規范可以基于此做出績效考核的幾個指標來衡量測試人員的工作，顯然如果在正式產品運行后用戶反饋回級別較高的BUG教多，或級別不高但數量可觀，那么我們認為測試的工作效率是比較低的。
    呵呵，這一點我們在上初中時老師就教會了我們如何計算一級方程式，我們設定現在我們測出的總有量為80%，那么我們可以得到一個假設的總值，當然也可以算出剩余的20%。
      剩下我們需要去劃定幾個指標，就是超出20%的量有多少，質如何；可根據公司具體情況而定。

我們公司的處理方式：一個軟件或者一個系統在兩個版本測試之后，達到一個比較穩定的狀態，如果負責系統某個模塊測試的測試人員，在第二個版本測試已經不能提出質量較高的bug時，則進行交換，由其他的測試人員接手該模塊，如果在版本沒有更換的情況下，發現了級別較高的bug，那么我們會根據該bug的出現頻率，出現時機判斷是否應該更早提出，這樣可以判斷前一測試人員的工作效果，另外，我們還根據測試人員的溝通能力，工作速度，工作質量進行評判，還有一個長期的追蹤就是客戶反饋， 我們在出版本的時候，最終定版本的相關測試人員都要簽字的，這樣可以長期的跟蹤測試人員的工作質量。

這篇是老貼子了。我來說說。
一線的測試員工一般無法參與到整個產品的流程中去，只是當產品轉測試的時候，才能真正開始開工。一般由測試經理參與整個產品的流程中去。
既然測試執行者只做測試這部分，那么就該把這部分當做員工的考評標準。比如發現的BUG數，發現BUG的質量。測試過程中員工的主觀能動性，包括是否提出了自己的看法，該看法對改進測試工作是否有效，員工是否有自己的心得體會，是否善于總結小結等。

衡量測試工作的績效關鍵是看測試環節上對產品質量控制的好壞。測試有很多種，在SP的開發模型中測試人員和開發人員的界限已經不是很明確了。但是主要還是看漏測率。即產品開發周期中發現的問題（產品發布前）和網上問題（產品發布后）的比例。如果產品發布后還是一堆問題擔負首要責任的必然是測試

原文轉自：http://www.anti-gravitydesign.com