移動互聯網測試項目的風險管理

李敬林

【摘要】隨著移動互聯網業務的急速發展，軟件測試項目的管理也日新月異，傳統的測試項目管理方式也隨之接受新的挑戰。業務需求訊息萬變，開發測試周期縮短，敏捷開發，先商用再優化，各種各樣的新模式，新問題隨之而來擺在測試管理者和工程師面前，如何應對這些新問題，新風險呢？ 這就是此文需要闡述的。

【關鍵字】 移動互聯網 軟件測試 風險管理

引言

本文將從風險識別，風險影響評估，風險處理，風險監控四個方面來闡述測試項目的風險管理的觀點和概念。

我們先看看如何識別風險。首先，我們搞清楚什么樣的問題可以上升為風險，風險分為哪幾種類型。我們先看下面一個風險描述的例子：

一般來說，風險包括這么幾個要素，它屬于那種類型的，具體問題是什么，級別高低，誰負責跟蹤處理，當前狀態如何，還有應急措施是什么。

對應互聯網測試項目來說，風險的類別從來源來看，一般可以分為這么幾類：需求變更，測試人力，測試環境（軟件和硬件），測試周期，溝通協調，流程制度，缺陷管理。

當我們知道風險包括了哪些要素和風險的分類后，我們就可以在項目中發現和識別那類的問題需要列為風險對象進行管理。

我們先看需求變更類的風險，在移動互聯網項目中，來自客戶業務發起方的需求往往變化比較快，比如說，為了在某個節日舉行營銷活動，需要推出一款新的產品和業務，需要在軟件層面進行配合實現，當銷售市場部決定需要定制軟件或者修改軟件實現時，往往留給后臺研發人員的時間已經比較少，時間帶來風險壓力是不容置疑的。

對于此類風險，我們應該及時和市場業務部獲取最新的策略信息，從而根據當前測試人力和設備資源做好準備，同時要根據自己測試能力進行客觀評估，哪些功能需求是必須實現的，哪些功能需求是可選的，必須實現的功能需求里哪些功能是最重要的。在這里，可以通過建立需求跟蹤矩陣，確定功能實現的優先級，然后在短時間內實現最重要最有價值的功能需求。

另外，還有測試人力類的風險，這一類風險一般是多個測試項目同時啟動，測試人力需求在短期內劇增，或者是測試的核心骨干請假等情況。我們在測試人員的管理和復用上，往往都是一個測試人員從事多個項目或者多個業務的測試，若多個項目同時開展就會出現此類問題。 對于此類風險，我們在做測試計劃時就可以預見并識別，并納入到我們的風險管理表中。

同時，我們應該提前做好測試人力資源的儲備，培養一些備用的測試人力。測試團隊組成應該是有一定梯度的，骨干，普通測試人員和新手都要有人員。這樣，當測試人力需求高峰期來臨時，就可以充分的靈活應對。另外，在測試人員技能培養方面，也需要注意全面的發展和學習，可以建立測試人員的技能樹，記錄每個測試人員的對產品測試的掌握程度，利用項目的間歇期讓測試人員進行自我的學習和練習，最后讓其實現技能的全面發展。

下面我們再看看測試環境（軟件和硬件）類的風險，這類風險主要來源于測試硬件設備和軟件工具，license等。測試硬件設備容易理解，這里就包括了功能測試設備，性能測試設備，硬件設備的配置是否跟硬件需求匹配，數量是否足夠完成。

軟件類的就包括功能測試仿真工具，性能測試工具，數據庫，中間件和第三方軟件的license，這些都歸納為測試軟件環境帶來的風險。例如，某個項目需要使用oracle數據庫，但是license有效期將要結束，需要采購部門配合購買新的license。

還有，某個項目需要性能測試，但是現有的業界性能測試工具沒法滿足，需要開發一個適合本項目本產品的性能測試工具或者腳本，這些都是風險點所在。

在測試項目管理的過程中，我們需要全面考慮測試的軟硬件需求，從繁雜的項目管理中發現此類影響測試工作開展的風險問題。

鑒于篇幅的原因，后面還有測試周期，溝通協調，流程制度和缺陷管理類的風險就不再一一闡述了。然后我們看看如何評估風險的影響范圍。

