我是如何做測試項目管理的

帶項目差不多1個季度了，針對這一季度的工作做一個總結，分析一下成長和遇到的問題，希望後面可以做的更好。

以下内容有自己的總結，也有參考蔡為東老師的步步為赢—軟體測試管理全程實踐。

項目内容：IOS端項目

人員：測試組内——4人（包含我）；開發組——10人（包含開發leader）；産品組——1人（單獨跟進IOS相關進度）

測試組主要工作職責：做好測試工作，以最少的人力、物力和cost産出符合需求、保障品質的産品。

測試項目管理主要内容：

項目就是一件事，那麼項目管理就是通過某種方式來做成這件事情。測試項目管理主要包含測試流程的制定、根據制定的測試流程，控制三方（包含需求方、開發方、測試方）工作進度、工作流程以及溝通等，最終保障産出需要的東西。

作為測試組長，站在這個角度上，對于測試管理的了解是什麼？

1、心态的轉變——從一個初級工程師，到一個中級工程師，是對自己手頭被配置設定的任務有了一個更深入的認知和了解；再到測試組長，就需要完成從點到面的過渡，看問題需要有大局觀，需要把握整個項目，很多邊緣邊界的問題，以及互相牽扯的子產品，互相有互動工作的團隊，都需要考慮到，對于你的思維的整體性、溝通的能力、考慮問題的全面性，以及多線程工作的能力，都會是一個考驗。

2、建構測試體系——明确測試流程，該流程是各方都需要明确的，這樣協調工作起來才能有條不紊，主要是指：需要測試盡早介入；需要給測試留出時間和準備資源；軟體測試小組需要編寫正式的測試計劃和測試用例，并且需要做評審；管理好測試環境（保證測試環境的單一性，不受其他的影響，能夠盡快确認是問題并且能夠盡快定位問題）；為提測版本做驗證測試（驗證測試就是從用例中挑選出最精簡的測試用例集合）；測試正式開始前開發需要自測；測試正式開始前要做可接受性測試（即從用例中挑選出P0級别的，也就是本次提測内容的最主要功能實作），不滿足的打回；明确bug管理流程（包括需求bug——由産品提出；提測後功能性bug——由測試産出；在這個過程中隻有測試有權利關閉bug，要及時三方對bug情況）；

測試組需要寫測試報告（目前為每天晚上針對當天的測試情況給出報告：包括提測情況、測試情況、bug情況、明日計劃；其中bug情況需要統計當日bug總數、當日修複bug數、各個子產品的bug、嚴重bug數、reopen的bug數，這些資料主要是為版本釋出後的項目複盤做統計的；其中bug情況要針對當天的bug情況做一個總體說明，嚴重bug亟待解決的需要重點标出，産品上的bug也要說明，請産品盡快跟進解決）；項目釋出後要做項目複盤（目前我們主要是每個版本結束後，做一次項目總結，針對整個版本從需求到最終的釋出階段的各種問題，以及解決方案，以及上一期遺留問題及解決情況等一一做說明和彙總，隻有不斷總結和推進解決，才能夠讓整個項目組的情況越來越好）

組建測試團隊（該内容目前我并沒有做過，因為項目人員是由上面配置設定的，但是對組内人員确實要進行關心，你的真誠是基本）

編寫各種模闆檔案（目前組内已經推廣建立起來的包含：開發的提測模闆、測試的bug模闆、開發的bugfix模闆、測試報告的基本模闆、測試總結的模闆；當然各個版本都可以視情況進行專項調整；那麼沒有建立起來的包括：測試計劃，該内容在目前環境下因為是推進産品比較緊張，是以一直沒有做過，後期确實需要做出來：最主要是嚴禁開發提測晚，壓縮測試的時間）

搭建Bug管理系統、測試用例管理系統，我們現在用的Bug管理系統是Bugzilla、測試用例管理系統是TestLink，主要使用過程中感覺Bugzilla比較好用，TestLink的話就稍顯遜色，但目前還沒有發現更好用的，也許excel更好用，哈哈。（注：确實要有機會要自己搭建一下這兩個系統，這樣才有真正的實戰經驗啊！）

其實說到底，這些就是：人、流程、模闆、以及對流程中的産出的管理。

3、關于測試計劃的編寫：測試計劃的編寫，我這裡确實有疏漏，因為一直沒怎麼做過，沒有很好的經驗，這些後期要逐漸補上來。

4、溝通，溝通其實就包含對内和對外兩種，對内又包含對上和對下，以及同級三種，對外又包含對開發、對産品、對總的負責leader

