测试执行_3APP功能测试

APP问题定位

一、发现问题

需要借助工具来定位bug是客户端APP本身问题还是后台服务器问题。

二、分析问题

使用Charles工具对APP请求里的request和response，若无法定位问题根源，则使用adb logcat查看日志。

1 问题定位工具一——Charles

1.1 介绍

通常，APP请求发送到服务器，服务器进行处理后再返回给客户端APP；

Charles代理服务器起中转站作用。

1.2 Charles安装

1.2.1 所需环境

Charles工具由Java开发，需要Java环境。

1.2.2 下载及安装

a 浏览器打开Charles下载页

http://www.charlesproxy.com/download/

b 根据自己电脑系统平台选择下载

c 双击安装包，按照提示进行安装即可

1.3 Charles配置

1.3.1 点击菜单栏中Proxy -> Proxy Settings... 进行代理设置；

HTTP代理的默认端口是8888，可按照自己喜好修改，但不要与其他连接端口重叠。

1.3.2 点击菜单栏中Proxy -> 取消选择Windows Proxy

Charles可以与Android手机连接，也可与夜神Android模拟器连接。

这里，我使用夜神模拟器，因为目前没有Android手机，以后借到Android手机更新手机相关测试。

1.4 夜神Android模拟器安装

a 浏览器打开夜神模拟器下载页

http://www.yeshen.com/#p2

b 点击页面上方的“立即下载”

c 双击安装包，按照提示进行安装即可

1.5 夜神模拟器安装应用程序

a 打开模拟器，点击右侧“安装apk”按钮

b 选择要安装的apk

c安装完成后应用即可使用

1.6 Charles连接夜神模拟器

a 查看电脑IP地址，在cmd中键入ipconfig获取IPv4地址

b 手机自动连接名为“WiredSSID”的wifi

c 点击手机页面中”设置“图标 -> 选择WLAN项并长按该wifi -> 选择”修改网络“ -> 点击“显示高级选项” -> 修改“代理“为手动，”代理服务器主机名“填入本电脑IP，“代理服务器端口”填入之前设置的端口号8888

此时，Charles自动弹出窗口，询问是否允许接入，点击”Allow“后手机发出所有请求都被Charles拦截。

2 问题定位工具一——ADB

ADB类似手机助手，可看到手机的底层信息，开发人员经常使用ADB调试代码，测试人员使用ADB发现bug根源；

注意：省略对ADB安装讲解。

a 打开命令行窗口cmd

b 输入adb验证ADB是否安装成功

c 打开夜神模拟器

d 输入adb connect 127.0.0.1：62001使夜神模拟器连接ADB工具

e 输入adb devices验证是否连接

f 输入adb logcat > F:\AndroidTest\log.txt将ADB输出的log保存到F:\AndroidTest\l目录下的log.txt文件中

注意：可对log进行过滤输出，Android输出的每一条日志都有一个标记与优先级相关联；

V —— 明细 verbose（最低优先级）

D —— 调试 debug

I —— 信息 info

W ——警告 warn

E —— 错误 error

F —— 严重错误 fatal

S —— 无记载 silent

如：输入adb logcat *:W显示所有优先级大于等于warn的日志；

g 问题复现后，在命令行窗口敲ctrl+C退出ADB，到相应目录下查看log

案例：

MiniBlog APP案例一

1 操作

点击MiniBlog APP，以注册过的用户名和密码进行登录，但显示“登陆失败”；

2 猜测

是APP没有发送请求给服务器？还是服务器无法识别，没有返回？

3 复现bug——登陆异常

3.1 使用Charles抓包解析：

Charles与夜神模拟器连接后，输入用户名和密码并点击“登录”按钮，可看到Charles截取到APP的请求。

在Structure查看方式中，Overvie提供了URL链接、提交方式Method、服务器返回码Response Code等；

具体地，Request请求中用户名、密码信息是对的；Response响应中有错误提示信息——HTTP Status 404 - user not exist；

事实上，我们使用的是已注册过的用户名和密码进行登录，可判定为是服务器的bug，经与开发人员核对后发现服务器没有到数据库查询已注册用户。

4 报bug

MiniBlog APP案例二

1 操作

点击MiniBlog APP，在登录页面以注册过的用户名和密码进行登录，提示“登录成功”；

在日志列表页面点击右上角的“刷新”按钮，无反应。

2 猜测

是APP没有发送请求给服务器？还是服务器没有返回？

3 复现bug——点击刷新无响应

3.1 使用Charles抓包解析：

Charles与夜神模拟器连接后，输入用户名和密码并点击“登录”按钮，此时Charles截取两个请求，一个是登录，一个是获取博客列表信息；

点击“刷新”按钮，Charles没有截取到任何信息。

可判定为APP客户端的bug。

4 报bug

MiniBlog APP案例三

1 操作

点击MiniBlog APP，在登录页面以注册过的用户名和密码进行登录，提示“登录成功”；

在博客列表页面，点击日志进入日志详情页面，提示“刷新中。。。”。

2 猜测

是服务器没有返回内容给APP？

3 复现bug

3.1 使用Charles抓包解析：

Charles与夜神模拟器连接后，输入用户名和密码并点击“登录”按钮；

进入博客列表页面，点击查看博客详情，可看到Charles截取到一个信息，Overview中URL链接是正确的，ResponseCode返回200 OK表示成功，Method是GET；因此Request请求中无内容；Resopnse中可看到博客内容、标题，表示服务器返回信息是正确的，可判定服务器没有问题。

