入行測開，馬上就要5年了。創(chuàng)業(yè)公司待過，大公司也待過，工作這一路走來，一些心得，轉(zhuǎn)變，職場體會，早就想寫出來分享一下。這個歷程包含了技術(shù)的提升，工程師的素養(yǎng)和對這個行業(yè)的點(diǎn)滴感悟。

自動化測試vs測試開發(fā)

記得剛?cè)胄心菚?，我?a href="http://m.makelele.cn/tags/ti/" target="_blank">title是自動化測試工程師。那時對這兩者的區(qū)別還沒那么明顯，面試時候兩者的問題也都比較類似。當(dāng)時招聘“會寫代碼的測試人員”比較偏向稱之為“自動化測試工程師”；不過現(xiàn)在很多企業(yè)的招聘都變?yōu)椤皽y試開發(fā)工程師”了。

究其概念，其實(shí)自動化測試工程師更偏向于業(yè)務(wù)方向的效率提升；而測試開發(fā)則更偏向于基礎(chǔ)架構(gòu)方向的效率提升。打個簡單的比方，測試開發(fā)工程師產(chǎn)出的框架可以認(rèn)為是父類，自動化測試工程師按業(yè)務(wù)線不同，可以理解是繼承自父類的不同子類。

測試開發(fā)到底在做什么？

測試開發(fā)，最早起源于《Google軟件測試之道》這本書，里面第一次提出了SET（Software Engineer in Test）。不過不同的公司稱謂也不一樣，像國內(nèi)很多時候還是統(tǒng)稱為QA。

那么SET具體在做什么呢？在我看來，SET偏向于測試部門的基礎(chǔ)架構(gòu)開發(fā)和流程的設(shè)定，比如前面說到的自動化底層框架搭建，或者改寫一些開源的類和方法，去提供給組內(nèi)其他的測試人員使用；再比如，我們所熟知的CICD，單元測試or集成測試的覆蓋率統(tǒng)計，以及自動化部署發(fā)布的腳本，都可以歸到測開的工作范疇里；還有，我們常說測試也需要新技術(shù)的引入，現(xiàn)在常見的Docker跟k8s也在逐漸普及到測試團(tuán)隊(duì)，因?yàn)闇y試最大的一個障礙是“測試環(huán)境眾多”，而容器化可以很好的解決這一點(diǎn)。

當(dāng)然不同的公司情況多有差異。一般來說，越是大型的企業(yè)，它的測試流程越規(guī)范，測開的作用也就越明顯，對應(yīng)的產(chǎn)品測試效率，也就越高。

質(zhì)量保障的終極任務(wù)

我相信現(xiàn)在很多測試工程師，其實(shí)都有足夠的共鳴，就是“我們不是測bug的，我們是產(chǎn)品的質(zhì)量保障員”。但是很多不成熟的企業(yè)和團(tuán)隊(duì)還是會有誤區(qū)。比如，bug數(shù)目確實(shí)可以代表你工作的產(chǎn)出，但如果你的團(tuán)隊(duì)或領(lǐng)導(dǎo)把bug數(shù)目作為唯一指標(biāo)，我覺得你是時候考慮跳槽了。質(zhì)量保障，在我看來涵蓋很多東西，是一個很龐大的概念，大概可以包括四點(diǎn)：

1.正確的流程

現(xiàn)在很多都是敏捷開發(fā)模式了。在需求評審階段，測試同學(xué)參與并對需求or產(chǎn)品有一定的理解和初步的測試計劃

2.基礎(chǔ)的質(zhì)量

開發(fā)代碼的規(guī)范度，基礎(chǔ)代碼的走查，監(jiān)督單測覆蓋率的穩(wěn)步提升，畢竟基礎(chǔ)決定上層

3.業(yè)務(wù)的覆蓋

確切可以拆分成服務(wù)接口的測試/前端UI測試/性能測試/穩(wěn)定性測試/系統(tǒng)集成測試/回歸測試，這一點(diǎn)可以說是測試同學(xué)交叉最多的地方。

4.產(chǎn)品終端的保證

協(xié)同制定灰度發(fā)布策略/規(guī)范線上的操作/了解用戶使用過程中常見的風(fēng)險點(diǎn)/制定止損策略

