APP客户端性能专项测试手册

APP客户端性能专项测试手册

 

 

一、前言

1.1文档目的

通过对本文档的学习，对APP客户端性能专项测试的理论知识，测试工具，测试方法，缺陷分析思路等能有一定程度的了解，并能快速投入到专项测试工作中去。

 

1.2 使用对象

全体测试人员及对专项测试有兴趣的人员。

 

二、专项测试概述

微医集团作为一家医疗互联网中的领头企业，在APP产品研发测试过程中，除了不断完善功能需求外，对应用的性能体验也更为重视。在应用发布之前保证性能的优越和稳定，是测试部的重要职责。本文档旨在对以往的专项测试经验进行总结，沉淀，希望能给大家在工作当中带来帮助。

 

三、专项常规测试流程

目前公司的客户端性能专项测试常规流程主要包括以下几个部分：

l  明确专项测试目的

在新版本发布前，针对该版本的新增及改动点，做基础性能、深度性能测试，保障APP应用性能体验及稳定运行。

l  专项测试场景设计，分析

明确目的后，我们需要以目的为导向，分析业务场景，设计合适的测试策略及场景分布。

l  专项测试脚本开发

根据测试策略，使用不同的工具，完成对应场景的性能脚本开发。

l  测试过程执行

完成脚本开发并通过调试后，执行性能测试脚本。

l  测试结果分析

记录测试过程中得到的性能数据，在确保数据真实、有效的前提下，对数据进行分析。如有异常，提交BUG，并配开发定位问题。

l  输出测试报告

完成测试后，输出测试报告，跟踪遗留问题。

专项测试整体流程图如下：、

 

 

 

四、专项测试准备

4.1 测试资源准备

版本测试前，准备4台手机终端，Android及Iphone手机各两台，两台高配机型主测，两台中低配机型辅测；Windows及Mac笔记本各一台。

Android平台	RAM内存	手机型号	备注
高配手机	4G/6G	华为Mate20/VIVO X21	2019年TOP300中4G机型占比42.3%，6G机型占比27.67%
中配手机	3G/4G	华为Mate9
低配手机	2G/3G	VIVO Y66
IOS平台
高配手机	3G/2G	Iphone X/Iphone 8
中配手机	3G/2G	Iphone 7/ Iphone 7plus
低配手机	1G	Iphone 6/ Iphone 6plus

 

4.2 测试脚本准备

接收到测试任务后，获取到开发需求文档，对需求分档进行阅读分析，设计合理的深度性能测试场景，根据需求文档开发新版本所需要的性能专项脚本。

需求地址：20200115版本

安装包地址：

安卓：\\samba.guahao-inc.com\packages\安卓渠道APK

IOS：https://wy-mobile.guahao-inc.com/jenkins/

 

4.3测试环境准备

目前专项测试放在集成测试阶段进行，测试前需尽量确保需求都已上车集成，取release包在正式环境下进行测试。

 

五、专项测试平台及工具

5.1 Android测试平台及工具

5.1.1 WYPerformance

（1）WYPerformance可用来测试包括内存，CPU，流量，电量，帧率，启动时间的自研测试工具，该测试工具主要基于UIAutomator2 + bat + Java + Myqsl等技术实现，可自定义测试APP应用、测试用例、测试次数，最终获取专项结果。基础性能和深度性能数据均可用WYPerformance来进行获取。

（2）Android专项测试平台配置与使用介绍

进入config目录配置config.xml文件，修改各配置项，一般是新增用例脚本名；

 

进入CaseScript目录，主要是一些bat获取专项数据的脚本、自动化专项脚本，遍历测试脚本等等

 

连接测试手机，打开LanuchTool.bat，进入专项平台主界面；

 

配置测试应用，测试用例，测试次数，测试设备等信息（注：每次新版本测试需要对新增功能页面进行测试）；

点击开始，可执行测试；

测试结束后，主界面点击查看结果，可查看结果图表；

 

 

