App 测试类型

App 及手机测试过程中，有很多是传统测试所没有的，或者是不太重视的，如网络兼容性、SIM 卡兼容性、多部手机间的冲突测试、GPS、内置摄像头、手机丢失后的安全防御等。
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 测试者来讲，可以进行了解参考。

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 测试可以选择性进行覆盖，因此智能终端测试就必须完成。这里不再详述。以下再简要归纳这部分的选择范围：各种通信网络连接、Wi-Fi 网络、蓝牙、GPS 等常见的无线连接在兼容性测试中需要考虑。
2.3.6 第三方软件兼容性
第三方软件兼容性测试主要用于测试 App 产品与本机预装的 App 及主流 App 是否兼容。预装 App，就是每部手机出厂时，厂家或者相应的销售渠道代理给手机预装的一些 App。目前，很多预装软件是在用户使用模式下无法卸载的，即使不使用，这部分 App 也卸载不掉。除非进入手机的工厂模式下才能将其卸载。
2.4 性能测试
App 的性能测试非常重要，也是 App 测试中频率最高的必测内容。性能测试简单来讲就是，评估典型应用场景下 App 产品对系统资源的使用情况。这里的典型应用场景，一定要根据用户实际使用场景、软件极限应用场景、软件需求规格说明书（SRS）的相关标准来综合考虑，不同场景下的性能测试效果会差别很大，同时对软件质量的保障力度也不尽相同。传统性能测试从大的方面讲主要测试两个方向的特性，一个是空间特性，另一个就是时间特性。在 App 性能测试中，功耗测试（也叫电量测试）经常被划分到性能测试中。常见的性能测试评估指标有 CPU 占用率、内存占用率、上下行流量测试、耗时、流畅度、电量。
2.5 网络测试
2.5.1 室内网络测试
室内网络测试就是在室内固定地点，选择移动网络较好或者较差的地点，自行设计网络信号强弱点，还可以在室内连接稳定的 Wi-Fi、蓝牙等无线网络进行相关测试。
2.5.2 外网测试
外网测试包含常说的路测、户外拨测。
外网测试情况比较复杂。外网测试主要模拟客户使用的网络环境，如 Wi-Fi、GPS、北斗，以及移动、联通、电信的 2G、3G、4G 网络。场景包括在高山、丘陵、火车、高铁等特殊环境下的 App 测试。信号被屏蔽后，也要进行 App 的测试。
2.5.3 弱场测试
弱场测试一般是指在信号比较弱的场所进行的测试。
一般在测试时，选择地下车库、地下室、地铁上、地铁下层换乘厅、地下超市、电梯等场所即可以满足日常弱场测试场景。虽然很多实践中也把弱场测试划分到外场测试里面，但是最好还是提取出来单独设计。这个弱场测试对手机测试来讲更为重要一些。
2.6 异常测试
异常测试包括以下几种情况下的测试。
（1）各种网络信号的网络中断异常。
（2）SIM 卡松动，这可以采取 SIM 卡插拔手段模拟实现。
（3）低电量。
（4）手机内存占或 CPU 占用率达 100%。
（5）手机死机或卡死。
对于后面两种情况，可以自行研发一个 App。其主要功能是快速占满内存和 CPU，或让进程产生异常，使手机快速产生卡死现象，因为手工完成这些操作会很麻烦。
2.7 发布测试
要发布测试，可以按以下步骤进行。
发布测试包括以下内容。
（1）检查安装包大小。
（2）检查版本号、语言。
（3）安装和反安装测试。
（4）用其他辅助工具（如 91 助手、豆瓣荚等）安装、卸载测试。
（5）在线升级测试，相近版本及跨版本升级。
（6）验证数字签名。
2.8 用户界面测试
用户界面测试旨在测试用户界面（如菜单、对话框、窗口和其他可见控件布局、风格）是否满足客户要求，文字是否正确，页面是否美观、完整，文字、图片组合是否完美，操作是否友好等。
界面测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能，确保用户界面符合公司或行业的标准，包括易理解性、易操作性、易学习性等测试点。
下面重点介绍图形测试和内容测试。
2.8.1 图形测试
图形测试包括以下内容。
（1）横向或纵向比较，确认各控件操作方式统一。
（2）自适应界面设计，内容根据分辨率大小自适应。
（3）测试页面标签风格是否统一。
（4）测试页面是否美观。
（5）页面的图片应有其实际意义，而且要求整体有序美观。
（6）图片质量高且图片尺寸在符合设计要求的情况下应尽量小。
（7）界面整体使用的颜色不宜过多。
2.8.2 内容测试
内容测试包括以下内容。
（1）测试输入框说明文字的内容与系统功能是否一致。
（2）测试文字长度是否加以限制。
（3）测试文字内容是否表意不明。
（4）测试是否有错别字。
（5）测试信息是否有中英夹杂或中文中夹杂其他语言的情况，如果有，则需要核对需求规格说明书，或找前台开发负责人进行确认。通常，中外文夹杂就是 BUG。
（6）测试是否有公司、行业或法律法规所规定的敏感性词汇。
（7）测试图的合法性，如是否涉及版权、专利、隐私等问题。
2.9 冲突测试
第三方应用打断的场景，其实也就是冲突测试的内容。此部分可以放在功能测试里统一考量，也可以单独提取出来作为一个测试项目。因为人们经常会提到冲突测试，
下面给出几个移动终端上App 冲突测试的典型场景实例，有助于读者拓展思路。
2.9.1 按键打断
考虑到手机下方功能键有三个键的情况，还有一个键的情况，根据场景，可以设计不同的按键进行干扰打断。另外，还要考虑到关机/锁屏键的干扰打断，以及其他手机上的按键功能。
2.9.2 程序后台相互切换
在 App 之间频繁切换的场景很多，尤其是多个交互的 App 之间的业务协作切换（如 12306订票和支付宝之间的切换），需要重点考虑。
2.9.3 网络切换
网络切换包括：两种 4G 网络之间的切换，三家运营商之间的网络切换，移动网络和 Wi-Fi网络之间的相互切换。使用正交实验方法进行用例组合，会实现比较完整的测试。
2.9.4 待机唤醒
在手机进入待机状态之后，对于 App 要设计几个待机时长的等价类。至于待机的具体时长，可以通过咨询相应的开发人员，了解一下该 App 前台失效的等待时间阈值，在阈值边界处进行边界值（上点和离点）选取。
2.10 接口测试
App 的接口测试也是实际测试中使用非常频繁的一种测试类型。尤其是在快速迭代、一些紧急补丁的场景下，设计好充分的接口测试用例，自动进行快速测试比传统界面级别的功能测试的效率高很多。当然，效果也是很不错的。服务器端一般会提供 JSON（JSON 语法是 JavaScript 语法的子集）格式的数据给客户端，
这种格式就是键值对，如 "Name" : "David"。在服务器端需要进行接口测试，确保服务器端提供的接口和转换的 JSON 内容正确，对分支、异常流有相应的返回值。
此部分测试可以采用 ITest 框架完成，最方便的方法是采用 HttpClient。
下面给出几个接口测试的接口划分场景，以供参考。
（1）客户端和服务器端交互测试。
（2）测试客户端的数据更新和服务器端数据是否一致。
（3）当更新客户端时，客户端和服务器端断开。