关于android:APP测试

一、麻利开发模型

• 作用：形容公司中产品、开发、测试、运维等相干人员如何协同配合实现软件开发过程

• 利用场景：需要不稳固，工夫周期短(疾速高效)

  1.1 瀑布模型和麻利模型

• 瀑布模型：需要稳固【无奈应答需要变动】，我的项目周期长【测试染指是从开发编写完代码之后开
  始】
• 麻利模型：需要不稳固，工夫短速度快，要求疾速反馈，疾速试错，疾速改良

1.2 麻利开发模型介绍

• 定义：以用户的需要进化为外围，采纳迭代，循序渐进的办法进行软件开发

• 特点：小步快跑，互相独立

  1.3 麻利开发模型的框架 –scrum

• 定义：一个麻利的，疾速迭代的增量开发模型

  • 迭代（sprint）：我的项目开发过程中的最小周期，个别为 2~4 周，一个软件我的项目开发能够继续若干个迭代

  • 3 种角色 5 种会议

    • 3 种角色：产品经理【PO】、项目经理【SM】、我的项目小组【DT】

      一个 scrum 小组个别是 7~9 人
      有一个产品经理
      有一个项目经理（属于开发团队）开发和测试人员（3:1~5:1）

二、我的项目环境

2.1 后端

组成：OS-linux , 应用服务器：Nginx/Apache, 数据库服务器：Mysql, 我的项目代码：PHP

2.2 环境分类

• 开发环境：开发人员编写代码、调试代码的环境
• 测试环境：测试人员测试执行，回归测试的环境
• 预生产环境：行将公布的新代码，连贯生产数据库，次要由测试人员用于测试业务流程
• 生产环境：正式用户应用的环境，也叫正式环境【测试偶然会有，会复现 bug 或者公布之后验证流程】
  

2.3 后端环境的公布

灰度公布策略：危险低，对于用户应用过程不影响（用户是无感知）面试题：你们公司我的项目实现后是怎么上线的？

本人总结：首先让局部服务器下线，用于更新代码，更新之后让这部分服务器上线，同时把残余的服务器下线，测试须要和用户一样测试已上线更新过后的服务器，如果新服务器呈现问题立刻下线，持续把原有的服务器上线，如果不呈现问题就把残余的服务器全副更新上线。

三、专项测试

3.1 装置

3.2 卸载

3.3 降级

3.4 兼容性测试

APP 在不同的软硬件平台上应用是否失常
指标获取：https://tongji.baidu.com/research/app

兼容分类：

• 品牌及机型：市场支流机型（市场排名前三的找进去）

• 操作系统：市场支流操作系统

  不同的操作系统，同一操作系统的不同版本
  Android：4.4 以上
  iOS：8.5 以上
  HarmonyOS（鸿蒙）：2.0 以上
  

• 尺寸与分辨率
  留神：

  1. 个别第一个版本测试涵盖（占比 90%）比例分辨率和尺寸
  2. 更新的版本次要思考测试支流机型分辨率和尺寸（排名靠前三位）

• 网络(弱网)
  

• 利用兼容：和其余软硬件兼容

  • 与手机硬件：音量、开关机键、home 键等
  • 与内部硬件：耳机、音响、蓝牙设施等
  • 与操作系统组件：WLAN 设置、零碎工夫调整、定位服务等
  • 与其余 APP：以后 APP 音视频和正在进行的其余音视频软件

兼容性扩大
指标的获取：https://tongji.baidu.com/rese…
测试工具抉择
真机：继续一段时间市场占有率最高的几款机型购买
模拟器：市场占有率不高，然而又须要笼罩的机型能够通过手机模拟器去测试
云测平台：介于上述之间的，能够通过云测平台进行测试（免费）

3.5 穿插事件测试

A. 穿插事件测试：也叫抵触测试或干扰测试，指一个性能失常执行过程中，另外一个事件对该过程的干扰测试
B. 中断事件处理实现之后，个别会复原到以后中断的地位继续执行

3.6 Push 音讯

app 推送给用户的各种提醒音讯

3.7 用户体验

参考规范
- 考察询问用户
- 应用竞品公司软件比照

四、app 性能测试

从工夫和空间层面思考 app 的失常应用

4.1 CPU

• CPU 呈现性能问题景象

  • 超过 90%
  • 手机发烫
  • 耗电量减少
  • 反馈变慢

• CPU 验证的参考根据

  • 程序耗费 CPU/ 总 CPU

    • 屡次运行之后的 CPU 使用率平均值（依据教训和产品确认）
    • 同样的操作参考竞品公司同类软件的 CPU 使用率，进行比拟
• 论断：CPU 的使用率越小越好

4.2 内存

• 内存呈现故障景象

  • 内存泄露

    • 同一软件或者不同软件申请应用内存后没有齐全开释，导致内存空间越来越少的景象

  • 内存溢出

    • 因为某种原因（内存泄露），导致后续的软件无奈申请新的内存空间的现像

• 内存验证的根据

  • PSS(理论应用内存) = 公有内存 + 共享内存

    • 屡次运行之后的占用内存比例平均值
    • 同样的操作参考竞品公司同类软件的内存占用率，进行比拟
• 论断：内存的占有率越小越好（绝对
  

4.3 流量

