怎么高效率判断或定位缺陷bug

为什么要定位缺陷？

作为一名资深的老测试告诉你，如果你不想在开发面前表现的你是一个啥都不懂的就知道点点点找麻烦的人那么你最好的方式就是让他闭嘴。为什么说是让他闭嘴呢？原因很简单，在日常的测试生涯中我见过太多的新手测试不会定位问题，遇到问题直接提交缺陷，也不管是前端还是后端的bug。这种情况会导致测试和开发的关系紧张。试想一下，你作为一个前端天天打开邮件就看到一大堆的缺陷是不是很烦，然后随便打开一个缺陷，惊呼“操，和我有毛线关系啊，这明明就是后端返回的数据不对！”这就导致的开发人员的抱怨。甚至影响别人一天的心情啊。有时候甚至会一个在前端和后端之间不断来回扯皮，导致一个bug修改到上线的时候才解决。
但是如果说你把一个bug描述准确的告诉开发人员这个bug是什么原因导致的，问题点出现在哪里，甚至更高级的和开发人员讨论怎么修改这个bug的时候。试想一下开发人员还会有扯皮和抱怨你吗？我相信大部分的开发很乐意和你一起工作的。甚至先解决你提的缺陷，更或者主动和你讨论缺陷的修复，以及在更希望和你一起工作。
z

怎么去定位一个BUG？

状态码

首先作为新手而言，或者说作为一个普通的测试人员来说不用去了解HTTP协议，但是需要去了解一下HTTP的状态码。什么是状态码呢？
比较官方的解释：
HTTP状态码（英语：HTTP Status Code）是用以表示网页服务器超文本传输协议响应状态的3位数字代码。它由 RFC 2616 规范定义的，并得到 RFC 2518、RFC 2817、RFC 2295、RFC 2774 与 RFC 4918 等规范扩展。所有状态码的第一个数字代表了响应的五种状态之一。所示的消息短语是典型的，但是可以提供任何可读取的替代方案。 除非另有说明，状态码是HTTP / 1.1标准（RFC 7231）的一部分。
其实说白了一点，你可以把状态码看作成一种HTTP返回给你的一种日志。它可以让你判断一个请求出现问题的一个大概的范围例如

• 1XX：消息类型
• 2XX：成功
• 3XX：重定向
• 4XX：地址问题
• 5XX：服务端问题
  以上的一个基本判断只是一个大概的，也是最基本应该记下来的，但是记住这些还是不够的哦，至少也要记下以下的一些常见的状态码的意义
  

TCP/IP的三次握手

TCP三次握手如图：

第一次握手
客户主动（active open）去connect服务器，并且发送SYN 假设序列号为J,
服务器是被动打开(passive open)

第二次握手
服务器在收到SYN后，它会发送一个SYN以及一个ACK（应答）给客户，
ACK的序列号是 J+1表示是给SYN J的应答，新发送的SYN K 序列号是K

第三次握手
客户在收到新SYN K, ACK J+1 后，也回应ACK K+1 以表示收到了，
然后两边就可以开始数据发送数据了

当然这里TCP／IP的三次握手我就不详细介绍了，因为关于TCP／IP的三次握手网上一大堆的文章相信他们讲的也比较好，如果我要描述三次握手我会另写一片狗屁文章的。所以这里就不详细介绍了哈！但是你只要理解一个道理，你把三次握手看作是你找女朋友就好了。
1、男：你做我女朋友好不好
2、女：好的
3、男：那我们去玩吧

MVC

首先定位BUG需要了解一个标准的系统大致的一个数据流是怎么样的。相信对MVC比较了解的同学来说理解起来不是特别难。为什么说要了解什么是MVC呢？首先MVC又是什么呢？
M：model 模型
V：view 视图
C：controller 控制
你可以简单的把M看成一个数据，C看作成串后端代码，V看作是前端代码。一个完整的请求会是从前端到后端再到数据库。
首先不论你是APP还是电脑PC。用户看见的都是图形界面（view），用户该修改数据是通过图形界面（View）请求数据到后端代码（Controller）然后后端会去控制并判断当前请求是否合法，应该得到什么样子的数据，再去数据库（后端的model）获取数据。后端代码（controller）会将数据处理成前端（view）所需要的数据格式返回给前端图形界面。
以上便是一个最基本的一个数据操作的一个数据流，当然实际上你们的系统不会这么简单。里面会包含各种中间件的操作，比如说redis、es等中间件的组合。具体的数据流需要看公司的一个整体架构。你可以按照这个数据流举一反三。

当然以上是定位bug需要的基本知识、测试需要的知识需要更为全面，还有其他知识需要整合。目前我先说这些。以后有时间子啊迭代更新！

总结

怎么判断BUG问题

了解当前系统的架构，不仅仅是代码架构还有部署架构。一个问题的发现需要从不同的角度思考可能导致出现问题的原因。最好的就是从现有的一些条件查找。实在不行就是层层“剥削”
一个请求经历了什么？
操作——电脑——软件（例如chrome）——执行前端代码——网络——域名解析——网络——负载均衡——nginx——后端——数据（redis、mysql、sql）——网络——执行前端代码——渲染
这里的每一层都有可能出现问题，具体原因具体分析。根据现有的条件（抓包、日志、debug等）去判断问题出现的可能。
一般来说对于普通的测试人员要求只要判断该bug属于前端还是后端即可。例如发现问题、去校对需求、查看前端请求（检查地址、参数、方式、格式）、查看后端返回（参数、格式、是否和预期结果一致）、查看前端渲染结果。具体怎么去查看请求数据和返回数据，如果是web网页或者H5可以使用chrome的F12，或者使用抓包工具。
请求的参数

后端返回的数据