测试结果存放于result对应结果目录下

 

5.1.2 Profiler性能工具

Android Studio升级到3.0后，出现了一个Profiler性能测试与分析工具，它是一个分析app性能的强大工具合辑，可以分析内存、cpu、启动时间、网络情况、功耗等各个指标。

5.1.3 PerfDog

移动全平台iOS/Android性能测试、分析工具平台。快速定位分析性能问题,提升APP应用性能和品质。

5.1.4 Devevo studio

华为云测试服务平台，可进行性能测试，耗电测试，安全测试等

5.1.5 WYAPM监控平台

后续补充

 

5.2 IOS测试平台及工具

5.2.1 Instruments官方性能工具

Instruments 一个很灵活的、强大的工具，是性能分析、动态跟踪 和分析OS X以及iOS代码的测试工具，用它可以极为方便收集关于一个或多个系统进程的性能和行为的数据，并能及时随着时间跟踪而产生的数据，并检查所收集的数据，还可以广泛收集不同类型的数据.也可以追踪程序运行的过程，这样instrument就可以帮助我们了解用户的应用程序和操作系统的行为。

在Xcode中启动Instruments，根据需要选择相应的测试项。

 

 

六、主要专项指标原理，方法，分析

6.1 Android测试

6.1.1 启动时间

6.1.1.1 启动分类

应用有三种启动状态，每种状态都会影响应用向用户显示所需的时间，包括冷启动、温启动或热启动。平常我们测试更多的需要关注优化冷启动时间。在启动被测应用前确保被测应用进程不存在。

冷启动：指应用从头开始启动：系统进程在冷启动后才创建应用进程。发生冷启动的情况包括应用自设备启动后或系统终止应用后首次启动

热启动：应用的热启动比冷启动简单得多，开销也更低。在热启动中，系统的所有工作就是将您的 Activity 带到前台。如果应用的所有 Activity 都还驻留在内存中，则应用可以无须重复对象初始化、布局扩充和呈现。但是，如果一些内存为响应内存整理事件（如 onTrimMemory()）而被完全清除，将需要重新创建这些对象，以响应热启动事件。

温启动：涵盖在冷启动期间发生的操作的一些子集；同时，它的开销比热启动多。有许多潜在状态可视为温启动。例如：

• 用户退出您的应用，但之后又重新启动。进程可能已继续运行，但应用必须通过调用 onCreate() 从头开始重新创建 Activity。
• 系统将您的应用从内存中逐出，然后用户又重新启动它。进程和 Activity 需要重启，但传递到 onCreate() 的已保存实例状态包对于完成此任务有一定助益。

 

6.1.1.2 冷启动流程

应用在冷启动的时候，需要执行下面三个任务:

• 加载和启动应用程序；
• App启动之后立即展示出一个空白的启动窗口；
• 创建App程序的进程；

在这三个任务执行后，系统创建了应用进程，那么应用进程会执行下一步：

• 创建App对象；
• 启动Main Thread；
• 创建启动页的Activity；
• 加载View；
• 布置屏幕；
• 进行初始绘制；

 

6.1.1.3 冷启动测试方法

1）adb命令：adb shell am start -W com.greenline.guahao/com.greenline.guahao.home.WelcomeActivity（这里测试的是启动第一个Activity），线下使用方便，不能带到线上，非严谨、精确时间。

 

 

       启动时间有ThisTime，TotalTime，WaitTime，这里我们取的是TotalTime。从下图可以看出不管启动的Activity是单个还是多个，TotalTime是相对比较准确的启动时间，TotalTime表示新应用启动的耗时，包括新进程的启动和 Activity 的启动，但不包括前一个应用Activity切至后台的耗时。如果该应用有多个activity，TotalTime包括从该应用启动的第一个activity到最后一个activity启动完毕的时间，这个是测试App应用真正需要关注的时间

 

 

 

2）Androidstudio的logcat中Displayed值打印

 

3）云平台方式，比如华为云平台，阿里云平台

