測試管理-測試過程監控

測試活動的監控，對於總體測試工程而言是很是重要的管理內容。

測試工做自己是很是依賴項目其餘環節的，測試活動的進行充滿了變數。因此對測試的實行狀況進行持續的監控和作出及時應對，是管好一個測試項目的必要工做。

 

測試的監控是一個貫穿於整個測試周期內的工做。

在一些狀況下，監控的行爲並不須要很是系統化的規劃和定義，即便如此他極可能也在實時發生着。好比詢問某個測試人員的工做進展狀況，就能夠視做基礎的監控動做。對於複雜度相對較低，流程梳理清晰的項目而言，監控工做可能並不複雜，也無需精密的體系和機制進行保證。可是對於複雜平臺等一些項目，創建良好的監督控制框架多是有必要的。

1.監控的目標

在理想狀況下，參照V模型理論，咱們項目研發應該從項目立項到需求分析到設計到編碼，測試從需求評審到測試計劃到測試設計到測試執行和報告，有條不紊的開展下去。每一個階段都產出高質量的產出，爲下一個或下幾個階段提供支撐。

然而，在實際工做場景中，咱們有可能遇到複雜的甚至是計劃和預料以外的狀況。

好比：

• 需求到位不及時，或者需求文檔質量低下，測試依據不足；
• 單元測試覆蓋率不達標甚至總體缺失，底層測試不充分；
• 代碼提測時間延期，壓縮測試時間；
• 交付產品缺陷狀況超出預期，測試任務加劇；
• 項目計劃無預期變動，測試本來規劃被打亂；
• 等等......

筆者將監控的目標總結以下：

l 進度掌控

-把握項目進度狀況，根據實際與排期之間的差異及時作出調整。

l 管理風險

-及時對項目中的風險進行識別和評估，並做出控制和緩解。

l 解決問題

-作爲管理方主動發現和解決團隊成員工做中遭遇到的實際困難和問題。

l 增強協同

-經過監控達到增強團隊協同能力的目的。

 

總的來講，管理人員必須及時跟進測試實施狀況，一旦發生進度滯後，質量低下等影響產品定期高質量交付的狀況，必須採起合適的控制行動，扭轉這些偏離和異常。良好規劃的測試計劃是測試管理人實行監督控制的基準和依據，因此也要求咱們的計劃自己須要高質量制定。良好的計劃會使得監督工做更容易展開，有更明確的測試目標和安排，也就更容易讓咱們發現實際開展過程當中的異常。

實際操做過程當中，對異常狀況或者目標偏離的控制手段，能夠是計劃的變動以適應實際狀況，也能夠是資源（人員，時間）的調整。在這個過程當中，頗有可能須要項目其餘方面的協調協助，測試管理人應該始終與項目其餘干係人保持良好的合做關係。

爲了保證測試任務可以順利完成，創建有效的監控機制是有必要的。

 

2. 創建監控機制

2.1. 監控總體流程

咱們能夠用一系列的活動來組織監控流程，一個良好的監控流程應該有如下階段：

• 信息採集
• 問題分析
• 實施控制

具體到過程上：

• 瞭解狀況
• 發現問題
• 覈實問題
• 評估影響
• 給出方案
• 解決問題

以下圖所示：

  

2.2. 觸發機制

監控觸發機制定義測試管理人員在什麼觸發條件下，啓動監控手段。

CMMi定義瞭如下三種啓動形式：

l 按期監控

- 安排固定的監控週期，好比天天、每週等。

項目的管理安排通常都會肯定這樣的按期活動，好比周例會是不少項目會採起的形式，會議中與會各方會提供關於項目進展的信息以供跟蹤控制。

在敏捷型項目中，一個Scrum會議就是典型的按期監控活動，天天項目成員會集體討論各自的工做進展狀況；而在每個衝刺期的最後階段，還會安排當前衝刺期的按期回顧會議活動。

l 階段性監控

-以項目生命週期各階段的里程碑爲標記，經過里程碑的評審會議來對項目的各類參數進行跟蹤和監控。

在項目排期中，里程碑是一個很常見的設置。一個里程碑的到達標識着階段性成果的達成。之因此要設置里程碑，最主要的意義就在於給咱們預先設立一個檢查點，讓咱們檢查項目進度狀況。

l 事件觸發性監控

-當突發性事件發生時，須要啓動及時的控制手段以應對事件的影響。好比需求的計劃變動；好比人員的變更等。

 

除了以上這些觸發場景以外，測試管理人也須要實時關注測試工做進展，保證測試任務儘量無誤差完成。

2.3. 度量機制

測試管理人應該創建相應的度量指標，這樣才更有利於對相應狀況進行比對分析。不然若是缺少明確的度量辦法，監督得出的結論可能偏向主觀評判。

