也談測試的進度控制與團隊管理

在很多時候，產品（或項目）總不能如期地發布（或結項），發布期總在不斷地推延，推延。大的產品有時會延遲一個月，幾個月，甚至半年以上。這是個普遍現象，因為每個軟件的測試過程都會受到諸多不定因素的影響。

    近日，和業內同行聊起過如何控制產品的測試進度問題。我認為，延遲問題是無法避免的，但這種風險卻可以盡量地降低。我不做測試已經8年了，但還是有一些深刻感悟：

一、制定切實可行的測試計劃，制定和執行計劃時注意幾個原則：

1、務實原則

        即，沒有把握的事情，不輕諾；已經答應的事情，不失信。

測試計劃應依據功能設計書制定，明確測試范圍和發布條件，合理地分配和調度測試資源。并考慮版本的復雜度，和功能的成熟度，以及預期發布時間，實事求是地劃分測試階段，且對各種突發情況進行風險預估。

2、前緊后松原則

   對于接手的任務，要做到"前緊后松，趕早不趕晚"，盡力地按時、甚至提前完成。Bug的發現也盡量密集在集成測試階段和系統測試初期。

3、重者為先的原則

    各種事務"按類別"、"分優先級"處理。分清輕重緩急，重者為先。Bug的處理也以功能性錯誤、死機死鎖、致命等優先級為高，邊緣死角問題為低的原則。

4、提前進入原則

    國內很多軟件企業，由于受測試人手、測試人員的編碼水平、以及公司對測試的認知程度等因素影響，很難做到由測試人員來做單元測試和白盒測試，更甭說從設計階段開始了。但是，測試經理應該盡可能地參與到設計階段，及早地了解需求動向，為測試前期做準備。測試團隊則應提前進入到集成測試階段，而不是從系統測試才開始。

    因為，做過單元測試后，集成測試再由研發人員來做的話，則很容易產生懶散心理。集成測試階段，測試人員的進入，則能和研發有效地互動起來，把許多明顯的bug攔截在提交系統測試之前。早在1998年，我就提出這一想法并親身實踐。結論是，測試進入得越早，對后期的進度把控就越有效。

二、輔助自動化手段

    自動化測試框架，雖然優點很多，但由于時間、人力、物力成本投入太大，以及企業對測試的重視程度、不同軟件的不同特性等諸多因素，還有相當長的一段路要走。最起碼從目前來看，完全采用自動化還不太現實。

    所以，可以把自動化測試作為一種輔助手段。對于有規律的、重復性強的、大數據量的，可批處理的，以及壓力測試等，采取自動化測試。

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