一個工做5年的軟件測試員工的對軟件測試的理解和總結【精品文章】

背景

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

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

想法

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

Part1

待過作中國移動項目的傳統行業，測試流程一套一套的，需求評審 – 開發詳細設計評審 – 用例評審 – 提測評審 – 測試執行 – 報告輸出 – 安排上線 – 線上驗收，不少會議是須要產研測所有參加的，時間投入很大，這緣由是由於項目/業務迭代週期是一個月上一次版本，有足夠的時間去作這些，當測試全流程介入的時候確認能發現不少問題，這裏就引入一個詞：質量前移 ，比較好理解，不是在測試執行才發現問題，而是將問題前移，移到需求評審，設計評審，用例評審中去，這一步作的好的就是測試的一個方向：業務專家 ，看項目/產品的高度達到了產品高度，從全局去考慮測試用例場景，對業務很是熟悉，提高影響力，開發/產品會來諮詢你業務知識；

Part2

回想起惟品會的流程，有不少值得借鑑的地方。

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

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

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

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

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

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

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

這裏須要單獨提一點，代碼權限控制，開發合併代碼後，是沒有push代碼的權限了的，代碼權限控制在測試手中，這個時候須要修改代碼，緣由爲功能測試遺漏，或者是合併代碼錯誤，能夠作一個統計；

預發佈測試，迴歸OK後，打包部署到預發佈環境，這個環境都是生產的數據庫了的，重點校驗配置（配置文件，DB…）是否OK，到了這裏也有不少測試不經過的狀況，能夠作統計數據；

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

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

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

Part3

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

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

小結

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

管理，也估計是不少人想走的路線吧，不少人以爲在一家公司混久點就能走上管理層，但我發如今管理層混的好的，都是業務專家，都是會爲人處世的，有項目總體風險意識的，固然也須要必定的機遇；

技術，這條路是不少測試同窗在走的或者想走的，想搞自動化，想搞性能，由於技術的提高意味着工資的提高，學好一門語言是很是重要的；

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

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

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

2. 合併代碼迴歸測試，跟開發溝通後，不要直接上線，須要從新過一遍；

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

上面是我收集的一些視頻資源，在這個過程當中幫到了我不少。若是你不想再體驗一次自學時找不到資料，沒人解答問題，堅持幾天便放棄的感覺的話，能夠加入咱們扣扣羣【313782132 】，裏面有各類軟件測試資源和技術討論。

更多好文章分享：

原來功能測試轉成自動化測試這麼簡單？

見識瞭解python自動化測試（3）

測試大神的工做經驗總結

Python究竟有多簡單？

趕快進來學習瞭解與交流吧，我是一包傷心的辣條，關注小編，我帶你玩轉職場。