第4章 iOS性能测试
2.3响应速度测试方法
响应速度是软件性能中最重要的一环。想想点击软件的某一个按键需要等待十秒钟才有响应的体验，想想访问一个网站要两分钟的痛苦，就知道响应速度对于任何一个软件的重要性了。
那么如何对响应速度做出评价呢？
对于用户来说，响应速度就是完成某一项操作到预期结果显示完成的所需要的时间，这段时间越短越好。那既然我们关注的是这样一个数据，那么显然的，我们只能能够获取到完成操作的时间点以及预期结果显示完成的时间点，就可以知道这一项操作所花费的时间了。
这就是从用户视角看到的响应速度，是不是简单明了？那现在问题来了，这两个时间点如何确认呢？下面我们介绍几种常见的响应速度测试方法。
2.3.1掐表计时法
我们先从最简单的方法说起吧。你能想到的最简单的方式是什么呢？记得以前上体育课时老师总会拿着个秒表计算每个同学跑一圈操场所花的时间。
掐表计时，这应该是对于计时比较本能的反应。开始执行某一个动作的同时，开始计时，预期结果展示完成时，结束计时，其中所花费的时间就一目了然了。
这算是很原始的测速方法了。用于长时间才能完成的动作，或许是不成问题。但是软件的操作，都是短短几秒或者小于1秒内完成的动作，用这种方式就会有太大的误差，直接导致测试结论的错误。
这种方式不行，有没有更精确一点的方法呢？
我们想到既然操作的同时获取时间不可行，那可以先操作，然后记录这个操作过程，然后后期再处理操作过程所留下的痕迹，这样或许能让结果更加准确了。
操作的过程，可以用日志或者是图像来记录一些重要的信息，通过这些日志或是对图像的分析，可以得到一些有用的信息，我们下面一一来看一下。
2.3.2日志计时法
这个其实很好理解，就是在关键节点通过接口打印出有用的日志，然后人工或是脚本分析这些日志即可。
比如说，假设执行某个操作时调用的第一个接口是如下代码：
-(void)starUp{ //核心代码在这里 } |
预期结果显示完成时调用的接口是：
-(void)endUp{ //核心代码在这里 } |
那么在编码阶段，可以在这两个接口中分别打印当前时间：
-(void)starUp{ startTime = [[NSDate Date] timeIntervalSince1970]; //核心代码在这里 } -(void)endUp{ //核心代码在这里 endTime = [[NSDate Date] timeIntervalSince1970]; NSLog(@"runningTime=%f",endTime-startTime); } |
这样在执行一次这个操作时，就会有两个时间点，这两个时间节点能够精确得计算这个操作完成的时间。是非常赞的一个方式。我们来分析一下他的优缺点，如表4-2所示。
表4-1日志计时法的优缺点
这样看来，在关键节点增加了时间点后，后续的测试会变得很方便，只需要像一个用户正常得使用这个软件就行了。但是需要源代码这个缺陷有时候是致命的。首先是修改源码的成本相对会高一些，然后是无法与同类的产品作对比，特别是第二点，有时候就是因为这个而放弃去使用这个方式了。
2.3.3录像分帧记时法
下面再看看用图像记录的方式。
估且想想大概有哪些方式能够全程记录下我屏幕上的所有变化。大概是有计算机自动截屏、自动录屏、另一个工具拍照、录像这几个方式吧。
不管是用哪一种方式，总之我们都是希望能够确定起始点位并计算出来。用录像的方式，预期结果展示完成这个时间点是可以确定了。但开始的时间点却不一定，比如点击某一个按键，他可能在点击后一小段时间内没有任何界面上的变化，这样就没办法确定是什么时候完成操作的了。所以最好的方式就是在界面上留下操作的痕迹，比如点击时在点击位置绘制个白点，滑动时绘制滑动的轨迹。
这种方式的精确度是部分可控的，主要是看录屏的帧数或者是截屏的频率。但这也是有极限值的，而且录屏或截屏本身会占用系统资源，所以也不是越高越好。测试过程中一般设置为20帧到50帧之间，这样测试结果有40ms到100ms的误差，看具体情况而定。
视频的记录方式，如果想获得和截屏一样的精确度，那么还得先把视频分帧成图片，不然也比较难确定精确的起始时间点。
大致的思路已经确定了，那现在来对比一下以上几个记录方式的优缺点，如表4-3所示：
表4-2各种图像分帧计时优缺点
经过这样的对比，我们得到以下几个结论：
（1）在系统资源和磁盘资源都非常充足的情况下，截屏的方式是不错的选择；
（2）在系统资源和磁盘资源有限的情况下，录屏是更好的选择；
（3）连拍的方式基本是不可行的；
（4）录像的方式的记录过程相对繁琐，系统资源比较紧缺或是想保证除被测软件以外的其他的软件尽量少占资源的情况下，录像是一个选择。
现在对于记录方式有了一些认识，那么接下来讨论一下有了这些记录之后，怎么得出具体的结果。像用打日志计时的方式，可以直接获得速度数据，能快速地得出结果。而用图像的方式则需要一个繁琐的过程。首先得找到起始的两张图片，分别是开始点击的那张图和页面展示完的那张图，然后根据这两个图片计算出时间。通常来说，在众多图片中找到某一张图片是挺费时的。测试过程中每一秒钟都会生成数十张的图片，一个操作通常会有数秒或数十秒的时间跨度，这样就会有成百上千的图片，如果单凭人工去确认真是费劲得很。必须得找到一个方法，能够快速得把这两张图片找出来才行。不过具体应该怎么找，可能还得根据被测试软件的界面特点出发，来确定合适的方案。关于这一点，会在实例中提出一种解决方案，这里就不详述了。
2.4稳定性测试
软件闪退对用户感知冲击很大，想想玩着游戏突然闪退的愤怒，想想文档写到一半文档编辑器闪退时的无奈。从用户的角度来看，使用某一个软件不发生闪退当然最好，但这个是比较理想化的，任何一个软件都会有一定概率出现崩溃。我们常用一定的时间内软件闪退了多少次来衡量该软件的运行稳定性，次数越少越好。常用的方式一般是有两种，一是单一功能的反复测试，二是软件整体的随机测试，验证整体的稳定性。这边主要讲一下整体的随机测试。
2.4.1测试框架介绍
首先要说的是，在软件原代码的基础上，集成测试框架，利用测试框架封装好的测试接口，来编写测试用例。这是自动化测试最常采取的一种方式。
一个好的测试框架，会给测试人员省去不少的工作量，也可以让测试更有效，更稳定，那常用的测试框架有哪些？他们各自的优势在哪呢？这里列举对比一下iOS端的常用测试框架，如表4-4所示：
