手机软件测试最佳实践(三)

第七章  手机一致性测试

本章要点:

● GCF认证测试;

● 协议一致性测试;

● Symbian签名测试;

● 全型号认证测试和中国入网认证测试。

7.1  GCF认证测试

7.1.1  GCF认证测试的基本概念

GCF是Global Certification Forum的缩写,中文译名是全球认证论坛,是一个国际性的组织。它的成员由142个运营商、33个终端制造商、测试机构和测试设备供应商组成。GCF组织协调了手机一致性测试标准,定义了用来保证手机满足网络部署的测试体系,同时所有成员运营商都同意这一测试体系。也就是说,GCF认可就意味所有成员运营商都认可该手机,在将来可以无需额外测试。同时GCF还认可测试用例和测试系统。GCF的目的是通过独立的认证过程来确保终端的全球互操作,即:“Tested Once, Accepted by All”。

GCF在3G的一致性测试中扮演了非常重要的角色。这是因为3GPP只是制定了相关测试规范和组织编写了统一的测试用例(TC),但并没有就何时开展一致性测试、如何开展一致性测试、测试达标标准是什么等进行规定。而GCF承担了这部分工作

GCF设定了一系列一致性测试的里程碑,制定了测试用例、策划平台认证的流程以及终端产品认证注册的流程。但是GCF并不从事任何测试,而是交给第三方测试机构(如RFI)进行测试。GCF GSM/UTRA工作组、应用开发工作组、场测工作组及Ad-Hoc工作组这些工作组每三个月举行一次会议,对测试结果进行认可,测试用例和测试系统将同时被认可。当业内的测试用例和测试系统达到GCF的各个里程碑要求时,业内对于终端设备的一致性认证就真正开始了。GCF认可就意味着所有GCF运营商成员都认可了。

7.1.2  GCF对WCDMA终端认证测试的要求

要进行WCDMA终端认证测试,终端厂商首先必须明确该终端支持什么功能和特性,以形成选项表,然后在3GPP核心标准的基础上,选项表决定应该选择怎样的GCF CC测试标准、目的和方法,并形成测试需求表。与此同时,根据选项表和3GPP测试标准,实验室会制定一致性评估表,以反映该终端和相应测试标准之间的一致性程度;当然,评估的重点是相应的测试方法和测试目的。GCE认证测试技术文档的结构如图7.1所示。

 

 

图7.1  GCF认证测试技术文档结构

  根据选项表和测试需求表的内容和要求,GCF中终端认证测试主要包括以下几个方面:

● 一致性测试用于验证终端的行为是否符合3GPP所定义的核心标准和测试标准,以保证各个终端的相互兼容和一致;

● 外场测试是WCDMA终端的GCF认证不可缺少的重要组成部分,其实施是确保终端设备能够在实际网络环境下安全使用,可从最终用户角度来验证网络间互通及新的业务应用的性能;

在应用测试方面,目前GCF认证中涵盖了MMS、可视电话、IMPS、PoC等方面的所有业务测试,所以是应用一致性测试。

7.1.3  WCDMA终端认证程序

要进行WCDMA终端的GCF认证,终端厂商首先必须是GCF的成员,然后按照规定的程序和提供相应的文档资料给GCF进行审查。

终端厂商先要提供一份自我声明和相应证据,表明厂商是一个法人实体且在WCDMA终端的设计、研发和生产上拥有一套合格的质量管理流程,质量管理程序的证据,如ISO9000证书等。

然后,终端厂商再提供一份声明以自我评估的方式来反映WCDMA终端产品与相关的GCF认证标准的一致性符合状态。可以是自己测试设备所做的测试,也可以是基于相应资质的第三方测试实验室所做的测试。

最后终端厂商应该根据产品的一致性测试状态来自我评估该终端产品是否符合相关的GCF标准,提供相应材料予以证明。此外,作为GCF认证的一部分,终端厂商在认证状态文件中应该提供至少五个网络运营商外场测试的相关报告和资料。如若终端支持彩信业务,那还应执行彩信的一致性测试和互操作性测试,且提供对应的测试报告。

7.1.4  GCF对测试用例和测试系统的认证过程

GCF对测试用例和测系统的认证过程如图7.2所示。

从图7.2可以看到,对于测试系统厂商,首先测试项目必须通过3GPP终端测试组TSG-T1认可,在这一步的认可认证中,每个用例必须有一部手机支持,然后通过第三方测试机构确认。在这一步中,每个用例必须至少获得两部不同厂家手机的支持。最后,第三方测试机构将测试结果提交给GCF,GCF最终完成对测试用例和测试系统的认证。所以,认证过程是测试设备提供商和手机厂家共同合作的结果。

 

图7.2  认证过程图

  只有经过认可认证的测试项目才能广泛用于各种不同终端的一致性测试,使得各个终端能够互相兼容及保证互操作性。一般来说,每个测试项目的认证要经过两个重要阶段,两个阶段的工作都在经过授权的第三方实验室内进行,在一致性测试项目开发的开始阶段,看是否满足开发和设计的测试项目的正确条件;在项目开发最后阶段,同样由第三方实验室进行验证和确认是否已经设计出正确的测试项目。GCF测试项目的认可认证流程如图7.3所示。

 

图7.3  GCF测试项目认可认证流程

7.1.5  GCF测试项目实施原则和作用

GCF将所有的测试用例按优先级进行划分,分7个批次,即Batch1-Batch7,其中批次1优先级最高,批次7优先级最低,优先级高的必须先进行认证。一旦前4个最高优先级测试用例有80%通过认可,GCF即开始对终端进行认证。测试设备厂家同时必须按照优先级的高低将测试用例提供给业界使用。GCF批次及对应测试阶段如表7.1所示。

 

表7.1  GCF批次及对应测试阶段

  从表7.1中可看到,批次1包含协议的测试包1(每个包或测试套件由100个左右测试用例组成),大部分的射频测试用例,USIM/UICC和Audio全部测试用例。批次2包含协议的包2,少部分的射频测试用例。从批次3开始,主要针对协议测试进行认证。

