2023年6月27日发(作者：)

前端和后台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、急速模式、搜狗⾼速模式⾃带的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:127.0.0.1:8080/test/?name=mikan&address=street -------请求参数Request Method:GETStatus Code:200 OKRequest HeadersAccept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8Accept-Encoding:gzip,deflate,sdchAccept-Language:zh-CN,zh;q=0.8,en;q=0.6AlexaToolbar-ALX_NS_PH:AlexaToolbar/alxg-3.2Connection:keep-aliveCookie:JSESSIONID=74AC93F9F572980B6FC10474CD8EDD8DHost:127.0.0.1:8080Referer:127.0.0.1:8080/test/r-Agent:Mozilla/5.0 (Windows NT 6.1)AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.149 Safari/537.36Query String Parametersname:mikanaddress:streetResponse HeadersContent-Length:2Date:Sun, 11 May 2014 10:42:38 GMTServer:Apache-Coyote/1.1Post请求：RequestURL:127.0.0.1:8080/test/est Method:POSTStatus Code:200 OKRequest HeadersAccept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8Accept-Encoding:gzip,deflate,sdchAccept-Language:zh-CN,zh;q=0.8,en;q=0.6AlexaToolbar-ALX_NS_PH:AlexaToolbar/alxg-3.2Cache-Control:max-age=0Connection:keep-aliveContent-Length:25Content-Type:application/x-www-form-urlencodedCookie:JSESSIONID=74AC93F9F572980B6FC10474CD8EDD8DHost:127.0.0.1:8080Origin:127.0.0.1:8080Referer:127.0.0.1:8080/test/r-Agent:Mozilla/5.0 (Windows NT 6.1)AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.149 Safari/537.36Form Data--------其中显⽰请求的参数name:mikanaddress:streetResponse HeadersContent-Length:2Date:Sun, 11 May 2014 11:05:33 GMTServer:Apache-Coyote/1.1这⾥要注意post请求的Content-Type为application/x-www-form-urlencoded，参数是在请求体中，即上⾯请求中的Form Data。