4）代码埋点，比较精准，可带到线上

 

6.1.2 电量

6.1.2.1 电量概念

什么是电量测试？

所谓的电量测试，就是测试移动设备电量消耗快慢的一种测试方法。一般是用平均电流（电池生产厂家一般都采用mAh来标记电池容量大小，平均电流越小，说明设备使用时间就越长）来衡量电量消耗速度。

为什么进行电量测试？

为用户省电
手机的其他模块越来越小，而电池的体积越来越大，这已经成为了一个不争的事实。现在手机电池容量越来越大，但待机时间都不及之前功能机的三分之一。为了提高电池的续航能力，需要硬件厂商降低元器件的单位功耗以及软件系统开发商提高对硬件使用的效率，同样也需要APP开发者减小APP对电量的消耗。

提升用户体验
移动互联网的发展，优秀的APP层出不穷。然人们对优秀APP的要求也越发的“挑剔”。从起初的新颖，到后来的稳定，再到现在的流畅，省电等，所以为了，低耗电量也成为一个优秀APP的前提。

良好的产品设计和低下的电量消耗可以更好的提升用户的体验。电量测试目的就是通过不同的测试场景，找出APP高耗电的场景并解决，从而使APP的耗电量更低，提升用户的使用体验。

 

几个典型的耗电场景如下：

1. 定位，尤其是调用GPS定位。

2. 网络传输，尤其是非Wifi环境。

3. cpu频率

4. 内存调度频度

5. wake_locker时间和次数

6. 传感器

6.1.2.2 电量测试方法

耗电量场景选择：复杂运算，视频播放，传感器相关（使用时长，耗电量，发热），后台静默等。

1）adb命令

Android的耗电量主要通过dumpsys batterystats实现，因为电量是累加的，所以获取电量前需要先清零并设置USB不充电：

adb shell dumpsys batterystats --enable full-wake-history

adb shell dumpsys batterystats --reset

adb shell dumpsys battery set usb 0

再进行场景操作，然后获取电量信息如下图：

 

adb shell "dumpsys batterystats  package | grep UID"

UID是应用安装的唯一ID，可用以下命令获取UID，如果手机已root

adb shell "su root cat /data/system/packages.list | grep packageName"

如果手机未root 用获取top 获取应用的UID，（UID最好只取a后面的部分，如这里取799，这里的a有些地方是10）如下图

 

 

2）Battery Historian

Google推出的安卓电量测试工具，支持5.0（API21）以上的电量测试分析，功能强大，推荐使用，可视化的展示指标，适合线下使用，需要翻墙

3）WYPerformance工具

4）华为云平台

5）Perfdog工具

 

6.1.3 流量

6.1.3.1 流量概念

目前的网络类型包含2G\3G\4G\wifi，其中还有不同运营商的区分，我们在APP的使用中经常遇到大资源，重复请求，调用响应慢，调用失败等各种情况。在不同的网络类型之下，我们不仅要控制流量使用，还需要加快请求的响应。
流量测试可以给我们带来什么
1.可以让我们很清楚的知道用户在某种场景下使用我们的产品需要消耗多少流量。
2.流量数据分析可以指导我们去做优化；比如cgi的调用和参数设置是否合理，有些资源或者配置是否可以本地化。
3.流量的优化可以带来速度的优化；减少tcp数据包的个数，或者直接减少请求数都可以带来速度的优化。

6.1.3.2 流量测试方法

1）adb命令

 Android读取流量方法adb shell "cat /proc/net/xt_qtaguid/stats | grep UID" >>temp.txt。流量是rx_bytes（接收数据第6列）和tx_bytes（传输数据第8列）的总和。如下图：

• iface代表网络接口

• acct_tag_hex代表socket

• uid_tag_int是UID

• cnt_set实际上就是一个标志位，0代表前台流量，1代表后台流量

• rx_bytes，r代表receive，是接收数据

• tx_bytes，t代表transmit，是传输数据

 

