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