接口测试:如何定位BUG的产生缘由

转自公众号《QA之道》

 

咱们从在平常功能测试过程当中对UI的每一次操做说白了就是对一个或者多个接口的一次调用，接口的返回的内容(移动端通常为json)通过前端代码的处理最终展现在页面上。http接口是离咱们最近的一层接口，web端和移动端所展现的数据就来自于这层，那么咱们如何知道在测试过成功UI上的每一次点击都触发调用了那些接口呢？请在下面的场景中找答案。

以下场景：

你负责测试某一个电商网站一个用户的订单列表功能，测试过程当中你发现页面上展现的订单数量与实际数据库里的数量不一致，请你们结合本身平时的工做方式回忆下如何快速的定位该问题是否是BUG或者BUG产生的缘由是什么。

下面说下我认为比较合适的定位方式：
一、 用chrome浏览器打开你正在测试的项目 F12打开开发者工具，切到network 标签，访问订单列表页面，以下图

抓取到展现订单列表的接口，能够看出本次请求一共传递了9个参数，此时打开RD提供的接口文档确认须要传递的参数是否传递的正确，或者参数个数一致，若是不正确，那能够判断是前端的Bug。
有人说若是没有接口文档怎么办？能看得懂代码的直接去看这个接口的定义或者实现，看不懂的就只能找后端开发去确认了
二、 点击Response标签将标签内的内容复制出来，问了更好的查看能够将其粘贴到格式化json的工具上（若是返回类型是json）工具地址：http://json.parser.online.fr/，而后查看这里面展现的记录数是否是跟UI上展现的一致，若是不一致能够判断是前端的Bug

 

三、 若是上一步没有问题，请打开系统的debug日志，获取订单的操做说白了最后落到数据库层面就是一条带条件的select 查询语句，咱们从日志中能够获取到select 语句的参数，这个参数通常状况下就是在调用接口时传递的那9个，此时抓取到本次接口调用产生的sql语句而后放到数据库客户端上执行，分析查询条件和执行结果的关系，这个过程就是找出错误参数的过程。相似的debug日志以下：

从截图能够看出有一些select 语句如：select * from model where id = ? 

总结：测试过程遇到问题时先别急着喊开发，先本身有个初步的判断，或者直接定位到Bug产生的缘由，这样既能够减小一些没必要要的沟通还可让开发直奔Bug的产生缘由，提升问题的解决速度。