启动被测应用在场景操作前将流量数据保存到一个文件中，再进行场景操作，结束后也将流量数据记录到文本中。将两次结果的所有进程的数据rx_bytes（接收数据）和tx_bytes（传输数据）分别做减法，差值相加本次测试消耗的流量。如被测应用有A，B两个进程，原始数据是a_rx_1,a_tx_1,b_rx_1,b_tx_1；被测数据a_rx_2,a_tx_2,b_rx_2,b_tx_2；则

A进程接收到的数据：（a_rx_2 - a_rx_1）

A进程传输的数据：（a_tx_2 - a_tx_1）

A进程消耗的总流量 = （a_tx_2 - a_tx_1）+ （a_rx_2 - a_rx_1）

B进程消耗的总流量 = （b_tx_2 - b_tx_1）+ （b_rx_2 - b_rx_1）

本次测试的总的流利 = A进程消耗的总流量 + B进程消耗的总流量

 

adb命令获取流量文章参考http://mtc.baidu.com/academy/detail/article/175

 

2）NetWork Profiler

显示实时网络活动：发送和接受数据及连接数

只支持HttpURLConnection和OkHttp网络库

需要启动高级分析：run-edit configurations

 

 

 

3.WYPerformance工具

4.Wireshark+Tcpdump工具，需要root手机

5.Wtest，Prefdog平台工具

6.1.4 CPU使用率

6.1.4.1 CPU原理

1）CPU使用率原理理解

在Linux系统下，CPU利用率分为用户态、系统态、空闲态，分别表示CPU处于用户态执行的时间，系统内核执行的时间，和空闲系统进程执行的时间。

平时所说的CPU利用率是指：CPU执行非系统空闲进程的时间 / CPU总的执行时间。

2）CPU时间片： jiffies

Jiffies：为Linux核心变数(unsigned long)，它被用来记录系统自开机以来，已经过了多少tick。一定时间占用的jiffies可以反映出此进程的CPU消耗。

CPU使用率＝（用户态Jiffies＋系统态Jiffies）／总Jiffies

6.1.4.2 CPU测试方法

CPU问题会导致app发烫、卡顿、ANR等，这里介绍几种常见测试方法

1）top命令互获取CPU

Android7.0以前

adb shell "top -n 1 -s cpu|grep packageName”

Android7.0以后

adb shell "top -n 1 -b |grep packageName”

注：-t 显示进程名称，-s 按指定行排序，-n 在退出前刷新几次，-d 刷新间隔，-m 显示最大数量

 Android的CPU指标通常在场景测试中通过 多次读取CPU瞬时占用率来获取，写入一个文件中，计算平均值。

 

 

2）CPU Profiler

 

 

CPU相关文章http://mtc.baidu.com/academy/detail/article/172

 

3）WYPerformance性能测试工具

4）Wtest ，Perfdog，阿里云移动测试，Emagee，GT

6.1.5 内存

6.1.5.1 Android基础内存管理机制

1）内存弹性分配，分配值与最大值受具体设备影响。这里的内存指的是堆内存，每个设备分配给APP堆内存的限制大小是不同的。

2）OOM（out of memory内存溢出）场景：内存真正不足，比如单个设备对APP的内存上限是512M，已用510M，再申请5M，超标了就会报OOM，还有一种是可用内存不足，这是指的是手机系统本身确实无内存分配了，导致APP也会出现OOM。

 

3）Dalvik和Art的区别：Dalvik仅仅固定一种回收算法，而Art回收算法可在运行期选择，安卓5.0以后都是用Art算法，Art算法具备内存整理能力，减少内存空洞。

4）Low Memory Killer：这是针对所有进程来说的，当手机内存不足时，就会对所有进程进行回收，他将进程分为五类，前台进程，可见进程，服务进程，后台进程，空进程，优先级右前往后，Low Memory Killer会优先清理低优先级进程，并且会考虑回收内存大小的收益。通过这套机制来尽可能保证进程不出现内存不足的情况。

 

