測試流程？項目管理流程？

阿新 • • 發佈：2017-08-26

生產測試的直接項目部是你管理 ast 火車臨時

背景

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

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

想法

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

Part1

待過做中國移動項目的傳統行業，測試流程一套一套的，需求評審 -- 開發詳細設計評審 -- 用例評審 -- 提測評審 -- 測試執行 -- 報告輸出 -- 安排上線 -- 線上驗收，很多會議是需要產研測全部參加的，時間投入很大，這原因是因為項目/業務叠代周期是一個月上一次版本，有足夠的時間去做這些，當測試全流程介入的時候確認能發現很多問題，這裏就引入一個詞：質量前移

，比較好理解，不是在測試執行才發現問題，而是將問題前移，移到需求評審，設計評審，用例評審中去，這一步做的好的就是測試的一個方向：業務專家 ，看項目/產品的高度達到了產品高度，從全局去考慮測試用例場景，對業務非常熟悉，提升影響力，開發/產品會來咨詢你業務知識；

Part2

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

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

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

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

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

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

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

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

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

預發布測試，回歸OK後，打包部署到預發布環境，這個環境都是生產的數據庫了的，重點校驗配置（配置文件，DB...）是否OK，到了這裏也有很多測試不通過的情況，可以做統計數據；

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

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

需求評審 -- 用例評審 -- 提測 -- 冒煙測試 -- 功能測試 -- 回歸測試 -- 預發布測試 -- 線上驗收 -- 數據監控

Part3

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

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

小結

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

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

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

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