Question

糜家蔚@测试团队 2017-08-14

摘要

作为测试人员，我们接触的 “bug” 可能比吃的盐还多。当发现 bug 后，测试需要采取什么样的行动？直接上报？重现以后再上报？Bug 的来源无论是客诉反馈，还是测试过程中出现的，亦或是开发修复后告知的，知其然以及知其所以然都是测试经验的积累。

本篇笔记将做一次梳理，明确测试人员定位问题的重要性，并给出定位问题的思路与基本方法。

重现即正义，定位很重要

定位问题的意义

能降低误报率。 明确一个问题是不是真的 bug，比如客诉反馈的可能是某用户的操作盲区，若根据提供的信息再次制造出该问题的现象，再以对待 bug 的姿态对待该问题。

能在过程中学习。 比如理解产品内部逻辑，对业务架构的理解，知晓数据流是怎样的走向。随着对业务架构逻辑的理解，反过来又会促进对问题的定位。

能加强推进能力。 上报 bug 时将问题的复现步骤、现象、期待结果、初测判断描述清楚，指派给对应的开发人员，防止他们“打太极”，提高缺陷的修复速度。

能提升挖掘 bug 的敏锐度。 只有自己对 bug 有一个较全面的认识，才会判别出开发回复的是不是真正的原因，才能有助于我们后续对 bug 进行分析归类，在后续测试工作时有针对性地做出计划、设计用例。

能建立开发对测试的信任。 开发人员会欣赏你对待问题的细致程度，并乐意配合你调整代码的可测性。

两组对话，已见分晓

一号测试人员：“你的代码有 bug，可能是某某问题吧，你检查一下！”

二号测试人员：“你的代码出 bug 了，初步断定是只在某某情况下有问题，需要针对这类情况做特殊的处理。之前在产品 B 上也发生过类似的问题，当时判断说问题发生的概率低无需修复，但上线后接到用户的反馈，在某某输入情况下会导致异常。相关页面截屏、日志、复现步骤我都记录在 bug 系统指派给你了，请尽快修复！”

不必作具体说明，无论从专业性角度还是从情感角度，开发人员更愿意和二号测试人员合作。那么如何成为 “二号测试人员”？请接着阅读。

问题定位有套路

先看两个案例

案例一： 清除 A.com 站点下的所有 cookie，添加一个设置了过期时间为当前日期 +1 小时的 cookie 然后在 B.com 站点的页面通过用户中心中访问 A.com 站点，在火狐、Chrome 下正常，均可以正常访问，在 IE 下无法访问。如何定位？

首先，以相同前置动作查看其他站点的跳转，观察是否有相同问题。其次，在 A.com 站点下先添加一个过期时间不设置的 cookie，然后执行相同的操作。在 IE、火狐、Chrome 下观察是否可以正确获取。接着，将 A.com 与 B.com 两个站点添加到信任站点，并将信任站点的安全级别设置为低，然后访问查看是否可以正确获取，从而推测是否只是 IE 对于跨域请求 cookie 有限制。

案例二： 在一个文本框内填写文字并发布，显示发布成功后点击跳转到详情页查看，发现之前填写的文本内容显示不全，如何定位？

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

追溯有层次，思考有方向

无论是开发还是测试，发现与定位问题都有总的思路，一个由上自下的方向，而这个方向基本是和数据的走向一致的：

以下以 PC 页面为例进行说明（移动端问题相对更复杂，还牵涉依赖的外部应用与设备本身）：

1. 用户使用问题指的是用户自己的环境问题或者操作问题，比如环境不通，或者操作不正确。这种问题一般不是 bug，当然，如果要考虑构建更加健壮的软件，那么可以根据实际情况来决定要不要处理这类问题。
2. 前端页面问题也是最为直观的问题。这类问题一般通过观察以及利用一些常识可以发现，比如样式问题一般是 CSS 的问题，交互问题一般是 JS 的问题，文本问题一般是 HTML 的问题（当然有可能是其他问题）。
3. Web 页面操作后，浏览器会发出请求，此时 Web 服务器、应用服务器比如 nginx 会收到请求。如果发现内存溢出，那么就可能会定位到是 Tomcat 配置的问题。如果请求返回 404，也可能是 nginx 配置不当。当然，这个时候可能会遇到一些环境问题，比如测试环境没有的问题，到线上就有了，很可能是环境原因，比如依赖包版本不同等等。
4. 最后是数据库。代码没有问题，不代表软件也没有问题。数据库层面也可能会有各种各样的问题，比如字段的约束问题等等。假如一个文本框的前端校验和接口校验的文本长度最大是 50，但数据表字段设定的是 varchar(30)，那么在存数据的时候肯定会报错。再比如之前发现一个数据库的问题，测试环境没有，到线上却有了，那么也可以看下是不是数据不一致造成。