经验总结得知,GCF在一致性测试中的作用主要是:

● 厂商的目的是迅速获得进入市场的新模式;

● 运营商的目的是提供有吸引力和可靠的业务。

市场反应的结果表明,欢迎对手机进行商业一致性认证。GCF为满足市场的目标进行了如下一些工作:

● 定义了每个终端所必须接受的测试,保证了终端的可靠、一致的行为;

● 确保任何接受过GCF认证的终端都通过了这些测试;

● 保证在将来能引入更多更复杂的技术。

7.2  协议一致性测试

7.2.1  协议一致性测试的基本概念

协议测试通常是在软件测试基础上产生的一种黑盒测试,主要是根据协议标准,通过检测协议实现外部行为,对其进行评价。一般可分为以下四种测试:

● 协议一致性测试,检测实现的系统与标准协议符合的程度;

● 协议性能测试,检测协议实体或系统的性能指标;

● 协议互操作性测试,检测同一协议在不同实现版本之间的互通、互连和互操作性能力;

● 协议健壮性测试,检测协议实体或系统在各种恶劣环境下运行的能力。

ETSI的ISO/IEC9646定义的协议一致性测试的方法如图7.4所示:

图7.4  协议一致性测试的方法

  一致性测试是用来确认设备是否符合对其功能要求方面的规范或协议的测试过程,一致性测试标准包括3个部分:抽象测试集(ATS)、协议实现一致性说明(PICS)和协议实施附加信息(PIXIT)。可执行测试集(ETS)是在以上3部分的基础上生成的。

协议一致性测试的主要步骤如下:

(1)根据协议规范,研究协议规范每个特性,并为每个特性编写测试目的;

(2)把每个测试目的转化为抽象测试用例。覆盖协议规范所有特性的多个测试用例集合则构成了该协议规范的抽象测试集;

(3)生成PICS/PIXIT。PICS用来说明实施的要求、能力及可选项实施的情况,PIXIT用来提供测试时必须标明的协议参数;

(4)确定测试方法,针对不同的IUT,即测试实现,用户应该采用不同的测试方法;

(5)根据PICS/PIXIT和测试目的编写测试用例,生成ETS;

(6)使用生成的ETS测试IUT;

(7)根据测试结果生成PTCR。

协议一致性测试的工作包括两部分:一部分是ETSI的工作,另一部分是非ETSI的工作。

ETSI的工作包括以下三项:

● 根据基本协议提供以自然语言描述的测试套件结构和测试目的;

● 根据测试套件结构和测试目的生成以TTCN3语言描述的抽象测试套;

● 提供PICS和PIXIT的格式。

 

非ETSI的工作有以下三项:

● 测试工具开发商将抽象测试套件实现为可执行的测试套件的工作;

● 由被测提供商和测试实验室填写PICS和PIXIT;

● 测试实验室对测试环境的配置、对IUT进行测试、分析测试结果并最终生成协议一致性测试报告。

协议一致性测试和射频一致性测试是其中最复杂也最重要的部分,协议一致性测试属于软件测试的范畴,在一定的网络环境下,对被测协议实现(IUT)进行黑盒测试,通过比较IUT的实际输出与预期输出的异同,判定IUT在多大程度上与协议描述相一致,从而确立通过一致性测试的IUT在互连时成功率的高低。实际上,2G系统同样需要进行一致性测试,3G系统则因相对于2G系统来说更加复杂,而使得一致性测试显得更加重要。

7.2.2  协议一致性测试的几种形式及举例

协议一致性测试用于验证测试手机和网络之间的信令协议是否符合3GPP发布的TS34.123规范,该规范测试非常详尽,主要包括以下几个方面的空闲模式操作:MAC层信令测试、PDCP协议测试、RRC测试、MM流程测试、CS域呼叫控制测试、会话管理流程测试、PS域移动性管理流程测试、补充业务及短消息业务测试等。3GPPTS34.123定义了约700个TTCN测试用例,对RLC层、MAC层和RRC层分别进行测试。

CC是非接入层CM子层的一个实体,主要完成CS域基本的呼叫管理,是整个CM子层的核心,终端组成结构如图7.5所示。本例结合CC实体的主叫过程,提出一种一致性协议测试的方法。对系统高层协议的开发测试而言,目的是验证开发能否满足标准,是否能与其他基于同一个协议标准的产品实现互通,以尽可能减少产品在现场或用户实际运行时出错的风险。

CC测试环境如图7.6所示,模块SPVCALL和MM共同组成了CC的测试环境,CC即是待测试的IUT,CC的上层是SPVCALL模块,它负责将MMI应用层发来的消息转发到CC实体;CC的下层是MM子层,它为CC提供MM连接服务。从中选取可控制的观察点有两个:其一在SPVCALL与CC的接口处;其二在CC与MM的接口处。

图7.5  终端组成结构图

图7.6  CC测试环境

CC实体的主要功能是对用户之间的呼叫进行控制,包括呼叫建立、呼叫释放及呼叫重建等。根据协议描述,CC发起的主叫过程描述如图7.7所示。

图7.7  主叫过程描述图

  如图7.7所示,由CC发起的主叫过程的操作过程如下:

(1)终端发起呼叫,MMI发起一个建立请求送到SPVCALL模块,SPVCALL将向CC发送“CAPI_CALL_SETUP_REQ”信号;

(2)CC收到此信号后,将发送“MMCC_EST_REQ”信号到MM子层,要求其创建一个MM连接;同时,开启定时器T303,状态即跃迁到“Connect Pending”;

(3)MM子层向CC发送“MMCC_EST_CNF”信号,表示MM连接创建成功,CC通过原语“MMCC_DATA_REQ”向MM子层发送“SETUP”消息,状态跳到“Call Initiate”;

