如何規範小開發公司的測試流程。?
目前在一家創業公司上班，剛組建測試部門，領導讓我規範和建立測試流程。頭大。
在首頁看到這個話題，就不邀自來了。
如果是剛組建測試團隊，那需要整理的流程可多了。
1、梳理測試流程，可以重點把關的測試流程有：
需求Review：策劃完成的需求文檔必須讓開發、測試、運營進行Review，提出Review意見並最終改掉。這種Review能發現需求的漏洞並提早改掉，提高整個研發過程的效率。測試用例Review：測試人員針對需求寫出粗略的用例點之後，再讓策劃、開發、測試、運營Review一遍，目的還是發現需求的遺漏點，根據我們的經驗，由於測試人員已經思考了測試點，所以相當於是對需求的細化和剖析，這個Review環節還是能發現很多需求的漏洞。
開發提測：測試人員事先發出冒煙測試用例，開發完成後，讓開發人員先根據冒煙用例進行自測，自測通過了以後才提交給測試，然後測試再根據相同的用例做冒煙測試。這樣能提高開發提測的質量。上線前報告：上線以前，需要讓測試人員發一封報告，重點指出測試過程中發現的問題、及上線以後可能會出的質量問題，並在項目群裡面、或者召集開會把這些風險一一溝通過。如果有因為時間不足、或者因為客觀條件限制導致的測試不足的情況，一定要在這個環節進行說明，這樣，如果上線以後出問題了，大家也能理解測試。線上Bug Review：對於線上發現的Bug，如果沒有分析流程，測試人員需要制定線上Bug的分析流程，先重點分析這個線上Bug產生的原因、線上Bug的影響範圍，然後大家一起決定可以有哪些改進措施可以避免同類線上Bug再犯。這種改進措施需要能真正落實的，如果是可有可無的改進措施，就不要提了。這個措施可以讓大家一起剖析線上Bug的產生原因，一方面可以避免項目組認為都是測試的錯導致線上Bug，一方面，也發揮了測試人員質量保證的角色，推動流程讓質量更好。2、確定測試技術可以提升的點：
環境部署：如果有技術積累，可以把測試環境的部署拿來讓測試來做，這樣測試人員可以自己控制測試的版本和配置。也提高測試人員的工作範圍。性能測試：如果是流量很大的產品，需要專業的服務端性能測試人員來進行性能測試，對於測試的專業性提升有很大的價值。專項測試：如果是APP產品，需要讓技術比較好的同學來探索專項的測試，把APP端的性能、流量、電量等體驗提升上去。題主可以自己先評估需要引入上述哪些流程，然後，就是溝通、溝通、再溝通。所謂新官上任三把火，第一把火就是要把現有的情況先摸清楚。跟自己的組員溝通、跟項目的開發負責人、產品負責人溝通、跟自己的老大溝通。清楚他們希望我們重點改進的點，同時也把我們想要推的流程、理念傳遞出去。
在推流程的時候，建議盡量不要把自己站在產品的對立面，而是要跟產品站在同一邊，以產品的質量、開發效率等出發點來進行流程的推廣。大家相處愉快，整個團隊齊心協力，這才是老大願意看到的局面。根據我的經驗，其實不管是開發負責人還是老大，還是比較願意尊重我們的職業經驗，只要我們真正站在產品的角度去溝通，大多數人還是願意配合的。謝邀
這個話題好大
先簡答一下吧首先制定流程的人一定要明白和堅守一個原則：
流程不能是死的必須是活的其次測試流程的核心是在保障研發效率的前提下提高產品質量明白這兩點接下來的事就容易理順了
1）充分了解當前研發流程對不合理的地方尤其不要急於下定論和提出改進意見而要充分了解歷史成因2）跟領導聊天了解領導期望的未來的或理想的研發流程是什麼樣的
和現有流程的差距在哪裡、實現的難度在哪裡在這兩點的指導下提出測試流程草案除非是研發太扯蛋否則最初的測試流程最好是在現在的研發流程上做少量提升和修改草案要與領導與研發團隊共同討論盡最大可能取得相關人員的理解和支持試行反饋改進無限循環
不要心急不要期望一次到位測試流程一般包括但不限於以下內容：
- 測試團隊結構、崗位定義及職責範圍- 相關合作團隊職責、主要聯繫人、溝通方式- 產品研發周期、階段 （瀑布開發要考慮到大的release、小的release和hot fix的不同）- 測試在研發整個周期的不同階段的任務和出品- 測試類型（Unit test, Integration test, System test, UAT, performance test, etc）在本測試團隊內的定義- 測試出品主要包括測試計劃、測試用例、缺陷報告、測試進度報告、測試完成報告（或質量評定報告），每項出品應該有相關模板和寫作規範- 測試用例撰寫、審核、執行、記錄執行結果的流程
- 缺陷管理流程- 測試平台、測試實驗室管理使用規範- 測試進入和退出標準- 測試工具管理- 測試數據收集、統計和過程改進辦法- 員工培訓計劃、組內知識共享計劃嗯。。。這一大坨東西沒兩年以上的沉澱是積累不出來的其實很簡單，列出章程，嚴格執行，做得到嗎？做不到那就沒必要去規範了。
強行來回答一發……
分兩個點來說吧，想通過流程規範來保證軟體質量，除了測試環節的流程之外，更重要的是研發、測試都要具有質量意識，必須讓測試作為一個核心角色參與進整個軟體生命周期中掌握一定的話語權，這樣的測試才會有意義。
對整個軟體生命周期來說，測試從需求評審開始到最後的發布上線全部參與，在評審需求的時候，要提煉核心業務需求，研發、測試、產品三個部門在業務需求的理解上達成一致、同時評估軟體的可測試性；設計評審時需要考慮對數據存儲（例如資料庫、表的設計，存儲方式從資料庫遷移到redis等）的修改、對程序結構的影響等方面，設計是否有不合理的地方、是否存在風險等。從測試用例設計開始正式進入測試環節，一般來說會讓研發冒煙自測通過後才能提交代碼進行測試，否則測試可以直接將版本打回；測試用例的設計到測試執行，可以採用經典的三輪測試體系與探索性軟體測試體系，這裡重點說一下前者（實際上是答主這個戰五渣自己都搞不定探索性軟體測試，還要先學習一個），按照測試用例——用例評審——一輪測試（全面執行測試用例）——二輪測試（針對bug修復的驗證以及bug修復可能帶來問題的驗證）——三輪測試（內網全面回歸）——外網回歸測試的流程基本就可以了。無論是手動測試還是自動化測試，都特別考驗測試用例設計的是否全面，我們可以請研發同學一起參與用例評審，保證用例能全面覆蓋功能場景。
如果是某個產品線處於快速迭代期，可以考慮將三輪測試流程進行適當簡化，設計輕量級的測試流程標準，但是這種標準有風險，如果確定某個版本要採用輕量級的流程，事先就必須說明風險點了。
bug等級、測試通過標準、性能標準、兼容性標準都是根據實際項目決定的，沒有說一個絕對量化的指標，可以根據項目情況視情況調整。強答一發吧。
考慮流程之前，應該考慮的是你們公司的環境，或許這個才是最重要的。由於你們之前沒有測試部門，那麼你們老大建立測試部門的初衷是什麼？他想要達到什麼效果？這點很關鍵。如果他有想法，必須先弄清楚他的想法，再來查看實施可能性；如果他沒清晰的想法，那麼就需要不斷的通過溝通，提出你的想法，他來反饋意見。快速非正式迭代。
為什麼這個很重要呢？因為一旦測試部門建立起來，會出現兩個情況：
1、研發周期被拉長。這個是一定的，無論採取什麼辦法，都會被拉長。創業公司我沒呆過，想來對發布速度是有要求的吧。2、質量有可能在短期內下降。為什麼呢？因為質量掌握在開發手上。而測試部建立起來之後，可能出現開發人員覺得有人兜底了，導致開發質量下降。後面有個號稱質量保障的部門了，多了個背鍋的傢伙。呵呵 上面這倆點合在一起的最壞情況是什麼呢？建立測試部後，研發周期拉長，而質量下降。開發抱怨測試帶來額外任務增多，而且還搞不定質量。所以，回過頭來，找老大，溝通：
1、為什麼要建立測試部？原來出現嚴重質量問題？ok，這簡單搞定上線發布環節就行了。如果只是很模糊的需要測試，那就要確定測試的範疇，能達到的效果。思考點包括：測試人力投入、測試周期。2、基於第一點的範圍和目的效果，再往你上游的開發環節看，設立轉測試點要求，千萬不要多，找到最關鍵兩三點即可。這個環節要拉上開發負責充分溝通。3、建立發布評審機制。參與人員和輸出。
4、建立起問題單管理系統和機制，基於問題單給出質量晾曬機制。這點對老大有用，開發討厭。我覺得剛開始搞定這些也就差不多了小公司里老闆招的每個人都有著明確的目的，對組建測試團隊也一樣，如果你在面試的過程中應聘的是測試團隊主管類似的崗位，我認為要和面試官認真溝通他們希望的測試團隊在整個大團隊中的意義，你通過什麼手段（流程、工具、制度）能夠達到他們的預期要求，如果在面試的時候我能勝任，我會告訴他們我能通過工作給整個團隊，產品質量的改善上帶來什麼，如果不能勝任通常我不會接活。我個人認為最難搞的公司是這樣的他們也不知道到底測試team能給他們帶來什麼，因為別的軟體公司有，所以我也來一個，這樣的活兒我不接，沒有明確目的和方向的浪費的是彼此的精力。入職後剛進入團隊，應該快速進入產品測試，慢熱型的提出整改意見。熟悉產品，熟悉產品生命周期的流程與環節，熟悉每位大神：研發老大、項目經理、技術牛人的脾氣與性格。然後從產品最薄弱最急迫需要解決的地方入手，用溫柔的語氣、堅定的立場、快速而堅韌的執行力解決制度和流程的不足。從顯而易見的點入手的優點有：一是好解決；二是會比較容易出成績（不是個人成績，而是讓整個大團隊看到測試team是對整個項目有幫助的）
知乎大牛太多，見笑了~
正是我現在做的事，忍不住寫下來。
首先看什麼樣的公司和什麼樣的產品以及周圍的人的技術水平，老大們的真實想法。
核心還是要從把當前產品出發，如何把產品測試好。這樣才能得到老大甚至老闆的認同。另外建議先做好規劃和老闆彙報下，摸清楚他們的期望。很多老闆以為有了流程產品質量就會變好，這種事要先解釋清楚，最終是要人執行和落地，而改革中也勢必會有阻力，這時候一定要老闆支持。然後技術上，不建議搞太多流程。技術上建議做以下幾個動作1、控制版本發布最好做到自動化，可參考使用jenkins，好處節約發版時間，避免測試版本與發布不一致2、控制開發後版本提交測試環節，開發必須輸出有效的功能清單和自測報告。3、推動需求端討論，驅動問題提前發現。4、推動自動化測試最好要看公司測試本身的職責。如果有其它質量部門負責制訂流程的話還是要專人來做，制訂流程及落實的工作並不是想像中一個兼職人員可以完成的。
補充個人觀點，好的流程不如好的工具和人員的習慣。之前看一篇文章寫Google 的 代碼評審，開發人員提交後自動進行靜態檢查，和送到評審員那裡不通過無法提交。
而對比華為花大價錢搞的IPD 效果大量人力物力，效果暫且不評論了。和題主有類似的經歷，個人認為最主要的是還要搞好與領導的關係，以及開發老大的關係。首先要弄清楚公司領導要你這麼做的目的是什麼，以及他的期望是怎樣的；其次要獲取領導的絕對支持，特別是測試與開發起衝突時的支持（雖說測試與開發的大致利益是一致的，但實際操作中難免有衝突）；最後還要處理好與開發老大的關係，否則一些你想弄的流程、規範等等也很難推進落實。至於具體的流程、規範，根據公司實際的情況制定，並且多與領導、同事以及開發人員討論，實事求是、符合實際情況是最重要的。在具體執行的過程中，也要不斷的權衡與開發、公司等之間的利益關係，對一些開發人員覺得不滿的地方做好記錄和解釋工作，持續改進。總之，個人覺得在小公司里，人是最需要考慮的因素。
我也是呀， 我也迷糊著。 求指教
推薦閱讀：
※做介面測試的流程一般是怎麼樣的？
※哪家軟體測試教學教得好？
※軟體測試培訓哪個好？
※最近在找實習。面試軟體測試時，面試最想聽到的答案是什麼？
※在編寫編譯器時，如何測試編譯器優化效果？