以上，是问题定位的一个大致思路。每一个环节都有可能出现 bug。很多时候我们不需要这样一层一层去定位（毕竟很耗费时间），经验丰富的开发或者测试根据现象可能马上能定位到究竟哪里出了问题。

过来人的 Tips

保存犯罪现场

碰到问题先请保存犯罪现场，并且确认能复现。如果复现不了，就证明不了问题的存在。

多问自己几个问题

• 是测试环境配置的问题吗？
• 是数据不一致吗？
• 是测试使用的版本不对吗？
• 是外接第三方产品的问题吗？
• 当时的错误日志存在吗？
• 能复现吗？

避免 QA 的低级问题。常见的就是 hosts 不对，网络不通，以及操作姿势不正确等等。这个其实就是上文提到的用户层面问题，这里的用户就是 QA 人员。

熟悉状态码

以下列举常用的 HTTP 状态码：

• 2xx 表示成功处理了请求的状态代码。

  200（成功）：服务器已成功处理了请求。通常，这表示服务器提供了请求的网页。

• 3xx 表示要完成请求，需要进一步操作。通常，这些状态代码用来重定向。

  301（永久移动）：请求的网页已永久移动到新位置。 服务器返回此响应（对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。

  302（临时移动）：服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。

• 4xx 这些状态代码表示请求可能出错，妨碍了服务器的处理。

  401（未授权）：请求要求身份验证。对于需要登录的网页，服务器可能返回此响应。

  403（禁止）：服务器拒绝请求。

  404（未找到）：服务器找不到请求的网页。

• 5xx 这些状态代码表示服务器在尝试处理请求时发生内部错误。这些错误可能是服务器本身的错误，而不是请求出错。

  500（服务器内部错误）：服务器遇到错误，无法完成请求。

查看服务器日志

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

还有一类问题就是脏数据，我们有时候会遇到服务端报 500 错误，查看相关日志能判断是否数据库中关联表的数据被人为删掉导致的。还有的问题是由于工具的影响导致的，例如设置了代理。

关注接口的请求与返回

在第3点中我们说了状态码的问题，明确了 4xx 和 5xx 的问题所在。那么，如果接口返回了 200，就一定正常吗？

假设有这么一种情况，要测试一个翻页控件，翻到第二页的时候，发现内容和第一页完全一样，接口请求返回的是 200。这个时候需要如何定位？

这个时候就要看前端发送的参数正不正常，后端返回的内容正不正常，即接口的请求和返回。看看返回的内容对不对，以此就知道到底是前端问题还是服务端问题。

请求 URL 不正确，是前端 bug，传参不正确，是前端 bug，响应内容不正确，则是后端 bug。

及时核对需求文档

需求是否就是如此呢？

有时候，前端和服务端的交互都正确，但是从测试的角度看不合理。这个时候，我们应该复阅需求文档。如果和需求文档不符，那么就要看下谁改合理，是前端改，还是服务端改，或者两者都得改。当然，不要以为需求文档就全部正确，它也可能会有错误，我们也应该去发现需求文档中产品逻辑等问题，然后再去协调 PM。

后端生成页面问题

后端生成页面，最常见的就是类似于 JSP、PHP、Python 的某些前后端不分离的框架，这种比较特殊，好在前后端 bug 的修改可能都是同一个人而已。

获得可测性的支持

有时候，涉及到多方面合作，测某一产品要关联到多个系统的使用，测试账号有别、测试数据难造的情况下，需要开发提供可测性支持。比如，要查看接口给另一个接口发的请求是否正确，可以让开发打印出完整的请求 log，或者开发有写一些对应的开关配合测试。

构建问题

常见的可能还有构建的问题，比如代码本身都没错，但是合并代码到主干后出问题了，常见的就是代码存在冲突时手动解决的时候。这个要靠各种流程正规化来解决了……

建立 Bug 的知识库

也许你遇到的问题别人一早就遇到过，多沟通、多交流、多分享。

列出 Web 产品常见问题关键词：

浏览器设置、浏览器兼容性、cookie 相关、request 是否发出、response 是否正确、JS 跨域问题、前后台接口定义不一致、边界值、并发问题、多线程问题……

恩，测试经验是个很厉害的东西。

以上，只是对问题的初步定位。

结语

可以发现，所有过往案例都没有具体的定论，凡是具体问题具体分析。我们只要掌握了分析方法和思路，就能够找出来到底是哪里出了问题。

最后，对于无法确定的问题或者目前功力难以定位的问题，要交给开发，不要浪费时间。优先解决项目进度问题，其次才是测试深度。