(4)MM子层通过接入层将“SETUP”消息发送给网络,网络收到此消息后,向终端发送“CALL PROCEEDING”消息,CC一旦收到该消息,就关闭定时器T303,开启定时器T310,并向SPVCALL报告收到“CALL PROCEEDING”消息,状态亦跃迁到“Call Proceeding”;

(5)网络向终端发送“ALERTING”振铃消息,CC收到该消息时,停止定时器T310,向SPVCALL报告收到了“ALERTING”,状态并跃迁到“Call Delivered”;

(6)当终端分配了专用资源后,MM层将通过“MMCC_SYNC_IND”原语通知CC,CC将通知SPVCALL专用资源已经分配;

(7)网络向终端发送“CONNNECT”消息,CC收到该消息后,将向网络发送“CONNECT ACKNOWLEDGE”,并通知SPVCALL模块,CC收到了“CONNECT”消息,状态即进入“Call Active”。

在协议软件开发流程中,SDL被广泛用来描述通信系统行为。它可把SDL的描述和设计直接生成标准的C代码,用户也可直接在SDL描述和设计中嵌入C代码。经SDL描述产生的C代码,可在评估板或目标板上运行。与SDL相对应的MSC是ITU-T规范中用来表示信号序列的语言,用MSC图可以直观地表现出信号流向:信号从什么进程发送到什么进程,以及信号带有哪些参数值,都能直观地表示在SDL的MSC图中,这为了解和分析信号在各个模块间的传递带来了很大方便。特别需要指出的是,在对高层软件进行测试时,采用黑盒测试方法进行测试,通过TTCN与SDL的协议仿真,可生成MSC,通过观察IUT内部、IUT与测试系统间消息序列和数据流,达到查找错误的目的。

为了验证终端和网络收发消息的内容是否正确,要确认对终端收到消息后做出的响应是否与规范相符。以CC向网络发送一条“SETUP”消息为例,如表7.2(参数列表)所示,该消息的构造参考3GPPTS24.008,内容包含有PD/TI、消息类型、承载能力、被叫用户子地址、被叫用户号码、SI及其他跟普通呼叫相关的参数。

表7.2  参数列表

  用类似方法,构造出相关消息后,便可以通过和SDL进行协议仿真测试,得出的MSC图如图7.8所示。

检查MSC图,当手机处于“状态”时,CC一旦收到“消息”后,就停止定时器T310,并跃迁到“状态”。实际结果与协议要求所预期的符合一致。

然而,实际测试中常遇到环境搭建的困难和具体实施办法。若硬件平台不成熟,则终端研发企业往往愿意花钱开发独立测试系统,即无线模块和协议单元、测试软件和测试集。

另一种方式,国际通行的协议一致性测试方式,即通过真实基站配合,令待测终端在实际基站信号下进行一致性测试。这样的测试中有许多项目需要基站按照预定方式进行有关操作或对终端请求给予回复,这样的判定结果更直观,有利于达到预期目的。关键在于要对现有基站进行扩展或二次开发,使得测试控制程序能够按终端一致性规范定义的无线参数、信令流程、消息字段等来设置Node B进行控制,以满足测试条件。

 

还有一种方式是采用安立的系统仿真器,它可进一步理解采用系统仿真器进行一致性测试的几个实例,MD8470A可以模拟TD-SCDMA网络行为,如图7.9 TD-SCDMA系统仿真器所示,它可以帮助芯片或手机研发单位做好应用测试和协议测试。

丰富的应用功能是3G手机的最大特点,在实验室环境下可能没有TD-SCDMA网络,在这样的环境下要进行如MMS、可视电话应用的开发,就要采用系统仿真。在MD8470A提供的仿真环境下,可以支持语音、SMS、数据包通信、彩信、可视电话、补充业务等各项业务测试,用户就可以专注于开发上层的应用软件,从而加快开发的进程。

图7.8  MSC图

图7.9  TD-SCDMA系统仿真器

MD8470A还可以与Setcom,Radvison等公司的产品一起构成符合3GPP标准的应用一致性测试系统,对手机的彩信、PoC、可视电话等功能进行标准测试。

MD8470A另一个合适的应用是TD-SCDMA的协议测试,它提供了API对仪表进行控制。研发工程师可以用C语言编写协议测试的脚本,自由定义物理层、MAC层、RLC层的参数,在Layer3层任意编写协议流程。基站一侧发送的消息完全由用户来定义,而这一点在实际的网络中是很难做到的。发射和接收任意消息的情况如图7.10所示,一个BTS发起release消息,TD-SCDMA手机回复release complete消息。在测试运行过程中,可以随时监视Uu接口的信令流程,从而可以很方便地进行查错和调试。

图7.10  发射和接收任意消息

  MD8470A还可以支持多种移动通信系统的仿真,为多模手机提供了非常强大的测试环境。例如,可以为TD-SCDMA/GSM的双模手机开发提供最好的协议应用测试方案。除了TD-SCDMA外,MD8470A还支持WCDMA/HSPA/GSM/GPRS/EDGE/C2K等,并且提供了图形化界面方便用户的操作。在这个环境中,用户就像在实际的网络中一样,手机可以进行各种功能的测试。

 

文章分类 未分类

手机软件测试最佳实践(二)

5.1  测试环境搭建

5.1.1  环境搭建重要性和要素

众所周知,没有测试环境根本无法执行测试。对搭建测试环境的考虑应该跟测试活动本身一起被计划。假如你现在想在真实网络环境下验证集成后的模块功能,恰好你所处环境没有网络覆盖,显然测试将无法执行。

然而终端测试环境很多,通常需要准备硬件可靠性测试、环境适应性测试、一致性测试和外场测试等各类环境。为了更好地回答“怎么搭建测试环境?”、“为什么要搭建测试环境?”等问题,本章着重讨论针对手机软件测试的环境。

目前,终端厂商越来越注重人机界面、功能齐全的应用、智能的操作系统,故测试工程师要应对的测试要求也越来越多。并且测试的好坏直接取决于应用业务测试环境的搭建,所以测试质量不仅取决于在建好的测试环境下对功能点测试覆盖情况,还取决于在建好的测试环境下对终端或业务互连互通要求的测试覆盖情况。