簡單來說，測試保障質(zhì)量，質(zhì)量決定產(chǎn)品。測試應(yīng)該是對需求，對產(chǎn)品邏輯最最了解的那個角色。所以，只要關(guān)于產(chǎn)品變更的，測試同學(xué)都應(yīng)該下意識去跟進(jìn)。

而以上的任何一點(diǎn)，都可以深究，去做的更好。

工程師文化

我相信再牛逼的測試開發(fā)，也要從業(yè)務(wù)抓起，你不了解業(yè)務(wù)，不了解一些開發(fā)代碼或者的話，有些東西也是扯淡。業(yè)務(wù)測試在我看來一點(diǎn)都不low，反而是一個很考驗(yàn)人的事情。不管是測試工程師也好，測試開發(fā)也好，我們都是工程師，都服務(wù)于產(chǎn)品。既是工程師，就該有工程師的素養(yǎng)，我認(rèn)為完成一個好的測試任務(wù)，大概需要同時做到以下幾點(diǎn)：

1.對測試結(jié)果負(fù)責(zé)

我們是產(chǎn)品的最后一道關(guān)卡，我們對產(chǎn)品發(fā)布與否有絕對的話語權(quán)，同時，我們也要對自己的測試結(jié)果負(fù)責(zé)。

2.測試到最終場景

現(xiàn)在很多產(chǎn)品鏈路都很長，這就需要測試同學(xué)主動去塑造自己產(chǎn)品的大局觀，而不局限在某個單元的測試，不考慮全局，有時會造成致命的線上災(zāi)難。

3.對日志敏感，能夠精準(zhǔn)定位問題

如果開發(fā)流程足夠規(guī)范的話，有完整的日志系統(tǒng)，其實(shí)定位問題并不難；我們每發(fā)現(xiàn)一個bug，都可以嘗試去追溯它的根源，時間久了，你會對工程代碼或邏輯摸的很清楚，這對你接下來的測試工作簡直如虎添翼。

4.對相似問題和漏洞的歸納

不管是前方客戶的問題，PM發(fā)現(xiàn)的問題還是自己的bug庫，經(jīng)常歸納可以節(jié)省很多時間，會讓你對自己的工作產(chǎn)生一種“直覺”，但這種直覺有時很準(zhǔn)哦。

面對不同的產(chǎn)品該怎么辦？

開發(fā)技術(shù)或框架可能是通用的，但測試可能會隨著產(chǎn)品形態(tài)而產(chǎn)生“獨(dú)特”的調(diào)整，我稱之為“測試形態(tài)”。比如，現(xiàn)在的人工智能測試，因?yàn)槊看文Ｐ偷?，測試所需的數(shù)據(jù)量很大，你用傳統(tǒng)的并發(fā)去請求可能就不行，那你可能就需要學(xué)一些分布式技術(shù)；再有就是云服務(wù)測試，這種絕大部分是純后端服務(wù)測試，或者SDK測試，沒有前端去assert你的預(yù)期，那么你就需要足夠熟悉curl命令，網(wǎng)絡(luò)命令等，甚至去生成一些shell腳本，來執(zhí)行你的測試請求；還比如手機(jī)端的測試，那它的兼容和穩(wěn)定性呢怎么保證，則又是一門學(xué)問；最后還有比較火的智能硬件，盒子啊TV啊這些，怎么保證它的質(zhì)量，則又是另一種路子。

但，歸根結(jié)底：測試思想不會變，以不變應(yīng)萬變。

總結(jié)：

測試是一門大學(xué)問，它入門門檻并不高，但是越深入，你發(fā)現(xiàn)自己了解的越少。作為一個職場人員，不隨業(yè)務(wù)轉(zhuǎn)變而轉(zhuǎn)變，有自己的沉淀和技術(shù)底子，才能更長久。而測試開發(fā)這個行業(yè)，鄙人認(rèn)為未來也會愈加重要，它是銜接產(chǎn)品/測試/開發(fā)的一根紐帶，它在背后默默支撐著整個測試體系有條不紊的進(jìn)行，某種程度上說， 算是一個隱者吧。