軟體測試流程和項目管理流程

背景

工作五年了，一直是做測試。認識了很多人大牛，也接觸到很多新人，從他們身上看到了很多，自己的過去，自己的未來（當然很多是自己達不到的高度）。

做這測試這一行的，很多人都追求技術：自動化+性能，往往忽略測試流程，或者說是項目管理流程。

想法

流程是要結合團隊來看的，換句話來說就是case by case，沒有标準，适合團隊/業務的流程就是好流程；

待過做中國移動項目的傳統行業，測試流程一套一套的，需求評審 -- 開發詳細設計評審 -- 用例評審 -- 提測評審 -- 測試執行 -- 報告輸出 -- 安排上線 -- 線上驗收，很多會議是需要産研測全部參加的，時間投入很大，這原因是因為項目/業務疊代周期是一個月上一次版本，有足夠的時間去做這些，當測試全流程介入的時候确認能發現很多問題，這裡就引入一個詞：品質前移 ，比較好了解，不是在測試執行才發現問題，而是将問題前移，移到需求評審，設計評審，用例評審中去，這一步做的好的就是測試的一個方向：業務專家 ，看項目/産品的高度達到了産品高度，從全局去考慮測試用例場景，對業務非常熟悉，提升影響力，開發/産品會來咨詢你業務知識；

回想起唯品會的流程，有很多值得借鑒的地方。

唯品會的流程，核心是火車釋出制，項目安排是每個星期釋出一個版本，也就是每個星期隻有一趟車，項目想上線的話，就需要在指定時間上車，意思就是在規定時間開發測試打包完畢。整個項目的流程就是按照這個火車開車時間來排期規劃。（當然你要問到很多線上問題怎麼辦？緊急項目怎麼辦？ 春運不是也有臨時車次這個說法嗎？）

在網際網路行業的話，疊代速度明顯加快，都是你追我趕的節奏，但很多流程也是必須有的。

需求評審會根據需求大小來看是否開展的，小需求的話，就直接是一份文檔查閱就完事了的。

在唯品會的時候，所在團隊有點做的比較好，就是提測環節，我們要求開發提測有輸出，要求他們整理功能點：新增/修改了哪些功能，改動了哪些檔案，自測點，自測結果，靜态代碼檢查，單元測試是否全部通過，這些也是測試的一種職責，項目的保證不單單隻是測試的事情，測試有義務/責任從整個項目流程中去提升品質。

提測過後，測試要經過冒煙測試，這個冒煙首先要檢查開發的輸出是不是包含了上面提的那些，測試有權利直接打回這次提測，阻塞主流程的問題也要打回，冒煙不通過。冒煙不通過的項目代碼品質堪憂；

功能測試，測試人手一台測試機器，将項目部署在自己的環境進行功能測試，（這裡講一句，唯品會這方面确實壕，而開發是整個團隊公用一套開發環境，哈哈哈）

回歸測試，功能測試完畢後，需要開發合并代碼到master（最終上線的分支），由于多個項目并行，可能存在代碼合并問題，需要重新再回歸一輪，這個環境可以驗證主幹用例，也可以用自動化去驗證 ，這裡還有一個code review環節；

這裡需要單獨提一點，代碼權限控制，開發合并代碼後，是沒有push代碼的權限了的，代碼權限控制在測試手中，這個時候需要修改代碼，原因為功能測試遺漏，或者是合并代碼錯誤，可以做一個統計；

預釋出測試，回歸OK後，打包部署到預釋出環境，這個環境都是生産的資料庫了的，重點校驗配置（配置檔案，DB...）是否OK，到了這裡也有很多測試不通過的情況，可以做統計資料；

上線驗收，提供給運維最終的包，做上線驗收

唯品會一些細節的流程做的比較好，上線前會有小組的上線評審，這個環節的話，需要說明這個項目有什麼功能；會不會對線上舊功能造成什麼影響；存在什麼風險；是否可以線上驗收，若有怎麼驗收，如果沒有什麼做監控；復原方案是什麼，集思廣益

需求評審 -- 用例評審 -- 提測 --  冒煙測試 -- 功能測試 --  回歸測試 -- 預釋出測試 --  線上驗收 -- 資料監控

現在的UC，沒有火車釋出制度，項目并發更多，很多都是今天提測明天上線的節奏，更加靈活。一些關鍵流程的缺失會帶來一些風險，但核心點不變，品質前移和監控，這就是看到過一篇文章提到的左移和右移。

團隊也在慢慢加強流程這塊東西了的，品質的保證是整個團隊的事情，測試有業務和責任去提升品質，這裡的品質部分是從項目流程去提升的

小結

測試，不是找bug，應該稱為品質保障，其中的手段就是你職業規劃的路線。

管理，也估計是很多人想走的路線吧，很多人覺得在一家公司混久點就能走上管理層，但我發現在管理層混的好的，都是業務專家，都是會為人處世的，有項目整體風險意識的，當然也需要一定的機遇；

技術，這條路是很多測試同學在走的或者想走的，想搞自動化，想搞性能，因為技術的提升意味着工資的提升，學好一門語言是非常重要的；

不管是做什麼的，自身掌握了稀有資源，待遇自然上去了的。

回到這次的主題：流程，工作經驗的優勢就要凸顯出來，以過往經驗結合現有團隊情況，制定流程，或者對現有流程提出建議；

1. 品質遷移，測試提前介入，從需求端發現問題，帶着問題去開需求評審，怼産品/需求；

2. 合并代碼回歸測試，跟開發溝通後，不要直接上線，需要重新過一遍；

3. 上線評審，思考上線依賴，風險，舊資料/功能影響，復原方案；

如果你覺的文章閱讀不過瘾，可以檢視詳細的視訊教程

【軟體測試全棧系列課程】請點選我哦…

 https://edu.51cto.com/course/25359.html

【部落客完整視訊課程系列】請點選我哦…

 https://edu.51cto.com/lecturer/13226632.html

【JMETER基礎和實踐課程】請點選我哦…

 https://edu.51cto.com/course/28017.html

【JMETER 性能測試基礎與項目實戰視訊課程】請點選我哦…

 https://edu.51cto.com/course/16055.html

【Jmeter+ant+jenkins接口層性能與自動化測試課程】請點選我哦…

 https://edu.51cto.com/course/19323.html

【零基礎新手入門軟體測試基礎課程】請點選我哦…

 https://edu.51cto.com/course/27846.html

【軟體測試之移動端測試系列課程】請點選我哦…

 https://edu.51cto.com/course/26878.html

【Fiddler接口抓包神器使用教程】請點選我哦…

 https://edu.51cto.com/course/28066.html