在3G牌照发放初期,网络覆盖较差的情况下,多样化的双模终端推广便是当时的工作重点。所以,关键的测试是双模机切换控制、业务兼容、机卡兼容、终端耗电、漫游等。

在3G全球商用推广阶段,3G终端不仅要解决芯片方案、操作系统、电源技术的部分,还要解决个性化的业务应用、定制化的软件功能、丰富的3G业务的部分。因此,只满足手机软件功能的测试是不够的,手机软件的性能测试、平台或应用业务的认证测试也势在必行。

在互联网全面普及的今天,用户对终端的外观感受、终端的使用质量、人机交互的便利、音视频高保真、网络数据的带宽、视频的品质、互联网大量免费的内容等需求越来越多,故大量业务仿真模拟测试,集成应用的测试都将越来越难。

为了更好地满足以上手机应用软件的业务规范,满足终端的测试规范,满足运营商定制手机的要求,在进行手机的人机界面设计和应用软件测试环境搭建时应该考虑如下的问题。

● 配置。准备要测试的手机,将其选择默认配置或置于正确的起始状态,否则测试结果会受到不良变量的影响。

● 运行。向手机输入数据,向网络、终端本身或终端上SIM卡发命令,以某种方式与被测手机进行交互。否则,测试工程师能够做的只是静态的评审,而不是动态的测试。

● 观察。收集有关手机的响应信息、输出数据、系统整体状态、人机界面输出与其他实体的交互等方面的信息。如果测试工程师不能很好地观察所有事物,那就看不到问题所在。

● 评估。参考对照业务规范,运用逻辑推理或业务流程分析测试所观察到的数据中存在的问题,否则就无法根据对数据的分析汇总出报告,进行评估。

模拟环境要能全面地模拟出业务系统所能实现的功能,以贴近真实用户使用环境。

5.1.2  实验室配置和规划

实验室配置依据终端平台不同、研发过程不同、测试类型不同,将做出不同的规划和调整。在2G时代,测试的重点是在物理层和协议层,因为2G主要提供的是语音业务,对物理层和协议层的测试可以保证语音业务的服务质量。

而3G则完全不同,大量的新应用正在不断地出现在3G移动设备上,其中几乎所有的应用都是以数据为中心的应用。最终用户感受到的数据服务性能将决定设备的优劣。因此,在3G时代,测试的重点正在转移。虽然评估手机的最低性能指标和协议一致性测试始终十分重要,但越来越多的测试将重点放在验证终端支持的应用和其他高级特性上。某些应用运行时的性能往往直接影响到最终用户的体验,因此为了实现新业务和应用的成功部署,在部署测试工具前必须帮助制造商和运营商在实验室中确定端到端应用存在的问题,测试环境必须在手机销售到最终用户手中之前对其进行包括集成、设计验证、互通性和应用/业务测试在内的全面评估。

手机一致性测试用例所要求的基本配置,如下所示:

● 射频指标测试:Anritsu,ME7873A;

● 协议一致性测试:R&S,CRTU W;

● 机卡接口测试:Orga,Test System IT3 platform;

● 音频性能测试:Sonora,Acoustic Measurement System;

● 自动测试平台:TestQuest,CountDown;

● 性能测试平台:Spirentcom,APEX C2K。

目前,也可用模拟的网络进行终端一致性测试。真实网络的测试主要是基于现网的业务实现进行相应的测试,在现有的网络设备、网络配置以及网络所支持的业务功能情况下进行的测试;而对模拟网络来讲,进行目前网络所不支持的一些性能的测试,是为了保障将来在网络设备升级或者增加新业务或者网络结构演进的情况下,仍能保证终端能够正常工作。

对于智能手机的测试,搭建测试环境时往往还需要投入大量的周边设备和资金。在构建测试环境过程中,需要考虑具体的测试过程,早期的单元测试、集成测试过程,需求相对独立,对测试工具和测试工程师知识技能方面要求更高,如测试脚本编写、维护及自动化测试的构建。后期的系统测试、可接受性测试过程,应用业务繁多又复杂,绝大多数情况下可以借助现网业务的环境。但考虑到不同种类的测试需求,测试工程师仍需要准备设备的一次性投入,以确保执行测试的有效性和充分性。模块及对应测试环境最少的投入如表5.1所示。

测试类型 功能模块 需求软硬件环境
功能测试 公共模块 存储卡及读卡器、兼容的SIM/USIM卡、蓝牙设备、USB设备、红外、GPS、下载Java MIDlet、Provisioning、Push、E-mail
通话模块 兼容的SIM卡及补充业务开通、传真及数据呼叫业务捆绑、日志及计费、STK快速拨号、固定拨号
多媒体应用模块 终端模拟器、图像浏览、播放器、录音、兼容的多媒体测试数据
性能测试
互操作性测试
智能短消息 短消息中心
即时消息 即时通信服务器、网络名片簿、网关
呈现业务 呈现业务服务器、用户数据库
语音通话 网络
彩信 彩信中心、多媒体文件资源
认证测试 J2ME 终端、网络、测试服务器
蓝牙 终端、蓝牙设备、附件软件
USB 终端、USB设备、附件软件
易用性测试 UI布局和风格 用户体验场所、耳麦、录像记录、操作对比记录表

 

5.2  语音类业务

语音类业务是运营商为用户提供的电话业务和各种语音类增值业务的总称。

5.2.1  语音类业务简介

电话业务是GSM移动通信网提供的最重要的业务,经过GSM网和PSTN网,能为数字移动用户之间和数字蜂窝移动电话网用户与固定网用户之间,提供实时双工通信,包括各种特殊服务呼叫、查询业务和申告业务,以及提供人工、自动无线寻呼业务。

