测试定位问题和分析总结

一般作为测试，有人可能会说我们找到bug就好了，为什么还要给开发定位问题呢？但其实定位问题不仅有利于开发快速修复问题，更是可以提高自己的本身技能，更加有利于在客户现场快速解决问题，下面就给大家讲解下具体小技巧。

PS:测试勤快了那必然开发就懒了，哈哈！！！

一、测试定位问题的重要性

1.找到bug后，再次复现一次bug，降低bug误报，导致不必要的沟通；

2.找到bug分析原因后，可以明确地指个某个开发，提高修改bug的效率防止bug转过来转过去；

3.找到bug能够精确bug的原因，让开发人员能够觉得测试厉害，提升开发对测试的信任度；

4.自己在分析的过程中，可以更好地理解产品内部逻辑，对产品架构的理解，以及数据流存储走向，数据存储都有一定的了解；

5.如果在客户现场能够快速找到bug原因，可以让客户对测试岗位刮目相看，增加对公司和本人信任度，也进一步提高效率；

6.可以降低缺陷率，在bug系统中，测试会要求开发人员记录bug产生的原因。只有我们自己对bug有一个较全面的认识，才会判别出开发写的是不是真正的原因，也才能有助于我们后续对bug进行分析归类，进而提升产品质量，降低产品缺陷。

所以，定位问题非常重要，接下来我们就来探讨下有哪些定位问题的方法和技巧。

二、问题定位技巧

首先，不管是开发还说测试也好，定位问题有一个总的思路，而这个思路是和数据的走向一致的。

大致是这样：

用户层面问题 - Web页面/软件界面 - 中间件 - 后端服务 - 数据存储 - 数据库

1. 用户层面问题：

用户自己的环境问题或操作问题，比如环境不通或者操作不正确。这种问题一般不是bug,如果要考虑构建更加健壮的软件，那么可以根据实际情况来决定要不要处理。

1. web页面问题：

这类问题一般通过观察以及利用一些常识可发现，比如样式问题一般是css问题，交互问题一般是js的问题，文本问题一般是HTML的问题。

1. 中间件问题：

web页面正常操作后，比如发出一个请求或者跳转到一个页面，可能会进入中间件这个层面。这里的中间件是广义上的，比如负载均衡，各种缓存服务器等。

举例说明：我们经常遇到一个问题，发现刚刚上传的图片进行读取展示时就读不到，图表也看不到，那么可以想到可能是负载均衡时将上传照片和读取照片两个请求分配到了不同的服务器导致的，也就是我们常说的会话保持。当然，中间件问题有时候是和开发相关的，中间件也不仅仅会出现在这一步，实际的项目中可能还会用到更多的基础设施，比如消息中间件、数据存取中间件等，如果发现了相应的问题也就需要有对应的思路去排查。

1. 后端服务层问题：

服务会转发到真正的后端服务层，WEB服务器、应用服务器比如nginx、tomcat会收到对应的请求。如果发现内存溢出，那么就可能定位到是Tomcat配置问题；如果请求返回404，也可能是nginx配置不正确现象。这个时候可能会遇到一些环境问题，比如测试环境没有问题，到线上就有了，很可能是环境原因，比如jdk版本不同、Tomcat版本不同、jar包版本不同等等。测试的话大概了解就可以，其他的交给开发。

数据测试过程中，一般后端服务处问题遇到比较多，比如后端服务多线程有问题，不同线程运行中，部分线程稳定运行，部分线程不稳定，再比如发送数据，服务都没接收到数据，一般这种情况都是框架服务不稳定，后端环境问题导致，具体环境问题需要具体分析。

1. 数据存储问题：

前端正确接收到后端的数据，在检查数据过程中，发现数据跟预期结果不一致，此时就要后端排查数据存的是否正确。比如我正常的发送一个事件数据，订单金额是是数值类型，对应的数据为：28.09，但是接收到的数据直接是28，此时就要看存储数据的时候转换是不是四舍五入了，也有一些数据存储的时候出现字段错位的场景，导致接收的数据不对，都需要严格校验。

1. 最后一层是数据库问题：

也可能会有代码没有问题，不代表软件没有问题。数据库层面各种问题，比如数据库字段的约束，类型问题，长度问题问题等。假如一个文本框的前端校验和接口校验的文本长度是50，但数据表字段设定的是VARCHAR（30），那么在存数据的时候肯定会报错。再比如测试环境没有，到线上却有了，也可能是数据库版本不同导致的。

有的问题会直接暴露在用户面前，有的问题需要我们看环境，有些可能需要打印看分析日志。

状态码常用解析和问题归类分析：

1. 状态码4xx一般表示客户端问题（当然也有可能是服务器端配置问题）

比如401要看一下是否带了正确的身份验证信息；

403看下是否有访问权限；

404看下对应的URL是否真实存在；

1. 状态码5xx一般表示服务器端问题，

500服务器内部错误，需要配合服务器log进行定位；

502可能是服务器挂了；

503可能是网络过载导致；

504可能是程序执行时间过长导致；

3.看服务器日志

如果发生5xx问题，或者检查后端接口执行的sql是否正确，最常见的排查方法就是去看服务器日志，比如Tomcat日志，开发人员一般会打印出关键信息和报错信息，从而找到问题所在。

4.接口的请求和返回以及js执行是否报错。如果接口返回了200，就一定正常吗?