對内——對上：讓上司知道你在做什麼，及時溝通，有問題當然要自己掌握度，不能事無巨細全部問上司如何處理，一般上司隻喜歡做選擇題也不喜歡做問答題，你需要有自己的判斷，然後從中選擇一些你不好推動或者需要他出面，或者一些事情上首次處理無很多經驗的情況下，要及時跟上司溝通，告知當下情況，當然要說出你的解決方案或者你的見解，并在上司推進解決問題，或者他提出一些方案之後能夠盡快學**到自己身上；當然及時告知也是為了避免出現事後無法補救才打臉的情況，提前告知風險，提前預知情況，能夠有更好的心理準備。上司其實也是你的老師，要跟他多學**，不要怕，學**他的經驗，學**他處理事情的方式，并主動在一段工作時間之後進行個人彙報總結以及小組彙報總結，及時回報和得到上級回報，如此才能不斷進步，往更好的方向走。

對内——對下：要真誠；要有個人的能力和德行作為服衆的一個基礎，是以要不斷學**、總結、提高個人工作能力；要開放和公平，營造出這樣的氛圍才能人心不失；要量才用人；要及時溝通；對于自己指導的學員，更要及時溝通，能夠讓學員從工作中學到東西；建立起整個組内的學**、創新意識和氛圍（這是我覺得需要做的，雖然目前項目太緊張，做的很不好，隻是自己在之前不是組長時做過，但上任組長之後事情太多自己也擱置了，确實是需要調整）

對内——對同級：對同級也抱着學**的心态，多溝通，多聊多問，解自己的工作疑惑，也聽他人的五味雜陳，吸取經驗和教訓，盡量減少坑和彎路，哈哈。

對外——對開發：要實事求是，遇到問題就事論事，測試與開發可能經常會因為一些問題争吵，但不要影響互相之間的合作，這是前提，否則将來的工作無法繼續開展；要盡快溝通：大多數情況下确實是應該直接找單人私下溝通，比如一些比較嚴重的問題（涉及到類似提測失敗、reopen率太高這樣的情況），讓此人了解自己的問題，但不可縱容，對這種情況的縱容就是對測試工作的阻礙；對一些嚴重問題，還需要找開發的上級上司溝通，讓他做到心中有數，也将自己的觀點和期望表達清楚，但一切都是建立更好的做好工作的基礎上；對一而再、再而三的出現嚴重問題的情況，需要嚴厲、嚴重、特别的提出來，如此才能夠推進一些改革和改進的更好推行，友善開發建立起流程，也是對測試工作的一種支援。

對外——對産品：說實話，每個人站的立場是不同的，産品是關注功能和體驗更多，關注我怎麼做能用的更好；開發關注的是我實作起來有木有難度，測試是測試這個流程和邏輯有沒有漏洞、也包含這個體驗是不是不好。很多産品人員确實不懂技術，在一些邏輯和流程的考慮上可能确實不夠周全，這些問題盡量要盡早提出來。對産品而言，要站在更多的使用者角度上，來對其講解自己對流程及邏輯上不合理的地方；當然也要自己多發現新産品和多使用競争對手的産品（這裡目前做的還不夠好），這樣才能更有說服力，因為很多産品都是從競争對手和其他類似産品那裡借鑒來的東西。

對外——對總的負責leader：定期彙總上報工作内容，目前是通過項目總結的方式來做的，這樣能讓最上面的leader知道問題在哪裡，并盡快借力來推進很多問題的解決。

5、測試用例的編寫：用例的編寫最重要，用例考慮的詳盡、步驟清晰，關注多個不同方面，才能夠從多個方面發現問題。

組織編寫測試用例，流程主要分為以下幾步：

明确任務和進度

提供相關的資料和條件

全面深入了解軟體需求

編寫測試用例的概要（測試點）

做測試用例的評審

細化測試用例

對測試用例保持動态更新（一定要堅持做，并且要總結出易錯點，保證每次回歸時覆寫到，并在之後的測試中關注類似的方面）

之前在其他文章中也提過用例的編寫的一些考慮點，比如需要從：相容性（包含大環境和小環境下的相容；包含新舊版本的相容）、基本功能和邏輯、使用者體驗、異常情況處理、不同網絡情況處理（比如目前測試app相關基本上都跟網絡關系密切，必須對不同的網絡情況做處理）、針對所測試的内容做特殊case的測試（比如與聲音相關的：做不同距離測試等）

