論測試工程師的職責

前言

• 最近不斷地回顧總結自己這些年作為測試工程師的經歷，作為一名在測試崗位上工作快5年的老兔，基本上已經歷完從新手到熟練的階段，做過各終端，供應鏈平臺、業務中臺，內容分發等質量保障的工作以及帶過團隊，朋友問過我在這些業務是幹什麼的，最初我可能會介紹說版本測試、自動化測試、測試工具開發和流程規範，到後面總結為質量保證和效能提升，直到現在我認為簡練但又精粹的總結-測試能力建設，我們看很多招聘資訊裡面對測試工程師的職責要求，列了很多項，包括了技術的要求和專案管理的要求等，最後都是能夠用測試能力建設來概括，對於測試能力建設，我們作為測試工程師需要做些什麼，接下來結合我個人的經歷來講一下怎麼做測試能力建設

關於測試工作

• 測試工作，換在4年前我第一反應可能也會認為是幫這個業務在每個版本中找bug，讓版本順利釋出，但是作為工程師，我們的工作方式是否已經是以工程的形式開展，或許你看到研發同學敲程式碼開發一個業務系統稱謂工程，把系統的各種能力各種服務規劃設計好稱謂架構，回到測試的性質，不是開發一個測試工具就叫測試工程，不是把持續整合自動化測試設計好落地好，把流程規劃好就叫做測試架構，測試工作其實是要求測試工程師能夠把一個業務或者一整塊的業務的質量保障體系給建立起來，質量保障體系需要我們做的就是通過測試能力建設帶建立
• 測試能力建設，還是圍繞質量保障和工程效能的兩個核心，說通俗一些就是業務在質量和效率這兩塊缺什麼，作為測試開發就需要做什麼，這一點在很多企業中已經作為考核測試開發的指標

• 在工作中我們往往遇到接手別人的業務或接手新業務的測試工作，或許你對這種業務有經驗，但也會遇到從來沒接觸過的業務，這樣我們如何開展測試工作，不管是你做工程效能還是業務質量，開展任何工作的第一步都是熟悉，熟悉業務，熟悉技術，熟悉團隊協作，對於如何熟悉這一點，我會從這幾點出發
  

• 要入手一個業務首先是要了解前世今生，要知道這個業務存在的原因，定位是什麼，發展至今現在又是怎麼樣的形態，什麼樣的地位，將來的發展方向是什麼，這好比需要先認清自己

• 我們的業務如何交付給使用者使用，可以從釋出流程入手，其實業務團隊裡面的流程，不管是測試流程還是研發流程，最終結果都會表現在釋出流程，釋出流程可以推匯出業務團隊用的是什麼研發流程，用什麼測試流程，同時通過釋出流程我們可以瞭解到系統的部署，從而推匯出系統架構，依賴呼叫關係等，再深入推匯出業務使用的技術棧，釋出策略，人員水平等，所以我每加入一個新團隊或接手新業務，我習慣性的會看版本如何釋出，釋出流程是怎麼樣的，以此為線索，很容易就可以把業務團隊的協作能力和技術能力瞭解清楚，這個就是了解業務內部

• 使用者怎麼使用我們的業務，其實就是了解我們業務的外部情況，我們的目標使用者是誰，表現形態如何，我們的業務為使用者產出了什麼，解決了什麼，大家可以試一下通過上面的一些方法是否會更容易瞭解一個業務甚至一整塊業務

• 對於業務瞭解完之後，那接下來才是測試工程師的主菜，我們怎麼去做測試能力建設

測試能力建設

• 測試能力建設有一個關鍵點，就是如何把測試肉身投入轉換成測試能力投入，我們是人，但我們也是能力的一種，但能力未必是人，他可以是技術，可以是流程，簡單地說就是怎麼把人力轉換成技術能力和流程化

• 在測試能力建設的工作投入中，直白的目標就是業務需要什麼我們就做什麼，所以我們還是需要找到適合業務和團隊的方式，傳統的IT公司習慣走V模型或是雙V模型，到了網際網路行業，大家都開始強調要研測一體，devops，測試左移右移等，在我的經歷中大部分在網際網路行業，所以習慣性從方向上會考慮當前業務和團隊要如何左右移，如圖中所示
  

• 測試左移強調的是儘早介入測試，提前發現問題

• 這時候還是從工程化和流程優化那兩個點去打，我之前所在的業務，我投入測試時一般會先規範程式碼的管理分支，在多位研發並行開發的時候我們需要怎麼規避一些由於切分支帶來的問題，我們明確好開發分支，提測分支，釋出分支和主幹，測試只接受提測分支的版本測試，釋出的版本只能用釋出分支等，同時接入靜態程式碼掃描等程式碼精準測試的能力，研發每次提交程式碼後基本上都經歷了一層程式碼掃描的質量保障過程，同時在介面和端功能層面，作為測試我會去建立自動化迴歸測試的能力，我們可以用介面測試框架或UI測試框架等自己手打自動化測試用例，把持續整合的流程建設起來，也可以通過更成熟的工具或平臺如線上流量引流回歸等等，其實就是通過大規模的自動化等能力來從最根本的程式碼層面，介面層面等保障起來，為了就是在儘可能不帶bug提測，所以這個過程就是要做如何把這些自動化的能力建設起來，缺乏工具和平臺的時候，我們就得去找合適的工具和平臺，找不到就得自己設計開發，這也是作為測試開發乃至所有的測試工程師都需要具備的能力，有了工具和平臺之後就結合業務的特徵進行相應能力的建設，做到懂得用，懂得做，懂得落地

