• 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 跨域问题、前后台接口定义不一致、边界值、并发问题、多线程问题……

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

以上，只是对问题的初步

16cvpr_staple.pdf

85cccab3gw1ete12o9vtwg20dc0a0n9w.gif