在業界，隻要涉及測試，自動化是避不開的話題。
毫不避諱地說，對于一名qa人員而言，手工黑盒測試是最low的行為。在這個基礎上，不同風格的qa有不同的發展方向：成為業務專家、鑽研自動化測試、進行白盒測試、性能測試等。這篇文章主要從自動化的角度進行分析。
進行自動化，首先就是要進行自動化架構的選擇。目前開源的自動化架構簡直不能更多：底層的junit 、testng、 pyunit，以及業務類型強相關的webdriver、 selenium、 uiautomation等等。對于這些架構的選取，隻有合不合适，并不存在絕對意義上的好或者壞，在這裡也無意進行對比。而對于實際的業務痛點，這些架構也各有各的難處，也不多述。下面的正文主要是根據實際的業務痛點，談論下對自動化架構的訴求，實作難點以及一點思路（如果有可能，實作方式等放在其他文章中說明）。
痛點1：開發架構日新月異，而測試架構卻鮮有新意。
單元測試需要深入代碼邏輯，不過這基本是rd同學的任務，與qa人員貌似沒有太大關系，是以此處不提。
可能是基于測試活動的本身的特點，測試架構的種類範圍總是不大。自動化測試和項目本身在某種意義上講是分離的：不論是ui測試，還是接口測試，都是從外部去對系統進行檢驗，可以認為是一種比較高端的黑盒測試。ui測試方面，基于web的webdriver、基于app的appium、macaca都是cs模式，寫作用例的同學寫的本質上都是webdriver的用戶端，用戶端組裝webdriver請求，發送到服務端，服務端再通過js腳本進行具體操作；接口測試方面，最常用的就是模拟http/https協定發送請求到服務端，再根據服務端的傳回進行校驗。而testing這類底層架構，需要做的就是按照既定的流程去執行已經實作的各個功能，并聲稱測試報告。
當然，剛才提到ui和接口對應的兩類測試方式，都是基于手工測試抽象出來的，本身并沒有問題，也足以覆寫絕大部分場景。不過由于基礎測試手法的單調（或者說對自動化測試需求不多），自動化架構的花樣也比較少，無非是從不同的業務角度進行細化。
解決方案：暫時沒有。自動化測試就是手工測試的抽象，手工測試變革之前，自動化測也會保持現有的狀态。不過嚴格來講，上述内容本質上隻是一個現狀，并不是亟待解決的問題。
痛點2：頻繁變更的業務需求，導緻自動化的維護成本巨大。
現在進入主題。除非極少數純粹為了kpi而寫自動化的同學，一般而言，所有同學都希望自動化case能夠穩定執行，閑來無事發現幾個bug也是極好的。不過現實卻是：每當用例失敗時，排除用例本身問題，絕大多數情況下，都是需求變動導緻的。這恐怕也是大部分自動化測試同學的痛點，尤其是當case足夠多時，很難跟着版本去維護已有的case（與産品代碼不同，各個測試case的代碼往往是相對獨立的，彼此之間并沒有足夠的邏輯性，修改case時很可能需要把case完整看一遍；同時，在一個版本中，測試同學投入在自動化中的精力并不高，無法和開發同學投入項目的精力相提并論）。總而言之，case修改的進度肯定是很難趕上項目代碼修改的進度的。
解決方案：為什麼難？因為改測試case代碼成本高。成本高一方面是人員能力的問題，很多自動化case都是照貓畫虎寫出來的，qa同學對于case的原理并不清楚。遇到小的業務邏輯修改還可以接受；當變動大時，很可能會涉及到測試架構底層的修改，這種情況下，不少qa同學就被阻塞住了。是以，qa人員的能力提升就很重要。
不過，針對這個問題，架構能做什麼？我希望這個架構能夠屏蔽掉代碼層，而僅僅從功能點的層面進行修改。架構本身就可以提供一個ui界面，每個case是一個一系列功能點在ui界面的羅列，執行時是對每個功能的串行。當需求變動時，隻需要修改串行清單的内容和參數，而不需要修改代碼。如此一來，另一個問題就出來了，具體如何屏蔽，功能點怎麼來的？按照痛點1所說，所有測試行為的本質無非那麼幾個。對于ui——找元素、點選、輸入、拖動；對于接口——發http/https請求，收http/https響應，對結果的校驗幾乎等價于對xml/json的校驗。将這些主要功能點抽象出來，保留适當的接口，結合具體業務進行參數化配置即可。
痛點3：測試過程和結果的穩定性堪憂。
即使代碼不改動，在執行自動化case時，成功率也經常難以令人滿意。原因在于，影響最終輸出結果的因素中， 除去代碼邏輯，還包括産品的配置、上下遊服務調用時傳遞的消息、底層資料庫資料、中間件資料等。對于一個小系統來說，這些因素的可控性強一些；而對于較大的系統，一個測試團隊往往隻測試其中某一個子產品，對于其他子產品以及其他子產品對基礎資料的影響時無能為力的。
解決方案：對于可控的部分而言，做到環境可配置以及環境可恢複是很重要的，我認為這也是很多測試架構在具有test之外，還具有before 和 after的原因。不過這種方式也存在一些問題：1、修改成本高。修改資料庫、中間件資料，甚至修改産品配置，都需要通過代碼完成，而這些配置對于普通自動化協作人員而言，成本還是比較高的。2、case之間難免存在互相依賴活着互相影響的關系，盡管before和after執行的是一些基本操作，但并不能保證一定可以完全執行，當二者的某個過程執行失敗時，勢必造成資料的異常，而這種異常對其他case的影響，也是難以預知的。針對上述問題，也有兩點方案：1、收斂環境配置所需要的操作，盡量做到可固化，并進行封裝；2、重新設計自動化測試流程，盡最大努力保證before和after中的操作能夠完全執行。
對于不可控部分，需要能夠mock資料，這樣就減少了對其他系統的依賴。
痛點4：對于執行結果的校驗和問題定位不完善。
已有的自動化架構中，檢測用例是否成功的方法主要是流程是否執行完成以及通過assert判斷某些關鍵資料是否正确。我将這種校驗方式了解為散點式的校驗，校驗的結果僅限于流程是否正确，對于資料計算的正确性是無法覆寫到的。同時，一個完善的資料校驗，除了針對傳回結果，還應該針對執行過程進行校驗：同步/異步調用參數、資料落盤、關鍵日志等都是在手工測試時會關注但自動化覆寫不到的部分。是以說，怎樣做到從散點到線再到到面的覆寫，同時控制住自動化case的寫作和維護成本，可以作為判斷自動化架構優劣的标準。根據我目前的了解，現有開源自動化架構是可以做到這些的，問題在于成本太高。
解決方案：1、由點到線——橫向。橫向指的是對傳回資料（ui自動化通過webdriver協定，擷取頁面資訊的過程也可以了解為傳回資料）校驗的擴充。一般的自動化case校驗點主要是傳回狀态碼，或者頁面是否包含某些關鍵字，但涉及到資料的結構（比如json串的樹狀結構、頁面的html結構）、資料的準确性時，往往無能為力。一個重要的原因是在，這些資料對于case而言是不可控的：手工測試可以一步步從底層資料計算出最終資料，但自動化測試沒這麼靈活。一個解決方法是，通過與基礎分支的對比進行校驗。針對同一個case，在兩套代碼上分别（分别為master分支和dev分支）跑一次，以master代碼的結果為基準，對兩次的結果進行diff，進而判斷用例是否執行成功。說到這裡，又會延伸出很多其他問題，比如基礎資料一緻性、兩套代碼所部署環境的拓撲資訊、diff校驗方法、噪音處理等等，此處不多表述，後續在做架構設計時，會給出方案。
2、由點到線——縱向。縱向是指除了對傳回資料校驗之外，對系統本身的資料校驗。這塊目前時沒有太多技術難度的，難點在于時間成本。一個更加複雜的用例，在寫作和維護時都需要更多的時間。降低時間成本的方法，還是在于對功能的收斂和抽象和封裝，從業務中将功能進行抽離，封裝成通用功能，并提供合适的接口。
從單點開始，進行兩個次元的擴充，最終可以實作自動化從點到面的擴充。
總結： 進行自動化寫作，目的是維護系統穩定性，保證産品品質，而非單純kpi。自動化用例架構，存在一個貌似悖論的問題：應用靈活的自動化架構，往往比較複雜，對人員要求更高；簡單易用的架構，靈活性又比較差，不易适配業務需求。解決這個“悖論”的問題，需要從更宏觀的角度來看。個人認為有兩點：1、人員能力。老生長談，不說也罷。2、更改架構模式。根據實際業務狀态，在已有開源架構的基礎上，進行二次開發；或是另起爐竈，寫一個全新的自動化架構。目前正在構思一個測試架構，設計思路、實作思路應該也會寫在這裡。
上面是我收集的一些視訊資源，在這個過程中幫到了我很多。如果你不想再體驗一次自學時找不到資料，沒人解答問題，堅持幾天便放棄的感受的話，可以加入我們扣扣群【313782132 】，裡面有各種軟體測試資源和技術讨論。
當然還有面試，面試一般分為技術面和hr面，形式的話很少有群面，少部分企業可能會有一個交叉面，不過總的來說，技術面基本就是考察你的專業技術水準的，hr面的話主要是看這個人的綜合素質以及家庭情況符不符合公司要求，一般來講，技術的話隻要通過了技術面hr面基本上是沒有問題（也有少數企業hr面會刷很多人）
我們主要來說技術面，技術面的話主要是考察專業技術知識和水準，上面也是我整理好的精選面試題。
加油吧，測試人！如果你需要提升規劃，那就行動吧，在路上總比在起點觀望的要好。事必有法，然後有成。
資源不錯就給個推薦吧~