前端和後臺BUG區分方法

測試工程師不僅是負責發現問題，除了發現問題這種基本功外，定位問題，提出解決方案，提出預防方案也是要掌握的技能。這裏先說定位問題的要求，定位問題要向深刻，前提固然是對功能、產品的流程、開發方案、開發人員很是熟悉了，以咱們部門爲例，定位bug至少要到下面這種程度。 　　首先肯定是界面顯示問題仍是功能問題， 　　若是是界面問題，如貼圖錯誤，文字錯誤，樣式錯誤，則須要截圖 　　若是是功能問題： 　　控制檯的問題至少定位到：www的問題仍是數據庫問題，若是是www問題至少要定位到是前端仍是後端問題；若是是數據庫問題至少要定位到是服務端接口問題仍是中間件問題 　　客戶端的問題至少定位到：哪一個dll模塊或者邏輯出的問題 　　服務端的問題至少定位到：什麼接口出的問題，致使數據庫哪裏不對 　　另外， 　　1）測試時不要全按照用例走，要多發散思惟 　　2）測試時要儘可能考慮得更全面，把一些多用戶多終端或其餘極端的狀況都考慮到。 　　最後， 　　跟進重點問題的修改進度和方案，詢問開發時如何修改的，反思開發的修改方案是否存在漏洞。 　　爲什麼要學會區分前端和後臺BUG？ 　　若是是一個多人開發的系統，不能明肯定位到這個bug是誰形成的，容易提交給錯誤的開發人員，因而bug會像皮球同樣被開發踢來踢去，耽誤開發解決bug的時間。 　　即使提交給對的開發，開發也未必能查到bug產生的緣由和代碼有問題的地方，所以不必定能修復bug，每每修改了本身認爲可能有問題的地方，而後測試發現還有問題，繼續發回給開發，開發繼續查，來來回回耽誤解決bug的時間。 　　再退一步來講，若是開發水平很高，沒有1和2的問題，對於測試來講也很容易提交重複的bug，由於可能不少bug都是因爲一個地方引發的，只是表現出問題不同，但本質倒是同樣的，這樣也是耽誤了測試時間。 　　固然能遇到的遠遠不止以上3種狀況，因此對於測試來講僅僅提交bug是不夠的，不管對於測試自身的提升積累，仍是對於項目進度推動都是很是重要的。 　　要怎麼樣才能定位bug呢？ 　　當bug出現時，通常來講分大體3種狀況， 　　數據庫層面的：可能少某個字段，或者字段值爲空等等，這些可能在設計數據庫時就埋下了錯誤的種子，致使程序調用數據庫錯誤的數據產生bug，這一類問題不算廣泛，但也是最容易忽視的一種狀況，有時候從數據庫入手定位bug說不定還能發現數據庫的設計缺陷呢。 　　網絡層面的：一般這種都是網絡狀況較差的時候產生的，好比手機的移動網絡信號很差，又或是公司網絡不穩定，致使js/css未加載徹底或者請求超時等等，這種問題其實非程序bug形成的，能夠不用提交bug，也不用讓開發毫無頭緒的去查代碼的問題。固然若是能夠的話也能夠當優化建議提給開發，讓他優化代碼，好比壓縮js/css，增長超時時間，超時後的重試機制。 　　代碼層面的：廣泛的bug基本都是代碼有問題形成的，排除掉1和2剩下後就能夠肯定是程序bug了。對於瞭解網絡架構的人來講，其實程序也分前端和後端的，通常對於界面顯示有問題直接能夠判斷是前端的問題，好比系統兼容性，瀏覽器兼容性。 　　而對於數據或者邏輯上的問題，則須要（檢查接口）前端和後臺之間是經過接口文件相互聯繫的，經過抓包工具來進行分析 ： 　　1）請求未返回數據，多是client（客戶端）請求數據錯誤，多是server端處理錯誤。 　　2）請求返回錯誤的數據，那就是server端（服務器端）處理錯誤。 　　3）請求返回正確的數據，那就是前端處理server端（服務器端）返回數據有錯誤 　　定位bug就像這樣抽絲剝繭一層層排除，從而把最後剩下的可能性給找出來，說難其實也不難，但須要有足夠的邏輯思惟能力來推斷，也須要足夠的耐心去尋找bug的根源。 　　什麼是前端和後臺？ 　　經常說到的一個IT項目，包括前端開發，後臺開發，軟件測試，架構，項目經理，產品需求。那麼對於一位優秀的軟件測試工程師來講，須要區分前端和後臺的工做就顯得尤其重要。 　　簡而言之，前端通常是指界面的設計居多，他們每每須要調用後臺的一個接口，進行一個HTTP請求，根據後臺反饋回來的數據，渲染到頁面上。從而實現按鈕（若是前端只是畫了頁面，接口未調試，點擊頁面按鈕是無反應的），數據顯示的正常。 　　測試工程師如何區分前端和後臺的BUG----------- 前臺的bug一般是功能、界面和兼容性等有關；後臺的bug與邏輯、性能和安全性有關。與數據相關的錯誤、排序問題大可能是後臺問題，對於APP頁面toast提示多是後臺給的，多是APP給的 　　一、檢查接口 　　前端和後臺之間是經過接口文件相互聯繫的，一樣，測試人員也是能夠看到這個一接口文件，不少人覺得，這一點都不重要，那你大錯特錯了。由於這是區分前端和後臺bug的關鍵。 　　二、狀況分析 　　a、檢查請求的數據是什麼，反饋的數據又是什麼 　　能夠經過抓包工具來進行抓包分析。 　　大多數的瀏覽器都有自帶的抓包插件，如FireFox的FireBug插件，Chrome、360急速模式、搜狗高速模式自帶的DevelopTools插件，F12開啓抓包後，在NetWork中能夠看到當前頁面發送的每個http請求。 　　一般狀況下，咱們能夠經過請求接口、傳參和響應三部分來判斷Bug，另外，也能夠在瀏覽器的控制檯進行代碼調試定位。 　　（1）請求接口URL是否正確 　　若是請求接口URL不正確，爲前端Bug； 　　（2）http請求中的參數是否正確 　　若是http請求中的參數不正確，爲前端Bug； 　　（3）若是接口URL和參數都正確，查看響應內容是否正確 　　若是這種狀況下響應內容不正確，則爲後端Bug。 　　（4）若是JS基礎比較好的話，也能夠在瀏覽器的控制檯中輸入JS代碼進行調試 　　HTTP請求中，若是是get請求，那麼表單參數以name=value&name1=value1的形式附到url的後面，若是是post請求，那麼表單參數是在請求體中，也是以name=value&name1=value1的形式在請求體中。經過chrome的開發者工具能夠看到以下（這裏是可讀的形式，不是真正的HTTP請求協議的請求格式）： 　　get請求： RequestURL:http://127.0.0.1:8080/test/test.do?name=mikan&address=street -------請求參數 　　Request Method:GET 　　Status Code:200 OK 　　Request Headers 　　Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 　　Accept-Encoding:gzip,deflate,sdch 　　Accept-Language:zh-CN,zh;q=0.8,en;q=0.6 　　AlexaToolbar-ALX_NS_PH:AlexaToolbar/alxg-3.2 　　Connection:keep-alive 　　Cookie:JSESSIONID=74AC93F9F572980B6FC10474CD8EDD8D 　　Host:127.0.0.1:8080 　　Referer:http://127.0.0.1:8080/test/index.jsp 　　User-Agent:Mozilla/5.0 (Windows NT 6.1)AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.149 Safari/537.36 　　Query String Parameters 　　name:mikan 　　address:street 　　Response Headers 　　Content-Length:2 　　Date:Sun, 11 May 2014 10:42:38 GMT 　　Server:Apache-Coyote/1.1 　　Post請求： RequestURL:http://127.0.0.1:8080/test/test.do 　　Request Method:POST 　　Status Code:200 OK 　　Request Headers 　　Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 　　Accept-Encoding:gzip,deflate,sdch 　　Accept-Language:zh-CN,zh;q=0.8,en;q=0.6 　　AlexaToolbar-ALX_NS_PH:AlexaToolbar/alxg-3.2 　　Cache-Control:max-age=0 　　Connection:keep-alive 　　Content-Length:25 　　Content-Type:application/x-www-form-urlencoded 　　Cookie:JSESSIONID=74AC93F9F572980B6FC10474CD8EDD8D 　　Host:127.0.0.1:8080 　　Origin:http://127.0.0.1:8080 　　Referer:http://127.0.0.1:8080/test/index.jsp 　　User-Agent:Mozilla/5.0 (Windows NT 6.1)AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.149 Safari/537.36 　　Form Data--------其中顯示請求的參數 　　name:mikan 　　address:street 　　Response Headers 　　Content-Length:2 　　Date:Sun, 11 May 2014 11:05:33 GMT 　　Server:Apache-Coyote/1.1 　　這裏要注意post請求的Content-Type爲application/x-www-form-urlencoded，參數是在請求體中，即上面請求中的Form Data。 　　經過chrome的開發者工具看到請求頭以下： RequestURL:http://127.0.0.1:8080/test/test.do 　　Request Method:POST 　　Status Code:200 OK 　　Request Headers 　　Accept:*/* 　　Accept-Encoding:gzip,deflate,sdch 　　Accept-Language:zh-CN,zh;q=0.8,en;q=0.6 　　AlexaToolbar-ALX_NS_PH:AlexaToolbar/alxg-3.2 　　Connection:keep-alive 　　Content-Length:28 　　Content-Type:text/plain;charset=UTF-8 　　Cookie:JSESSIONID=C40C7823648E952E7C6F7D2E687A0A89 　　Host:127.0.0.1:8080 　　Origin:http://127.0.0.1:8080 　　Referer:http://127.0.0.1:8080/test/index.jsp 　　User-Agent:Mozilla/5.0 (Windows NT 6.1)AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.149 Safari/537.36 　　Request Payload-------其中顯示參數 　　name=mikan&address=street 　　Response Headers 　　Content-Length:2 　　Date:Sun, 11 May 2014 11:49:23 GMT 　　Server:Apache-Coyote/1.1 　　注意請求的Content-Type爲text/plain;charset=UTF-8，而請求表單參數在RequestPayload中。 　　下面是後臺響應參數， 　　b、根據接口的文件，檢查數據是否正確，至於如何分析，這個就看我的的基礎了，若是發送的數據是正確的，可是後臺反饋的數據是不符合需求的，那就是後臺的問題；若是前端沒有請求接口，或者請求的時候發送數據與需求不符，那這個時候就是前端的問題了。總而言之，這種狀況不少，須要各位本身多多總結經驗。一位優秀的測試開發工程師，固然也離不開好的編程基礎。 　　前臺bug定位：按F12在console中查看報錯信息，對於出錯的js能夠在Sources下查看對應報錯的資源文件，寫入禪道提交給開發便可 　　2.後端的Bug，如何準確的定位問題在哪裏，如何精準的描述Bug？ 　　（1）查看報錯日誌 　　查看報錯日誌，經過日誌分析，須要有必定的經驗，而且有必定的代碼基礎，才能更好地定位問題。 　　（2）查看數據庫的數據 　　瞭解所測功能的數據表結構，測試過程當中，查看數據庫的數據，確認數據的正確性。 　　（3）查看緩存（如Memcache、apc、redis等緩存）是否正確 　　如今來分析bug多是前臺仍是後臺： 　　case1：文本框輸入不合法的內容，點擊提交按鈕， 若是不合法的內容提交成功， 那應該是先後臺沒有作校驗， 先後臺都有這個bug 　　case2：文本框輸入合法的內容，點擊提交按鈕， 查看數據庫中的數據和輸入的內容不一致， 這個時候須要看前臺傳的數據是否正確，使用fiddler抓包， 查看請求頭裏面的數據是否和輸入一致，若是一致就是後臺的問題， 若是不一致，就是前臺的bug 　　case3：界面展現不友好， 重複提交 這些都是前臺的bug 　　前臺定位方法： 　　前臺bug定位：按F12在console中查看報錯信息，對於出錯的js能夠在Sources下查看對應報錯的資源文件，寫入禪道提交給開發便可 　　前臺bug注意如下三個方面： 　　（1）網站前臺的權限控制：沒有權限的用戶是不能直接輸入url的方式來進行訪問的，必須進行登陸。之後涉及到權限的測試，必定不能漏掉url的方式也須要驗證一下。而在單個頁面進行W3C測試時則須要去掉該權限控制。 　　（2）網站前臺的title，對於這個也很容易忽視。進入到不一樣的功能頁面，title顯示應該是有，而且要和你進入的頁面一致。title就是在瀏覽器最左上角看到的那些文字 　　（3）http和https的注意點：https是一種安全連接，它是須要證書的，而http就是普通連接，因此在你的系統中客戶會要求某些關鍵的地方但願加上這種安全鏈接，那麼此時你須要注意的是，對於不須要的安全連接的地方千萬也要去重點測試，有些開發會很容易忽略這一點。 　　你要打開HTTPS開頭的網站，前提是該網站安裝了SSL證書，只有安裝了SSL證書的網站，而且開啓了443端口，你才能夠經過HTTPS加密協議無訪問。若是沒有則不能訪問。 　　你可要測試，好比在某個網站http協議後面加個s去訪問，看可否訪問成功，能成功，會顯示綠色安全小鎖，不然就不能訪問。給你舉幾個安裝了ssl證書，可要https訪問的網站，1號店，天貓，淘寶，支付寶，百度，沃通CA，工信部網站等等 　　前端bug主要分爲3個類別：HTML,CSS,Javascript三類問題 　　給個最大的區別方式方法： 　　出現樣式的問題基本都是CSS的bug 　　出現文本的問題基本都是html的bug 　　出現交互類的問題基本都是Javascript的bug 　　如今以淘寶的前端人員工做爲例進行相關bug定位的剖析 　　判斷先後臺問題的區分方法： 　　F12, 打開錯誤控制檯console 　　區分先後臺交互：查看網絡請求 　　a) Html中若是有連接，有相應的狀況下，基本能夠定位到是屬於前端的問題 　　b) 若是爲空，或者有出現error錯誤信息，咱們就能夠定位到屬於後臺開發的問題 　　TMS對應的VM模板，出現的一些截斷控制，轉換功能都屬於前端的問題 　　1、HTML 　　最多見的HTML的問題—就是標籤的問題了，最多見的排查和解決辦法就是查看頁面源代碼，而後經過檢查標籤的工具，如今暫時提供idea.exe進行檢查，有其餘更好的工具再進行推薦。 　　常見問題類別： 　　標籤閉合—表象，頁面中出現大範圍的混亂，就是少了標籤的狀況，致使標籤未閉合 　　標籤浮出—例如鼠標移動到文本位置，浮出全名的這種浮出形式都屬於標籤浮出的問題 　　標籤在不一樣的瀏覽器的一種解析方式的不一樣致使的前端bug例如以下結構 　　該部分能夠看作爲一個大的框便是標籤 內嵌標題的標籤