假设要测试一个翻页控件，翻到第二页的时候，发现内容和第一页完全一样，接口请求返回的是200，该怎么排查？

这个时候就要看前端发送的参数正不正常，后端返回的内容正不正常，即接口的请求和返回。我们来看翻页控件的问题。我们看接口的请求（F12控制台查看网络请求或者抓包工具），一般根据开发的习惯，会有pn、ps参数，看看传值是否正确。如果请求参数不正确，那么就是前端的问题。如果正确，那么就看response，看看返回的内容对不对，以此就知道到底是前端问题还是服务端问题。如果发现js执行报错了，那就是前端有问题，比如跨域问题。

5.请求URL不正确是前端bug，传参不正确是前端bug，响应内容不正确则是后端bug，如果是响应内容不正确的后端问题，那就要继续深挖，是接口吐数据时出错还是数据库中的数据存储就错了，还是缓存中的数据错了（如果用到缓存的话），经常见到后端开发人员有的负责接口，有的负责写入数据库，有的负责缓存。

6.看需求文档

有时候，前端和服务端的交互都正确，但是从测试的角度看不合理。这个时候，我们应该翻翻需求文档（如果没有的话，就直接抛出这个问题）。如果和需求文档不符，那么就要看下谁改合理，是前端改，还是服务端改，或者两者都得改。这里有一个原则，就是前端尽可能少地去承担逻辑，只负责渲染展现。当然，不要以为需求文档就全部正确，它也可能会有错误，我们也应该去发现需求文档的bug，多提出自己的见解

7.后端生成页面问题

后端生成页面，最常见的就是类似于jsp、php、python的某些前后端不分离的框架，这种比较特殊，常见于单人开发的项目，这种项目的问题排查和其他项目总的思路也一样，只不过前后端bug的修改可能都是同一个人而已。

8.开发提供可测性支持

有时候，涉及到多方面合作，不太好测试的情况下，需要开发提供可测性支持。比如，要查看接口给另一个接口发的请求是否正确，可以让开发打印出完整的请求log。还有一些逻辑开关、修改页面数据条数等，都属于可测性支持的范畴。

9.配置的问题

很多时候，bug不是代码问题，而是tomcat配置、nginx配置、jdbc配置，其他配置等的问题。在这个层面上，测试人员最好能够了解下它们的各项配置，在发现问题后可能就会想到这方面的问题。

10.经验法则

测试多了也就看多了，直接就是经验之谈了，能够快速找到问题。

11、其他

常见的可能还有构建的问题，比如代码本身都没错，但是合并代码到主干后出问题了，代码分支太多，常见的就是代码存在冲突时手动解决的时候。所以我之前有一段时间喜欢问开发在合并代码时有没有冲突，如果有冲突，那是什么地方有冲突，合并代码后开发要检查好，测试要进行冒烟验证，还有数据库迁移,服务器迁移，数据倾斜等一些常见问题；

三、案例

下面介绍几个常见的问题并逐一分析下。

1.点击页面的某个“修改”按钮，页面弹窗提示“unforbidden”，但需求文档中显示应该提示“没有权限”，如何定位？

这个问题要看弹窗中的错误信息是谁发出的。如果点击修改按钮，前端发出了一个接口请求，而该接口的response中有“unforbidden”，那么说明前端的提示是后端返回的，那么就需要后端去修改。否则就是前端写的提示。所以，有时候不能想当然地认为前端弹窗提示文案一定是前端的问题。具体问题具体分析。

2.修改某个表单中文本框内的文字并提交，跳转到结果列表页后发现该文本内容显示不全，该如何排查？

这个问题的可能性有很多，我们可能需要这样排查：首先查看下表单提交时，前端发送的请求中该文本内容是否正确，如果正确就再去数据库中查看记录，然后去看后端响应内容是否正确，然后去看前端渲染是否正确，以此来判断是前后端交互的哪个环节出了问题。

四、总结

可以发现，上面两个案例都没有定论，都是得具体问题具体分析。我们只要掌握了分析方法和思路，就能够找出来到底是哪里出了问题。前端页面所看到的所有元素以及所有数据，要么是前端返回，要么是后端返回，有问题了，就看是谁生成的返回，前端返回的就去找前端，后端返回的就去找后端，谁的孩子惹麻烦了就去找谁，前后端就靠http来通信，所以要多F12，多观察前后端接口交互。

这只是经验总结，并非标准。bug千差万别，有时候需要一个一个分析。多修炼内功：对业务系统的掌握，测试方法以及开发技术。建设自己的bug知识库，多思考、多积累、多总结。

一定请谨记：对于无法确定的问题或者目前功力难以定位的问题，要交给开发，不要死磕，浪费时间。如果冒烟测试都不通过，就不要浪费时间定位了，直接打回。优先解决项目进度问题，其次才是测试深度。
此外，定位到bug后，也需要具体情况具体分析，根据开发人员的性格采取合适的沟通方式以保证开发能够接受你发现的bug。

当然，在发现bug或者定位bug产生原因后，记得要再次确认bug。所谓确认bug，就是弄清楚bug是否每次都发生，是概率事件，还是工具相关的问题。

比如换个浏览器是否能重现？如果换个浏览器不能重现的话，很可能就是前端的兼容性问题，比如翻页控件。待测的系统有很多页面都有翻页控件，那么就要看下是否每个页面都会出现这个问题，进而报bug时进行统一说明归类，也更加方便开发人员批量处理，防止漏改。