作为一个测试人员，如果你连常见的系统问题都不懂得分析，频繁地把前端人员问题分配给后端人员，把后端人员问题分配给前端人员，那么你在团队发展中的地位是显而易见的，声誉、赏识、加薪应该是你遥不可及的梦想。

但是作为测试人员，虽然不能深入分析问题，但是可以发现系统中的问题，这也是值得肯定的，所以继续加油吧。

所以今天要和大家分享的话题是:“如何快速定位bug”

01定位问题的重要性

很多测试人员可能会说我的职责是发现bug。至于找到原因并加以解决，这是一个发展问题。这对我有什么关系？

好吧，我的回答是，如果你只是想做一个测试人员最基本最尽职的事情，那么你可以这么想。然而，如果你想在测试甚至开发的道路上取得巨大的进步，你需要知道为什么。

那么，为什么定位问题如此重要？

1、可以明确一个问题是否真的是“bug”。很多时候，我们找出问题的原因，可能根本不是bug。如果原因明确，假阳性就会减少。比如我们团队的大美，全年500个bug没有一个是无效的。

2.找到bug的原因后，可以明确指向某个开发，防止他们用太极推来推去，提高缺陷修复的速度。

3.让开发者佩服你，增强开发对测试的信任。

4.在这个过程中我可以学到很多东西，有助于理解产品的内在逻辑、架构和数据流的方向。随着对业务架构逻辑的理解，反过来也会促进问题的定位。

5.可以降低缺陷率。这可以说是最重要的。在bug系统中，我们会要求开发人员记录bug的原因。只有对bug有了全面的了解，才能判断开发写作是否是真正的原因，帮助我们在后续对bug进行分析和分类。根据bug分析，我们可以有针对性地未雨绸缪，从而提高产品质量，减少缺陷。

因此，定位问题非常重要。

接下来我们来讨论定位问题的方法和技巧。

02问题定位技巧

首先，定位问题有一个大概的思路，和数据的趋势是一致的。大致是这样的:

首先，当系统出现bug时，一定要记录并保存bug现象，这是证明bug已经发生。如果bug修复后重新出现，很容易说如果bug不能重现，那么保存下来的截图就是你的直接证据，所以你要养成保存场景的好习惯。

提到BUG，还是要体现测试的专业性。标题简洁，问题环境标识清晰，问题描述清晰详细，系统错误表示图，接口参数传递返回图，必要时服务器日志。总之，bug标签应该不会少。

一.小规模产品，前后一体一人。

一些小程序，比如前端和后端都是用node和php语言开发的，整个系统的前端和后端是同时开发的，所以边肖可以很自信的告诉你，当系统出现问题的时候，bug是大胆提到的，责任人不会错！

二.传统系统，多人开发协作

预测试:测试前，测试人员熟悉系统、业务、环境部署、开发人员等。

测试前，打开相应浏览器的F12直接打开新的标签页，或者使用包捕获工具等。当系统出现问题时，检查相应的请求、日志信息等。，这样我们就可以充分定位前端或后端人员的问题，并具体介绍以下常见的方法。

1.分析问题场景并做出预测。

先看页面表象，根据问题表象判断问题可能的原因，缩小范围，准备记录工具记录问题。

如果系统无法正常访问页面，在5开头找到后端，在4开头检查请求地址或对应权限，进入系统页面正常打开，直接提示后端有异常代码错误。

进入系统页面，显示异常图片、视频、相关提示、Flash等安装相关信息。如果Flash不可用，找前端，UI显示兼容错误会找前端。

如果系统访问正常，进入操作页面和功能错误信息，然后进入以下链接，抓取包检查对应的请求体，读取日志等。

2. 关注请求体的状态码

4**开头的状态码一般都是客户端（前端）的问题；例如常见的404确认下是否是请求的地址有错，403确认是否有权限访问，具体可百度

5**开头的状态码一般都是服务端（后端）问题，例如常见的500，则表示是服务器内部错误，503网络过载导致服务端延时，502服务器崩溃等，具体可百度

3.关注请求的入参与响应数据

通过访问报错的页面，加载错误请求时我们通过F12进行分析请求包，查看对应的入参以及响应数据

例如：请求入参错误，那么该bug属于前端的错误；入参标准可以根据前端页面的输入的内容或者选择的内容，进行核验，入参格式以及是否必填等可以对应接口文档去进行分析或跟开发确认

例如：请求未响应或者响应数据错误，那么该bug就属于后端的错误；一般是数据库查看报错，例如删了某个表查询报错误空指针等

如果请求的参数或响应数据没有问题，如果开发反馈是浏览器解决问题，可以使用另一个浏览器进行测试。

