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

自動(dòng)化測(cè)試vs測(cè)試開發(fā)

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

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

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

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

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

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

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

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

1.正確的流程

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

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

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

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

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

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

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

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

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

工程師文化

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

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

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

2.測(cè)試到最終場(chǎng)景

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

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

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

4.對(duì)相似問題和漏洞的歸納

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

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

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

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

總結(jié)：

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