产品经理验收测试过程中，最常遇到的是，发现了问题却不知道指派给前端还是后端。最尴尬的是，明明是前端的问题，指派给后端，或者是后端的问题指派给了前端，导致给其他团队成员造成不专业的印象。因此，为避免这种情况的发生，结合自身的测试经验以及网络收集的资料，整理成如下文章，希望可以给大家带来帮助。
一、什么是前端/后端？
前端是用户看得见摸得着的东西，主要体现在页面的视觉效果以及交互设计上。比如说一个网站的页面风格、页面跳转等，最简单的例子就是一个注册界面：前端设计界面风格，约束输入的字符类型、长度以及合法性校验等，不涉及到与数据库之间的信息交流。
后台，则侧重于更深层面的东西，关于逻辑，关于数据，关于平台的稳定性与性能。后台主要负责实现具体的功能，举个例子，还是那个注册界面，前端写好了界面，规定了你能输入哪些数据，不能输入哪些数据，而后台则会把你输入的信息与数据库进行比对，由后端服务处理是否需要进一步运算，并且把数据保存在哪一个数据库的哪一张表里。如果是新用户，则顺势在数据库中插入一条信息。
当然，关于数据的校验，不同项目情况不同，有些是由前端进行校验，有些是后台，有些是前后台都需要校验。
二、为什么要区分前端/后端BUG？
目前多数项目都是多人协作开发的，如果不能明确这个BUG是谁造成的，容易提交给错误的开发人员，会大大降低BUG的解决效率。
另外，如果团队规模较大，或者由各地的项目组拼凑而成，势必会增加沟通成本，这更需要我们在类似禅道或者Jira等项目管理软件中提交BUG时，先指明是谁的BUG，避免互相踢皮球的现象。
所以，为了提高团队效率，测试人员尤其要做好BUG分类。
三、如何定位前端/后端BUG?
弄清楚如何定位和分类BUG之前，需要了解一下页面请求的过程，以 http 请求为例，请求过程如下：
用户在前端页面操作，如点击某个功能
页面携带数据进行请求，访问具体功能接口
由后端服务执行该接口相应的业务逻辑，如涉及数据，再去请求并组装数据返回给前端
前端页面进行渲染和展示对应的页面和数据
前后端BUG各有什么样的特点？
前端BUG
– 界面相关
– 布局相关
– 兼容性相关
给个最大的区别方式方法：
1.出现样式的问题基本都是CSS的bug
2.出现文本的问题基本都是html的bug
3.出现交互类的问题基本都是Javascript的bug
后端BUG
– 业务逻辑相关
– 性能相关
– 数据相关
– 安全性相关
四、定位BUG属于前端还是后端，有什么方法？
经验法
软件测试人员应不断精进自己的技能，负责的项目多了，自然对功能的实现过程有了解，也就明白如何分类BUG了。
例如：
网页上的某个图片的分辨率不对，如果我们了解实现过程，可以想到一般情况下，是根据某个地址去服务器取图片的，数据库一般只保存地址，那么图片能正确显示，就说明后端的基本功能是满足需求的。如果具体图片分辨率有误，最可能的原因是前端显示过程出了差错。
日志查看法
当我们发现一个BUG，并不确定这个BUG属于前端还是后端，可以查看后端服务的日志，复现BUG时，查看日志中有没有相关信息。基本可以认为，如果日志没有输出，很可能这个功能并没有与后端交互，也就不存在后端的问题。反之，如果日志有输出，可以进一步查看有无错误日志信息，进一步分析。
接口查看法
这种方法常用于查看是后端返回给前端的数据有误，还是前端显示有误。
大多数浏览器都有自带的接口查看工具，如Chrome，FireFox等都可以通过F12开启抓包，在NetWork中可以看到当前页面发送的每个http请求。
通过Chrome看到的接口情况如下
NetWork
可以在Response中查看响应数据
Response
我们需要对比通过后端接口拿到的数据和前端显示的数据，来确认问题出在哪里。如果数据错了，页面显示是错的，也是正常的，先从后端入手去解决。如果数据对了，但是显示错了，就需要问问前端的开发人员了。
五、经验和总结
沟通很重要
我们在定位BUG的过程中，最不能忽略的一个问题是和开发人员的沟通，有时候忙活半天，不如一问一答。经验和技术的成长也都离不开合理高效的沟通。
参考资料：
网友评论