管理：管人+管事。
說到管理，其實就是團隊，沒有團隊，就談不上管理。個人理解，對個人而言，更多應該是計畫，而非管理。做管理的時間並不長，或者說很短，可能很多地方理解的有問題。寫這篇文章也是為了能更多的與大家交流，也是記錄下在目前這個階段我的理解。(本文均以在創業型公司工作為背景)，全篇分為管事篇跟管人篇。
管事篇
一、測試的工作流程。
關於這個點，其實網路上一搜一大堆，大體都差不多，需求分析，測試計畫，設計測試用例，評審用例，執行測試，缺陷管理，定版，發布。但是，我認為作為乙個測試leader，在乙個創業型公司，並不是出乙個這樣的流程這麼簡單。我覺得更多應該考慮的是適合公司的。在我制定我們團隊的測試流程時，與我們的專案經理，架構師甚至產品經理都有過很長時間的溝通，測試活動離不開產品，開發，所以在測試的工作流程中，應該包括如何去產品，開發更高效的去協作。下面講講我整理的測試工作流程。
1、需求分析
黑盒測試離不開需求分析，所有的測試都是基於需求，如果對於需求的理解不夠透徹，測試的質量也就可想而知。所以在這個階段，我會花很大量的時間去做。我團隊的需求分析主要包括：兩圖一文件。
兩圖：業務流程圖，思維導圖。
一文件：需求分析文件。
業務流程圖，是對於需求從流程（整體）去理解。思維導圖，是對需求所包含的各項功能點去理解。需求分析文件，是對思維導圖中的功能點去發散成為測試點。這樣下來，乙個需求所表達的內容，基本不會漏掉。而更高層次的隱性需求，就需要對業務有著很深的理解，這點可以在工作中慢慢去引導團隊成員去做。流程上很難去控制。
2、測試計畫
網路上的測試計畫，都是乙個文件，一大堆形式上的東西，可能對於大公司而言，有這個必要，我目前所見識的，基本都沒有必要。
我認為測試計畫主要給出以下幾點：
（1）、測試型別：黑盒測試，介面測試，ui自動化測試，介面自動化測試，效能測試等等
（3）、測試執行人：創業型公司由於人員少的情況，很可能以專案（模組）劃分測試負責人，也可以根據設計和執行來劃分測試負責人
乙個測試計畫，有這三點，我個人認為就可行了。
3、測試用例
關於設計測試用例，可能很多在創業型公司工作過的小夥伴會說，時間很緊，壓根沒時間來做這個事。
這一點，我用了兩個月做了乙個調研，前乙個月不寫測試用例，大家就按照自己的思路去測試；後乙個月，嚴格寫測試用例，執行測試集去測試。調研結果是：前乙個月在測試開始時，測試速度稍微快點，在進入測試中後期，測試速度就很慢很慢，因為常見點已經測試完了，測試工程師自己都不知道哪些東西測試過了，哪些還沒？哪些沒有問題，哪些還有問題？不能很直觀的去管控。後乙個月在開始時，由於寫測試用例的時間，速度會稍微慢點，但是在中後期，測試效率明顯比前乙個月要好很多，測試工程師對於專案的把握也更清楚。兩者整個花的時間基本差不多。質量就更不用說了，肯定後者更***。
探索性測試，我覺得在業務能力以及測試經驗都很充足的情況下，可以結合編寫測試用例，去執行測試。一味的追求探索性測試，其實對於大多數測試工程師來講，很難。
目前，我的團隊是，測試工程師編寫好測試用例，先組內評審，然後匯入到qc，測試人員根據qc測試集去執行測試，而我也能很直觀的把控測試進度，以及當然存在的問題。
4、測試用例評審
用例評審很重要，畢竟測試工程師也是人，也會有很多點是想不到的，所以用例評審就是乙個查漏補缺的環節。用例評審不是找人茬，而是在這個過程中，補充測試思路，提公升測試質量。
年前，這一項，我們沒有做，因為當時我們的測試工程師寫的用例還達不到評審的水平，所以只是組內評審。目前已經啟動用例評審。效果還待觀察中。
測試用例評審方法：
（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）、風險控制
等等。四、線上跟蹤
我一直都認為，不管測試多麼精確，到線上後，都會存在問題。只是說測試可以盡量去減少這樣的情況發生。
如果產品上線後，出現問題，怎麼處理？
第一時間，在測試環境中，重現。能重現，則找相應的開發工程師解決，再評估上線時間。如果不能重現，就直接找專案經理，評估解決辦法。
而一般而言，出現問題後，責任我會擔著（這是一種得人心的方法），事後會跟相關的測試工程師去**出現這個問題的原因，是由於他自己引起的，就總結為什麼，爭取別在同乙個地方跌倒兩次，對於他而言，是一種成長和進步。
測試管理，管人還是管事？
今天和乙個朋友聊天，聊到測試管理這個話題，朋友突然問我，你這個測試主管快要成光桿司令了，還管理什麼啊？我笑曰，我現在主要不是管人，是管事。玩笑歸玩笑，我倒是想來聊聊測試管理到底做些什麼。一般一提到管理，人們第乙個感覺就是管人，可能是被幾千年封建帝制禁錮了頭腦，說到管理就必須是人管人，人統治人，人使喚...
測試管理篇
需求分析注意事項 1.測試應盡早介入 介入越早發現問題越早解決問題成本越低 2.不斷變化的需求需要及時的收集和整理 3.沒有需求文件時，需要測試人員不斷的收集原始的客戶需求 4.要有質疑 堅持精神，當需求不明確時，我們可以將需求追溯到終端客戶。分析需求的具體方法 1.需求串講 主要解決問題 需求理解...
測試管理篇
完整的需求文件包括以下內容 需求分析注意事項 分析需求的具體方法 1 快速理解需求的捷徑 需求串講 主要解決的問題 需求理解不一致 方式 介紹需求背景 內容，進行答疑 2 驗證需求 需求文件也需要測試 正確性 必要性 完整性 一致性等。3 從設計需求中提取測試需求 軟體需求是軟體測試需求的主要 但不...