1. web自動化測試環境如何搭建
web自動化測試環境搭建主要包含如下幾點:
1. Python 開發環境
2. 安裝selenium包
3. 安裝瀏覽器
4. 安裝瀏覽器驅動 -- 保證能夠用程序驅動瀏覽器，實現自動化測試.
如果想學習更多的內容,一個朋友在傳智播客學習軟體測試.現在月薪12K。
2. 公司如何開展web自動化測試的
1簡單介紹項目開展自動化的原因(項目周期長,版本需要回歸測試迭代,需求變動不頻繁)
2介紹自動化測試框架情況(企業做自動化一般都是有框架的如unittest+selenium框架結合po模式進行封裝的自動化測試框架)
3確定框架後會與持續集成配合使用,如常用Jenkins配置項目進行自動化測試任務的流水線執行,如配置每天晚上5點運行測試腳本或者每周運行更新維護後的測試腳本
4.我們知道自動化測試不能覆蓋所有功能的,所以腳本通常根據功能的覆蓋度設計smoke(冒煙)和sanity(可用性)自動化測試腳本產出測試報告
5.自動化測試輔助手工測試進行的日常測試工作
如果想這塊內容增強的小夥伴參考網上的相關知識(黑馬程序員論壇等)
3. 自動化測試的過程
自動化測試 與軟體開發過程從本質上來講是一樣的，無非是利用自動化測試工具（相當於軟體開發工具），經過對測試需求的分析（軟體過程中的需求分析），設計出自動化測試用例（軟體過程中的需求規格），從而搭建自動化測試的框架（軟體過程中的概要設計），設計與編寫自動化腳本（詳細設計與編碼），測試腳本的正確性，從而完成該套測試腳本（即主要功能為測試的應用軟體）。
1) 自動化測試需求分析。
當測試項目滿足了自動化的前提條件，並確定在該項目中需要使用自動化測試時，我們便開始進行自動化測試需求分析。此過程需要確定自動化測試的范圍以及相應的測試用例、測試數據，並形成詳細的文檔，以便於自動化測試框架的建立。
2)自動化測試框架的搭建。
所謂自動化測試框架便是像軟體架構一般，定義了在使用該套腳本時需要調用哪些文件、結構，調用的過程，以及文件結構如何劃分。
而根據自動化測試用例，我們很容易能夠定位出自動化測試框架的典型要素：
a. 公用的對象。
不同的測試用例會有一些相同的對象被重復使用，比如窗口、按鈕、頁面等。這些公用的對象可被抽取出來，在編寫腳本時隨時調用。當這些對象的屬性因為需求的變更而改變時，只需要修改該對象屬性即可，而無需修改所有相關的測試腳本。
b. 公用的環境。
各測試用例也會用到相同的測試環境，將該測試環境獨立封裝，在各個測試用例中靈活調用，也能增強腳本的可維護性。
c. 公用的方法。
當測試工具沒有需要的方法時，而該方法又會被經常使用，我們便需要自己編寫該方法，以方便腳本的調用。
d. 測試數據。
也許一個測試用例需要執行很多個測試數據，我們便可將測試數據放在一個獨立的文件中，由測試腳本執行到該用例時讀取數據文件，從而達到數據覆蓋的目的。
在該框架中需要將這些典型要素考慮進去，在測試用例中抽取出公用的元素放入已定義的文件，設定好調用的過程。
4. 自動化測試基本流程是什麼
自動化測試基本流程
1、制定測試計劃
在展開自動化測試之前，最好做個測試計劃，明確測試對象、測試目的、測試的項目內容、測試的方法、測試的進度要求，並確保測試所需的人力、硬體、數據等資源都准備充分。制定好測試計劃後，下發給用例設計者。
2、分析測試需求
用例設計者根據測試計劃和需求說明書，分析測試需求，設計測試需求樹，以便用例設計時能夠覆蓋所有的需求點。一般來講，基於Web功能測試需要覆蓋一下幾個方面：
1）頁面鏈接測試，確保各個鏈接正常；
2）頁面控制項測試，確保各個控制項可靠；
3）頁面功能測試，確保各項操作正常；
4）數據處理測試，確保數據顯示准確、處理精確可靠；
5）模塊業務邏輯測試，確保各個業務流程暢通。
3、設計測試用例
通過分析測試需求，設計出能夠覆蓋所有需求點的測試用例，形成專門的測試用例文檔。由於不是所有的測試用例都能用自動化來執行，所以需要將能夠執行自動化測試的用例匯總成自動化測試用例。必要時，要將登陸系統的用戶、密碼、產品、客戶等參數信息獨立出來形成測試數據，便於腳本開發。
4、搭建測試環境
自動化測試人員在用例設計工作開展的同時即可著手搭建測試環境。因為自動化測試的腳本編寫需要錄制頁面控制項，添加對象。測試環境的搭建，包括被測系統的部署、測試硬體的調用、測試工具的安裝和設置、網路環境的布置等。
5、編寫測試腳本
根據自動化測試用例和問題的難易程度，採取適當的腳本開發方法編寫測試較薄。一般先通過錄制的方式獲取測試所需要的頁面控制項，然後再用結構化語句控制腳本的執行，插入檢查點和異常判定反饋語句，將公共普遍的功能獨立成共享腳本，必要時對數據驚醒參數化。當然還可以用其他高級功能編輯腳本。腳本編寫好了之後，需要反復執行，不斷調試，知道運行正常為止。腳本的編寫和命名要符合管理規范，以便統一管理和維護。
6、分析測試結果、記錄測試問題
應該及時分析自動化測試結果，建議測試人員每天抽出一定時間，對自動化測試結果進行分析，以便盡早地發現缺陷。如果採用開源自動化測試工具，建議對其進行二次開發，以便與測試部門選定的缺陷管理工具緊密結合。理想情況下，自動化測試案例運行失敗後，自動化測試平台就會自動上報一個缺陷。測試人員只需每天抽出一地你該時間，確認這些自動上報的缺陷，是否是真實的系統缺陷。如果是系統缺陷就提交開發人員修復，如果不是系統缺陷，就檢查自動化測試腳本或者測試環境。
7、跟蹤測試BUG
測試記錄的BUG要記錄到缺陷管理工具中去，以便定期跟蹤處理。開發人員修復後，需要對此問題執行回歸測試，就是重復執行一次該問題對應的較薄，執行通過則關閉，否則繼續修改。如果問題的修改方案與客戶達成一致，但與原來的需求有所偏離，那麼在回歸測試前，還需要對腳本進行必要的修改和調試。
8、自動化腳本的維護
如果系統發生變更時，對自動化測試腳本和相關文檔包括《自動化測試用例》、《自動化腳本設計說明書》進行維護，以適應變更後的系統。
5. Web開發團隊開發，測試，上線的環境和流程是怎樣的
總結一下：
1，你需要一個可以模擬線上的開發環境。
2，你需要一個可以模擬線上的測試環境。
3，你需要一個可連調的測試環境。
4，你需要一個自動化的上線系統。
5，一個開發流程適合前後端的。
1，本地反向代理線上真實環境開發即可。（apache，nginx，nodejs均可實現）
2，模擬線上的測試環境，其實就是你需要一台有真實數據的測試機么，我建議沒條件搭daily的，就直接用線上數據測好了，只不過程序部分走你們的測試環境而已，有條件搭daily當然最好咯。
3，可連調的測試環境，分為2種。一種是你們開發測試都在一個區域網段，直接綁hosts就完了，不在一個網段，就一人給一台虛擬的測試機，放在大家都可以訪問到的公司內網，代碼直接往上布即可。
4，自動化的上線系統，如果你們運維不給你們做，我猜你們都是直接ftp往線上扔？那麼你可以自己做一個簡易的上線系統。原理不復雜，每次上線時都抽取最新的trunk或master，做一個tag，再打一個時間戳的標記，然後分發到cdn就行了。界面里就2個功能，打tag，回滾到某tag，部署【夠簡易了吧，而且是全自動的】。
5，開發流程就是看項目了還有所用到的工具，構建，框架了。簡單來說，原則就是分散獨立開發，互相不幹擾，連調時有hosts可綁即可。
回答了你的問題之後，我說下我自己的項目是怎麼個開發流程。
灰常簡單，代碼管理工具是svn，起新需求就起新分支，獨立開發，開發完合並到trunk，trunk不做任何開發工作，只負責merge。
上線有上線系統，你可以理解為我上面說的那個簡易功能的加強版。我們是自帶build的功能的。
自己編寫build腳本，ant，grunt隨便了。做好連到發布系統，一鍵集成，本地只關心源碼開發。
本地環境，我拿nodejs寫了一個自帶rewrite，反向代理的server，超級模擬線上，一個hosts組管理的工具，一套適合自己部門的grunt插件庫【就是很多很多grunt插件。。】。完全適合開發各種獨立項目了。
當然如果你的測試，文檔都集成在build那一步，是最棒的了。
協同合作我們是每個人開發都有一台自己的測試機，linux的，我本地也有工具可以完成自動build+push的功能。方便快捷。
可能全看下來挺復雜，不過前端工程化確實就是這個樣子。幫你脫離之前的手忙腳亂，專注於業務的開發
6. 如何學習Web自動化測試
如果想系統的學習web自動化測試，可以參考一下步驟學習：
1.先學習手工測試和HTML相關的知識。
2.了解主流的web自動化測試框架，選擇一個比較流行的框架，比如：Selenium。
3.重點學習web自動化測試框架Selenium的API。
4.可以學習一下單元測試框架來管理測試用例。
5.最後可以學習一下PO模式和數據驅動等高級技術，來更好的封裝維護腳本。
黑馬程序員的測試課程里講解的非常詳細，可以學習一下。
7. web自動化測試計劃和步驟
測試用例：前置、步驟、斷言
項目周期長：功能會越來越復雜
歷史功能：比較穩定
回歸，歷史功能
開發-介面自動化同步
項目-8大模塊-2000左右用例數
1、熟悉業務
需求文檔/手動測試/產品聊，了解模塊之間的關系/測試人員
項目目前在測試的階段，棘手的問題
2、分析
系統當中哪些模塊適合自動化、哪些模塊不適合
歷史功能穩定性、功能復雜性
核心模塊
使用頻率模塊，哪一個模塊bug率目前偏高
測試團隊、產品 開會討論
篩選2個模塊 400個功能測試用例
如果是介面 ---介面有多少個，每個介面有多少個用例
3、功能測試 ---篩選自動化測試用例----核心功能、主流程、主功能點---140
用例評審===
4、自動化計劃
自動化類型：web/介面
框架選型：
團隊人員：
搭框架、定規范
時間規劃：用例編寫時間2個半月
效果：覆蓋率是多少---用例通過率---跟項目測試進度結合
8. Web自動化測試入門
讓程序代替人工去驗證系統功能的過程
回歸測試：項目在發新版本之後對項目之前的功能進行驗證
壓力測試：可以理解多用戶同時去操作軟體，統計軟體伺服器處理多用戶請求的能力
兼容性測試：不同瀏覽器（IE、Firefox、Chrome）等
優點
誤區
自動化測試分類
概念：讓程序代替人工自動驗證Web項目功能的過程
1.需求變動不頻繁
2.項目周期長
3.項目需要回歸測試
功能測試完畢(手工測試)
Selenium是一個用於Web應用程序的自動化測試工具；中文的意思（硒）
基於Python環境搭建
PIP工具
9. Web自動化的流程
web自動化流程
一. 了解需求，什麼是系統的核心業務
二. 編寫測試用例：用例名稱，前置條件，測試數據，測試步驟，期望結果
三. 自動化代碼的初步構建：所有的元素定位、元素操作、測試用例都寫在一個模塊中
問題：
1. 層次混亂，一旦頁面元素調整，需要挨個尋找對應的測試模塊，測試類，測試用例函數，不便於後期維護
2. 不便於代碼的復用
四. 引入PO模式，進行分層設計：實現測試用例和頁面對象分離
好處：
1. 層次清晰，相互獨立，易維護
2. 頁面對象可以多次調用，提高了代碼的復用度
五. 引入單元測試框架unittest
六. 優化分層設計
將每個頁面公共的屬性和方法提取出來，封裝成一個BasePage模塊下的BasePage類，後期各個頁面只需要繼承它，就可以獲得父類的所有屬性和方法，這樣不僅簡化了代碼，而且提高了復用度
七. 引入pytest：基於unittest，比unittest更"智能"
好處：
1. 可以通過打標記來運行特定的測試用例
2. 利用contest.py定義公共的fixture，多個測試類中都可以調用，不需要每個測試用例類都定義一遍環境准備和環境清理，簡化了代碼
3. pytest可以按一定規則自動發現測試用例，而unittest則需要向指定的測試套件中添加測試用例
4. 利用pytest-html庫，可以生成自帶的html報告和xml文件，而xml文件的好處是方便跟其它平台的集成和展示，方便做二次開發
八. 注意點
1. 做自動化前，要有獨立的賬號，避免外界環境的干擾
2. 頁面順序完全是由業務邏輯來決定，由測試用例來決定。因此在封裝頁面時不用考慮誰來調用它，不用考慮哪一個頁面操作之後再來使用它(或者哪一個功能操作之後再來使用它)，應該考慮的是無論前面做了什麼樣的操作，誰來用它，任何一個步驟來調用它的時候，它都能正常的操作(這也是為什麼一些頁面的元素需要滾動操作)
3. 在封裝功能時不要考慮在用例中是什麼意思，只需要考慮在本頁面是什麼功能(比如：標詳情頁面獲取余額功能的封裝，不需要把函數命名為get_user_left_money_before_invest，而是在只考慮它的功能的情況下命名為get_user_left_money)
4. 在選標的過程中，不要指定特定的標名，而是要隨機選擇，因為頁面上的標是會變的。因此測試數據的選取，用例的設計要遵循盡量不要依賴系統的原則，這樣也提高了代碼的穩定性
5. 投資操作的前置條件是：可用余額要大於投資金額，如何保證這個條件，有兩種方法：
1) 後台充值足夠多的錢
2) 判斷當前用戶余額夠不夠，不夠就充值，可以調用查詢介面查詢用戶余額，調用充值介面進行充值——因為API操作是非常快的，這也提高了測試用例的效率
6. 保證用例的獨立性：每一個測試用例都要重新打開瀏覽器