軟件測試管理（管事）

聊聊測試管理（管事篇）

 

管理：管人+管事。

說到管理，其實就是團隊，沒有團隊，就談不上管理。我的理解，對我的而言，更多應該是計劃，而非管理。作管理的時間並不長，或者說很短，可能不少地方理解的有問題。寫這篇文章也是爲了能更多的與你們交流，也是記錄下在目前這個階段個人理解。(本文均以在創業型公司工做爲背景)，全篇分爲管事篇跟管人篇。

管事篇

1、測試的工做流程。

關於這個點，其實網絡上一搜一大堆，大致都差很少，需求分析，測試計劃，設計測試用例，評審用例，執行測試，缺陷管理，定版，發佈。可是，我認爲做爲一個測試leader，在一個創業型公司，並非出一個這樣的流程這麼簡單。我以爲更多應該考慮的是適合公司的。在我制定咱們團隊的測試流程時，與咱們的項目經理，架構師甚至產品經理都有過很長時間的溝通，測試活動離不開產品，開發，因此在測試的工做流程中，應該包括如何去產品，開發更高效的去協做。下面講講我整理的測試工做流程。

 

一、需求分析

 

黑盒測試離不開需求分析，全部的測試都是基於需求，若是對於需求的理解不夠透徹，測試的質量也就可想而知。因此在這個階段，我會花很大量的時間去作。我團隊的需求分析主要包括：兩圖一文檔。

兩圖：業務流程圖，思惟導圖。

一文檔：需求分析文檔。

業務流程圖，是對於需求從流程（總體）去理解。思惟導圖，是對需求所包含的各項功能點去理解。需求分析文檔，是對思惟導圖中的功能點去發散成爲測試點。這樣下來，一個需求所表達的內容，基本不會漏掉。而更高層次的隱性需求，就須要對業務有着很深的理解，這點能夠在工做中慢慢去引導團隊成員去作。流程上很難去控制。

 

二、測試計劃

 

網絡上的測試計劃，都是一個文檔，一大堆形式上的東西，可能對於大公司而言，有這個必要，我目前所見識的，基本都沒有必要。

我認爲測試計劃主要給出如下幾點：

（1）、測試類型：黑盒測試，接口測試，UI自動化測試，接口自動化測試，性能測試等等

（2）、測試時間：需求分析起止時間，設計測試用例的起止時間，執行測試的起止時間

（3）、測試執行人：創業型公司因爲人員少的狀況，極可能以項目（模塊）劃分測試負責人，也能夠根據設計和執行來劃分測試負責人

一個測試計劃，有這三點，我我的認爲就可行了。

 

三、測試用例

 

關於設計測試用例，可能不少在創業型公司工做過的小夥伴會說，時間很緊，壓根沒時間來作這個事。

這一點，我用了兩個月作了一個調研，前一個月不寫測試用例，你們就按照本身的思路去測試；後一個月，嚴格寫測試用例，執行測試集去測試。調研結果是：前一個月在測試開始時，測試速度稍微快點，在進入測試中後期，測試速度就很慢很慢，由於常見點已經測試完了，測試工程師本身都不知道哪些東西測試過了，哪些還沒？哪些沒有問題，哪些還有問題？不能很直觀的去管控。後一個月在開始時，因爲寫測試用例的時間，速度會稍微慢點，可是在中後期，測試效率明顯比前一個月要好不少，測試工程師對於項目的把握也更清楚。二者整個花的時間基本差很少。質量就更不用說了，確定後者更有保證。

探索性測試，我以爲在業務能力以及測試經驗都很充足的狀況下，能夠結合編寫測試用例，去執行測試。一味的追求探索性測試，其實對於大多數測試工程師來說，很難。

目前，個人團隊是，測試工程師編寫好測試用例，先組內評審，而後導入到QC，測試人員根據QC測試集去執行測試，而我也能很直觀的把控測試進度，以及固然存在的問題。

 

四、測試用例評審

 

用例評審很重要，畢竟測試工程師也是人，也會有不少點是想不到的，因此用例評審就是一個查漏補缺的環節。用例評審不是找人茬，而是在這個過程當中，補充測試思路，提高測試質量。

年前，這一項，咱們沒有作，由於當時咱們的測試工程師寫的用例還達不到評審的水平，因此只是組內評審。目前已經啓動用例評審。效果還待觀察中。

測試用例評審方法：

（1）、提早郵件提醒評審相關人員（開發負責人，產品負責人，測試負責人，項目經理等），附件上測試用例。

（2）、1-2天后，組織用例評審會議，因爲事前有看過需求跟用例，因此會議時間不建議很長，只要是查漏補缺，每一個人都會有一些測試思路，也會發現已有的測試用例的不足。

（3）、根據會議記錄，將沒有考慮到的點維護成測試用例。定版。

定版後的測試用例，就能夠用來執行測試了。

 

五、缺陷管理

 

缺陷，最重要的是，清晰明瞭的說明問題，重現步驟，以及如何解決。

效率的提升在於細節，缺陷管理工具上寫的不明瞭，也能夠經過實時溝通來解決，可是溝通就須要時間，若是缺陷管理工具上，寫的很清晰明瞭，這溝通的時間成本就節省了。

一個缺陷就是一個用例，這個思想很重要，我經歷的公司，對於缺陷都是放在管理工具中，缺陷解決後，關閉，就沒有而後了。其實每個缺陷都是一個優秀的用例，這些用例你可能已經寫了，也可能沒有，而沒有的話，就須要維護到測試用例中去，下次執行時，你就多預防一個點。

 

六、驗收測試

 

