第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的稳定性测试中是一个必选途径。
版权声明：51Testing软件测试网获人民邮电出版社和作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