IVR业务是其中主要的无线语音增值服务。和目前大家熟悉的固定电话声讯服务类似,用户只需用电话即可进入服务中心,根据操作提示收听语音服务,系统会根据用户输入内容播放有关的声讯信息。手机用户拨打指定服务号码,能获取所需信息或参与互动式服务,例如聊天室或交友信息等。

个性化回铃音业务,又名彩铃,是语音类增值业务的一种,也是一项定制该业务的用户作为被叫用户时生效的业务。申请业务的用户可以通过多种方式设定或管理回送给呼叫自己的用户的回铃音。

PTT业务又称一键通,实现了Walkie-Talkie功能的半双工集群话音业务,PoC是基于蜂窝移动通信网的PTT业务。呼叫方无须拨号,按下PTT键进入呼叫状态,立刻发起对所定义的个人或群组进行呼叫,接收方弹起PTT键后进入接收状态,来话无须振铃即可自动播放。同一时刻只允许一个人处于呼叫状态,系统通过判断各PTT用户按键先后顺序及预定义的优先级来决定呼叫权的分配。

5.2.2  语音类业务功能和典型业务流程

语音类业务功能及其典型业务流程主要有以下三类。

1.IVR业务

IVR业务大致分为基本业务和扩展业务两种,基本业务主要包括点对点语音短信业务、超级寻呼业务及免打扰业务等;扩展业务可包括歌曲点播、信息定制、移动聊天、语音广告、语音游戏、移动彩票及公共信息查询等。以典型的语音短信为例,主要功能包括语音短信发送、语音短信获取及语音短信管理(重放、回放、存储、回复、转发、删除等)。

2.个性化回铃音业务

个性化回铃音业务的功能是在被叫用户空闲状态下,系统将播放用户定制的回铃;在被叫用户忙的情况下,终端根据MSC的指示播放相应回铃;在被叫网络忙或用户不可及等情况,终端根据MSC的指示播放相应回铃;如遇无主叫号码或号码不正确等情况,终端根据MSC的指示播放相应回铃。

在呼叫保持、呼叫等待和多方通话的情况下,终端根据MSC的指示播放相应回铃。例如,用户A与用户B正在通话中,用户C呼叫用户B,则用户C是否能听到回铃取决于用户B端回送给业务平台的ACM消息中标识的用户B的状态,如果状态为空闲,业务平台将建立与主叫的通信,可以播放回铃;否则透明传输ACM消息,由用户C端发送对应参数来控制终端回铃。

3.PoC业务

PoC业务的功能包括一对一即时通话、群组通话和回呼请求。一对一即时通话是PoC业务的基本功能,两个用户之间可以进行一对一呼叫,但在呼叫的某一时刻,只能有一方发话。PoC业务也允许用户和其他多个用户建立语音通信。但在同一时刻,处于一个群组中的用户只能一个人处于发话状态,其他人处于接收状态。用户可以通过如下三种方式建立群组会话:

● 用户创建完预设群组后,直接选择该群组,邀请预设群组内的成员开始会话;

● 用户在发起群组呼叫时,临时选择并邀请多个用户开始会话;

● 用户无须邀请其他用户,主动加入聊天室后,就可以直接进行会话。

主叫方还可以给被叫用户发送回呼请求,要求被叫方进行回呼建立一对一会话的过程。被叫用户可以识别回呼请求及呼叫用户标志,并可以自由选择回呼或忽略该请求。

典型业务流程主要包括PoC会话建立流程、离开PoC会话流程及增加用户到当前PoC会话流程。

5.2.3  PoC业务对终端的测试需求

PoC业务是基于IP的数据分组业务。终端功能需求如下:

● 终端需支持AMR语音编码;

● 支持SIP、RTP/RTCP和SDP协议;

● 终端需PoC客户端软件,支持回话控制和相关用户界面;

● 定制PoC终端,独立的PoC物理按键和扬声器设计,在不同的核心网支持下,具有不同PDP连接能力,对信令和语音流数据分别使用不同优先级的PDP连接。

终端参数配置要求支持以下参数:

● PoC Server地址;

● PS域设置-APN,用户及密码;

● IMS域名;

● 支持USIM卡或ISIM卡中Private URI;

● 用户Public URI;

● 预建立会话支持标志,用来通知PoC Server是否支持预建立的Session功能;

● 群组多用户回话支持标志,用来通知PoC Server是否支持同时发生的Sessions功能

终端能力协商可以保持与网络侧版本及相关参数一致。

5.2.4  PoC业务应用的测试实例

从PoC业务特点看,PoC用户应有以下会话最小能力集合:

● 创建和管理由PoC业务实体使用的PoC用户定义的预设PoC群组列表;

● 创建和管理PoC用户定义的聊天群组;

● 管理PoC会话处理方法包括Presence信息,基于邀请用户的标志自动接收、人工接收及拒绝接收;

● 创建和管理PoC用户自己的联系人列表;

● 运营商可以中止某一个特定PoC通信;

运营商可以配置一个会话最大时长和某用户一次发话的最大时长。

5.3  消息类业务

5.3.1  消息类业务简介

短消息服务(SMS)作为GSM Phase1的业务标准,目前已经被集成到CDMA、TDMA和PHS等众多网络标准中,使得SMS成为最普及的移动无线数据业务,即通过手机发送和接收有限长度文本信息的服务。它可以是字符串、数字及字母的组合,包含160个英文字母(7bit编码)或70个非拉丁字母(16bit编码),如中文汉字或阿拉伯字母等Unicode编码;按其实现方式,可分为点到点短消息业务和小区广播短消息业务。

EMS是SMS增强版本,实现原理类似。它使用信令信道,通过短消息中心存储和转发消息,能够将简单音调、图片、声音、动画、文本集成到一起,在支持EMS的手机上整体显示出来。例如,当消息中出现感叹号时,可演奏相关的音调,或把简单黑白图片、文本及声音效果同时显示出来。EMS支持以下各种标准格式的多媒体:

(1)格式化文本,如左右对齐、居中、字体、字形、加粗、加黑、斜体、下画线等;

