ctrl+shift+del 清除瀏覽器緩存
1、發現bug
通過抓包，看http請求的響應狀態碼
例如密碼未加密問題（安全性bug）
狀態碼為 404（不一定是整個網頁顯示不出來，也可能是某個請求請求不到資源，顯示404，前端頁面對應的地方就會顯示不出來），500的bug
提交bug的時候直接寫出那一條請求出現了404 500，
2、 定位前后端的bug
比如點擊一個按鈕沒反應也沒任何提示，或者前端頁面數據顯示錯誤
首先打開F12看前端有沒有報錯信息。有報錯信息但是沒有給服務器發起網絡請求，那就是前端問題
如果沒有報錯信息，也向服務器發起了請求，然后要看前端請求的地址和傳參是否正確，如果正確可能是后端問題，如果不正確就是前端接口調用有問題
如果遇到服務器響應狀態碼是5開頭的一般是服務器端的問題
1、什么場景需要進行自動化測試
1、需求變更少，2、項目周期長、3、穩定性好（比如測試過程中后台接口穩定、服務器保持運行） 如果整個需求變更多，只能抽取部分功能進行自動化測試，
是不是自動化測試一定會替代手工測試
只能說自動化是用來輔助手工測試，自動化實現一些穩定、次要功能，就能節省出時間、花更多時間來手動測試一些主流程！保證產品質量
不一定，因為自動化測試只是把測試人員從繁瑣的手動測試中解脫出來，讓手動測試更充分，對一些核心功能有時間測試得更徹底
404是前端還是后端bug
404表示資源找不到
前端代碼資源地址寫錯了（前端bug）；后台確實URL沒有對應的資源（后台bug）
http://www.cnblogs.com/nickjiang/p/9893278.html
3、composer定位前后端的bug（修改請求）
繞過前端向后台發請求（驗證后台有沒有做對應的限制）
4、做接口測試
一、應用場景1（mock數據）
聚合數據的獲取全國天氣的接口：
http://v.juhe.cn/weather/indexcityname=110&dtype=&format=&key=5b3a961ed1478b529d5ae2416ccfd2eb
這個接口可以免費調用500次，超過500次，每調用一次收取1分錢，為了免費使用，就要fiddler來mock數據
1、首先，免費使用的過程中，用fiddler獲取該接口請求和響應，將響應body保存下來
右鍵點擊fiddler左側的會話框中該接口請求會話——Save——Response——Response Body，將該請求的響應內容保存到桌面（該接口請求的資源是什么類型，保存下來就是什么類型）
2、超過500次后瀏覽器請求該接口提示
3、使用fiddler的autoresponder，添加規則，當請求地址和下面規則中的地址一致時，返回存儲在本地（上一步驟保存在桌面的文件）的響應內容
4、再次瀏覽器請求該接口，就不去從服務器獲取響應，而是按照fiddler設置的規則重定向到本地的文件。這樣前端開發或測試可以使用該方法去調用接口，線上請求，返回本地的內容，可以隨意修改本地內容，再次請求，可以查看前端頁面顯示了 上述第3個步驟，也可以使用before Request設置斷點，在截取瀏覽器的請求后，設置一個響應內容返回（可以是json、css、html、圖片、txt等各種形式），如下圖
應用場景二 后端接口還未開發好或者不穩定時，前端開發人員就沒辦法調試代碼，此時可以用fiddler的mock功能，只要知道接口返回的json串，請求接口時，重定向返回本地保存的json內容！不依賴於后端接口 某些模塊沒有實現，但是又希望對一些已經實現的模塊進行測試，提升測試效率，所以我們需要模擬未實現的模塊 比如前端開發人員已經將注冊頁面寫好了，但是后端注冊接口還沒寫完，測試想要測試前端的注冊功能，就要用fiddler的autoresponsder功能或者before request斷點調試功能模擬注冊接口的返回結果 設置before request ，修改服務器返回為接口文檔中該接口返回的字符串（有10種返回結果，就要測試10種返回結果），就會不經過服務器，直接將該字串內容顯示到前端頁面了，這種只是測試前端頁面跳轉、數據展示、提示語顯示等是否正常 應用場景三、 Fiddler mock后端接口的返回值 作用：攔截后端接口的返回，並修改 Fiddler 重定向--利用線上的環境來測試你的代碼,但又不對線上產生影響--修改js,圖片,CSS,HTML
比如外部接口，不容易獲取或響應速度慢
應用場景四 客戶端滲透 1、獲取用戶管家信息——敏感信息 2、蒙蔽客戶端——修改服務器返回 服務器滲透 1、篡改用戶信息——篡改用戶操作信息 2、釣魚—請求到達代理網站