1、如何區分前端和后端
通俗講，用戶看到的部分都叫前端。
而用戶看不到的部分可以統稱為后端。
2、前端和后端的呈現形式
前端的呈現形式有web端、移動端（ios、安卓）、小程序等。
后端系統一般只有一個，收集不同前端反饋回來的數據。
3、前端和后端工作內容的差別
前端主要是考慮怎樣能讓用戶覺得用起來更舒服，考慮界面布局、交互效果、頁面加載速度等。
后端更多的是與數據庫進行交互以處理相應的業務邏輯。需要考慮的是如何實現功能、數據的存取、平台的穩定性與性能等。
4、如何分析bug（bug類型）
當bug出現時，一般來說分大致3種情況：
（1）數據庫層面的：
可能少某個字段，或者字段值為空等等，這些可能在設計數據庫時就埋下了錯誤的種子，導致程序調用數據庫錯誤的數據產生bug，這一類問題不算普遍，但也是最容易忽視的一種情況，有時候從數據庫入手定位bug說不定還能發現數據庫的設計缺陷。
（2）網絡層面的：
通常這種都是網絡情況較差的時候產生的，比如手機的移動網絡信號不好，又或是公司網絡不穩定，導致js/css未加載完全或者請求超時等等，這種問題其實非程序bug造成的，可以不用提交bug，也不用讓開發毫無頭緒的去查代碼的問題。當然如果可以的話也可以當優化建議提給開發，讓他優化代碼，比如壓縮js/css，增加超時時間，超時后的重試機制。
（3）代碼層面的：
普遍的bug基本都是代碼有問題造成的，排除掉1和2剩下后就可以確定是程序bug了。對於了解網絡架構的人來說，其實程序也分前端和后端的，一般對於界面顯示有問題直接可以判斷是前端的問題，比如系統兼容性，瀏覽器兼容性。
而對於數據或者邏輯上的問題，則需要（檢查接口）前端和后台之間是通過接口文件相互聯系的，通過抓包工具來進行分析 ：
1）請求未返回數據，可能是client（客戶端）請求數據錯誤，可能是server端（服務器端）處理錯誤。
2）請求返回錯誤的數據，那就是server端處理錯誤。
5、如何區分前端問題和后端問題
前台的bug通常是功能、界面和兼容性等有關；
后台的bug與邏輯、性能和安全性有關。
與數據相關的錯誤、排序問題大多是后台問題；
對於APP頁面toast提示可能是后台給的，可能是APP給的。
（1）檢查接口
前端和后台之間是通過接口文件相互聯系的，測試人員可以通過查看接口文件，來區分前端和后台bug。
（2）情況分析
a、檢查請求的數據是什么？反饋的數據又是什么？
通過抓包工具來進行抓包分析。
大多數的瀏覽器都有自帶的抓包插件，如 FireFox 的 FireBug 插件，Chrome、360急速模式、搜狗高速模式自帶的 DevelopTools 插件（F12開啟），在 NetWork 中可以看到當前頁面發送的每一個http請求。請求接口、傳參、響應三部分來判斷Bug，另外，也可以在瀏覽器的控制台進行js代碼調試定位。
1）請求接口URL是否正確
如果請求接口URL不正確，為前端Bug；
2）http請求中的參數是否正確
如果http請求中的參數不正確，為前端Bug；
3）如果接口URL和參數都正確，查看響應內容是否正確
如果這種情況下響應內容不正確，則為后端Bug。
4）如果JS基礎比較好的話，也可以在瀏覽器的控制台中輸入JS代碼進行調試。
b、根據接口的文件，檢查數據是否正確。
如果發送的數據是正確的，但是后台反饋的數據是不符合需求的，那就是后台的問題。
如果前端沒有請求接口，或者請求的時候發送數據與需求不符，那這個時候就是前端的問題了。
6、如何精准的定位前台bug並且描述bug？
（1）按F12在 console（控制台）中查看報錯信息，對於出錯的 js 可以在 Sources 下查看對應報錯的資源文件，截圖放入bug單，bug定位策略：
1）網站前台的權限控制：沒有權限的用戶是不能直接輸入url的方式來進行訪問的，必須進行登錄。涉及到權限的測試，一定不能漏掉url的方式也需要驗證一下。而在單個頁面進行W3C測試時則需要去掉該權限控制。
2）網站前台的title，對於這個也很容易忽視。進入到不同的功能頁面，title顯示應該是有，並且要和你進入的頁面一致。title就是在瀏覽器最左上角看到的那些文字
3）http和https的注意點：https是一種安全鏈接，它是需要證書的，而http就是普通鏈接，所以在你的系統中客戶會要求某些關鍵的地方加上這種安全連接，那么此時你需要注意的是，對於不需要安全鏈接的地方也要去重點測試，有些開發會很容易忽略這一點。要打開HTTPS開頭的網站，前提是該網站安裝了SSL證書，只有安裝了SSL證書的網站，並且開啟了 443 端口，你才可以通過HTTPS加密協議無訪問。如果沒有則不能訪問。
（2）前端bug主要分為3個類別：HTML,CSS,Javascript 三類問題：
一）出現文本的問題基本都是html的bug
二）出現樣式的問題基本都是CSS的bug
三）出現交互類的問題基本都是Javascript的bug
一）HTML
最常見的HTML的問題—就是標簽的問題了，最常見的排查和解決辦法就是查看頁面源代碼，然后通過檢查標簽的工具，現在暫時提供 idea.exe 進行檢查，有其他更好的工具再進行推薦。
常見問題類別：
1.標簽閉合—>>> 表象，頁面中出現大范圍的混亂，就是少了標簽的情況，導致標簽未閉合。
2.標簽浮出—>>> 例如鼠標移動到文本位置，浮出全名的這種浮出形式都屬於標簽浮出的問題。
3.標簽在不同的瀏覽器的一種解析方式的不同導致的前端bug，例如如下結構：
該部分可以看做為一個大的框即是標簽<a> 內嵌標題的標簽<p>，里面再有這些個內容<ing>，那么在不同的瀏覽器中，可能ie和FF的解析會產生不同，假設IE解析為<a><p><ing></ing></a></p>的一種形式，但在FF下可能解析為
<a><ing></ing></a>
<p></p>
的兩行的形式從而導致前端在 ing 里面的格式產生混亂。
4.頁面定點的問題->>> 最明顯的前端功能，在於點擊某個鏈接將頁面位置定位到對應的位置。
我們可以通過右鍵，查看元素的工具進行定位到毛點所定位到的位置，如果出現問題這種問題很直觀，並且能通過這種方法直接定位到問題。
5.頁面的跳轉，也屬於html的問題，大家在出現點擊未跳轉或者跳轉方式不正確的問題，直接可以定位到跳轉屬性的問題，找到對應的跳轉對應的塊提供給開發人員即可。
二）CSS，產生樣式問題。例如：排版，布局，顏色，背景等，分：
1.兼容型bug
a) 表現：僅在少數幾個瀏覽器上出現
b) 原因：瀏覽器的解析不一致
c) 解決：根據實際情況進行前端代碼的通用性
d) 類別：
腳本兼容型bug：在出現對應交互的問題就基本可以定位到腳本兼容型bug，例如 DIV 的顯示和層結構。實際可以參考聚划算的幾個商品鼠標移動到小圖的時候，對應大圖展示的功能。
頁面樣式兼容型bug：直接表象在樣式上，都是基於框架的頁面展示錯誤，很容易定位
2.業務性bug
a) 表現：在所有瀏覽器下都有該問題
b) 原因：對業務不熟悉
c) 解決：根據需求進行修改達到業務要求
d) 總結：該類型的定位，主要在和實現的要求不一致，最直接表現在頁面的友好型，用戶的可用性的bug，可以定位為該類型
3.內容型bug
a) 表現： 前端自測正確，但在填入內容后，出現的錯誤，內容消失等
b) 原因： 擴展性未考慮周全
c) 解決： 進行overflow test
d) 總結： 輸入內容的長度限制等功能可定位為內容型bug
三）Javascript
a) 最直接的判斷方法，刷新頁面，出現滯后顯示的一些模塊基本都為腳本的輸出塊。該部分的一些問題可以參照兼容型 bug 中類別的 腳本兼容型bug。
b) 有產生交互類的問題，大多數都可以定位到是屬於javascript產生的問題，該部分大多不會報錯
c) 有如下錯誤提示類的都屬於javascript的bug：
頁面左下方有出現javascript的錯誤提示；
有彈出錯誤信息提示的bug；
瀏覽器返回的一些錯誤彈出框。
7、如何精准的定位后端bug並且描述bug？
（1）根據后台日志文件定位：
1）查看報錯日志
查看報錯日志，通過日志分析，有利於幫助開發更好地定位問題，初期 bug單 可以攜帶日志一起發送指給開發。
2）查看數據庫的數據
了解所測功能的數據表結構，測試過程中，查看數據庫的數據，確認數據的正確性。
3）查看緩存（如 Memcache、apc、redis 等緩存）是否正確
（2）后端部署在liunx系統使用secureCRT進行日志獲取，常見問題分類：
1）編碼問題：tomcat是新的，需要改編碼 修改tomcat的server.xml文件<Connector port="8080" URIEncoding="UTF-8"/>，特別是windows下的項目重新部署到linux系統下。
2）空指針：程序問題，一般沒有考慮到為空情況，或者主外鍵約束的數據為空，或者刪除關聯數據，導致為空。
3）長度過長：超過最大長度，測試環境修改數據庫字段長度后生產環境未修改，導致報錯。
4）非法數據：特殊字符，是否對特殊字符進行容錯處理。
5）內存溢出：重啟。
重啟的一般情況：
1）熱部署 （新增部分功能，或者修改部分bug)
2）發布新版本 （整個系統）
3）內存溢出，此時重啟服務器即可
4）由於項目中有線程程序，./shutdown腳本關閉tomcat程序，不能把啟動的線程全部關閉，造成服務器啟動線程未關閉的錯誤。
Linux系統中重啟Tomcat的一般步驟：（一般是先關閉進程，然后進行重啟 ，如果 /要刪除某個文件：rm 文件名，或者不為空的文件夾：rm -rf 文件夾名）
cd usr/local/ //測試服務器名稱/bin
ps -exf //看測試服務器下運行的項目的主進程（最前面的數字為PID進程號）
kill -9 PID //強制關閉某一項目的主進程
./startup.sh // ./**.sh 即執行重啟shell腳本文件 ，此時在測試服務器的bin下面，直接執行即可，其余的加上 chmod a+x shell腳本文件，也可用./執行
ps aux 和 ps -ef命令區別：
ps aux 是用BSD的格式來顯示java這個進程
顯示的項目有：USER,PID,%CPU,%MEM,VSZ,RSS,TTY,STAT,START,TIME,COMMAND
ps -ef 是用標准的格式顯示java這個進程
顯示的項目有：UID,PID,PPID,C,STIME,TTY,TIME,CMD
（3）一般的問題原因總結：
1）程序：為空判斷，增刪改查,不同公眾號調用的接口也不一樣
2）數據初始化：數據庫表結構和數據初始化，權限配置，特別注意生產環境上的用戶數據修改，此時用戶在使用，很重要！！！
3）故障無法重現時：
a）看日志，根據日志定位原因，則在測試環境中按照日志提示構造條件相同的測試案例測試，嘗試在測試環境中將問題重現。
b）測試環境和配置與實際的工程環境和配置有哪些差異等等。同時主動與開發負責人、工程實施人員以及有經驗的項目經理討論，分析可能導致的原因。
c）測試環境ok，生產環境新增時保存失敗，查看后台日志報長度溢出，數據庫內容字段要求和生產環境不一致。
（4）如何查看日志（tail -f）？
一台服務器可以部署多個應用：
cd usr/local/測試服務器名稱/logs//查看先進入到服務器的logs目錄下
tail -f catalina.out//監視catalina.out 文件的尾部內容（默認10行）
（5）輔助工具：linux和SQL
linux查看日志
SQL用來篩選數據或直接進行數據修改狀態，多用於集成測試過程中前后流程相連接
8、瀏覽器兼容性和網頁規范標准測試
瀏覽器兼容性測試（偏主流瀏覽器，如谷歌，火狐，IE8以上）：
https://dev.windows.com/en-us/microsoft-edge/tools/staticscan/
W3C網頁驗證：（判斷網頁書寫是否符合規范，記住此處必須去掉權限控制，單個單元頁面url需要跟參數）
https://validator.w3.org/
W3C手機端頁面檢測（如手機微信菜單下的頁面）：
https://validator.w3.org/mobile-alpha/
9、互聯網與傳統測試互聯網測試與傳統測試的區別
（1）最大的不同：互聯網產品需要自己部署和運營，用戶使用瘦客戶端（瀏覽器，app或一個需要安裝的client)，核心的數據和業務邏輯在互聯網公司的機房，在IDC，在雲端。
如：我們做的系統用戶只需一個瀏覽器，服務器用的阿里雲，部署和運營只需要一個運維人員即可。
考慮現網（生產環境）存在下面兩個問題：
1）如何發布功能到現網？
互聯網測試完一般可直接發布，測試周期短，有時候需要進行灰度發布，先讓部分用戶用起來，發布完做生產驗證。
2）如何保證測試環境和生產環境同步？
測試環境比較難搞，牽扯的系統平台比較多，用到很多微信平台的接口，這個很難自己搭建或者用mock。
另外保證測試環境和到生產環境都是好的，需要代碼和數據庫，以及環境配置都要保持一致，這需要相應的機制和工具來驗證和同步。
（2）互聯網產品節奏很快
有的軟件公司，基本是進行二次開發，周期長，每次都需要經過下面幾個完整的測試流程：
客戶提出需求>>>BA和客戶溝通，確定出需求和解決方案>>>測試人員根據需求說明書和解決方案編寫測試用例>>>進行概要評審>>>進行詳細設計評審>>>開始測試>>>回歸測試>>>生產驗證。
現在的互聯網產品測試基本為：
產品經理確定好測試需求>>>開發人員寫詳設>>>（此階段可以進行設計bug檢查）>>>開發人員開發>>>測試人員測試，上線
弊端：來不及測試設計，來不及自動化，短時間內如何保證測試的覆蓋率和質量？>>>（探索式測試應勢而生）
（3）更多的人參與到測試中
互聯網公司有專門的測試團隊的比較少，一般開發和測試比例： 7:1，如何保證質量？
1）開發人員的自測
開發人員進行單元測試，測試用例的通過率，同一個版本拉代碼的次數
2）產品或運營人員的體驗
在這里基本我就相當於用戶，進行產品體驗，或者根據免費試用者反饋的意見進行優化
3）發布之前的評審
注意環境，配置，數據方面的問題
（4）有一些是免測試的
並不是所有發布到生產環境的東西都需要在測試環境檢驗，如：圖片樣式改動，小bug修復，但是哪些免測是個復雜的問題
（5）海量用戶帶來的挑戰
1）性能方面
如何做輕量級的性能測試
2）瀏覽器的兼容性
現在的系統大多基於主流的火狐，谷歌，IE8以上，放棄瀏覽器兼容就等於放棄一部分客戶。
（6）測試工具和技術方面
傳統的企業花錢購買商業軟件，如QTP，loadrunner，或者自己開發的項目管理工具
大部分的互聯網公司使用開源或自主研發的，如 selenium，appium，robotium,monkeyrunner,jmeter
相同點：
1.都需要非常熟悉產品和業務
2.都需要了解產品的技術（深度測試方面性能分析，內存泄露，web服務器，cache，代理)
3.具體的測試技術
4.測試設計的方法
5.測試人員的技術體系