（轉）如何規範小開發公司的測試流程。?

提問 | 希傑

轉自 | 知乎

連接 | https://www.zhihu.com/question/33406353/answer/417278125

 更多解答請查看知乎原文：https://www.zhihu.com/question/33406353/answer/417278125

如何規範小開發公司的測試流程。?

目前在一家創業公司上班，剛組建測試部門，領導讓我規範和創建測試流程。頭大。

 

1 號嘉賓一個比較懶的測試開發

7788：不邀自來。首先，做爲一個剛組建的測試部門Leader，特別是在小的創業公司，題主應該先關注目前項目開發過程當中存在的一些問題，如過需求不叫測試、開發提測質量差、用例覆蓋率低等等。其次，回到問題自己，根據答主多年的測試經驗，給出一些小小的建議。通常來講，通用的測試流程不外乎就是項目立項->需求評審->開發設計->設計評審->開發編碼->測試用例編寫->用例評審->功能測試->上線跟蹤 而後根據目前存在的問題制定一些特定的流程，目的就是爲了達到提升整個項目的質量和效率。答主目前在VPGAME(電競賽事平臺、賽事數據、互動娛樂)，咱們是從如下流程重點把關：

1、產品測

需求評審：開發、測試拿到產品的PRD文檔後，須要提早閱讀並標出有疑問的地方，在需求評審上提出並溝通達到一致。保證產品、開發、測試對需求的理解一致，前期的修改爲本是最低的。

2、開發測

開發設計：測試有條件的話應該參與到開發的設計評審和接口評審中，一方面能夠達到理解開發設計的思路和邏輯，對以後的用例設計起到幫助，另外一方面能夠及早的發現開發設計上的錯誤和遺漏，將維護成本降到最低

開發提測：爲了提升整個項目的效率，開發提測的質量也是相當重要的，若是出現一些流程性的問題，將影響到整個測試進度，因此測試這邊應該事先將冒煙測試用例提供到開發，開發把冒煙測試用例所有測試經過後纔可提測，測試接收到提測版本也應該先將冒煙測試用例過一遍，沒有問題方可開始測試，不然打回從新開發直到符合標準。

3、測試測

用例設計：我的以爲用例設計應該分爲兩部分，一是根據需求分解出測試功能點並標出優先級，二是根據功能點設計測試用例和流程方面用例。

上線前驗收：當項目達到上線標準時，應該出具測試報告發送至整個項目組，說明測試結果及存在的風險，並告知產品和運營能夠進行驗收測試，保證項目功能是符合他們要求的。

上線後跟蹤：這一點有時候會被忽視，這塊其實對測試來講也是有幫助的。若是線上有反饋問題，測試應該及時跟進，通知對應開發最快速度修復和總結出問題出現的場景和緣由，最後須要把場景和對應的測試策略測試方法補充到用例當中，下次測試的時候應該重點關注。

4、其餘

測試策略：好比自動化、持續集成、靜態代碼檢查、代碼覆蓋率、APP專項測試等等，這就看項目須要和實際狀況選擇進行。

客觀因素：需求變動等外部因素也常常打斷咱們的項目進度，咱們須要作的就是不停的溝通，能夠結合實際狀況加入晨會流程，天天溝通好昨天的進度、碰到的問題、今天的計劃，作到部門之間很透明。

以上是以VPGAME做爲案例，固然各個公司因業務不一樣，產品不一樣，存在必定的差別和區別。說到底，流程是用來提高效率的。最重要的是，題主須要根據本身所在的公司，加入本身的思考，這點纔是相當重要的。

附一張咱們目前簡單的流程圖

 

2 號嘉賓錢蓓蕾-網易測試總監

錢蓓蕾：在首頁看到這個話題，就不邀自來了。若是是剛組建測試團隊，那須要整理的流程可多了。

一、梳理測試流程，能夠重點把關的測試流程有：

需求Review：策劃完成的需求文檔必須讓開發、測試、運營進行Review，提出Review意見並最終改掉。這種Review能發現需求的漏洞並提前改掉，提升整個研發過程的效率。

測試用例Review：測試人員針對需求寫出粗略的用例點以後，再讓策劃、開發、測試、運營Review一遍，目的仍是發現需求的遺漏點，根據咱們的經驗，因爲測試人員已經思考了測試點，因此至關因而對需求的細化和剖析，這個Review環節仍是能發現不少需求的漏洞。

