中国联通LBS大众应用业务测试规范1227.docx
- 文档编号:9830738
- 上传时间:2023-05-21
- 格式:DOCX
- 页数:38
- 大小:133.59KB
中国联通LBS大众应用业务测试规范1227.docx
《中国联通LBS大众应用业务测试规范1227.docx》由会员分享,可在线阅读,更多相关《中国联通LBS大众应用业务测试规范1227.docx(38页珍藏版)》请在冰点文库上搜索。
中国联通LBS大众应用业务测试规范1227
中国联通LBS大众应用
业务测试规范
2004年12月27日
版本1.0
目录
1概述3
1.1文档修改历史3
1.2编写目的3
1.3适用对象3
1.4缩略语4
2测试目的5
3测试用时6
4LBS业务测试报告7
4.1LBS业务测试报告性质7
4.2LBS业务测试报告分类7
4.3LBS业务测试报告要求级别7
5LBS应用测试标准9
5.1LBS应用普遍标准9
5.2BREW定位应用标准12
5.3WAP应用标准13
6与其它测试的关系14
6.1与核心定位系统端到端测试的关系14
6.2与BREWUBT测试的关系14
6.3与WAP技术测试的关系15
6.4与网络接入测试的关系15
7测试环境16
7.1现网测试环境16
7.1.1需要具备的条件16
8测试方法17
8.1人工手动测试17
8.1.1需要具备的条件17
9测试流程18
10LBS应用测试项目20
10.1应用功能描述文档20
10.2应用功能确认测试20
10.3应用性能测试21
10.4地图质量测试21
10.4.1地图精度测试21
附录一:
应用测试表格23
附表一:
23
附表二:
25
fubiaodsan附表三:
26
附表四:
28
附录二:
“返回”系统举例29
附录三:
功能说明文档要求31
目的31
文档内容31
格式要求31
附录四:
计费点后移操作32
BREW方式:
32
WAP方式:
32
附录五:
业务架构图模版34
附录六页面迁移图模板35
1
概述
1.1文档修改历史
表1-1所示为本文档的修改历史。
表11文档修改历史
版本
发布日期
版本描述
作者
母版
2003/11/27
由SnapTrack的RP提供
SnapTrack/RP
0.1
2004/05/26
初版。
CU/yangx
0.2
2004/05/31
第一次修改版本,增加了一些实际的测试要求。
CU/dingj
0.3
2004/06/01
增加了测试所需的表格,详细明确了“返回”的要求
CU/dingj/songhg
0.4
2004/06/02
增加申请表格,明确功能说明文档
CU/dingj
0.5
2004/06/03
增加测试评定标准和业务架构图
CU/dingj/songhg
1.0
2004/12/27
根据位置业务发展情况大规模修改
CU/songhg
1.2编写目的
为了保证基于位置的服务的质量,在进行应用的商用发布前,需要进行综合的业务测试。
本文就业务测试的范围、具体的测试方法和流程进行了详细的描述。
1.3适用对象
本文适用于各个提供位置服务的增值业务开发商。
适用于利用联通定位平台实现大众应用的CP业务测试,包括页面规范性测试、业务功能性测试和用户体验性测试。
页面规范性测试将交给振戎融通去做,不在本测试规范讨论范围之内。
1.4缩略语
BREWBinaryRuntimeEnvironmentforWireless无线二进制运行环境
CDMACodeDivisionMultipleAccess码分多址
CPContentProvider内容提供商
LBSLocationBasedService基于位置的服务
NINetworkInitiazted网络端发起
TBTTrueBREWTestBREW应用测试
WAPWirelessApplicationProtocol无线应用协议
2
测试目的
中国联通采用美国高通公司提供的先进的gpsOne定位技术建设了覆盖全国的定位系统,可以提供所有CDMA1X覆盖范围内(包含室内和室外)的定位信息服务。
在强大的核心定位系统的基础上,如何提供优质的基于位置的服务(LBS)或应用对移动通信运营商的业务拓展有着极其重要的作用。
服务质量,服务区域和具体服务内容必然成为衡量所有定位应用的重要标准。
因此,在应用发布前的功能,业务测试就成为保证质量的必要环节。
本文后续章节将详细描述各种测试标准和测试步骤,所有测量的标准和步骤都将以“保证质量,提高性能”为目的。
3
测试用时
中国联通位置业务处业务测试采用依照CP排序的方式。
通过位置业务处审批的业务进入测试序列,并且按照通过审批顺序轮寻CP进行测试。
当一个CP在业务测试序列中有多于一个待测业务时,并且轮寻到该CP进行业务测试,该CP可以选择对自身提交的哪一个业务优先进行测试,在该CP选择业务测试结束后,CP重新进入业务测试序列直到下一次轮到此CP。
业务测试具体开始时间不另行通知CP进行准备,第一次业务测试结束时间、业务补测结束时间、业务通过测试时间会通知CP并附业务测试报告。
业务测试开始时间为:
业务进入测试序列并且CPserver、测试区准备妥当后的8工作日以内。
业务测试用时为:
小于等于2个工作日
不能通过首次测试业务需要进行补测,补测业务单独排测试序列。
第一次补测业务在CP修改结束后3工作日内进行,测试时间小于等于2个工作日。
第一次补测不能通过业务将进行第二次补测,第二次依照CP修改情况安排时间。
4LBS业务测试报告
本节描述LBS应用的业务测试报告,在普遍测试标准的基础上,根据BREW,WAP等不同类型的LBS应用,给出CP业务测试的反馈意见和建议,作为CP业务在下一步操作中的依据。
4.1LBS业务测试报告性质
LBS业务测试报告由LBS业务测试人员撰写,反馈给分管该CP的联通位置业务小组成员,并抄送其他人,并由分管成员发送给CP。
内容为对提交业务的评价、要求、建议。
CP在收到LBS业务测试报告后需要依照其中的要求对业务做出修改和改进。
4.2LBS业务测试报告分类
LBS业务测试报告分为以下两类:
∙LBS业务测试报告:
对业务第一次测试的反馈报告
∙LBS业务补测报告:
对业务第二次和第二次以后测试的反馈报告
4.3LBS业务测试报告要求级别
对提交测试业务中出现的问题,按照一定的等级进行分类,按大类分为严重错误、错误、强烈建议和建议,如下:
●严重错误
业务中出现不符合位置业务处总体要求的问题,不进行业务测试,要求CP立刻整改。
●错误
⏹一级错误:
不能完全满足系统设计要求,基本功能未完全实现。
⏹二级错误:
严重地影响系统要求或基本功能的实现。
⏹三级错误:
使操作者不方便或遇到麻烦,但它不影响执行工作功能或重要功能。
⏹四级错误:
其他错误。
●强烈建议
在本业务和本CP没有特殊情况下,必须进行更改
●建议
业务测试人员根据自身经验和业务发展情况、统计结果给出的合理性建议,希望CP斟酌。
其中严重错误、“一、二级错误”属于测试失败,建议让CP修改后重新提交全面测试;“三、四级错误、强烈建议”等允许CP修改后,对修改后的功能或模块进行测试。
建议希望CP可以充分考虑。
5LBS应用测试标准
本节描述LBS应用的测试标准。
在普遍测试标准的基础上,根据BREW,WAP等不同类型的LBS应用,提出针对性的标准,作为在实施具体测试过程中的参考和最终的应用评价的基础。
5.1LBS应用普遍标准
下面所描述的标准对所有的LBS应用均适用。
a.位置业务中不能以任何理由出现任何形式的黄色内容。
b.位置业务中不能以任何理由出现任何涉及政治敏感的内容。
c.普通WAP、BREW业务不属于位置业务,不能通过位置业务测试。
d.位置服务应用在“返回”要求:
∙所有应用必须在业务的各级菜单上提供“返回定位之星”链接,用于用户在必要时能最方便的返回“定位之星”的主菜单。
∙在需要显示“返回”信息时,原则上不多于三个,即:
“返回上级”、“返回栏目”、“返回定位之星”;对于“返回上级”与“返回栏目”功能相同的页面,不提供“返回上级”项,只保留“返回栏目”和“返回定位之星”项。
∙对于入口页面和业务主页面不同的业务,在入口页面的子栏目下可以提供“返回入口”项目来达成返回功能;而业务主页面下的子栏目通过“返回栏目”项来达成返回功能;无特殊情况下不允许“返回入口”项和“返回栏目”项同时出现在一个页面下。
∙位置应用的第一级菜单(即首页面)只提供“返回定位之星”、“返回首页”。
∙位置游戏类业务和聊天交友类业务由于其特殊性可以考虑采用其他类型的返回系统,但是必须达到用户可以自由、方便的浏览、使用业务资源的目的。
e.所有应用必须在用户界面上(一级菜单)认真详细提供“使用帮助”(说明该LBS应用的使用方法,所提供服务的城市)、“业务说明”(说明业务提供商、业务名称、业务简介、版权说明、客服电话)、“资费说明”(业务资费)栏目。
f.所有应用必须在“业务说明”栏目中提供一子栏目“覆盖城市”,并且在其中并认真详细提供本业务针对不同城市所能提供的不同级别服务。
∙能够提供定位、导航、地图功能城市
∙能够提供位置信息城市
∙能够提供普通信息城市
∙能够提供其他功能、信息城市
g.业务主菜单下和业务入口页面下所有栏目提供图标、业务入口提供业务logo(有些特殊业务需要实时刷新,太多的图片可能导致大流量,可以不按照此要求处理)。
h.分类项目页面下,通过提供“全部”和“其他”两项来覆盖通过普通项目分类无法划分的信息,采用此两项时,需要把“全部”置顶,“其他”置底。
i.制定各种类型应用的性能指标,包含应用成功率和时延标准。
在后续的应用性能测试中有具体描述。
j.在业务任何页面下不能给返回系统中的项目编号,同样也不能给其它系统功能项目编号。
k.业务任何页面中返回系统中的项目不能分开放置,但是返回系统项目需要和其他项目分开放置,采用的方法可以是空行、通过图标区别、划线区别等等,达到区分的目标即可。
l.规范文字说明,并且添加标点;规范业务信息排版。
充分考虑同样的信息在不同机型(不同的单行文字数,不同的单屏显示航数、不同的鉴权机制、不同的下载方式等等区别)上面的不同显示效果,需要在大多数机型上都达到美观的显示效果。
m.在业务中采用定位功能时,可以根据业务需求采取各种精度的定位技术,但是无论采用哪种精度的定位,都要有存在的意义才可以。
n.在CP业务体中出现有电话号码的地方,需要设置通过点击电话号码直接拨打的功能。
o.论坛功能需要严格管理,在论坛中不能出现政治敏感言论、黄色言论等不良信息。
p.业务中不能有任何形式的欺骗用户行为,也不能有误导用户的行为。
q.涉及到第三方定位的业务,需要在业务中有对第三方定位功能的明确描述,包括可能涉及到的用户隐私问题、CPNIID、用户开通第三方定位的方法等,保证用户能够在了解这项功能的基础上,会申请、使用这项功能。
r.不能把逻辑上不同意义得项目通过并列、统一编号等方法导致给用户一种逻辑意义相同得概念。
s.单页中信息条目、信息量比较多时,需要设置分页功能,并且提供“上一页”,“下一页”提供翻页功能。
在第一页不提供“上一页”,在最后一页不提供“下一页”。
t.出现翻页时,如果进入第N页下面的某项并且点击了该项目中的“返回上级”,应该返回第N页,而不是返回第1页。
u.在有分页出现的时候,需要提供“共X页,当前是第Y页”样式的文字页码提示用户总共的信息量和当前的页面位置。
v.在用户误操作或者用户的要求超出了业务能力或者业务无法提供用户要求的信息时,业务应该有响应文字提示,不能仅仅返回“网络繁忙”等信息。
当用户输入信息明显不正确的时候(如输入为空、要求输入数字,用户却输入字母等),需要业务有正确的判断,并且返回正确的提示信息给用户,满足业务测试对业务健壮性的要求。
w.对于支持多种语言的应用,需要根据移动终端的语言设置情况自动显示相应的应用界面,所有的文字服务信息也必须支持对应的语言。
x.对在应用处理过程中可能出现的各种异常情况,要求应用界面提供如下的提示信息:
∙如果应用客户端在设定的时间内不能成功地建立与应用服务器的数据联接,应用界面提示信息:
“网络繁忙,请稍后再试”
∙如果应用不能根据定位结果(经纬度等信息)获得用户所申请的的服务信息,应用界面提示信息:
“对不起,没有您想要的服务信息!
”
∙如果在需要用户输入关键字的处理步骤中,用户没有输入,应用界面提示信息:
“关键字不能为空,请重新输入!
”
∙如果定位结果不在该应用所能够提供服务的城市范围内,应用界面提示信息:
“对不起,尚未提供该地区的位置信息服务!
”
∙如果定位过程失败,应用界面提示信息:
“网络繁忙,请稍后再试!
”并在页面下显示返回上一栏目和返回定位之星按键。
∙如果应用超时,中断服务,应用界面提示信息“服务超时,请稍后再试”
y.对于用户定位返回的结果,有如下要求:
不显示具体的方位词和距离数字,文字描述中以“在……附近”显示,要求尽量选择一条主干路、一个标志性建筑物为描述信息,在没有这些信息时,可以选择其他较为典型点作为描述对象,文字描述必须清楚明白。
zz.对于非定位返回结果,原则上不作上一条要求。
aa.定位应用应该能够自动识别请求服务的移动终端,对不支持定位功能的移动终端在应用界面上不显示与定位相关的服务栏目或功能项。
bb.定位应用应该能够正确识别使用位置服务的移动终端的各种性能参数,例如:
屏幕大小、支持色彩、WAP浏览器版本等。
应用需要提供与移动终端匹配的信息服务内容,保证应用界面在移动终端上可以完整、正确地显示。
(对于WAP及BREW方式实现的位置服务,在该项内容上采取的操作不同,详见3.2和3.3)。
cc.由于在移动终端上输入信息的过程较为繁琐和不便,要求应用界面上尽可能向用户提供选择列表,减少信息输入步骤。
dd.对于需要用户在移动终端应用界面上输入信息的处理步骤,需要应用尽量关联相应的输入法,例如对需要用户输入号码时会自动切换成数字输入法。
ee.位置服务应该具备一定的信息记忆功能,至少需记忆用户最近一次输入的关键字或选择项。
ff.应用界面上提供所提供的服务城市列表,按省(自治区、直辖市)单列,供用户选择。
gg.对于用户选择的每个服务城市,在应用界面上清楚地描述所提供的服务区域。
例如:
对于北京市,服务区域为:
“北京市四环内和昌平区,通州区。
”
hh.由于地图信息的数据量相对较大,会影响应用时延和用户的费用,要求提供位置信息服务的应用先提供文字信息描述和下载地图信息的选择项。
待用户确认需要下载地图信息后才进行地图数据的下载。
要求全部服务信息尽可能在应用界面的一个服务页面内展现。
ii.对于定位应用提供的文字信息描述,要求根据不同的服务城市提供完整的、准确的具有地方特色的服务信息。
jj.对于地图的质量,可参考相应的地图测试规范。
考虑定位应用的质量,有如下的初步标准:
∙地图的准确性:
在应用发布前需要根据联通提供的城市真值点进行地图校准,未达到规定精度的城市地图,应用不能提供其服务。
∙地图内容描述:
文字完整且不重叠,定位点标识清晰;对于导航类业务,符合联通对于导航地图的特殊规范要求。
5.2BREW定位应用标准
BREW应用属于移动终端驻留类型的应用,在应用界面的实现上具有其他类型的应用所不能比拟的优势,并且BREW定位应用的流程也具有特殊性。
下面所述为针对BREW应用提出的标准:
a.BREW位置应用在下载信息里,给用户以足够的信息,包括:
业务简介、应用服务城市列表、业务提供商、程序大小等。
b.BREW程序的移植按照机型进行,对于定位和非定位手机,应区分对待。
c.在应用处理过程中,任何时候均不能将核心定位系统返回的定位结果中的具体定位位置信息(经度、纬度、海拔等)显示到应用界面上。
d.根据定位系统规范所定义的应用处理流程,要求应用界面对每个处理步骤均有明确的提示。
e.每个处理步骤中如果应用界面等待时间超过2秒,需要提供动画或进度条提示。
f.在显示地图信息的应用界面时,提供对地图的各种操作,包括放大、缩小、移动等。
g.充分发挥BREW应用本地驻留客户端的特点,尽量减少不必要的信息交互次数。
例如可以一次下载多屏(最多9屏)的地图数据,在随后的有限的地图操作中避免与服务器进行信息交互。
h.对利用特定的短消息触发的BREW定位应用,要求应用服务器和客户端提供完善的认证策略和安全验证方法。
i.所有BREW应用应符合UBT测试规范要求,并于业务测试完成后,提交UBT测试。
5.3WAP应用标准
下面所述为针对WAP应用提出的标准:
a.CP在WAP测试区中只有一个链接,链接名称以CP的名称命名,CP提供总入口URL,该链接以下的组织由CP自己进行,原则上要求,以业务名称命名。
b.位置处提供最多3个CP的手机号为测试号码。
c.WAP位置CP根据位置处提供的定位手机参数,建立定位手机参数库;通过对手机的UA判断来选择是否显示定位菜单。
d.WAP位置CP根据位置处提供的WAP手机参数,建立WAP手机参数库;通过手机的UA,来对手机进行正确适配,适配内容包括:
手机屏幕尺寸大小、屏幕色彩等。
e.任何时候均不能将核心定位系统返回的定位结果中的具体定位位置信息(经度、纬度、海拔等)显示到WAP服务页面上。
f.应用WAP页面层次不能多于3层。
g.对需要进行连续定位的应用可以设定时间间隔和连续定位次数,时间间隔不能小于5分钟,次数不能大于30次。
h.在定位结果超出所提供的服务区域情况下,需要提供明确的信息提示页面。
i.所有WAPLBS应用均需符合普通WAP应用的技术测试标准,并于业务测试后提交技术测试,技术测试包括性能测试和计费测试。
j.所有上线WAP方式LBS业务应满足先展示后定制的原则,具体见附录四。
6
与其它测试的关系
在应用从设计、开发到商用发布过程中,需要经历多种不同的测试。
定位应用业务测试与其他各种测试相互配合,共同确保应用质量。
同时,核心定位系统的端到端测试也对定位应用业务的开展提供了有力的帮助。
6.1与核心定位系统端到端测试的关系
在定位系统端到端测试中,为了测试系统的整体性能和处理能力,将选择各种不同的具体应用进行测试,要求所选择的应用可以完成系统规范要求的核心处理流程。
根据实际情况,可以是实际的、已经正式商用发布的定位应用,也可以是为了测试目的开发的简化的应用,我们称它们为“参考应用”。
端到端测试在借助各种类型的“参考应用”完成对核心定位系统的性能、功能的测试。
从而建立了核心定位系统的各种标准。
由于端到端测试中采用的“参考应用”与广大应用提供商提供的各种不同的实际定位应用具有相同的核心处理流程,经过了相同的处理环节。
因此端到端测试的结果可以作为衡量实际定位应用性能的参考标准。
在应用业务测试过程中,建议将应用业务测试结果与同类型的应用在系统端到端测试中的各种指标进行对比。
6.2与BREWUBT测试的关系
BREWUBT测试主要对所有BREW应用进行包括应用操作界面、与移动终端的适配性、与无线网络环境的适配性等方面进行测试,保证BREW应用的安全、可靠和正确运行。
由于提供定位服务的BREW应用的特殊性(采用了特殊的应用处理流程),BREWUBT测试并未对提供定位服务的应用进行业务方面的测试,也没有针对定位应用的特点制定特别标准。
为了保障BREW定位应用的服务高质量,在满足普通的BREWUBT测试要求之前,需要所有的提供位置服务的应用满足应用业务测试的标准。
6.3与WAP技术测试的关系
WAP的技术测试包括性能测试和计费测试。
性能测试主要是对CP应用服务器的压力测试,通过向CP服务器发包(分为多组,每组时间间隔不同),来检验CP的应用服务器性能;计费测试主要是检验应用的计费是否正常进行和正确扣费。
WAP技术测试将由北京振戎融通通信技术有限公司进行,并按照情况收取相应的测试费用。
技术测试前,需要所有的WAP位置服务满足业务测试的标准。
6.4与网络接入测试的关系
所有在运营商的网络上(无线网络和有线网络)提供服务的应用均需要进行网络接入测试,保证网络的通常和数据服务的稳定性。
与业务测试保证高质量的服务相比,网络接入测试为应用保证了高速、可靠的网络运行环境。
网络接入测试在技术测试中(BREWUBT测试)一并进行。
由于目前BREW业务均为全国性业务,所有BREW应用的服务器均要求在联通内网,为了保证应用的稳定性和连接的可靠性,原则上要求,所有WAP位置服务的应用服务器搬至联通内网中。
联通内网可以是联通总部IDC机房,联通分公司IDC机房以及专线接入方式。
7
测试环境
要高效、可靠地完成LBS应用的测试,必须选择适当的测试环境。
由于LBS应用的处理流程或性能表现与核心定位系统、CDMA1X网络性能密切相关,所以与其他类型的增值服务相比,具备一定的特殊性,例如需要在实际的CDMA1X网络环境中进行测试,需要在各个不同的网络环境下进行测试等。
7.1现网测试环境
现网测试环境即在实际的CDMA1X网络运行环境中挑选合适的满足测试需求的环境。
在该环境下,可以实现对所有LBS应用的测试工作。
7.1.1需要具备的条件
(1)在端到端测试中表现出稳定可靠的性能,包括定位精确度、定位成功率和定位时延等;
(2)便于测试,选择相对开阔,容易安排测试工作的环境;由于客观原因的限制,目前测试环境选择在联通大厦室内环境下进行。
(3)在该环境下,端到端测试已经建立了完整的应用测试参考标准;
8
测试方法
LBS应用的测试工作量较大,测试过程相对较为繁琐,如果选择了合适的测试方法,将提高测试的效率,降低测试人员的工作量。
8.1人工手动测试
对于主观的、测试量少的测试项目,测试人员的素质和测试技能将影响测试的效果。
作为合格的LBS应用测试人员,需要具备多个方面的知识和能力。
8.1.1需要具备的条件
(1)热爱测试工作,严谨的工作作风,一丝不苟的工作态度;
(2)熟悉LBS应用处理流程和核心定位系统的系统结构;
(3)熟悉各种类型应用(BREW,WAP等)的技术特点和局限性;
(4)对移动增值业务和应用软件有深入的了解;
(5)熟悉测试流程,测试环境和各种测试方法;
9
测试流程
LBS应用业务测试流程如下图所示:
(1)LBS应用开发商(CP)完成应用开发和内部测试后,向业务测试小组提交测试申请;
CP需要提交的文档详见10.1节:
(2)测试小组判断申请是否合格,所递交的测试材料是否完整;
(3)对不合格的测试申请,反馈回应用开发商,重新准备申请材料;
(4)对于合格的测试申请,选择需要测试的项目,安排测试计划;
(5)对于需要测试的所有测试项目,根据项目特点,在现网测试环境中进行测试;
(6)所有项目测试结束后,汇总测试结果;
(7)判断所测试的LBS应用是否通过测试;
(8)对没有通过测试的LBS应用,将测试结果反馈给应用开发商;
(9)对于通过测试的LBS应用,生成详细的测试报告。
10
LBS应用测试项目
根据前面所描述的位置服务应用的测试标准,对LBS应用的全面测试可以划分为以下几个测试项目,本节将就如何实施每个测
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 中国联通 LBS 大众 应用 业务 测试 规范 1227