測試的監控對象主要能夠有如下方面：

• l 質量風險 ·
• l 缺陷 ·
• l 測試進度 ·
• l 覆蓋率 ·
• l 信心

在項目和業務中，產品風險、缺陷、測試和覆蓋率能夠，且一般以特定的方式進行度量和彙報。若是這些度量數據和測試計劃中定義的出口準則相關，他們能夠做爲判斷測試工做是否完成的客觀標準。信心的度量能夠經過調查或使用覆蓋率做爲替代度量，不過一般也會以主觀的方式彙報信心。

若是以上內容在項目中適合作爲監控對象，那麼測試管理人應該儘可能明確量化的標準，而且創建這些相關數據的採集辦法。

好比對於風險的監控，能夠採用的度量：

• l 徹底覆蓋的風險百分比
• l 部分覆蓋的風險的百分比
• l 還未徹底測試的風險的百分比
• l 按風險類別劃分的覆蓋的風險百分比 ·
• l 在初次質量風險分析後識別的風險的百分比

 

對於測試過程的監控，能夠採用的度量：

• l 已定義的測試工做項（好比用例設計）的完成度與完成時間
• l 已計劃的、已詳細說明（已實施）的、已運行、經過的、失敗的、沒法執行的和跳過不執行的 測試總數 ·
• l 迴歸測試和確認測試的狀態，包括趨勢和未經過的迴歸測試總數及未經過的確認測試總數 ·
• l 計劃的每日測試時長對比實際的每日測試時長 ·
• l 測試環境的可用性（準備測試團隊可用的測試環境佔計劃測試時長的百分比）

 

對於缺陷狀況能夠採用的度量：

• l 缺陷到達率：缺陷在必定時間段內爆出的數量；
• l 缺陷移除率：缺陷在發生階段被移除的狀況；
• l 缺陷分佈：缺陷在不一樣模塊或子系統中出現的佔比；
• l 缺陷修復率：單位時間內，報出的，被修復的以及遺留的缺陷數量的對比；

除了這些之外還有缺陷有效率，缺陷類型統計等等能夠幫助咱們去度量缺陷收斂狀況的數據。

 

對於覆蓋率監控，能夠採用的度量：

• l 需求和設計要素的覆蓋率 ·
• l 風險覆蓋率 ·
• l 環境／配置覆蓋率 ·
• l 代碼覆蓋率

 

 2.4. 信息採集機制

上節提到的數據度量，都須要基於足夠而且準確的數據才能完成，因此有必要創建高效的數據採集機制。能夠考慮採用如下辦法：

• l 問訊 ·

　　-　　即測試管理人主動向測試干係人和測試人員詢問進度狀況

• l 階段性彙報

　　-　　好比日報和週報的手段，收集測試人員關於工做內容及時間花費、測試執行狀況、缺陷收斂狀況、須要解決之問題以及將來大體安排等信息。

　　-　　這些信息須要被整合，得出總體進度、缺陷、工做安排、嚴重問題的彙總。

• l 跟蹤矩陣

　　-　　採用跟蹤矩陣的形式，收集測試活動進程信息。

　　-　　常見的矩陣能夠從我的工做信息和彙總信息兩個層面組織。

好比我的層面：

彙總層面：

採用圖表跟蹤的辦法可讓收集的信息呈現出更高的可視性和可讀性，例如： 

 

 

3. 補充

　　最後，測試監控的目的，不只僅是確保測試進度、完成狀況與計劃和預期的吻合。對於測試管理人而言，咱們測試管理的終極目的在於對質量的保證，而不僅僅是完成測試的任務。像以前章節中提到的，測試作爲總體研發的反饋迴路，測試監控中收集到的信息和分析，也是對於項目總體狀況的反饋信息源。

　　測試工做自己並不能直接產出質量，就像用體重器稱重並不能減肥同樣。測試須要依靠它的反饋功能，來促使問題的解決和質量的提升。

　　測試的反饋做用體如今彙報問題和促進問題解決，還表如今用測試的信息收集功能，對於整個研發過程乃至項目管理的狀況進行反饋，幫助解決研發過程和管理效能方面的問題。測試監督過程當中收集到的數據和信息，均可以用於研發過程能力的反饋。好比項目計劃階段，咱們經過風險評估可能會得出某一模塊出現缺陷的分概念較低的結論。可是實際測試過程當中，可能反映出的實際狀況是該模塊缺陷頻繁爆出。這樣的信息能夠很大程度推出開發過程出現了未預知的問題。

　　測試管理人應該及時將相似問題系統化，並反饋給開發負責人，依靠和告知團隊其餘干係人好比項目經理。不能一味的依靠測試執行工做去解決這樣的現狀，而是要爭取從研發鏈路的更上游控制問題的解決。