前端和后台BUG區分方法

 

測試工程師不只是負責發現問題，除了發現問題這種基本功外，定位問題，提出解決方案，提出預防方案也是要掌握的技能。這里先說定位問題的要求，定位問題要向深入，前提當然是對功能、產品的流程、開發方案、開發人員非常熟悉了，以我們部門為例，定位bug至少要到下面這種程度。

首先確定是界面顯示問題還是功能問題，

　　如果是界面問題，如貼圖錯誤，文字錯誤，樣式錯誤，則需要截圖

　如果是功能問題：

　　控制台的問題至少定位到：www的問題還是數據庫問題，如果是www問題至少要定位到是前端還是后端問題；如果是數據庫問題至少要定位到是服務端接口問題還是中間件問題

　　客戶端的問題至少定位到：哪個dll模塊或者邏輯出的問題

　　服務端的問題至少定位到：什么接口出的問題，導致數據庫哪里不對

另外，

1）測試時不要全按照用例走，要多發散思維

2）測試時要盡量考慮得更全面，把一些多用戶多終端或其他極端的情況都考慮到。

　最后，

　　跟進重點問題的修改進度和方案，詢問開發時如何修改的，反思開發的修改方案是否存在漏洞。

 

 

 

 

 

 

 

 

 

 

 

為何要學會區分前端和后台BUG？

 

1. 如果是一個多人開發的系統，不能明確定位到這個bug是誰造成的，容易提交給錯誤的開發人員，於是bug會像皮球一樣被開發踢來踢去，耽誤開發解決bug的時間。

2. 即便提交給對的開發，開發也未必能查到bug產生的原因和代碼有問題的地方，因此不一定能修復bug，往往修改了自己認為可能有問題的地方，然后測試發現還有問題，繼續發回給開發，開發繼續查，來來回回耽誤解決bug的時間。

3. 再退一步來說，如果開發水平很高，沒有1和2的問題，對於測試來說也很容易提交重復的bug，因為可能很多bug都是由於一個地方引起的，只是表現出問題不一樣，但本質卻是一樣的，這樣也是耽誤了測試時間。

    

當然能遇到的遠遠不止以上3種情況，所以對於測試來說僅僅提交bug是不夠的，無論對於測試自身的提高積累，還是對於項目進度推進都是非常重要的。

 

要怎么樣才能定位bug呢？

 

當bug出現時，一般來說分大致3種情況，

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

2. 網絡層面的：通常這種都是網絡情況較差的時候產生的，比如手機的移動網絡信號不好，又或是公司網絡不穩定，導致js/css未加載完全或者請求超時等等，這種問題其實非程序bug造成的，可以不用提交bug，也不用讓開發毫無頭緒的去查代碼的問題。當然如果可以的話也可以當優化建議提給開發，讓他優化代碼，比如壓縮js/css，增加超時時間，超時后的重試機制。

3. 代碼層面的：普遍的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三類問題

給個最大的區別方式方法：

1. 出現樣式的問題基本都是CSS的bug
2. 出現文本的問題基本都是html的bug
3. 出現交互類的問題基本都是Javascript的bug

現在以淘寶的前端人員工作為例進行相關bug定位的剖析

判斷前后台問題的區分方法：

F12, 打開錯誤控制台console

1. 區分前后台交互：查看網絡請求

a) Html中如果有鏈接，有相應的情況下，基本可以定位到是屬於前端的問題

b) 如果為空，或者有出現error錯誤信息，我們就可以定位到屬於后台開發的問題

1. TMS對應的VM模板，出現的一些截斷控制，轉換功能都屬於前端的問題

一、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里面的格式產生混亂

結構可看為：

1. 頁面定點的問題：最明顯的前端功能，在於點擊某個鏈接將頁面位置定位到對應的位置

a) 我們可以通過右鍵，查看元素的工具進行定位到毛點所定位到的位置，如果出現問題這種問題很直觀，並且能通過這種方法直接定位到問題

1. 頁面的跳轉，也屬於html的問題，大家在出現點擊未跳轉或者跳轉方式不正確的問題，直接可以定位到跳轉屬性的問題，找到對應的跳轉對應的塊提供給開發人員即可

二、CSS，產生樣式問題。例如：排版，布局，顏色，背景等

css的bug主要分為：兼容型bug 、業務性bug 和 內容型bug

1. 兼容型bug

a) 表現：僅在少數幾個瀏覽器上出現

b) 原因：瀏覽器的解析不一致

c) 解決：根據實際情況進行前端代碼的通用性

d) 類別：

1. 腳本兼容型問題：在出現對應交互的問題就基本可以定位到腳本兼容型bug，例如DIV的顯示和層結構。實際可以參考聚划算的幾個商品鼠標移動到小圖的時候，對應大圖展示的功能。
2. 頁面樣式兼容型問題：直接表象在樣式上，都是基於框架的頁面展示錯誤，很容易定位
3. 業務性bug

a) 表現：在所有瀏覽器下都有該問題

b) 原因：對業務不熟悉

c) 解決：根據需求進行修改達到業務要求

該類型的定位，主要在和實現的要求不一致，最直接表現在頁面的友好型，用戶的可用性的bug，可以定位為該類型

1. 內容型bug

a) 表現： 前端自測正確，但在填入內容后，出現的錯誤，內容消失等

b) 原因： 擴展性未考慮周全

c) 解決： 進行overflow test

輸入內容的長度限制等功能可定位為內容型bug

三、Javascript

最直接的判斷方法，刷新頁面，出現滯后顯示的一些模塊基本都為腳本的輸出塊。該部分的一些問題可以參照兼容型bug中類別的腳本兼容型bug。

1. 有產生交互類的問題，大多數都可以定位到是屬於javascript產生的問題，該部分大多不會報錯
2. 有錯誤提示類的。頁面左下方有出現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