APP客户端存在什么bug导致的？

3.2 使用ADB Logcat查询日志：

ADB与夜神模拟器连接后，APP进入博客列表页面，在cmd命令行窗口输入adb logcat *:W > F:\test\log.txt；

回到APP，点击博客详情，bug出现后，在cmd输入ctrl+C结束日志查询；

打开日志，查看到如下信息：

org.json.JSONException: Value 啦啦啦 at title of type java.lang.String cannot be converted to int

说明string类型的字段不能转换为int类型的字段；

4 报bug

APP兼容性测试

一、为什么做兼容性测试？

IOS端每年都会发布新的移动设备；

Android端有很多手机品牌，Android是免费开源的，手机厂商会对Android系统进行改造，变成独立的Android，造成Android系统碎片化、屏幕碎片化、品牌碎片化。

二、怎么做兼容性测试？

1 机型怎么选择？

1.1 根据项目用户统计、用户反馈问题统计，做针对性兼容性测试；

1.2 调研同类产品的用户使用情况；

1.3 系统兼容性测试、屏幕兼容性测试、型号兼容性测试；

对于系统，关注新版本操作系统，优先测试主流系统；

对于屏幕，优先测试主流分辨率，考虑不同尺寸；

其中，分辨率(px)是指在横向、纵向上的像素点数；尺寸(寸)是指屏幕的对角线长度；屏幕像素密度(dpi)是指每英寸的像素点数；

对于型号，优先测试主流品牌，考虑品牌的主流系列；

2 用例怎么考虑？

选择主干用例覆盖主流程；

在保证主干流程没有问题后，选择大部分页面审查UI显示；

3 什么时候做兼容性测试？

在回归测试阶段进行兼容性测试；

三、典型问题举例

1 系统兼容性bug

1.1 案例一

1.1.1 IOS新特性

默认使用HTTPS请求；

1.1.2 bug描述

在IOS9.0上，”我加入的圈子“页面只显示分隔线，不显示圈子信息；

1.2 案例二

1.2.1 Android 4.4 新系统的修改点

在播放视频时可自行添加字幕；

1.2.2 bug描述

在Android 4.4系统的手机上，点击播放视频，进入播放页给出加载提示后；

2 屏幕兼容性bug

2.1 案例一

2.1.1 bug描述

在低分辨率像素的手机上，信息流列表页，每一条信息的来源过长被覆盖；

2.2 案例二

2.2.1 bug描述

在大屏幕手机上，个人资料修改页面底部不能完全显示；

3 型号兼容性bug

3.1 案例一

3.1.1 bug描述

在iPhone6S手机上，对已经做了3D Touch功能的用户头像重按往上拉，新出现的页面没有私信功能；

3.2 案例二

3.2.1 bug描述

在VIVO手机上，点击搜索，页面上的热词显示整体居于偏上位置；

APP性能测试

一、APP性能反馈

1 卡顿

2 耗流量

3 启动时间长

二、APP性能问题

1 内存问题——导致程序卡顿、崩溃

1.1 内存泄漏

申请的内存空间，使用结束没有释放；

1.2 内存溢出

APP占用内存越来越大，无法限制，导致程序崩溃；

2 CPU问题——导致程序卡顿、崩溃

2.1 CPU占用过高

3 帧率问题——导致页面丢帧卡顿，影响用户体验

（页面显示是一帧一帧的画面组成，该过程叫画面渲染；帧率大小影响页面流畅度）

3.1 渲染时间过长

4 流量问题——加重用户的花费

4.1 流量消耗过多

5 启动时间——影响用户初体验

（点击APP图标到主界面完成显示的时间段，其中有一个或多个页面activity）

5.1 启动时间过长

三、APP性能测试流程

1 内存、CPU

a 制定测试策略

检查新功能流程是否导致内存、CPU问题（一般新功能容易造成内存或CPU问题）

选取主干用例排查

与老版本或同类产品的APP的内存、CPU数据进行对比

b 根据测试策略，使用测试工具排查以下情况：

内存抖动（一下高一下低，不平缓的抖动）—— 内存泄露风险

内存持续升高（关多次打开并关闭页面，是否及时释放内存）—— 内存溢出风险

CPU占用过高

2 帧率

a 制定测试策略

页面遍历

b 根据测试策略，使用测试工具排查以下情况：

每帧的渲染绘制时间不超过16ms

3 流量

a 制定测试策略

主干流程

多资源场景（连续多个图片浏览，音频视频浏览）

安装后首次启动

后台运行

注意：流量测试时需要保证没有其他APP应用的干扰

4 启动时间

a 制定测试策略

安装后首次启动时长

常规启动时长

b 根据测试策略，使用测试工具排查以下情况：

整个过程一般是3~5s

四、APP性能测试工具

1 Emmagee——内存、CPU、流量

1.1 支持Android 2.2系统及其以上系统版本

1.2 监控单个APP应用的CPU、内存、流量等

2 gfxinfo——帧率

2.1 Android系统自带工具

2.2 手机设置 -> 开发者工具 -> GPU呈现模式分析 -> 在屏幕上显示为条形图

3 ADB——启动时间

a 通过adb logcat保存log

b 过滤"Displayed"字段

c 根据activity名称筛选

d 时间累加