做過幾個項目的測試執行負責人，有自己單獨負責測試的小項目，也有8、9個人組成的團隊進行的大項目測試，以下總結下測試執行負責人的職責和整個項目把控過程中的注意事項。實際項目測試活動主要有三部分組成：測試計劃，實際測試和總結文檔，以下也主要從這三個部分來介紹。
測試計劃
當老大告知要來一個項目，并讓我們作為測試執行負責人時，欣喜之余也要開始著手準備工作，也就是制定我們的測試計劃。首先要詢問老大，開發人員對應的項目負責人是誰，測試執行周期多長，測試人員有哪些，環境資源能提供多少。接下來就是與開發人員項目負責人溝通，要來的項目是個全新項目還是維護項目，測試的重點是什么，如是進行主要功能測試還是詳細測試等等，項目什么時候過來，有無產品需求說明書或說明文檔，各個模塊對應開發人員是誰及聯系方式等等。在這個過程中要特別注意幾點（這也是工作中遇到的問題）：項目中的功能可能有些是直接從其他開發團隊引進的，如圖片服務器，當我們發現圖片服務器bug時，上報bug時對應的開發責任人是誰，如果是其他組的開發人員，負責人是否提前與他們溝通，畢竟這不是他們本組的項目，可能出現不接或者不處理情況；召開測試和開發人員會議，或者直接與開發人員負責人溝通，統一對bug的定義，之所以這么說是因為我遇到過一個接口測試的項目，開發人員提供一個demo，讓我們測試接口調用是否正常。我是臨時接的這個項目，之前已測試幾輪，因為不能看源碼，就與開發人員溝通，因為有些缺陷看起來是提供的demo問題，但是接口有返回碼，函數對輸入值的具體處理或者是否處理我們不知道，為避免遺漏bug，如我們不能判斷是demo問題還是程序問題就都上報，他們最終同意這個處理意見，通過這種策略測試，發現了一些前兩輪沒有發現的問題。
當我們與老大和開發人員負責人溝通過之后，就開始執行測試計劃，這里要強調下要注重制定測試計劃過程，而不是測試計劃文檔結果。首先要進行任務分配，任務分配前要與各測試成員先溝通，了解下情況。就拿前階段負責的項目來說，包括我自己有9個人參加項目測試，有幾個是經驗豐富的老員工，幾個是剛入職的新人。因為對老員工平時的能力及負責的模塊都很了解，與他們溝通后，就把相關的主要模塊分配到個人，新員工主要是測試次線模塊和學習。分配完任務后，制定測試方案，制定測試說明文檔，測試說明文檔包括項目的簡單介紹，測試策略，測試重點，測試進度安排，各個測試人員負責模塊，各個模塊對應開發人員及聯系方式，測試時間等說明，然后郵件發給各個測試人員。如果能聯系到銷售人員或者技術支持人員更好，邀請他們給我們測試人員講解用戶使用習慣及用戶關注的主要功能，避免我們對主要功能的把握有偏差（可惜一直沒有做起來）。
接下來就是具體的準備工作了，這個過程是所有測試人員都參與的，如閱讀相關文檔，編寫測試用例（老員工編寫，新員工學習），評審測試用例，搭建測試環境等，這里略過。
實際測試
實際測試直接決定測試質量。作為測試執行負責人，我們大多數情況下也是參與測試的，執行負責人與測試執行人的區別就是要放眼于整個項目，把控整個項目的進度，這意味著你要承擔更多職責。還是拿上面的項目來說，首先安排冒煙測試，我們知道冒煙測試的側重點和觀察點是項目的主要功能是否有問題，是否影響后續測試，根據冒煙測試結果評估風險，判斷項目是否進入系統測試。但是對于新員工來說，什么是主要功能不是很好把握，如果有整理的有冒煙checklist好辦，沒有的話就很糾結，當時我就給他們講解冒煙測試，如何去測試，有什么問題問老員工，讓老員工輔導新員工，但是如果冒煙測試時間很緊的話，還是有點力不從心，老員工也沒有那么多時間，真心感覺到基礎的培訓很有必要。接著進入系統測試，當時提出讓每個測試成員每天反饋執行進度及發現的主要bug，這樣方便把控項目，實時調節人力資源。但是有些同事可能工作太忙很容易忘記寫，沒辦法只能硬著頭皮每天一個一個去問執行進度怎么樣，能不能按時完成測試任務等等。我得出的結論就是：作為測試執行負責人，能調節大家的積極性最好，不行的話，同事不積極，你就得積極。把發現的重大問題及時向上級反映，并每天報告測試進度，讓領導知道你在做什么，做到什么程度。
經手過幾個項目發現，有些老同事執行測試時，不按照測試用例來走，完全按照自己的思路來走，這個問題我也想過，如果按照執行用例來走，提高不了老員工的積極性，不按照測試用例走，可能是測試用例是自己寫的，每個測試點他們都知道，但是又怕同事遺漏測試點，到現場有問題。我自己的解決方法是等項目功能穩定以后按測試用例詳細測試一遍，后面幾輪按照員工自己執行策略來測，涉及到回歸測試用例篩選和探索式測試等等。說是這么說，但是有些同事不是這么做的，感覺這個問題還是沒有很好的解決，還在思考具體的解決方法，等待大俠指點。
實際執行中還遇到新員工看不懂測試用例的情況（真心感覺到測試用例很重要，特別是團隊中有新人），一般測試用例都是老員工來寫，新員工執行。這里主要有兩個原因，一是測試用例寫的不詳細明了，如是這種情況，及時更新測試用例；二是新人對業務不熟悉，可通過老員工給新員工講解業務流程或實際測試前讓開發人員給測試人員進行簡要培訓解決。主要還是編寫出高質量的測試用例最重要，我一直認為測試用例的顆粒度取決于時間和用例的可重用性，測試用例是一定要寫的，時間緊的話至少有個主要功能checklist，這也是工作成果物展示的一部分。具體測試用例的編寫就不介紹了，這里要提醒下編寫測試用例的人員，你們編寫的測試用例的質量及語言描述真的很重要。
還有就是與開發溝通問題，有些開發人員不是很好溝通，特別是新人與開發人員溝通時會遇到各種問題，這時測試執行負責人充當中間協調者的角色，一邊向同事了解情況，一邊與開發人員溝通，實在不行，就上報給老大，讓老大跟開發人員老大溝通，現實中發現一個很奇怪的問題：測試人員軟開發人員就硬，測試人員強硬點開發人員就很客氣。當然和氣最好，呵呵呵
總結文檔
測試結束后，所有測試人員要上交測試用例執行報告或測試記錄，測試執行負責人匯總后形成測試報告和總結，分析bug趨勢及原因；編寫主要問題說明，分析其風險，并反饋給上級和開發人員。整理出開發人員犯的低級錯誤，如reopen的bug，給的程序有毒，打包有誤等等，提交給老大，讓老大與開發負責人溝通，避免犯同樣的錯誤，影響我們的測試。
測試結束后測試活動，我總感覺組內少了一個很重要環節：bug分類分析，持續跟蹤。多數同事對提交的bug很少跟蹤，提交了就提交了，沒有盡量確保提交的bug修復了。缺少對bug沒有分類，如哪些是功能問題，哪些是UI問題，哪些是控件問題，這樣可以為下輪測試提供參考。還有就是開發人員置成Not A bug的缺陷，是測試人員理解錯誤還是開發人員的問題，以免下次犯同樣的錯誤。這也是自己以后應該注意的地方。（個人感覺這個問題還是小組老大出面處理好點，因為我發現測試執行負責人的權利不夠，呵呵）
名稱之所以為經驗總結一，我想剛作為測試執行負責人不久，對測試執行負責人的職責及項目各個階段的把握和掌控還有很多不足和需要提高的地方，但愿明年再寫一篇總結二，對測試執行負責人的職責有不一樣的看法和更多的經驗總結。
版權聲明：本文出自 沒翅膀的飛魚 的51Testing軟件測試博客：http://www.51testing.com/?363907
原創作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。