提問 | 希傑轉自 | 知乎鏈接 | https://www.zhihu.com/question/33406353/answer/417278125
如何規范小開發公司的測試流程。?
目前在一家創業公司上班，剛組建測試部門，領導讓我規范和建立測試流程。頭大。
1 號嘉賓一個比較懶的測試開發
7788：不邀自來。首先，作為一個剛組建的測試部門Leader，特別是在小的創業公司，題主應該先關注目前項目開發過程中存在的一些問題，如過需求不叫測試、開發提測質量差、用例覆蓋率低等等。其次，回到問題本身，根據答主多年的測試經驗，給出一些小小的建議。一般來說，通用的測試流程不外乎就是項目立項->需求評審->開發設計->設計評審->開發編碼->測試用例編寫->用例評審->功能測試->上線跟蹤 然后根據目前存在的問題制定一些特定的流程，目的就是為了達到提高整個項目的質量和效率。答主目前在VPGAME(電競賽事平台、賽事數據、互動娛樂)，我們是從以下流程重點把關：
一、產品測
需求評審：開發、測試拿到產品的PRD文檔后，需要提前閱讀並標出有疑問的地方，在需求評審上提出並溝通達到一致。保證產品、開發、測試對需求的理解一致，前期的修改成本是最低的。
二、開發測
開發設計：測試有條件的話應該參與到開發的設計評審和接口評審中，一方面可以達到理解開發設計的思路和邏輯，對之后的用例設計起到幫助，另一方面可以及早的發現開發設計上的錯誤和遺漏，將維護成本降到最低
開發提測：為了提高整個項目的效率，開發提測的質量也是至關重要的，如果出現一些流程性的問題，將影響到整個測試進度，所以測試這邊應該事先將冒煙測試用例提供到開發，開發把冒煙測試用例全部測試通過后才可提測，測試接收到提測版本也應該先將冒煙測試用例過一遍，沒有問題方可開始測試，否則打回重新開發直到符合標准。
三、測試測
用例設計：個人覺得用例設計應該分為兩部分，一是根據需求分解出測試功能點並標出優先級，二是根據功能點設計測試用例和流程方面用例。
上線前驗收：當項目達到上線標准時，應該出具測試報告發送至整個項目組，說明測試結果及存在的風險，並告知產品和運營可以進行驗收測試，保證項目功能是符合他們要求的。
上線后跟蹤：這一點有時候會被忽視，這塊其實對測試來說也是有幫助的。如果線上有反饋問題，測試應該及時跟進，通知對應開發最快速度修復和總結出問題出現的場景和原因，最后需要把場景和對應的測試策略測試方法補充到用例當中，下次測試的時候應該重點關注。
四、其他
測試策略：比如自動化、持續集成、靜態代碼檢查、代碼覆蓋率、APP專項測試等等，這就看項目需要和實際情況選擇進行。
客觀因素：需求變更等外部因素也經常打斷我們的項目進度，我們需要做的就是不停的溝通，可以結合實際情況加入晨會流程，每天溝通好昨天的進度、碰到的問題、今天的計划，做到部門之間很透明。
以上是以VPGAME作為案例，當然各個公司因業務不同，產品不同，存在一定的差異和區別。說到底，流程是用來提升效率的。最重要的是，題主需要根據自己所在的公司，加入自己的思考，這點才是至關重要的。
附一張我們目前簡單的流程圖
2 號嘉賓錢蓓蕾-網易測試總監
錢蓓蕾：在首頁看到這個話題，就不邀自來了。如果是剛組建測試團隊，那需要整理的流程可多了。
1、梳理測試流程，可以重點把關的測試流程有：
需求Review：策划完成的需求文檔必須讓開發、測試、運營進行Review，提出Review意見並最終改掉。這種Review能發現需求的漏洞並提早改掉，提高整個研發過程的效率。
測試用例Review：測試人員針對需求寫出粗略的用例點之后，再讓策划、開發、測試、運營Review一遍，目的還是發現需求的遺漏點，根據我們的經驗，由於測試人員已經思考了測試點，所以相當於是對需求的細化和剖析，這個Review環節還是能發現很多需求的漏洞。
開發提測：測試人員事先發出冒煙測試用例，開發完成后，讓開發人員先根據冒煙用例進行自測，自測通過了以后才提交給測試，然后測試再根據相同的用例做冒煙測試。這樣能提高開發提測的質量。
上線前報告：上線以前，需要讓測試人員發一封報告，重點指出測試過程中發現的問題、及上線以后可能會出的質量問題，並在項目群里面、或者召集開會把這些風險一一溝通過。如果有因為時間不足、或者因為客觀條件限制導致的測試不足的情況，一定要在這個環節進行說明，這樣，如果上線以后出問題了，大家也能理解測試。
線上Bug Review：對於線上發現的Bug，如果沒有分析流程，測試人員需要制定線上Bug的分析流程，先重點分析這個線上Bug產生的原因、線上Bug的影響范圍，然后大家一起決定可以有哪些改進措施可以避免同類線上Bug再犯。這種改進措施需要能真正落實的，如果是可有可無的改進措施，就不要提了。這個措施可以讓大家一起剖析線上Bug的產生原因，一方面可以避免項目組認為都是測試的錯導致線上Bug，一方面，也發揮了測試人員質量保證的角色，推動流程讓質量更好。
2、確定測試技術可以提升的點：
環境部署：如果有技術積累，可以把測試環境的部署拿來讓測試來做，這樣測試人員可以自己控制測試的版本和配置。也提高測試人員的工作范圍。
性能測試：如果是流量很大的產品，需要專業的服務端性能測試人員來進行性能測試，對於測試的專業性提升有很大的價值。
專項測試：如果是APP產品，需要讓技術比較好的同學來探索專項的測試，把APP端的性能、流量、電量等體驗提升上去。
題主可以自己先評估需要引入上述哪些流程，然后，就是溝通、溝通、再溝通。所謂新官上任三把火，第一把火就是要把現有的情況先摸清楚。跟自己的組員溝通、跟項目的開發負責人、產品負責人溝通、跟自己的老大溝通。清楚他們希望我們重點改進的點，同時也把我們想要推的流程、理念傳遞出去。
在推流程的時候，建議盡量不要把自己站在產品的對立面，而是要跟產品站在同一邊，以產品的質量、開發效率等出發點來進行流程的推廣。大家相處愉快，整個團隊齊心協力，這才是老大願意看到的局面。根據我的經驗，其實不管是開發負責人還是老大，還是比較願意尊重我們的職業經驗，只要我們真正站在產品的角度去溝通，大多數人還是願意配合的。
3 號嘉賓佐撰
佐撰：謝邀。這個話題好大 先簡答一下吧。首先 制定流程的人一定要明白和堅守一個原則：流程不能是死的必須是活的 其次測試流程的核心是在保障研發效率的前提下提高產品質量 明白這兩點接下來的事就容易理順了
1）充分了解當前研發流程，對不合理的地方尤其不要急於下定論和提出改進意見，而要充分了解歷史成因
2）跟領導聊天了解領導期望的未來的或理想的研發流程是什么樣的，和現有流程的差距在哪里、實現的難度在哪里，在這兩點的指導下提出測試流程草案，除非是研發太扯蛋，否則最初的測試流程最好是在現在的研發流程上做少量提升和修改，草案要與領導與研發團隊共同討論，盡最大可能取得相關人員的理解和支持 試行 反饋 改進 無限循環，不要心急 ，不要期望一次到位測試流程一般包括但不限於以下內容：
- 測試團隊結構、崗位定義及職責范圍
- 相關合作團隊職責、主要聯系人、溝通方式
- 產品研發周期、階段 （瀑布開發要考慮到大的release、小的release和hot fix的不同）
- 測試在研發整個周期的不同階段的任務和出品
- 測試類型（Unit test, Integration test, System test, UAT, performance test, etc）在本測試團隊內的定義
- 測試出品主要包括測試計划、測試用例、缺陷報告、測試進度報告、測試完成報告（或質量評定報告），每項出品應該有相關模板和寫作規范
- 測試用例撰寫、審核、執行、記錄執行結果的流程
- 缺陷管理流程
- 測試平台、測試實驗室管理使用規范
- 測試進入和退出標准
- 測試工具管理
- 測試數據收集、統計和過程改進辦法
- 員工培訓計划、組內知識共享計划
嗯。。。這一大坨東西，沒兩年以上的沉淀是積累不出來的
4 號嘉賓JMasche-Tester，阿根廷足球，BBer
JMasche：強答一發吧。考慮流程之前，應該考慮的是你們公司的環境，或許這個才是最重要的。由於你們之前沒有測試部門，那么你們老大建立測試部門的初衷是什么？他想要達到什么效果？這點很關鍵。如果他有想法，必須先弄清楚他的想法，再來查看實施可能性；如果他沒清晰的想法，那么就需要不斷的通過溝通，提出你的想法，他來反饋意見。快速非正式迭代。為什么這個很重要呢？因為一旦測試部門建立起來，會出現兩個情況：1、研發周期被拉長。這個是一定的，無論采取什么辦法，都會被拉長。創業公司我沒呆過，想來對發布速度是有要求的吧。2、質量有可能在短期內下降。為什么呢？因為質量掌握在開發手上。而測試部建立起來之后，可能出現開發人員覺得有人兜底了，導致開發質量下降。后面有個號稱質量保障的部門了，多了個背鍋的家伙。呵呵
上面這倆點合在一起的最壞情況是什么呢？建立測試部后，研發周期拉長，而質量下降。開發抱怨測試帶來額外任務增多，而且還搞不定質量。所以，回過頭來，找老大，溝通：
1、為什么要建立測試部？原來出現嚴重質量問題？ok，這簡單搞定上線發布環節就行了。如果只是很模糊的需要測試，那就要確定測試的范疇，能達到的效果。思考點包括：測試人力投入、測試周期。
2、基於第一點的范圍和目的效果，再往你上游的開發環節看，設立轉測試點要求，千萬不要多，找到最關鍵兩三點即可。這個環節要拉上開發負責充分溝通。
3、建立發布評審機制。參與人員和輸出。
4、建立起問題單管理系統和機制，基於問題單給出質量晾曬機制。這點對老大有用，開發討厭。
我覺得剛開始搞定這些也就差不多了
5 號嘉賓天狼星
天狼星：正是我現在做的事，忍不住寫下來。首先看什么樣的公司和什么樣的產品以及周圍的人的技術水平，老大們的真實想法。核心還是要從把當前產品出發，如何把產品測試好。這樣才能得到老大甚至老板的認同。另外建議先做好規划和老板匯報下，摸清楚他們的期望。很多老板以為有了流程產品質量就會變好，這種事要先解釋清楚，最終是要人執行和落地，而改革中也勢必會有阻力，這時候一定要老板支持。然后技術上，不建議搞太多流程。技術上建議做以下幾個動作
1、控制版本發布最好做到自動化，可參考使用jenkins，好處節約發版時間，避免測試版本與發布不一致
2、控制開發后版本提交測試環節，開發必須輸出有效的功能清單和自測報告
3、推動需求端討論，驅動問題提前發現。
4、推動自動化測試
最好要看公司測試本身的職責。如果有其它質量部門負責制訂流程的話還是要專人來做，制訂流程及落實的工作並不是想象中一個兼職人員可以完成的。補充個人觀點，好的流程不如好的工具和人員的習慣。之前看一篇文章寫Google 的 代碼評審，開發人員提交后自動進行靜態檢查，和送到評審員那里不通過無法提交。而對比華為花大價錢搞的IPD 效果大量人力物力，效果暫且不評論了。
6 號嘉賓王小二-塵世中迷途小書童
王小二：和題主有類似的經歷，個人認為最主要的是還要搞好與領導的關系，以及開發老大的關系。首先要弄清楚公司領導要你這么做的目的是什么，以及他的期望是怎樣的；其次要獲取領導的絕對支持，特別是測試與開發起沖突時的支持（雖說測試與開發的大致利益是一致的，但實際操作中難免有沖突）；最后還要處理好與開發老大的關系，否則一些你想弄的流程、規范等等也很難推進落實。
至於具體的流程、規范，根據公司實際的情況制定，並且多與領導、同事以及開發人員討論，實事求是、符合實際情況是最重要的。在具體執行的過程中，也要不斷的權衡與開發、公司等之間的利益關系，對一些開發人員覺得不滿的地方做好記錄和解釋工作，持續改進。
總之，個人覺得在小公司里，人是最需要考慮的因素。