開發提測：測試人員事先發出冒煙測試用例，開發完成後，讓開發人員先根據冒煙用例進行自測，自測經過了之後才提交給測試，而後測試再根據相同的用例作冒煙測試。這樣能提升開發提測的質量。

上線前報告：上線之前，須要讓測試人員發一封報告，重點指出測試過程當中發現的問題、及上線之後可能會出的質量問題，並在項目羣裏面、或者召集開會把這些風險一一溝經過。若是有由於時間不足、或者由於客觀條件限制致使的測試不足的狀況，必定要在這個環節進行說明，這樣，若是上線之後出問題了，你們也能理解測試。

線上Bug Review：對於線上發現的Bug，若是沒有分析流程，測試人員須要制定線上Bug的分析流程，先重點分析這個線上Bug產生的緣由、線上Bug的影響範圍，而後你們一塊兒決定能夠有哪些改進措施能夠避免同類線上Bug再犯。這種改進措施須要能真正落實的，若是是無關緊要的改進措施，就不要提了。這個措施可讓你們一塊兒剖析線上Bug的產生緣由，一方面能夠避免項目組認爲都是測試的錯致使線上Bug，一方面，也發揮了測試人員質量保證的角色，推進流程讓質量更好。

二、肯定測試技術能夠提高的點：

環境部署：若是有技術積累，能夠把測試環境的部署拿來讓測試來作，這樣測試人員能夠本身控制測試的版本和配置。也提升測試人員的工做範圍。

性能測試：若是是流量很大的產品，須要專業的服務端性能測試人員來進行性能測試，對於測試的專業性提高有很大的價值。

專項測試：若是是APP產品，須要讓技術比較好的同窗來探索專項的測試，把APP端的性能、流量、電量等體驗提高上去。

題主能夠本身先評估須要引入上述哪些流程，而後，就是溝通、溝通、再溝通。所謂新官上任三把火，第一把火就是要把現有的狀況先摸清楚。跟本身的組員溝通、跟項目的開發負責人、產品負責人溝通、跟本身的老大溝通。清楚他們但願咱們重點改進的點，同時也把咱們想要推的流程、理念傳遞出去。

在推流程的時候，建議儘可能不要把本身站在產品的對立面，而是要跟產品站在同一邊，以產品的質量、開發效率等出發點來進行流程的推廣。你們相處愉快，整個團隊齊心合力，這纔是老大願意看到的局面。根據個人經驗，其實無論是開發負責人仍是老大，仍是比較願意尊重咱們的職業經驗，只要咱們真正站在產品的角度去溝通，大多數人仍是願意配合的。

 

3 號嘉賓佐撰

佐撰：謝邀。這個話題好大 先簡答一下吧。首先 制定流程的人必定要明白和堅守一個原則：流程不能是死的必須是活的 其次測試流程的核心是在保障研發效率的前提下提升產品質量  明白這兩點接下來的事就容易理順了

1）充分了解當前研發流程，對不合理的地方尤爲不要急於下定論和提出改進意見，而要充分了解歷史成因

2）跟領導聊天瞭解領導指望的將來的或理想的研發流程是什麼樣的，和現有流程的差距在哪裏、實現的難度在哪裏，在這兩點的指導下提出測試流程草案，除非是研發太扯蛋，不然最初的測試流程最好是在如今的研發流程上作少許提高和修改，草案要與領導與研發團隊共同討論，盡最大可能取得相關人員的理解和支持 試行 反饋 改進 無限循環，不要心急 ，不要指望一次到位測試流程通常包括但不限於如下內容：

- 測試團隊結構、崗位定義及職責範圍

- 相關合做團隊職責、主要聯繫人、溝通方式

- 產品研發週期、階段 （瀑布開發要考慮到大的release、小的release和hot fix的不一樣）

- 測試在研發整個週期的不一樣階段的任務和出品

- 測試類型（Unit test, Integration test, System test, UAT, performance test, etc）在本測試團隊內的定義

- 測試出品主要包括測試計劃、測試用例、缺陷報告、測試進度報告、測試完成報告（或質量評定報告），每項出品應該有相關模板和寫做規範

- 測試用例撰寫、審覈、執行、記錄執行結果的流程

- 缺陷管理流程

- 測試平臺、測試實驗室管理使用規範

- 測試進入和退出標準

- 測試工具管理

- 測試數據收集、統計和過程改進辦法

- 員工培訓計劃、組內知識共享計劃