6.5.1.2 内存分类

在linux下表示内存的耗用情况有四种不同的表现形式

VSS - Virtual Set Size 虚拟耗用内存（包含共享库占用的内存）
RSS - Resident Set Size 实际使用物理内存（包含共享库占用的内存）
PSS - Proportional Set Size 实际使用的物理内存（比例分配共享库占用的内存）
USS - Unique Set Size 进程独自占用的物理内存（不包含共享库占用的内存）

VSS：VSS表示一个进程可访问的全部内存地址空间的大小。这个大小包括了进程已经申请但尚未使用的内存空间。在实际中很少用这种方式来表示进程占用内存的情况，用它来表示单个进程的内存使用情况是不准确的。
RSS：表示一个进程在RAM中实际使用的空间地址大小，包括了全部共享库占用的内存，这种表示进程占用内存的情况也是不准确的。
PSS：表示一个进程在RAM中实际使用的空间地址大小，它按比例包含了共享库占用的内存。假如有3个进程使用同一个共享库，那么每个进程的PSS就包括了1/3大小的共享库内存。这种方式表示进程的内存使用情况较准确，但当只有一个进程使用共享库时，其情况和RSS一模一样。
USS：表示一个进程本身占用的内存空间大小，不包含其它任何成分，这是表示进程内存大小的最好方式！
可以看到:VSS>=RSS>=PSS>=USS

 

6.5.1.3 内存测试方向

首先搞清楚一个问题，我们为什么要进行内存测试及优化：1.APP运行内存存在限制，OOM会导致APP崩溃；2.APP内存跟流畅性，响应速度和用户体验相关联。

我们常见的内存测试项包括：

1）获取内存值：PSS内存值和Heap堆内存

2）内存泄漏（Memory Leak）：是指程序中己动态分配的堆内存由于某种原因程序未释放或无法释放，造成系统内存的浪费，导致程序运行速度减慢甚至系统崩溃等严重后果。通俗点讲，在大部分应用中，会有一类功能是需要加载附加资源的，比如显示从网络下载的文本或图片。这类功能往往需要在内存中存放要使用的资源对象，退出该功能后，就需要将这些资源对象清空。如果忘了清理，或者是代码原因造成的清理无效，就会形成内存泄漏。

常见内存泄漏：https://www.jianshu.com/p/bcb792720987

3）内存抖动：指在短时间内有大量的对象被创建或者被回收的现象。假如抖动频繁，会导致垃圾回收GC也会频繁，从而导致卡顿，OOM。

 

6.5.1.4 内存测试方法

获取内存值

1）adb命令（adb shell dumpsys meminfo package）

通过命令可读取主进程和各个辅助进程的内存使用情况，包括进程总的PSS total和堆内存Heap Size

 

 

2）Androidstuido Profiler工具

打开Androidstuido Profiler-View-Profiler-MEMORY，这里详细记录了主进程的内存情况，实测这里的内存是USS内存，会比PSS内存小一些。

 

Java：从Java或Kotlin代码分配的对象的内存。

Native：从C或C ++代码分配的对象的内存。

Graphics：用于图形缓冲区队列的内存，用于在屏幕上显示像素，包括GL表面，GL纹理等。（请注意，这是与CPU共享的内存，不是专用的GPU内存。）

Stack：您的应用中的native和Java堆栈使用的内存。这通常与您的应用程序运行的线程数有关。

Code:您的应用程序使用代码和资源的内存，如dex字节码，优化或编译的dex代码，.so库和字体。

Other:你的应用程序使用的内存，系统不知道如何分类。

Allocated:您的应用程序分配的Java / Kotlin对象的数量。这不会计算以C或C ++分配的对象。

 

3）WYPerformance性能测试工具

4）Perfdog腾讯专项测试工具

 

5）云平台方式，比如Wtest，华为云平台，阿里云平台

 

 

内存泄漏：