(2)16´16像素、32´32像素、可变尺寸黑白图片,标准建议图片最大尺寸为94´94像素;

(3)EMS预定义了10种声音,标准格式是iMelody,大小不得超过128字节,以基于文本的方式表示音调;

(4)支持16´16像素、8´8像素两种尺寸动画图片,预定义了一些表情动画,用户也可以自己定义动画。

多媒体信息业务是按照TS23.140和WAP-206/209中有关多媒体信息的标准开发的全新业务。在GPRS、CDMA2000 1X等网络的数据传输能力的支持下,以WAP无线应用协议为载体传送视频片段、图片、声音和文字,同时支持与语音、浏览、电子邮件等多种业务互通,实现终端到终端、应用到终端、终端到应用的手机多媒体消息服务。

5.3.2  短信业务功能和典型业务流程

短信业务流程可总结为三种情况:点对点是指在普通用户间收发短信;点对SP是指用户与各种服务提供商间进行短信业务;短信存储容量已满或用户不在服务区或关机的情形下存储转发流程。具体功能和典型业务流程说明如下:

● 点对点业务的流程:本网间MO与MT收发流程;异地网MO与本网MT间收发流程;本网MO与异地网MT间收发流程;

● 点对SP业务的流程:本网终端用户访问异地SP;异地SP访问本网终端用户;

● 通知报警业务流程:分终端短信存储空间是否可用和终端是否可及两种情况。即短信存储容量已满或用户不在服务区或关机无法收发短信的流程。

彩信业务流程可总结为四种情况:端到端收发流程;终端到应用及应用到终端流程;点对多点业务流程,在一次彩信发送过程中,接收方可指定多个终端或应用地址;与非彩信终端互通支持,非彩信终端用户接收到彩信消息到达通知后,可采用E-mail、WWW和WAP浏览等方式访问多媒体消息。

● 根据用户接收彩信情况,发送端到接收端有5类流程:

Ø 接收方终端延时成功下载彩信;

Ø 接收方终端立刻成功下载彩信;

Ø 接收方终端延时前转彩信;

Ø 接收方终端立刻前转彩信;

Ø 接收方终端拒绝接收彩信。

● 彩信终端与外部邮件服务器之间的收发流程。

● 彩信终端与网站应用之间的处理流程。

5.3.3  短信业务对终端的测试需求

随着短信业务的逐步开展,业务种类和业务形式的逐渐丰富,对手机终端的需求也越来越多,对终端的要求主要有以下几个方面。

● 终端能支持短信中心号码的设置,支持从USIM卡得到短信中心号码。

● 终端协议必须支持TS 23.040,TS 24.011和TS 23.038。

● 终端必须支持通过电路域和分组域两种方式来承载短信业务。

● 如果需要以短信的格式或以短信串接的格式,即那些支持下载的铃声和图片,甚至EMS对终端又有更多的要求:

Ø 需要增加对文本格式的修饰功能,如字体、字符及对齐方式等;

Ø 图片需要支持小图片,大图片和可变尺寸图片,支持扩展黑白图片和大图片,可以通过压缩方式传输;

Ø 如上节内容所提,支持10种不同的声音格式,可以在短信中以压缩格式发送。

● 对于WAP2.0所支持的一些新业务,往往需要借助短信来配合,如OTA Provisioning和WAP Push,终端支持通过短信承载来发送到最终用户。

从用户使用角度考虑,终端需要支持超长短信和群发短信功能。

文章分类 未分类

手机软件测试最佳实践(一)

第2章 手机软件测试用例设计

本章要点:

● 用例设计考虑因素;

● 用例设计基本原则;

● 用例设计常用方法。

2.1  用例设计考虑因素

从理论上讲,手机软件规模越大,模块间的关系越复杂,组合的情况越多,测试用例数目占的比例也就越大,因而总是很难设计出“足够”的测试用例。

虽然理论上缺陷空间(测试空间上所有可能发生的缺陷构成的集合就是缺陷空间)可以接近无限大,但实际情况中存在的缺陷只是缺陷空间的一个很小的子集。测试中最重要的是要找到已经存在的缺陷,但在没有进行测试前,手机软件中存在多少缺陷却是不知道的。

从理论上讲,测试是不能穷尽的,就意味着不存在一种方法能将所有的缺陷都所以找出来,找到缺陷的问题注定是一个概率问题,将那些发生概率较大的缺陷找出来就成了测试的主要任务。

测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。测试用例是执行的最小实体。简单地说,测试用例就是设计一个场景,使测试程序在这种场景下运行并且达到程序所设计的执行结果。

设计测试用例首先要考虑以下几个问题:

● 为什么要设计测试用例?

● 谁来写测试用例?这些写测试用例的人的测试技术如何?以及对被测试产品了解有多深入?

● 测试用例写给谁看,多少人将使用测试用例文档?

● 分配给编写测试用例的时间是多长?要安排几个人来写?

● 怎么在测试用例的成本、质量和效率方面达到平衡?

目前的手机市场对于新推出的功能和应用程序有着迫切的需要,使得产品周期非常短;然而只有回答了这些问题,才能确定测试用例的具体写作方法和表现形式。一般而言,手机软件测试项目中分配写测试用例的时间并不长,而且提供的文档也不全面,所以写测试用例要符合测试部门的当前现状和项目的测试特点。

对于测试设计工程师来说,设计测试用例需要考虑以下几个方面:

● 测试用例设计必须考虑有效:容易发现并呈现错误;

● 测试用例设计必须覆盖全面又不冗余:数量上不应有重复的、多余的用例,对软件规格说明书和设计功能点有全面的覆盖,不仅包括功能测试用例,还包括性能测试用例,外场测试、易用性等测试用例;

● 测试用例设计必须明确粒度和测试分类的程度:粒度越细,测试成本就越高,测试周期就越长;分类越多,测试成本相应增加,测试周期就越长;

