A. 前端UI自動化puppeteer實踐
背景
在表單（web頁面）測試過程中，要經常對表單基本功能進行回歸，曾經考慮過使用webUI自動化工具，減少重復性的操作，但是因為之前用過appium，對UI自動化的體驗不是很好，所以有些糾結，但是，再仔細想一下，有可能存在比較好用又確實能提升效率的工具，也不妨去嘗試一下。
上網查詢了一下，puppeteer具有可以使用錄制腳本的工具puppeteer-recorder、截圖等功能，找了個demo開始試了一下，發現坑較少，安裝方便，使用比較流暢。
puppeteer介紹
Puppeteer 是一個Node庫， 它提供高級API，通過DevTools Protocol 來控制Chrome 或 Chromium。 Puppeteer 默認運行為headless ，但是可以配置為運行為non-headless。詳見文末參考鏈接。
效果展示
目錄結構
cases：用例腳本
config：配置文件，可區分測試、線上環境
screenshot_outputs：輸出的截圖文件
utils：用到的通用方法
測試思路
1、在腳本中寫入測試執行步驟
2、運行腳本
3、查看執行結果（截圖），查看是否符合預期。
這樣操作會使簡單很測試很多。就拿表單人工審核為例，全部人工操作的話，需要填寫並提交表單，登錄表單運營後台，找到對應的目錄及表單，對表單進行審核，再重新打開表單並進行查看，而自動化的話，在寫好腳本（在腳本中可進行介面請求）之後，就可以直接運行腳本，查看結果。
環境搭建
1、安裝puppeteer：npm install puppeteer（前提是安裝了node、npm）
2、安裝chrome插件puppeteer-recorder（可自行網路，比較簡單）
3、npm init，初始化一個項目
腳本編寫
遇到問題
1、puppeteer-recorder只能錄制獲取元素、點擊元素操作，沒有獲取到填寫文本的操作，需要修改或添加已錄制好的腳本
2、有些地方例如截圖前，介面請求結束後，需要使用等待方法。await page.waitFor(3000)
3、使用await進行介面請求，不然會出現同步非同步問題，後面的語句開始執行（但是要用到的參數還沒有獲取到）
參考：
https://zhuanlan.hu.com/p/76237595
https://www.jianshu.com/p/679f07ba474b
B. 什麼是"前端工程化"
前端工程化是指使用軟體工程的技術和方法來進行前端的開發流程、技術、工具、經驗等規范化、標准化。其主要目的為了提高效率和降低成本，即提高開發過程中的開發效率，減少不必要的重復工作時間。
前端工程化是前端架構中重要的一環，主要就是為了解決上述大部分問題的。而前端工程本質上是軟體工程的一種，因此我們應該從軟體工程的角度來研究前端工程。
前端工程化有四個特點：模塊化、組件化、自動化、規范化。
1、模塊化：
就是將一個大文件拆分成相互依賴的小文件，再進行統一的拼裝和載入。只有這樣，才有多人協助的可能。在工程化之前，一直是使用js、jquery、ajax，這沒有模塊概念，對於開發大型且復雜的系統會有一定的限制。
2、組件化：
組件化≠模塊化。模板化只是在文件層面上，對代碼和資源的拆分；組件化是在設計層面上，對於UI的拆分。目前市場上的組件化框架最多，主要的有Vue，React，Angular2。
3、自動化：
「簡單重復的工作交給機器來做」，自動化也就是有很多自動化工具代替我們來完成，例如持續集成、自動化構建、自動化部署、自動化測試等等。
4、規范化：（至關重要的一環）
在項目規劃初期制定的好壞對於後期的開發有一定影響。包括的規范有：
目錄結構的制定、編碼規范、前後端介面規范、文檔規范、組件管理、Git分支管理、Commit描述規范、定期codeReview、視覺圖標規范。
(2)前端ui自動化測試擴展閱讀：
為什麼需要前端工程化：
前端越來越復雜，設計的問題和環節也越來越多，不採用工程化管理，就無法很好的實現團隊協同和降低復雜性。 原因如下：
1、前端范疇不斷擴大
早期的前端只需要適配桌面瀏覽器，而現在的前端，需要適配不同類型和尺寸的設備，包括移動端網頁，app應用等。
2、前後端分離
早期的前端只是後端 MVC 框架的一層模塊， 而現在的前端普遍是從後端介面獲取數據，編寫處理邏輯，各種前端mvc前端框架也層出不窮。
3、模塊化開發的出現
現在的前端開發不再是從零寫起，重復造輪子，而是會引用大量內部和外部的組件和模塊，這也導致前端必須進行模塊管理。
4、轉碼器的盛行
為了提高效率，前端工程往往不會直接寫html,css,和js代碼，而是改用其他格式書寫，再用工具編譯為目標格式。
比如用Jade 寫HTML，用less、sass、stylus 編寫CSS,用ES6、Typescript編寫JavaScript。
5、開發流程和團隊
早期的前端團隊往往只有幾個人，而現在的前端團隊可以擴展到幾十人，甚至上百人。每個人只負責自己的一塊內容。所以，如何協調多人多團隊的工作，保證溝通順暢，保證許可權管理，越來越成為一大問題。
前端工程化的具體內容：
1、代碼規范: 保證團隊所有成員以同樣的規范開發代碼。
2、分支管理: 不同的開發人員開發不同的功能或組件，按照統一的流程合並到主幹。
3、模塊管理: 一方面，團隊引用的模塊應該是規范的;另一方面，必須保證這些模塊可以正確的加入到最終編譯好的包文件中。
4、自動化測試：為了保證和並進主幹的代碼達到質量標准，必須有測試，而且測試應該是自動化的，可以回歸的；
5、構建：主幹更新以後，自動將代碼編譯為最終的目標格式，並且准備好各種靜態資源；
6、部署：將構建好的代碼部署到生產環境。
C. 軟體測試和前端開發有什麼區別
在選擇之前可以先分別了解一下這兩個方向的主要工作職責是什麼。
一、軟體測試
字面意思，主要工作是測試軟體。發現軟體程序中的錯誤，對軟體是否符合設計要求，以及是否能達到技術要求，進行有關驗證，以及評估軟體的質量。
隨著IT類企業的大量增加，從而導致各類人才出現大量缺口，其中軟體測試人才更是緊缺。當然，這里說的是嚴格意義上的軟體測試開發工程師。
需要熟練標准規范的測試流程，能夠做性能，功能，自動化測試；熟練使用Linux操縱系統，獨立搭建測試環境；熟練MySQL、Oracle等資料庫的一種或多種；至少掌握Java、Python、C++等一門編程語言。
在蝸牛學苑的教學過程中，不但要教會學員做標準的軟體測試，還會教會學員自己開發自動化測試工具。我們會讓學員用這些工具來完成一些項目，但是這些工具對我們來說根本不是核心和重點，我們要教會大家的是不依賴於這些工具也可以完成自動化測試，這就牽涉到其背後的底層的工作原理，這些才是我們要學習的重點。
二、Web前端
前端開發是創建Web頁面或APP等前端界面呈現給用戶的過程。通過HTML、CSS及JavaScript以及衍生出來的各種技術、框架、解決方案，來實現互聯網產品的用戶界面交互。前端技術變化比較快，需要不斷的學習。在終端應用場景不斷拓展的當下，前端開發的邊界也在不斷的拓展，崗位需求的數量也會呈不斷上升的趨勢。
蝸牛學苑在結合了企業需求、企業技術調研以及目前主流的技術分析和實戰後將Web前端課程重磅升級，增加了更多項目實戰，框架原理的分析，加強了前後端的實戰。不僅要學會怎麼用，還要知道是怎麼來的。
總之，軟體測試和Web前端都是不錯的專業，都有充足的上升空間和發展前景。根據你自己的興趣和擅長的方向來選擇吧。
D. 自動化測試和前端哪個好學
前端比較好學一點，前端相對來說適合零基礎的人學習，比較好掌握一些。
E. 前後端自動化測試方案
這段時間我探索了點自動化測試方面的技術，探索結果如下
【後端】：任意後端工程 + python 自動化測試腳本（實現介面測試），伺服器要求：指令伺服器即可（即終端操作系統）
【前端】：任意前端工程 + python 自動化測試腳本（實現UI交互測試），伺服器要求：必須是可視化伺服器（即有交互界面的系統） （雖然說 phantomjs 可以實現無界面的情況下進行瀏覽器測試，但是還是不太推薦，畢竟對於前端而言，可視化才最好）
經過探索下來，發現 python 在實現自動化方案確實非常合適，且前後端都可以通過python實現自動化測試，如此一來自動化測試也就可以獨立出一個工程，而無需受前後端工程語種、框架等各種不同的影響。只是前端自動化測試比較特殊，需要模擬用戶交互，最好是有界面的系統（通過瀏覽器驅動器調用瀏覽器實現自動化交互測試），也就是說前後端的自動化測試伺服器要麼都用一台帶交互界面的系統，要麼就用2台伺服器，一台終端伺服器測後台介面，一台交互伺服器測前端交互
F. 如何成為一名高級自動化測試工程師
優秀的測試人員可以做的事情可以包括如下3點：
由單純的測試變成項目質量保證工作
持續集成探索和推動和自動化測試技術研究
測試相關工具的開發
- 1、我們先來講第一點，由單純的測試變成項目質量保證工作
- 測試，從狹義的角度來講，包括如下這些環節：
- 測試計劃和測試用例編寫－測試執行－質量報告書寫
- 測試人員一般會在開發階段就進行測試計劃和測試用例的編寫和准備工作；在測試階段，我們一般先會做功能測試，等項目功能基本穩定，bug較少了，就開始做兼容性測試、性能測試、安全性測試。兼容性測試保證了產品在多瀏覽器、APP在產品在不同機型下的兼容性；性能測試保證了產品在海量用戶大流量下的服務能力；安全測試能發現產品可能會被攻擊的各個隱患。做完了這些測試以後，人員發布質量報告，產品上線。
- 不過，優秀的測試人員需要向上游和下游拓展測試的領域，把自己放在「質量保障」的角色上，推動整個項目組一起保證質量，上游的工作包括：
在產品剛立項、進行需求確認的時候，測試人員就會參與進去，仔細地Review需求，看需求是不是完整、有沒有漏洞，這個時候中毀拿還沒有進入正式開發，修改需求對於項目組來說代價是最少的。在這個環節，測試人員憑借縝密的推演、發散性的思維，往往能發現很多需求的漏洞，提高了項目的整體效率。
另外，測試人員在完成測試計劃、測試用例以後，會邀請開發、策劃一起來評審測試用例，在這個環節，由於測試人員把每個需求如何細化測試都體現在了用例裡面，就相當於再次把需求分析了個透，往往還能發現很多需求的漏洞。這也是提早發現需求漏洞的有效環節。
我們知道，代碼的質量歸根結底是由開發保證的，測試做的工作，只是發現Bug讓開發修復。如果一個花瓶，一開始就是很完美的；另一花瓶經過了各種修補，看起來比較完美，大家覺得哪個花瓶比較好？當然是第一個花瓶。所以，測試人員應該站在質量保障的立場，想辦法跟項目組溝通、給開發提供工具，讓開發自己把質量保障工作做好。比較可行的一些方式是：提供一些手工用例讓開發自測；給一些自動化的介面和UI測試代碼讓開發自測；部署靜態代碼檢查工具，並推動開發分析和修改發現的問題；有一些做得好的項目已經實現了持續集成，也可以嘗試。
- 下游的工作包括：
在產品完成了測試以後，就是發布的環節了，測試人員在發布的環節也能發揮作用，首先，測試人員為了部署測試環境，研究自動化部署的技術，可以把上線部署的環節也自動化，以前需要2個小時的部署環節壓縮到半個小時甚至更少，而且更加准確可靠。
如果有些版本修改比較多，上線的質量風險大，測試人員會跟產品一起制定灰度發布的方案並在技術上進行實現，讓版本先賣搭面向一小部分用戶開放，如果發現Bug了，影響的用戶也比較小，Bug改掉以後，再逐漸擴大用戶范圍。
- 另外，優秀的測試人員還會發動項目組的其他人一起來保證項目質量，比如推動開發進行代碼Review；引入冒煙自測流程，讓開發先自測以後再提交給測試做冒煙測試；通過在項目組分析Bug，讓開發提高自測，降低Bug數量等；引入策劃、交互、視覺在測試階段進行走查，等等各種措施。
- 2、持續集成探索和自動化測試技術研究
- 業界都在說持續集成，那持續集成究竟是個什麼鬼呢？
- 持續集成原本的意思是讓開發每提交一次代碼就自動化測試一次，如果自動化測試發現問題了，測試用例就會失敗，開發就會馬上發現這個失敗，並修改代碼。
- 要做到持續集成可有很多工作要做。
首先就是編譯環節，要把所有編譯的環節都自動化起來，開發每次提交代碼都能進行自動編譯；
編譯完成後，就是靜態代碼檢查的環節，通過靜態代碼檢查的工具檢查代碼的問題，比如，資料庫連接池沒有釋放，參數不匹配等。
靜態代碼檢查完成後，就是單元測試了，單元測試用例一般是開發人員或者測試人員編寫，或者開發和測試合作編寫，保證的是余茄開發內部函數的正確性。一個健康的自動化測試方案中，單元測試用例的佔比是最高的。
然後就是介面測試，一般保證的是後端開發提供給前端開發的HTTP介面，介面一般也比較穩定，用例比較容易維護，所以，介面測試的自動化佔比也可以做到很高。
在介面測試的上層就是針對用戶界面的UI測試了，就像測試人員手工執行一樣，UI自動化測試能操作頁面的元素，完成自動化。不過，由於用戶界面常常要重構，所以我們常常會控制UI自動化測試的規模，只覆蓋主幹的用例。
- 優秀的測試人員可以把自己的工作盡量自動化，並用持續集成框架串起來，提高工作效率和質量。
- 3、測試相關工具的開發
- 優秀的測試人員會開發其他好用、趁手的工具來提高工作效率，比如數據自動生成、報表自動生成、報bug工具等。
- 其實歸根結底就是一句話：測試人員最核心的工作就是保障項目的質量，各類測試流程、技術、工具和平台的發展讓我們可以更好地保證項目的質量。
G. 「自動化測試」是否有必要做自動化測試
目錄
一、前言
二、自動化目的
三、自動化分類
四、自動化實現
一、前言
在一些測試交流群經常會看到有小夥伴在問，"怎麼做自動化測試？學習自動化測試有什麼資料嗎？自動化測試是不是很牛逼？" ，甚至有些言論是"不會自動化的測試人員，真的要被淘汰了嗎？"
不得不說一堆流量號主抓住大眾心理，點進去的必然是賣課廣告，或者是關注微信公眾號領取測試資料大禮包。
實話實說，我之前也有同樣的疑問，甚至帶著擔憂。每次又不甘心得領著測試資料大禮包......
當然，隨著自己的認知不斷擴大，自己的一套測試體系建設不斷完善，於是這些擔憂逐漸的消失。每項技術引用都要看適用場景，是否適合自己的團隊，因地制宜才能發揮其最大的價值。
因此，我想通過這篇文章來分享下我對於自動化測試的理解。
二、自動化目的
自動化工作可以節省很多人工操作成本，減少人工重復性操作，提高整個團隊的研發效率。但是如果搭建自動化體系需要耗費很長時間，投入很多人力資源，但是用戶只要2-3分鍾的手動工作就能解決，而且這個操作並不頻繁，又或者需要自動化操作的平台變更迭代非常快並且沒有規律，自動化工具在後面類似累活的跟著。那麼自動化還是有必要嗎？
我之前在的團隊，造測試數據特別困難，嚴重影響了整個研發效率，但是當時也沒有一個好的解決辦法，後來基礎研發組做了一個造數平台，這個平台需要自己去配置各種欄位，並且梳理出各個表欄位的關聯，從頭到尾一個一個去構建場景，一不小心就配置錯誤，看著提示你也找不到原因的那種。這給造數過程中又添了一個攔路虎，給本不充裕的測試時間，又耗時一把。
如果能在做執行任務前評估任務的投入和收益，那麼是不是就能更加合理的開展這項任務。那麼自動化測試的投入和收益是怎樣的呢？
投入：通過測試人員藉助腳本或者工具實現自動化，維護自動化平台。
收益：提高測試效率，提升測試人員的成長。
自動化測試真的提高測試效率嗎？真的可以提升測試人員的成長嗎？針對後者，我認為是有的。接下來我們就來聊聊自動化測試是否提高測試效率。
三、自動化分類
自動化一般分為介面自動化和UI自動化，其中UI自動化又分為Web UI自動化和App UI自動化，按照我的理解還應加上部署自動化。
接下來我將針對這四種自動化的場景做一個介紹。因為我對於UI自動化不是很熟悉，我認為投入產出比不是很高，主要還是因為我沒咋接觸過，所以後面僅做簡單介紹，重點講解介面自動化和部署自動化。
四、自動化實現
4.1、介面自動化
介面
介面測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換，傳遞過程，以及系統間的相互邏輯依賴關系等。
流程
填寫介面，入參，對出參進行斷言，每天定時構建，輸出測試報告。
入參覆蓋范圍：必選，可選，有/無/null，類型，數值大小/數值范圍，特殊字元；
出參：json，data；
介面關聯：介面之間的依賴，數據傳遞；
斷言：對響應做核驗，可以對狀態碼或者msg做校驗。
優點
介面測試可以做到更多的覆蓋場景；
介面測試可以更快的發現服務端問題；
介面測試相對容易實現自動化持續集成；
介面測試相對於比單元測試比較貼近業務場景；
技術選型
1、MeterSphere
MeterSphere 是一站式測試平台，涵蓋測試跟蹤、介面測試、性能測試、 團隊協作等功能，全面兼容 JMeter、Postman、Swagger 等開源、主流標准。
MeterSphere是一個功能交全的平台，並且是開源的，對於免費版就足夠小團隊使用了，使用門檻相對來說較低，對於技術能力要求不高，所以是一個不錯的選擇。MeterShpre使用的技術棧是SpringBoot+vue，以及一些中間件，也可以在此基礎上進行二次開發。
2、Python
通過Python來做介面自動化的話，常用組件有：執行庫Requests，斷言庫unittest，測試報告HTMLTestRunner，通過持續集成Jenkins做定時構建。
框架思想：封裝，數據驅動。
使用Python的話則需要掌握一定的代碼能力，當然這個對個人技能的提升是很有幫助的，但是如果在時間比較緊迫的並且沒有足夠的技術功底情況下，還是比較推薦MeterSphere的。
4.2、部署自動化
部署
部署就是將源代碼編譯成可運行軟體包，比如jar包或者war包，並且將軟體包放到目標環境，將軟體包運行起來，並且能夠被客戶端調用。
流程
通過遠程倉庫拉取代碼，前端編譯，後端編譯，下發軟體包到目標機器，重啟服務，啟動失敗則告警。
優點
相比傳統手工部署，速度更快，不容易出錯，提高交付效率。
技術選型
gitlab或者gitee：代碼託管
git：版本管理
node：前端編譯
maven：後端編譯
ansible：下發文件
shell：重啟服務
pipeline：流水線構建
Jenkins：CICD大總管，將以上工具整合起來，提供頁面供用戶操作部署流程。
4.3、Web UI自動化
UI自動化
通過頁面元素定位定位到元素，模擬用戶的操作行為，點擊，輸入，拖拽等。
流程
定位元素，模擬用戶操作，發送測試報告。
優點
適用於回歸主流程，並且變更不頻繁的場景。可用於重復性的功能測試及驗證。我之前在的團隊做過一段Web UI自動化，但是因為需求頻繁變更，並且精力有限，維護這個平台的成本較高，後面就沒有持續維護了。
技術選型
Python，selenium。
4.4、App UI自動化
UI自動化
通過頁面元素定位定位到元素，模擬用戶的操作行為，點擊，輸入，拖拽等。
流程
定位元素，模擬用戶操作，發送測試報告。
優點
適用於回歸主流程，並且變更不頻繁的場景。
技術選型
Appinum。
結論：我認為介面自動化和部署自動化是能夠帶來收益的，是真實能夠提高效率的，並且也能夠給測試人員的帶來成長。
關注【嘎嘎軟體測試】
搞測試，不迷路
呱呱大王本呱帶你飛！
嘎嘎軟體測試 分享個人成長、團隊管理、軟體測試技能知識等內容，做到有思想、有觀點、有深度，歡迎訂閱。
H. 自動精靈ui界面如何製作
製作自動精靈UI界面的具體方法會因使用的開發工具和目歷塌標平台等因素而有所不同。以肢凱圓下是一些常見的方法供您參考：
1. 使用自動化測試工具提供的界面編輯器或可視化配置工具，例如Selenium IDE、Robot Framework等，它們通常具有可拖拽、可調整大小、可編輯屬性等功能，可以很方便地製作UI界面。
2. 如果需要定製化更多的UI元素和交互效果，可以選擇使用前端開發框架和工具孫派進行開發。例如，如果在Web應用中使用自動化測試，可以選擇使用HTML、CSS和JavaScript等Web前端開發技術，利用主流的框架，如Vue.js、React.js等快速進行開發。
3. 另外還可以使用UI設計器和界面模板來加快UI製作過程。常見的UI設計器包括Sketch、Adobe XD、Figma等，在這些設計器的幫助下，您可以通過可視化拖拽、設計藍圖和樣式表等方式快速完成靜態UI設計。同時，還可以直接使用現有的UI模板，以模塊化和組件化的方式構建UI，提高開發效率。
總之，無論哪種方式，都需要根據具體需求有選擇地借用各種開發工具和框架，在快速實現UI設計的同時，保證交互體驗和可擴展性。
I. Appium進行自動化測試的時候，始終無反應，也沒有日誌輸出，請問什麼原因
1. 啟http伺服器：127.0.0.1:4723 2. 根據測試代碼setUp()進行初始化http伺服器建立session象； 3. 始調用adb找連接設備設置設備id 猜測：我連接模擬器設備呢第二篇文章命令行啟使用-U參數指定某設備我現圖形界面啟沒指定設備 4. 等待設備准備響應命令 相關命令： c1: adb.exe -s emulator-5554 wait-for-device c2: adb.exe -s emulator-5554 shell "echo 'ready'" 5.啟logcat志監控 java -jar appium\node_moles\appium\lib\devices\android\helpers\strings_from_apk.jar aimsi.apk c:\windows\temp\com.example.aimsi 條命令讀取apk文件些apk基本信息json描述我例： { "app_name" : "Aimsi", "menu_settings" : "Settings", "title_activity_main" : "MainActivity", "RbtnImsi" : "漢字", "RtxtImsi" : "IMSI_IMEI" } apk屬性信息文件strings.json存設備目錄： c3:adb.exe -s emulator-5554 push "c:\\windows\\temp\\com.example.aimsi\\strings.json" /data/local/tmp 6.讀取apk安裝情況 c4:adb.exe -s emulator-5554 shell "pm list packages -3 com.example.aimsi" 讀結我前已經安裝apk 7.埠映射發給appium httpserver內容經httpserver直接發給設備 c5:adb.exe -s emulator-5554 forward tcp:4724 tcp:4724 8. 弄appiumjar包設備 c6:adb.exe -s emulator-5554 appium\node_moles\appium\build\android_bootstrap\appiumbootstrap.jar /data/local/tmp 網路bootstrap：Bootstrap 快速發Web應用程序前端工具包CSSHTML集合,使用新瀏覽器技術,給Web發提供尚版式 9.哇k安裝unlock_apk-debug.apk c7:adb.exe -s emulator-5554 install appium\node_moles\appium\build\unlock_apk\unlock_apk-debug.apk apk用解鎖屏幕解鎖apk使其調試我猜者吧運行測試程序候看看手機沒apk知道 10.kill掉所uiautomator進程 c8:adb.exe -s emulator-5554 shell "ps|grep 'uiautomator'" 我模擬器沒啟進程 11.執行bootstrap c9:adb.exe -s emulator-5554 uiautomator runtest appiumbootstrap.jar -c io.appium.android.bootstrap.bootstrap 帝原諒我沒管寫面緊跟著uiautomator輸 12.bootstrap始工作 socket打4724埠appiumsocket伺服器准備緒 載入json,喚醒客戶端 等我想想設備apk--設備bootstrap--pcappium http server--測試程序先姑且猜著吧 13. 所設備運行窗口都輸志文件判斷設備已經解鎖繼續 c10:adb.exe -s emulator-5554 shell "mpsys window" 志文件寫pc：appium\node_moles\appium\.mpsys.log 14.啟測試程序 c11:adb.exe -s emulator-5554 shell "am start -S -n com.example.aimsi/.MainActivity" 15.等待測程序獲焦點處超60s模擬器太慢居讀兩窗口才啟功 16.創建session記初候根據setup提交給appium httpserver東東吧sessionid維持工作隊列bootstrap隊列面取命令執行像知道隊列pc設備我覺像pc； 面些內容沒啥看非步步調用 說啥研究些東西仔細做技術尤其測試技術原則用少搞明白底細遇問題候處理起快 吧
J. 學軟體測試還是前端好一點 沒什麼基礎，但是邏輯思維還算不錯。
前端和測試就入行難度來說的話，肯定是前端比較難得。
國內的軟體測試大多都是黑盒測試，通俗的講就是手動輸入，然後點點點。多一點就是配合一點自動化測試。絕大多數的創業公司都是這么一個情況。
而前端，相對於測試來，這么說都屬於開發范疇了，要學習的肯定也更多，前端很雜，要學習的語言也是非常多的。我之前是測試轉 Android 開發的，對前端了解並不多。
就發展前景來說，如果按照同等努力程度來說，也是前端的發展前景樂觀一點。
國內的軟體測試不那麼受重視，很重要一個原因就是很多互聯網公司對自己的系統質量要求不夠高，導致很多情況都是近十個前端開發，然後就那麼一個測試。甚至沒有，得靠開發的自測。當然創業初期，需要削減成本，這個也是一個因素。
前端就不同了，雖然很多產品都偏向移動用戶去了。但是從大趨勢來看的話，不管是 Android 還是 IOS，以後都會被統一為大前端，只是時間問題。還有很多產品也是很重視PC前端的。
所以因人而異，要看自己的條件及興趣天賦。
1、理工科好點的，邏輯思維比較強的，英語好的，有一定編程興趣的，可以考慮前端。如果不是特別喜歡鑽研的， 學前端，如果沒有學好，可能很難找到工作 。
2、文科的，沒啥計算基礎的，希望可以風險小點的，可以選擇軟體測試，軟體測試入門相對還是容易一些。