1）使用LeakCanary检测内存泄漏，目前微医生，微医生APP已集成。方法：只要在工厂模式下打开按钮后操作即可，如有内存泄漏会生成一个黄色图表的APP应用，打开即可看到有哪些activity发生泄漏。

2）通过AS的Memory Profiler结合Memory Analyzer这两个工具进行内存泄漏分析。

测试步骤：

进入Memory Profiler，点击垃圾桶回收内存；

 

进入退出内存泄漏界面，查看Memory Profiler，如果内存出现明显升高，说明可用内存逐渐减少，初步判断存在内存泄漏；

使用堆转储功能，点击垃圾回收，再点击dump java heap转换为内存泄漏文件，通过adb命令将文件转化为Memory Analyzer识别的标准格式；

使用Memory Analyzer打开内存泄漏文件，从Overview页的Histogram进入；

输入搜索当前Activity，点击右键当前Activity---List Object—with incoming references；

 

进入后继续右键找到Path to GC Root----exclude weak references；

 

这样就可以找到并分析Activity被哪个类所引用未释放了。

 

内存抖动

1）Memory Profiler

使用Memory Profiler对新需求页面进行筛查，通过锯齿状图形进行初步判断，

可以点击录制按钮进行记录跟踪分配内存，结合代码来进行排查。

 

6.1.6 流畅度（帧率、卡顿，ANR）

6.1.6.1 基础概念

6.1.6.2 测试方法

1）adb命令

Android 通过adb shell dumpsys gfxinfo package获取帧率，如下图。

 

Draw：（画、绘制）代表的是测量绘制显示列表（Display List）的时间，即一个视图渲染之前需要转换成GPU 熟悉的格式去处理的这个过程花费的时间。

Prepare：（准备）代表的是为渲染做准备所耗费的时间；（android 5.0以上版本才有）。

Process：（处理加工） 代表的是 OpenGL 渲染 Display List 的时间；UI层级（hierarchy）中的View数量越多，需要执行的绘画命令就越多。

Execute：（执行） 代表的是将一帧图像交给合成器（compositor）的时间,把每一帧数据传送到屏幕上排版显示的时间，也就是 CPU 等待 GPU 处理的时间。

一帧的时间为绘制、准备、加工处理、执行的时间的总和，单位（ms）。

目前此测试方式尚不能很好的对卡顿进行测试，需要改进。

 

2）CPU Profiler ，线下检测及优化卡顿工具

3）Systrace ，线下检测及优化卡顿工具

4）Bugly线上监控平台---线上

针对移动应用，腾讯 Bugly 提供了专业的 Crash、Android ANR ( application not response)、iOS 卡顿监控和解决方案。移动开发者 ( Android / iOS ) 可以通过监控，快速发现用户在使用过程中出现的 Crash (崩溃)、Android ANR 和 iOS 卡顿，并根据上报的信息快速定位和解决问题

5）Choreographer.FrameCallback 方案

 

6.2 IOS测试

6.2.1 启动时间

Pre-main：指 main 函数执行之前的加载时间，包括 dylib 动态库加载，Mach-O 文件加载，Rebase/Binding，Objective-C Runtime 加载等；

在Xcode的菜单中选择Project→Scheme→Edit Scheme...，然后找到 Run→ Environment Variables →+，添加name为DYLD_PRINT_STATISTICS，把value为1的环境变量。

这样我们就可以在编译运行工程时，在控制台看到 Total pre-main time 总耗时了，如下图所示，包含 main 函数执行之前各项的加载时间，我们可以多次运行取一下平均值，苹果推荐这个时间应在 400ms以内。

main时间：指的是main()第一行代码到didFinishLaunchingWithOptions最后一行代码的耗时，

可以通过插桩获得

 

 

 

可以通过instruments的Time Profiler获得，分析didFinishLaunchingWithOptions的时间

 

6.2.2 电量

 1）目前主要使用官方的工具sysdiagnose，这是苹果日志系统的统称，苹果经常会询问是否要官方帮忙诊断和定位问题时，上传的就是sysdiagnose的各种日志。Sysdiagnose很庞大，每天上几百M的日志，记录电池、第三方APP、各种系统功能和应用的所有运行情况。