以文章開頭第一個風險例子為例，我們看看如何評估具體某個風險的影響范圍。例如性能測試設備到位比較晚，那么就可能影響性能測試和調優的啟動的時間點，而一般產品發布都要求完成性能測試且性能指標達到要求，那么這個問題的影響范圍估計就是產品的發布。

這個影響范圍有時候不僅僅是項目內部的，還可能是項目外部的，例如，由于整個項目延期，測試人員沒法及時釋放，導致其他項目的測試受到影響，這也是風險的影響范圍。

我們在做風險評估的時候，要秉著客觀的態度，實事求是，這樣，我們做出的評估判斷才比較客觀實在，也比較讓項目組成員和公司領導接受。另外，這個影響范圍也決定了風險的級別，讓大家在茫茫的項目風險列表里找出重點解決的問題。

對于風險的影響范圍，有的影響僅限于測試組內的，有的會影響到開發組和需求組，設計組和客戶驗收，比如產品的系統測試完成時間延期，會影響客戶的驗收，產品的發布時間，從而對采購驗收也產生影響，所以，當我們評估時，需要考慮問題對項目組每個團隊小組的影響，以便其他團隊成員做好相應的準備和應對措施。

下面，我們談談風險的處理。當我們識別了風險，評估了風險的影響范圍后，我們就需要著手處理風險。再以第一個例子為例，當我們發現性能測試設備到位時間比較晚，影響性能測試的執行后，我們該怎么辦呢？ 是被動的等待，還是積極的想其他辦法，將風險降低到最小的影響嗎？ 當然不是，在這個例子中，項目組成員討論后，決定我們可以采用配置較低的設備先進行性能測試，提前發現一些基本的性能問題，待符合規格的硬件設備到位后再次進行性能測試，雖然前期的性能測試沒有在標準的服務器進行測試，但是這樣測試會提前完成測試腳本的開發，測試工具的準備，統計腳步的準備。

而且，雖然設備配置跟商用不完全一致，也有可能發現一些常見的性能問題，可以提前發現并解決，這樣，為后面用標準服務器的測試打下了鋪墊，掃除了一些障礙。

我們再看看一個人員方面的風險處理，也就是制訂應急措施。

例如，某個業務線需要規劃一個大版本，修改商用環境出現的各類問題，依據測試人員的技能和熟悉程度，我們安排測試人員A負責版本的回歸測試，A一直負責這個產品業務的測試，是最熟悉此產品的測試人員。可是，第一個版本測試到一半時，A提出了離職申請，問題單已經驗證了一半，還有的問題是驗證不通過，返回給開發重新修改了。上線時間已經確定了，版本測試剩余時間不多了，質量和進度風險明顯的出現了，怎么辦？

在此情況下，我們第一步是找一個對此業務相對熟悉的人接替A，例如測試人員B， A已經完成了第一輪的測試，有的問題單已經驗證過一次，雖然如此，我們還是需要B把已經驗證的問題單重新驗證一次，同時把相關案例再跑一次，這樣比較穩妥一點。同時，召集開發，測試一起，對所有的問題單重新梳理一次，分析每個問題單的修改點，哪些地方已經修復，哪些地方還需要繼續修改，做好會議記錄和會后的問題跟蹤。

當然，A測試人員還不能立馬離開，需要待B完全接手版本測試才可以離職。由于現在軟件外包服務比較常見，研發人員的變動是常見事情，所以我們盡量在某些產品業務上儲備2-3個核心的測試骨干，以便應對這種人員變動帶來的風險。

另外，若測試人員要離職，其工作質量是有所影響的，因為他（她）往往已經身在曹營心在漢，需要對其工作質量進行一個補充檢查。

最后，我們來談談如何監控管理風險。首先我們需要建立一張風險控制的跟蹤表，如文章開始所列的例子，記錄每個風險點的內容，影響范圍和狀態，同時要給每個風險分配責任人，也就是誰負責跟蹤解決此問題，推動問題的解決，更新風險的狀態和最新信息。

綜上所述，我們在參與移動互聯網測試項目時，需要學會識別風險點，評估風險的影響范圍，制訂風險的應對措施，然后對所有風險進行跟蹤和監控，達到高質量高效率的測試管理效果。