本文 從 阿里測驗工程師親身經歷的角度，和大家聊聊測驗一行學習成長的經歷，
對自動化測驗個人看法
自動化是一個老生常談的話題，也是一個軟體領域非常有技術廣度和技術深度的活動，特別是在大型軟體的生命 周期上，
個人覺得開展自動化測驗的難度不亞于傳統意義上的軟體開發，
從產品角度來看： 質量領域本身要求從業人員要全面了解產品、有全域風險意識，例如：產品需求/設計階段能否發現設計缺陷、產品測驗階段能否發現深層次的bug、產品運維階段能否制定良好的灰度策略、快速發現、定位線上問題，甚至如何做好新/老系統線上過渡切換等等，這里面都有自動化測驗可發揮的空間，
給大家推薦一個軟體測驗技術交流群：1079636098 群友福利免費領取
從技術的廣度和深度來看：
-
從技術廣度來說， 不同的技術領域的質量保障需要使用不同的技術（這些技術領域都有一些代表性的工具，但不一定能完全滿足實際的專案自動化測驗需求），例如有做JUnit介面測驗的、有做Web/App/桌面客戶端 UI測驗的、有做性能測驗的、有做用戶體驗測驗的、有做AI演算法測驗的、有做IoT的、有做壓測的、有做各種專項（如兼容性、安全、多媒體、網路）測驗的等等，實在太多了......，
如果考慮到測驗工具本身的可用性、系統性，除知道使用工具以外，可能還需要掌握一些基礎開發技能，例如：Java/Node/Python后臺、React/H5前端、或者Android/iOS客戶端；
-
從技術深度來說， 想通過開發軟體去測驗另一個軟體是否正常，本身就是一個很具挑戰的事情，特別是在黑盒的狀態下，舉個例子，試想你能否開發一款自動化測驗工具能夠模擬人的意識形態，它能夠對當前多如牛毛的App開展自動化測驗，很多人此時想起了Monkey、Appium、AirTest或者Applitools，其實這遠遠不夠，因為目前并不具備解決場景構建甚至自我發現缺陷的能力，簡單來說，還不具備“認知”App的能力，這個想法不是天方夜譚，事實上很多人正在往這個方向努力ing，自動化測驗遠遠不只是在一個已有的工具上開發自己的腳本，達到所謂的一個通過率或覆寫率，更核心是思考如何在軟體生命周期各個階段提升產品研發效能及穩定性甚至用戶體驗，
技術新人如何學習自動化測驗
首先簡單了解下QA在軟體研發迭代程序中的定位
傳統軟體使用較多的是瀑布模型，測驗人員的活動區域是有限的，活動的時間區域主要是提測至上線前，
傳統瀑布模型中，QA發揮的空間比較有限，質量壓力都集中在測驗階段，隨著軟體規模的擴大、部門職能的劃分、敏捷迭代模式的發展，互聯網或者大型軟體專案絕大部分演變成了DevOps：
DevOps是軟體文化上的一次飛躍，它強調產品、開發、測驗、交付、運維各個環節的溝通合作，將敏捷的方式延伸到整個產品，從QA的角度也有了測驗左移和測驗右移的概念，
測驗左移：
測驗左移的思想是需求階段、開發架構設計階段或是未到系統測驗或集成測驗前就進行測驗，目標是降低時間成本、減少風險，從用戶角度描述產品行為、從技術角度建立好開發與產品需求的連接，防止產品設計上的雷或缺陷，這有利于減少無效代碼的開發、以投入更好的時間在正確的產品上，也可以在代碼撰寫階段進行單元測驗或覆寫率統計，
日常作業中，QA都期望只對修改的代碼或受連帶影響功能/需求進行測驗，從而減少重復回歸的作業量，即“精準測驗”，但是實際上，往往得到開發同學的回復要么是“最好全回歸或者核心流程全回歸”，要么“是沒關系的，就回歸下A功能就好”（實際可能已經帶雷上線了），設想如果能夠有個工具能夠幫我們將需求與相關的代碼呼叫堆疊聯系起來，在相關代碼依賴變動時都能夠自動評估有效回歸范圍，可能是“精準測驗”實作的一個方向（我相信業界應該已經有人在做了），
測驗右移：
測驗右移簡單來說是指產品上線以后開展的一系列質量活動，事實證明，在快速迭代以及產品復雜化、多樣化的今天，幾乎不可能做到0缺陷上線，當然，對硬體產品或涉及資金的產品而言，存在缺陷可能意味著產品召回或是資損，會給公司帶來巨大損失，對于某些互聯網產品而言，由于產品發布的天然優勢，一般具備熱修復、熱發布能力，因此在時間和產品質量維度，可能會更強調快速上線，比如facebook就提倡灰度快速上線，因而如何監控產品的穩定性、第一時間發現線上用戶問題、用戶反饋并使問題及時得到解決、如何了解更好的用戶需求（如AB測驗）變成了QA在測驗右移活動中的關注點，期間也有大量自動化測驗可發揮的空間，
由此可見，QA發揮的空間是在整個軟體的生命周期的，DevOps的理念也強調流程自動化，我理解的在各個階段能夠代替人工作業、提升測驗效率的都可以稱之為自動化測驗，這也反過來要求QA具備更高的軟體產品流程/風險意識以及更強的自動化理念、編碼落地實踐能力，
QA做自動化測驗應該掌握哪些技術？
說到具體的技術，其它回復也有提到，感覺整體太散了，初學者可能有點摸不到邊，不知從哪里開始，個人建議順序是這樣的：
那讓我們先修煉下最基本的內功吧！
給大家推薦一個軟體測驗技術交流群：1079636098 群友福利免費領取
軟體工程&測驗理論基礎
各個公司產品形態迥異，因此也制定了不同的軟體研發流程，大多數大公司都設定有運營、產品、視覺/互動、開發、測驗、運維、技術支持、客服等崗位，應當明白各個角色的職責，以及了解整個產品運轉的邏輯，至少應該了解所在公司的研發流程以及當前主流的研發流程（如敏捷開發Scrum），并在專案程序中積極思考，形成自身的軟體意識與理念，在校的同學可以多在網上找找資料，有個大概了解，個人理解，軟體工程本身是一個浩大的工程，也在日新月異不斷地向前發展，它需要長期積累、不斷修煉內功，并在實際專案中實踐驅動，從業2年、5年、10年、20年都會有不同層次/深度的理解，自動化測驗亦是如此，
關于測驗理論基礎這里不贅述了，網上資料一大把，搜白盒/黑盒、等價類、邊界值等關鍵字就可以找到，
通用計算機基礎（其實就是計算機專業相關的大學課程）
建議至少掌握一門編程語言（C/C++/Java/Python，推薦Python，學習成本相對更簡單一些），相比于特定需求/領域的開發人員來說，測驗人員對編碼技術要求相對會榷訓一些（當然并不意味著不需要極客精神、架構思想），涉及到Web、桌面GUI、Android/iOS的可以到具體應用再學習相應的框架，
-
掌味訓本的資料結構以及在具體程式語言中的應用，例如：list、map，
-
掌握面向物件程式設計的基本思想，
-
掌握一種代碼管理工具，如git、svn，
-
掌握Linux的使用及基本命令使用，如： cp、grep、vi/vim等，
-
掌握關系資料庫的基本理論和關系資料庫（如MySQL）SQL基本使用、NoSQL（如Redis）的基本使用，
-
掌味訓礎的計算機網路理論，如TCP/UDP協議、IP劃分，
接下來，我們就需要站在巨人的肩膀上了，這部分可以根據實際需要進行學習，涉及的內容實在太多了，我這里主要從App自動化測驗的角度給出一些工具使用、方向學習建議，大家搜關鍵字應該都能找到一些資料，
服務端：
-
白盒單元測驗：Junit(Java)、unittest(Python)、gtest(C++)
-
http介面測驗： Postman
-
抓包工具： Charles、Wireshark
-
壓測： Jmeter，在大廠里面都會有特定的一些寫好的工具可以使用，
-
鏈路依賴分析： 梳理應用間的依賴關系，提供壓測模型，大廠里面也有一些工具可以使用，
-
監控&日志分析： 應用穩定性監控，如qps、rt，服務器負載、cpu監控等，日志分析這塊可以做一些基于規則的錯誤日志監控、甚至基于AI的方式（如： 機器學習）對日志大資料進行聚類、問題分析/定位，
客戶端（Android/iOS/H5）：
-
UI：Appium、Macaca、Airtest
-
性能（CPU/記憶體/幀率）： Android Studio、Instruments(iOS)
-
穩定性： Monkey
-
兼容性： 各種云真機平臺
事實上，即使非常熟練掌握了以上工具，也無法達到完全釋放人力的目的，甚至在自動化實踐程序中會存在各種各樣的問題（例如如何針對具體的場景設計自動化用例、提升覆寫率、如何維護/構造測驗資料、如何進行精確校驗、如何提高執行穩定性、如何縮短執行時長、如何監控線上問題等等），
這就需要我們更加深度的去了解產品形態、在已有工具解決不了問題時，怎么去用創新的思維看待各個階段面臨的問題、甚至創造工具，這已經不僅僅只是技術本身的問題了，而是如何去挖掘、思考問題、如何去運用技術的問題了，實際上自動化測驗可以歸納為如下幾個階段，這也是近2年智能化測驗的研究方向：
另外，個人覺得目前市面上對自動化測驗其實是存在的一些誤區的：
-
認為自動化測驗無所不能，只要有自動化，人工可以完全釋放， 對于復雜產品，目前來看，這幾乎是不可能的， 因此，目前市面上并沒有類似“統一宇宙理論”的自動化測驗工具，
-
自動化測驗沒技術含量（測驗沒開發有前途），如果僅僅是對工具使用，沒有創造力，那確實沒有什么太高的技術含量， 但是如果是在DevOps各個階段發揮最大價值，個人認為比傳統意義的開發崗位難度更高，并且可發揮空間更大， 舉個例子，能否創造一種工具，能夠根據視覺稿或者App UI自動生成測驗用例（啊？ 怎么可能，試想下人是怎么設計用例的，得益于AI技術的發展，這完全有可能，目前也有一些根據視覺稿生成前端代碼的工具了）， 我不覺得這是一個沒技術含量或沒有價值的自動化測驗， 近些年，質量領域的大會越來越多，大家也可以關注關注， 例如QCon、MTSC、TICA、Tid等等，
-
自動化覆寫率至高無上， 這部分往往來自人們對自動化測驗過高的期望，為了提升覆寫率，未考慮好ROI，以至于南轅北轍，入不敷出， 著名的測驗金字塔給了最好的解釋，
-
人云亦云，泛而不專， 相比于開發人員，個人認為QA開展自動化測驗需要掌握的技術知識可能會更廣泛，例如： 開發人員可能專注于Android、iOS或者Java后端，亦或是某類AI演算法，即對開發人員的要求是對某一技術掌握的足夠深入，對QA來說，精力有限的情況下，可能又要懂點服務端、又要懂點客戶端、又要懂點演算法等等， 再加上各種產品、技術形態不一，也衍生出了形形色色的工具和研究方向，初學者容易受到誤導，不知所措， 自動化測驗和開發角色一樣，也是一個逐步積累、實踐的程序，
關于自動化測驗確實有非常多的內容可以交流、學習，篇幅有限，先寫到這里啦，以上內容是個人對自動化測一些理解，當然，如果繼續往上走，到管理者，需要掌握的知識也遠不止這些了，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/249356.html
標籤：其他