測試工程師不只是負責發現問題，除了發現問題這種基本功外，定位問題，提出解決方案，提出預防方案也是要掌握的技能。這裏先說定位問題的要求，定位問題要向深入，前提當然是對功能、產品的流程、開發方案、開發人員非常熟悉了，以我們部門爲例，定位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給的
1、檢查接口
前端和後臺之間是通過接口文件相互聯繫的，同樣，測試人員也是可以看到這個一接口文件，很多人以爲，這一點都不重要，那你大錯特錯了。因爲這是區分前端和後臺bug的關鍵。
2、情況分析
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模板，出現的一些截斷控制，轉換功能都屬於前端的問題
一、HTML
最常見的HTML的問題—就是標籤的問題了，最常見的排查和解決辦法就是查看頁面源代碼，然後通過檢查標籤的工具，現在暫時提供idea.exe進行檢查，有其他更好的工具再進行推薦。
常見問題類別：
標籤閉合—表象，頁面中出現大範圍的混亂，就是少了標籤的情況，導致標籤未閉合
標籤浮出—例如鼠標移動到文本位置，浮出全名的這種浮出形式都屬於標籤浮出的問題
標籤在不同的瀏覽器的一種解析方式的不同導致的前端bug例如如下結構
該部分可以看做爲一個大的框即是標籤<a> 內嵌標題的標籤<p>，裏面再有這些個內容<ing>,那麼在不同的瀏覽器中，可能ie和FF的解析會產生不同，假設IE解析爲<a><p><ing></ing></a></p>的一種形式，但在FF下可能解析爲
<a><ing></ing></a>
<p></p>
的兩行的形式從而導致前端在復古鞋/板鞋這塊ing裏面的格式產生混亂
結構可看爲：
頁面定點的問題：最明顯的前端功能，在於點擊某個鏈接將頁面位置定位到對應的位置
a) 我們可以通過右鍵，查看元素的工具進行定位到毛點所定位到的位置，如果出現問題這種問題很直觀，並且能通過這種方法直接定位到問題
頁面的跳轉，也屬於html的問題，大家在出現點擊未跳轉或者跳轉方式不正確的問題，直接可以定位到跳轉屬性的問題，找到對應的跳轉對應的塊提供給開發人員即可
二、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
三、Javascript
最直接的判斷方法，刷新頁面，出現滯後顯示的一些模塊基本都爲腳本的輸出塊。該部分的一些問題可以參照兼容型bug中類別的腳本兼容型bug。
有產生交互類的問題，大多數都可以定位到是屬於javascript產生的問題，該部分大多不會報錯
有錯誤提示類的。頁面左下方有出現javascript的錯誤提示；有彈出錯誤信息提示的bug；瀏覽器返回的一些錯誤彈出框都屬於javascript的bug
後臺bug定位：根據後臺日誌文件
系統使用secureCRT進行日誌獲取
(1)編碼問題：tomcat是新的，需要改編碼 修改tomcat的server.xml文件<Connector port="8080" URIEncoding="UTF-8"/>
特別是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文件<Connector port="8080" URIEncoding="UTF-8"/>
特別是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