主要包括：測試點的梳理（測試點很重要，需要從不同方面、以及大面大點上全部涵蓋到）；測試點及測試概要的用例評審（這個很重要，有兩個評審時間：測試開始前和一輪測試之後；其實一輪測試之後，大家拿到實際産品測試使用了，能夠對産品了解更深入，也能夠想到更多方面或者問題等）；測試點的細化（細化到具體的測試用例，需要明确測試步驟和預期結果）

6、測試執行：執行階段需要明确責任，鼓勵機制，并建立起整個測試組都及時發現問題、跟進、推進自己名下問題解決的氛圍快速建立起來，不止是為了發現問題，最重要的是發現之後推進問題的解決；當然在測試組長的角度上，就需要同時做多項工作，需要自己做相關的部分測試工作，還需要及時跟進其他成員的測試情況（這裡定期的溝通、抽查和咨詢就很重要了），也需要對大家所報的bug有一個大概的認知，能從bug的情況以及bug的趨勢上看出大概目前進行到什麼測試階段了

測試執行的安排也很重要，一般情況下重要的子產品會配置設定給比較有經驗的人來做；如果人手不太緊張，可以大家一起做，其他新人能夠在這個過程中不斷像其他經驗豐富的人學**。

測試組長要閱讀每一個Bug，這個要求并不過分，這個目前卻做得很不好。

7、測試總結：測試總結很重要，包括項目整理的總結、個人的總結、小組的總結；做項目總結，是為了梳理整個過程，明确問題和找到原因，改進整個流程和推進項目狀态越來越好。

自己目前所做的是項目的總結，會針對三方做一個總結，分别是開發、産品和測試，總結要主體上基于目前版本項目做，也需要對之前版本做回顧，以及在目前版本項目上之前的問題是否有所改進。因為目前基本上是10天一個app的版本，基于比較重要的版本，基本上都做了回顧，最重要的還是基于問題，要找到解決方案，并且最重要的是：跟開發負責人、産品負責人溝通，跟自己組内人員溝通，一起來執行解決方案，并且要确實嚴格執行（針對不執行的，要有一定的懲罰制度，讓大家都了解執行的重要性和必要性）

那麼一個基本通用的模闆如下：

測試計劃執行情況：看實際情況有麼有按照計劃執行，如果沒有，找出阻礙和原因，是否可解

Bug庫分析：包括Bug的有效率、各優先級的Bug所占的比率、各子產品的Bug分布比率、測試工程師的Bug發現率、Bug的修複率、各階段發現的Bug發現率、Bug的生命周期

其實可以通過問自己N個方面的問題，來豐滿每次的總結：人員安排、時間安排、風險分析、測試執行、Bug、溝通、項目管理、員工管理，這些方面的總結需要根據不同的送出對象進行不同方面的删減和充實。

在自己帶項目的整個過程中目前為止遇到的問題？如何處理的？目前自己認為可能需要加強或者需要後續更加關注的内容？

1、目前為止遇到的問題及處理措施：

跟開發團隊之間的溝通問題：主要大家來自不同的團隊，剛開始的工作态度都會有不同，這個時候視問題的嚴重程度，有些時候确實需要采取一些強硬措施，當然提前跟開發負責人打招呼是比較好的一種方式

開發團隊遇到很多問題，因為對産品品質的認知不足導緻不願意解決，甚至有問題但是無法立即定位原因的，會拖N個版本也不解決：通過郵件方式、通過會議說明、通過項目總結、通過每天的項目測試情況的彙報，通過各種方式說明，并明顯注明（需要告知開發負責人、開發組的上級leader），告知開發需要解決，并且需要組内指派人員單獨跟進，并關注跟進的結果

對開發團隊不斷出現Bug反複、提測品質不高的問題：一個是态度問題，一個是能力問題；能力問題也需要找開發負責人溝通，由開發負責人來按照各人的能力配置設定工作子產品，或者開發組内自己制定其他措施等，測試這方就是要告知開發需要明确的提測模闆（包含提測檔案名、提測路徑、提測說明，提測說明中包含詳細的資訊：正式環境或測試環境等，提測子產品，影響範圍、建議重點關注内容、修複Bug）、提測标準（測試點提前準備好，給開發做自測，需要自測之後功能上無明顯Bug才可提測）；态度問題就是：多溝通、測試人員單獨找對應開發溝通，積極追自己名下的問題，将測試的情況及時回報給開發負責人，讓開發負責人來督促他們及時解決問題，制定各種模闆，包含提測模闆、bugfix模闆、bugreopen率統計及處理措施等

2、後續需要關注的問題：