前言
- 最近不斷地回顧總結自己這些年作為測驗工程師的經歷，作為一名在測驗崗位上作業快5年的老兔，基本上已經歷完從新手到熟練的階段，做過各終端，供應鏈平臺、業務中臺，內容分發等質量保障的作業以及帶過團隊，朋友問過我在這些業務是干什么的，最初我可能會介紹說版本測驗、自動化測驗、測驗工具開發和流程規范，到后面總結為質量保證和效能提升，直到現在我認為簡練但又精粹的總結-測驗能力建設，我們看很多招聘資訊里面對測驗工程師的職責要求，列了很多項，包括了技術的要求和專案管理的要求等，最后都是能夠用測驗能力建設來概括，對于測驗能力建設，我們作為測驗工程師需要做些什么，接下來結合我個人的經歷來講一下怎么做測驗能力建設
關于測驗作業
- 測驗作業，換在4年前我第一反應可能也會認為是幫這個業務在每個版本中找bug，讓版本順利發布，但是作為工程師，我們的作業方式是否已經是以工程的形式開展，或許你看到研發同學敲代碼開發一個業務系統稱謂工程，把系統的各種能力各種服務規劃設計好稱謂架構，回到測驗的性質，不是開發一個測驗工具就叫測驗工程，不是把持續集成自動化測驗設計好落地好，把流程規劃好就叫做測驗架構，測驗作業其實是要求測驗工程師能夠把一個業務或者一整塊的業務的質量保障體系給建立起來，質量保障體系需要我們做的就是通過測驗能力建設
- 測驗能力建設，還是圍繞質量保障和工程效能的兩個核心，說通俗一些就是業務在質量和效率這兩塊缺什么，作為測驗工程師就需要做什么，這一點在很多企業中已經作為考核測驗工程師的指標
-
在作業中我們往往遇到接手別人的業務或接手新業務的測驗作業，或許你對這種業務有經驗，但也會遇到從來沒接觸過的業務，這樣我們如何開展測驗作業，不管是你做工程效能還是業務質量，開展任何作業的第一步都是熟悉，熟悉業務，熟悉技術，熟悉團隊協作，對于如何熟悉這一點，我會從這幾點出發
-
-
要入手一個業務首先是要了解前世今生，要知道這個業務存在的原因，定位是什么，發展至今現在又是怎么樣的形態，什么樣的地位，將來的發展方向是什么，這好比需要先認清自己
-
我們的業務如何交付給用戶使用，可以從發布流程入手，其實業務團隊里面的流程，不管是測驗流程還是研發流程，最終結果都會表現在發布流程，發布流程可以推匯出業務團隊用的是什么研發流程，用什么測驗流程，同時通過發布流程我們可以了解到系統的部署，從而推匯出系統架構，依賴呼叫關系等，再深入推匯出業務使用的技術堆疊，發布策略，人員水平等，所以我每加入一個新團隊或接手新業務，我習慣性的會看版本如何發布，發布流程是怎么樣的，以此為線索，很容易就可以把業務團隊的協作能力和技術能力了解清楚，這個就是了解業務內部
-
用戶怎么使用我們的業務，其實就是了解我們業務的外部情況，我們的目標用戶是誰，表現形態如何，我們的業務為用戶產出了什么，解決了什么，大家可以試一下通過上面的一些方法是否會更容易了解一個業務甚至一整塊業務
-
對于業務了解完之后，那接下來才是測驗工程師的主菜，我們怎么去做測驗能力建設
-
測驗能力建設
- 測驗能力建設有一個關鍵點，就是如何把測驗肉身投入轉換成測驗能力投入，我們是人，但我們也是能力的一種，但能力未必是人，他可以是技術，可以是流程，簡單地說就是怎么把人力轉換成技術能力和流程化
-
在測驗能力建設的作業投入中，直白的目標就是業務需要什么我們就做什么，所以我們還是需要找到適合業務和團隊的方式，傳統的IT公司習慣走V模型或是雙V模型，到了互聯網行業，大家都開始強調要研測一體，devops，測驗左移右移等，在我的經歷中大部分在互聯網行業，所以習慣性從方向上會考慮當前業務和團隊要如何左右移，如圖中所示
-
測驗左移強調的是盡早介入測驗，提前發現問題
-
這時候還是從工程化和流程優化那兩個點去打，我之前所在的業務，我投入測驗時一般會先規范代碼的管理分支，在多位研發并行開發的時候我們需要怎么規避一些由于切分支帶來的問題，我們明確好開發分支，提測分支，發布分支和主干，測驗只接受提測分支的版本測驗，發布的版本只能用發布分支等，同時接入靜態代碼掃描等代碼精準測驗的能力，研發每次提交代碼后基本上都經歷了一層代碼掃描的質量保障程序，同時在介面和端功能層面，作為測驗我會去建立自動化回歸測驗的能力，我們可以用介面測驗框架或UI測驗框架等自己手打自動化測驗用例，把持續集成的流程建設起來，也可以通過更成熟的工具或平臺如線上流量引流回歸等等，其實就是通過大規模的自動化等能力來從最根本的代碼層面，介面層面等保障起來，為了就是盡可能不帶bug提測，所以這個程序就是要做如何把這些自動化的能力建設起來，缺乏工具和平臺的時候，我們就得去找合適的工具和平臺，找不到就得自己設計開發，這也是作為測驗開發乃至所有的測驗工程師都需要具備的能力，有了工具和平臺之后就結合業務的特征進行相應能力的建設，做到懂得用，懂得做，懂得落地
-
在流程上，左移的方式是通過提前交付測驗用例或測驗方案實行研發自測，為了還是不要把bug帶到測驗階段這個目標，或許研發會質疑說研發來測驗，要測驗來干嘛，我們從ROI的角度去思考，研發自測花大概0.5到1個人天，但如果出現bug導致版本阻塞，可能影響的就不是0.5到1個人天，測驗包來來回回幾次，測驗找bug，定位bug原因等，一不小心幾天就過去了，這時候就會出現版本延期的風險，所以我們要把問題扼殺在搖籃之中，這需要代價，但這也給我們帶來了更好的結果，研發自測和產品驗收很大程度就是依賴了測驗用例或測驗方案，所以這個時候我們就不僅僅是把當前的需求要點或技術改動點給覆寫，當然不是說所有的用例產品研發都要過完，測驗工程師是測驗執行的兜底，研發基本上都是把核心鏈路和功能過完后就提測，這時我們更多的是實踐探索性的測驗，測驗執行和研發分工，節省的時間做更有深度的測驗作業，包括把版本的一些測驗需求自動化，或者考究安全性性能等，我在寫測驗用例或方案的時候基本上會使用這個大綱
-
-
每個版本的測驗，不是簡簡單單把測驗用例執行完，功能執行完就完成的，每做一件事情，必須明確這件事情的目標或背景，因為接下來所做的一切都會圍繞著這個目標去開展，對于目標不清晰的，設計出來的方案或用例，存在偏差的概率就會增大，也就會存在漏測的風險，二來我們需要明確版本的改動范圍，尤其是多組件多服務組成的業務，在加上相關依賴關系，這個是可以用來明確我們的測驗范圍，測驗成本永遠都是有限的，要做到即充分又低成本的那就需要明確測驗范圍，目標和范圍都明確之后我們就可以進行相關的用例設計，需求的用例，技術性的用例，都需要在測驗用例中體現，具體的如介面的邏輯是如何的，快取的邏輯如何，如遇到資料遷移等情況，我們也需要把對應的資料驗證和資料同步用例等設計好，
-
把測驗階段的驗證都設計好之后，那就是發布階段和運營階段的一些質量保障手段，大家都了解有灰度發布，流量隔離，線上監控，線上驗收等一些測驗能力，這些就是在測驗右移中采取的一些質量保障策略，所以在設計階段我們就要把作為線上驗收能力的一些打點和日志輸出設計好，監控項給明確好，甚至設計好質量相關的資料報表，通過這些采集監控資料進行分析和配置告警，來觀察版本發布的情況，從而建立了一個線上的業務健康度模型
-
有些情況確實是通過測驗右移的方式來執行，我在做中臺業務的時候，經常遇到業務方由于環境等原因，功能必須在線上驗收，所以這個時候我們就需要有線上驗證的能力，線上驗證的原則是盡可能的不要影響到原有功能和使用業務的用戶，這個就需要做好很好的隔離，所以從研發一開始的設計就從線上可測性角度就需要考慮到這一點，功能做好隔離，資料做好隔離，一旦出現問題，我們有相對應的風險預案，如何清除臟資料，如何將功能降級等，前期的設計都要考慮好，發布完成以后我們還需要考慮運營層面的事情，運營事故在各大互聯網公司中也是屢見不鮮，比如暴露了一些敏感資料等，對于這方面作為業務的測驗我們也是需要建立其相關的防范機制，不管是流程上和從技術上去杜絕，這往往也會在我們的風險預案中體現，當然故障都沒有是最好的，但一旦出現故障的時候我們就要能夠快速的發現和解決，這也是我們作為測驗能力建設中的一個重要環節，下面就是我根據上面的一些方法論所建立的專案流程
-
-
小結
- 是否會發現，一旦把這些能力都建立起來，測驗人員的投入就會變成測驗能力的投入，測驗工程師就是測驗能力的體現，測驗能力的建設者，只要安排人員去執行使用測驗能力即可，就不一定需要測驗工程師的肉身投入，讓業務都具備自我質量保障的能力，從根本上的提效和降低投入成本
- 縱觀我上文所說，其實我作為測驗工程師大部分的時間都是在做測驗設計，測驗設計體現一名測驗工程師的產出，測驗執行不一定需要測驗工程師來做，但需要你做好的是在測驗能力方面的建設，質量是整個團隊的目標和責任，測驗工程師就是專門為這個目標出謀劃策的，我們認清出自己的職責，把自己的思維轉換過來，把肉身轉化成能力，把人力成本變成技術成本，這是作為測驗工程師價值的體現，希望通過此文，能夠對大家在測驗作業上有一點點幫助，謝謝
-
-
-
-
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/135452.html
標籤：其他