• 在流程上，左移的方式是通過提前交付測試用例或測試方案實行研發自測，為了還是不要把bug帶到測試階段這個目標，或許研發會質疑說研發來測試，要測試來幹嘛，我們從ROI的角度去思考，研發自測花大概0.5到1個人天，但如果出現bug導致版本阻塞，可能影響的就不是0.5到1個人天，測試包來來回回幾次，測試找bug，定位bug原因等，一不小心幾天就過去了，這時候就會出現版本延期的風險，所以我們要把問題扼殺在搖籃之中，這需要代價，但給我們帶來了確實更好的結果，研發自測和產品驗收很大程度就是依賴了測試用例或測試方案，所以這個時候我們就不僅僅是把當前的需求要點或技術改動點給覆蓋，當然不是說所有的用例產品研發都要過完，測試工程師是測試執行的兜底，研發基本上都是把核心鏈路和功能過完後就提測，這是我們更多的是實踐探索性的測試，測試執行和研發分工，節省的時間做更有深度的測試工作，包括把版本的一些測試需求自動化，或者考究安全性效能等，我在寫測試用例或方案的時候基本上會使用這個大綱
  

• 每個版本的測試，不是簡簡單單把測試用例執行完，功能執行完就完成的，每做一件事情，必須明確這件事情的目標或背景，因為接下來所做的一切都會圍繞著這個目標去開展，對於目標不清晰的，設計出來的方案或用例，存在偏差的概率就會增大，也就會存在漏測的風險，二來我們需要明確版本的改動範圍，尤其是多元件多服務組成的業務，在加上相關依賴關係，這個是可以用來明確我們的測試範圍，測試成本永遠都是有限的，要做到即充分又低成本的那就需要明確測試範圍，目標和範圍都明確之後我們就可以進行相關的用例設計，需求的用例，技術性的用例，都需要在測試用例中體現，具體的如介面的邏輯是如何的，快取的邏輯如何，如遇到資料遷移等情況，我們也需要把對應的資料驗證和資料同步用例等設計好，

• 把測試階段的驗證都設計好之後，那就是釋出階段和運營階段的一些質量保障手段，大家都瞭解有灰度釋出，流量隔離，線上監控，線上驗收等一些測試能力，這些就是在測試右移中採取的一些質量保障策略，所以在設計階段我們就要把作為線上驗收能力的一些日誌輸出設計好，監控項給明確好，甚至設計好質量相關的資料包表，通過這些採集監控資料進行分析和配置告警，來觀察版本釋出的情況，從而建立了一個線上的業務健康度模型

• 有些情況確實是通過測試右移的方式來執行，我在做中臺業務的時候，經常遇到業務方由於環境等原因，功能必須線上上驗收，所以這個時候我們就需要有線上驗證的能力，線上驗證的原則是儘可能的不要影響到原有功能和使用業務的使用者，這個就需要做好很好的隔離，所以從研發一開始的設計就從線上可測性角度就需要考慮到這一點，功能做好隔離，資料做好隔離，一旦出現問題，我們有相對應的風險預案，如何清除髒資料，如何將功能降級等，前期的設計都要考慮好，釋出完成以後我們還需要考慮運營層面的事情，運營事故在各大網際網路公司中也是屢見不鮮，比如暴露了一些敏感資料等，對於這方面作為業務的測試我們也是需要建立其相關的防範機制，不管是流程上和從技術上去杜絕，這往往也會在我們的風險預案中體現，當然故障都沒有是最好的，但一旦出現故障的時候我們就要能夠快速的發現和解決，這也是我們作為測試能力建設中的一個重要環節，下面就是我根據上面的一些方法論所建立的專案流程
  

小結

• 是否會發現，一旦把這些能力都建立起來，測試人員的投入就會變成測試能力的投入，業務團隊擁有了測試能力，只要安排人員去執行使用測試能力即可，就不一定需要測試工程師的肉身投入，從根本上的提效和降低投入成本
• 縱觀我上文所說，其實我作為測試工程師大部分的時間都是在做測試設計，測試設計體現一名測試工程師的產出，測試執行不一定需要測試工程師來做，也就是你在測試能力方面的建設，質量是整個團隊的目標和責任，測試工程師就是專門為這個目標出謀劃策的，我們認清出自己的職責，把自己的思維轉換過來，把肉身轉化成能力，把人力成本變成技術成本，這是作為測試工程師價值的體現，希望通過此文，能夠對大家在測試工作上有一點點幫助，謝謝