来源：http://www.51testing.com
第2章 App测试类型
2.1 功能测试
功能测试，通常的定义就是测试功能的可执行性和有效性。
以下内容没有覆盖到功能测试的所有方面，读者都很熟悉的常规内容就不再讲述了。在App功能测试中，有一些传统软件测试里不太常见的关注点，以下权当抛砖引玉，启发一下读者在App功能测试中的思考维度。
2.1.1 高级别事件响应
高级别事件响应也可以归为冲突测试的一个类别。这里单独提出来进行介绍，能让读者更准确地理解冲突测试，从而使设计思路更清晰。
比如，当用户正在操作一个App时，闹铃响了，这里的闹铃显然比该App相关操作的事件级别要高，因为即使在关机时，闹铃也照样会响，在不主动干预的情况下，这个事件是不可阻止的。同理，我们也可以把其他App定期产生的推送消息当作一种高级别事件，拿到测试场景中来进行设计。当然，当App自动化测试的环境初始化时，一定要阻止这些事件响应的发生，应该在手机的相关设置里将其屏蔽掉。否则，这肯定会影响App自动化测试程序的正常运行。
2.1.2 第三方应用打断
广义上，上述高级别事件响应也属于一种第三方应用打断场景，但是这里归纳出来的第三方应用打断，重点考虑的是多终端场景。比如，A手机正在操作一个App，B手机给A打电话，C手机给A手机发短信，D手机给A手机发送邮件。当然，还可以根据场景扩展到更多的第三方终端，让他们来发送QQ消息、微信消息，还有手机上其他应用产生的推送消息等。关于这部分测试，使用自动化测试手段才能化繁为简，并且取得比手工测试更准确、更客观的测试结果。自动化测试手段能够编写同一时钟下的相关操作，以确保测试的及时性和准确性。而确保动作序列的流程、最大限度地提高容错性和实现相关的等待时延判断，是这种自动化测试程序的关键所在。
2.1.3 通信录的备份恢复功能
测试人员需要充分考虑新手机开机时的备份恢复功能，刷机前后的相关备份恢复功能，增量备份恢复、全量备份恢复、备份恢复时的异常情况测试。这些是很多客户都关注的功能，不管是手机本身，还是相关App，如果能够灵活、准确、高效地提供此项功能，那么在特定场景下的用户满意度将会非常高。
2.1.4 手机和其他外设产品的互联互通
目前，智能手机给人们提供的服务已经远远超过电话、短信业务，也不仅仅是手机上安装的相关App提供的服务。手机及某些App和其他外部设备的互联互通极其常见，而且很多时候也是非常必要的。比如与蓝牙音箱连接，手机可外部播放音乐；与智能电视连接，手机甚至可以用来做遥控器；与小区的门禁系统连接，手机就是门禁卡。此外，还可以与汽车影音系统和智能可穿戴设备连接，实现更多功能。手机本身具备的功能，或者手机上某款App具备的功能，外部设备的互联互通肯定不能不进行测试。连接方式也有很多，有通过电信网连接的，有通过蓝牙连接的，有通过Wi-Fi连接的，也许还可以用ZigBee、GPS等连接，不一而足。我们在选择测试场景时可以参考一下。
2.2 稳定性测试
传统硬件测试中的可靠性测试，在软件测试中通常叫作稳定性测试。软件稳定性的测试方法借鉴硬件的可靠性测试非常多，目前广泛应用的硬件可靠性指标有MTTF、MTTR和MTBF三个指标，较为通用权威的标准是MIL-HDBK-217、IEC 61508和Bellcore，分别是美国国防部、AT&T贝尔实验室和国际电工委员会提出的标准。下面介绍一下MTTF、MTTR和MTBF三个指标。
" MTTF（Mean Time To Failure，平均失效前时间）。平均失效前时间是指系统/产品平均正常运行多长时间，才发生一次故障。我们也可以称它为平均无故障时间。这个指标值越大越好，最好永远不会发生故障。
" MTTR（Mean Time To Restoration，平均修复时间）。平均修复时间就是修复产品所用的平均时间，即从出现故障到修复故障的这段时间。在统计时，这个时间要包括获取到产品的时间、维修团队的响应时间、记录所有任务的时间，还有将产品重新投入使用的时间。当然，这个指标越小越好，出现故障后最好能立刻修复。
" MTBF（Mean Time Between Failures，平均故障间隔时间）。平均故障间隔时间，是指修复产品两次相邻故障之间的平均时间。这个指标对于经常做稳定性测试的人员耳熟能详，它是体现产品持续正常工作多长时间的一种能力。这个指标的值也是越大越好。
通过以上三个指标的概念可以看出，它们之间存在着这样的公式，即MTBF = MTTF MTTR。在实际测试度量中可以发现，MTTR的值远远小于MTTF，所以一般直接用MTBF值表示系统/产品的稳定性。
更专业的硬件或电子元器件的可靠性测试指标是如何度量或计算的，这里就不做介绍了，下面说一下软件测试中怎么使用MTBF值。一般我们看到某款计算机或者电子产品在宣传中称，该产品经过了几千小时、几万小时的稳定性测试，难道该产品真的是单一产品连续测试几千小时吗？1年按365天算，几万小时就是好几年，如果一个产品测试就要几年，那么电子产品就永远无法上市。
软件的稳定性测试可以借鉴以下公式：
MTBF（时间/次）=N个选样产品总运行时间之和/N个产品发现的指标BUG之和
也就是说，当测试MTBF时，可以选择多个产品并行测试，将其并行运行时间和期间发现的BUG数量进行累加，这样测出几千、几万小时的指标值就不需要那么长的实际时间。值得注意的是，这里所说的指标BUG，不完全等同于功能测试时找到的一般性BUG（也就是说，稳定性测试中的指标BUG）。我们可以界定几类重点关注的BUG，而把一些不是很重要的BUG忽略不计。比如手机的稳定性测试中，我们可以只关心闪退、花屏、黑屏、死机等BUG，而出现的其他BUG可以不计入BUG数量，这样可以让MTBF这个值更能表现出产品稳定性的特定意义。当然，把所有出现的BUG都计入指标BUG也是可以的。
传统的软件稳定性测试还有一种要求，只要发现后台进程core dump，或修改BUG导致后台进行重启，稳定性测试就重新计时，即不管指标BUG怎么界定，后台进程只要挂掉一次，稳定性要从头再做，时间不可累计。
至于手机测试和App测试中的稳定性需要测试多久，还没有像硬件产品那样比较丰富的参考对象和相应的标准。关于手机的稳定性测试，一些手机厂商曾给出过一个参考指标是几百小时这样的量级。当然，不管是多久，对于一款App最少要测试24小时的稳定性，即使是这样，进行24小时连续不间断的手工测试也很难做到，如果要进行N×24小时的稳定性测试，那必须借助自动化手段来完成。所以自动化测试手段在手机和App的稳定性测试中是一个必选途径。
2.3 兼容性测试
兼容性测试本身比较复杂，实施难度也很大，历来都被测试界公认为"又脏又累"的工作。下面设有完全展开兼容性测试分析，仅仅给出App或手机测试中与兼容性相关的常见思考维度，以供参考。
2.3.1 手机品牌
Android的开源特性，使得同一个大的Android版本在不同的厂商进行的定制化不同，且操作系统千差万别。在我们无法统计和分析到底有哪些不同的时候，我们要尽可能多地兼容手机的品牌，以及相同品牌下不同型号的手机。
业界的有些实践经验就是重点要兼容3个季度内的手机，我们可以权且把它们叫作"新机"，上市在一年或一年半左右的机型，可以称为"主流机型"。根据公司的实力和渠道，要尽可能多地覆盖测试这些品牌和机型。对于时间更久的机型，可以适当挑选典型的机型进行测试，覆盖太全可能导致测试成本太高，测试效果未必能得到正向收益。
2.3.2 硬件种类
常用的智能硬件有以下几种。
" 智能手机。按操作系统来划分，有iOS、Android、Window Mobile等智能手机。
" PAD。App还要考虑各种操作系统上的PAD产品，因为PAD并不属于通信设备，在硬件构造上和手机不同，屏幕尺寸也比手机大很多。对于一些平板类笔记本电脑，这种二合一的结合体也是一个新生事物，要酌情加以考虑。
" 智能可穿戴设备。常见的智能可穿戴设备有智能手表、智能手环。目前的硬件产品上所承载的App可能并不多，这也受限于这类产品的硬件能力和使用场景，但是未来这类产品肯定会被广泛应用，并且所承载的App会越来越多。
" 车载终端。对于车载导航、车载的语音娱乐系统平台等车载终端，App的承载需求也很突出。
" 智能电视/智能机顶盒。虽然智能电视/机顶盒上大部分都是影音类播放App，但是随着智能电视的普及，它在很多场合可以作为智慧家庭的重要入口点，需要的App种类和数量也是可以期待的。
随着技术的发展，可能日后还会出现更多的智能硬件品种，这里列举如上种类，旨在扩宽我们测试选型的角度。对某些App产品，如果应用领域本身就很宽，测试载体就不可仅仅局限在智能手机范畴，也可以在移动互联网、物联网的领域多多寻找，这样所测试的App产品可能会有更广阔的应用领域。
2.3.3 芯片种类
对于App测试来讲，芯片种类并不是必须要兼容的内容，这部分内容过于底层。不过对于移动终端产品来讲，不同芯片的解决方案不同，产品是要重点进行测试的。为了保持知识体系的完整性，将这部分内容也归纳进来，对于App测试者来讲，可以进行了解参考。
目前，主要的芯片厂商有美国的高通、美国的苹果、中国深圳的华为海思、中国上海的展讯科技、中国上海的大唐联芯、中国台湾的MTK（联发科）、韩国的三星、美国Marvell（马维尔）等。在TD-LTE、FDD-LTE、TD-SCDMA、WCDMA等领域，各家都有各家的长处。我国市面上手机产品使用的芯片解决方案几乎都是以上厂家提供的，芯片质量的好坏直接决定了手机的各种质量指标。所以，有的时候，同样一个产品在这款手机上稳定性很高，在另一款手机上稳定性不高，这是因为手机使用的芯片不同造成的。
2.3.4 分辨率
分辨率简言之就是屏幕的精密度，即一个屏幕上容纳像素点的多少的衡量。分辨率越高，我们在同一屏幕上所看到的图像越清晰。比如，当分辨率较高时，屏幕上一行能显示80个汉字；当分辨率较低时，屏幕上一行只能看到40个汉字。
对于这项兼容性，不仅App要测试，传统软件也要测试。兼容性就是测试软件对分辨率的自适应性，即会不会因为分辨率改变界面显示情况。
智能终端的分辨率表述和PC的分辨率表述是一致的，都使用行×列像素的表示方法，如常见的540×960像素、640×1136像素、720×1280像素、800×1280像素、1024×768像素、2048×1536像素等。
选择测试载体时可以按照分辨率来选择。当然，更简单的选择标准，可以按照屏幕尺寸来选择，比如4.3英寸屏、5英寸屏、5.5英寸屏、5.8英寸屏等。这时候需要注意的是，同样尺寸的屏幕分辨率未必一样。所以在选择时，统筹考虑是有必要的。在测试中，最常见的就是对手机屏幕进行旋转，可能会发生很多类型的错误。
2.3.5 各种无线网络的兼容性
针对各种无线网络的兼容性，App测试可以选择性进行覆盖，因此智能终端测试就必须完成。
移动通信网络信号在1.3节中已经介绍过，这里不再详述。以下再简要归纳这部分的选择范围：各种通信网络连接、Wi-Fi网络、蓝牙、GPS等常见的无线连接在兼容性测试中需要考虑。
2.3.6 第三方软件兼容性
第三方软件兼容性测试主要用于测试App产品与本机预装的App及主流App是否兼容。
预装App，就是每部手机出厂时，厂家或者相应的销售渠道代理给手机预装的一些App。目前，很多预装软件是在用户使用模式下无法卸载的，即使不使用，这部分App也卸载不掉。除非进入手机的工厂模式下才能将其卸载。
主流App目前也没有标准的定义，我们可以根据国内几大App Store中App的下载量排名来选择，也可以根据自己的经验来进行判断。
别外，和被测App属于同行竞争产品的App，以及和被测软件有交互操作的App也需要重点测试。
2.4 性能测试
App的性能测试非常重要，也是App测试中频率最高的必测内容。性能测试简单来讲就是，评估典型应用场景下App产品对系统资源的使用情况。这里的典型应用场景，一定要根据用户实际使用场景、软件极限应用场景、软件需求规格说明书（SRS）的相关标准来综合考虑，不同场景下的性能测试效果会差别很大，同时对软件质量的保障力度也不尽相同。
传统性能测试从大的方面讲主要测试两个方向的特性，一个是空间特性，另一个就是时间特性。在App性能测试中，功耗测试（也叫电量测试）经常被划分到性能测试中。常见的性能测试评估指标有CPU占用率、内存占用率、上下行流量测试、耗时、流畅度、电量。
具体App的性能自动化测试不是本书的重点，想深入了解相关内容请读者参阅相关专业书籍。
星云测试
http://www.teststars.cc
奇林软件
http://www.kylinpet.com
联合通测
http://www.quicktesting.net
