軟件測試過程的監控方法(2)

　　圖2：測試監理過程

　　1. 首先依據自己的經驗，問訊項目組的相關人員，看看項目的過程是否符合通常的測試規范。

　　2. 通過問訊，記錄發現的問題或者疑問

　　3. 通過詢問不同的項目組成員或查閱相關的文檔，核實發現問題或疑問的真實性

　　4. 匯總所有問題，評估各個問題的影響和風險，列出優先級

　　5. 給出可能的解決方案。注意，這里的解決方案不是指具體的解決方法，而是指激發項目組成員行動的可行的方案，如建議項目組開會討論可能的處理方式等。

　　6. 跟蹤解決方案，驗證問題是否真正得到解決。

　　以上是一個通行的監控過程，這里需要強調的一點是：不管出于什么理由對測試過程進行監控，但是發現問題絕對不是我們的目標，能夠有效的解決問題、降低項目的風險才是我們的目標，只有這樣的監控才是有價值的，對公司整體有利的工作。

　　對測試工作監控的方法，依據項目所處的不同階段我們分為三個部分進行闡述。

　　這三個部分暫且稱為：測試初始期，測試實施期，測試結項期

　　測試初始期

　　在這個階段，測試工作剛剛啟動或者才開始按照計劃實施測試工作，測試工作的啟動時間點在各個公司可能不同，有可能是：需求調研后期，集成測試期或者系統測試期等。具體在軟件開發的什么階段測試工作開始介入，并沒有一個一定的說法，關鍵要看所在公司的軟件開發活動的成熟度來靈活選擇，但是這點并不影響下面的討論。

　　作為測試工作的監控者，應該在那些重要環節上加以注意?首先請大家注意這個階段的特征：軟件開發工作已經開始，需求開發工作已經完成或者接近尾聲，以測試人員為主的測試工作正式啟動或者剛開始運行。

　　在以上的前提下，我們來說一說需要注意的監控點：

　　l 測試工作有沒有明確的工作范圍

　　這是在測試工作中最需要明確的，也是非常多的項目忽略的工作。在做測試工作之前，一定要非常明確準備對那些內容進行測試，預計達到的質量標準是什么，尤其是對那些不進行測試。

　　我遇到過的很多的測試經理都抱怨說：“我們不可能在前期把這些事情都弄清楚，開發人員都不知道產品將來是什么樣子，我們怎么知道需要測試那些內容?”咋一聽，感覺很有道理，但是情況是否真像大家說的那樣?作為公司，或者項目經理都希望能將項目做好，能生產出一件令用戶滿意的產品，如果這個假設成立的話，這也就是我們能夠改變現狀的動力。

　　首先，原先的那種做法已經多次證明是行不通的，所以只有改變我們的做法才有可能成功，前期先弄明白我們打算做什么并不是一個過分的要求。

　　其次，開發人員實際上并不是完全不知道他們打算生產什么樣的產品，而是就一些細節考慮的不夠，或者不周全。作為測試人員，一定要知道如何對一件產品的功能和性能怎么驗證，這實際上在幫助開發人員從使用者的角度上重新的審視一遍需求，也許這時候開發人員也說不清楚，那如果你和開發人員都非常清楚那些是明確的、那些是需要后面再補充的，也已經達到了我們的目的。

　　l 被測系統有無明確的性能指標?

　　對性能要求比較高的系統，需要在前期明確具體指標到底是多少?用何種手段進行確認?用戶是否認可這個指標的描述以及確認的方法。

　　性能指標一般從需求中對一些敏感的數字的描述中來，如：必須保證能處理30個在線用戶同時操作，主要業務系統響應時間不能大于1.5秒等。

　　針對這些數據，測試人員一定要細化數據背后的含義，使這些數據變得可驗證。如在規劃這些性能指標的驗證方式時，首先需要明確軟硬件的環境是什么?在此基礎上，還需知道什么叫30個在線用戶同時操作?都操作什么?這個場景應該怎么模擬?只有和這個指標相關的所有驗證方法都可行，而且得到了認可，在后續的測試活動中我們才能相信這條性能指標能夠進行測試。

　　l 測試工作有無明確的階段劃分(如單元、集成、系統、驗收等)?各階段是否有明確的交付確認條件?

　　實際過程中，我們都會將測試工作按照階段進行劃分，上面描述的是一個通常的劃分方式。在做監控工作時，還需要明確一點：這些階段的劃分是不是只有時間點的描述，而沒有各個階段之間可量化、可衡量的交付確認條件?

　　如果只有時間點的劃分，那我已經可以斷定，這個項目勢必會延期，原因是在整個生產活動過程中沒有明確的階段點交付的檢驗標準，問題肯定會沿著整個開發過程逐步的傳遞下去，終歸會在某一點爆發，最不幸的爆發點是在客戶處。

　　如果想盡量的避免上述的風險，就需要在開發過程中明確各個階段點之間的交付、確認條件。而且這些條件必須可量化、可衡量，決不能是含糊的，不易操作的，否則在實際操作過程中還是會將大量的問題推入下一個階段。

　　下面也以單元測試為例，看看怎么建立一個可量化、可衡量的單元測試階段的交付標準。

　　首先，需要確定開發人員是否進行了單元測試?？梢宰岄_發人員提交一份單元測試總結報告，上面需要大致的描述一下進行了那些單元測試。單元測試總結報告是否提交是一個可以量化的條件。

　　其次，需要評估一下單元測試的質量，主要可以通過如下方法：

　　是否有足夠的單元測試用例?可以對照詳細設計規定單元測試用例的數量，這是個量化的方法。

　　單元測試用例的通過率必須達到90%以上。

　　測試人員還可以抽樣執行開發人員編寫的單元測試用例，抽樣執行的單元測試用例的一次通過率必須在90%以上。這也是一個量化的方法，同時檢查了測試用例書寫的質量和單元測試執行的質量。

　　以上是一些常用的方式，而且這只是非常少的一部分，當給出確實可行的方法和可以量化的指標后，我們發現，評估一個產品是否達到了預計的質量要求就會變得相對容易很多，而且也避免了人為主觀判斷的尷尬。

　　l 最終的交付驗收有無和客戶確認通過的驗收標準和范圍?上線、割接和維護期有無明確的成功、失敗判定標準?

　　對于項目類的軟件開發，上面的監控非常重要。為客戶做項目的時候，一定要在前期和客戶確認怎么進行驗收，驗收通過的標準是什么，最好能形成書面的文檔，這樣才能在最后交貨的時候避免不必要的麻煩。而且，驗收標準和范圍應該是測試的一個最小測試集，要最大程度的確保正確性。

原文轉自：http://www.kjueaiud.com