移动APP系统测试用例设计大全（下）
流程分析方法1-手动/自动选网模式；11-自动注册并显示已有网络服务。
2-手动模式（选网模式的一种）；3-搜寻到HPLMN（归属网络）及FPLMN（禁止网络）；6-频段搜索；7-自动选择频段；8-手动选择频段900或1800；（新手机才有频段手动选择）4-选择FPLMN；5-注册FPLMN。
路径
path1:1-11
path2:1-2-3-4-5-1-11
path3:1-2-3-6-8-9-10-1-11
path4:1-2-3-6-7-9-10-1-11
彩信发送功能
1. 终端发送MMS，如果是终端到终端，那么以WSP（无线会话协议）协议编码送到WAP网关；如果终端到应用服务器（发送Email）,则以IP协议发送到IP网关；
2. WAP网关或IP网关都以HTTP协议与MMS中继器通信，文件内容传给中继器
3. 中继器将文件送往MMS服务器，并以MIME格式存储。（MIME的格式可以被手机终端识别并显示，并且可以被Email客户端浏览并显示的文件格式）
4. 如果MMS接收方为手机终端，MMS服务器调用号码以及相关路由信息，并进行数据分析，判断终端支持能力和承载能力，如果终端不支持MMS，只通过短消息格式发文字部分；如果终端支持MMS，直接发送MIME格式的文件到手机终端。
5. 如果，发送到Email服务器，系统通过路由选择，把MIME格式的文件发送到Email地址所在的服务器。
6. 该MMS支持的媒体格式包括文本、铃声、图片；文本没有上限64K，包括64K；铃声单首最大为64K，包括64K，最多支持5页；单页图片最大64K，最多5页。
测试用例设计
利用流程分析方法，测试分析时需要考虑以下几点：
1、彩信发送测试时需要考虑基于WAP业务实现和基于IP网关的流程差异；
2、MMS服务器数据分析并确定处理方法时需要考虑终端到终端的情形和终端到应用的业务情形；
3、确定终端到终端的情形下，还需要考虑终端是否支持MMS发送。
正交试验设计法
例子1：
假设一个WEB站点，该站点有大量的服务器和操作系统，并且有许多具有各种插件的浏览器浏览：
WEB浏览器：Netscape6.2、IE6.0、Opera4.0
插件： 无、RealPlayer、MediaPlayer
应用服务器：IIS、Apche、Netscape Enterprise
操作系统：Windows2000、Windows NT、Linux
正交表：
http://www.51testing.com/attachments/2023/02/15326880_202302091449081zQCL.png
提取系统功能说明中的因子：
·WEB浏览器
· 插件
· 应用服务器
· 操作系统
分析各因子的状态
· WEB浏览器：1＝Netscape6.2、2=IE6.0、3=Opera4.0
· 插件: 1=None、2=RealPlayer、3=MediaPlayer
· 应用服务器: 1=IIS、2=Apche、3=Netscape Enterprise
· 操作系统: 1=Windows2000、2=Windows NT、3=Linux
将因子、状态映射到上面正交表中：
http://www.51testing.com/attachments/2023/02/15326880_202302091449111y9LJ.png
举例2：MMS处理模块
编辑模块：支持SMIL（同步多媒体综合语言）、不支持SMIL…..
效果处理模块：水波纹、半透明、水印、反透…..
界面显示模块：POP形式、窗体式显示…..
举例3：照相机功能测试
状态迁移法
举例手机mp3键盘播放模式测试用例设计：
1. 键盘用户模式基本操作功能
2. 支持媒体格式与文件格式要求
3. 多媒体播放中对外部事件的响应
4. 终端处理能力（包括终端异常处理、文件操作）
5. PC与终端同步能力
键盘用户模式基本操作功能系统测试用例设计步骤：
·编写状态—事件表；
· 编制状态图转换表；
· 编写合法测试用例；
· 编写非法测试用例；
· 编写错误异常处理测试项；
http://www.51testing.com/attachments/2023/02/15326880_202302091449141w6rl.png
http://www.51testing.com/attachments/2023/02/15326880_202302091449191vcrT.png
状态—事件表（黑点着重号表示为非法组合）
http://www.51testing.com/attachments/2023/02/15326880_2023020914492213AQG.png
1、软件测试文档就是为将软件测试当作一个项目一样实施计划和管理而引入的，它为测试项目的组织、规划和管理提供了一个规范化的架构。
2、软件测试文档主要包括测试计划、测试用例、测试规程、测试事件报告、测试总结报告等。测试文档总所规定的内容可以作为对测试过程完备性的对照检查表，有助于提高测试工程每个阶段的能见度，极大地提高了测试工作的可管理性。
为了统一测试文档的书写标准，IEEE/ANSI制定了829-1983标准，还有其他的一些也用于指导软件测试文档的编写，如我国制定的《计算机软件测试文件百年之规范（GB/T 9386-1988）》
3、 测试文档编写规范（GB/T 9386-1988）简介
（1）引用标准
该规范的引用标准为：
GB/T 11457 软件工程术语
GB 8566 计算机软件开发规范
GB 8567 计算机软件产品开发文件编制指南
（2）关键术语定义
设计层：软件项的设计分解（如系统，子系统，程序，模块）
通过准则：一个软件项或软件特性的测试是否通过的判别依据
软件特性：软件项的显著特性（如功能，性能或可移植性）
软件项：源代码，目标代码，作业控制代码，控制数据或这些项的集合。
测试项：作为测试对象的软件项
（3）规范的主要内容
该规范确定了各个测试文件的格式和内容，所提出的文件类型包括测试计划，测试说明和测试报告。
测试计划免除测试活动的范围，方法，资源和进度，他规定被测试的项，被测试的特性，应完成的测试任务，担任各项工作的人员职责及与本计划有关的风险等。
4、测试说明包括三类文件
测试设计说明：详细描述测试方法，规定该设计及其有关测试所包括的特性，还规定完成测试所需的测试用例和测试规程，并规定特性的通过准则。
测试用例说明：列出用于输入的具体值以及预期的输出结果，并规定在使用具体测试用例时，对测试规程的各种限制。将测试用例与测试设计封开，可以使它们用于多个设计并能在其它情形下重复使用。
测试规程说明：规定对于运行系统和执行指定的测试用例来实现有关测试设计所要求的所有步骤。
5、测试报告则包括四类文件：
测试项传递包括：指明在开发组和测试组独立工作的情况下或者在希望正式开始测试的情况下为进行测试而传递的测试项。
测试日志：测试组用于记录测试执行过程中发生的情况。
测试事件报告：描述在测试执行期间发生并需进一步调查的一切事件。
测试总结报告：总结与测试设计说明有关的测试活动。
6.对规范的实施
使用该规范的每个单位，要规定测试阶段所应有的特性文件，并在测试计划中规定测试完成后所能提交的全部文件。
使用该规范的每个单位应该补充规定对内容的要求和约定，及便反映总结在测试，文件控制，配置管理和质量保证方面所用的特定方法，设备工具。
一下是规范中的文件编制实施及使用指南
· 实施指南
在实施测试文件编制的初始阶段可先编写测试计划于测试报告文件。测试计划将为整个测试过程提供基础。测试报告将鼓励测试单位以良好的方式记录整个测试过程的情况。
· 用法指南
在项目计划及单位标准中，指明在那些测试活动中需要那些测试文件，并可在文件中加入一些内容，使各个文件适应一个特定的测试项及一个特定的测试环境。
页:
[1]
