专栏首页用户6517667的专栏APP测试类型—App自动化测试与框架实战(2)

APP测试类型—App自动化测试与框架实战(2)

来源: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

本文分享自微信公众号 - 软件测试培训(iTestTrain),作者:软件测试培训

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-06-21

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 了解App测试—App自动化测试与框架实战(1)

      传统软件都部署和安装在计算机(台式机和笔记本电脑)上,而App的载体是手机等智能移动终端,因此我们可以将手机这个概念扩充为"智能移动终端"或者"智能终端"。

    小老鼠
  • 通过一张图来了解一下敏捷测试和DevOps测试

    现在DevOps已经成了一个非常热门话题,但是又有谁真正理解了DevOps,可能少之又少。上周聆听了茹炳晟老师的在线课程,通过一张图我才发现真正理解了DevOp...

    小老鼠
  • 关于自动化测试的定位及一些实践思考

    大家对自动化的理解,首先是想到WebUI自动化,这就为什么我一说自动化,公司一般就会有很多人反对,因为自动化的成本实在太高了。其实自动化是分为三...

    小老鼠
  • 了解App测试—App自动化测试与框架实战(1)

      传统软件都部署和安装在计算机(台式机和笔记本电脑)上,而App的载体是手机等智能移动终端,因此我们可以将手机这个概念扩充为"智能移动终端"或者"智能终端"。

    小老鼠
  • 生产环境中进行自动化测试

    大多数功能测试用例和自动化测试用例在测试环境中以速度验证通过,但是很难保证这些用例在生产环境中具有相同的效果。特别是跨浏览器测试,则需要确保跨各种操作系统,运行...

    八音弦
  • 你掌握的那点代码技术 ,很容易被淘汰的 。

    对于测试团队 ,严格来说;老徐把其分为两个岗位:「业务测试工程师」和「测试开发工程师」 。

    IDO老徐
  • SnpSift学习笔记(三)

    本篇主要介绍caseControl, rmRefGen, tstv, rmInfo, gt, vcfcheck这6个命令的用法。

    生信修炼手册
  • WordWind(Java版)开发环境搭建

    我的操作平台Windows 7 64位操作系统,如果是32位的则在拷贝有些Jar包的时候注意对应32位的。

    卡尔曼和玻尔兹曼谁曼
  • 小米赴港IPO背后的潜台词

    孟永辉
  • Web端自动化测试失败原因汇总

    最初的测试自动化失败是从不切实际的期望中获得的。在我的职业生涯中,我已经多次观察到它,一旦您获得了自动化的质量保证或工作人员,管理层就期望他们对所有内容进行自动...

    八音弦

扫码关注云+社区

领取腾讯云代金券