4.检查日志

针对服务器类型错误，我们可以登录日志平台或者在服务器对应的日志目录中查看打印的日志。

检查日志命令tail，/error，以快速检索关键字接口名称和其他相关内容。

获取相应的日志，将日志文件粘贴到bug列表中，分配到后端，提高专业性。测试人员也要养成看日志的习惯，看了就明白了。

5.经验法则

在系统的首页，当遇到与服务器配置相关的错误信息，比如Nginx***或者代码和SQL相关的提示错误信息，直接去后端处理，比如JAVA****，。PHP、SQL等。

前端字符检查、格式检查等。、浏览器界面和插件的UI兼容性，或者APP、小程序类调用手机相关功能拍照，语音无法正常调用，直接去前端。

我们来谈谈测试人员定位问题的N板斧。

1.让子弹飞一会儿。

不要忙于查找问题。首先，请保存犯罪现场，确保它能够重现。然后消除QA的低级问题。为什么要拯救现场？如果以后不能重现，就不能证明问题的存在。有哪些低级别的QA问题？常见的有主机不正确、网络不通、操作姿势不正确等等。其实这就是上面提到的用户层面的问题，这里的用户都是QA人员。通常，质量保证人员在发现问题后会迅速打电话给开发人员过来看看。在这个发展的时候，他们淡淡地说“主持人说得对”，看看是不是说错了就尴尬了。

另一种问题是脏数据。有时，我们会遇到服务器报告的500错误。检查日志后，我们将报告空指针，这可能是由于数据库中关联表的数据被人为删除造成的。其他问题是工具的影响造成的，比如提琴手。所以发现问题不要慌，让子弹飞一会儿，确定不是自己的问题。

2.目视检查页面性能

这是对上面提到的网页的观察。没有更多的细节。

3.看看状态码

4xx状态代码通常表示这是客户端问题(当然，也可能是服务器端配置问题)。例如，如果发生401，则有必要查看您是否有正确的身份验证信息。如果发生403，就看你有没有权限了；04查看对应的URL是否真的存在。

而5xx通常表示服务器端问题。例如，如果出现500个错误，则表明这是服务器的内部错误。此时需要配合服务器日志进行定位；502可能是服务器挂机造成的；503可能是网络过载造成的；如果发生504，可能是程序执行时间过长，导致超时。

4.查看服务器日志。

如果出现5xx问题，或者后端接口执行的sql是正确的，我们最常用的故障排除方法就是查看服务器日志，比如tomcat日志。开发人员通常键入关键信息和错误消息来找出问题。测试人员应该养成阅读日志的习惯。而且，如果以后发展，也要养成伐木的习惯，不然发现问题真的不知道哭到哪里去了。

5.接口和js执行的请求和返回是否有错误

在第3点中，我们谈到了状态代码，并明确了4xx和5xx的问题。那么，如果界面返回200，一定是正常的吗？

假设有这样的情况。为了测试翻页控件，当您翻到第二页时，您发现内容与第一页完全相同，接口请求返回200。这个时候你会做什么？

这时候就要看前端发送的参数是否正常，后端返回的内容是否正常，也就是接口的请求和返回。

我们来看看翻页控件的问题。我们来看看界面的请求(F12控制台检查网络请求或者抓取包工具)。一般根据开发习惯，会有pn和ps参数，看传递的值是否正确。如果请求参数不正确，那就是前端问题。如果是正确的，那就看看响应，看看返回的内容是否正确，从而知道是前端问题还是服务器端问题。如果发现js执行错误，那就是前端问题，比如跨域问题。

请求URL不正确，是前端bug，参数不正确，是前端bug，响应内容不正确，是后端bug。如果你用不正确的内容来回应后端问题，你应该继续深入挖掘。接口吐出数据的时候是不是有问题，或者数据库中的数据有问题，或者缓存中的数据有问题(如果使用缓存的话)？经常看到有些后端开发人员负责接口，有些负责写入数据库，有些负责维护缓存，所以如果发现后端有问题，我们可以进一步确认是哪个块。

6.查看需求文档。

有时候前端和服务器端的交互是正确的，但是从测试的角度来看是不合理的。这时，我们应该浏览一下需求文档(如果没有，就直接抛出这个问题)。如果它与需求文档不匹配，那么我们必须看看谁应该合理地更改它，无论是前端更改，还是服务器端更改，或者两者都更改。这里有一个原则，就是前端要承担尽可能少的逻辑，只负责渲染和呈现。当然，不要认为所有的需求文档都是正确的，可能会有错误。我们还应该在需求文档中发现bug，然后与PM协调，督促FE或RD修改。在这一点上，我不得不说，有些开发人员做得很好，他们会有自己的想法，他们在开发的时候可以发现需求文档的错误，而另一些则是无条件无脑地执行。