● 测试用例设计完成后必须经过评审:以帮助进一步补充用例,提高测试覆盖率,提高用例质量。

对于测试执行工程师来说,测试用例的内容应包括以下几个方面:

● 测试用例的测试目标;

● 测试用例的被测功能点描述;

● 测试用例的测试运行环境;

● 测试用例的执行方法(包括测试步骤,输入测试数据或测试脚本);

● 测试期望的结果;

● 执行测试的实际结果;

● 其他辅助说明。

2.2  用例设计基本原则

● 测试用例的代表性:能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的输入数据、操作和环境设置等。

● 测试用例的可执行特点:在测试前提符合的情况下,依照测试步骤,每一个测试用例都能够顺利地使程序运行,同时呈现相应的期望结果。

● 测试结果的可判定性:即测试执行结果的正确性是可判定的,每一个测试用例都应有相应的期望结果。

测试结果的可再现性:即对同样的测试用例,系统的执行结果应当是相同的。

2.3  用例设计常用方法

一个好的测试用例是指可能找到迄今为止尚未发现的错误的测试,由此可见,测试用例设计工作在整个测试过程中占有十分重要的地位,所以我们不能只凭借一些主观或直观的想法来设计测试用例,而应该要以一些比较成熟的测试用例设计方法为指导,再加上设计人员个人的经验积累来设计测试用例。

2.3.1  等价类划分方法

1.等价类划分方法基本概念

如果把所有可能的输入数据分为有效等价类和无效等价类两种,那么可以做出这样的合理假定:如果等价类中的一个输入数据能发现一个缺陷,那么等价类中其他输入数据也能发现同一个缺陷;反之,如果一个输入数据不能发现某个错误,那么等价类中其他输入数据也不能发现这一错误。

有效等价类是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。

与有效等价类恰巧相反,无效等价类是指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。对于具体的问题,无效等价类至少应有一个,也可能有多个。

等价类分析法不但可以针对输入数据,而且可以针对输出数据进行划分。总之,他们发现缺陷的概率是等效的。

2.等价类划分方法设计用例的原则

● 如果输入条件规定了取值范围,或者值的个数,则可以确定一个有效等价类和两个无效等价类;

● 如果输入条件规定了输入值的集合,或者是规定了“必须如何”的条件,这时可以确立一个有效等价类和一个无效等价类;

● 如果输入条件是一个布尔量,则可以确立一个有效等价类和一个无效等价类;

● 如果规定了输入数据的一组值,则程序要对每一个输入值分别进行处理;这时要对每一个规定的输入值确立一个等价类,并且对于这组值之外的所有值也都确立一个等价类;

● 如果规定了输入数据必须遵守的规则,则可以确立一个有效等价类(即遵守规则的数据)和若干无效等价类(从不同角度违反规则的数据);

● 如果已划分的等价类中的各元素在程序中的处理方式不同,则应进一步划分成更小的等价类。

3.利用等价类划分方法选择用例

● 为每一个等价类规定一个唯一的编号;

● 设计一个新的测试用例,使其尽可能多地覆盖尚未覆盖的有效等价类;重复这一步骤,直到所有的无效等价类都被覆盖为止;

● 设计一个新的测试用例,使其仅覆盖一个无效等价类,重复这一步骤,直到所有的无效等价类都被覆盖为止。

【举例1】以短消息编辑用户场景为例。

第一步:为每一个等价类和无效等价类规定一个唯一的编号,如表2.1所示。

表2.1  输入字符有效等价类

有效等价类编号 有效等价类字符长度 有效等价类编号 有效等价类字符长度
1 0 10 数字
2 1 11 字母
3 35 12 汉字
4 69 13 汉字+符号
5 70 14 汉字+数字+字母+符号
6 80 15 字母+符号
7 159 16 字母+数字+符号
8 160 17 71
9 符号 18 161

第二步:尽可能多地覆盖有效等价类,如表2.2所示。

表2.2  有效等价类测试用例

用例编号 字符类型 长     度 覆盖有效等价类编号
1 0 1
2 符号 1 2、9
3 数字(电话号码为11位) 11 1
4 汉字 35 3、12
5 汉字+符号 70 5、13
6 汉字+数字+字母+符号 69 4、14
7 字母 80 6、11
8 字母+符号 159 7、15
9 字母+数字+符号 160 8、16

第三步:所有无效等价类均被覆盖,如表2.3所示。

表2.3  无效等价类测试用例

用例编号 字符类型 长     度 覆盖无效等价类编号
10 汉字 71 17
11 字母 161 18

【举例2】某保险公司承担人寿保险,保费计算方式为投保额 * 保险率,保险率又依点数不同而有别,10点以上费率为0.6%,10点以下费率为0.1%。

年龄:一或两位数字

性别:以英文【Male】、【Female】、【M】、【F】表示

婚姻:【已婚】、【未婚】

扶养人数:空白或一位数字

保险费率:10点以上,10点以下

该例的需求描述、等价类划分和测试用例的情况分别如表2.4、表2.5和表2.6所示。

表2.4  需求描述

参 数 名 参数取值范围 参数取值 点    数
年龄 1~99 1~19 2
20~39 6
40~59 4
60~99 2
性别 Male,Female Male 5
Female 3
婚姻状况 已婚,未婚 已婚 3
未婚 5
扶养人数 1~9 1~2 4
3~6 3
6~9 1

表2.5  等价类划分

参 数 名 有效等价类 无效等价类
年龄 1~19 <1
20~39 >99
40~59  
60~99  
性别 Male 非Male,非Female
Female  
婚姻状况 已婚 非已婚,非未婚
未婚  
扶养人数 1~2 <1
3~6 >9
6~9  

表2.6  测试用例

测试用例 年    龄 性    别 婚姻状况 扶养人数
1 9 MALE 已婚 1
2 28 FEMALE 未婚 4
3 45 MALE 已婚 7
4 65 MALE 未婚 1
5 0 MALE 未婚 1
6 100 MALE 已婚 1
7 45 FEMALE 已婚 1
8 45 MALE 未婚 6
9 34 MALE 已婚 0
10 34 MALE 已婚 10

