知識分享---如何區分前端與後端bug

一、如何區分前端和後端

通俗講，用戶看到的部分都叫前端。

而用戶看不到的部分能夠統稱爲後端。

 

二、前端和後端的呈現形式

前端的呈現形式有web端、移動端（ios、安卓）、小程序等。

後端系統通常只有一個，收集不一樣前端反饋回來的數據。

 

三、前端和後端工做內容的差異

前端主要是考慮怎樣能讓用戶以爲用起來更舒服，考慮界面佈局、交互效果、頁面加載速度等。

後端更多的是與數據庫進行交互以處理相應的業務邏輯。須要考慮的是如何實現功能、數據的存取、平臺的穩定性與性能等。

 

四、如何分析bug（bug類型）

當bug出現時，通常來講分大體3種狀況：

（1）數據庫層面的：

可能少某個字段，或者字段值爲空等等，這些可能在設計數據庫時就埋下了錯誤的種子，致使程序調用數據庫錯誤的數據產生bug，這一類問題不算廣泛，但也是最容易忽視的一種狀況，有時候從數據庫入手定位bug說不定還能發現數據庫的設計缺陷。

（2）網絡層面的：

一般這種都是網絡狀況較差的時候產生的，好比手機的移動網絡信號很差，又或是公司網絡不穩定，致使js/css未加載徹底或者請求超時等等，這種問題其實非程序bug形成的，能夠不用提交bug，也不用讓開發毫無頭緒的去查代碼的問題。固然若是能夠的話也能夠當優化建議提給開發，讓他優化代碼，好比壓縮js/css，增長超時時間，超時後的重試機制。

（3）代碼層面的：

廣泛的bug基本都是代碼有問題形成的，排除掉1和2剩下後就能夠肯定是程序bug了。對於瞭解網絡架構的人來講，其實程序也分前端和後端的，通常對於界面顯示有問題直接能夠判斷是前端的問題，好比系統兼容性，瀏覽器兼容性。

而對於數據或者邏輯上的問題，則須要（檢查接口）前端和後臺之間是經過接口文件相互聯繫的，經過抓包工具來進行分析 ：

1）請求未返回數據，多是client（客戶端）請求數據錯誤，多是server端（服務器端）處理錯誤。

2）請求返回錯誤的數據，那就是server端處理錯誤。

 

五、如何區分前端問題和後端問題

前臺的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、根據接口的文件，檢查數據是否正確。

若是發送的數據是正確的，可是後臺反饋的數據是不符合需求的，那就是後臺的問題。

若是前端沒有請求接口，或者請求的時候發送數據與需求不符，那這個時候就是前端的問題了。

 

六、如何精準的定位前臺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；

瀏覽器返回的一些錯誤彈出框。

 

七、如何精準的定位後端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用來篩選數據或直接進行數據修改狀態，多用於集成測試過程當中先後流程相鏈接

 

八、瀏覽器兼容性和網頁規範標準測試

瀏覽器兼容性測試（偏主流瀏覽器，如谷歌，火狐，IE8以上）：

https://dev.windows.com/en-us/microsoft-edge/tools/staticscan/

W3C網頁驗證：（判斷網頁書寫是否符合規範，記住此處必須去掉權限控制，單個單元頁面url須要跟參數）

https://validator.w3.org/

　　W3C手機端頁面檢測（如手機微信菜單下的頁面）：

https://validator.w3.org/mobile-alpha/

 

九、互聯網與傳統測試互聯網測試與傳統測試的區別

（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.測試人員的技術體系