1. 程式人生 > >測試流程?項目管理流程?

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

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

背景

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

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

想法

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

Part1

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

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

Part2

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

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

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

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

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

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

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

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

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

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

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

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

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

Part3

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

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

小結

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

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

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

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

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

1. 質量遷移,測試提前介入,從需求端發現問題,帶著問題去開需求評審,懟產品/需求;

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

3. 上線評審,思考上線依賴,風險,舊數據/功能影響,回滾方案;

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