• 测试分类

  • 上行（例如上传，发送文件）
  • 上行（也叫下载，个别上行消耗流量最多）
• 规范
  

• 流量优化办法

  • 数据的压缩
  • 不同数据格式的采纳
  • 管制拜访的频次
  • 只获取必要的数据
  • 缓存机制
  • 针对不同的网路类型设置不必的拜访策略
• 论断：同类型产品运行过程消耗流量越小越好

4.4 电量

• 规范：要求运行的 app 消耗电量越少越好（mAh : 毫安时）

• 耗电场景

  • 定位，尤其是调用 GPS 定位
  • 网路传输，尤其是非 wifi 环境
  • 屏幕亮度
  • CPU 运算：简单的运算逻辑，死循环等会间接导致 CPU 负载过高，会导致耗电
  • 锁屏 - 截屏工夫和次数

• 验证电量指标

  • 和产品沟通，获取历史的根底数据确定规范
  • 和竞品公司做同样测试电量测试进行比照，查看耗电量的高下
• 论断：个别产品 app 耗电量越少越好

4.5 晦涩度

通过 FPS 形容每秒钟图片的数量（有关联的间断图片依照肯定的工夫间断切换时会产生动态效果）FPS : 每秒帧数（图片数）frame per second
常见应用程序：游戏类、播放类

• 人类肉眼有感知：10~12 帧
• 根本流程达到：24 帧
• 达到十分流程水平：举荐 60 帧以上
• 论断：个别软件应用晦涩度能达到 24 帧以上即可

五、ADB

什么是 ADB？Android Debug Bridge，Android 调试桥，用来管理控制 Android 的模拟器或者 Android 的设施
ADB 蕴含三局部：adb 客户端（cmd 窗口界面，负责输出编写 adb 命令）；adb 服务器（负责传输 adb 命令到模拟器 /Android 设施终端）；adb daemon（负责执行 adb 命令的模拟器终端 / 手机终端）；为什么须要 ADB 工具？通过命令模式操作治理挪动端设施
APP 的性能测试须要用 adb 相干命令
环境变量：以命令行的模式疾速启动软件应用程序【例如：adb 程序

5.1 ADB 命令

# 在装置了雷电模拟器的门路下进入 cmd
# 1. 查看设施是否接入，如果 offline，能够重启雷电模拟器之后重试
# 正确结果显示：emulator-5554 device 或 127.0.0.1:5555 device
    adb devices
# 2. 查看以后挪动设施装置的软件包，pm :package management
    adb shell pm list packages
# 3. 查看以后曾经关上的某个 APP 的包名和 Activity 名（流动页面）adb shell dumpsys window w | findstr mFocusedApp
# 查看启动上述包的工夫 
    adb shell am start -W 包名 /Activity 名
# 对于稳定性测试，模仿人随机操作 1000 次
    adb shell monkey -p 包名 --ignore-crashes --ignore-timeouts --throttle
    400 -v 10000
# 查看 monkey 过程的编号（PID）adb shell ps | findstr monkey
# 完结 money 命令（将上述输出的 PID 填写后完结）adb shell kill 过程 PID
# app 软件装置 / 卸载
    adb install 软件门路
    adb uninstall  包名
# 获取 app 的日志
    adb logcat

5.2 启动速度测试

• 启动分类

   手动操作开始到显示出所有后果的工夫过程，叫做启动测试 

  • 冷启动：app 没有运行（曾经被杀死），在运行启动的过程
  • 热启动：app 在后盾运行，通过界面关上启动的过程

• 查看以后曾经关上的 APP 软件包名和界面名

  adb shell dumpsys window w | findstr mFocusedApp

• 测试 app 的启动工夫

adb shell am start -W com.pingxixi.malls/.SPMainActivity

ThisTime：示意程序启动工夫
TotalTime：程序启动工夫 + 资源初始化工夫
论断：启动速度越快越好（具体规范由产品定）

5.3 稳定性测试

稳定性测试（伪随机测试）：模仿人工操作进行长时间运行 APP 程序，看会不会呈现闪退，无响应（ANR）等景象的过程
闪退：crash，忽然间退出
无响应：ANR，Application Not Response 的简称

• 通过 monkey 工具测试：长时间模仿人的各种操作（点击、滑动、输出等操作）
• 稳定性测试工夫：个别在 APP 根本稳固没有太多 bug 时，就能够进行 monkey 的稳定性测试

• 演示 monkey 测试

    对于商城 APP 稳定性测试，模仿人随机操作 10000 次

  adb shell monkey -p com.pingxixi.malls --ignore-crashes --ignore-timeouts 
  --throttle  400 -v 10000 > d:\aaa.txt
  # -p：前面指定包名
  # --ignore-crashes：疏忽闪退（crash），即闪退后 monkey 持续发送测试事件直到实现
  # --ignore-timeouts：疏忽超时（ANR），即超时后 monkey 持续发送测试事件直到实现
  # --throttle 400：随机提早提早 400ms
  # -v : 示意记录反馈日志的具体水平，-v -v -v 最具体
  # 100000：伪随机的事件次数

  对于测试过程中常见的日志信息能够搜寻一些关键词确认是否有问题
  error：谬误
  failed：失败
  crash：闪退
  timeout：超时（ANR）