Sysdiagnose怎么使用呢？简单得说，就是需要一个开发者账号，然后到苹果开发者网下载对应的证书。不需要越狱，没有系统限制，这个特别关键。

电量日志是sysdiagnose系统中最庞大的一块。电量日志每天有几十到一百M，他是一个庞大的数据库，里面有267张表，记录了电池电量的各维度信息。

下面是最常用的几张与电量相关的表：

 

 

可参考文档：

https://testerhome.com/topics/10666

http://www.itboth.com/d/A7BZVf/ios

 

2）instrument的energy

使用步骤：

1.iOS 设置选项 ->开发者选项－>logging －>start recording

2.进行需要测试电量的场景操作后进入开发者选项点击stop recording 

3.将iOS设备和Mac连接

4.打开Instrument，选择Energy Diagnostics

5.选择 File > Import Logged Data from Device

6.保存的数据以时间轴输出到Instrument面板

 

6.2.3 流量

 IOS流量测试主要使用Instruments的Network插件的connecttions工具，点击左上角录制按钮，进行场景操作，结束后按该按钮停止。被测应用的DataIn和DataOut就是本次操作消耗的流量。

注：据开发这边了解，这个测出的流量是原生页面的流量，不包含H5页面流量。

 

 

6.2.4 CPU

 1）  IOS的CPU主要通过Instruments的CPU Activity Log工具实现。如下图，取Total Cpu Activity的值，是该进程占用的所有CPU的总和。

 

2）Instrument的Activity monitor进行某个进程（比如微医，微医生）的CPU测试，获取CPU使用情况，也可以与其他应用程序做对比。

3）Instrument的time profiler，分析APP中各个方法消耗CPU的时间。

使用步骤：

修改Debug Info Format, 这里一定要选择DWARF with DSYM File, 否则无法定位具体源代码位置, 然后在模拟器或者真机运行

打开Instrument -> Time Profiler

选择模拟器或者真机和你要调试的App

点击Start按钮，Time Profiler就开始记录App的运行情况

可以看到在CPU使用过高的位置对应的具体调用栈

最后双击对应的函数可以跳转到具体的代码行

注意设置下Call Tree，点击底部下面蓝色的Call Tree 弹出框，选择如下两个：

Separate byt Thread（建议选择）：通过线程分类来查看那些纯种占用CPU最多。

Hide System Libraries（建议选择）：选上它只会展示与应用有关的符号信息，一般情况下我们只关心自己写的代码所需的耗时，而不关心系统库的CPU耗时。

6.2.5 内存

 1）内存泄漏：主要用Instruments的Leaks查看内存泄漏，选中泄漏的地方（红色的×），查看ResponsibleLibaray查看由那个库引起的内存泄漏。右侧可以看出函数间的调用情况。点击可查看源码

 

点开右侧函数可以看到泄漏存在泄漏的代码位置，如下图：

 

2）Allocations查看堆内存使用情况。PersistentBytes是当前应用内存使用情况，如果使用工程中一直增值，且停止使用后没有下降，则说明存在内存泄漏。

 

3）Instrument的Activity monitor进行某个进程（比如筛选微医，微医生）的实际内存测试，获内存使用情况。

6.2.6 帧率