嗯。。。這一大坨東西，沒兩年以上的沉澱是積累不出來的

4 號嘉賓JMasche-Tester，阿根廷足球，BBer

JMasche：強答一發吧。考慮流程以前，應該考慮的是大家公司的環境，或許這個纔是最重要的。因爲大家以前沒有測試部門，那麼大家老大創建測試部門的初衷是什麼？他想要達到什麼效果？這點很關鍵。若是他有想法，必須先弄清楚他的想法，再來查看實施可能性；若是他沒清晰的想法，那麼就須要不斷的經過溝通，提出你的想法，他來反饋意見。快速非正式迭代。爲何這個很重要呢？由於一旦測試部門創建起來，會出現兩個狀況：一、研發週期被拉長。這個是必定的，不管採起什麼辦法，都會被拉長。創業公司我沒呆過，想來對發佈速度是有要求的吧。二、質量有可能在短時間內降低。爲何呢？由於質量掌握在開發手上。而測試部創建起來以後，可能出現開發人員以爲有人兜底了，致使開發質量降低。後面有個號稱質量保障的部門了，多了個背鍋的傢伙。呵呵

上面這倆點合在一塊兒的最壞狀況是什麼呢？創建測試部後，研發週期拉長，而質量降低。開發抱怨測試帶來額外任務增多，並且還搞不定質量。因此，回過頭來，找老大，溝通：

一、爲何要創建測試部？原來出現嚴重質量問題？ok，這簡單搞定上線發佈環節就好了。若是隻是很模糊的須要測試，那就要肯定測試的範疇，能達到的效果。思考點包括：測試人力投入、測試周期。

二、基於第一點的範圍和目的效果，再往你上游的開發環節看，設立轉測試點要求，千萬不要多，找到最關鍵兩三點便可。這個環節要拉上開發負責充分溝通。

三、創建發佈評審機制。參與人員和輸出。

四、創建起問題單管理系統和機制，基於問題單給出質量晾曬機制。這點對老大有用，開發討厭。

我以爲剛開始搞定這些也就差很少了

5 號嘉賓天狼星

天狼星：正是我如今作的事，忍不住寫下來。首先看什麼樣的公司和什麼樣的產品以及周圍的人的技術水平，老大們的真實想法。核心仍是要從把當前產品出發，如何把產品測試好。這樣才能獲得老大甚至老闆的認同。另外建議先作好規劃和老闆彙報下，摸清楚他們的指望。不少老闆覺得有了流程產品質量就會變好，這種事要先解釋清楚，最終是要人執行和落地，而改革中也勢必會有阻力，這時候必定要老闆支持。而後技術上，不建議搞太多流程。技術上建議作如下幾個動做

一、控制版本發佈最好作到自動化，可參考使用jenkins，好處節約發版時間，避免測試版本與發佈不一致

二、控制開發後版本提交測試環節，開發必須輸出有效的功能清單和自測報告

三、推進需求端討論，驅動問題提早發現。

四、推進自動化測試

最好要看公司測試自己的職責。若是有其它質量部門負責制訂流程的話仍是要專人來作，制訂流程及落實的工做並非想象中一個兼職人員能夠完成的。補充我的觀點，好的流程不如好的工具和人員的習慣。以前看一篇文章寫Google 的 代碼評審，開發人員提交後自動進行靜態檢查，和送到評審員那裏不經過沒法提交。而對比華爲花大價錢搞的IPD 效果大量人力物力，效果暫且不評論了。

6 號嘉賓王小二-塵世中迷途小書童

王小二：和題主有相似的經歷，我的認爲最主要的是還要搞好與領導的關係，以及開發老大的關係。首先要弄清楚公司領導要你這麼作的目的是什麼，以及他的指望是怎樣的；其次要獲取領導的絕對支持，特別是測試與開發起衝突時的支持（雖然說測試與開發的大體利益是一致的，但實際操做中不免有衝突）；最後還要處理好與開發老大的關係，不然一些你想弄的流程、規範等等也很難推動落實。

至於具體的流程、規範，根據公司實際的狀況制定，而且多與領導、同事以及開發人員討論，實事求是、符合實際狀況是最重要的。在具體執行的過程當中，也要不斷的權衡與開發、公司等之間的利益關係，對一些開發人員以爲不滿的地方作好記錄和解釋工做，持續改進。

總之，我的以爲在小公司裏，人是最須要考慮的因素。

————————————————————————————————————————————————————————————————————————————————————

本文完