A. 在pc端寫的web前端頁面，要轉到微信上，怎麼樣在電腦上測試有沒有什麼好用的軟體呢
Opera Mobile Emulator 模擬手機瀏覽器，微信頁面也是調用微信的內置瀏覽器
B. 前端寫好的代碼要在公司內部區域網伺服器測試之後才提交後台嗎
公司給你svn帳號和密碼--->在自己電腦上下載網站代碼--->本地開發測試--->通過svn提交--->線上查看
C. 前端使用mqtt之後 如何測試
使用JMeter測試MQTT協議
服務端基於spring-cloud微服務框架,主要提供服務發現,用戶管理,許可權管理,設備管理,MQTT節點管理等管理功能
D. vue.js前端自己寫死的數據在自己電腦上怎麼測
安裝一個wamp, 相當於一個虛擬的伺服器。軟體小，操作簡單。方便易用。實在不行 安裝HBulid， 這個玩意是個前端開發工具，也自帶伺服器。
E. 請問我是女生現從事Web前端工作，我想轉測試類的工作，比如前端測試好轉么
你做過前端開發，確實懂技術的測試比較吃香，因為他們無論在自動測試還是性能測試都有很大優勢。如果只做功能測試會埋沒你的能力
1.寫測試用例，這個需要理清產品流程，你做過開發會簡單些，然後設計自己測試的方法，以文字形式將所有操作表現出來，要覆蓋所有功能點，正常異常等各種操作都要考慮到
2.自動測試相對手工測試來說比較高端，他也屬於功能測試。通過腳本或自動測試工具來執行被測程序從而檢查功能是否正確實現。自動測試只能檢查已經發現的BUG是否重現，或能否正確執行被測程序。通常用以回歸測試和重復測試。他不能發現新的BUG。
3.性能測試。這個需要網路知識，代碼能力，計算機知識等，如果只是錄制腳本運行腳本，那麼每個人都能做，主要的是分析瓶頸，相信大多數開發也沒這個能力，所以在我的認知里性能是最難的。
4.安全測試，一聽肯定需要網路安全方面的知識
5.本地化測試。合格必須需要的是語言能力，然後是功能測試的能力。
其實無論那種測試，都是以功能測試為基礎。
其他測試就不一一列舉了。如果只做功能測試，除了設計測試用例，其他就是執行測試用例，只要測試用例寫的好，誰都能做，這個「誰都能做」是用例寫的好的前提。
測試主要是一個覆蓋率的問題。雖說不能百分百覆蓋所有組合的操作。但是好的測試人員能夠更全面的考慮測試方法。
F. APP開發之後該怎麼測試
1. UI 測試
app主要核ui與實際設計的效果圖是否一致；交互方面的問題建議，可以先與產品經理確認，確認通過後，才開始讓開發實施更改或優化
2. 功能測試
根據軟體說明或用戶需求驗證App的各個功能實現，實際測試過程一般都是根據功能測試用例來執行。測試覆蓋率基本上都是有測試用例主導，也就是說在功能測試部分，是檢驗測試用例是否有效以及完整的，也就導致另外一個問題，測試用例怎麼寫的問題，將另外一篇文章來單獨闡述測試用例的編寫方法。
3. 中斷測試
模擬用戶真實使用app是會遇到的中斷情況進行測試.如： 網路的斷網， 切換網路， 斷電，來電話/簡訊，聽音樂，切換到其他app， 打開其他app 的通知等
4. 兼容以及適配測試
新舊版本的在功能，邏輯層面的兼容測試， 同一個app 在不同系統版本運行，以及不同機型之間的適配測試
兼容測試：介面的兼容性測試能夠保證大部分的功能完善；app在不同系統版本上保證運行
適配性： 屏幕，系統版本等（系統位數一定要考慮）
該部分通過第三方的雲平台進行
5. 性能測試
可測試的方面
- 安裝和啟動時間
- CPU的佔用
- 內存的佔用
- 流量的耗用
- 電量的耗用
- 後端,測試App中的各類操作是否滿足用戶響應時間要求，主要是測試點在網速方面，2g，3g，wifi， 4g一定要覆蓋到
- 後端 有網路並發
6. 穩定性測試，壓力測試
1.在各種邊界壓力情況下（如電池、存儲、網速等），驗證App是否能正確響應
2.反復/長期操作下，系統資源是否佔用異常；Android 可是使用adb命令
3.壓力測試主要集中在後端，前端的壓力測試目前測的較少
7.安全測試
App安全測試大概劃分為以下幾類：
1)從數據的本地存儲到數據的傳輸、處理以及遠程訪問等各個環節，基於相應的安全標准/行業標准評估App的安全特性；
2)借鑒在Web App和網路安全測試的一些成功經驗在智能終端App測試中進行裁減或適配；
3)檢測App的用戶授權級別，數據泄漏，非法授權訪問等；
4)對App的輸入有效性校驗、認證、授權、敏感數據存儲、數據加密等方面進行檢測,以期發現潛在的安全問題；
5)基於各種通信協議或相應的行業安全標准檢視App是否滿足相應的要求。
8.用戶體驗測試
這個簡單的說就是站在用戶的角度上進行使用app，學習成本低，易上手等，可以進行用戶盲測，根據用戶反饋的意見進行修改。測試人員可以通過與其他競爭品進行對比， 或者根據較大廠商app的交互習慣進行比較。
9. 回歸測試--一般這部分建議使用自動化測試， 如果沒有自動化測試，可以根據以幾方面進行測試
1.根據產品說明書或者功能文檔進行功能確認
2.重新將主要優先順序較高的測試用例執行一遍
3.重新驗證bug
10. 線上測試
線上測試是產品上線之後一定要完成的，這部分可以根據場景化進行回歸測試，其中網路環境要全部覆蓋一遍
G. 一個前端開發的工作流程是什麼樣的
我們以前基本的流程是，領導或甲方提出需求，然後產品分析需求，並且根據需求畫出原型圖，然後根據原型圖出設計稿。
出完設計稿團隊評審，過後交與前端製作靜態頁面，然後靜態頁面，交與設計審核，過後交給開發人員，進行動態數據的添加。
添加完之後，發布測試環境，產品測試領導審核，成功後，直接發布產品環境。或進行版本迭代。
這是整個的一個設計，開發，部署的流程。
根據前面的，在補充一下，前面的所有流程中的靈魂是原始需求提出者，但人隨著客觀條件的變化，思維認識會有所不一致，
所以產生了文檔，文檔是貫穿整個流程的一個靈魂。
而產品是整個流程中文檔的編寫者，因為產品最能接觸最原始的需求，對需求的理解更深刻或專業，所以他會有一個文檔出來。
這個文檔是需要交付給設計，讓設計在設計過程中進行參考。
前端看的另外一個文檔。交互設計師出交互文檔，一般的公司沒有交互設計師那就是由產品來出的交互文檔。
有的交互不過於復雜，就沒有文檔，只是郵件。
有時候說，不要這個郵件行不行，那怕是最簡單的原始東西，沒有文件或郵件是不能做一個後期測試回溯的依據。
產品文檔表示頁面的流轉或數據的走向，交互文檔描述頁面復雜的交互或各個用戶表單與用戶發生的各種互動。
另外2個是，要架構師或項目經理出的需求文檔，需求文檔是對整個項目的歷史背景，系統開發軟硬體要求，或版本信息，等等。
另外一個是由服務端工程師提供的介面文檔，這里邊包括一些請求類型，傳參的數目與鍵名，還有服務端返回的參數名約定等等的，這些文檔是開發中的靈魂，也是以後測試回溯的標准或依據。
H. 如何進行前端自動化測試
沒人邀請，路過回答。
前端測試是前端工程方面的重要分支，有過一些探索，這里簡單分享一下。
首先，還是要強調一點：
前端是一種特殊的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的展現問題已經是不小的進步了。
I. 剛進一家公司，這個公司有人專門寫前端，我是java寫後台，我想問測試的時候怎麼搞
自己寫個簡單的頁面，去測試，或者如果是struts可以寫action的測試用例的
~~~~~~~~~~
J. 前端中怎樣將寫好的網頁在真機上進行測試
使用grunt+bower+webstorm作為前端開發工具，在開發移動端的時候，怎麼才能直接在真機上進行頁面調試？
舉個例子就是在IDE里寫html，手機上也會同步展示。
-------分隔線------
在各位大神的推薦下使用了browser-sync，發現真是神器啊，現在使用grunt-watch + browser-sync 可以實現了實時編譯。這里有個前端大牛裙前面是五五二中間是就一二後面是思五五連起來可以了，不是來學習請不要加了
在使用的過程中發現了一個問題，就是使用ip在本機是可以訪問的
http://192.168.2.224:3000/src/html/index.html
但是發到手機上就訪問不了了
確定是在同一個網段，路由器配置也檢查過了。。。實在找不到原因了