Charles入门-APP抓包实战

牛肉大汉堡

已于 2024-10-01 12:59:21 修改

阅读量449

点赞数 19

文章标签：测试工具功能测试

于 2024-10-01 12:57:36 首次发布

本文链接：https://blog.csdn.net/weixin_43812150/article/details/142665040

版权

文章目录

前言
Charles界面组件介绍
- 顶部导航栏
- - 请求栏
实战
总结

前言

装完了Charles，接下来就要开始抓包分析了，但是面对Charles界面时却无从下手，既不懂各个组件有什么用，也不懂抓取到的包该怎么分析。本文就一个APP抓包的具体例子介绍Charles的基本使用方法。

Charles界面组件介绍

顶部导航栏

在这里插入图片描述
:清空请求列表中抓取到的请求

红色时：监听请求，我们访问的内容会在请求列表中展示。
灰色：停止监听，我们访问的内容不会在请求列表中展示。

锁上状态：访问的内容都先请求到了Charles，Charles 拦截并查看通过 HTTPS 加密连接传输的数据，解密这些 HTTPS 流量，然后再由Charles转发到目标地址。
开启状态：访问的内容就直接请求到目标地址了。
eg:苹果手机连上Charles后, 别的APP都能正常访问唯独AppStore访问的时候提示是无法连接,放在之前我会打开手机的设置–网络–关闭代理,然后下载一个APP后在到设置–网络–配置一遍代理.但是现在我只需要将锁打开下载完APP后我在锁就搞定了。

高亮的时候就是开启限制流量功能。
灰的时候就是关闭限制流量功能。
模拟3g/4g网是在Proxy-Throttle Settings中设置。

高亮的时候就是开启请求拦截功能。
灰的时候就是关闭请求拦截功能。

（还没用到，简单介绍）：

选择某个请求后点击这个图标就是可以自定义方式发送请求。有的时候我们想要更改请求参数再次请求时就可以使用这个方法,如果不适用这个方法就是将要修改参数的请求进行拦截然后修改参数. 这样就省去了拦截那一步。

选择某个请求后点击这个图标就会重新请求一次

一些常用的工具开关点击这个图标就可以

设置

请求栏

在这里插入图片描述

Structure视图将网络请求按访问的域名分类
Sequence视图将网络请求按访问的时间排序
Filter是过滤功能，Filter栏中填入需要过滤出来的关键字。例如我们的服务器的地址是：http://*.zitech.com，那么只需要在Filter栏中填入zitech.com即可。

实战

Bug介绍

在某APP（测试端）订票时，只要添加两个及以上的乘客时就会报如下错误

我们使用Charles进行抓包，如下图：
在这里插入图片描述
我比较习惯Structure视图，Fliter筛选出我们要找的域名，打开之后找到newOrderService文件夹，为什么找这个文件夹呢，因为我们是订单生成这一步出错的，所以找有关订单的文件夹。如果遇到其他目标文件夹不太清楚的情况呢？emmm，那就一个一个找吧；或者重复刚刚的请求，发送请求时，Charles目标文件夹会高亮一下；实在找不到就在Sequence中找，先用扫把清一下请求，再重新发送请求，Sequence视图将网络请求按访问的时间排序的，最新的就是你刚刚发送的了。

Overview视图

在Overview视图中，我们需要关注的有下面几个方面：

URL：看URL可以确定请求来源，清晰地看到请求是从哪个具体的页面或应用发起的。
Status：状态，主要有如下5个状态：

Complete：表示请求已成功完成，客户端接收到了服务器的完整响应。这是最常见的成功状态，意味着请求的发送、服务器处理和响应的接收都没有出现问题。
Timed Out：表示请求在规定的时间内没有得到服务器的响应。这可能是由于网络问题、服务器负载过高或者请求本身出现问题导致的。
Connection Failed：表示客户端无法与服务器建立连接。这可能是由于服务器不可用、网络故障或者客户端配置错误等原因引起的。
Unknown：当 Charles 无法确定请求的具体状态时，可能会显示为 “Unknown”。这通常是由于请求过程中出现了异常情况或者 Charles 无法解析请求的状态信息。
In Progress：表示请求正在发送或服务器正在处理请求，尚未完成。在请求开始后但还未收到响应之前，状态可能会显示为 “In Progress”。
例如，当你打开一个大型文件的下载时，在下载过程中，请求的状态可能会显示为 “In Progress”，直到下载完成变为 “Complete”。

