你們如何實現前端專案的自動化測試？

1樓：

GUI自動化也分桌面軟體和web端的。

Web端自動化測試，看前台開發用啥的。

1.Angular JS的，用protractor測試。

2.其餘的，直接C# codedUI，乙個類乙個類的抓child，這個必須要了解頁面結構，而且前期封裝好功能，搭框架的步驟很關鍵，實現case並不難。

3.直接截圖，對比。這個簡單粗暴。寫個截圖對比的演算法實現就成了，不侷限工具。

其他啟動瀏覽器啥的，怎麼調能啟動就怎麼調。其實windows下邊都是個WebDriver.exe。能調起來就行。

桌面的用UI Automation，就是微軟的accessibility工具包，也是找id的套路。

2樓：王仕軍

測試尤其是自動化測試在現代 WEB 工程中有著非常重要的角色，與交付過程整合良好的自動化測試流程可以在新版發布時幫你快速回歸產品功能，也可以充當產品文件。

測試因粒度不同又可以分為單元測試、介面測試、功能測試。

3樓：胖子碼農

單純從gui自動化的角度談，gui自動化最大的問題就是gui頁面變化太快太多，導致自動化case指令碼後期維護成本太高。

解決辦法有兩種：

一，快速重寫錯誤case。現在有很多自動化工具，可以提供錄製功能，而且是基於元素標籤的錄製，不是基於螢幕座標，準確率90%以上。錯誤的case，重新錄製一遍，比修改的成本低多了

二，自動化框架，實現操作流程、測試資料、頁面定位元素的分離。

頁面變化，最多的是頁面元素定位的改變。可以將乙個頁面需要用的元素和其定位的資料寫在乙個xml中，取個別名，呼叫時就用別名。這樣就隔離了變化，元素變化就只修改這個檔案即可

操作流程變化。操作流程，其實就是各個元素的操作。操作流程，裡面元素用別名。

每一型別的元素操作，封裝成統一的介面，例如button.click等。這樣操作流程也比較簡單，而且也不會影響其他

測試資料也單獨拎出來，通過變數的方式引用。

總之，自動化最大的問題就是後期維護問題，那麼我們最大的問題就是怎麼把變化隔離出來，以最小的成本來應對這些變化

4樓：Bugtags

首先，想從事自動化測試，必須先了解What/Why/How，也就是常說的去了解什麼是自動化測試、為什麼要進行自動化測試、該如何進行自動化測試，這類的資料在網上有很多，這裡就不做重複了；其次，需要根據專案的特點，選擇合適的自動化測試工具

5樓：城下秋草

GUI覆蓋最基本的主流程保證功能即可。 QTP、selenium

如果就是做前端的，用偏單元測試的方式驗證吧。phantomJS

6樓：凝曉峰

8年UI端，5家公司做下來，我覺得UI自動化測試就是個超級大坑。從來沒看到過這方面真正做的好的專案。要我是老闆寧可花幾千招個認真負責的實習生滑鼠認真一路點下去，也比什麼GUI自動化測試靠譜多了.....

7樓：Jim Liu

GUI自動測試，目前用的是nightwatch，配合4~5臺windows機器（虛擬機器亦可），每個機器上起乙個版本IE的selenium服務，nightwatch可以一次性在多個服務上執行用例。

當然，不管用什麼方案，技術方案在整個自動化測試裡佔的比重都是很小的，我見過挺多做自動化測試的同事，似乎都走進乙個怪圈，技術方案很屌，但是測試效果並不是很好。

我覺得自動化測試難還是難在編寫指令碼，因為這玩意兒跟業務關係太緊密，尼瑪天天改，於是經常改的地方根本沒有人敢去寫case。那就對了，頻繁改的東西最該測，但是沒的測，那要之何用？

然後自動化測試漸漸就用來做准入測試，jenkins觸發，case都是一些fatal級的，這個強度的測試很難通不過（當然也有的RD沒有條件測試各種IE導致fail的），乙個不會fail的測試，要之何用？

8樓：姚垚

ui測試分兩塊，第一是基於selenium之類的做ui自動化測試，這些測試一般對頁面排班命名有依賴，需要寫相應的測試鉤子類名，完事錄製指令碼就好。第二是雲龍做的截圖對比畫素差，基於phantomjs寫了乙個類似的。

介面測試用phpunit做了介面比對的自動化測試，大概就是curl遠端介面帶著特定的引數狀態等等，看輸入輸出結果合法性一致性和資料結構。

其實還可以用phantomjs比對DOM，不過和截圖邏輯一樣，沒啥寫的意義了~

效能測試涉及不多，只用過ab做測試。

貌似只有前端的單測沒做…主要因為懶…