著作權歸作者所有，任何形式轉載請聯系作者，
作者：程式員一凡（來自豆瓣）
來源：https://www.douban.com/note/777720230/
今天和大家來聊一聊測驗工程師日常的作業是做什么的，
首先，一個互聯網產品或者說一個新功能上線，需要經過需求評審，功能開發，測驗，上線發布這四個流程，
測驗就可以理解為，產品生產的最后一道關卡，負責產品的質量，我們需要盡可能的去發現開發的缺陷 ，及時發現及時解決，保證產品交付給用戶是合格的產品，
那么測驗工程師，每天都在做什么呢？
主要的作業分為四大部分：
業務測驗
專項測驗
效能提升和質量監控，
第一、業務測驗
有的同學可能還不是很清楚，什么是業務，業務說白了，就是你們公司或者專案組為了達成商業目標而 所做的事，業務是由銷售，運營，產品，設計，開發和測驗共同完成的，比方說你們的專案組主要負責 搜索功能，那么你在里面的角色，就是這個搜索功能的迭代測驗，那么如何進行業務測驗呢？首先：需要參加需求評審和技術評審，熟悉和明確產品的需求，其次：針對需求檔案和技術檔案，進行測驗用例的撰寫，撰寫完測驗用例之后，還需要對測驗用例進行評審，接下來：研發工程師會進行產品的開發，等開發完畢，開發自測通過后，會把代碼提測到你這邊，此時你要做的就是把代碼部署到測驗環境，并開始進行冒煙測驗，冒煙測驗就是把產品功能的主流程走一遍，看是不是能符合提測標準，如果已經滿足提測標準，就可以開始按照你撰寫的測驗用例逐漸進行測驗，這個階段就是測驗的重頭戲，主旋律就是發現bug、提交bug，開發解決完bug，再驗證bug是否修復，測驗完畢之后，需要讓產品進行產品驗收和體驗，驗證通過后方可進行上線，上線完畢之后，還需要在生產環境下進行回歸測驗，等回歸測驗沒問題之后才能宣告功能正式交付，接下來就開始進行下一個功能迭代測驗，
第二、專項測驗
顧名思義，就是諸如資料測驗，性能測驗，自動化測驗等特殊的測驗，主要是對業務測驗的進行補充，沒有絕對完美無缺的系統，單靠業務測驗是無法保證產品或代碼質量得到更多提升的，比方說，自動化測驗可以模擬1000次點擊操作，但是這個要讓手工測驗去做的話，不得把測驗工程師逼瘋囖~（需要自動化測驗學習資料可以關注我的公眾號：程式員一凡，免費領取）專項測驗可以發現一些手工測驗發現不到的bug，但是專項測驗不可能完全替代業務測驗，業務測驗具有主觀能動性，可以站在用戶的角度，去體驗一個功能的好壞以及產品是否美觀，但是專項測驗不能做到這一點，
第三、效能提升
現在的互聯網公司產品迭代周期很短，一個功能可能一到兩天之類就得上線，加入說企業不追求效率提升的話，就無法快速占領市場，我們的測驗作業也是一樣，更應該注重效能提升，效能提升主要可以從CI/CD,bug管理，測驗環境維護、流程管理和優化去考慮，有能力的測驗團隊可以考慮開發出適合自己團隊的測驗平臺，集結所有優秀的測驗工具，方便測驗工程師提升測驗效率，近幾年來，DevOps也是火了一陣，DevOps就是開發運維一體化，可以把整個產品的生產程序，形成一套流水線規范，這樣也可以很大程度提升產品的交付效率，
第四、質量監控
無論如何質量都是測驗的臉面，為了保證質量，我們不能只局限于測驗階段去發現bug，我們應該也要在產品交付之后進行質量的監控，比方說移動app正式發布之前，都會有灰度測驗的階段，在這個階段，已經有部分用戶可以率先體驗到我們的新功能，我們需要進行app的Crash監控，所謂的Crash就是app的崩潰，Crash給用戶體驗造成相當大的影響，監控Crash可以有效的把Crash扼殺在正式發版之前，其他的監控還有服務器的狀態監控，用戶的反饋監控，埋點資料監控等等，下圖是我對測驗工程師所做的事進行一個大概的總結，
大家如果對測驗感興趣，歡迎關注我，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/37682.html
標籤：其他
上一篇：啟動spark-shell出現<console>:10: error: not found: value sqlContext的錯誤