『壹』 本人女，准研三，就業的話自動化測試和前端開發哪個更
研三。。
建議自動化測試，生娃後還可以繼續做或是轉產品運營好轉一些。
大公司的前端和自動化測試剛開始工資待遇是一樣的，但是前端開發的技術更新太快，生孩子或是歲數再大點後，一般女生都會考慮轉方向。
本人也是研三女畢業從事IT大企業前端n年，前端相比測試和服務端前期漲幅很大，後期很難上去，所以各有優劣，看你怎麼選了。
『貳』 web前端的自動化測試工具都有哪些啊
工具太多了，推薦幾個
Selenium
HP QuickTest Professional
WATIR
WATIN
還有其他的供選
Rational robot
SilkTest
TestComplete
TestPartner
『叄』 如何進行前端自動化測試
沒人邀請，路過回答。
前端測試是前端工程方面的重要分支，有過一些探索，這里簡單分享一下。
首先，還是要強調一點：
前端是一種特殊的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的展現問題已經是不小的進步了。
『肆』 自動化測試框架怎麼集成到web前端
有QTP，有selenium,尤其是selenium，結合Python的unittest，可以部署自己前端自動化測試方案了。
『伍』 前端是vue框架如何用python+selenium做自動化測試
你好，下面是一個簡單的python+selenium的例子：
from selenium import webdriver
import time
driver = webdriver.Chrome()
driver.get("http://www..com")
print(driver.title)
driver.find_element_by_id("kw").send_keys("selenium")
driver.find_element_by_id("su").click()
time.sleep(3)
driver.close()
webdriver.Chrome()：創建一個Chrome瀏覽器的webdriver實例
driver.get(「http://www..com「)：打開」http://www..com「頁面
driver.find_element_by_id(「kw」).send_keys(「selenium」)：找到id為「kw」的元素，在這個頁面上為網路首頁的搜索框，在其中輸入「selenium」
driver.find_element_by_id(「su」).click()：找到id為「su」的元素並點擊，在這個頁面上為網路首頁的「網路一下」按鈕
driver.close()：退出瀏覽器
『陸』 最好的web前端自動化測試框架是哪個為什麼
測試框架大同小異，主體思路大致都是「控制項-頁面-測試用例」三個層面。
當前主流的「控制項-頁面-測試用例」框架。
『柒』 使用Sypress前端自動化測試組件怎麼獲取一個標簽裡面的text文本，並且存放在變數中。
首先，我個人認為無論前端後端，只要是用代碼寫的，都需要進行自動化測試，測試的全不全我們暫且不說，測試需要伴隨整個的開發過程，不能全部將發現問題的時間堆到測試部門介入後，這樣一來產品發測的風險會很大，有可能會被打回來，嚴重影響產品發布。二來，就像我像前面提到的那樣，可能發測前各種問題會蜂擁而至，造成自己天天加班，熬夜多了，你懂的。自動化測試可以幫我們提前暴露問題，節約我們手動跑測試用例的時間。
其次，目前市面上前端自動化測試的方案已經比較成熟了，我們前面提到的那些問題，大部分是可以得到較好解決的，社區裡面前端達人們分享了許多關於前端自動化測試的經驗。所以在前端自動化測試，在技術上是沒有問題的，所以我們需要大膽的去嘗試。
再者，這是前端發展的趨勢，我們可以打開目前開源的熱門框架，Vue,React，UI組件庫iview，element-ui，以及常用的npm包的源代碼看看，他們的目錄結構裡面絕對都含有自動化測試腳本，可見前端自動化測試不僅僅是花錢秀腿。歷史的車輪是滾滾向前的，誰都停不下來，身為前端的我們也不能再是一個切圖仔，頁面小王子了。互聯網技術的發展，用戶對於產品的更高要求，產品的快速迭代，這些都要求我們前端開發人員需要具備更高的開發效率，而自動化測試貌似是我們加班之外最好的一個選擇了。
『捌』 自動化測試和前端哪個好學
前端比較好學一點，前端相對來說適合零基礎的人學習，比較好掌握一些。