通过chrome的开发者⼯具看到请求头如下：RequestURL:127.0.0.1:8080/test/est Method:POSTStatus Code:200 OKRequest HeadersAccept:*/*Accept-Encoding:gzip,deflate,sdchAccept-Language:zh-CN,zh;q=0.8,en;q=0.6AlexaToolbar-ALX_NS_PH:AlexaToolbar/alxg-3.2Connection:keep-aliveContent-Length:28Content-Type:text/plain;charset=UTF-8Cookie:JSESSIONID=C40C7823648E952E7C6F7D2E687A0A89Host:127.0.0.1:8080Origin:127.0.0.1:8080Referer:127.0.0.1:8080/test/r-Agent:Mozilla/5.0 (Windows NT 6.1)AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.149 Safari/537.36Request Payload-------其中显⽰参数name=mikan&address=streetResponse HeadersContent-Length:2Date:Sun, 11 May 2014 11:49:23 GMTServer: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：⽂本框输⼊不合法的内容，点击提交按钮， 如果不合法的内容提交成功， 那应该是前后台没有做校验， 前后台都有这个bugcase2：⽂本框输⼊合法的内容，点击提交按钮， 查看数据库中的数据和输⼊的内容不⼀致， 这个时候需要看前台传的数据是否正确，使⽤fiddler抓包， 查看请求头⾥⾯的数据是否和输⼊⼀致，如果⼀致就是后台的问题， 如果不⼀致，就是前台的bugcase3：界⾯展⽰不友好， 重复提交 这些都是前台的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的bug2. 出现⽂本的问题基本都是html的bug3. 出现交互类的问题基本都是Javascript的bug现在以淘宝的前端⼈员⼯作为例进⾏相关bug定位的剖析判断前后台问题的区分⽅法：F12, 打开错误控制台console1. 区分前后台交互：查看⽹络请求a) Html中如果有链接，有相应的情况下，基本可以定位到是属于前端的问题b) 如果为空，或者有出现error错误信息，我们就可以定位到属于后台开发的问题1. TMS对应的VM模板，出现的⼀些截断控制，转换功能都属于前端的问题⼀、HTML最常见的HTML的问题—就是标签的问题了，最常见的排查和解决办法就是查看页⾯源代码，然后通过检查标签的⼯具，现在暂时提供进⾏检查，有其他更好的⼯具再进⾏推荐。常见问题类别：1. 标签闭合—表象，页⾯中出现⼤范围的混乱，就是少了标签的情况，导致标签未闭合2. 标签浮出—例如⿏标移动到⽂本位置，浮出全名的这种浮出形式都属于标签浮出的问题3. 标签在不同的浏览器的⼀种解析⽅式的不同导致的前端bug例如如下结构该部分可以看做为⼀个⼤的框即是标签 内嵌标题的标签

，⾥⾯再有这些个内容,那么在不同的浏览器中，可能ie和FF的解析会产⽣不同，假设IE解析为

的⼀种形式，但在FF下可能解析为

的两⾏的形式从⽽导致前端在复古鞋/板鞋这块ing⾥⾯的格式产⽣混乱结构可看为：1. 页⾯定点的问题：最明显的前端功能，在于点击某个链接将页⾯位置定位到对应的位置a) 我们可以通过右键，查看元素的⼯具进⾏定位到⽑点所定位到的位置，如果出现问题这种问题很直观，并且能通过这种⽅法直接定位到问题1. 页⾯的跳转，也属于html的问题，⼤家在出现点击未跳转或者跳转⽅式不正确的问题，直接可以定位到跳转属性的问题，找到对应的跳转对应的块提供给开发⼈员即可⼆、CSS，产⽣样式问题。例如：排版，布局，颜⾊，背景等css的bug主要分为：兼容型bug 、业务性bug 和 内容型bug1. 兼容型buga) 表现：仅在少数⼏个浏览器上出现b) 原因：浏览器的解析不⼀致c) 解决：根据实际情况进⾏前端代码的通⽤性d) 类别：1. 脚本兼容型问题：在出现对应交互的问题就基本可以定位到脚本兼容型bug，例如DIV的显⽰和层结构。实际可以参考聚划算的⼏个商品⿏标移动到⼩图的时候，对应⼤图展⽰的功能。2. 页⾯样式兼容型问题：直接表象在样式上，都是基于框架的页⾯展⽰错误，很容易定位3. 业务性buga) 表现：在所有浏览器下都有该问题b) 原因：对业务不熟悉c) 解决：根据需求进⾏修改达到业务要求该类型的定位，主要在和实现的要求不⼀致，最直接表现在页⾯的友好型，⽤户的可⽤性的bug，可以定位为该类型1. 内容型buga) 表现： 前端⾃测正确，但在填⼊内容后，出现的错误，内容消失等b) 原因： 扩展性未考虑周全c) 解决： 进⾏overflow test输⼊内容的长度限制等功能可定位为内容型bug三、Javascript最直接的判断⽅法，刷新页⾯，出现滞后显⽰的⼀些模块基本都为脚本的输出块。该部分的⼀些问题可以参照兼容型bug中类别的脚本兼容型bug。1. 有产⽣交互类的问题，⼤多数都可以定位到是属于javascript产⽣的问题，该部分⼤多不会报错2. 有错误提⽰类的。页⾯左下⽅有出现javascript的错误提⽰；有弹出错误信息提⽰的bug；浏览器返回的⼀些错误弹出框都属于javascript的bug

后台bug定位：根据后台⽇志⽂件系统使⽤secureCRT进⾏⽇志获取(1)编码问题：tomcat是新的，需要改编码 修改tomcat的⽂件特别是windows下的项⽬重新部署到linux系统下，(2)空指针：程序问题，⼀般没有考虑到为空情况，或者主外键约束的数据为空，或者删除关联数据，导致为空(3)长度过长，超过最⼤长度，测试环境修改数据库字段长度后⽣产环境未修改，导致报错！！(4)⾮法数据：(5)内存溢出：重启

系统使⽤secureCRT进⾏⽇志获取，或者服务器控制⽅⾯的操作（关闭和重启）重启的⼀般情况： 1）热部署 （新增部分功能，或者修改部分bug) 2）发布新版本 （整个系统） 3）内存溢出，此时重启服务器即可由于项⽬中有线程程序，./shutdown脚本关闭tomcat程序，不能把启动的线程全部关闭，造成服务器启动线程未关闭的错误。　　系统中重启Tomcat的⼀般步骤：（⼀般是先关闭进程，然后进⾏重启 ，如果 /要删除某个⽂件：rm ⽂件名，或者不为空的⽂件夹：rm -rf ⽂件夹名）　　cd usr/local/ //测试服务器名称/bin　　ps -exf //看测试服务器下运⾏的项⽬的主进程（最前⾯的数字为PID进程号）　　kill -9 PID //强制关闭某⼀项⽬的主进程　　./ // ./**.sh 即执⾏重启脚本⽂件 ，此时在测试服务器的bin下⾯，直接执⾏即可，其余的加上 chmod a+x shell脚本⽂件，也可⽤./执⾏　　⼩知识：　　ps aux和ps -ef命令区别　　ps aux 是⽤BSD的格式来显⽰这个进程　　显⽰的项⽬有：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 //监视 ⽂件的尾部内容（默认10⾏） 4.⽇志中常见的问题获取⽇志⽂件中常遇到的问题：　　1)编码问题：tomcat是新的，需要改编码 修改tomcat的⽂件　　特别是windows下的项⽬重新部署到linux系统下，　　2)空指针：程序问题，⼀般没有考虑到为空情况，或者主外键约束的数据为空，或者删除关联数据，导致为空　　3)长度过长，超过最⼤长度，测试环境修改数据库字段长度后⽣产环境未修改，导致报错！！　　4)⾮法数据： 5)内存溢出：重启

5.⼀般的问题原因总结：　　程序：为空判断，增删改查,不同公众号调⽤的接⼝也不⼀样　　数据初始化：数据库表结构和数据初始化，权限配置，　　特别注意⽣产环境上的⽤户数据修改，此时⽤户在使⽤，很重要！！！　　故障⽆法重现时：　　1）看⽇志，根据⽇志定位原因，则在测试环境中按照⽇志提⽰构造条件相同的测试案例测试，尝试在测试环境中将问题重现。　　2）测试环境和配置与实际的⼯程环境和配置有哪些差异等等。同时主动与开发负责⼈、⼯程实施⼈员以及有经验的项⽬经理讨论，分析可能导致的原因。　　 测试环境ok，⽣产环境新增时保存失败，查看后台⽇志报长度溢出，数据库内容字段要求和⽣产环境不⼀致！！

6.辅助⼯具：linux和　linux查看⽇志　SQL⽤来筛选数据或直接进⾏数据修改状态，多⽤于集成测试过程中前后流程相连接

三.浏览器兼容性和⽹页规范标准测试　 浏览器兼容性测试（偏主流浏览器，如，⽕狐，IE8以上）：　　/en-us/microsoft-edge/tools/staticscan/　　W3C⽹页验证：（判断⽹页书写是否符合规范，记住此处必须去掉权限控制，单个单元页⾯url需要跟参数）　　/　　W3C⼿机端页⾯检测（如⼿机微信菜单下的页⾯）：　　/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.测试⼯具和技术⽅⾯　　传统的企业花钱购买商业软件，如，loadrunner，或者⾃⼰开发的⼯具　　⼤部分的互联⽹公司使⽤开源或⾃主研发的，如 selenium，appium，robotium,monkeyrunner,jmeter　　相同点：　　1.都需要⾮常熟悉产品和业务　　2.都需要了解产品的技术（深度测试⽅⾯性能分析，内存泄露，web服务器，cache，代理)　　3.具体的　　4.测试设计的⽅法　 5.测试⼈员的技术体系：

实战图中参数city code 为空此时不应该为空，为空就可能导致前端看不到该数据 后台返回的⼀条数据没有----后台BUG