浅谈移动终端Web应用测试 - 最终版

浅谈移动终端Web应用测试21/21浅谈移动终端Web应用测试浅谈移动终端Web应用测试陈宝珠石艳芬2012-06-08

目录浅谈移动终端Web应用测试 31. 移动终端及移动Web应用的定义 31.1 移动终端 31.2 移动Web应用 32. 嵌入式软件测试与传统PC软件测试的异同 32.1 嵌入式软件测试与传统PC软件测试的相同之处 42.2 嵌入式系统软件的独特之处 73. 移动终端Web应用测试的特点 113.1 移动终端应用的热点问题 113.2 移动终端Web应用测试的关注点 123.3 移动应用中的自动化测试 133.4 移动应用中的性能测试 194. 声明 215. 参考文献 21

浅谈移动终端Web应用测试随着越来越多的企业软件拥抱移动互联网，移动终端Web应用也已成为IT产业中的一大热点。而作为一名测试工作者的角度，本文将从移动终端应用软件测试与传统的应用软件的异同的角度，逐步阐述移动终端Web应用软件测试的相关内容。移动终端及移动Web应用的定义移动终端定义：在移动通信设备中，终止来自或送至网络的无线传输，并将终端设备的能力适配到无线传输的部分。移动终端或者叫移动通信终端是指可以在移动中使用的计算机设备，广义的讲包括手机、笔记本、平板电脑、POS机甚至包括车载电脑。但是大部分情况下是指手机或者具有多种应用功能的智能手机以及平板电脑。移动Web应用简单来理解，移动Web应用就是针对移动终端优化过的Web站点。Web站点上的内容无关紧要，可以是一个标准小型企业的宣传册，也可以是按揭贷款计算器，甚至是一个每日热量消耗记录的工具。移动Web应用定义性的特点是，用户界面(UI)是用Web标准技术建立的，它能够通过一个URL(公开的，私有的，或者是需要登录的)访问到，而且针对移动终端的特点优化过。嵌入式软件测试与传统PC软件测试的异同众所周知，移动终端产品属于一种嵌入式产品。而要想深入了解移动终端应用软件测试与传统的应用软件的异同，应先从嵌入式软件测试与传统PC软件测试的异同开始着手分析。首先，这里讨论的嵌入式软件测试是一个系统测试的概念。即将开发的软件系统（包括嵌入式操作系统和嵌入式应用软件）、硬件系统和其它相关因素（如人员的操作、数据的获取等）综合起来，对整个产品进行的全面测试。然而，嵌入式软件与传统PC软件相比，它具有专用性，它只能在需求所指定的硬件平台上执行，并且嵌入式软件的开发环境和运行环境是不一致的，因此即使宿主机环境下测试再充分，也不能说明在目标机环境下运行该软件就不出问题。因而，嵌入式软件还面临着目标环境的测试。这不仅增加了测试的代价，而且还带来了嵌入式软件的测试策略问题，即哪些测试分配在宿主环境进行，哪些测试分配到目标环境下进行。所以，嵌入式软件测试更有它的必要性，而且比一般的软件测试存在更多的困难，主要体现如下：测试软件功能依赖不需编码的硬件功能，快速定位软硬件错误困难；强壮性测试、可知性测试很难编码实现；交叉测试平台的测试用例、测试结果上载困难；基于消息系统测试的复杂性，包括线程、任务、子系统之间的交互，并发、容错和对时间的要求；性能测试、确定性能瓶颈困难；实施测试自动化技术困难。嵌入式软件测试与传统PC软件测试的相同之处传统的软件测试是将软件分在不同的层面上进行测试，包括模块测试（或单元测试），集成测试，系统测试等。嵌入式软件测试和一般的软件测试存在着许多相似的问题和相似的解决方法。这就是我们寻找的嵌入式软件的通用的测试方法。按阶段可分为单元测试、集成测试、系统测试和确认测试单元测试(Unittesting)完成对最小的软件设计单元的验证工作，只有在该基础之上才能保证后续的测试工作。主要采用白盒测试技术，用来保证单元的最大覆盖率和发现编码和详细设计中的错误。单元测试一般可以就在宿主环境上运行。嵌入式测试系统一般分为以下几个单元:预处理和词法语法分析单元、插桩单元和测试信息分析和显示单元以及测试用例单元。集成测试(Integrationtesting)是把经过单元测试的模块按软件的结构组合在一起作为一个系统或一个子系统来综合测试。主要是用来发现程序的架构和体系结构设计方面的错误。虽然白盒测试用来保证大部分的路径覆盖率，但黑盒测试在集成测试中还是比较广泛。集成测试一般是在宿主环境中进行。系统测试(SystemTesting)将系统的测试软件系统和其他资源(硬件、人机交互信息资源和数据库等)都综合起来构成完整的计算机应用系统进行测试的。是用来确保整个系统的性能、执行强度、安全性和功能都达到了我们的要求。所以在这个阶段是要和硬件结合，即和目标板一起进行测试，在目标环境中进行。确认测试(Validationtesting):是把软件系统作为一个单一的执行实体而进行的需求有效性测试。其目的是验证我们的软件是否满足所有的功能、行为和执行要求，这部分主要是用黑盒测试。根据测试时是否运行被测试的程序，软件测试技术还可分为静态测试方法和动态测试方法静态测试方法静态测试方法的主要特征就是不运行被测试的程序，主要采用检查、技术复审和代码静态分析来检查被测软件的错误，对于嵌入式软件来说该测试只需在主机上进行就可以了;动态测试方法动态测试方法是使被测代码在相对真实环境下运行，从多角度观察程序运行时能体现的功能、行为、结构等，并从中发现错误。它又分为白盒测试方法和黑盒测试方法。对于嵌入式软件来说，为了保证测试的真实性，一般要求在目标环境中进行。从测试是否针对系统的内部结构和逻辑处理过程，通常可分为:白盒测试与黑盒测试黑盒测试黑盒测试又称为功能测试、数据驱动测试或基于规格说明的测试。它必须依靠能够反映这一关系和程序功能的需求规格说明书来考虑测试用例和推断测试结果的正确性。即所依据的只能是程序的外部特性。因此黑盒测试是从用户观点出发的测试。黑盒测试方法包括等价类划分、边界值分析、因果图和正交设计等基于软件功能的测试技术。在进行嵌入式软件黑盒测试时，要把系统的预期用途作为重要依据，根据需求中对负载、定时、性能的要求，判断软件是否满足这些需求规范。为了保证正确地测试，还需要检验与硬件之间的接口。嵌入式软件黑盒测试的一个重要方面是极限测试。在使用环境中，通常要求嵌入式软件的失效过程要平稳，所以，黑盒测试不仅要检查软件工作过程，也要检查软件失效过程。白盒测试白盒测试又称为结构测试、逻辑驱动测试或基于程序的测试。采用这一测试方法，测试者可以看到被测的源程序，用以分析程序的内部构造，并且根据其内部构造设计测试用例。这时测试者可以完全不顾程序的功能。白盒测试方法又包括逻辑覆盖、符号测试、路径分析、程序插桩和程序变异等基于软件内部结构的测试技术。白盒测试与代码覆盖率密切相关，可以在白盒测试的同时计算出测试的代码覆盖率，保证测试的充分性。由于严格的安全性和可靠性的要求，嵌入式软件测试同非嵌入式软件测试相比，通常要求有更高的代码覆盖率。在软件工程的测试中有一个颇为实用的覆盖准则，即当语句覆盖率100%，分支覆盖率≥85%时，认为测试是理想的，软件错误可查出近90%，且允许时间和空间的消耗。日本日立公司和美国空军均采用此标准。对于嵌入式软件，白盒测试一般不必在目标硬件上进行，更为实际的方式是在开发环境中通过硬件仿真进行，所以选取的测试工具应该支持在宿主环境中的测试。嵌入式软件测试强调的是白盒测试，一般的白盒测试包括语句覆盖、分支覆盖和条件覆盖。嵌入式系统软件的独特之处嵌入式系统由于自己本身的特点，如实时性强、内存不丰富、I/O通道少、开发工具昂贵并且与硬件紧密相关、CPU种类繁多等等，决定了不同的嵌入式系统必须有不同的测试方法，下面介绍几种不同的嵌入式产品在测试时应特别关注的问题。唯一系统——“一次性”开发某些系统，比如人造卫星，一旦发射之后就无法对其进行维护。这样的系统是“唯一系统”，意味着其建造是一次性的。自治系统有些嵌入式系统可以在无限长的时间内自主运行，它们担负某种任务。一旦运行后，就不再需要有人干预或与人交互。硬件限制硬件资源的局限性会给嵌入式软件带来一定的约束，比如内存使用和电力消耗。有时候特定的硬件也依赖于软件中计时的解决方法。对软件方面的这些约束并不会影响到需求的系统功能，但它们却是系统运行的首要条件，需要对此进行大量深入而技术性又很强的测试。硬实时行为“实时”的本质就是输入或输出在发生的瞬间就能够影响到系统的行为。控制系统控制系统通过连续的反馈机制和环境相互作用：系统的输出会影响环境，而环境反过来会影响到控制的行为。强调安全系统在嵌入式系统中当嵌入式系统的故障会导致对人体健康的严重伤害（或更为可怕的后果）时，则称该系统是“强调安全”的。大量的嵌入式系统都和人体有直接的物理接触，故障会直接导致身体的损伤，例如航空电子设备、医疗设备及核反应堆等。对这样的系统进行风险分析是极其重要的，需要采用严格的技术来分析并提高系统的可靠性。极端的环境条件有些系统需要在极端的环境条件下进行连续的操作，比如极热或极冷、机械震动、化学物质或放射性等环境条件。测试这些系统需要有特殊的设备来提供极端条件。当真实环境中的测试太危险时，就需要用设备来模拟环境。嵌入式软件集成测试注意事项嵌入式软件集成测试不仅要求软件行为的正确性，而且它要与其被控制的硬件设备实现正确的交互。在具体测试过程中可包含以下几个方面的测试工作任务测试首先独立测试系统中的每个任务，对每个任务设计白盒测试和黑盒测试用例。任务测试可以发现任务中的逻辑错误和功能错误，不能发现实时性错误和行为错误;行为测试:通过使用CASE工具创建的软件模型来仿真实时系统，按照外部事件(如中断、控制信号和数据)的序列检查其行为的正确性，可以先对每个事件进行独立测试，然后随机的把事件输入给系统来检查系统行为的正确性;任务间测试独立的任务测试完成后，就可以多个任务一起来测试时间相关的错误，错误用不同的数据率和处理负载来测试任务间的通信，来确定任务间的同步是否会产生;另外，测试通过消息队列和数据存储进行通信的任务以发现这些数据存储区域大小方面的错误。集成测试集成软件和硬件一起测试，来发现软硬件之间接口错误，同时测试是否存在中断处理方面的错误，包括中断优先级的分配是否正确、中断的处理是否正确、中断处理是否满足时间要求、多个中断出现的情况下系统的功能和性能是否存在问题。特殊的交叉式测试策略这里介绍一种典型的嵌入式测试策略——交叉测试，它采用数字平台的方法，将嵌入式软件从系统中剥离出来，通过开发CPU指令、常用芯片、I/O、中断、时钟等模拟器在HOST上实现嵌入式软件的测试。简单来说，与目标环境无关的部分在PC机上完成，与硬件密切相关的部分在Target上完成，最后在目标环境中确认。其主要特点：与嵌入式硬件平台脱钩；操作简单，可以借鉴常规的软件测试方法；适用于功能测试；有局限性等。下面介绍在测试的各个阶段有着通用的策略。单元测试所有单元级测试都可以在主机环境上进行，除非少数情况，特别具体指定了单元测试直接在目标环境进行。最大化在主机环境进行软件测试的比例，通过尽可能小的目标单元访问所有目标指定的界面。在主机平台上运行测试速度比在目标平台上快的多，当在主机平台完成测试，可以在目标环境上重复作一简单的确认测试，确认测试结果在主机和目标机上没有被他们的不同影响。在目标环境上进行确认测试将确定一些未知的，未预料到的，未说明的主机与目标机的不同。例如，目标编译器可能有bug，但在主机编译器上没有。集成测试软件集成也可在主机环境上完成，在主机平台上模拟目标环境运行，当然在目标环境上重复测试也是必须的，在此级别上的确认测试将确定一些环境上的问题，比如内存定位和分配上的一些错误。在主机环境上的集成测试的使用，依赖于目标系统的具体功能有多少。有些嵌入式系统与目标环境耦合的非常紧密，若在主机环境做集成是不切实际的。一个大型软件的开发可以分几个级别的集成。低级别的软件集成在主机平台上完成有很大优势，越往后的集成越依赖于目标环境。系统测试和确认测试所有的系统测试和确认测试必须在目标环境下执行。当然在主机上开发和执行系统测试，然后移植到目标环境重复执行是很方便的。对目标系统的依赖性会妨碍将主机环境上的系统测试移植到目标系统上，况且只有少数开发者会卷入系统测试，所以有时放弃在主机环境上执行系统测试可能更方便。确认测试最终的实施舞台必须在目标环境中，系统的确认必须在真实系统之下测试，而不能在主机环境下模拟。这关系到嵌入式软件的最终使用。通常在主机环境执行多数的测试，只是在最终确定测试结果和最后的系统测试才移植到目标环境，这样可以避免发生访问目标系统资源上的瓶颈，也可以减少在昂贵资源如在线仿真器上的费用。另外，若目标系统的硬件由于某种原因而不能使用时，最后的确认测试可以推迟直到目标硬件可用，这为嵌入式软件的开发测试提供了弹性。设计软件的可移植性是成功进行交叉测试的先决条件，它通常可以提高软件的质量，并且对软件的维护大有益处。移动终端Web应用测试的特点了解了这么多嵌入式软件测试的特点后，现在来具体看看移动终端Web应用测试，它除了具有一般Web应用测试的特点外，还在测试环境（平台）、网络测试、交互测试、分辨率测试、兼容性测试等诸多方面存在其自身特点。而正由于这些特殊性在诸如UI测试、自动化测试、性能测试等组织和使用工具上，与传统的Web应用测试有着不同，下面就这些不同做一些粗浅的分析和介绍。移动终端应用的热点问题跨平台或者多终端适配问题即如何更快更好的让应用适配到多个平台。大屏幕和高分辨选项已逐渐变得重要。另外在做界面的时候一定要留出可伸缩的范围，留下页面拉伸的余地。移动Web特别是HTML5作为一种跨平台方案的优劣和适用范围如果用HTML5做游戏类应用的话，现在已可在iOS上进行尝试，而Android平台上则效果相对较差。平台选择这关系到背后需要投入多少的时间和精力问题。企业级应用的安全性如何处理数据安全问题，是需要事先考虑的重要事项之一。将业务数据封装为组件，适用于所有客户端，而客户端层面并不直接处理数据而是调用组件，其作用类似于定制化的浏览器，是目前可行的方法之一。移动终端Web应用测试的关注点针对以上热点问题，在测试中除基本测试外，有一下需格外关注的地方。测试环境跨平台或者多终端适配问题一直是当下移动终端的热点问题，针对这个问题常用方法即是上面介绍的交叉测试，可以在各平台（iPhoneOS、Android、Symbian等）模拟器测试、真机测试。网络测试移动终端是基于GPRS等无线网络访问，各种诸如WIFI、WAP、3G等不同网络连接状况下的显示效果。因为网络的不稳定性，对断网情况也需要进行测试。交互测试对来电话、来短信等优先级高的进程中断程序后是否能返回程序，屏保待机后是否能返回程序，程序退出后进程是否结束进行测试。兼容性测试平台兼容性测试在前面测试环境中有提到对各大平台厂商（iPhoneOS、Android、Symbian等）的支持，对同一平台厂商，不同操作系统版本的兼容。浏览器兼容性测试主要考虑内置浏览器和非内置浏览器的支持与兼容，同一浏览器不同版本的支持与兼容。分辨率兼容性测试由于现在移动终端的屏幕尺寸大小不一，其支持的分辨率也各不相同，对不同的分辨率下，图片、文字、控件的显示和布局是否合理进行测试。移动应用中的自动化测试面临的挑战自动化脚本需求自动化脚本需求在一个应用程序发布、正在被使用，和随后需要推出更新时更为紧迫。所有现存的特点需要每次推出更新时被测试，要确保在升级代码的时候没有回归误差。同时，各种各样的造型和模型，特别是像Android平台、自动化脚本、测试就不可避免。多种语言和环境脚本企业中通常采用将测试脚本可能需要综合回到语言和测试环境中，像JUnit、QTP、PERL或者Python。分布式测试越来越多的移动测试外包出去，甚至是海外外包。开发人员和测试人员可能地理上是分离的。测试环境下可能需要处理全世界许多地方的多个时区，或者使用不同的当地电信服务供应商。测试环境可能需要24/7/365和互联网/浏览器访问可用。发布自动化错误和崩溃跟踪一两个崩溃之后，用户就会放弃移动应用，甚至可能将其删除。移动应用可能需要在内部测试模式一段时期后，才第一次在应用商店发布。自动化测试工具可能需要监测和跟踪错误和崩溃，这些可能在正式的测试时遗漏掉了，即使在一个正式的发布之后。测试设备登记管理测试设备登记，特别是对于iOS设备，是一件苦差事，个人电话ID可能需要在苹果网站上注册。安装包需要以电子邮件的形式发送给测试人员进行安装和测试。自动化测试工具平稳并自动化地管理注册，让这个过程高效和有效。多个电话模型可用性打开移动操作系统，如：Android有一大批制造商直销运行着不同版本操作系统的移动设备。在这种情况下，移动应用测试要求种类繁多的设备制造商和模型可用，用以完成可靠的验证和认证。模拟器处理器缺陷模拟器，用笔记本电脑或者台式电脑运行时可以使用其他的处理器，移动设备上只能使用一个处理器。为了完成可靠的测试，自动化测试需要在实际的设备上操作，而不只是模拟器。远程响应测试移动应用在手机上可以独立的，或者通过后端服务器在执行期间频繁访问。后者中，从多个地理位置进行远程测试可能需要成为自动化测试的一部分。这是为了确保应用不论在哪里使用，其响应时间是合理的。介绍一种自动化测试工具——NativeDriver简介Google发布了NativeDriver，该工具是WebDriverAPI的一种实现，使用原生UI而不是浏览器UI（Selenium）的自动化测试框架，用于运行Android应用程序的功能测试。Google决定重用WebDriverAPI用于原生应用而不是创建全新的接口是因为两者之间有许多相似点——它们都控制相同的UI操作如点击、输入、读取文本、切换窗口，而且熟悉WebDriver的用户不需要学习另一种API就可以立即开始使用NativeDriver。该工具的主要功能NativeDriver可用于在原生应用中执行自动化UI命令以测试应用在不同情况下的操作。NativeDriver允许开发人员为应用程序创建自动化的测试。它创建了一个"Driver",通过点击按钮，对设备进行虚拟化调整，切换视图等其它操作来控制应用程序。NativeDriver复制了WebDriverAPI，而Google正是用WebDriverAPI来执行网页应用程序上的自动化测试。通过应用WebDriver和本地应用程序的相关技术，可以用来弥和差距，降低网页应用程序和本地应用程序之间的不匹配率。WebDriver支持在多种平台和浏览器中多功能地测试网页的应用程序Android-在SVN资源库中可用。iOS-目前尚在开发中。Windows-目前处在试验和原型阶段。介绍LinkedIn案例——移动APP开发的自动化测试与持续部署概述下面是LinkedIn移动应用的总体架构。图1LinkedIn移动应用架构所支持的平台(iPhone,Android,mobileweb)主要使用JavaScript和HTML向Node.js移动服务器发送RESTful请求。而这个服务器通过RESTful调用从LinkedIn平台上获取数据。持续集成流水线我们的移动持续集成流水线一共包括五个阶段：Unittests:通常少于10秒，用于测试独立的模块和单元Fixturestests:通过使用静态或模拟数据对客户端应用进行测试。Layouttests:通过截屏并与基线图像进行对比，测试客户端应用的Layout。Deployment:自动部署到一个试运行环境中。End-to-endtests:在试运行环境中进行端到端的测试。前面的阶段通常比后面的阶段要快，而且在后一个阶段开始之前，必须保证前面的100%通过。单元测试及覆盖率使用Hudson做持续集成服务器，让它在每次提交之后就执行单元测试。用JsTestDriver做测试框架，因为它是能够支持持续集成的仅有的几个JavaScript单元测试框架之一。另外，它还可以计算测试覆盖率：图2.JsTestDriver中的代码覆盖率Fixturestests可以通过配置让客户端向一个nginx服务器发送请求，它会以JSON文件格式返回testfixtures。由于这些测试完成与模拟数据打交道，所以只要出错，就可以认为是客户端的bugs。而且，这些模拟数据的使用令测试执行得更快。还可以在测试过程中配置nginx，用来查看客户端是如何处理不同的HTTP状态码的。可以设置nginx规则，用于确保客户端代码能优雅地处理HTTP500错误，或204等。Layouttests这种fixtures环境也可以运行layouttests，它可以自动地验证界面渲染是否正确，而不需要人用肉眼来看。使用WebKitLayout和Rendering来做无标题栏（抬头）的浏览器截屏。当界面开发完成后，这个截屏就被标记为基线。只要根据这个基础PNG文件进行对比，就可以发现回归问题。这些工具fixtures会让那些引起UI变化的随机数据最少化。有一少部分情况下，渲染总是动态的，比如时间戳，在截屏之前，我们执行特定的JavaScript用静态数据来取代动态的数据。PNG的比较，我们也增加了一些容忍度，因为在某些情况下，WebKit会生成稍有不同的PNG文件。部署与端到端测试当layouttests全部通过以后，一个产品构建就会自动化的部署到试运行环境中，并运行端到端的测试。这些测试会在整个架构上执行全路径，并试图捕获在之间的测试中可能遗漏的任何集成问题。在生产环境上也运行端到端的测试，可以快速地识别任何livesite的问题，比如某个服务器宕机了，或者负载平衡器出了问题。使用SeleniumWebDriver和TestNg.来创建端到端的测试。使用iPhoneDriver让这些测试可以运行在一个iPhone模拟器之上。而Selenium-WebDriver的测试可以使用很多种语言来写，而我们用Java，因为对它的支持比较广泛。这里有一些Selenium-WebDriver测试的例子。使用JSCoverage来分析端到端测试的覆盖率：图3.JSCoverage:红色是没有被端到端测试执行到的代码小结通过所有这些移动持续集成的阶段，测试覆盖率为75%，这使我们能捕获到很多bugs，尤其是单元测试和fixturestests。这些测试的一个要点是快速：当新代码提交后，通常不到5分钟就可以找到。在发现漏到开发中后面阶段（比如试运行和生产环境）的问题来说，端到端测试也是有帮助的。在不久的将来，随着团队更趋于测试驱动开发（TDD），我们会在流水线的最后增加一个阶段：向生产环境部署。这样，就达成了持续部署的目标。一个资深测试的自动化测试心得（当然不是我）自动化测试可以帮助提升技术团队与客户团队之间的合作，帮助团队更加透彻地理解业务需求，辅助指导开发方面。功能测试与单元测试有重叠的部分，开发者要综合考虑所花费的时间精力以及找到缺陷的概率，尽可能找到平衡点。自动化测试并不能测试到用户对应用的感觉，也不能对动画效果进行测试。让自动化测试价值最大化需要持续集成环境的支持，这样你才可以持续获取测试结果反馈。移动应用中的性能测试移动Web性能的基本的思路衡量：确定分析性能的指标和标准。分析：通过工具对性能问题进行度量。研究：分析性能问题，找出根源。最佳实践/分享：总结出最有可能改进移动性能的各种方法，并发布出来。提示：开发提示性能问题的工具。自动化：提供服务修补问题。移动平台的特殊性移动设备的硬件限制。移动浏览器的精简实现。移动网络的不稳定性。移动Web开发的发展阶段。介绍一个移动Web性能工具PCAPWebPerformanceAnalyzerPCAPWebPerformanceAnalyzer（简称pcapperf）工具充分利用了开放文件格式PCAP和HAR以及开源工具cap2har、HARViewer和PageSpeed的技术优势。对于性能分析工程师来说，首先抓取移动设备的PCAP文件，然后使用pcapperf分析PCAP文件，绘制出网络瀑布图，获取PageSpeed的建议，或者下载PCAP文件的HAR格式输出。PageSpeed团队已经利用pcapperf发现了移动浏