① 如何進行前端自動化測試
沒人邀請，路過回答。
前端測試是前端工程方面的重要分支，有過一些探索，這里簡單分享一下。
首先，還是要強調一點：
前端是一種特殊的GUI軟體
看過我最近一年內做前端工程方面相關分享的人可能有印象，我總是在強調這一點。前端測試也跟這個理論基礎有所關聯。
在這里，我還想吐槽一下：
API測試方法論在測試GUI時並不能解決所有問題。
與很多前端工程師討論過前端測試，大家更多的還是盯著API測試方法論。誠然，前端有那麼一小部分代碼是可以用API測試保證質量的，但前端項目中的絕大多數代碼是GUI界面，前端測試應該向傳統GUI測試方法論需求解決方案：GUI軟體測試_網路 ，這個網路詞條介紹的很不錯，大家可以感受一下GUI測試相關概念和方法。它的測試用例、覆蓋率統計、測試方法等等都與API測試有著很大的不同。
統一了這個認知之後，我們來討論一下前端GUI測試的特殊性。根據網路詞條上的那些介紹，相信大家都能感覺到GUI測試的成本非常高，而前端這種特殊的GUI軟體，具有天生的快速迭代特徵，這使得case維護成本也變得非常高，經常跟不上迭代速度。
一
個標準的互聯網應用產品的前端部分，我粗略估計大概有20%的業務基礎代碼比較穩定，比如通用組件、通用演算法和數據模塊等，可以針對這些建立復雜一些的
API和GUI測試用例來保證質量。剩下80%的部分不是很穩定，每天都在迭代，針對他們維護case的成本非常高。目前業界中號稱做了自動化測試的項
目，也大多是在做那穩定的20%。
關於穩定部分的單元測試方法我這里就不贅述了， @貘吃饃香 的答案給出了很多關鍵字，有興趣的去搜索就好了。我想討論的是針對剩下80%不穩定部分的工程化測試方案。據我了解，前端測試面對這些問題還是很無力的，業內大部分團隊還是靠堆人解決。
面對這種現狀，我其實也沒想到過什麼好的方法，基本原則就是：以最低的成本建立和維護自動化測試用例。到目前為止，就想到過兩個方案（都不是測試方案，只是回歸測試輔助）：
1. 不太靠譜的「超級工位」大法。
這個方案可以說根本不是什麼技術方案，而是一個辦公設施，就是我們准備一個工位，擺上所有我們需要測試的主流設備，然後設備通過某種方式與一台電腦相連接，測試人員坐在工位上，在電腦中輸入某個url，就能同步到所有設備中，然後開始逐個的人肉測試。
超級工位大法示意圖（應該很多設備的，這里就是隨便展示一下而已。。。）超級工位大法示意圖（應該很多設備的，這里就是隨便展示一下而已。。。）
相比現在的前端GUI測試，超級工位已經算是從0到1的飛躍了，雖然沒解決什麼技術問題，但為測試前的准備工作做好了鋪墊。如果把前端測試比作吃屎，超級工位就是為這餐准備了一個好一點的餐桌。。。
2. 靠譜一些的「頁面差異監控」
12
年的時候還在網路，當時有同事去美國參加velocity，twitter分享了一下他們的開發流程，其中有一個環節就是頁面對比監控，利用了一個叫
pdiff的工具，每次提交代碼，會自動對比頁面之間的差異然後提醒測試人員注意回歸。這也是一個典型的GUI測試零成本維護用例的案例。不過pdiff
這個工具是基於像素對比的，誤報率比較高，所以去年我做了一個這個項目：fouber/page-monitor · GitHub 基於DOM樹的diff，這樣就能很大程度上自主控制要監控的元素，可以設置監控樣式、文本的變化，比起像素diff智能了一些。
其
工作原理就是利用phantom或其他headless瀏覽器訪問頁面，然後截圖，然後執行一段js，遍歷整個dom樹，獲取元素計算樣式和元素內文本內
容，構造出一個JSON結構，然後每次diff這個json來判斷頁面差異，並標記在截圖上展示。dom樹的diff過程有點類似react的虛擬dom
樹diff。
（react的dom樹diff演算法示意圖）（react的dom樹diff演算法示意圖）
（react的dom樹diff演算法示意圖）（react的dom樹diff演算法示意圖）
DOM樹diff我們可以分辨出元素樣式修改/內容修改/新增元素/刪除元素四種不同的頁面差異，我們可以配置選擇器來忽略元素。四種頁面差異的效果圖：
新增元素（綠色區域標記部分，「i am new here」）新增元素（綠色區域標記部分，「i am new here」）
刪除元素（灰色區域標記部分，「你好」）刪除元素（灰色區域標記部分，「你好」）
內容修改（黃色區域標記部分，「百-度」，「新-浪」）內容修改（黃色區域標記部分，「百-度」，「新-浪」）
樣式修改（紅色區域標記的部分）樣式修改（紅色區域標記的部分）
基於這樣的頁面差異對比監控，我們可以建立一個任務系統，把應用的所有頁面url監控起來，這樣每次版本迭代提交代碼後，系統就能自動告訴我們，哪些頁面的元素展現發生了改變，用於確定回歸范圍。
用監控的方式確定測試回歸范圍，是一種「少吃屎」的手段，符合工程化要求，能比較大范圍的應用，雖然不能完美解決GUI中的交互問題，但能保證GUI的展現問題已經是不小的進步了。
② 兩年前端開發，感覺太累了，不知道該不該換行
同開發，只不過我是兩年後端開發，外行人只看到我們行業掙得多，卻不知道我們多少個日日夜夜加班到凌晨，為了上線穩定通宵也是有的。這個行業累是肯定的，但我想我們的收獲也是多的，正所謂收獲與付出成正比。樓主如果是喜歡這個行業，那可以趁著年輕再多奮斗幾年，如果身體 健康 差了或者是厭倦了這個行業，那就盡早轉行吧，轉測試轉產品等等都是可以的。
累因為積累的東西不足以支撐自己走下去
累因為東西學不動了沒有競爭能力了
累因為覺得這行業給你了對未來的恐懼感
累總是因為你有不敢面對的原因，走出來就好了
最近幾年前端的變化確實很大，不過你剛從業兩年，如果換行業，我覺得一個是看自己興趣方向，另一個就是考慮收入情況！
首先，兩年的前端開發經驗，在前端開發這個領域的收入是你轉到任何一個行業都比不了的！其實還有好多人由於自己工資太低還想去培訓做開發多賺些錢呢[可愛]
其次，就是關於工作累的問題，我覺得任何行業可能都不輕松，而且也不一定可以拿高工資。
最後，我想說的是，目前前端趨勢還算明朗，多花些時間把常用的框架，語言學習扎實 ，然後多積累多總結，後續工作可能效率就會提高，也就沒那麼累了
純屬個人的一些想法與建議，最後還是要自己做打算，只能幫你到這兒啦 [呲牙]
看你是不是還繼續喜歡著前端工作，如果喜歡請繼續。因為現在的前端開發行業很火，現在的用戶在基本操作的前提下越來越注重頁面的美觀和體驗，而這都是靠前端技術人員來完成的，不管後端代碼寫得有多好，演算法用的多麼精通這些用戶通通不管，他們看到的就是眼前的頁面，所以說前端還是很好的。不過前端技術更新太快所以要及時掌握新技術才能不被淘汰。
為啥你們程序員都說換行，我覺得轉行沒那麼容易呀？
前端轉行有什麼路子沒？
轉行，做什麼呢？感覺除了寫代碼，其它都不會啊？？？？
③ 如何進行前端自動化測試
一般前端自動化測試大致包括
類庫單元測試自動化
UI組件測試自動化
類庫單元測試自動化
較好實現
基本思路是讓不同的瀏覽器可以自動根據指令跑一些JS函數
結果與預期比對後返回是否通過case測試標志
其中一般有兩種實現方式：
其一：
1.打開目標瀏覽器，運行測試框架站點
2.測試框架站點通過ajax 輪詢、websocket 等方式，將待測 js 的 case 在瀏覽器內運行（通過eval 、createElement("script") 等方式）
3.比對測試結果，將結果 post 到遠端
4.遠端接受測試結果
5.遠端等待所有瀏覽器返回結果完成
6.marge 所有瀏覽器數據顯示最終通過與否結果。
這種方式弊端：
人工開啟一次所有瀏覽器
需要排隊測試，瀏覽器只能一次運行完一組測試後才能再運行下一組
如果中間某testcase導致瀏覽器異常，返回結果將缺失，需要人工去伺服器上檢查下瀏覽器狀態
好處：
可以覆蓋所有想覆蓋到的瀏覽器
另一種方式：
1.將常用瀏覽器內核放進一個或多個相互有關聯的進程內
2.用例通過系統消息發送到各個包裝的內核中
3.每次開啟一個新內核進程運行JS用例
4.用例結果發送給包裝進程
5.包裝進程匯集所有用例結果後post到遠端保存
6.包裝進程連帶內核進程一起退出
優點：
無序人工開啟一次瀏覽器
獨立進程運行，無需排隊
不怕內核異常，異常後包裝進程可以直接恢復內核或者通知測試失敗
缺點：
前端實現太困難，需要C++開發
無法覆蓋到所有瀏覽器
常用內核覆蓋更新勞心勞力
④ 怎麼加強自動化測試腳本的穩定性
IBM® Rational® Functional Tester 是用於功能性和回歸線測試的高級測試自動化工具，它可以在一個基於圖形化用戶界面（GUI）的程序上錄制測試場景，並回放測試場景以實現測試自動化。在錄制期間，您可以插入確認點，這些確認點可以從您正在測試的程序中獲取特定的數據或者屬性。然後在回放期間，這些確認點用來將錄制的信息，與現場信息進行比較以確保穩定性。工具會搜索映射的對象，並在測試期間對其執行一系列的操作。 但是，由於對象不存在或者不適當的狀態，Playback 特性通常會遇到一些失敗情況，在回放期間，如果 GUI 響應時間或者 GUI 到達預期狀態所花費的時間，要遠遠高於錄制時間，那麼工具所執行的操作就不能在適當的位置找到適當的對象或者它們的狀態或屬性了，這樣腳本回放就會失敗。通過按照本文中所介紹的步驟進行操作，您將會學到怎樣利用 Rational Functional Tester 程序編程界面（API），來改進腳本以實現基於 Eclipse 程序地可靠測試自動化。 前提條件 如果您擁有下述的知識，那麼您就能從本文中學到更多的信息： 熟悉 Eclipse 環境以及為測試下程序配置 Rational Functional Tester 熟悉錄制和回放測試腳本，並理解測試腳本的內容 場景 注意： 對於這些範例，IBM® Rational® Software Architect（一種基於 Eclipse 的程序）用作測試下的程序。 本文將會涉及到測試自動化中以下的失敗場景，並解釋在 Eclipse 工作區中遇到它們時的方案。 場景 1：不匹配的 GUI 響應時間 在回放期間，如果 GUI 響應時間要比錄制期間的時間長，那麼自動化工具將不會找到需要執行操作的對象，而測試腳本也將會失敗。 場景 2：未預期的活動窗口 如果在自動化測試的回放期間，出現了一個未預期的活動窗口，那麼在錄制期間該窗口將不會出現，自動化腳本將會失敗。自動化會因為未處理的窗口而停止。 場景 3：不適當的對象狀態 當您在創建確認點時，如果對象沒有處於它所預期的狀態，那麼它會獲取所有需要的具體內容。同樣，在回放期間，如果並不能確保相同的對象狀態，那麼確認點將會失敗。 圖 1 中的圖表描述了處理這些場景的基本方法。 圖 1. 方案的基本方法 方案方法基本上可以改進使用 Rational Functional Tester API 的腳本。作出的選擇能夠處理描述的場景，該場景可能發生在測試自動化場景之中。 創建 Eclipse：准備 Rational Functional Tester 以測試基於 Eclipse 的程序 為了對基於 Eclipse 的程序使用 Rational Functional Tester 自動化測試特性，您必須首先按照下面的方法來創建測試的環境： 點擊 Configure > Enable environment for testing 以打開 Enable Environments 窗口（參見圖 2）。 選擇 Eclipse 實例，並點擊 Enable。如果 Eclipse 環境尚沒有列出，那您您可以點擊 Search。 點擊 Finish 以保存您所做的修改。 圖 2. 激活環境窗口 修改代碼：根據用例來更改自動生成的代碼 在這一步中，會獲得對自動生成代碼所做的更改，以處理前面所描述的一個或者多個失敗。每一個失敗場景的解決方案，都與下述描述的子部分不同。 場景 1：不匹配的 GUI 響應時間 對於該場景有兩個可能的解決方案： 方案 1a. 檢查進度條的狀態 當您在基於 Eclipse 的程序中創建一個項目時，項目構建和確認會在項目向導完成之後才啟動，其中基於 Eclipse 的程序例如 Rational Software Architect 或者 IBM® Rational® Application Developer。有時所花費的時間要比預期的長，腳本回放會失敗，因為項目構建沒有完成，但是腳本會試著進一步地操作。為了避免這種失敗情況的發生，您可以在 Eclipse 工作區右下角查看進度條的狀態 修改代碼：根據用例來更改自動生成的代碼 在這一步中，會獲得對自動生成代碼所做的更改，以處理前面所描述的一個或者多個失敗。每一個失敗場景的解決方案，都與下述描述的子部分不同。 場景 1：不匹配的 GUI 響應時間 對於該場景有兩個可能的解決方案： 方案 1a. 檢查進度條的狀態 當您在基於 Eclipse 的程序中創建一個項目時，項目構建和確認會在項目向導完成之後才啟動，其中基於 Eclipse 的程序例如 Rational Software Architect 或者 IBM® Rational® Application Developer。有時所花費的時間要比預期的長，腳本回放會失敗，因為項目構建沒有完成，但是腳本會試著進一步地操作。為了避免這種失敗情況的發生，您可以在 Eclipse 工作區右下角查看進度條的狀態
⑤ Web端自動化測試失敗的原因
最初的測試自動化失敗是從不切實際的期望中獲得的。在我的職業生涯中，我已經多次觀察到它，一旦您獲得了自動化的質量保證或工作人員，管理層就期望他們對所有內容進行自動化測試。盡管聽起來很令人愉悅，但這是不可能的。您不能進行100％的自動化測試，因為在少數幾個領域必須進行人工檢查。這些領域之一可能與您的Web應用程序的可訪問性有關。
例如，如果您正在執行自動跨瀏覽器測試，則用於Selenium測試的自動化腳本將在不同的瀏覽器或操作系統上呈現網頁的顯示。但是，要確定網站是否按照設計進行渲染，版式是否合適，文字是否合適，最好手動評估
許多組織確實意識到期望進行100％自動化測試的問題陳述，但通常會遇到以下問題。我們可以實現什麼自動化，如果不是100％，那麼我們可以為Web產品實際實現多少自動化？
沒有適用於每個企業的自動化測試覆蓋率的完美百分比或近似值。這完全取決於您所提供的Web應用程序，並且由於不同的企業正在滿足不同的需求。自然而然地，人們會對圍繞自動化測試實際能實現的自動化測試百分比抱有獨特的期望？自動化測試的范圍將從電子商務Web應用程序到靜態，動態或動畫Web應用程序有所不同。因此，如果您想知道為什麼自動化測試對您的組織失敗？然後，我建議您根據所提供的Web應用程序的類型來評估所需的自動化測試量。
在我作為自動化測試員開始IT生涯時，我就一直是管理不當的受害者。我當時在一家基於Service的公司工作，他們為我分配了我的第一個項目。這個項目已經運行了兩年，當我加入後，我被交給了一系列測試自動化腳本。項目的高層將要離開組織，管理層對即將到來的沖刺太忙了，無法考慮將要離開的高級自動化測試人員進行的全面知識轉移課程。他們離開後發生的景象不佳？我的經理在聽證會的結尾說，我們因停電而大吃一驚，而我剛起步，對各種出站和入站流程如何受到眾多自動化腳本的影響的了解最少。然而， 我見過一些由少數成員負責實現自動化的團隊，而其他成員則對正在發生的事情一無所知。
您是否認為當一半的團隊缺乏可見性時，從自動化測試中獲得魔術效果是不現實的嗎？由於自動化必須是一個協作的工作，因此對每個團隊成員進行相關工具和流程的教育非常重要，尤其是對新手而言。您可以通過舉行團隊會議和會議來討論與自動化有關的工具，趨勢和實踐，從而實現這一目標。
這可能會讓您有些驚訝，測試自動化失敗的另一個原因可能是缺少手動測試技能或 探索 性測試技能。自動化測試腳本並不意味著團隊成員可以減少一些懈怠。到目前為止，我們已經知道，自動化方法不能涵蓋所有內容，而這正是挑戰所在。因為現在您必須更深入地研究Web應用程序，並找到隊友尚未發現的關鍵測試方案。
自動化是節省測試工作的一種方式。軟體公司應該使用它來最大程度地減少重復，並盡量使那些不易更改的元素自動化。一旦完成，公司應該分配他們的資源來執行廣泛的手動測試或 探索 性測試，以找到獨特的測試用例。
自動化似乎是減少工作量的一個目標。但是在開發測試自動化腳本之前，必須考慮周全。此外，這可能會花費大量的自動化測試執行時間。框架和測試自動化工具的靈活性在開發腳本場景所需的時間中起著至關重要的作用。
由於每種情況都不同，因此必須編寫腳本。即使您仔細考慮，如果不編寫腳本腳本，這都是浪費。確保測試工程師的編碼技能與測試的復雜性保持一致。復雜的測試需要大量時間才能實現自動化。因此，隨著全新功能的發展，他們通常沒有機會發現回歸的錯誤。在寫下測試方案之前，請確保牢記這些注意事項。
「 為什麼測試自動化對您的公司失敗？」背後的最常見的原因？」是人們不知道什麼時候應該自動化，什麼時候不知道。例如，可以自動化不同的網頁功能。但是通過測試自動化評估填充，圖像等渲染問題不是一個好主意。如果使用坐標來確定元素位置，則在以不同的屏幕解析度和大小運行時，可能會導致差異。
在測試易於進行大量更改的項目時，使用自動化是不可行的。如果您要測試穩定的實體，那麼自動化是必經之路。基本上，需要重復執行某些操作的普通任務最適合自動化測試。因此，測試自動化可以簡化您的回歸測試過程。
我看到IT行業普遍存在錯誤觀念。人們認為任何開發人員或測試人員都可以執行測試自動化。測試自動化的設計，配置和實施需要特定的技能。執行自動化的測試人員應該知道如何在經理，開發人員和客戶之間闡明想法。他/她還應該對開發趨勢有清晰的了解，並且應該知道開發團隊要去的方向。
自動化測試工程師是最困難但最重要的一些人。為了啟動各種自動化項目，聘請具有廣泛技術知識的測試人員至關重要。整個團隊應該知道發生了什麼，而不是由一個或幾個人進行自動化測試。即使在僱用技術精湛的員工方面投入很高，但回報還是值得的。
由於自動化測試是一個相對較新的現象，因此失敗的可能性很高。測試團隊進行的新實驗太多，因此准確分析結果變得很重要。進行測試後，測試人員必須做出詳盡的測試報告。但是，這就是測試自動化對您而言失敗的原因！您的團隊沒有對測試報告的分析給予足夠的重視。如果執行不當，分析可能會導致無人看管的故障，並浪費時間，資源和精力。
在自動測試中，有些測試成功，有些失敗。因此，必須檢查測試報告是否有故障並分析某些測試失敗的原因。最好手動進行分析，以發現真正的故障。揭露隱藏的問題並確保它們不會被其他問題掩蓋而被忽略是至關重要的。
設置太高而不能成為自動化的真正目標，在紙面上似乎很完美。但是，在執行步驟時，團隊成員之間嚴重缺乏清晰度。最大的問題是目標不明確。他們缺乏從自動化中獲得真正價值的准確性和准確性。大多數公司所做的是，他們開始將非常復雜的事情自動化，並最終重構整個框架。結果，團隊最終會浪費大量時間，金錢和精力。
您可以通過從小處著手並逐步提高復雜性來消除不確定性。選擇穩定的功能，並從其自動化開始。之後，收集反饋以確定出了什麼問題。一旦您的測試達到一致性，就可以繼續使用其他功能。對於不同的項目環境，需求可能會有所不同，因此請使用自定義方法進行測試自動化。
在擁有大量自動化工具的情況下，有時候選擇最佳工具變得充滿挑戰。最終目標是改善整體測試程序並滿足實際要求。但是大多數團隊都無法從頭再來，也沒有挑選出最適合其測試需求的工具。毫無疑問，自動化測試是高度依賴於您決定繼續使用的工具。每個工具都有特定的功能。但是，團隊缺乏充分利用這些功能所需的專業知識水平。
此外，公司陷入了對特定工具的炒作。但是在選擇它之後，他們意識到它並沒有提供他們希望獲得的一切。另外，每個團隊都有預算，有時該工具的成本超出了預算。在繼續選擇操作工具之前，請仔細列出要求。之後，確定您對該工具的期望值。在設定目標時要非常具體，並檢查與產品用戶接受標準的對應關系。您也可以咨詢有使用這些工具經驗的專家。
幾乎每個組織都經常觀察到這一點。一旦自動化測試套件准備就緒並且工作正常，管理就開始放鬆。他們開始放寬對測試執行的深入分析，因為他們認為只有通過/失敗檢查才足夠。但是，這就是測試自動化導致他們失敗的原因！
有時，系統從根本上可以正常運行。但是，自動化腳本不能反映出相同的情況。他們以其他方式陳述並導致假陽性方案。因此，這造成了混亂的局面，浪費了時間，精力和資源。我已經看到測試團隊試圖找到不存在的東西是多麼令人沮喪！
每個Web元素都必須有一個ID才能執行有效的測試。但是有時，開發人員無法將ID分配給所有Web元素，這就是測試自動化失敗的原因。在這種情況下，自動腳本必須查找這些Web元素，這會花費大量時間。此外，如果腳本無法在規定的時間內找到這些元素，則測試將失敗。因此，為了確保腳本的正確同步，團隊必須為所有Web元素分配唯一的ID。
因此，最終使所有想要自動化的東西都自動化了。您最終獲得了龐大的測試套件，直到現在，您才開始碰壁。這些復雜的測試套件執行時間比您預期的要長。這開始與您各自的IDE測試自動化框架中的測試隊列質量相抵觸。結果，由於隊列超時問題，測試用例突然停止，這都是因為您要按順序執行它們。測試用例的順序執行是Web應用程序測試自動化失敗的另一個原因。
與順序運行測試不同，並行執行使您可以在不同的環境中同時執行多個測試。但是自動化測試可能會導致意外的代碼交互。調試失敗的原因非常困難，因此您需要透徹的報告機制，提供有關測試執行的詳細見解。
無論您在線經營什麼業務，ROI都將成為每次董事會會議的議程。股東要求更高的回報。而且，無論您准備測試自動化套件花費了多少時間和精力，如果它們產生的ROI均達不到預期，那麼它們的重要性將比您預期的要輕得多。
在計算測試自動化的投資回報率時，可能需要考慮許多指標，例如測試維護，購買必要的測試自動化工具所涉及的成本，板載資源等等。計劃不切實際的ROI對於許多組織而言可能是成問題的，並且可能是測試自動化失敗的原因。
許多組織給人以自動化測試容易的印象。您所需要做的只是編寫幾行代碼以自動化您的Web應用程序的測試工作流程。就是這樣！您完全不必擔心測試自動化腳本的計劃和輸入。但這不是！
您需要評估波紋效應。您的Web應用程序將包含許多旨在測試不同模塊和流程的測試自動化腳本。如果一個測試腳本無法正確執行，則其他腳本也可能觸發測試自動化失敗。不僅如此，在計劃資源時還應該計算出連鎖反應。
假設您有一個高級資源，他曾經寫過腳本，現在已經離開了公司。您可能沒有想到辭職可能會在自動化項目的未來時間表中產生連鎖反應。這就是為什麼需要記錄有關系統中每個自動化測試腳本的每個細節的原因。該文檔應作為萌芽的自動化測試人員以及經驗豐富的自動化測試人員的標准。
測試自動化對您的組織失敗的另一個原因可能是不合適的測試套件。許多自動化測試人員會創建靜態測試套件，這些套件在您擴展業務時並不那麼靈活。每當平台發展時，它們最終都會重新編寫整個自動化測試腳本。這是一個壞習慣，因為您在浪費時間，資源和金錢。另外，這也是一個錯誤的過程。確保您編寫隨平台擴展而發展和適應的測試套件。
避免測試自動化失敗的另一種方法是即興測試套件。現在，這聽起來似乎很明顯，但是在許多組織中卻沒有實踐。原因是，一旦他們設計了測試套件，並發現它可以正常工作，便開始著手自動化新領域。我沒有批評沉迷或 探索 新領域以實現自動化的努力。但是，管理一個時間窗口並讓您和您的團隊回顧現有的代碼段，以找出進一步優化它的方法並沒有什麼壞處。始終嘗試使用您的測試套件，以使事情變得更好。
隨著敏捷軟體，看板軟體等現代SDLC（軟體開發生命周期）方法在全球范圍內的採用，協作已成為將Web應用程序更快部署到市場中的關鍵組成部分。
這是一個多維軟體開發過程，所有團隊都在同時開發Web應用程序。您有一組開發人員設計前端，另一個負責後端，還有一個負責中間件活動的團隊。作為測試人員，您需要了解哪個團隊負責哪個模塊。您必須及時了解不同團隊所做的產品增強功能，並對自動化腳本進行相關更改，以確保測試自動化不會失敗。
自動化測試的主要目的是最大程度地減少重復手動測試所涉及的壓力，以節省時間。從抽象的角度看，這聽起來不錯，但對於那些執行測試自動化的人來說，要意識到為執行內部測試自動化而配置正確的基礎結構的艱辛。我經常觀察到測試人員在執行新腳本之前會刷新整個測試自動化套件，以避免與腳本產生任何歧義。但這不能使自動化測試的整個過程都失敗，不是嗎？
例如，如果您正在使用內部Selenium Grid執行自動跨瀏覽器測試，以測試適用於Google Chrome和Safari瀏覽器的macOS和Windows操作系統的網站。現在，您可能每次都要運行Selenium腳本之前就不得不面對設置新操作系統的麻煩。
這是組織自動化測試失敗得非常普遍的原因。特別是在臨近最後期限時。您的測試部門將繼續在同一測試環境上運行大量測試套件，而不會清除先前執行的測試自動化腳本的緩存。這可能會導致錯誤的測試評估，當您遇到更多的假陰性和假陽性時，您的測試報告可能會受到影響。
例如，假設您需要針對不同的地理位置測試您的Web應用程序。在靜態測試環境中執行地理位置定位時。您的腳本可能會遭到Google的測試，要求您證明自己不是機器人。這將導致測試自動化腳本失敗。
這就是需要使用清除的緩存的新虛擬機的原因，因此您可以獲得自動化跨瀏覽器測試腳本的准確結果。
為了使自動化能夠在不同的測試環境中工作，需要進行大量的計劃。您需要在暫存環境上進行測試，以確保將代碼移入生產管道時，它們可以完美地工作。但是，經常會發生這樣的情況：在舞台環境中進行測試時，用於代碼更改的測試自動化腳本可以無縫運行，但是當移至生產環境時，它就會崩潰。此類問題背後可能有許多原因，例如缺乏持續的監控，登台環境無法使生產環境成對增長，缺少實時流量等等。
但並非最不重要的。如果到目前為止我們已經講完所有要點，並且您的測試自動化仍然失敗，那麼您唯一需要反思的地方就是您自己的測試自動化腳本。確保您沒有為整個項目中涉及的任何測試腳本提交任何編譯時以及運行時錯誤。
如果您的組織需要提高生產力，那麼自動化測試就是必經之路。這是提高產品質量所需的最有效的過程之一。測試自動化還提高了軟體的健壯性。但是要謹慎執行和拖延。您不能在沒有障礙的情況下匆匆忙忙，因為沒有一家公司可以承受損失巨額資金的麻煩。另一方面，過多的恐懼會阻止您獲得自動化測試所提供的顯著優勢。
感謝每一個認真閱讀我文章的人！！！
如果下面這些資料用得到的話可以直接拿走：
1、自學開發或者測試必備的完整項目源碼與環境
2、測試工作中所有模板（測試計劃、測試用例、測試報告等）
3、軟體測試經典面試題
4、Python/Java自動化測試實戰.pdf
5、Jmeter/postman介面測試全套視頻獲取
我個人整理了我這幾年軟體測試生涯整理的一些技術資料，包含：電子書，簡歷模塊，各種工作模板，面試寶典，自學項目等。需要的可以私我謝謝
⑥ 前端自動化測試框架Jest 基礎入門-
一、引言
前端這幾年發展的非常迅速，我們的系統的功能正在變的越來越復雜，這對我們的前端工程化能力提出了更高的要求，聽到工程化，大家的第一反應肯定是高質量的代碼設計和高質量的代碼實現。
但實際上，前端 自動化測試 也是前端工程化裡面非常重要的一個環節。
二、 Jest 基礎入門
一個普通前端聽到自動化測試，第一反應可能是：我工作這么多年也沒寫過測試，這個東西有用嗎？
答：非常有用
如果你打開GitHub，去看一下流行的開源庫或者框架的源碼，你會發現，在這些源碼裡面，全部都包含了大量的自動化測試的代碼。比如antd、lodash、再比如vue、react、echarts、rex等等……
開源的工具需要穩定性，而引入前端自動化測試為開源項目提供穩定性，是再好不過的選擇了。
三、學習前提
閱讀這篇 文章 需要以下知識儲備：
·js、es6 基礎語法
·node、npm 相關知識
·git 的相關操作
·react或者vue，至少了解一個
·狀態管理工具，至少了解一個
四、背景及原理
首先在任意目錄下創建一個math.js文件，假設這個文件是一個數學庫，裡面定義兩個函數，分別是加法和減法：
// math.js
function add(a, b) {
return a + b;
}
function minus(a, b) {
return a - b;
}
這時候我們可以在業務代碼里去使用這個數學庫。
但是，假如，上面的minus函數我們不小心寫錯了，把減法寫成了乘法，如果直接在業務代碼中使用這個方法，就會帶來無法預期的bug。
所以這時候，我們就需要對math.js這個公共庫進行自動化測試，確保沒問題之後，再讓業務組件去調用，這樣就會保證不會出特別多的bug了。
我們可以這樣做：
在該目錄下創建一個math.test.js文件，然後寫一點測試代碼：
const result = add(3, 7);
const expect = 10;
if (result !== expect) {
throw new Error(`3 + 7 應該等於${expect}，結果卻是${result}`);
}
const result = minus(3, 3);
const expect = 0;
if (result !== expect) {
throw new Error(`3 - 3 應該等於${expect}，結果卻是${result}`);
}
這時候我們運行這段代碼，會發現沒有拋出任何異常，說明這兩個 測試用例 都通過了。
這就是自動化測試最原始的雛形。
然後我們思考一個問題，如何將這堆代碼進行簡化，做成一個公用的函數，比如這樣：
// 測試 3 + 3 是否等於 6
expect(add(3, 3)).toBe(6);
// 測試 3 - 3 是否等於 0
expect(minus(3, 3)).toBe(0);
expect 方法實現：
function expect(result) {
return {
toBe(actual) {
if (result !== actual) {
throw new Error("預期值和實際值不相等");
}
},
};
}
這時候我們運行這段代碼，會發現沒有拋出任何異常，說明這兩個測試用例都通過了。
雖然實現了 expect 函數，但是報錯的內容始終是一樣的，我們不知道是具體哪個方法出現了問題，這時候我們就會想到，我們需要將這個 expect 方法進一步做改良，我們如果能在 expect 方法外部再包裝一層，就可以多傳遞一些額外的內容，比如創造這樣的寫法：
test("測試加法 3 + 3", () => {
expect(add(3, 3)).toBe(6);
});
test("測試減法 3 - 3", () => {
expect(minus(3, 3)).toBe(0);
});
這樣封裝之後，我們既能進行測試，又能得到測試的描述。
test 方法實現：
function test(desc, fn) {
try {
fn();
console.log(`${desc} 通過測試`);
} catch {
console.log(`${desc} 沒有通過測試`);
}
}
所以前端自動化測試到底是什麼？
答：實際上就是寫了一段其它的用來測試的js代碼，通過測試代碼去運行業務代碼，判斷實際結果是否滿足預期結果，如果滿足，就是沒有問題，如果不滿足，就是有問題。
上面實現的 expect 方法 和 test 方法 實際上和主流的前端自動化測試框架 jest 裡面的語法是完全一致的。所以上面的示例代碼可以理解為 jest 的底層實現原理。
⑦ 如何有效的開展自動化測試
自動化測試不宜大力投入
不管是自動化測試還是介面測試，都不宜在前期大量投入。當前業務是否適用自動化，哪些框架或者工具更適合，適合做介面自動化還是 UI 的自動化？如何讓自動化達到收益和效果？
這些問題都需要根據團隊和業務具體的情況去嘗試，找到合適的才行。如果前期投入太大，團隊對其期望太高，非常容易在遇到一點挫折的時候對自動化喪失信心。
另外，投入太大，畢竟加大人力或者減少手工測試的投入，會造成測試資源的緊張。在項目時間和成本的壓力下，測試管理者需要頂著巨大的壓力，這本身就很難成功。
可以安排一些技術強或者技術興趣濃厚的成員，在項目允許的情況下減少其手工測試工作量，讓其可以利用部分工作時間和部分業余時間嘗試做自動化，先局部功能嘗試，能夠有效果，在擴大范圍。逐步達到一定的自動化規模。
以介面為主UI為輔
UI 自動化因其運行環境的問題，會導致運行速度慢，對環境依賴過高。同時因程序界面的多變性，導致自動化腳本維護成本大大增加。
介面測試有很多優於 UI 自動化的地方。但是介面測試也自有其短板，對流程性質的測試並不適合用介面自動化來覆蓋。介面自動化更適合覆蓋單一介面功能的檢查。
所以我們可以採用核心業務流程使用 UI 自動化，單一功能使用介面自動化，兩種層面的自動化結合的方式來進行。
不輕談自動化測試平台
目前測試界開始流行起自己開發測試平台（以介面為主）。簡單來說就是模仿常見的介面測試工具，用 Python 或者 Java 寫成了一個 web 版本的。
當然也有其理由，「定製性更強！」但是畢竟是軟體都需要進行測試，花大量精力開發的平台並不穩定，而本身功能和理念上並沒有太多更新。而這樣的一些功能，市面上的絕大部分測試工具都能勝任。
如果是為了提高個人能力，項目時間有空餘，怎麼玩都可以。若是要在實際工作中應用，那麼就有點得不償失了。
自動化測試中，工具的重要性始終是最低的。理念、思維和環境治理才是最重要的。
通過不斷小范圍試錯，找到適合自己團隊的自動化策略才是最重要的。任何技術脫離實際應用都是耍流氓。
⑧ 誰知道做軟體測試好還是做開發好
從工資上講是軟體開發：
軟體開發是要看資歷的。一般初級工程師，也就剛入門，基本能力過關，沒經驗的人工資大概4k到8k，隨時間的累積工資也會上漲。工具工作年限5年以上，有豐富的團隊開發經驗，有一定的大型系統框架設計經驗，工資大概會在30k到50k左右。
軟體測試剛入行的軟體測試人員，起步月薪大多才5000-7000元左右。高於同齡人1000-2000元的薪資水平，工作2-3年後月薪在9000-12000元左右，3年以後基本就在10k到20k左右。
從技術上講是軟體測試：
開發又要前端和都端，現在還有一個終端，這些開發基本要熟悉Java，H5，資料庫等語言，作為一個公司的開發要想拿高工資技術肯定要到位。如今大量的人投入IT行業可為什麼還是大量缺人，那是很少的人技術達到高端水平，可想技術的難度有多大。
測試是進入IT的一個低門檻職業，需要你掌握的內容不要求精,但是要求廣。文案編寫是最基本的還需要熟悉一下編程語言比如腳本。然後了解你自己所需要的工具，關於計算機的配置信息。相比於開發肯定是簡單了不少。
職業規劃上講,肯定是軟體測試：
開發是非常傷腦的職業，相信如果仔細的人會發現IT行業禿頭的人多、年輕人多。第一點就是做開發費腦頭發容易掉，很傷身體，所以一般40歲左右就是開發的結束年齡。第二點一個IT公司需要新鮮血液，沒有新的idea，公司就會面臨淘汰，所以年輕人較多。
軟體測試門檻低、技術要點少，基本就是固定的結構和方法，所以對於資歷越老對公司的效益越高。
⑨ 前後端自動化測試方案
這段時間我探索了點自動化測試方面的技術，探索結果如下
【後端】：任意後端工程 + python 自動化測試腳本（實現介面測試），伺服器要求：指令伺服器即可（即終端操作系統）
【前端】：任意前端工程 + python 自動化測試腳本（實現UI交互測試），伺服器要求：必須是可視化伺服器（即有交互界面的系統） （雖然說 phantomjs 可以實現無界面的情況下進行瀏覽器測試，但是還是不太推薦，畢竟對於前端而言，可視化才最好）
經過探索下來，發現 python 在實現自動化方案確實非常合適，且前後端都可以通過python實現自動化測試，如此一來自動化測試也就可以獨立出一個工程，而無需受前後端工程語種、框架等各種不同的影響。只是前端自動化測試比較特殊，需要模擬用戶交互，最好是有界面的系統（通過瀏覽器驅動器調用瀏覽器實現自動化交互測試），也就是說前後端的自動化測試伺服器要麼都用一台帶交互界面的系統，要麼就用2台伺服器，一台終端伺服器測後台介面，一台交互伺服器測前端交互