測試活動的監控，對于整體測試工程而言是非常重要的管理內容。

　　測試工作本身是非常依賴項目其他環節的，測試活動的進行充滿了變數。所以對測試的實行情況進行持續的監控和做出及時應對，是管好一個測試項目的必要工作。

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

　　在一些情況下，監控的行為并不需要非常系統化的規劃和定義，即使如此他很可能也在實時發生著。比如詢問某個測試人員的工作進展情況，就可以視作基礎的監控動作。對于復雜度相對較低，流程梳理清晰的項目而言，監控工作可能并不復雜，也無需精密的體系和機制進行保證。但是對于復雜平臺等一些項目，建立良好的監督控制框架可能是有必要的。

　　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. 補充

　　最后，測試監控的目的，不僅僅是確保測試進度、完成情況與計劃和預期的吻合。對于測試管理人而言，我們測試管理的終極目的在于對質量的保證，而不單單是完成測試的任務。像之前章節中提到的，測試做為整體研發的反饋回路，測試監控中收集到的信息和分析，也是對于項目整體情況的反饋信息源。

　　測試工作本身并不能直接產出質量，就像用體重器稱重并不能減肥一樣。測試需要依靠它的反饋功能，來促使問題的解決和質量的提高。

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

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