部分 不能 評估 需求分析 業務 環境 並不是 後者 clas

聊聊測試管理（管事篇）

管理：管人+管事。 說到管理，其實就是團隊，沒有團隊，就談不上管理。個人理解，對個人而言，更多應該是計劃，而非管理。做管理的時間並不長，或者說很短，可能很多地方理解的有問題。寫這篇文章也是為了能更多的與大家交流，也是記錄下在目前這個階段我的理解。(本文均以在創業型公司工作為背景)，全篇分為管事篇跟管人篇。 管事篇 一、測試的工作流程。 關於這個點，其實網絡上一搜一大堆，大體都差不多，需求分析，測試計劃，設計測試用例，評審用例，執行測試，缺陷管理，定版，發布。但是，我認為作為一個測試leader，在一個創業型公司，並不是出一個這樣的流程這麽簡單。我覺得更多應該考慮的是適合公司的。在我制定我們團隊的測試流程時，與我們的項目經理，架構師甚至產品經理都有過很長時間的溝通，測試活動離不開產品，開發，所以在測試的工作流程中，應該包括如何去產品，開發更高效的去協作。下面講講我整理的測試工作流程。 1、需求分析 黑盒測試離不開需求分析，所有的測試都是基於需求，如果對於需求的理解不夠透徹，測試的質量也就可想而知。所以在這個階段，我會花很大量的時間去做。我團隊的需求分析主要包括：兩圖一文檔。 兩圖：業務流程圖，思維導圖。 一文檔：需求分析文檔。 業務流程圖，是對於需求從流程（整體）去理解。思維導圖，是對需求所包含的各項功能點去理解。需求分析文檔，是對思維導圖中的功能點去發散成為測試點。這樣下來，一個需求所表達的內容，基本不會漏掉。而更高層次的隱性需求，就需要對業務有著很深的理解，這點可以在工作中慢慢去引導團隊成員去做。流程上很難去控制。 2、測試計劃 網絡上的測試計劃，都是一個文檔，一大堆形式上的東西，可能對於大公司而言，有這個必要，我目前所見識的，基本都沒有必要。 我認為測試計劃主要給出以下幾點： （1）、測試類型：黑盒測試，接口測試，UI自動化測試，接口自動化測試，性能測試等等 （2）、測試時間：需求分析起止時間，設計測試用例的起止時間，執行測試的起止時間 （3）、測試執行人：創業型公司由於人員少的情況，很可能以項目（模塊）劃分測試負責人，也可以根據設計和執行來劃分測試負責人 一個測試計劃，有這三點，我個人認為就可行了。 3、測試用例 關於設計測試用例，可能很多在創業型公司工作過的小夥伴會說，時間很緊，壓根沒時間來做這個事。 這一點，我用了兩個月做了一個調研，前一個月不寫測試用例，大家就按照自己的思路去測試；後一個月，嚴格寫測試用例，執行測試集去測試。調研結果是：前一個月在測試開始時，測試速度稍微快點，在進入測試中後期，測試速度就很慢很慢，因為常見點已經測試完了，測試工程師自己都不知道哪些東西測試過了，哪些還沒？哪些沒有問題，哪些還有問題？不能很直觀的去管控。後一個月在開始時，由於寫測試用例的時間，速度會稍微慢點，但是在中後期，測試效率明顯比前一個月要好很多，測試工程師對於項目的把握也更清楚。兩者整個花的時間基本差不多。質量就更不用說了，肯定後者更有保證。 探索性測試，我覺得在業務能力以及測試經驗都很充足的情況下，可以結合編寫測試用例，去執行測試。一味的追求探索性測試，其實對於大多數測試工程師來講，很難。 目前，我的團隊是，測試工程師編寫好測試用例，先組內評審，然後導入到QC，測試人員根據QC測試集去執行測試，而我也能很直觀的把控測試進度，以及當然存在的問題。 4、測試用例評審 用例評審很重要，畢竟測試工程師也是人，也會有很多點是想不到的，所以用例評審就是一個查漏補缺的環節。用例評審不是找人茬，而是在這個過程中，補充測試思路，提升測試質量。 年前，這一項，我們沒有做，因為當時我們的測試工程師寫的用例還達不到評審的水平，所以只是組內評審。目前已經啟動用例評審。效果還待觀察中。 測試用例評審方法： （1）、提前郵件提醒評審相關人員（開發負責人，產品負責人，測試負責人，項目經理等），附件上測試用例。 （2）、1-2天後，組織用例評審會議，由於事前有看過需求跟用例，所以會議時間不建議很長，只要是查漏補缺，每個人都會有一些測試思路，也會發現已有的測試用例的不足。 （3）、根據會議記錄，將沒有考慮到的點維護成測試用例。定版。 定版後的測試用例，就可以用來執行測試了。 5、缺陷管理 缺陷，最重要的是，清晰明了的說明問題，重現步驟，以及如何解決。 效率的提高在於細節，缺陷管理工具上寫的不明了，也可以通過實時溝通來解決，但是溝通就需要時間，如果缺陷管理工具上，寫的很清晰明了，這溝通的時間成本就節省了。 一個缺陷就是一個用例，這個思想很重要，我經歷的公司，對於缺陷都是放在管理工具中，缺陷解決後，關閉，就沒有然後了。其實每一個缺陷都是一個優秀的用例，這些用例你可能已經寫了，也可能沒有，而沒有的話，就需要維護到測試用例中去，下次執行時，你就多預防一個點。 6、驗收測試 通常，通過測試的功能就會準備上線。但是上線前，還需要產品或者運營，來驗收需求。功能實現是否滿足需求，有沒有未考慮到的功能等等。產品或者運營做驗收測試時，我會給一個EXCEL文檔，作為他們記錄問題的LIST，每天跟我反饋下進度跟結果。如果有缺陷，再安排時間去解決。如果有需求上的缺陷，會定會議評審，在這次發布修改，還是下次發布修改。最後，上線與否，需要他們的確定。 二、測試時間 1、爭取測試時間 創業型公司，產品版本叠代快，周期緊，往往壓縮的是測試時間。而測試質量在一定程度上，與測試時間成正比，所以這點很矛盾。 測試時間需要爭取，因為項目時間很緊，資源更多的用於開發，上線時間確定後，基本上離上線時間只有2天時間才開發結束，才交付測試。而這麽短的測試時間，要保證測試質量很大，並且可能還需要大量加班。而測試時間的爭取，又需要測試質量作為依據。那麽怎麽來爭取測試時間呢？我認為是這樣的： （1）、盡量在開始時，哪怕加班也要做好質量保證，之後在爭取時間的時候，可以盡量拿質量作為理由來說； （2）、平常要多跟項目經理，架構師等聊聊產品質量，輸送質量意識，並多講講測試的重要性，不是每一個開發或者負責人，對於測試很重視的，盡管現在測試行業在快速發展。 （3）、就是在測試時間上，堅決不讓步。上線後，產品出現問題，很多時候，會讓測試背鍋，當然也有開發的原因，但是大家的想法是：這個問題怎麽沒有測試到？這個時候，你再說測試時間不夠，意義就不大了。 2、安排測試時間 測試時間的安排，需要根據測試人員本身能力定。能力強的，當然需要的時間短。大體上而言，我對於測試時間的安排如下： （1）、模塊內（模塊間交互少）的功能，需求分析時間和設計測試用例的時間為1天，執行測試的時間為2天（主要是缺陷修復時間），最後驗收時間為半天。 （2）、模塊間交互多的功能，需求分析和設計測試用例各1-2天，執行測試時間4-5天，最後驗收時間為1天。 （3）、系統級的功能需求，需求分析3天及以上，設計測試用例時間2-3天，執行測試時間一周以上，最後驗收時間為2-3天 主要策略是，需求分析的時間得保證，這個時間不能擠，畢竟這是測試最重要的部分。設計測試用例的時間可以稍微擠擠，這塊最主要的時間是需要寫文檔。測試時間多考慮缺陷修復時間，測試一輪下來可能很快，但是缺陷修復的時間就可能很久。最後需要驗收時間，產品或者運維對於該功能的驗收，看是否滿足產品需求。 三、測試進度與質量 1、測試進度 測試計劃確定後，接下來就是測試進度的把控了。進度的把握不是實時的要求測試工程師反饋，也不是自己想了解的時候就去問一下。需要有這麽一個規則，既可以直觀的查詢到目前的測試進度，又可以接受測試工程師的反饋。而我們團隊的規則如下： 1、使用項目管理工具：Teambiton，任務板上有每一個測試工程師在這次發布前的任務，每一個任務都有詳細的測試時間，能明了直觀的看到任務的執行情況。 2、執行QC測試集：QC測試集，是基於測試用例的執行，每一個用例的每一個步驟都有執行狀態，這樣在測試過程中，就能實時的查看到當前測試的進度。這個最為準確。有沒有偷懶，或者是否是應付式的工作都能看出來。 3、每天下班前，都會將今天的測試情況反饋給我。這一點準備改良，定為每天早上5-10分鐘站會。每一個人都需要講講昨天幹了什麽，今天準備幹什麽。時間長了，站會可以提高整個團隊的效率。 4、每天早上跟每天下班前，都需要檢查一次缺陷管理工具，查看今天已解決尚未驗證的缺陷是否已經處理完了。 如果出現測試進度很慢，跟預期嚴重不符，會先跟相關測試工程師討論，是預期時間不夠，還是測試工程師本身的問題，還是開發工程師的問題。這個時候就是需要測試leader來解決了。找到相應的問題並解決它。 如果出現測試進度過快，也需要去確認，防止為了趕進度而忽略質量的情況。 2、測試質量 行業內有一句話：測試不能保證軟件質量。我認為，雖然我們不能保證軟件質量，但是我們可以保證測試質量，盡量提高軟件質量。 測試的質量，是測試活動最重要的一環，所有之前的一切都是基於提高測試質量為目標的。那麽如何提高測試質量呢？ （1）、充足的測試時間。並不是時間越長越好。 （2）、全面的測試需求分析。 （3）、充分的測試用例設計。 （4）、測試人員的能力（管人篇詳細聊） （5）、做好驗收測試。 （6）、風險控制 等等。 四、線上跟蹤 我一直都認為，不管測試多麽精確，到線上後，都會存在問題。只是說測試可以盡量去減少這樣的情況發生。 如果產品上線後，出現問題，怎麽處理？ 第一時間，在測試環境中，重現。能重現，則找相應的開發工程師解決，再評估上線時間。如果不能重現，就直接找項目經理，評估解決辦法。 而一般而言，出現問題後，責任我會擔著（這是一種得人心的方法），事後會跟相關的測試工程師去探討出現這個問題的原因，是由於他自己引起的，就總結為什麽，爭取別在同一個地方跌倒兩次，對於他而言，是一種成長和進步。 結語 以上僅僅是個人的理解。希望大家能多探討。

軟件測試管理（管事）