，裏面再有這些個內容 ,那麼在不一樣的瀏覽器中，可能ie和FF的解析會產生不一樣，假設IE解析爲

的一種形式，但在FF下可能解析爲 　　 　　 　　的兩行的形式從而致使前端在復古鞋/板鞋這塊ing裏面的格式產生混亂 　　結構可看爲： 　　頁面定點的問題：最明顯的前端功能，在於點擊某個連接將頁面位置定位到對應的位置 　　a) 咱們能夠經過右鍵，查看元素的工具進行定位到毛點所定位到的位置，若是出現問題這種問題很直觀，而且能經過這種方法直接定位到問題 　　頁面的跳轉，也屬於html的問題，你們在出現點擊未跳轉或者跳轉方式不正確的問題，直接能夠定位到跳轉屬性的問題，找到對應的跳轉對應的塊提供給開發人員便可 　　2、CSS，產生樣式問題。例如：排版，佈局，顏色，背景等 　　css的bug主要分爲：兼容型bug 、業務性bug 和 內容型bug 　　兼容型bug 　　a) 表現：僅在少數幾個瀏覽器上出現 　　b) 緣由：瀏覽器的解析不一致 　　c) 解決：根據實際狀況進行前端代碼的通用性 　　d) 類別： 　　腳本兼容型問題：在出現對應交互的問題就基本能夠定位到腳本兼容型bug，例如DIV的顯示和層結構。實際能夠參考聚划算的幾個商品鼠標移動到小圖的時候，對應大圖展現的功能。 　　頁面樣式兼容型問題：直接表象在樣式上，都是基於框架的頁面展現錯誤，很容易定位 　　業務性bug 　　a) 表現：在全部瀏覽器下都有該問題 　　b) 緣由：對業務不熟悉 　　c) 解決：根據需求進行修改達到業務要求 　　該類型的定位，主要在和實現的要求不一致，最直接表如今頁面的友好型，用戶的可用性的bug，能夠定位爲該類型 　　內容型bug 　　a) 表現： 前端自測正確，但在填入內容後，出現的錯誤，內容消失等 　　b) 緣由： 擴展性未考慮周全 　　c) 解決： 進行overflow test 　　輸入內容的長度限制等功能可定位爲內容型bug 　　3、Javascript 　　最直接的判斷方法，刷新頁面，出現滯後顯示的一些模塊基本都爲腳本的輸出塊。該部分的一些問題能夠參照兼容型bug中類別的腳本兼容型bug。 　　有產生交互類的問題，大多數均可以定位到是屬於javascript產生的問題，該部分大多不會報錯 　　有錯誤提示類的。頁面左下方有出現javascript的錯誤提示；有彈出錯誤信息提示的bug；瀏覽器返回的一些錯誤彈出框都屬於javascript的bug 　　後臺bug定位：根據後臺日誌文件 　　系統使用secureCRT進行日誌獲取 　　(1)編碼問題：tomcat是新的，須要改編碼 修改tomcat的server.xml文件 　　特別是windows下的項目從新部署到linux系統下， 　　(2)空指針：程序問題，通常沒有考慮到爲空狀況，或者主外鍵約束的數據爲空，或者刪除關聯數據，致使爲空 　　(3)長度過長，超過最大長度，測試環境修改數據庫字段長度後生產環境未修改，致使報錯！！ 　　(4)非法數據： 　　(5)內存溢出：重啓 　　系統使用secureCRT進行日誌獲取，或者服務器控制方面的操做（關閉和重啓） 　　重啓的通常狀況： 　　1）熱部署 （新增部分功能，或者修改部分bug) 　　2）發佈新版本 （整個系統） 　　3）內存溢出，此時重啓服務器便可 　　因爲項目中有線程程序，./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.如何查看日誌？ 　　一臺服務器能夠部署多個應用： 　　cd usr/local/測試服務器名稱/logs //查看先進入到服務器的logs目錄下 　　tail -f catalina.out //監視catalina.out 文件的尾部內容（默認10行） 　　4.日誌中常見的問題 　　獲取日誌文件中常遇到的問題： 　　1)編碼問題：tomcat是新的，須要改編碼 修改tomcat的server.xml文件 　　特別是windows下的項目從新部署到linux系統下， 　　2)空指針：程序問題，通常沒有考慮到爲空狀況，或者主外鍵約束的數據爲空，或者刪除關聯數據，致使爲空 　　3)長度過長，超過最大長度，測試環境修改數據庫字段長度後生產環境未修改，致使報錯！！ 　　4)非法數據： 　　5)內存溢出：重啓 　　5.通常的問題緣由總結： 　　程序：爲空判斷，增刪改查,不一樣公衆號調用的接口也不同 　　數據初始化：數據庫表結構和數據初始化，權限配置， 　　特別注意生產環境上的用戶數據修改，此時用戶在使用，很重要！！！ 　　故障沒法重現時： 　　1）看日誌，根據日誌定位緣由，則在測試環境中按照日誌提示構造條件相同的測試案例測試，嘗試在測試環境中將問題重現。 　　2）測試環境和配置與實際的工程環境和配置有哪些差別等等。同時主動與開發負責人、工程實施人員以及有經驗的項目經理討論，分析可能致使的緣由。 　　測試環境ok，生產環境新增時保存失敗，查看後臺日誌報長度溢出，數據庫內容字段要求和生產環境不一致！！ 　　6.輔助工具：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.測試人員的技術體系： 　　實戰 　　圖中參數city code 爲空此時不該該爲空，爲空就可能致使前端看不到該數據 　　後臺返回的一條數據沒有----後臺BUG