笔者认为对Web还是App测试思路通常应先按照测试类型来进行考虑。
| 类型 | 内容 |
|---|---|
| 功能测试 | 业务逻辑的正确性测试；以某商品网站搜索功能为例： **单功能测试：**考虑单个关键字和多个关键字等；功能交互测试：考虑搜索已下架的商品、搜索已删除的商品等；用户场景测试：考虑在登录之后的搜索，未登录时候的搜索等。 |
| 性能测试 | 负载测试、压力测试、容量测试等通过Emmagee、Solopi、Monkey监测性能指标，包括时间(adb logcat|finstr exception)、存储空间(du -sh/adb shell)、CPU、GPU占用、流量、电量消耗等 |
| 兼容测试 | 对App，通过腾讯云、华为云等云测平台，测试操作系统版本、机型、分辨率等兼容性 |
| 网络测试 | 对App，通过NEWT、ATC、Qnet、Fiddler等，测试不同网络下（2G、3G、4G、WiFi）的表现，弱网、无网、网络切换的测试 |
| 安装测试 | 对App，各版本的安装/卸载/升级测试，启动检查测试 |
| 中断测试 | App遇到断网、断电、闪退、通话、收到异常数据 |
| 用户体验测试 | 操作是否方便，界面是否美观 |
以钉钉中发送消息功能为例：
单功能测试：考虑发送文本、图片、语音、视频消息等；
功能交互测试
与手机本身功能的交互，如通话、短信、闹钟等。在编辑待发送消息时接听、拒接电话等；
与手机助手App功能的交互，如限制低电量时不允许使用网络，此时发送消息；
与App本身功能的交互，给已拉黑自己好友发消息、给已删除自己好友发消息、给被封号好友发消息等；
用户场景测试：如连续发送消息、撤回已发送消息再发送等；
特殊的测试点：手机横竖屏、分屏；通知栏；长按、滑屏、双击等对应的App功能操作。
移动App测试，仅通过界面上测试往往不够，常常还需要使用抓包工具，抓取App、Server之间数据的交互，更详细的测试。常用抓包工具有 Fiddler(Windows)、Charles(Windows、Mac)。有关Wireshark可参考我另一篇《Wireshark 抓包过滤器使用》。
Fiddler -> Tools -> Options -> Connections 中，全勾选【允许远程计算机(包括真机/模拟器)连接】，默认监听端口是 8888
adb.exe 所在路径
adb (Android debug bridge) 路径，注册到环境变量（用户或系统级别）
启动模拟器后，运行 adb devices 验证模拟器连接正常，adb install 安装待测试应用 ECMoblie_v3.2.apk
查看所连接设备App的抓包，首先要使【安卓端模拟器代理】和【PC端Fiddler代理】保持一致。
192.168.137.1:8888与一致
笔者总结以往工作经历，Fiddler大致有四类测试应用场景：
| Fiddler模块 | 应用场景 | 具体使用 |
|---|---|---|
| Inspectors | 抓包辅助定位Bug原因 | ①通过参数分析是前端还是后端；②参数是否加密；③在没有接口文档时抓包获得Http后台接口 |
| AutoResponder、BreakPoints | Mock模拟构建测试场景 | ①绕过前端测试功能在服务端处理异常请求的场景；②前后端开发进度不一致，没有HTTP后台服务情况下；③或要快速验证完信息匹配测试 |
| Simulate Modem Speeds | APP弱网测试 | 设置模拟调制解调器的速度，模仿不同网络速率 |
| Statistic、Timeline | 前端性能分析调优 | 客户端开始请求、服务器获取请求、开始响应、完成响应等时间点 |
合格的测试攻城狮，不仅需要能发现Bug，还需要能透过Bug表象，分析定位出Bug的根本原因，从而提升开发的Bug的解决效率。因此提Bug时，不能直接把APP页面报错信息截个图就了事，而不去定位Bug。
通过Fiddler->Inspectors抓取request、response，分析参数可以定位Bug是前端还是后端问题。
例如：APP内输入数据，点下一步时，提示错误；这时候不能判断问题的根本原因在哪里？
是前端页面限制导致？**前端request参数问题？或者后端程序挂了？**此时可通过Fiddler抓包，分析请求、响应判断Bug的根本原因。
Fiddler - Inspectors 模块 支持多种不同格式如 Raw、WebForm来查看请求数据、响应数据信息。
有时由于被测试App版本过旧问题，App访问服务器不成功。可在Fiddler -> Tools -> Options -> Hosts 设置 App 所访问服务器 shop.ecmobile.cn 与所测试服务器 118.25.179.224 映射关系。重启ECMoblie.apk 即可正常访问App的服务器网络。
在过滤器 Filters 勾选 Use Filters 并选择 show only the following hosts 可只查看指定服务器的抓包，如 shop.ecmobile.cn;cloud.ecmobile.cn
如图Inspectors 模块请求部分的 Headers(请求头)，JSON(响应数据)，还可以查看WebForms、Raw等格式
Fiddler -> Tools -> Options -> HTTPS 勾选 Capture HTTPS CONNECTs 及 Decrypt HTTPS traffic，允许捕获 HTTPS 连接并破解 HTTPS
Fiddler 根证书
Options -> HTTPS -> Actions 点 Open Windows Certificate Manager打开 certmgr 证书管理中心
查看已安装的 DO_NOT_TRUST_FiddlerRoot certificate 证书
访问 HTTPS 协议站点如 https://www.baidu.com，用 Fiddler -> Inspectors 查看返回的 https 响应信息
为保证测试覆盖率，要验证某个功能在各种场景下的业务处理能力，包括正常、异常场景，但这还不是所有场景。
如：对某个功能在服务端处理异常请求的场景，只通过页面端（前端）来发起是不行的
如：对前后端开发进度不一致，没有HTTP后台服务情况下或要快速验证完信息匹配测试，需要模拟服务器端响应
通过Fiddler的Breakpoints、AutoResponsder等修改request、response参数来模拟构建测试场景。
第一种，Rules->Automatic BreakPoints->Before Requests 或 F11 （会中断所有会话）
也可以在工具最下方切换图标来控制断点状态
第二种，bpu URL命令行输入“bpu命令+Host地址”如 bpu https://s.taobao.com（只会中断该会话）
未启用断点拦截请求(Disabled)前，请求参数不可修改
启用断点拦截请求(Before Requests)后，可突破前端对表单输入的限制，在Inspectors->WebForms将请求参数修改为特殊边界值等测试数据，点Run to Completion发送修改后请求，测试后端响应是否符合预期
下图为Fiddler请求断点设置成功的提示
第一种，Rules->Automatic BreakPoints->After Responses或Alt+F11（会中断所有会话）
第二种，bpafter URL命令行输入“bpafter+Host地址”（只会中断该会话）
启用断点修改响应(After Responses)后，可在Inspectors->TextView修改响应体内容
如图浏览器会一直处于加载状态，请求会被挂起
例如：在响应体中修改某商品为“100000000人付款”，点Run to Completion回送修改后的响应，测试页面展现的变化情况；实际当中响应修改会更复杂一些，此处仅为示例。
如图，响应的Web页面已经对应发生变化了
下图为Fiddler响应断点设置成功的提示
AutoResponder模块可快速模拟服务器在各种情况下响应的数据，给APP发送伪造的响应数据，从而测试不同场景下APP的响应。
以测试把商品订单添加到购物车后，结算为待付款状态为例，一件件加显然不可能，可修改响应体中待付款数字1为1000：
注册一个账户登录并购买一个商品不付款
在 Fiddler 中能查到对应操作的抓包列表
找到购物车对应的抓包信息，在 Inspector 模块下查看 Headers (请求信息头) 和 JSON (响应数据)
Fiddler 抓包列表选中要篡改的记录 ，右键 Save 完整的“Response”响应数据Cui_My_Response.txt
AutoResponder->Add Rule，将刚保存的响应数据 Cui_My_Response.txt 添加为响应规则 
Inspectors->JSON选择要修改的抓包项，在它响应数据中的 JSON，发现对应待付款字段是 await_pay=0
编辑Cui_My_Response.txt 修改响应体中 "await_pay":"0" 为 "await_pay":"1000"，保存后关闭
模拟器App个人中心查看“待付款”的结果已经变成1000，初步测试出了UI出现了错乱
App测试与Web测试的不同点之一是：网络的多样性。不同网络环境、制式的差异，都会对App造成一定影响。
因此需要保证各种情况下（2G-4G、WiFi、网络切换，DNS劫持，IP更换等）功能正常使用、响应时间合理。
如：地铁、郊区、电梯，若没有对各种网络异常进行兼容处理，那么用户可能在日常生活中遇到闪退、ANR、数据丢失等问题。
Rules->Customize Rules或Ctrl+R查找到代码，设置网络上行/下行速率
上行速率默认：1kb/0.3s，即只有3.3kb/s
下行速率默认：1kb/0.15s，即只有6.6kb/s
Rules->Performances->Simulate Modem Speeds启动使用模拟调制解调器的速度
在弱网条件下操作App，通过查看第一个和最后一个请求的Statistics，获得完整加载的耗时。
或对同一个接口，对比开启弱网前后的数据。通过Timeline条形图表可以直白观察到耗时最多的请求，为页面访问速度的优化提供依据。
前端性能数据可通过Fiddler->Statistics、Timeline获取，从而为性能分析及优化提供依据，提升用户体验。
指标时间包括了：客户端连接、客户开始请求、获取请求头、HTTPS握手、服务器获取请求、服务器开始响应、服务器完成响应、总运行时间等等
ACTUAL PERFORMANCE
--------------
ClientConnected: 02:25:15.251
ClientBeginRequest: 02:27:11.869
GotRequestHeaders: 02:27:11.869
ClientDoneRequest: 02:27:11.869
Determine Gateway: 0ms
DNS Lookup: 0ms
TCP/IP Connect: 23ms
HTTPS Handshake: 79ms
ServerConnected: 02:27:11.889
FiddlerBeginRequest: 02:27:11.969
ServerGotRequest: 02:27:12.929
ServerBeginResponse: 02:27:12.929
GotResponseHeaders: 02:27:12.929
ServerDoneResponse: 02:27:12.929
ClientBeginResponse: 02:27:12.929
ClientDoneResponse: 02:27:13.249
Overall Elapsed: 0:00:01.379
博主CSDN@崔同学原创手动码字，喜欢记得点赞收藏哦 😃