一般，經過測試的功能就會準備上線。可是上線前，還須要產品或者運營，來驗收需求。功能實現是否知足需求，有沒有未考慮到的功能等等。產品或者運營作驗收測試時，我會給一個EXCEL文檔，做爲他們記錄問題的LIST，天天跟我反饋下進度跟結果。若是有缺陷，再安排時間去解決。若是有需求上的缺陷，會定會議評審，在此次發佈修改，仍是下次發佈修改。最後，上線與否，須要他們的肯定。

 

2、測試時間

 

一、爭取測試時間

創業型公司，產品版本迭代快，週期緊，每每壓縮的是測試時間。而測試質量在必定程度上，與測試時間成正比，因此這點很矛盾。

測試時間須要爭取，由於項目時間很緊，資源更多的用於開發，上線時間肯定後，基本上離上線時間只有2天時間纔開髮結束，才交付測試。而這麼短的測試時間，要保證測試質量很大，而且可能還須要大量加班。而測試時間的爭取，又須要測試質量做爲依據。那麼怎麼來爭取測試時間呢？我認爲是這樣的：

（1）、儘可能在開始時，哪怕加班也要作好質量保證，以後在爭取時間的時候，能夠儘可能拿質量做爲理由來講；

（2）、日常要多跟項目經理，架構師等聊聊產品質量，輸送質量意識，並多講講測試的重要性，不是每個開發或者負責人，對於測試很重視的，儘管如今測試行業在快速發展。

（3）、就是在測試時間上，堅定不讓步。上線後，產品出現問題，不少時候，會讓測試背鍋，固然也有開發的緣由，可是你們的想法是：這個問題怎麼沒有測試到？這個時候，你再說測試時間不夠，意義就不大了。

 

二、安排測試時間

測試時間的安排，須要根據測試人員自己能力定。能力強的，固然須要的時間短。大致上而言，我對於測試時間的安排以下：

（1）、模塊內（模塊間交互少）的功能，需求分析時間和設計測試用例的時間爲1天，執行測試的時間爲2天（主要是缺陷修復時間），最後驗收時間爲半天。

（2）、模塊間交互多的功能，需求分析和設計測試用例各1-2天，執行測試時間4-5天，最後驗收時間爲1天。

（3）、系統級的功能需求，需求分析3天及以上，設計測試用例時間2-3天，執行測試時間一週以上，最後驗收時間爲2-3天

主要策略是，需求分析的時間得保證，這個時間不能擠，畢竟這是測試最重要的部分。設計測試用例的時間能夠稍微擠擠，這塊最主要的時間是須要寫文檔。測試時間多考慮缺陷修復時間，測試一輪下來可能很快，可是缺陷修復的時間就可能好久。最後須要驗收時間，產品或者運維對於該功能的驗收，看是否知足產品需求。

 

3、測試進度與質量

 

一、測試進度

測試計劃肯定後，接下來就是測試進度的把控了。進度的把握不是實時的要求測試工程師反饋，也不是本身想了解的時候就去問一下。須要有這麼一個規則，既能夠直觀的查詢到目前的測試進度，又能夠接受測試工程師的反饋。而咱們團隊的規則以下：

一、使用項目管理工具：Teambiton，任務板上有每個測試工程師在此次發佈前的任務，每個任務都有詳細的測試時間，能明瞭直觀的看到任務的執行狀況。

二、執行QC測試集：QC測試集，是基於測試用例的執行，每個用例的每個步驟都有執行狀態，這樣在測試過程當中，就能實時的查看到當前測試的進度。這個最爲準確。有沒有偷懶，或者是不是應付式的工做都能看出來。

三、天天下班前，都會將今天的測試狀況反饋給我。這一點準備改良，定爲天天早上5-10分鐘站會。每個人都須要講講昨天干了什麼，今天準備幹什麼。時間長了，站會能夠提升整個團隊的效率。

四、天天早上跟天天下班前，都須要檢查一次缺陷管理工具，查看今天已解決還沒有驗證的缺陷是否已經處理完了。

若是出現測試進度很慢，跟預期嚴重不符，會先跟相關測試工程師討論，是預期時間不夠，仍是測試工程師自己的問題，仍是開發工程師的問題。這個時候就是須要測試leader來解決了。找到相應的問題並解決它。

若是出現測試進度過快，也須要去確認，防止爲了趕進度而忽略質量的狀況。

 

二、測試質量

行業內有一句話：測試不能保證軟件質量。我認爲，雖然咱們不能保證軟件質量，可是咱們能夠保證測試質量，儘可能提升軟件質量。

測試的質量，是測試活動最重要的一環，全部以前的一切都是基於提升測試質量爲目標的。那麼如何提升測試質量呢？

（1）、充足的測試時間。並非時間越長越好。

（2）、全面的測試需求分析。

（3）、充分的測試用例設計。

（4）、測試人員的能力（管人篇詳細聊）

（5）、作好驗收測試。

（6）、風險控制

等等。

 

4、線上跟蹤

 

我一直都認爲，無論測試多麼精確，到線上後，都會存在問題。只是說測試能夠儘可能去減小這樣的狀況發生。

若是產品上線後，出現問題，怎麼處理？

第一時間，在測試環境中，重現。能重現，則找相應的開發工程師解決，再評估上線時間。若是不能重現，就直接找項目經理，評估解決辦法。

而通常而言，出現問題後，責任我會擔着（這是一種得人心的方法），過後會跟相關的測試工程師去探討出現這個問題的緣由，是因爲他本身引發的，就總結爲何，爭取別在同一個地方跌倒兩次，對於他而言，是一種成長和進步。

 

結語

以上僅僅是我的的理解。但願你們能多探討。