中国电信移动增值业务BREW业务测试规范v11.docx
《中国电信移动增值业务BREW业务测试规范v11.docx》由会员分享，可在线阅读，更多相关《中国电信移动增值业务BREW业务测试规范v11.docx（105页珍藏版）》请在冰点文库上搜索。
中国电信移动增值业务BREW业务测试规范v11
中国电信移动增值业务
—BREW测试规范
中国电信股份有限公司
目录
1.范围4
2.测试环境4
3.测试概述4
1.1测试提交文档4
1.2测试目的5
1.3测试过程6
1.4测试结果定义7
1.5问题修改意见分类7
4.应用程序检查7
5.进入测试9
6.应用程序全面检测15
6.1UI测试15
6.1.1UI逻辑测试15
6.1.2UI内容16
6.1.3UI设计19
6.2功能测试23
6.2.1程序的启动与退出23
6.2.2使用许可24
6.2.3动态显示25
6.2.4数据存储26
6.2.5功能性按键28
6.2.6清除键29
6.2.76.2.7发送键31
6.2.8铃声下载应用32
6.2.9音乐下载应用34
6.2.10图片下载应用36
6.2.11AUT地址簿37
6.2.12声音连续播放39
6.2.13定时器与报警41
6.2.14照相机41
6.2.15定位应用，非导航类42
6.2.16定位应用，导航类43
6.2.17屏幕保护44
6.2.18公共扩展类遍历测试（暂不测）45
6.2.19BREW自升级功能46
计费网关47
6.3兼容性测试47
6.3.1手机端发起的SMS短信息47
6.3.2特定应用的SMS消息48
6.3.3语音呼叫49
6.3.4中断/恢复51
6.3.5网络连接55
6.3.6服务丢失57
6.3.76.3.7文件系统限制59
7.特殊类别应用探索测试61
7.1流媒体应用62
7.2社区类及搜索类应用63
7.3养成类应用64
7.4开机自动运行或后台运行类应用65
7.5永远在线类应用67
8.应用快速探索测试70
8.1A类快速测试70
8.2B类快速测试71
1.范围
本标准规定了中国电信BREW应用测试的方法及依据。
本标准作为所有BREW应用测试人员所遵循的测试标准。
2.测试环境
●移动设备：
用于测试的终端。
●中国电信CDMA1X网络：
移动设备将利用其进行测试。
3.测试概述
1.1测试提交文档
1、测试提交文档压缩包格式：
应用Zip/Rar压缩包：
XXX_YYY_Va.b.c_p.zip（.rar）
XXX指公司英文名。
YYY指应用英文名。
a指主版本号。
主要标识应用程序的主体及架构的变化。
b指二级版本号。
主要标识应用增加新的Feature。
c指三级版本号。
主要标识对Error或Issue的修改。
p对于不同的提交方式，有不同的定义：
∙单一手机平台提交时，则使用单一的手机平台号进行标识（platformId），在测试流程中不会改变。
例如：
XXX_YYY_V1.0.1_1016.zip该应用是XXX公司的应用YYY，版本为V1.0.1，仅用于LGCU8188手机。
∙多手机平台提交时，则使用“Multiple”进行标识。
平台列表应在提交清单中列出。
例如：
XXX_YYY_V1.0.3_Multiple.zip该应用是XXX公司的应用YYY，版本为V1.0.3，该版本支持多款BREW手机平台。
备注：
应用程序中的版本号Va.b.c应与应用Zip压缩包Va.b.c一致.
2、压缩包文件目录：
∙arm目录：
∙mif文件
∙mod文件
∙bar文件（可选）
∙其它数据文件（可选）
∙doc目录：
∙用户使用手册（PowerPoint）：
Mnl_XXX_YYY.ppt
∙产品规范说明:
Spec_XXX_YYY.doc
∙SubmitForm文件:
Submit_XXX_YYY.doc
∙win目录：
∙dll文件
∙mif文件
∙bar文件（可选）
∙其它数据文件（可选）
∙src目录（仅当应用作为公共扩展类的TestApp才应包括，请参见下一节）：
包括完整的TestApp项目。
测试方可直接编译生成mod和dll文件。
∙TestApp所有源码文件。
∙Arm或GCCMake文件。
∙TestApp项目文件。
∙其它数据文件（可选）
1.2测试目的
●应用界面的统一性以方便用户的使用。
●应用功能的完整性。
●应用运行稳定性以及安全性。
●应用的兼容性：
⏹保证应用符合BREW规范
⏹保证应用的运行不会影响到目标终端的通信功能
●保证用户能够正确下载应用。
●保证用户的合法权益受到保护。
1.3测试过程
1．应用程序接受检查。
主要检查开发商资质以及测试包格式及基本信息是否正确。
如正确则接受该应用，否则将退回测试包。
2．应用程序进入测试。
该阶段主要对测试程序进行详细测试前的基本测试。
3．应用程序全面测试：
主要包括UI性测试、手机与应用交互性功能测试和BREW功能性测试三大类：
∙UI测试：
该阶段主要对应用进行探索性浏览测试，包括应用的基本逻辑与使用用例检查，BREW应用是否符合电信UI规范检查要求，特殊类别应用是否符合专项检查要求以及3类BREW应用快速测试。
∙BREW功能性测试：
该阶段将对应用程序通过BREWAPI实现的功能进行分类严格测试。
确保功能的实现符合运营商的基本要求。
∙应用兼容性测试：
该阶段将对应用程序和手机电话系统的兼容性进行严格测试，涉及到手机的短信收发，语音的呼入呼出，网络连接，服务丢失，文件系统，中断与恢复等。
确保BREW应用的使用不影响手机的基本电话功能。
本BREW测试不包含应用程序的功能及内容方面的测试内容。
任何有关应用功能及内容方面的质量保证由开发商自行承担。
关于应用内容及业务方面的质量要求及相关程序请参考电信有关规定。
本BREW测试在正常执行过程中，如果发现了应用的逻辑或内容存在严重问题，且对最终用户的正常使用有较大影响。
即使未在本测试指南中明确说明，也将本着为开发商负责的态度进行报告，并可能导致应用测试失败。
1.4测试结果定义
当对应用的测试完成后，测试的结果将被分析和评估。
被测试应用将得到如下5种测试结论：
Fail
当应用有一个或多个Error时的测试结论。
说明应用没有通过BREW测试。
Pass
应用满足BREW所有测试需求后所作的最终测试结论。
说明应用通过了BREW测试。
Pass-with-notes
当应用有一个或多个Error,但这些Error对最终用户只有较小的影响,经评估后允许通过测试时的测试结论。
N/A
应用不具有该项功能.未予测试。
Skip
测试过程中，由于某一项测试用例失败导致某些应当执行的测试用例无法继续执行。
1.5问题修改意见分类
对测试中发现的问题，分成以下两种修改意见：
●必须修改：
该类问题会影响用户的使用，CP/SP必须修正后才能申请上线。
●建议修改：
该类问题基本不影响用户的使用，但修改后能提高用户的满意度，建议修改此类问题，该类问题不影响业务上线。
BREW测试不包含应用程序的功能及内容方面的测试内容，任何有关应用功能及内容方面的质量保证由开发商自行承担。
4.应用程序检查
电信应用开发商在提交应用测试包后，首先要对测试包进行应用程序接收检查。
本测试包括以下内容：
Checkpoint
Description
Result（Yes/No）
1
检查应用包是否符合所申请的测试类型的条件？
2
应用包名字和提交清单中的版本号是否一致？
3
应用提交清单中是否明确了申请下载栏目位置？
4
是否符合电信Brew测试打包格式要求？
5
应用包的平台号是否与提交清单中的平台号一致？
6
ARM目录中的所有文件名称和后缀是否全部采用小写？
文件名不能包含空格
7
应用程序的文件包中不得包含零字节的文件。
每个文件至少有一个字节。
MIF文件名不得以数字开头。
8
应用程序的ARM目录下不包含子目录
9
ARM目录中的所有文件都不能设为只读
10
检查应用是否使用BREW计费网关，如果是则检查应用计费方案中是否规定了使用的产品及产品的资费类型
11
检查应用是否具有应用自升级功能，如果是则检查是否提交了自升级测试应用包
5.进入测试
Note:
下面每一项测试均应为YES才能提交BREW测试
Checkpoint
Description
Result（Yes/No）
1.1MIF设置
C1
MIF文件可以正常被打开。
C2
MIF文件名和MOD文件名应保持同名。
C3
MIF文件中应用程序的中文名称应和提交清单中应用程序名称一致
MIF文件中应用名字只允许采用中文简体（英文缩写或常用英文专有名词除外）
C4
MIF文件中的所有优先级须和应用程序开发商提供的提交清单相符合。
Advanced优先级不能被选择，除非得到电信或高通书面允许。
C5
如果应用程序支持iLicense，那么File优先级必须被选择
C6
ClassID不同时出现在MIF文件中的Applets和Dependencies栏内。
C7
Applets栏和Extensions栏的数据仅在一个栏下出现
C8
MIF Editor中出现的所有通知均存在于应用程序规范中
C9
选择Unicode作为移动设备支持的StringFormat
C10
如果这是一个具有屏幕保护（ScreenSaver）功能的应用程序,那么屏幕保护（ScreenSaver）选项被选定
C11
MIF文件中的iLicense应被设为NotUsed（None）
C12
如果被使用扩展类已经通过BREW测试，是否在提交报告中及MIF文件中准确填写了该扩展类的ClassID号？
C13
MIF中Dependancy中所包含的扩展类具有合法的授权。
不得非法使用XX的扩展类。
1.2应用程序图标的尺寸
C14
Image、Icon、Thumbnail三种图标都应包括在AUT的MIF中。
对于超低端手机，只要求Icon图标，Image和Thumbnail则使用BREW默认图标。
默认图标类型由MIF默认Applet类型决定。
微缩图像（Thumbnail）为16（w）x16（h）像素。
超低端手机不包含Thumbnail。
图标图像（icon）26（w）x26（h）像素。
支持部分或全部透明。
标准AUT图像（Image）是65（w）x42（h）。
如果数据设备支持，允许满屏显示或者按标准显示尺寸进行显示。
超低端手机不包含Image。
对于超低端手机应用，是否选择了默认Applet类型？
手机采用BAM2.0.5c01时，图标图像（icon）尺寸与该手机DDS相关说明一致。
手机采用BAM2.0.5c01Sp01时，图标图像（icon）及微缩图像（thumbnail）尺寸与该手机DDS相关说明一致
1.3版本号
C15
应用程序必需包含版本号码：
∙MIF文件的GeneralTAB栏内应包含应用版本号
∙应用的关于应包含版本号
C16
应用程序新提交的版本不能与老版本号相同。
应用中所有出现版本号的地方应该保持一致
1.4应用程序的下载和显示
C17
应用程序必需可以通过BREW的AppLoader（或类似工具）下载AUT到手机上
C18
当应用程序下载到手机后，图标显示在BREW中。
每一个应用程序的ClassID只显示一个图标。
应用程序的图标不使用BREW图标。
C19
应用程序的显示名称应保证与提交清单中的应用中文名称一致
C20
应用程序能使用应用程序管理器启动并退出。
主菜单页面应为一级或二级子页面。
C21
应用应包括帮助和关于，并放在明显位置（如主菜单）。
可使用文字或图标方式。
帮助项名称应包含“帮助”二字。
关于项名称应包含“关于”二字。
应给出应用中文名称、公司中文名称、应用程序的版本号、公司客服电话。
并与提交清单一致。
C22
如果应用程序是一个联网程序，须采用电信内部URL。
应用必须能通过BREW/BREW的用户名和密码来访问应用程序服务器而不是CARD/CARD。
确认AUT能够访问服务器。
C23
如果应用程序是一个屏幕保护程序、墙纸程序或铃声等程序，应支持内容的下载。
1.5测试规范
C24
应用Spec应包含程序框架或UI框架
C25
应用Spec应包含基本使用用例
C26
应用Spec是否有详细的按键说明
C27
MIF中的应用优先级使用在应用Spec相关章节中是否有详细的使用说明：
File
Network
PositionLocation
TAPI
WebAccess
AccesstoAddressBook
Writeaccesstoshareddirectory
WriteaccesstoRingerDirecotry
WriteaccesstoSectorInformation
1.7应用尺寸大小
C30
对于超低端手机，应用包尺寸（MIF、MOD、SIG和其他文件）应小于Max（40K60K），Min（EFS尺寸/5,RAM尺寸/3）
对于低端手机，应用包尺寸（MIF、MOD、SIG和其他文件）应小于Min（EFS尺寸/5,RAM尺寸/3）
对于高端手机，应用包尺寸（MIF、MOD、SIG和其他文件）应小于500Kbytes
1.8特殊类别应用
C31
流媒体应用，应用程序应获得电信的允许开发流媒体类应用。
应用Spec中应对特殊应用类别加以说明。
社区论坛类或搜索类应用，应用程序应获得电信的允许开发社区论坛类或搜索类应用，或具有相关功能。
应用Spec中应对特殊应用类别加以说明。
永远在线类应用，应用程序应获得电信的允许开发永远在线类应用。
应用Spec中应对特殊应用类别加以说明。
1.9应用说明
C32
提交清单的应用描述中应包含应用说明、免责说明、公司名称、客服电话和应用大小
1.10外存卡操作许可
C33
如应用Spec说明了具备外存卡操作功能，应提交电信批准的内容版权保护声明。
6.应用程序全面检测
6.1UI测试
6.1.1UI逻辑测试
6.1.1.1程序结构
Requirement:
应用程序结构与规范文档中描述的一致。
Mapstoapplicationspecification:
Applicationuserinterfacearchitecturediagram.
Step
Action
Expectedresults/detailedrequirements
TypeofApps
Status
Comment
1.
按照规范文档的流程图的基本分支运行应用程序。
∙流程图中描绘的各个页面在应用程序中正确显示。
∙应用程序中各页面按照流程图的描述进行转换。
∙应用程序的主要页面及功能与AppSpec保持一致
All
6.1.1.2程序用例
Requirement:
应用程序例程能够正确完成，并得到规范文档中所描述的结果。
Mapstoapplicationspecification:
Applicationuserinterfacearchitecturediagram.
Step
Action
Expectedresults/detailedrequirements
TypeofApps
Status
Comment
2.
按照规范文档的程序例程运行应用程序。
应用程序例程能够正确完成，并得到规范文档中所描述的结果
All
6.1.1.3帮助
Requirement:
应用程序按照帮助中的描述正确执行。
Mapstoapplicationspecification:
N/A
Step
Action
Expectedresults/detailedrequirements
TypeofApps
Status
Comment
1.
实现帮助中提及的功能和定义等。
帮助中提及的功能和定义等描述在应用程序中正常实现。
All
6.1.2UI内容
6.1.2.1语言要求
要求：
∙应用程序的名称、标准菜单和各种标题必须采用中文简体，但常见英文缩写或英文专有名词除外。
∙应用程序其它内容的主体应尽量采用中文简体，如包含英文或其他字符，以不影响普通用户理解，操作为原则。
∙应用是否支持英文界面不作具体要求。
此项测试考察测试中所进入的页面是否满足电信UI规范。
假设：
AUT已经安装到移动设备中。
步骤
操作
预期的结果/详细的要求
状态
注
1.
考察AppSpec定义的所有被测试屏幕。
∙应用程序的名称、标准菜单和各种标题必须采用中文简体，但常见英文缩写或专有名词除外。
∙应用程序其它内容的主体应尽量采用中文简体，如包含英文或其他字符，以不影响普通用户理解，操作为原则。
∙应用是否支持英文界面不作具体要求。
（V:
P4）
6.1.2.2Splash屏幕
要求：
闪屏常用于应用程序启动时显示应用的信息或公司的Logo。
如果应用支持闪屏，将作此项测试。
建议AUT支持闪屏。
•Splash内容不作具体要求。
•应用程序启动时应出现Splash屏幕。
•Splash出现后，应在2S内自动跳出当前Splash页面，或在2S之后可按任意键跳出当前Splash页面。
2S内按键是否响应不作要求。
•Splash页面数量不作具体要求，建议1屏，最多不超过3屏。
任意键定义：
包括*键、＃键、0－9数字键、方向键、选择（OK）键。
对于接听键、清除键、功能键，是否支持跳过闪屏不作具体要求。
假设：
AUT已经安装到移动设备中，应用程序支持Splash。
步骤
操作
预期的结果/详细的要求
状态
注
3.
从应用程序管理器启动AUT。
出现Splash屏幕。
如果支持定时跳出。
应在2S内自动跳出当前Splash页面。
4.
从应用程序管理器启动AUT。
如果不支持定时跳出。
2S后按任意键。
如果支持按键跳出，Splash将响应按键跳出当前Splash页面。
6.1.2.3开关
Requirement:
应用程序的开关能正确执行并对应用程序无不良影响。
Mapstoapplicationspecification:
N/A
Step
Action
Expectedresults/detailedrequirements
TypeofApps
Status
Comment
1.
根据规范文档中对开关的描述控制开关的开合。
开关全开后指定的功能正常实现。
开关全关后指定的功能没有实现。
单个开关功能正常实现。
All
不测试组合开关的状况。
6.1.3UI设计
6.1.3.1屏幕布局
要求：
应用程序UI有三种布局方案：
∙应用程序自适应屏幕尺寸来调整UI满屏显示
∙应用程序修改屏幕尺寸大小以保证满屏显示。
∙应用程序UI按大，中，小标准尺寸设计。
如手机的屏幕实际尺寸不符合此标准尺寸，应用的UI须在长和宽的方向上居中对齐：
（具体参见电信UI规范）
此项测试考察测试中所进入的页面是否满足电信UI规范。
假设：
AUT已经安装到移动设备中。
步骤
操作
预期的结果/详细的要求
状态
注
1.
从应用程序管理器启动AUT并进入程序主屏幕及各个子屏幕。
∙应用程序每个页面能够满屏显示或，
∙如果按标准尺寸显示，UI应大致居中显示。
6.1.3.2等待处理
要求：
很多情况下，应用程序无法做出瞬间反应。
如果用户必须等待应用程序完成一个进程，应向用户提供一个可视的反馈。
∙当用户在等待长时间的进程时，应向用户提供一个可视的反馈。
建议使用动画进程或提示信息来显示运行的进度状态。
∙对网络连接等待状态，至少应提供一种方式退出连接等待状态。
如使用清除键、特定功能键或结束键。
∙对非网络连接等待状态，至少保证30秒后可使用清除键、特定功能键或结束键退出等待状态。
∙对其他重复按键，如果程序能够响应，建议予以忽略，因为用户在反应迟钝时倾向于重复按键。
该项不作为测试要求。
假设：
AUT已经安装到移动设备中。
步骤
操作
预期的结果/详细的要求
状态
注
5.
从应用程序管理器启动AUT并运行该程序。
∙当用户在等待长时间的进程时，应向用户提供一个可视的反馈。
建议使用动画进程或提示信息来显示运行的进度状态。
∙对网络连接等待状态，至少应提供一种方式退出连接等待状态。
如使用清除键、特定功能键或结束键。
AUT返回前级某一页面或作出相应响应（如弹出中间页面）
∙对非网络连接等待状态，至少保证30秒后可使用清除键、特定功能键或结束键退出等待状态。
AUT返回前级某一页面或作出相应响应（如弹出中间页面）
∙对其他重复按键，如果程序能够响应，建议予以忽略，因为用户在反应迟钝时倾向于重复按键。
该项不作为测试要求。
如使用结束键退出等待状态，应用退出可以被接受。
6.1.3.3屏幕的刷新
要求：
每个屏幕（例如splash、帮助、弹出对话框、文本输入）可以正确的刷新且内容正确。
将覆盖在另一屏幕上的某一屏幕取消后可以正确的刷新。
如果屏幕无法完全刷新，但该屏幕不是主要功能页面（如帮助、关于等），且屏幕主要部分交叠不严重，不影响用户的使用，将被作为Issue来处理。
此项测试考察在兼容性测试及功能性测试中所进入的页面是否满足电信UI规范。
假设：
AUT已经安装到移动设备中。
步骤
操作
预期的结果/详细的要求
状态
注
6.
考察所有被测试屏幕。
弹出窗口或图形消失后屏幕可以完全刷新。
在过渡期间屏幕不会是空屏。
屏幕中没有乱字符。
（V:
P4）
如果屏幕无法完全刷新，但该屏幕不是主要功能页面（如帮助、关于等），且屏幕主要部分交叠不严重，不影响用户的使用，将被作为Issue来处理。
6.1.3.4UI控件检查
要求：
检查控件的显示符合UI规范。
控件包括菜单、文本输入框等
此项测试考察在兼容性测试及功能性测试中所进入的页面是否满足电信UI规范。
假设：
AUT已经安装到移动设备中。
步骤
操作
预期的结果/详细的要求
状态
注
7.
考察所有被测试屏幕。
∙UI
升级会员 