7.后端页面生成问题

最常见的生成后端页面的方式类似于jsp、php和python的一些框架，它们与前端页面没有分离。这种框架相当特殊，在单人开发的项目中很常见。除了前端和后端bug的修改可能都是同一个人进行之外，这个项目的故障排除总体思路和其他项目是一样的。

8.开发提供可测试性支持。

有时候涉及到很多方面的合作，测试不是很好的时候，就需要开发和提供测试性支持。例如，为了检查接口发送到另一个接口的请求是否正确，您可以让开发人员打印出完整的请求日志。还有一些逻辑开关，修改页面数据的数量等。，所有这些都属于可测试性支持的范畴。

9.配置问题

很多时候，bug不是代码问题，而是tomcat配置、nginx配置、jdbc配置等等的问题。在这个层面上，测试人员最好了解自己的配置，发现问题后可能会想到这个问题。

10.经验法则

天底下没有什么新鲜事，有经验的人早就遇到过同样的问题。高手往往一眼就能看穿表面现象的内在问题，然后直奔主题，迅速报告或解决，把别人搞得乱七八糟...

11.其他的

也可能有构建的常见问题，比如代码本身是正确的，但是合并到主干后就出现了问题，常见的问题是手工解决代码冲突的时候。所以以前喜欢问开发人员在合并代码的时候有没有冲突。如果有冲突，哪里有冲突，我们就应该关注它。

另外，定位问题后，考虑具体情况，根据开发者的心态决定是否告诉开发者具体原因。有些开发商不够开放，认为你抢了他的工作。为了开放的发展，你们会更加默契地合作。

当然，在我们发现问题或找到问题的原因后，我们必须再进一步，即再次确认问题。所谓确认问题，就是找出问题是否每次都发生，是概率事件还是工具相关问题(比如，是否还有另一个浏览器出现？如果没有出现另一个浏览器，很可能是前端的兼容性问题)。比如翻页控件，被测系统的很多页面都有翻页控件，所以需要看是否每个页面都会出现这个问题，然后在上报bug的时候做统一的解释，这样更方便开发者批量处理，防止遗漏更改。

03如何首次编写用例

很多朋友第一次写用例，却不知道从何下手。虽然有些公司提供了相关的文档，但还是写起来不太容易。编写用例的方法有很多:面向功能的用例(边界值、等价类等)。)，面向用户的用例(场景方法)，以及结合函数的面向用户的用例...

那么，如何第一次高效地编写用例呢？需要注意什么？

1.面向功能的用例是根据系统需要实现的每个功能编写的。这样的用例集中在功能实现上，没有考虑每个功能之间的关系。因此，尽管用例已经达到了功能覆盖，但它们不一定达到逻辑覆盖。因此，这种方法通常与其他方法结合使用。面向功能的用例是每个用例作者在早期阶段最常用的方法。

第二，面向用户的用例是根据用户的习惯设计的，以用户使用系统的每一个目的为目标，以每个目标的实现为基础。但是，在设计这类用例的时候，初学者可能会有很多困惑(请写下我第一次写的时候有哪些困惑，以及后来针对这些困惑采取了哪些解决方案)。

1.写用例的第一步应该怎么做？

要了解系统，首先要从测试的角度，深入了解系统的各个功能和系统的业务逻辑，并画出业务逻辑图(即系统能做什么)。

其次，从用户的角度，列出用户使用系统的目的(即用户使用这个系统时想做什么？)

2.如何确定用户的目标？

无法确定用户的目标可能是由两个原因造成的:a >不熟悉系统，b >不了解用户背景。第一个原因，是你自己的原因。你得回头看看文件。第二个原因，你可以从系统能做什么来计算用户能做什么，然后总结用户可能想做什么。当然，这样做的前提是你已经熟悉了系统。

3.这个月我要做什么？

第一次进入测试行业如何总结(使用测试管理工具总结):

1)对测试管理工具中的所有缺陷进行分类导出，总结哪些模块容易产生哪些缺陷，重点关注你没有发现或考虑的缺陷。

2)如果测试新人工作的第一层是从测试用例的执行开始，那么第二层就是写测试用例。详细阅读几遍测试管理工具中的用例，学习别人的用例编写方法和思路，在业余时间尝试自己写，看看自己写的用例和别人写的用例差距在哪里，从而不断改进。重要描述；专注于用例编写方法和思路的研究，不要拘泥于照搬。

3)进入一些测试论坛，与大家分享自己的困惑和经历，在学习中不断进步。