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