Response Code:响应码,定位Bug是前端Bug还是后端Bug，Response Code的种类如下：
3.1 2xx - 成功状态码：
- 200 - OK:表示请求已成功，服务器已成功返回请求的数据。例如，当你请求一个网页时，如果服务器成功返回了该网页的内容，响应码通常就是 200。
- 201 Created：表示请求已成功，并且服务器创建了新的资源。比如，向一个服务器提交表单数据以创建一个新的用户账户，如果创建成功，服务器可能会返回 201 状态码。
- 204 No Content：表示请求已成功，但服务器没有返回任何内容。通常在一些请求成功但不需要返回具体数据的情况下使用，比如 DELETE 请求成功删除资源后可能返回这个状态码。
3.2 3xx - 重定向状态码：
- 301 - Moved Permanently：表示请求的资源已被永久移动到新的 URL。客户端应自动重定向到新的 URL。例如，当一个网站的域名发生变化时，服务器可能会返回 301 状态码，指示客户端以后访问新的域名。
- 302 - Found：表示请求的资源临时被移动到了另一个 URL。客户端应临时重定向到新的 URL。与 301 的区别在于，302 表示的是临时重定向，而 301 表示永久重定向。
- 304 - Not Modified。表示客户端的缓存资源仍然有效，服务器没有返回新的内容。当客户端发送一个带有条件请求头（如 If-Modified-Since 或 If-None-Match）的请求时，如果服务器发现资源没有被修改，就会返回 304 状态码，让客户端使用缓存的资源。
3.3 4xx - 客户端错误状态码：
- 400 - Bad Request：表示客户端发送的请求有语法错误或参数不正确。例如，请求的 URL 格式错误、请求体中的数据格式不正确等都可能导致服务器返回 400 状态码。
- 401 - Unauthorized：表示请求需要用户认证。如果客户端没有提供有效的认证信息，服务器可能会返回 401 状态码。例如，访问一个需要登录才能访问的页面，如果没有登录就会收到这个状态码。
- 403 - Forbidden：表示服务器理解请求，但拒绝执行。通常是由于客户端没有足够的权限访问请求的资源。例如，试图访问一个受保护的文件或目录，但没有相应的权限，服务器可能会返回 403 状态码。
- 404 - Not Found：表示服务器找不到请求的资源。当客户端请求一个不存在的 URL 时，服务器通常会返回 404 状态码。
3.4 5xx - 服务器错误状态码：
- 500 - Internal Server Error：表示服务器内部发生错误，无法完成请求。这是一个比较笼统的错误状态码，可能是由于服务器代码中的错误、数据库连接问题、服务器配置错误等原因引起的。
- 502 - Bad Gateway：表示作为网关或代理的服务器从上游服务器接收到无效的响应。例如，当一个代理服务器无法从后端服务器获取正确的响应时，可能会返回 502 状态码。
- 503 - Service Unavailable。表示服务器暂时无法处理请求，通常是由于服务器过载或正在进行维护。例如，一个网站在进行系统升级时，可能会返回 503 状态码，告诉客户端服务暂时不可用。
Method :主要有下面四个方法（四个中还有一个还没遇到过🦅🦅🦅），还有两个是HEAD和OPTIONS方法。

Get:获取服务器上某个资源
POST:向指定资源提交数据，请求服务器进行处理。对参数进行封装，URL地址中间看不到请求的参数。
PUT:用于更新服务器上的资源，通常是全量更新，即覆盖整个资源(没遇到过)
DELETE:用于删除服务器上的指定资源

Kept Alive：性能测试时关注，YES意味着在完成一次请求和响应后，连接会不会立即关闭，而是可以被复用用于后续的请求（这里就不讲了，等我学到性能测试再来和大家分享）。
Content-Type:看字符编码
Remote Address：代理地址，与客户端进行通信的服务器的 IP 地址和端口号。
Timing：请求的开始时间和结束时间；Duration，一个网络请求从开始到结束所花费的时间

Bug分析定位

OK,说完了这些让我们分析下这个Bug，Status是Complete，Response Code是200，说明请求已成功，服务器已成功返回请求的数据，这时打开Content
在这里插入图片描述
上面一部分的JSON Text是入参，下面是出参。在出参里找到了"errorInfo": "生成订单结果:网络异常，请稍后再试",说明前端的显示没有错误，是后端的逻辑判定出错了。这时候我找到我们的后端开发大哥，简单说明了Bug是怎么出现的，给他看了这两张截图，然后大哥让我把入参发给他，也就是上面一部分的JSON Text全部复制过去。定位到下面的问题
在这里插入图片描述
具体到订单的后端那边，然后又屁颠屁颠找订单的后端开发，至此顺利的将Bug定位完成。

总结

作为新手测试，不知道该怎么定位Bug是前端还是后端；而一个较大的项目里有前端开发，后端开发；后端里有专门负责接口部分的，有具体业务划分的比如专门负责订单或者专门负责辅营产品的。如果不能正确的分析Bug，就会导致报错时不知道找谁，提到的问题就会被踢皮球，大大的浪费时间。
Charles也不能直接帮我们定位Bug类型，但是通过对抓取到的请求进行分析，大部分情况下都能正确的定位到Bug类型，从而节约了找开发掰扯的时间。EMMM😄写这篇文章是已经是我来公司的第50天了（包括周六周日），加油加油！！欢迎各位大佬讨论学习！！