IOS通过Core Animation查看FPS(每秒传输帧数(Frames Per Second)如下图

 

 

另外：

可以使用华为云测，阿里云测，百度云测，腾讯Wtest等云测网站作为专项测试辅助测试手段。

可以使用QAPM等APM进行测试

可以使用腾讯GT进行测试

 

instrument相关资料文档：

https://www.jianshu.com/p/c562d38c577d

七、专项测试用例及标准

用例及标准：App专项测试用例集

 

 

八、BUG提交与处理原则

8.1 BUG提交地址

微医生BUG提交地址http://redmine.guahao-inc.com/projects/apphosp

微医BUG提交地址http://redmine.guahao-inc.com/projects/appuser

 

8.2 BUG描述说明

 

编号	描述	说明
1	Bug标题	n  标题为Bug的简要定义要求：言简意赅的文字准确描述Bug 。 n  字数要求：原则上小于40个双字节字符 。 n  字数要求：陈述语句，不要用感叹，疑问，倒装语句，双关语句 。
2	模块路径	专项测试问题默认选择性能模块
3	指派给	指派给对应模块的开发人员，对于不能确定的Bug，需要和测试负责人沟通后再指定各对应的开发人员。
4	严重程度	系统中有A,B,C,D,E 五个等级
5	优先级	系统中有P1，P2，P3，P4 四个等级。
6	重现步骤	测试人员应该尽可能详细的描写重现步骤 n  整体Bug描述要求 1).站在对方(开发，PD，PM，其他测试人员)的立场，以最准确的文字描述清楚Bug。 2).要陈述语句，不要用感叹，疑问，倒装语句，双关语句； 2).描述中不要出现错别字； 3).尽量不要使用“正确”“正常”“不正常”“不好”等给人无限遐想的词语； 4).多使用截图、规频、log等方式更清晰的直观的方式； 5).Bug复现频率不要使用模糊语言“有时”“偶尔”“一段时间”“多次”等，需要给出明确的发生率。 n  Bug模板 [版本信息] [预置条件] 要求：应包含测试执行前的状态、所处的环境、以及配置等信息 [复现步骤] 要求：按照Bug复现的实际步骤，完整、清晰、准确描述每个步骤，并且前后衔接准确。 以如下条目的方式表述复现步骤，尽量避免出现大段文字。 1. 2. 3. [实际结果] 要求：实际结果是期望意外的，要求清楚描述出实际测试结果，不能包含正常和不正常这种含糊词 [期望结果] 要求：期望结果实际上按照需求文档所预期实现的功能结果，要求描述清楚，不能包含正常和不正常这种含糊词。 [复现概率] 描述实际测试情况，如一台手机测试次数，复现情况；多台手机测试，每台手机测试次数，复现情况等。 【备注】 说明：备注项中用来描述步骤/预期/结果以外你还想透露给开发人员的信息、当前问题影响的后果、Bug复现测试工具、数据文件等，例如：详细错诨结果请参见附件中截图 。 说明：一个Bug描述一个缺陷，避免多个缺陷出现在一个Bug中。
7	上传附件	作为对 Bug描述的补充方式，请尽可能提交附件（截图或者Log日志）

 

8.3 处理原则

8.3.1 处理时间

及时跟进指派给自己的Bug，严重程度ABC优先级高的Bug必须在24小时内给出验证结果或更新状态；

严重程度ABC优先级高级别以下的Bug需要在48小时给出反馈；

 

8.3.2 处理方式

对于已修复状态的Bug，需要跟踪2个版本验证确认后关闭。

对于暂延状态的Bug，需要对此类Bug进行跟踪

对于无法修复状态的Bug，需要积极沟通不修复的理由，不应盲目关闭

对于暂无法复现的Bug，需要留有bug记录，对此类Bug进行跟踪，当再次出现时reopen

 

8.3.3 偶现bug的处理

1)   偶现 Bug需要在redmine中提交Bug记录，并提供Log或者其他有用信息；

2)   偶现 Bug在处理时需跟踪3个版本，验证过程中需要在注释里说明验证的方法或步骤，如果连续3个版本都未复现，由测试关闭。

3)   偶现Bug在跟踪的3个版本中，如果其中一个版本有复现需要在当前发现的版本后续再跟踪3个测试版本，并在Bug记录中更新信息（比如已找到复现路径，复现概率等）

4)   在偶现 Bug上对待跟踪结果的描述必须包含但不限于：验证版本号、操作次数、复现次数。如 “XXX版本操作10次，复现2次，请在后续版本继续跟进。”