Android平台下手机软件功能测试模型的研究与应用（可编辑）

Android平台下手机软件功能测试模型的研究与应用（可编辑） Android平台下手机软件功能测试模型的研究与应用 漳州师范学院 毕业论文(设计) Android平台下手机软件功能测试模型的研究与应用 The research and application of the functional testing model of Android mobile phone software 姓 名: 学 号: 090811426 系 别:计算机科学与系 专 业: 计算机科学与技术 年 级: 09级 指导教师: 2012年5月30日 摘要 Android系统是近几年来新兴的智能手机系统,其显著的开放性使其拥有更多的开发者。随着用户和应用的日益丰富,Android平台也日趋成熟。与此同时,针对android手机的软件工程理论与技术也成为国内外的研究热点。对android手机软件而言,良好的测试模型是保证测试质量进而保证产品质量和可靠性的重要途径。 本文以手机软件测试技术为主线,选取了较为常用的UC浏览器为测试实例,根据对实际工作经验的总结,详细分析了android手机软件与传统软件的差别以及在测试工作中存在的问题,并根据分析结果提出了一种针对android手机 软件的测试模型框架。 关键字:android手机;手机软件测试;测试模型框架 AbstractAndroid system is an emerging intelligent mobile phone system in last few years. In advantage, the first is the openness, it allows any mobile terminal manufacturers to join in. With the significant openness so that it has more developers, with the increasingly users and applications, a new platform will also soon to mature。It is hot for the android mobile phone software engineering theory and technology over the world. For the test of android mobile phone software, the test model is the important way to guarantee the quality of test and ensure the product quality and reliability, a special and rational test model framework for android smart phones plays a decisive role in testBased on the mobile phone software testing technology as the main line, choose the UC browser commonly used for test case. According to the summary of actual working experience, analyze the difference the problems in test between the android mobile phone software and the traditional software carefully, and come up with a feasible solution of the test model framework of android smart phone software test implementation according to the results of analysis and demand. Key words: Android Mobile Phone, Mobile Phone Software Test, Test Model Framework 目 录 摘要 I Abstract I 1.引言 1 2.安卓系统简介 1 3.手机软件概述 2 3.1智能手机软件分类及范围 2 3.2 安卓手机软件特点 3 4. 手机软件测试类型 4 4.1 功能测试 4 4.2 性能测试 4 5.测试实践 5 5.1 测试策略及模型选择 5 5.2 测试工具的选择 6 5.3 测试 7 5.4 测试过程中的风险和应对措施 7 5.5 测试设计 9 5.6 测试实施与分析 11 5.7 测试总结 22 6.结论 23 致谢 25 1.引言发布仅仅四年时间,安卓成功打败了称霸智能手机界十年的诺基亚, 超越了苹果,成为了全世界最受欢迎的智能手机平台。这个成功是拉里?佩奇都没有想到过的,这个曾经将乔布斯当作创业导师的年轻人如今已然站在了导师[1]。 安卓系统虽然拥有很多优点,但仍然存在众多无法忽视的缺点。由于移动设备厂商会针对多个共存的Android系统推出不同的新产品,从而引发了平台分化问题。对于软件开发者而言,这一问题非常棘手,因为他们必须要支持所有版本。正因为以上问题,导致对于安卓软件的测试必不可少。手机软件大体分为游戏、影音、浏览器、通讯、安全等类。对于不同种类的手机软件,都有各自适合的测试模型,面向模型的软件测试技术是测试效率很高的测试方法,是目前其他测试方法无法替代的。当然,它也不能替代已有的其他测试技术,因为,软件中的故障仅仅只依靠该方法进行测试是不行的。随着软件模型类型的逐步增多,测试算法的逐步成熟,以该方法为基础所开发的测试系统必然会在市场上广泛在我国,该技术的研究则刚刚起步,但已经收到了很好的效果[2]。从这么多个模型中挑选出适用于手机软件测试的模型正是我们现在需要努力的方向。 2.安卓系统简介 Android是一种以Linux为基础的开放源代码的操作系统,主要使用于便携式设备。目前尚未有统一中文名称,中国大陆地区较多人使用“安卓”或“安致”。Android操作系统最初由Andy Rubin开发,最初主要支持手机。2005年由Google收购注资,并组建开放手机联盟开发改良,逐渐扩展到平板电脑及其他领域上。Android的主要竞争对手是苹果公司的iOS以及RIM的Blackberry OS。2011年第一季度,Android在全球的市场份额首次超过塞班系统,跃居全球第一。 2012年2月数据,Android占据全球智能手机操作系统市场52.5%的份额,中国市场占有率为68.4%。 Android的系统架构和其它操作系统一样,采用了分层的架 构。android分为四个层,从高层到低层分别是应用程序层、应用程序框架层、系统运行库层和Linux核心层。作为一款开放式的操作系统,随着Android的快速发展,如今已允许开发者使用多种编程语言来开发Android应用程序,而不再是以前只能使用Java开发Android应用程序的单一局面,因而受到众多开发者的欢迎,成为真正意义上的开放式操作系统。在Android中,开发者可以使用Java作为编程语言来开发应用程序,也可以通过NDK使用C/C++作为编程语言来开发应用程序,也可使用SL4A来使用其他各种脚本语言进行编程(如:python、lua、tcl、php等等),还有其他诸如:Qt(qt for android)、Mono(mono for android) 等一些著名编程框架也开始支持Android编程,甚至通过MonoDroid,开发者还可以使用C#作为编程语言来开发应用程序。另外,谷歌还在2009年特别发布了针对初学者的Android Simple语言,该语言类似Basic语言。而在网页编程语言方面,JavaScript,ajax,6>HTML5,jquery、sencha、dojo、mobl、Phone-Gap等等都已经支持Android开发。而在Android系统底层方面,Android使用C/C++作为开发语言。 安卓开源带来巨大的成功的同时也面临着巨大的问题,最大的问题就是市场混乱,各个厂商之间的产品大同小异,同质化严重,应用市场混乱。开始标榜的不易中毒,到现在已成为人们攻击的对象。厂商之间为了争夺市场,在平台相同的情况下只有走向拼硬件的道路。最终走向了与计算机发展同样的道路上。光靠拼硬件是无法走远的。这就要求厂商加强技术开发,这对技术研发能力相对不强的厂商来说无疑是个硬伤。由于安卓的开源应用市场混乱,应用同质化严重,病毒木马程序越来越多,威胁用户个人信息的安全。安卓更新太频繁,各个手机厂商的标准不一样导致手机的升级跟不上。设备采用大触屏,拥有绚丽的画面,这就导致 了手机待机的时间的不足,一般情况下只能维持一天的使用,这对经常出差和业务比较忙的用户来说无疑是很不方便的。 3.手机软件概述 3.1智能手机软件分类及范围 从开发的角度上简单的说手机软件可以分成应用软件、用户界面、操作系统、底层与设备驱动以及通信协议等几个方面。 3.1.1应用软件 包括游戏、聊天工具、浏览器、电子邮件、音乐播放器、视频播放器、日程管理、电子辞典、语音录音、语音识别以及汉字输入等等。相对应的是手机应用软件的功能测试。 其中基于安卓手机的应用软件测试工作在手机功能测试中占有很大的比重,目前这类应用软件大致可以分为以下四类: ? 嵌入式的手机应用软件:这是一种传统的手机应用软件的应用模式,手机中的应用软件都是出厂时由手机生产商固化在其硬件设备的芯片中的,例如手机中的内置闹钟、日历、浏览器等等。 ? 基于短消息的手机应用软件:短消息服务SMS是通过手机发送和接收有限长度的文本信息的服务。短消息服务类型的手机应用软件的使用方法通常是用户发送一条特定的信息到某个手机应用软件提供商的服务器,服务器接收这条信息执行一系列操作后返回一条带有结果的消息到用户的手机中。 ? 基于浏览器的手机应用软件:目前几乎所有智能手机都支持WAP无限应用协议浏览器。手机用户通过移动运营商门户网站的一个链接进入手机应用软件供应商的URL,下载并浏览一个或多个页面,通过交互将数据提交到服务器。 ? 基于下载方式的手机软件:运用J2ME、Java技术开发的手机应用软件是一种可以下载到用户手机使用的手机应用软件。它们极大地提高了智能手机支持应用软件的能力,并且有比SMS或WAP更好控制的界面,允许使用子图形动画,可以通过无线网络连接到远程服务器。J2ME、Java技术提供了一个相对开放的平台,手机用户可以随需扩充手机功能在手机上附加别的应用。 3.1.2用户界面 包括待机界面、呼叫控制、MMS界面、短消息/EMS界面、菜单的显示、电话号码或名字等等一切操作手机时所能够看到的、听到的和摸到的过程控制。开发用户界面涉及到对GUI和通信过程的理解。这类软件是界面测试的主要对象。 3.1.3嵌入式多任务操作系统 每个手机里而都有一个嵌入式多任务操作系统,在测试的阶段对应操作系统相关的文件管理、多任务调度、响应时间、多线程测试等交互功能的测试。 3.1.4底层部分 包含语音编解码、信令在无线接口上进行传输编解码、数据编解码等等内容。底层网络软件主要完成呼叫的建立、连接、释放等工作。设备驱动指的是LCD驱动、Flash驱动、GPIO驱动、MIDI芯片驱动、通用串口驱动、USB驱动、电源管理单元驱动等等方面。在测试阶段对应与硬件相关较高的相关设备测试、电源测试等阶段。这部分测试与硬件耦合性较高,因此不在本文的讨论范围之内。 3.1.5通信协议 包含完成空中传输过程第2层、第3层协议、补充业务协议、数据传输协议、以及SIM/UIM协议等等。扩展一点,TCP/IP协议,WAF协议也可以归在这一 类。相对应的测试也是独立于手机应用软件测试的比较难以控制实施的协议测试,这部分测试包含关键技术较多,是独立出来的另外一个研究领域,不在本文的讨论范围之内。 3.2 安卓手机软件特点 安卓智能手机属于运算功能有限、电力供应也有限的嵌入式装置中的一种,因此其软件特点与嵌入式软件也有相似之处。嵌入式软件的优点在于代码执行效率高,不过由于与硬件高度相关,也存在软件可移植性差的通弊。 3.2.1 软件要求固态化存储 为了提高执行速度和系统可靠性,嵌入式系统中的软件一般都固化在存储器芯片或单片机本身中,而不是存贮于磁盘等载体中,可以随意更换,所以嵌入式系统的应用软件生命周期也和嵌入式产品一样长。 3.2.2 软件代码高质量、高可靠性 尽管半导体技术的发展使处理器速度不断提高、片上存储器容量不断增加,但在大多数应用中,存储空间仍然是宝贵的,还存在实时性的要求。为此要求程序编写和编译工具的质量要高,以减少程序二进制代码长度、提高执行速度。 3.2.3 系统软件的高实时性 在多任务嵌入式系统中,对重要性各不相同的任务进行统筹兼顾的合理调度是保证每个任务及时执行的关键,单纯通过提高处理器速度是无法完成和没有效率的,这种任务调度只能由优化编写的系统软件来完成,因此系统软件的高实时性是基本要求。由于手机使用的特殊性,因此要求手机软件响应时间达到一定限制范围。也就是所谓的实时操作系统,如果一个电话不能在90秒内接听,那么对方可能会结束此次呼叫,若操作系统还没反应过来,那么这个操作系统无疑 是失败的,这就是手机软件对嵌入式操作系统实时性的要求。 3.2.4硬件相关性 手机软件系统不像WINDOWS操作系统,有图形界面可以输入输出:也不像DOS操作系统使用命令行模式,而是需要自己编写一个编辑器,编写一个交互界面|:上及一个输入输出界面。在WINDOWS中,不用考虑硬件的问题,因为系统WINDOWS是讲究和硬件分离的,这样可以保护系统不受侵入。而在嵌入式系统里面,这些都要求和硬件息息相关。嵌入式处理器的功耗、体积、成本、可靠性、速度、处理能力、电磁兼容性等硬件方面的特殊性,均与应用相互制约。软件的专用性:由于手机软件设计是以一定的目标硬件平台为基础的、面向固定的任务进行的,因此,一旦被加载到目标系统上,功能必须完全确定。 3.2.5面向消息的编程思想 对于手机这样一个复杂的人机交互系统采用面向过程的编程方法显然是不合适的。手机软件一般采用Windows程序的“Message based,Event Driven”基于消息,事件驱动的思想,上下层之间通过触发事件通知对方执行相应的操作.因此不同于传统的面向过程的编程方法,也与面向对象的编程方法有所区别。 4. 手机软件测试类型 4.1 功能测试 1)Basic Function [基本功能测试]:就是验证手机基本功能是否实现,发短信、通话、照相等,包括他们的子功能如转发、连拍等。最基本的也是投入时间精力最大的测试类型,也是最重要的,如果基本功能都没有实现其他测试也就变成枉然了。 2)UI [用户界面验证]:验证手机的界面、菜单等是否是与客户需求和设 计保持一致,主要依据 UI spec[用户界面说明],MMI[人机交互界面],Menu tree[菜单树]等,这些文档也是需要根据客户需求及时更新的。 4.2 性能测试 1)Limit Value [极限值测试]:对应黑盒测试的边界值分析法,边界值分析法设计出的测试用例发现 bug 的能力也是最强的,一般依据极限值表设计测试用例,来指导测试。一般测试点如输入字符的个数,会议通话的个数,文档存储个数等。 2)Confict Test[冲突测试]:主要依据冲突表,冲突表中列出各个事件之间是否存在冲突,冲突测试用例也是依据冲突表设计,这类用例往往可以发现一些比较严重的 bug ,如游戏中来电,流览WAP时插拔充电器、USB线、camera 中低电等。 3)Performance Test[性能测试]:主要测试项Call test,长时间通话,发送大容量的彩信x条,开关机x次,摄像x时间,可以考虑用自动化测试,手机自动化测试与PC软件自动化测试类似,利用自动化测试工具录制、调试 写脚本、回放、分析结果,与PC软件不同的是手机自动化测试需要硬件的支持来固定手机和利用气压按键。 4)Stress Test[压力测试]:压力测试是在将手机容量存储状态到满后做的一系列操作,如短信、彩信满,Idle界面各事件个数满如未接电话、闹铃等。 5)Network Compatibilit[网络兼容性测试]:网络参数的设置,GPRS等业务是否可用,本外地的联通移动卡各类业务卡在本地的作测试,还需要做Filed Test[场测]即到最终用户实际使用的环境作现场测试,Filed test 有国际专用用例。 6)SIM Card Compatibilit[SIM卡兼容性测试]:一般是对联通移动的各类业务卡,新出的大容量64K、国际漫游卡、呼叫限制卡、一卡双号卡等卡的验证,验证能否正确注册、对应的业务功能是否实现、基本功能的正确性。 7)PD test [Project Design Test]:验证在项目设计阶段的设计的功能是否得以实现、是否正确,设计用例依据项目设计文档。 8)CR Verification[客户需求验证]:验证客户的一些特定需求和变更后的需求。 9)User Manual [用户手册验证]:其重要性是不言而喻的,用户手册一定要和手机实际功能相符合,不然将会影响用户对产品的信任。 10)FAT Full Type Approval[全类型批准]:是GSM手机进入GSM网络必须通过的专业测试。 5.测试实践 5.1 测试策略及模型选择 一个好的测试过程是手机软件质量的保证,在未来的竞争中向用户提供最好的服务将成为取胜的关键,手机测试则是其中重要的环节。大部分手机软件在其一生中都将经历多次测试,主要有;协议测试、单元测试,系统测试以及验证测试等,通过多次的测试,保证使用者在任何环节都能拥有性能良好的手机。选择适合手机软件的测试模型是执行测试工作的前提条件。根据智能手机软件的开发过程,本文所采用的测试模型是适合手机软件开发测试的v模型。 V模型的价值在于它非常明确地标明了测试过程中存在的不同级别,并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系: ?单元测试:其主要目的是针对编码过程中可能存在的各种错误,例如用户输入验证过程中的边界值的错误。单元测试是针对源代码的测试,是以后各种测试过程的基础,由于安卓应用软件的整个开发过程和测试过程是分开并行的,并且测试人员无法获得手机软件程序源代码,所以单元测试由开发人员在编程的过程中编写测试程序或者使用辅助工具来完成。 ?模块测试:这是传统测试V模型中所没有的,是针对本文设计的安卓手机软件测试方案添加的一个测试过程,准确的讲应该是Feature测试,这里的Feature并不是传统意义上的模块,而是一种功能部件。从模块粒度来说,它指粗粒度模块的功能,是面向客户需求的。它可能包含多个应用,用以实现某一类功能,属于系统级的黑盒测试。 ?集成测试:主要目的是针对详细设计中可能存在的问题,尤其是检查各Feature模块之间的接口上可能存在的错误。此过程是模块级集成的测试,而非传统意义上的单元集成的测试。它在功能模块集成或模块中应用的集成过程中进行,使用增量集成测试方法,用功能模块组合成越来越大的系统并进行测试,来检测组成的系统整体和各个功能模块是否正确。因此,也是系统级的黑盒测试。 ?系统测试:主要针对概要设计,检查了系统作为一个整体是否有效地得 到运行,例如在产品设置中是否达到了预期的高性能。 ?验收测试:通常由业务专家或用户进行,以确认产品能真正符合用户业务上的需要。由公司品质管理部门把关,包括RF射频、高低温、跌落、电气特性等方面的测试。这部分测试与硬件相关,可以采用辅助工具来完成,与软件相关性很小。 在不同的开发阶段,会出现不同类型的缺陷和错误,所以需要不同的测试 技术和方法来发现这些缺陷。针对手机软件开发过程的V模型主要突出了测试与开发过程的平等性和并行性,而针对测试过程本身的测试过程模型设计如图6?1所示: 在集成测试和系统测试阶段,都设计了烟雾测试稳健测试过程,烟雾测试是一组用以确定系统处于稳定状态、所有的主要功能都具备并且能够在“正常”条件下运行的测试用例。烟雾测试不能由测试小组独立来建立;它是通过联合的方式,至少是在与开发人员达成一致的情况下建立的。它的目标是显示稳定性、而不是发现系统的每个bug,必须在系统测试环境中运行。 5.2 测试工具的选择 5.2.1 Testin - 移动互联网质量服务专家 北京云测网络科技有限公司所推出的业界领先的移动互联网真机云测服务平台,主要产品包括RealTest?、 RealAuto?、RealMonitor?,为移动应用开发和服务提供商提供专业的基于真实终端,跨地区真实移动网络的移动应用开发测试、自动原型测试、自动适配测试和应用程序运行质量的监控服务。 Testin RealMonitor智能监控服务,通过Testin真机云测平台以及遍布全球的监控节点,在真实手机(移动终端)、真实网络上为移动互联网服务提供商和开发者提供24小时不间断的功能、性能、用户体验和可用性的监控服务。 (1)监控类型:APP监控、网页监控(wap、web) (2)覆盖中国地级以上城市,香港、台湾、澳门及日本、东南亚、北美、大 洋洲及欧洲的主要城市。 (3)对于国内和海外主要移动运营商网络,和移动用户相对集中的地区,采用多监测点以保证监控数据的稳定和质量 (4)覆盖主流智能手机操作系统:iOS、Android、WP7、Symbian等 (5)覆盖主流终端厂商的移动终端:Apple、HTC、Samsung、MOTO、NOKIA、SonyEricsson、Lenovo、ZTE、Huawei等 (6)覆盖主流移动网络:GPRS、EDGE、CDMA、WCDMA、TD-SCDMA、EVDO、UMTS、HSDPA、LTE、WiFi等 。 (7)对于Testin暂时未覆盖的地区和网络,只要客户提出需求,Testin有能力在很短的时间内(一周内)开通监控节点,为客户提供服务。 5.2.2 中国移动开发者社区 开发者社区作为中国移动应用商场的产品生产基地,开发者们可以在上面发布自己的作品,满足商用条件后即可上线销售,为开发者带来高额的回报。 具有AP自服务区、能力池、终端池、操作系统池、机型信息库、创意孵化工坊、MM学院、工具文档等几大频道: (1)AP自服务区:具有作品管理、合作签约、结算管理、销售查询等功能,满足开发者的管理需要 (2)能力池:向开发者提供一个统一、易用、简便的开发环境。使开发者很方便地进行跨平台开发, 在同一代码的基础上,实现为不同的移动设备适应、构建和包装应用程序。可以为开发者节约开发者巨大的开发成本,快速帮助开发者把技术成果迅速普及到不同的手机操作系统。 (3)终端池:为开发者提供各种终端设备远程测试服务,使开发者测试应用适配性便捷轻松。 (4)操作系统池:为开发者提供一次开发、多次编译,生成多种手机应用,生成跨平台应用的工具。 (5)机型信息库:提供各种机型的信息内容,并与终端池无缝结合,提供真机体验服务。 (6)创意孵化工坊:用户仅需要将喜欢的内容在系统中上传,就可以在不需要编写任何代码的情况下,快速生成适用于手机系统的应用。 (7)MM学院:为开发者提供MM的知识培训以及考试认证。 (8)工具文档:拥有最齐全的各种开发工具和文档,为开发者提供更便捷的开发通道。 5.3 测试标准 测试通过标准:功能测试用例通过率大于等于97% 测试不通过标准:功能测试用例通过率小于97% 5.4 测试过程中的风险和应对措施 软件测试风险是指软件测试过程中出现的或潜在的问题,这些问题会给软件测试工作带来不同程度的损失。 软件测试风险产生的原因主要是测试的不充分、测试方法有误或测试过程的偏离、进度延误、任务量与人员能力比例失衡、测试工具的不合理使用或不熟练使用、测试资源的限制、测试范围的不合理等。[6] 5.4.1. 风险评估 风险评估是依据风险描述、风险概率和风险影响3个因素,从成本、进度及性能3个方面对风险进行评估,风险的评估师建立在风险的识别和分析的基础上。 表4-2 风险识别表 风险描述 风险概率 风险影响 测试计划不充分 可能 严重 测试方法有误或过程偏离 可能 一般 进度延误 可能 严重 任务量与人员能力比例失衡 一般 一般 测试工具的不合理使用或不熟练使用 可能 一般 测试资源的限制 极可能 一般 测试范围的不合理 可能 一般 测试数据的损坏或丢失 一般 极严重 测试系统的不完整 罕见 严重 测试结果不完全(不能发现全部错误) 极可能 一般 (说明:风险概率由高到低依次为极可能、可能、一般、罕见;风险影响由高到低依次为极严重、严重、一般、轻微。) 5.4.2. 风险控制 风险的控制是建立在风险评估的结果上,通过提前制定应急措施和可控制的方法对软件测试风险进行控制。 在做计划时,对软件测试所需的资源、时间、预算等的估算保留10%的余地,尽量避免可避免的风险。 项目开始之前,把一些环节或边界上可能发生的变化情况都考虑进去,对处于可控范围外的变动采取应急措施。 制定文档管理方案,对文档数据进行及时的管理、备份,确保软件测试的文档数据不会因为人为因素或不可控的因素造成的损坏或丢失。 5.4.3 应急措施 针对评估后的风险及控制方案,指定以下应急措施: 应急措施1:利用评审过程对测试计划进行再评审,并在可控的范围内对测试计划做可接受的修改,确保测试计划的合理性和充分性。 应急措施2:增加资源,在关键点对测试过程加快速度,提高进度。 应急措施3:优化测试方案和测试用例,加快测试执行的速度。 应急措施4:使用虚拟机等工具对测试环境进行模拟,扩大测试资源范围。 应急措施5:适当的调整任务分配,以保证任务量与人员能力相对平衡,加快测试效率。 应急措施6:建立测试文档数据归档机制,及时对测试文档数据进行管理、备份,保证软件测试数据的正确性和完整性。 应急措施7:缩小质量过程,对风险级别较低的特征测试,减少测试。 应急措施8:对测试工具进行评估,确保测试工具可用、并且能正确熟练使用。 5.5 测试设计 5.5.1 测试概述 嵌入式软件所有的单元级测试都可以在主机平台上进行 ,除非少数情况 ,特别具体指定了单元测试直接在目标平台进行。在主机平台上运行测试速度比在目标平台上快的多。当在主机平台完成测试可以在目标平台上重复作简单的确认测试 ,确认测试结果在主机和目标机上没有被他们的不同所影响。少数情况必须要求直接在目标平台上进行的可以采用交叉测试cross - testing策略。 对于数据方面的测试可以运用等价类划分、边界值分析、错误推测等功 能测试方法对被测软件的功能进行全面的测试和确认。依据软件本身的功能模块划分,对每个功能模块主要采用手工测试的方法逐一确认模块中的各个子功能是否实现,找出其中的缺陷和错误,并对测试结果进行分析,评价软件功能的实现率和与文档的符合程度,最后针对整个软件提出改进意见。 5.5.2 测试准备 测试过程中的输入主要有测试计划、完整的被测软件、用户文档、测试用例。即在测试准备阶段需要准备的有完整的被测软件、测试计划、测试环境设置及选用工具。 ?完整的被测软件:包括可执行的应用程序及帮助文档,使用指南等。具体包括完整的程序文件以及在线帮助等文档。 ?测试计划:包括测试范围、测试方法(策略)、测试环境和测试通过/不通过标准、人员任务安排、测试进度安排、风险及应急措施、测试计划审批及意见。 ?测试环境:我们可以选择通过Testin - 移动互联网质量服务专家或者中国移动的开发者社区提供的终端池在不同机型上测试软件的兼容性以及其他功能。 5.5.3 测试过程 参考手机软件系统测试方案框架图[7],制定如下可控制管理的软件测试过程。如下图所示: 1、制定测试计划。 一个详尽合理有效的测试计划能够对测试过程进行有效地约束、控制, 保证测试过程的顺利进行。并且能够对测试过程中可预见的异常及问题采取措施及时处理,从而保证测试过程与测试动作的正确进行。 2、测试需求分析。 以被测软件的使用说明书中功能说明为基础设计功能测试需求,并对生成的需求分析进行评估和审核,最终确定测试需求。 3、测试需求评审。 由于大多数的错误都是源于需求分析阶段,所以需求分析的正确、准确无误对以后的过程有着至关重要的作用。测试需求评审是对由软件功能说明推导出的软件测试需求做评审,以确保得到的测试需求符合软件功能,无偏差,完整无遗漏。 4、测试用例设计。 以测试需求分析为基础进行针对每一个测试需求点设计测试用例,争取做到测试用例覆盖每一个测试需求,并且每一个测试需求都可以在测试用例中有不同方面的体现,做到测试用例可跟踪、可追溯。 5、测试用例分析审核。 对设计出的测试用例进行分析审核,以确保设计选用的测试用例能够完全覆盖测试需求,并且对各种异常情况都有对应的用例进行执行分析。 6、测试执行。 执行每一个测试用例,确保测试用例执行情况无误,并且对测试用例执行过程中的异常和错误进行详实记录,以确保对每一个发现的Bug都能进行记录备案。对某些特殊的错误还要进行多次的执行测试用例,以确保错误异常的发生不是因为偶然的原因。 7、测试结果分析。 对测试用例执行结果进行归档,分析。分析错误发生较集中的模块和功能点,并统计错误数量与所在模块,为最终的测试结论做数据准备。 8、错误处理 为了正确跟踪每个软件错误的处理过程,通常将软件测试发现的每个错误作为一条条记录输入制定的错误跟踪管理系统。 9、测试报告。 根据测试用例的执行结果对软件的功能、性能进行分析、评估,以决定该软件是否符合上市标准,是否通过使用准则,满足功能需求中的说明,并对软件改进提出改进性参考意见。 5.6 测试实施与分析 5.6.1 测试用例设计 首先,我们先列出UC浏览器的测试点: UC浏览器: 网页的加载,收藏夹、历史记录的查看、语音输入、账户信息界面的加载、打开关闭网页、菜单设置等 测试目的:验证浏览器的各功能能正常实现,对整个浏览器的全部基本功能进行集成性测试,进而检查基本功能是否能够正常的运行。达到我们所需的系统状态,保证系统的稳定运行。 在测试过程中,首先需要对各子单元过程进行测试。在各子单元过程测试完毕后,再对各模块(包括各子单元过程之间的接口)进行测试,处理好各模块之间的接口,最后对系统进行测试和维护。 UC浏览器各子模块测试列表: 测试项目名称 测试内容 测试人员 网连接测试 输入网站链接,检查是否能够打开所要浏览的网页。 冯小冬 后退前进测试 测试网页浏览过后前进后退打开网页能否正常 冯小冬 历史浏览测试 通过点击浏览历史中的URL记录测试能否正常打开 冯小冬 测试浏览器主界面加载 不断打开和关闭浏览器,看浏览器每次是否能成功 加载进主界面。 冯小冬 测试浏览能否加载导航栏 每次打开浏览器,测试浏览器底部的导航栏能否 正常加载 冯小冬 测试账户信息界面的加载 触控相应的按钮进入账户界面 冯小冬 测试收藏夹栏的界面 触控相应的按钮进入收藏夹界面 冯小冬 语音输入测试 测试浏览器能否正确识别用户语音输入的信息 冯小冬 打开新网页测试 测试能否在浏览器中打开新的空白网页 冯小冬 根据上述各子模块,使用正交测试,对各个功能模块设计测试用例如下: 项目 UC浏览器 软件版本 V1.0 功能模块 网页连接测试 编制人 冯小冬 用例编号 UC_FUN_01 编制时间 2012.8.16 相关用例 连接的输入正常检测模块 功能特性 用户输入链接,点击连接建立连接浏览网页 测试目的 检查正常输入的链接是否能正常,所需网页是否能正常浏览 预设条件 用户输入网页URL 特殊规程说明 (区分大小写) 参考信息 需求说明中有关URL格式的说明 测试数据 //0>. 具体执行步骤 操作步骤 操作描述 数据 期望结果 实际结果 测试状态(P/F) 1 输入所要打开网页的URL //. URL检查没有错误提示 正常通过 P 2 确认建立连接,打开网页 //. 正常的打开百度页面 正常显示 P 测试人员开发人员负责人 项目 UC浏览器 软件版本 V1.0 功能模块 后退前进测试 编制人 冯小冬 用例编号 UC_FUN_02 编制时间 2012.8.16 相关用例 页面连接的Link用例 功能特性 把之前打开的网页再跳转回来,或者进入下一个网页 测试目的 保证网页连接的时刻状态良好性,及模块传值的正确可用性 预设条件 用户已浏览过网页。用户有所操作。 特殊规程说明 之前的 网页是正常的可用的,且页面有打开过 参考信息 URL格式,前进后退手势操作 测试数据 //.和.163切换 具体执行步骤 操作步骤 操作描述 数据 期望结果 实际结果 测试状态(P/F) 1 预先打开测试的网页 //.和.163 正常浏览 浏览正常,网页正常显 示 P 2 后退操作 后退手势 正常打开百度网页 百度正常现实 P 3 前进操作 前进手势 正常打开网易网页 网易网站页面正常显示 P 测试人员开发人员负责人 项目 UC浏览器 软件版本 V1.0 功能模块 历史浏览测试 编制人 冯小冬 用例编号 UC_FUN_03 编制时间 2012.8.16 相关用例 网页连接link用例 功能特性 把历史中记录的网页打开 测试目的 测试能否把历史记录正的URL打开,进而判断连接URL在保存时 是否正确,提取是值是否正常能够传递。 预设条件 已经有浏览历史记录 特殊规程说明 该记录为正常记录 参考信息 无 测试数据 浏览器中的网页浏览历史纪录 具体执行步骤 操作步骤 操作描述 数据 期望结果 实际结果 测试状态(P/F) 1 打开浏览历史选择所要打开的历史链接URL //. 正常链接URL 可以建 立连接 P 2 显示所要打开的网页 //. 百度首页正常显示 可以显示出来 P 测试人员开发人员负责人 项目 UC浏览器 软件版本 V1.0 功能模块 浏览器主界面加载 编制人 冯小冬 用例编号 UC_FUN_04 编制时间 2012.8.16 相关用例 浏览器主界面加载测试 功能特性 加载进入主界面 测试目的 测试浏览器是否能正常加载进入主界面 预设条件 不断打开和关闭浏览器 特殊规程说明 无 参考信息 浏览器主界面加载时间 测试数据 不断打开和关闭浏览器30次 具体执行步骤 操作步骤 操作描述 数据 期望结果 实际结果 测试状态(P/F) 1 第1次打开浏览器 无 正常加载浏览器主界面 加载成功 P 2 第2次打开浏览器 无 正常加载浏览器主界面 加载成功 P 3 第3次打开浏览器 无 正常加载浏览器主界面 加载成功 P 4 第4次打开浏览器 无 正常加载浏览器主界面 加载失败 F …… ………… …… …… 30 第30次打开浏览器 无 正常加载浏览器主界面 加载成功 P 测试人员开发人员负责人 项目 UC浏览器 软件版本 V1.0 功能模块 测试账户信息界面的加载 编制人 冯小冬 用例编号 UC_FUN_05 编制时间 2012.8.16 相关用例 账户信息界面的加载测试 功能特性 浏览器加载账户信息界面 测试目的 测试浏览器是否正常加载账户信息界面 预设条件 进入浏览器主界面 特殊规程说明 无 参考信息 账户信息界面是否加载成功 测试数据 无 具体执行步骤 操作步骤 操作描述 数据 期望结果 实际结果 测试状态(P/F) 1 打开浏览器,加载主界面,触控账户按钮,观察账户信息界面是否加载成功 无 账户信息界面成功加载 导航栏加载成功 P 2 打开浏览器,加载主界面,触控账户按钮,观察账户信息界面是否加载成功 无 账户信息界面成功加载 导航栏成功加载 P 3 打开浏览器,加载主界面,触控账户按钮,观察账户信息界面是否加载成功 无 账户信息界面成功加载 导航栏成功加载 P 4 打开浏览器,加载主界面,触控账户按钮,观察账户信息界面是否加载成功 无 账户信息界面成功加载 导航栏成功加载 P 5 打开浏览器,加载主界面,触控账户按钮,观察账户信息界面是否加载成功 无 账户信息界面成功加载 导航栏加载成功 P 测试人员开发人员负责人 项目 UC浏览器 软件版本 V1.0 功能模块 测试收藏夹栏的界面 编制人 冯小冬 用例编号 UC_FUN_06 编制时间 2012.8.16 相关用例 收藏夹栏的界面测试 功能特性 浏览器加载收藏夹栏的界面 测试目的 测试浏览器是否正常加载收藏夹栏的界面 预设条件 进入浏览器主界面 特殊规程说明 无 参考信息 收藏夹栏的界面是否加载成功 测试数据 无 具体执行步骤 操作步骤 操作描述 数据 期望结果 实际结果 测试状态(P/F) 1 打开浏览器,加载主界面,触控收藏夹按钮,观察收藏夹栏的界面是否加载成功 无 收藏夹栏的界面成功加载 收藏夹栏的界面加载成功 P 2 打开浏览器,加载主界面,触控收藏夹按钮,观察收藏夹栏的界面是否加载成功 无 收藏夹栏的界面成功加载 收藏夹栏的界面成功加载 P 3 打开浏览器,加载主界面,触控收藏夹按钮,观察收藏夹栏的界面是否加载成功 无 收藏夹栏的界面成功加载 收藏夹栏的界面成功加载 P 4 打开浏览器,加载主界面,触控收藏夹按钮,观察收藏夹栏的界面是否加载成功 无 收藏夹栏的界面成功加载 收藏夹栏的界面成功加载 P 5 打开浏览器,加载主界面,触控收藏夹按钮,观察收藏夹栏的界面是否加载成功 无 收藏夹栏的界面成功加载 收藏夹栏的界面加载失败 F 测试人员开发人员负责人 项目 UC浏览器 软件版本 V1.0 功能模块 浏览器语音输入 编制人 冯小冬 用例编号 UC_FUN_07 编制时间 2012.8.16 相关用例 功能特性 利用语音输入要搜索的信息 测试目的 测试浏览器是否能自动准确输入用户语音输入的信息 预设条件 安装语音输入插件 特殊规程说明 无 参考信息 测试数据 不断语音输入30次 具体执行步骤 操作步骤 操作描述 数据 期望结果 实际结果 测试状态(P/F) 1 第1次输入 百度 输入“百度” 输入成功 P 2 第2次输入 新浪 输入“新浪” 输入成功 P 3 第3次输入 谷歌 输入“谷歌” 输入成功 P 4 第4次输入 搜狗 输入“搜狗” 输入失败 F …… ………… …… …… 30 第30次输入 火狐 输入“火狐” 输入失败 F 测试人员开发人员负责人 5.6.2 测试执行 在执行中我们主要采用手工执行的方式,对某些特殊的异常和错误要进 行多次执行,以确保不是偶然原因造成的。 测试用例执行情况如下表所示: 功能模块 执行结果 用例通过率 问题描述 网页加载 OK 97% 无 网络连接 OK 98% 无 启动 OK 97% 无 输入 fall 95% 语音输入功能的辨别不够精准。 收藏夹、历史记录 OK 97% 无 根据表中的数据统计结果及规定的测试通过/不通过标准判定本次测试通过。 由于其测试过程较长,需要对各子单元程序.各模块及它们之间的接口分 别进行测试进度.一般测试过程都伴随其概要设计.详细设计过程一起进行, 进度为每个编码阶段都进行相应测试,保证风险控制,及时调整编码,或者保证关联编码的正确性,不影响其他模块的正常运行。 最后进行集中的系统集成测试,是的确定各个模块的正常运行,浏览器的稳定工作。 5.7 测试总结 通过对全部测试用例的设计、执行情况进行统计分析,我们可以得出如下结论: UC浏览器中除了语音识别的识别率不够外,并无其他问题,其中有个规律,除了儿化词以外,含常用词较多的语段,错误率较低;含罕见词较多和带文言色彩的,错误率较高。 UCam照相机的视频拍摄最高只支持352*288的分辨率,手机原本支持的高分辨率拍摄没有效果,拍摄时无法调整对比度,亮度。摄像模式自动默认800万像素,选择其他模式无效。 6.结论 从目前安卓手机应用软件的发展现状和发展趋势可以看到,安卓手机软件测试的需求前景非常广阔,它将成为未来手机行业发展的重要部分,并在手机软件工程的发展过程中发挥重要的作用。 V模型是一种较适合于安卓手机软件测试的模型,它非常明确地标明了 测试过程中存在的不同级别,并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。它针对手机软件开发过程,主要突出了测试与开发过程的平等性和并行性,根据V 模型的要求,一旦有文档提供,就要及时确定测试条件,以及编写测试用例,这些工作对测试的各级别都有意义。如当需求被提交后 ,就需要确定高级别的测试用例来测试这些需求。当概要设计编写完成后 ,就需要确定测试条件来查找该阶段的需求文档,对照需求列表编写测试计划的设计缺陷,由测试人员和用户进行软件的确认测试和验收测试,追溯软件需求说明书进行测试,以确定软件的实现是否满足用户需求或合同的要求。这意味着测试不仅仅是评定软件的质量,测试还可以尽可能早地找出缺陷所在 ,从而帮助改进项目内部的质量。相对的,V模型也存在一定的局限性,它仅仅把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段。容易使人理解为测试是软件开发的最后一个阶段,主要是针对程序进行测试寻找错误,而需求分析阶段隐藏的问题一直到后期的验收测试才被发现。本文所实现的测试过程是需要测试人员手动进行的,接下来的重点应放在自动化测试上,并且要加入适应性测试,在不同版本的系统上测试,这些自动化测试可采用monkeyrunner、robotium、Testin等自动化测试工具以及中国移动的开发者社区等提供手机终端进行安卓手机软件的自动化测试。参考文献 [1] 王辰越. 狠咬苹果一口的“绿巨人”安卓[J].中国经济周刊, China Economic Weekly, 编辑部邮箱 2011年 41期 [2] 吴艳,张慧.基于模型的软件测试方法研究[J].计算机系统应用,computer systems & applications,编辑部邮箱 2008年08期 [3] 朱少民 左智.《软件过程管理》[M].北京:清华大学出版社,2007. [4] 秦玉.