吳雄琳（榮木） 淘系技術

本文從阿里測試工程師親身經歷的角度，和大家聊聊測試一行學習成長的經歷。

對自動化測試個人看法

自動化是一個老生常談的話題，也是一個軟體領域非常有技術廣度和技術深度的活動，特別是在大型軟體的生命週期上。

個人覺得開展自動化測試的難度不亞於傳統意義上的軟體開發。

從產品角度來看：質量領域本身要求從業人員要全面瞭解產品、有全域性風險意識，例如：產品需求/設計階段能否發現設計缺陷、產品測試階段能否發現深層次的bug、產品運維階段能否制定良好的灰度策略、快速發現、定位線上問題，甚至如何做好新/老系統線上過渡切換等等，這裡面都有自動化測試可發揮的空間。

從技術的廣度和深度來看：

從技術廣度來說，不同的技術領域的質量保障需要使用不同的技術（這些技術領域都有一些代表性的工具，但不一定能完全滿足實際的專案自動化測試需求），例如有做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做自動化測試應該掌握哪些技術？

說到具體的技術，其它回覆也有提到，感覺整體太散了，初學者可能有點摸不到邊，不知從哪裡開始，個人建議順序是這樣的：

那讓我們先修煉下最基本的內功吧！

軟體工程&測試理論基礎

各個公司產品形態迥異，因此也制定了不同的軟體研發流程。大多數大公司都設定有運營、產品、視覺/互動、開發、測試、運維、技術支援、客服等崗位，應當明白各個角色的職責，以及瞭解整個產品運轉的邏輯。至少應該瞭解所在公司的研發流程以及當前主流的研發流程（如敏捷開發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來說，精力有限的情況下，可能又要懂點服務端、又要懂點客戶端、又要懂點演算法等等。再加上各種產品、技術形態不一，也衍生出了形形色色的工具和研究方向，初學者容易受到誤導，不知所措。自動化測試和開發角色一樣，也是一個逐步積累、實踐的過程。

關於自動化測試確實有非常多的內容可以交流、學習，篇幅有限，先寫到這裡啦。以上內容是個人對自動化測一些理解，當然，如果繼續往上走，到管理者，需要掌握的知識也遠不止這些了。