這是一篇當時寫作耗時耗力的文章，這篇文章是2007年CSDN雜志約稿的一篇文章，由于我曾經在神州數碼軟件集團的項目管理中心任職，做過大項目監理，本身又專注于軟件測試的管理領域，所以編寫了這篇文章。但是目前在網絡上搜索了一下，已經沒有了當時文章的配圖了，正好接著重做網站的機緣，找一些合適的圖片，重新排版一下，讓這篇文章重新完整起來吧。
軟件測試過程的監控方法
文/賀炘
軟件開發項目的成敗，很大程度上取決于三方面的配合：過程、人、技術，三方面相互制約，又相互促進。為了能更加有效的管理軟件開發項目，規劃軟件開發過程，近年來國內引入了不少軟件開發模型，如：CMM/CMMI，RUP，XP等，每一種都體現了一種思想，都希望能在最大限度內，協調上述三者之間的關系，最大程度的減少軟件開發過程中的風險，能按照既定的計劃，交付出合格的軟件產品。
V模型軟件測試的標準模型
對于軟件測試工作，國內大多數企業采用V模型作為測試的標準模型，來規劃和設計軟件測試流程，指導日常的測試工作，模型如下圖所示：
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?圖一：V模型
V模型帶給我們一個理想的開發方式，幫助我們理解軟件開發活動中各個階段之間的相互關系。
V模型的左側是以瀑布模型為基礎的開發活動，自上向下開展。V模型的右側是測試活動，以左側完成的活動為工作輸入，自下向上開展，最終通過驗收測試，交付給用戶合格的軟件產品。
通過這個模型，我們發現按照理想情況，如果需求獲取人員完成了需求分析工作，測試人員就可以按照需求分析的結果規劃我們的系統測試工作，設計系統測試用例，等待到系統測試階段執行測試用例，驗證系統是否實現了設計的所有功能和性能要求。
當概要設計人員完成了概要設計工作，測試人員或者開發人員（不同的公司可能會要求不同的角色完成這一工作）就可以規劃集成測試工作，設計集成測試用例，等待集成測試階段執行測試用例，驗證系統是否可以組裝成功，是否可以交付到下一個階段進行系統測試。
當詳細設計人員完成了詳細設計工作，開發人員就可以規劃單元測試工作，編寫單元測試用例，等待編碼完成后進行單元測試工作，驗證單個模塊或者類等（各個公司規劃的單元測試顆粒度不盡相同）內部的邏輯是否有問題，整個系統是否可以進入到集成測試階段。
通過分析我們發現，按照V模型來設計測試工作，測試人員可以在前期（需求獲取階段）就介入到整個開發過程中，設計測試用例規劃測試工作。這樣，有許多工作就可以并行開展，而且很多問題可以在開發的前期被發現，極大的規避了開發工作的風險，降低了改正缺陷的成本。
實際情況是什么那？
但是我們目前的實際情況是什么那？我們的需求總在變更，概要設計做的不夠好，而且變化頻繁，詳細設計不夠詳細或者根本不做，單元測試覆蓋率不夠或者根本不做，這樣造成測試工作步履維艱，質量難以控制。我們上面談到的幾種軟件過程改進模型，也是想在方法的高度上，盡量的改變這種現狀。
不管我們打算采用何種模型作為我們過程改進的基礎，對于軟件測試工作來講V模型都是我們很好的一盞路燈，它提供給我們一個軟件測試工作提前介入的思路，以測試或者說以質量保證為前提的軟件開發方法，只有這樣做，我們才有可能生產出高質量的軟件產品。
?如何對軟件測試工作進行監控
本文并不打算一一探討上述幾種過程改進模型的測試監控方法，而是參考V模型的架構，從軟件項目管理的角度談一談，如何對軟件測試工作進行監控，具體的監控手段都有那些，在平時的工作過程中我們應該怎樣使用。
?項目管理三要素
大家都知道，項目管理有三個要素，即：成本，進度，質量。
對于軟件測試經理來講，只需要對產品的質量負責。對于整個項目來講，項目經理作為項目組的最高領導自然要對項目整體的：成本、進度、質量負責；在這個團隊中，作為主管軟件測試工作的測試經理，需要協助項目經理只對質量負責，這樣才能客觀的對項目的質量做出評價。之所以說不用對其它兩項負責，更確切的說法應該是在做質量判斷的時候，不需要考慮成本和進度可能對質量造成的影響，具體的權衡工作由項目經理或者公司的高層來完成，測試經理只提供對軟件產品質量的客觀判斷。
測試人員和開發人員在溝通上存在問題
既然測試經理只對質量負責，這就會衍生出來一個問題，測試經理對產品質量過于吹毛求疵，與開發人員造成對立，進而影響項目開發工作。如果這件事情發生了，有一個確切的信號已經傳遞了出來：測試人員和開發人員在溝通上存在問題。如何解決這個問題？首先，我們應該審視測試人員和開發人員的溝通技巧是否存在問題。其次，我們應該重新核對我們在項目開始時確定的質量目標，看看是測試人員人為拔高質量目標，提出超范圍的要求，還是開發人員人為降低質量目標，生產出不符合質量要求的產品，以此作為對質量標準實施誤差的一個判斷。
為什么需要對軟件測試工作進行監控？
在項目中作為對產品質量檢驗的負責人——測試經理工作的好壞或者對產品質量的客觀評價，對公司的決策就會顯現的非常重要。
為了能有效的降低這種風險，管理上采用的一般方式就是監控，即由第三方人員對被監控方的工作進行客觀的評價。那誰是第三方人員？首先，這個人不在被監控的項目中負責具體的工作，其次，他代表公司或者所在部門，需要對項目的質量情況進行客觀的評價。
針對一個具體的組織結構模型，如下圖所示：
組織結構圖
圖一：組織結構圖
可能對測試工作有監控需求的部門有：軟件測試部門的主管，SQA人員或者其主管，技術或者開發部門的主管。他們的監控出于不同的目的，如：評估測試工作的有效性，了解具體項目的質量情況，了解開發的進度和效率等。不管出于什么目的，他們有一個共同的特征是：不參與項目組中具體的工作，并且需要在短時間內了解項目的實際情況，并且做出相對準確的判斷。但是，不在項目組中，對項目組的實際情況不是非常了解，如何能在短時間內對項目的測試情況做出準確的判斷？
?實際工作中的測試工作監控方法
在實際工作過程中，我們可以采用如下的方法對測試工作進行監控：
一般采用的手段是：問訊與查閱相結合，對關鍵點進行抽樣審核，并詢問不同的人員以進行核實。
具體的審查點和查閱項會在下面做詳細的闡述。在監控過程中，我們一般會經歷如下階段：
測試監理過程
- 首先依據自己的經驗，問訊項目組的相關人員，看看項目的過程是否符合通常的測試規范。
- 通過問訊，記錄發現的問題或者疑問
- 通過詢問不同的項目組成員或查閱相關的文檔，核實發現問題或疑問的真實性
- 匯總所有問題，評估各個問題的影響和風險，列出優先級
- 給出可能的解決方案。注意，這里的解決方案不是指具體的解決方法，而是指激發項目組成員行動的可行的方案，如建議項目組開會討論可能的處理方式等。
- 跟蹤解決方案，驗證問題是否真正得到解決。
以上是一個通行的監控過程，這里需要強調的一點是：不管出于什么理由對測試過程進行監控，但是發現問題絕對不是我們的目標，能夠有效的解決問題、降低項目的風險才是我們的目標，只有這樣的監控才是有價值的，對公司整體有利的工作。
對測試工作監控的三個階段
對測試工作監控的方法，依據項目所處的不同階段我們分為三個部分進行闡述。
這三個部分暫且稱為：測試初始期，測試實施期，測試結項期
測試初始期
在這個階段，測試工作剛剛啟動或者才開始按照計劃實施測試工作，測試工作的啟動時間點在各個公司可能不同，有可能是：需求調研后期，集成測試期或者系統測試期等。具體在軟件開發的什么階段測試工作開始介入，并沒有一個一定的說法，關鍵要看所在公司的軟件開發活動的成熟度來靈活選擇，但是這點并不影響下面的討論。
作為測試工作的監控者，應該在那些重要環節上加以注意？首先請大家注意這個階段的特征：軟件開發工作已經開始，需求開發工作已經完成或者接近尾聲，以測試人員為主的測試工作正式啟動或者剛開始運行。
在以上的前提下，我們來說一說需要注意的監控點：
1.測試工作有沒有明確的工作范圍
這是在測試工作中最需要明確的，也是非常多的項目忽略的工作。在做測試工作之前，一定要非常明確準備對那些內容進行測試，預計達到的質量標準是什么，尤其是對那些不進行測試。
我遇到過的很多的測試經理都抱怨說：“我們不可能在前期把這些事情都弄清楚，開發人員都不知道產品將來是什么樣子，我們怎么知道需要測試那些內容？”咋一聽，感覺很有道理，但是情況是否真像大家說的那樣？作為公司，或者項目經理都希望能將項目做好，能生產出一件令用戶滿意的產品，如果這個假設成立的話，這也就是我們能夠改變現狀的動力。
- 首先，原先的那種做法已經多次證明是行不通的，所以只有改變我們的做法才有可能成功，前期先弄明白我們打算做什么并不是一個過分的要求。
- 其次，開發人員實際上并不是完全不知道他們打算生產什么樣的產品，而是就一些細節考慮的不夠，或者不周全。作為測試人員，一定要知道如何對一件產品的功能和性能怎么驗證，這實際上在幫助開發人員從使用者的角度上重新的審視一遍需求，也許這時候開發人員也說不清楚，那如果你和開發人員都非常清楚那些是明確的、那些是需要后面再補充的，也已經達到了我們的目的。
2.被測系統有無明確的性能指標？
對性能要求比較高的系統，需要在前期明確具體指標到底是多少？用何種手段進行確認？用戶是否認可這個指標的描述以及確認的方法。
性能指標一般從需求中對一些敏感的數字的描述中來，如：必須保證能處理30個在線用戶同時操作，主要業務系統響應時間不能大于1.5秒等。
針對這些數據，測試人員一定要細化數據背后的含義，使這些數據變得可驗證。
如在規劃這些性能指標的驗證方式時，首先需要明確軟硬件的環境是什么？在此基礎上，還需知道什么叫30個在線用戶同時操作？都操作什么？這個場景應該怎么模擬？只有和這個指標相關的所有驗證方法都可行，而且得到了認可，在后續的測試活動中我們才能相信這條性能指標能夠進行測試。
3.測試工作有無明確的階段劃分（如單元、集成、系統、驗收等）？各階段是否有明確的交付確認條件？
實際過程中，我們都會將測試工作按照階段進行劃分，上面描述的是一個通常的劃分方式。在做監控工作時，還需要明確一點：這些階段的劃分是不是只有時間點的描述，而沒有各個階段之間可量化、可衡量的交付確認條件？
如果只有時間點的劃分，那我已經可以斷定，這個項目勢必會延期，原因是在整個生產活動過程中沒有明確的階段點交付的檢驗標準，問題肯定會沿著整個開發過程逐步的傳遞下去，終歸會在某一點爆發，最不幸的爆發點是在客戶處。
如果想盡量的避免上述的風險，就需要在開發過程中明確各個階段點之間的交付、確認條件。而且這些條件必須可量化、可衡量，決不能是含糊的，不易操作的，否則在實際操作過程中還是會將大量的問題推入下一個階段。
下面也以單元測試為例，看看怎么建立一個可量化、可衡量的單元測試階段的交付標準。
- 首先，需要確定開發人員是否進行了單元測試?？梢宰岄_發人員提交一份單元測試總結報告，上面需要大致的描述一下進行了那些單元測試。單元測試總結報告是否提交是一個可以量化的條件。
- 其次，需要評估一下單元測試的質量，主要可以通過如下方法：
- 是否有足夠的單元測試用例？可以對照詳細設計規定單元測試用例的數量，這是個量化的方法。
- 單元測試用例的通過率必須達到90%以上。
- 測試人員還可以抽樣執行開發人員編寫的單元測試用例，抽樣執行的單元測試用例的一次通過率必須在90％以上。這也是一個量化的方法，同時檢查了測試用例書寫的質量和單元測試執行的質量。
以上是一些常用的方式，而且這只是非常少的一部分，當給出確實可行的方法和可以量化的指標后，我們發現，評估一個產品是否達到了預計的質量要求就會變得相對容易很多，而且也避免了人為主觀判斷的尷尬。
4.最終的交付驗收有無和客戶確認通過的驗收標準和范圍？上線、割接和維護期有無明確的成功、失敗判定標準？
對于項目類的軟件開發，上面的監控非常重要。為客戶做項目的時候，一定要在前期和客戶確認怎么進行驗收，驗收通過的標準是什么，最好能形成書面的文檔，這樣才能在最后交貨的時候避免不必要的麻煩。而且，驗收標準和范圍應該是測試的一個最小測試集，要最大程度的確保正確性。
如果是比較大的軟件開發項目，還會牽扯到：上線、割接、維護，一般會寫在前期的合同中，客戶會按照上述階段點階段性付費，所以如果上述階段點沒有明確的成功、失敗判定標準的話，對于公司尾款的收取是個挑戰。
?可以定性了
通過以上的詳細詢問，我相信，測試工作范圍界定的是否有問題，測試工作是否規劃的全面、細致，監控者應該比較清楚了，下面的任務就是將你的疑問記錄下來，留待后面做證實。
測試實施期
在這個階段，測試工作進行了一段時間，測試人員的工作應該已經步入正軌，按部就班的完成一些任務。這個階段的特點是：開發人員和測試人員都按照日常的規范開始有條不紊的工作，有可能對一些問題已經習以為常，或者已經被同化。作為測試工作的監控者，應該在看似合理的工作中找出影響質量的問題，規避風險。
在這個階段，應該關注以下問題。
?1.缺陷管理流程是否規范？每個缺陷的提交和關閉是否都有復查？
缺陷管理是貫穿于整個軟件開發過程、測試過程的關鍵環節，也是測試工作的根本，所以缺陷管理的流程是否規范，將是監控的重點。
首先，需要詢問測試經理，軟件開發過程中對缺陷的實際管理情況是如何的？不要讓測試經理背誦公司的管理規范，而應該以一個實際缺陷為線索，追尋這個缺陷的產生直到關閉的過程是什么？期間是否有相關的記錄，證明項目組的實施過程完全與描述相一致。標準的缺陷管理流程是怎樣的，這里就不做敘述了，如果大家有興趣可以查閱相關的資料。
在這個過程中，還需要注意一點：缺陷的提交和關閉是否都進行了復查。
缺陷提交和關閉的復查人可以是測試經理，或者測試經理指定的人選，一方面經過復查，可以減少缺陷的重復提交，提高缺陷報告的質量，另一方面在測試組中會有一個人對系統或一個大組件的質量情況有比較全面的了解，尤其在后期，這種了解會在很大程度上降低系統誤發布的風險。還有一個好處是，在測試人員和開發人員交互的過程中，這個復查人員起到了橋梁的作用，可以有效的隔離開發與測試之間的多頭溝通，在一定程度上提高了效率。這個角色可以是專職的，也可以是兼職的，關鍵看系統的大小。
?2.配置管理工作是否規范？測試過程中涉及到的版本是否都可以完整的追溯？測試版本的發放頻度是否符合測試的實際要求？
配置管理工作是整個軟件開發過程的生命線，相比較而言，開發人員對此應該更為關心。對于測試人員來講一方面要保證可以取到自己想要的文檔版本，另一方面必須得到自己關心的程序的任意一個測試版本，以便可以在正確的版本上執行正確的測試用例。
在實際檢查過程中可以在缺陷庫中任意選擇一個缺陷，查看這個缺陷是在那一個版本的程序中發現的，隨即在配置庫中調出該版本，看是否可以調出。隨后，查閱該缺陷在那一個版本中修訂正確了，隨即也在配置庫中調出該版本，看是否可查到。
在這個過程中，還需要注意開發部門提交給測試部門版本的頻繁度，看是否過快或者過慢。過快或者過慢，沒有一個時間上的判斷。比如每2天提供一個新版本供測試人員進行測試，這個是過快還是過慢？判斷的依據關鍵要看測試人員所處的狀態，當版本提交的過快時，測試人員一直忙于對已修訂好的缺陷進行反測，沒有時間對新功能進行測試。當版本提交過慢的時候，測試人員的時間比較空閑。
在監控過程中，只需要詢問測試人員的測試工作的緊張程度，一般就能夠判斷出版本提交的頻度是否有問題了。
3.關鍵測試活動的關鍵測試資源是否如期到位？如沒有到位是否進行了合理的規劃來完成延誤的測試工作？
在測試過程中，某些關鍵測試任務需要用到特殊的設備或者特殊人員的技能，稱為關鍵資源。在測試實施過程中，要提前計劃會用到那些關鍵資源，以免耽誤項目進度。
作為測試的監控者，需要非常關心這些關鍵資源的使用情況，因為如果關鍵資源不能如期到位，勢必要影響項目的整體進度。
如果由于某種原因，關鍵資源沒有如期到位時，要注意測試人員是否對計劃進行了修訂，修訂的結果是否可以彌補已經造成的損失，或者能最大程度的減少損失。
4.測試策略，測試計劃，測試方案，測試用例是否都經過了正式評審？發現的問題是否都進行了更正？
作為測試的監控者，不可能在短時間內評估一份測試計劃制定的是否合理有效，一份測試方案是否可以正確實施，并且也不必要這么做。
測試策略，測試計劃，測試方案，測試用例等文檔都是測試過程中的關鍵文檔，也直接決定了測試工作的質量。監控者在評價這些文檔的質量時，首先想到的一點就是我要充分的閱讀這些文檔，以我的經驗和能力來判斷這份文檔的好壞。但是，作為一個項目組以外的人，很難能就所有的細節發表高質量的看法，其次，也不可能在短時間內完成所有文檔的評價工作。所以這不是我們的解決方案。
在監控過程中，首先要相信項目組自身的能力，假定他們有能力完成這些工作，這樣工作就簡單了，也變得可以操作了。
首先，查閱這些文檔，大致看看，有沒有明顯的問題。其次，應該檢查這些文檔的評審記錄，看看相關的人員是否參加了該評審，都發現了什么問題，大家的意見和建議都有那些。最后，看看所有的發現的問題是否都得到了解決，文檔是否按照解決的方法進行了修訂。
在監控的過程中，默認參與評審的人員技術能力都符合要求，這樣只需要關注評審的過程就可以控制質量了。但是，如果有證據證明，評審的人員或者組成不符合要求，作為監控者應該宣布該文檔的評審無效，需重新進行評審，以解決問題。但是，使用這項權利的時候要小心，而且要充分論證，否則會擾亂項目組的正常次序。
?5.測試的相關文檔是否都按照項目目前的實際情況進行了更新，并嚴格遵照執行？
經常會聽到一句話就是：計劃趕不上變化，這個問題就是沖著這句話來的。我在講課的過程中問過很多人這樣一個問題：不做計劃，直接做事情行不行？至今我還沒有遇到一個說行的。但是，如果計劃和行動不同步，這個和沒有計劃又有什么區別？
項目中有各種各樣的理由告訴你，我沒有同步計劃是合理的，但是我們的要求一定是必須有計劃，而且必須嚴格遵照執行，這才是降低系統風險的唯一合理方法。
6.項目先前定義的測試范圍在后續的計劃、方案中是否有遺漏？
在測試初始期我們一直強調測試范圍的必要性，在測試實施階段還需要檢查前期規劃的測試范圍是否在后續的計劃活動中覆蓋完全了，只有計劃中完全的覆蓋了所列的測試范圍，才能保證系統的質量。
?7.項目的測試過程是否按照公司預計的測試過程執行？
在測試實施階段，還需要了解測試人員是否按照公司要求在執行所有的測試活動，但是要在短時間內了解，手段只能是聽測試經理陳述他們的測試過程，再加以判斷。如果公司有SQA人員，工作就相對簡單了，只需要到配置管理庫中找到SQA的檢查報告，這些疑問就一目了然了。
測試結項期
在這個階段，主要的測試工作已經進行完畢，最終的發布版本也已經準備出來。測試經理開始書寫最終的測試報告，申請發貨。
作為測試的監控者，這個階段的主要任務就是評估軟件產品的質量，依據已有的數據評估測試工作是否做到位，產品是否可以發布。
在這個階段，應該如何進行監控，問些什么問題？
1.測試中發現的缺陷趨勢曲線是否處于收斂狀態？各個分模塊的缺陷趨勢曲線是否基本一致？
測試完成后，判斷產品是否能夠發貨的一個重要條件就是：缺陷趨勢曲線處于收斂狀態，并且持續一段時間，表示系統處于穩定狀態，滿足發貨條件。
那為什么還要看各個分模塊的曲線是否一致？因為，有的系統比較龐大，有可能某一個局部的缺陷曲線還沒有處于收斂狀態，但是整個系統的缺陷趨勢圖已經把這個信息掩蓋掉了。所以，還需要分別看一下各個模塊的趨勢曲線，確保系統的每一個部分都處于穩定狀態，這樣發貨的風險才能降到最低。
?2.是否有評判產品能否發貨的文字性材料？
發貨前，測試經理或者項目經理必須提交一份整個系統的整體質量說明，以文檔的形式證明整個系統質量穩定，達到用戶要求，可以發貨。
在這個過程中，如果和客戶有關于質量的約定，還需加入，如：用戶簽字認可的驗收報告，用戶簽字認可的性能測試報告等。
?3.是否召開了正式的最終評審會議？會議的參與評審人員是否有公司主管的高層？是否有用戶或者能體現用戶方意見的人員參與？所有的遺留問題是否都有了明確的解決方案，并且有相關的責任人負責問題的解決和跟蹤？
在發貨前，還需要召開正式的評審會議，而且會議必須有項目組以外，主管該項目的公司高層和能體現用戶方意見的人員參加。因為，一般系統中或多或少都會遺留一些缺陷，這些缺陷到底應該如何處理，會給公司和客戶帶來多大的麻煩，都應該在這個階段做一個評估，以決定該產品是否能夠發貨。
當一個問題確定遺留在系統中后，還需要對這個遺留問題有個明確的解決辦法，如：在升級版本中修改，建議用戶用以下方式繞過，或者干脆不再進行修改，都應該有一個明確的答復，而且還需要指派專門的人員跟蹤問題的解決情況，并進行報告。
4.在測試初始期確定的結項條件是否都得到了滿足？
為了能保證系統的正常交付，在前期和用戶做了一些交付的約定條件，在這個階段，需要確定這些條件是否都得到了滿足，并有相關的證明。
如：性能指標是否滿足用戶要求，用戶是否簽字確認。驗收測試是否完成，用戶是否簽字確認。后續的試運行期的方案是否完成，用戶是否同意，是否有明確的截至條件等。
總結
以上以一個測試監控者的角度，探討了如何對軟件測試工作進行監控。希望本文對大家的日常工作有些許借鑒意義。
筆者在本文的最后還想強調幾點：
1.監控是管理部門一項日常的工作
這件工作要在平時不停的進行，才能有效的改善產品的質量，而不是一時心血來潮的意氣之舉。
2.監控的目的是為了解決問題，而不是發現問題。
監控的目的不是為了證明我們的能力，而是為了能夠持續不斷的提高軟件開發的能力，能夠持續改進，所以發現問題并不是目的，解決問題才是根本。
3.對問題的判斷要準確，可驗證
作為監控者，同時也代表公司對這件事情進行的判斷，所以當發現問題的時一定要判斷準確，而且經的起復查，這樣才能避免不必要的麻煩，才能將更多的精力投入到處理事情本身的工作中。
4.質量的提高，工作的改進是一個漸進的過程，絕不能一蹴而就。
對于一個不太成熟的項目組，通過監控，可能發現很多的問題，這時不能太急躁，要心平氣和，一點一點的改進我們的過程。
5.通過分析，要先解決重要的事情，要有總體的規劃，而不是頭痛醫頭，腳痛醫腳。
發現的所有問題不可能都改正，這就要有個總體的策略，從大處招手，以公司的整體能力提升為要點，去區分解決問題的優先級，有節奏、有計劃的將公司引入持續改進的軌跡，逐步的提升公司的核心競爭力。
文章評論