2.3.2  边界值分析方法

1.边界值分析法基本概念

首先我们读0这个数,小学时我们已经知道大于0的叫正数,形成正数区域;小于0的叫负数,形成负数区域,0也就成了数学上我们大家所熟悉的边界点。然而我们常常去做些测试:用小的数减去大的数,老师告诉我们不够减,让我们记住小的数不能减去大的数。随着数域概念的扩大,发现这里有错误。同样,实际程序逻辑中也有类似的这种差别,钱不够可以向别人借钱;如果数据库内没有数据,仍然去删除一条记录,而这样的删除操作将报错。

长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例,可以查出更多的错误。说明程序在边界值上出现错误概率的可能性大。

2.边界值分析法设计用例的原则

通常边界值分析法是作为对等价类划分法的补充,其测试用例来自等价类边界,每个边界都要作为测试条件。因此,边界值分析不仅考虑输入条件,还要考虑输出产生的测试情况。边界值分析法设计用例的原则如下:

(1)如果输入条件规定了值的范围,则应该取刚刚达到这个范围的边界值,及刚刚超越这个范围边界的值作为测试数据;

(2)如果输入条件规定了值的个数,则用最大个数、最小个数、比最小个数少一的数、比最大个数多一的数作为测试数据;

(3)根据软件规格说明书的每个输出条件,应用上述的原则(1)和原则(2);

(4)如果软件程序规格说明书所给出的输入域或输出域是有序集合,则应该选取集合的第一个元素和最后一个元素作为测试数据;

(5)如果程序中采用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试数据;

(6)分析软件规格说明书,找出其他可能的边界条件。

按照上述方法,可以做到更好地使用边界值对用例进行选择,更容易发现缺陷。在实际测试中可以按照这样的分类思路进行扩展。

3.利用边界值分析法选择用例

【举例】LCD屏幕上有效显示区域为4行,每行8汉字;

LCD显示屏列边界值需要考虑:7个汉字,8个汉字,9个汉字;

LCD显示屏行边界值需要考虑:31个汉字,32个汉字,33个汉字;1行,4行,0行,5行。

通常情况下,软件测试所包含的边界检验有几种类型:数值、字符、位置、重量、大小、速度、方位、尺寸、空间等。以上类型的相应边界值应该在:最大/最小、首位/末位、上/下、最快/最慢、最高/最低、最短/最长、空/满等情况下,如表2.7所示。

  表2.7  常见边界值

边 界 值 测试用例的设计思路
字符 起始-1 个字符/结束+1个字符 假设一个文本输入区域允许输入1个到255个字符,输入1个和255个字符作为有效等价类;输入0个和256个字符作为无效等价类,这几个数值都属于边界条件值
数值 最小值-1/最大值+1 假设某软件的数据输入域要求输入5位的数据值,可以使用10000作为最小值、99999作为最大值;然后使用刚好小于5位和大于5位的数值来作为边界条件
空间 小于空余空间一点/大于满空间一点 例如在用U盘存储数据时,使用比剩余磁盘空间大一点(几KB)的文件作为边界条件

手机软件测试过程中,常需要考虑的边界值如下:

● 短消息在default 7bit alphabet编码时边界为0~160;UCS-2编码时边界为0~70;

● 对16-bit的整数而言32767和-32768是边界;

● 屏幕上光标在最左上、最右下位置;

● 报表的第一行和最后一行;

● 数组元素的第一个和最后一个;

● 循环的第0次、第1次和倒数第2次、最后一次。

等价类划分是一种用例设计的思想,是按照输入项和输出项的情况把要执行的具体测试用例划分成等价类和无效等价类两种,然后执行测试。边界值分析也是设计用例时的指导思想,它是在具体执行测试用例时要用到的一种测试技巧(取边界值)。具体实施用例设计时往往要两者结合考虑,一起使用。现以编辑一个彩信测试用例为例,输入项的划分如表2.8所示。

  表2.8  输入项划分

输 入 项 有效等价类 无效等价类
彩信帧数:0-8 0、1、2、8 9
彩信size:最小-50KB 最小、30KB左右、50KB 60KB
帧内容:

图片:无、BMP、JPEG、WBMP

无、WBMP或JPEG、GIF(图片格式由图形系统处理,对彩信测试无区别,因此只取一种) TIFF

目前是JPG文件

帧内容:

音频:无、WAV、IMEDODY、MIDI、AMR、MP3

无、WAV、IMEDODY、MIDI、AMR、MP3  
帧内容:

视频:无、MPEG

无、MPEG  
帧内容:

文本:无、中文、英文、符号

无、中文+英文+符号  

 

文章分类 未分类

monkey

monkey是android的一个命令行工具;

可以运行在模拟器或者实际设备;

monkey向系统发送伪随机用户事件,实现对应用程序的压力测试,用来测试软件的稳定性、健壮性。

monkey的特征:

1.测试对象仅仅局限于应用程序;

2.测试使用的事件流数据是随机的,不能自定义;

3.monkey包括很多选项,如下四种:

(1)基本配置选项,如设置尝试的事件数量。

(2)运行约束选项,如设置只对单独的一个包进行测试。

(3)事件类型和频率。

(4) 调试选项

 

文章分类 未分类

繁体斗地主主版本数值&场次

(三人)场次 下限 上限 快速开始 台费 炸弹概率
50场 1,000  10,000  1000-5000 10% 30/10/5
100场 5,000  80,000  5000-3w 10% 35/10/5
200场 10,000  300,000  3w-8w 10% 35/10/5
500场 20,000  800,000  8w-20w 12% 30/10/5
1000场 30,000  1,800,000  20w-50w 12% 30/10/5
2000场 90,000  / 50w-100w 12% 30/10/5
5000场 300,000  / 100w- 12% 30/10/5
文章分类 未分类