第2章手机软件测试用例设计
本章要点：
● 用例设计考虑因素；
● 用例设计基本原则；
● 用例设计常用方法。
2.1 用例设计考虑因素
从理论上讲，手机软件规模越大，模块间的关系越复杂，组合的情况越多，测试用例数目占的比例也就越大，因而总是很难设计出“足够”的测试用例。
虽然理论上缺陷空间（测试空间上所有可能发生的缺陷构成的集合就是缺陷空间）可以接近无限大，但实际情况中存在的缺陷只是缺陷空间的一个很小的子集。测试中最重要的是要找到已经存在的缺陷，但在没有进行测试前，手机软件中存在多少缺陷却是不知道的。
从理论上讲，测试是不能穷尽的，就意味着不存在一种方法能将所有的缺陷都所以找出来，找到缺陷的问题注定是一个概率问题，将那些发生概率较大的缺陷找出来就成了测试的主要任务。
测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。测试用例是执行的最小实体。简单地说，测试用例就是设计一个场景，使测试程序在这种场景下运行并且达到程序所设计的执行结果。
设计测试用例首先要考虑以下几个问题：
● 为什么要设计测试用例？
● 谁来写测试用例？这些写测试用例的人的测试技术如何？以及对被测试产品了解有多深入？
● 测试用例写给谁看，多少人将使用测试用例文档？
● 分配给编写测试用例的时间是多长？要安排几个人来写？
● 怎么在测试用例的成本、质量和效率方面达到平衡？
目前的手机市场对于新推出的功能和应用程序有着迫切的需要，使得产品周期非常短；然而只有回答了这些问题，才能确定测试用例的具体写作方法和表现形式。一般而言，手机软件测试项目中分配写测试用例的时间并不长，而且提供的文档也不全面，所以写测试用例要符合测试部门的当前现状和项目的测试特点。
对于测试设计工程师来说，设计测试用例需要考虑以下几个方面：
● 测试用例设计必须考虑有效：容易发现并呈现错误；
● 测试用例设计必须覆盖全面又不冗余：数量上不应有重复的、多余的用例，对软件规格说明书和设计功能点有全面的覆盖，不仅包括功能测试用例，还包括性能测试用例，外场测试、易用性等测试用例；
● 测试用例设计必须明确粒度和测试分类的程度：粒度越细，测试成本就越高，测试周期就越长；分类越多，测试成本相应增加，测试周期就越长；
● 测试用例设计完成后必须经过评审：以帮助进一步补充用例，提高测试覆盖率，提高用例质量。
对于测试执行工程师来说，测试用例的内容应包括以下几个方面：
● 测试用例的测试目标；
● 测试用例的被测功能点描述；
● 测试用例的测试运行环境；
● 测试用例的执行方法（包括测试步骤，输入测试数据或测试脚本）；
● 测试期望的结果；
● 执行测试的实际结果；
● 其他辅助说明。
2.2 用例设计基本原则
● 测试用例的代表性：能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的输入数据、操作和环境设置等。
● 测试用例的可执行特点：在测试前提符合的情况下，依照测试步骤，每一个测试用例都能够顺利地使程序运行，同时呈现相应的期望结果。
● 测试结果的可判定性：即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。
测试结果的可再现性：即对同样的测试用例，系统的执行结果应当是相同的。
2.3 用例设计常用方法
一个好的测试用例是指可能找到迄今为止尚未发现的错误的测试，由此可见，测试用例设计工作在整个测试过程中占有十分重要的地位，所以我们不能只凭借一些主观或直观的想法来设计测试用例，而应该要以一些比较成熟的测试用例设计方法为指导，再加上设计人员个人的经验积累来设计测试用例。
2.3.1 等价类划分方法
1．等价类划分方法基本概念
如果把所有可能的输入数据分为有效等价类和无效等价类两种，那么可以做出这样的合理假定：如果等价类中的一个输入数据能发现一个缺陷，那么等价类中其他输入数据也能发现同一个缺陷；反之，如果一个输入数据不能发现某个错误，那么等价类中其他输入数据也不能发现这一错误。
有效等价类是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。
与有效等价类恰巧相反，无效等价类是指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。对于具体的问题，无效等价类至少应有一个，也可能有多个。
等价类分析法不但可以针对输入数据，而且可以针对输出数据进行划分。总之，他们发现缺陷的概率是等效的。
2．等价类划分方法设计用例的原则
●如果输入条件规定了取值范围，或者值的个数，则可以确定一个有效等价类和两个无效等价类；
●如果输入条件规定了输入值的集合，或者是规定了“必须如何”的条件，这时可以确立一个有效等价类和一个无效等价类；
●如果输入条件是一个布尔量，则可以确立一个有效等价类和一个无效等价类；
●如果规定了输入数据的一组值，则程序要对每一个输入值分别进行处理；这时要对每一个规定的输入值确立一个等价类，并且对于这组值之外的所有值也都确立一个等价类；
●如果规定了输入数据必须遵守的规则，则可以确立一个有效等价类（即遵守规则的数据）和若干无效等价类（从不同角度违反规则的数据）；
●如果已划分的等价类中的各元素在程序中的处理方式不同，则应进一步划分成更小的等价类。
3．利用等价类划分方法选择用例
●为每一个等价类规定一个唯一的编号；
●设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类；重复这一步骤，直到所有的无效等价类都被覆盖为止；
●设计一个新的测试用例，使其仅覆盖一个无效等价类，重复这一步骤，直到所有的无效等价类都被覆盖为止。
【举例1】以短消息编辑用户场景为例。
第一步：为每一个等价类和无效等价类规定一个唯一的编号，如表2.1所示。
表2.1 输入字符有效等价类
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 常见边界值
手机软件测试过程中，常需要考虑的边界值如下：
●短消息在default 7bit alphabet编码时边界为0～160；UCS-2编码时边界为0～70；
●对16-bit的整数而言32767和-32768是边界；
●屏幕上光标在最左上、最右下位置；
●报表的第一行和最后一行；
●数组元素的第一个和最后一个；
●循环的第0次、第1次和倒数第2次、最后一次。
等价类划分是一种用例设计的思想，是按照输入项和输出项的情况把要执行的具体测试用例划分成等价类和无效等价类两种，然后执行测试。边界值分析也是设计用例时的指导思想，它是在具体执行测试用例时要用到的一种测试技巧（取边界值）。具体实施用例设计时往往要两者结合考虑，一起使用。现以编辑一个彩信测试用例为例，输入项的划分如表2.8所示。
表2.8 输入项划分
5.1 测试环境搭建
5.1.1 环境搭建重要性和要素
众所周知，没有测试环境根本无法执行测试。对搭建测试环境的考虑应该跟测试活动本身一起被计划。假如你现在想在真实网络环境下验证集成后的模块功能，恰好你所处环境没有网络覆盖，显然测试将无法执行。
然而终端测试环境很多，通常需要准备硬件可靠性测试、环境适应性测试、一致性测试和外场测试等各类环境。为了更好地回答“怎么搭建测试环境？”、“为什么要搭建测试环境？”等问题，本章着重讨论针对手机软件测试的环境。
目前，终端厂商越来越注重人机界面、功能齐全的应用、智能的操作系统，故测试工程师要应对的测试要求也越来越多。并且测试的好坏直接取决于应用业务测试环境的搭建，所以测试质量不仅取决于在建好的测试环境下对功能点测试覆盖情况，还取决于在建好的测试环境下对终端或业务互连互通要求的测试覆盖情况。
在3G牌照发放初期，网络覆盖较差的情况下，多样化的双模终端推广便是当时的工作重点。所以，关键的测试是双模机切换控制、业务兼容、机卡兼容、终端耗电、漫游等。
在3G全球商用推广阶段，3G终端不仅要解决芯片方案、操作系统、电源技术的部分，还要解决个性化的业务应用、定制化的软件功能、丰富的3G业务的部分。因此，只满足手机软件功能的测试是不够的，手机软件的性能测试、平台或应用业务的认证测试也势在必行。
在互联网全面普及的今天，用户对终端的外观感受、终端的使用质量、人机交互的便利、音视频高保真、网络数据的带宽、视频的品质、互联网大量免费的内容等需求越来越多，故大量业务仿真模拟测试，集成应用的测试都将越来越难。
为了更好地满足以上手机应用软件的业务规范，满足终端的测试规范，满足运营商定制手机的要求，在进行手机的人机界面设计和应用软件测试环境搭建时应该考虑如下的问题。
●配置。准备要测试的手机，将其选择默认配置或置于正确的起始状态，否则测试结果会受到不良变量的影响。
●运行。向手机输入数据，向网络、终端本身或终端上SIM卡发命令，以某种方式与被测手机进行交互。否则，测试工程师能够做的只是静态的评审，而不是动态的测试。
●观察。收集有关手机的响应信息、输出数据、系统整体状态、人机界面输出与其他实体的交互等方面的信息。如果测试工程师不能很好地观察所有事物，那就看不到问题所在。
●评估。参考对照业务规范，运用逻辑推理或业务流程分析测试所观察到的数据中存在的问题，否则就无法根据对数据的分析汇总出报告，进行评估。
模拟环境要能全面地模拟出业务系统所能实现的功能，以贴近真实用户使用环境。
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.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，终端支持通过短信承载来发送到最终用户。
从用户使用角度考虑，终端需要支持超长短信和群发短信功能。
第七章手机一致性测试
本章要点：
● 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、数据包通信、彩信、可视电话、补充业务等各项业务测试，用户就可以专注于开发上层的应用软件，从而加快开发的进程。
移动APP测试方案及流程 作者: 心来心去来源: 51Testing软件测试网采编 针对app的测试过程和重点关注内容，做以下梳理和总结。 1、首先是测试资源确认及准备 （1）产品需求文档、产品原型图、接口说明文档以及设计说明文档等应齐全； （2）测试设备及工具的准备：IOS和andriod不同版本的真机，以及相关测试工具的准备。 2、测试用例的设计与评审 （1）根据产品需求文档、产品原型图等文档，设计客户端的一般功能测试用例； （2）测试用例评审、修改与完善，评审通过后着手进入正式测试阶段。 3、UI测试 （1）确保手头的原型图与效果图为当前最新版本，符合产品经理及用户要求； （2）测试过程中一切以效果图为准，若有用户体验方面的建议，可以先以邮件的形式与产品经理确认，确认通过后，可以正式向开发提出用户体验方面的问题； （3）由于测试环境中的数据为模拟数据，测试时必须预先考虑到正式环境中可能出现的数据类型。 4、功能测试 （1）功能测试时主要依据编写的功能测试用例进行软件功能的遍历； （2）涉及的测试主要包括基本功能测试，安装、卸载、运行测试，异常处理（包括网络突然断开或者网速过慢、机器内存不足等异常情况的处理）测试。 5、中断测试 （1）软件运行过程中接电话、收短信、锁屏、闹铃、充电，收到通知提醒后再使用软件，软件应仍可正常运行使用； （2）软件运行时，由前台切换到后台，再切回前台后，应仍可正常运行使用。 6、兼容性及适配测试 （1）硬件的适配：不同手机厂商、硬件性能，不同屏幕大小的适配； （2）OS版本的兼容：IOS6-9；Andriod3以上等，如果用了一些新的API在老的系统上不支持会导致crash； （3）不同分辨率屏幕的适配：移动设备的分辨率多种多样，如果app没有做比较合适的处理就可能会显示不好，甚至影响功能的操作。
1 APP测试基本流程 1.1流程图 仍然为测试环境
1.2测试周期 测试周期可按项目的开发周期来确定测试时间，一般测试时间为两三周（即15个工作日），根据项目情况以及版本质量可适当缩短或延长测试时间。正式测试前先向主管确认项目排期。 1.3测试资源 测试任务开始前，检查各项测试资源。 --产品功能需求文档； --产品原型图； --产品效果图； --行为统计分析定义文档； --测试设备（ios3.1.3-ios5.0.1；Android1.6-Android4.0；Winphone7.1及以上；Symbian v3/v5/Nokia Belle等）； --其他。 1.4日报及产品上线报告 1）测试人员每天需对所测项目发送测试日报。 2）测试日报所包含的内容为： --对当前测试版本质量进行分级； --对较严重的问题进行例举，提示开发人员优先修改； --对版本的整体情况进行评估。 3）产品上线前，测试人员发送产品上线报告。 4）上线报告所包含的内容为： ---对当前版本质量进行分级； ---附上测试报告（功能测试报告、兼容性测试报告、性能测试报告以及app可用性能标准结果）； --总结上线版本的基本情况。若有遗留问题必须列出并记录解决方案。
2 App测试点 2.1安全测试 2.1.1软件权限 1）扣费风险：包括发送短信、拨打电话、连接网络等 2）隐私泄露风险：包括访问手机信息、访问联系人信息等 3）对App的输入有效性校验、认证、授权、敏感数据存储、数据加密等方面进行检测 4）限制/允许使用手机功能接入互联网 5）限制/允许使用手机发送接受信息功能 6）限制/允许应用程序来注册自动启动应用程序 7）限制或使用本地连接 8）限制/允许使用手机拍照或录音 9）限制/允许使用手机读取用户数据 10) 限制/允许使用手机写人用户数据 11) 检测App的用户授权级别、数据泄漏、非法授权访问等 2.1.2安装与卸载安全性 1）应用程序应能正确安装到设备驱动程序上 2）能够在安装设备驱动程序上找到应用程序的相应图标 3）是否包含数字签名信息 4）JAD文件和JAR包中包含的所有托管属性及其值必需是正确的 5）JAD文件显示的资料内容与应用程序显示的资料内容应一致 6）安装路径应能指定 7）没有用户的允许, 应用程序不能预先设定自动启动 8）卸载是否安全, 其安装进去的文件是否全部卸载 9）卸载用户使用过程中产生的文件是否有提示 10）其修改的配置信息是否复原 11）卸载是否影响其他软件的功能 12）卸载应该移除所有的文件 2.1.3数据安全性 1）当将密码或其他的敏感数据输入到应用程序时, 其不会被储存在设备中, 同时密码也不会被解码 2）输人的密码将不以明文形式进行显示
手机APP测试总结报告
目录 1.测试概述 (1) 1.1. 编写目的 (1) 1.2. 测试范围 (1) 2. 测试计划执行情况 (1) 2.1. 测试类型 (1) 2.2. 测试环境与配置 (3) 2.3. 测试人员 (3) 2.4. 测试问题总结 (3) 3. 测试总结 (4) 3.0.程序流程 图 (3) 3.1.测试用例执行结果 (4) 3.2. 安全测试 (6) 3.2.1. 软件权限 (7) 3.2.2. 安装与卸载安全性 (7) 3.2.2. 数据安全性 (8) 3.2.3. 通讯安全性 (9) 3.2.4. 人机接口安全性 (10) 3.3. 安装、卸载测试 (11) 3.3.1. 安装 (11)
3.3.2. 卸载 (11) 3.4. UI测试 (12) 3.4.1. 导航测试 (12) 3.4.2. 图形测试 (12) 3.4.3. 内容测试 (13) 3.5. 功能测试 (13) 3.5.1. 运行 (13) 3.5.2. 注册 (13) 3.5.3. 登录 (14) 3.5.4. 注销 (14) 3.5.5. 应用的前后台切换 (15) 3.5.6. 免登入 (15) 3.5.7. 数据更新 (16) 3.5.8. 离线浏览 (16) 3.5.9. APP更新 (17) 3.5.10. 时间测试 (17) 3.5.11. 性能测试 (17) 3.5.12. 交叉性事件测试 (17) 3.6. 兼容测试 (18) 3.7. 用户体验测试 (19) 4. 测试结果 (19) 软件缺
陷 (15)
1.测试概述 1.1.编写目的 本测试报告为招标手机APP的测试报告，目的在于总结测试阶段的测试情况以及分析测试结果，描述系统是否符合用户需求，是否已达到用户预期的功能目标，并对测试质量进行分析。 测试报告参考文档提供给用户、测试人员、开发人员、项目管理者、其他管理人员和需要阅读本报告的高层经理阅读。 1.2.测试范围 测试主要根据用户需求说明书和软件需求规格说明书以及相应的文档进行系统测试，包括功能测试、性能测试、安全性和访问控制测试、用户界面测试以及兼容性测试等，而单元测试和集成测试由开发人员来执行。 主要功能包括：用户登录、我的项目、推荐项目订阅、软件设置、我的收藏、消息中心，借阅同步等。 2.测试计划执行情况 2.1.测试类型
手机App测试策略和流程目录
1.引言 本文档是长春吉大正元信息技术股份有限公司东北公司手机APP测试的工作指导原则，它为手机APP测试过程中涉及到的测试方法、测试类型等制定标准做出明确的诠释和说明。 测试部门相关人员以此文档作为测试工作的依据和行为准则。 编写目的 本规范规定了东北公司手机APP测试过程中的活动和步骤。为公司测试（活动、产品）的实施和过程情况的各项检查提供依据；为度量被测试产品质量提供验证指标和验证方法。 适用范围 适用于长春吉大正元信息技术股份有限公司东北分公司测试部。 适用于：手机APP项目和产品的系统测试 针对手机APP的验证测试（外包项目）不在此范围之内，如需确保重点项目的手机APP质量度量和评价，需领导特殊审核。 2.测试过程描述 验证测试先决条件 对当前项目测试优先级进行划分： 产品大于项目优先级； 自主项目大于外包项目优先级； 重大项目（领导特批）大于客户化项目； 提前申请优先级大于变更申请优先级。(例如：监狱项目提前申请预留或者安排 测试员提前介入) 对当前测试版本质量进行评级：对于不符合测试准入原则的版本予以驳回。 验证测试三天后对提交版本进行质量预评估和评级：对第一轮发现较严重的问题进行列 举，对版本的整体情况进行评估。（详见BUG清单）对于不能度量质量的项目予以驳回 自测试。（例如：监狱移动OA项目）。 外埠公司提交测试前。应附上测试报告（功能测试报告、兼容性测试报告、性能测试报 告以及app可用性能标准结果）；?公司内部提交测试前，需附上缺陷记录和修改状态表。 上述有一项不能满足或不能按时提交予以测试驳回。 总结提交测试版本的内部测试情况（测试BUG列表）。对遗留问题必须列出并记录解决 方案。对性能和稳定性指标要予以详细描述。 测试周期 测试周期可按项目的开发周期来确定测试时间，一般客户化项目手机APP测试时间为三周（即15个工作日），根据项目情况以及版本质量标准可适当缩短或延长测试时间。正式测试前先向测试部经理确认项目排期。 需提供资源 测试任务开始前，检查各项测试资源是否提交，有两项没有提交予以测试驳回。 --产品功能需求文档； --产品原型图； --产品效果图； --用户使用手册； --测试设备确认表（例如：；；及以上；Symbian v3/v5/Nokia Belle等）； 轮次报告及产品上线报告
手机软件测试总结 沙晶晶 一个合格的手机软件测试工程师要掌握的东西是很多很多的。在我个人理解中，一个合格的高级手机软件测试工程师应该具有最基本的两点知识：软件测试理论知识和一定的开发技能。 1. 软件测试理论知识 这个不用多说，软件测试工程师必须要掌握的，软件测试如何融入整个开发的流程，什么时候介入，什么时候结束，如何搭建测试环境，如何设计测试用例（包括设计测试用例的方法，如：等价类划分，边界值法等），如何使用测试工具，还有测试领域专用的一些术语等等。 2. 开发技能 合格的高级软件测试工程师，编程技能不可缺少。在手机测试中，比如自动化测试，完全可以开发工具来实现自动化测试。所以掌握一门扎实的编程语言，C或者C++还是非常重要的，能够自己开发测试工具，也是一个高级手机软件测试工程师应该具备的素质。我认为我们不应该只是单纯的发现bug，而应该从更深层次的去探究这个bug 的原因，甚至可以定位bug。 另外从技能上讲，面向不同的技术方向，像操作系统、网络、通信等都要从专业上深入了解。这些是除去工作时间外必须去加强充电的部分。有这些做后盾，做起事来也会事半功倍。 另外手机测试中应该注意的问题 首先是正确性测试，正确性测试又可称为功能性测试，我们首先就是要测试所有功能是否都已实现、正确、是否满足需求规格说明。 正确性测试还要考虑到用户界面，软件产品始终是关注软件使用者——客户的体验，手机屏幕小，界面有限，所以手机软件的用户界面更需有一定的规范和标准：正确性、一致性、直观性、实用性、灵活性、舒适性便是最基本的标准。 正确性一般比较明显，比较容易发现，例如某个窗口没有被完全显示，文字没有对齐，文字拼写错误，密码输入时没有以*的形式自动屏蔽等。 一致性包括软件自身的一致性以及手机操作系统或与其它软件的一致性，具体表现在使用的术语，字体是否一致，界面的各参数风格是否前后一致等。特别也要注意中英
一：软件测试的基本流程 1.熟悉需求 2.需求评审（测试人员，开发，需求参与） 剔除需求中不合理的部分和一些无法实现的部分，有异议的地方，描述不清楚的地方。 3.编写测试计划 4.测试计划评审 5.测试分析 6.测试分析评审（交叉评审） 7.设计测试用例 8.编写测试用例 9.测试用例评审 10.冒烟测试 11.运行测试用例 12.提交BUG 13.回归测试 14.编写测试报告 二：什么是冒烟测试 冒烟测试，英文是Smoke testing。 冒烟测试的名称可以理解为该种测试耗时短，仅用一袋烟功夫足够了。也有人认为是形象地类比新电路板功基本功能检查。任何新电路板焊好后，先通电检查，如果存在设计缺陷，电路板可能会短路，板子冒烟了。 冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。 三：什么是回归测试 回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。 回归测试包括两部分：函数本身的测试、其他代码的测试。在对被修改的函数重新测试。如果函数的设计功能没有变化，直接运行函数测试就可以了。如果修改了设计功能，则要根据增减的功能点，增加或删除测试用例。另外，还要完成白盒覆盖。 函数代码的修改可能导致调用该函数的代码产生错误，所以需要测试其他代码。如果函数是私有函数并且未涉及到全局变量，应运行类测试，否则应运行工程测试。在函数列表中选择类测试或工程测试，编译运行测试工程，即可执行对其他代码的回归测试。 四：测试报告包含的内容
关于手机APP 测试流程规范 1、流程图 仍然为测试环境
测试周期 测试周期一般为两周（10个工作日），根据项目情况以及版本质量可适当缩短或延长测试时间。正式测试前先向主管确认项目排期。 1.1测试资源 测试任务开始前，检查各项测试资源。 1.产品功能需求文档 2.产品原型图 3.产品效果图 4.行为统计分析定义文档 5.测试设备（ios3.1.3-ios5.0.1；Android1.6-Android4.0；Winphone7.1及以上； Symbian v3/v5/Nokia Belle等） 6.其他（例如有秒杀专题的项目，需要规划秒杀时间表；有优惠券使用的 项目，需要申请添加优惠券数据；支付宝/银联支付功能的项目，需要提前申请支付宝/银联账户等等） 1.2测试要点 1.接收版本 A）接收测试版本的同时，需要查看程序填写的《App测试版本提交质量规范》，若符合则开始测试任务，若不符合规范，可拒绝测试。 B）日常接收版本时需要注意测试版本规范，如不符合，请开发人员重新修改合适的版本号后再次提交测试。 2.UI测试 A）确保手头的原型图与效果图为当前最新版本。 B）确保产品UI符合产品经理制定的原型图与效果图。 C）一切界面问题以效果图为准，若有用户体验方面的建议，必须先以邮件或口头的形式询问产品经理。 D）由于测试环境中的数据为模拟数据，测试时必须预先考虑到正式环境中可能出现的数据类型 3.功能测试 A）确保手头的功能需求文档为当前最新版本。 B）确保所有的软件功能都已实现且逻辑正常。 C）一切功能问题以需求文档为准，若有用户体验方面的建议，必须先以邮件或口头的形式询问产品经理。 D）若有些功能在技术上难以实现或者由于排期的原因无法在短时间内实现，必须得到产品经理的确认，而不是单单只听开发人员的技术解 释。 E）P MS上所有的“外部原因”问题，都需要尽早地督促开发人员与客
技术文件 技术文件名称：XXX手机软件测试报告技术文件编号： 版本： 共页 (包括封面) 拟制 审核 会签 标准化 批准
目录 1概述...................................................错误！未定义书签。 1.1 编写目的................................................................................. 错误！未定义书签。 1.2 术语和缩略语......................................................................... 错误！未定义书签。 1.2.1 术语、定义：................................................................. 错误！未定义书签。 1.2.2 缩略语：......................................................................... 错误！未定义书签。 1.3 参考文献................................................................................. 错误！未定义书签。2测试任务说明 .. (2) 2.1 测试活动类别 (2) 2.2 测试级别 (2) 2.3 版本变更情况......................................................................... 错误！未定义书签。 2.4 测试任务列表 (2) 3测试环境描述 (2) 3.1 测试环境描述 (2) 3.1.1 硬件环境描述 (2) 3.1.2 软件环境描述 (3) 3.2 测试环境比较 (3) 3.3 其它说明 (3) 4测试故障描述 (3) 4.1 ××××测试模块 (3) 4.2 ××××测试模块 (3) 5测试结果分析 (4) 5.1 ××××模块测试结果分析 (4) 5.2 ××××模块测试结果分析 (4) 5.3 总体测试结果分析 (4) <2.按实现结果统计：> (4) 6测试结论 (5) 7测试总结和评价 (5) 7.1 测试评估 (5) 7.2 测试总结和改进建议 (5) 8遗留问题报告 (5) 8.1 遗留问题统计 (5) 8.2 遗留问题详细列表 (6) 附录1：测试现场记录 (7)
（流程管理）软件测试的流 程
软件测试的流程，包含各阶段会产生什么文档 无论是采用瀑布式仍是其他的产品生命周期模型，软件测试分为如下几个阶段：1、测试需求分析阶段。 测试需求分析阶段主要工作是获得测试项目的测试需求（测试规格）。 输出产物：《可测试性需求说明书》和《测试规格》 2、测试计划阶段。 以测试需求为基础，分析产品的总体测试策略。 输出产物：《产品总体测试策略》 3、测试方案设计阶段。 本阶段主要是以测试规格为基础获得特性测试方案，对于有自动化测试的项目，进行自动化测试的分析，获得测试策略。 输出产物：《产品或者版本总体测试方案》 4、测试用例实现阶段。 本阶段主要是完成各个特性的测试用例的编写和自动化脚本的编写。 输出产物：《产品自动化测试用例》和《手工执行测试用例》 5、测试执行阶段。 本阶段是根据测试策略开展测试执行和回归测试。 输出产品：《产品或版本测试方案》和《缺陷分析方案》 6、评估和关闭阶段。 只对前面的各个阶段的执行情况，完成对测试项目的关闭，同时提供完整的度量数据和项目总结方案。 输出产物：《遗留问题风险分析方案》、《度量分析方案》和《测试关闭方案》软件生命周期的各个阶段如何应用哪些软件测试方法。
画壹个V模型你就明白了：左边为开发过程，对应右边的测试过程，开发自上而下，测试是自下而上 开发过程测试过程 可行性研究验收测试 需求分析系统测试 概要设计集成测试 详细设计单元测试 软件编码阶段 1、需求分析阶段对应生成需求规格说明书，对应测试生成系统测试方案，即为系统测试准备的，该阶段已经完成了单元测试和集成测试，主要是对软件产品的功能和非功能进行测试，几乎不测试代码，所以测试方法以黑盒为主； 2、概要设计阶段对应生成概要设计说明书，对应测试生成集成测试方案，该阶段已完成单元测试，是将各个功能模块组装起来进行的测试，所以也叫组装测试。主要见模块调用是否正常，接口是否可用，数据传输是否正确等，所以用到的测试方法几乎是白盒的方法，如路径覆盖，条件组合覆盖等； 3、详细设计阶段对应生成详细设计说明书，对应测试生成单元测试方案，该阶段是开发人员编码后的第壹个测试阶段，是对开发出来的单独模块进行测试，以确保每壹个功能模块的功能正常，能够构建桩模块和驱动模块来回调用，方法也是以白盒为主。 4、白盒测试的准则是尽可能覆盖程序内部的逻辑结构，黑盒则是尽可能覆盖所有的输入输出接口，包括文档等壹些静态的测试。除常用的测试方法外，仍需补充大范围的随机测试，尽可能达到覆盖率100%。
软件测试基础要点总结 软件测试基础要点总结 从宏观的角度讲，软件测试过程一般可划分为单元测试、集成测试、验收测试和系统测试等几个主要测试阶段。 1.测试计划注意事项 1．测试计划不一定要尽善尽美，但一定要切合实际，要根据项目特点、公司实际情况来编制，不能脱离实际情况； 2．测试计划一旦制定下来，并不就是一成不变的，随着软件需求、软件开发、人员流动等发生变化，测试计划也要根据实际情况的变化而不断进行调整，以满足实际测试要求．3．测试计划要能从宏观上反映项目的测试任务、测试阶段、资源需求等，不一定要太过详细．测试原则 ①应尽早和不断地进行软件“测试”。 ②测试用例中，不仅要选择合理的输入数据，还要选择不合理的输入数据。③在开发各阶段应事先分别制定出相应的测试计划，在测试开始后应严格执行，防止随意性。④对发现错误较多的程序模块，应进行重点测试。⑤避免程序员测试自己的程序。 ⑥用穷举测试是不现实的，一般通过设计测试用例，充分覆盖所有条件或所有语句即可。⑦长期妥善保存测试计划、测试用例、出错统计和有关的分析报告。 2.测试用例文档 测试用例文档通常是由简介和测试用例两部分组成：
简介部分编制了测试目的、测试范围、定义术语、参考文档等，这个与测试计划是一致的。 测试用例部分逐一列出各个测试用例。 测试用例（TestCase）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。 测试用例部分 测试用例通常包含的信息：用例标识和用例名称内容描述前提条件执行步骤预期结果评价准则 用例设计人员和设计时间用例执行人员和执行时间其它内容3.软件缺陷 缺陷的表现形式不仅体现在功能的失效方面，还体现在其他方面。主要类型有：①软件没有实现产品规格说明所要求的功能模块软件中；②出现了产品规格说明指明不应该出现的错误； ③软件实现了产品规格说明没有提到的功能模块； ④软件没有实现虽然产品规格说明没有明确提及但应该实现的目标； ⑤软件难以理解，不容易使用，运行缓慢，或从测试员的角度看，最终用户会认为不好。测试用例：以计算器为例 ①计算器的产品规格说明定应能准确无误地进行加、减、乘、除运算。如果按下加法键，没什么反应，就是第一种类型的缺陷；若计算结果出错，也是第一种类型的缺陷。②产品规格说明书还可能规定计算器不会死机，或者停止反应。如果随意敲键盘导致计算器停止接受输入，这就是第二种类型的缺陷。 ③如果使用计算器进行测试，发现除了加、减、乘、除之外还可以求平方根，但是产品规格说明没有提及这一功能模块。这是第三种类型的缺陷④在测试计算
手机软件测试规
手机软件测试规 1.目的: 用以规和统一手机产品软件测试标准。 2.围: 适用于所有手机产品的软件测试。 3. 职责 测试组负责对软件进行测试，产品项目部负责对软件存在的问题进行跟进和改善。4.测试方法 4. 1、新机型T0试产后，借用试产机，用三天时间重复测试各项功能，记录出现的异常。 4.2、总结测试中出现的异常现象，分别在每台机上验证，确认异常现象出现的机率，拟 制测试报告将其发送产品项目部，测试报告备案。 4.3、T1试产后，重新借用4台试产机，下载新软件，用二天时间重复测试各项功能， 记录出现的异常情况，后用4台机分别验证，得出测试结果。与第一次的测试结果比较，在测试报告中记录此次的改善情况，将测试报告发送产品项目部。 4.4、密切跟进软件修改进程，重复第3项操作步骤，直至软件改善的符合企业标准或国 家标准，再切入批量生产；如软件不能修正，结合实际情况，请示上层决定是否放弃修正，可以量产。 4.5、密切关注生产中出现的突发的软件问题，验证后反馈产品项目部并请迅速修正。 4.6、量产过程中的软件更新，针对软件更新容进行测试，操作同第3、4项。 5定义 软件测试出现异常分三个方面
1、A类致命缺陷致命缺陷指用户使用手机的过程中有明显障碍的问题，客户投诉等，有以下几类： （1）操作中出现重启、死机、键盘锁死、无网络、不开机等。 （2）手机无法实现菜单中所列的项目或主要功能，或与用户手册说明相冲突。（3）手机参数或功能不能通过，可能会导致客户投诉。客户不易发现但存在隐患规律。（4）手机偶尔不能工作或出现异常，引起原因不明但可以通过恢复出厂设置或复位电池恢复正常，测试较难重复。 2、B类轻微缺陷轻微缺陷是指该问题会影响用户使用手机，有以下几类： （1）手机界面不友好，不影响用户使用，但会导致手机界面异常。 （2）某项功能设计不合理不完整，但不会对用户使用造成明显障碍问题。 （3）与方案公司达成共识以后待修改容。 3、C类隐患缺陷隐患缺陷是指可能会造成用户投诉的问题，有以下几类 （1）由设计缺限存在的问题，出现的机率极低，客户不易发现。 （2）问题存在不影响使用，部分用户可以接受，设计定义问题。 （3）因平台局限，无法修改的问题通过协调后关闭。 6、流程图: 新机型软件
软件测试基本流程与规范 1目标 制定完整且具体的测试路线和流程，为快速、高效和高质量的软件测试提供基础流程框架。 最终目标是实现软件测试规范化，标准化。 2测试流程说明
3测试需求分析 测试需求是整个测试过程的基础；确定测试对象以及测试工作的范围和作用。用来确定整个测试工作（如安排时间表、测试设计等）并作为测试覆盖的基础。而且被确定的测试需求项必须是可核实的。即，它们必须有一个可观察、可评测的结果。无法核实的需求不是测试需求。所以我现在的理解是测试需求是一个比较大的概念，它是在整个测试计划文档中体现出来的，不是类似的一个用例或者其他. ·测试需求是制订测试计划的基本依据，确定了测试需求能够为测试计划提供客观依据； ·测试需求是设计测试用例的指导，确定了要测什么、测哪些方面后才能有针对性的设计测试用例； ·测试需求是计算测试覆盖的分母，没有测试需求就无法有效地进行测试覆盖； 3.1测试方法与规范 3.1.1测试方法 随着软件技术发展，项目类型越来越多样化。根据项目类型应选用针对性强的测试方法，合适的测试方法可以让我们事半功倍。以下是针对目前项目工程可以参考的测试方法： ?β测试（beta测试）--非程序员、测试人员 β测试，英文是Beta testing。又称Beta测试，用户验收测试（UAT）。 β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。 当开发和测试根本完成时所做的测试，而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员完成，不能由程序员或测试员完成。?α测试（Alpha测试）--非程序员、测试人员 α测试，英文是Alpha testing。又称Alpha测试. Alpha测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由该系统的程序员或测试员完成。 在系统开发接近完成时对应用系统的测试;测试后，仍然会有少量的设计变更。这种测试一般由最终用户或其他人员来完成，不能由程序员或测试员完成。?兼容性测试 --测试人员 兼容性测试是指测试软件是否可以成功移植到指定的硬件或者软件环境中，例如在B/S项目中各个不同浏览器之间的测试。 ?用户界面测试-UI测试--测试人员 用户界面测试，英文是User interface testing。又称UI测试。 用户界面，英文是User interface。是指软件中的可见外观及其底层与用户交互的部分（菜单、对话框、窗口和其它控件）。
手机app 测试用例 目录 目录 (1) 1. 用户登录 (3) 1.1用户登录流程 (3) 1.1.1游客登录 (3) 1.1.2微信登录 (3) 1.1.3正常账号登录 (4) 1.2接口要素检验 (4) 2. 用户注册 (5) 2.1用户注册流程 (5) 2.1.1正常注册 (5) 2.2接口要素检验 (5) 3. 个人中心 (6) 3.1正常用户个人中心 (6) 3.1.1推广收益 (6) 3.1.2昵称修改 (7) 3.1.3修改头像 (7) 3.2游客与微信用户个人中心 (7) 3.2.1推广收益 (7) 3.2.2一键转正 (8) 3.2.3昵称修改 (8) 3.2.4修改头像 (8) 3.3接口要素检验 (8) 4. 安全中心 (10) 4.1正常用户安全中心 (10) 4.1.1修改密码 (10) 4.1.2密保问题 (10) 4.1.3绑定手机 (11) 4.1.4实名认证 (11) 4.2游客与微信用户安全中心 (11) 4.2.1绑定手机 (11) 4.2.2实名认证 (12) 4.3接口要素检验 (12) 5. 设置 (13) 5.1功能设置 (13)
5.1.1背景音乐 (13) 5.1.2音效音乐 (14) 5.1.3音量控制 (14) 5.1.4退出app (14) 5.1.5账号切换 (14) 5.2app规则 (15) 5.3意见反馈 (15) 5.3.1发送反馈意见 (15) 5.4客服服务 (15) 5.5关于手机 (16) 5.5.1检查更新 (16) 5.5.2服务协议与隐私说明 (16) 6. 常用功能栏 (16) 6.1银行 (17) 6.1.1开通银行 (17) 6.1.2登录银行 (17) 6.1.3存款 (17) 6.1.4取款 (17) 6.2背包 (18) 6.3好友 (18) 6.3.1我的好友 (18) 6.3.2临时好友 (19) 6.3.3查找好友 (20) 6.4活动 (20) 6.4.1系统信息 (20) 6.4.2活动中心 (20) 6.5充值 (21) 6.5.1微信支付 (21) 6.5.2支付宝支付 (21) 6.5.3银联支付 (21) 6.6商城 (22) 6.6.1道具商城 (22) 6.6.2礼品商城 (22) 6.6.3兑换记录 (23) 6.7福利 (23) 6.7.1会员特权 (23) 6.7.2破产补助 (23) 6.7.3每日签到 (23) 6.7.4首冲奖励 (24) 6.7.5每日抽奖 (24) 6.8更多 (24) 6.8.1兑换码 (24) 6.8.2分享 (24) 6.9接口要素检验 (25)
软件测试的目的 软件测试的目的是为了保证产品的最终质量，在软件开发的过程中，对软件产品进行质量控制，提高软件的可靠性。 测试在软件开发中的作用 ● 由于现在软件的规模越来越大，一个人或者少数几个人已经不可能在一定的时间内完成一个 软件，所以软件开发的过程越来越复杂，层次越来越深。这就导致开发人员之间的沟通有了一定的隔阂。所以，软件测试越来越有单立出来的必要和重要性。 ● 由于软件开发的过程的复杂性，软件必然存在着无数的Bug 。而且大多数是在软件上市前必 须解决的，而开发者有不定能发现这些问题，故而测试就显得非常必要。测试是开发成功的必要保障。 ● 由于软件开发的层次性，所以开发的结果很可能与初衷不一样，这就需要测试者去发现这些 差异。因此，测试是软件成功的重要保证。 ● 软件不仅要实现一些功能，更要完善它的性能。这就需要测试人员对软件进行评测，从而不 断地完善软件的性能。 手机软件测试介入开发时间 开发阶段测试准备阶段测试执行阶段 测试总结阶段
手机软件测试流程 1 制定测试计划 ● 开启测试项目 ● 根据用户需求报告中关于功能要求和性能指标的规格说明书，定义相应的测试需求报 告，即制订黑盒测试的最高标准，以后所有的测试工作都将围绕着测试需求来进行，符合测试需求的应用程序即是合格的，反之即是不合格的；同时，还要适当选择测试内容，合理安排测试人员、测试时间及测试资源等。 test plan.doc 2 测试准备 ● 在计划制定好之后，在执行之前，必须将测试所需的人力资源，硬件资源，软件资源， 文档资源以及环境和人文资源准备充分 ● 将测试计划阶段制订的测试需求分解、细化为若干个可执行的测试过程，并为每个测 试过程选择适当的测试用例（测试用例选择的好坏将直接影响到测试结果的有效性） MTK平台测试用例（王丙振）.xls 软件缺陷级别定义.doc zxxxx测试策略模版 .doc 3 测试执行 ● 测试组根据测试计划和测试日程安排进行测试，并输出测试结果 ● 执行测试开发阶段建立的测试过程，并对所发现的缺陷进行跟踪管理。测试执行一般 由单元测试、组合测试、集成测试、系统测试及回归测试等步骤组成，测试人员应本着科学负责的态度，一步一个脚印地进行测试。 zxxxx软件测试报告 模版.doc 4 测试评估 ● 有测试结果评估小组或评估人员对测试结果进行评测，分析，并输出分析结果 ● 结合量化的测试覆盖域及缺陷跟踪报告，对于应用软件的质量和开发团队的工作进度 及工作效率进行综合评价。
软件测试流程规划 一、引言 本文档规范了软件测试过程中的整体流程，明确了软件测试从开始到结束的各个阶段，以及在各阶段中的负责人、具体工作内容和必需的输入输出文档。另外，本文还介绍了各测试阶段需要的测试工具、测试点和测试步骤，并提供了各类测试文档的参考模板。 二、测试流程概述 1、流程介绍 一般来讲，软件测试是伴随着项目的立项而开始的。也就是说，软件项目一旦确立，测试工作也就开始了。在测试的过程中，前后要经过以下主要环节： 需求分析—>制定测试计划—>搭建测试环境—>测试用例设计—>测试执行—>BUG回归测试—>测试总结—>软件发布 对于以上流程环节，一般而言，需求分析属于需求分析人员的工作范畴，环境搭建、用例设计、测试执行以及回归测试等属于测试人员的工作范畴，测试负责人负责制定测试计划以及对各个环节的跟踪、实施、管理等。 2、流程图 功能测试 项目开始 需求阶段 测试计划 测试阶段 性能测试 用户界面测试 兼容性测试 安全性测试 接口测试 测试总结 软件发布
在这个阶段，主要是对于需求的收集、分析以及评估。 1.由需求分析人员统一收集需求，并整理成文档格式转发给项目经理、开发经理和测试经理； 2.项目经理召集开发经理、测试经理和需求分析人员进行会议讨论，了解具体每个需求的实际含义，并且明确各需求的有效性和可用性； 3.小组会议讨论，确定最终实现的需求和功能点，并整理出重点需求； 4.项目经理根据会议讨论结果编写需求说明，并且再次召集小组开会讨论，对需求说明进行修复、完善，并最终确定《需求规格说明书》。 负责人：项目经理 输入文档：需求说明文档 输出文档：《需求规格说明书》 四、测试计划阶段 作为测试的起始步骤和重要环节，测试计划是对测试全过程的组织、资源、原则等进行规定和约束，并制定测试全过程各个阶段的任务以及时间进度安排，并提出对各项任务的评估、风险分析和管理需求。用一句话概括就是：测试计划是从管理角度对整个测试活动进行规划和控制。 测试计划的主要内容可分以下几个方面： 1.测试概述（介绍项目测试的范围、目的以及组织形式） 2.测试进度（测试时间周期的安排） 3.测试策略（包括测试环境、测试工具及测试方法） 4.需求跟踪（确定系统测试项与需求之间的对应关系） 5.测试通过失败标准（指明测试何时通过何时结束） 6.测试挂起恢复标准（指明当测试过程无法进行下去时测试活动挂起以及恢复的标准） 7.资源分配（工作量的统计以及工作任务的安排） 8.应交付测试工作产品（明确测试需要提交的各类工作文档） 9.风险评估（预估测试存在的风险） 测试经理根据项目的总体进度、发布时间以及需求规格说明、开发计划制定相应的测试计划，完成后提交给项目经理。项目经理组织讨论会，连同开发经理、测试经理以及各模块负责人，对测试计划进行评审并确定。 负责人：测试经理 输入文档：《需求规格说明书》、《软件开发计划》 输出文档：《软件测试计划》
软件测试基本流程与要求（提纲） 1目标 制定完整且具体的测试路线和流程，为快速、高效和高质量的软件测试提供基础流程框架。 最终目标是实现软件测试规范化，标准化。 2测试流程说明
3测试需求分析 测试需求是整个测试过程的基础；确定测试对象以及测试工作的范围和作用。用来确定整个测试工作（如安排时间表、测试设计等）并作为测试覆盖的基础。而且被确定的测试需求项必须是可核实的。即，它们必须有一个可观察、可评测的结果。无法核实的需求不是测试需求。所以我现在的理解是测试需求是一个比较大的概念，它是在整个测试计划文档中体现出来的，不是类似的一个用例或者其他. ·测试需求是制订测试计划的基本依据，确定了测试需求能够为测试计划提供客观依据； ·测试需求是设计测试用例的指导，确定了要测什么、测哪些方面后才能有针对性的设计测试用例； ·测试需求是计算测试覆盖的分母，没有测试需求就无法有效地进行测试覆盖； 3.1测试方法与规范 3.1.1测试方法 随着软件技术发展，项目类型越来越多样化。根据项目类型应选用针对性强的测试方法，合适的测试方法可以让我们事半功倍。以下是针对目前项目工程可以参考的测试方法： ?β测试（beta测试）--非程序员、测试人员 β测试，英文是Beta testing。又称Beta测试，用户验收测试（UAT）。
β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。 当开发和测试根本完成时所做的测试，而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员完成，不能由程序员或测试员完成。?α测试（Alpha测试）--非程序员、测试人员 α测试，英文是Alpha testing。又称Alpha测试. Alpha测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由该系统的程序员或测试员完成。 在系统开发接近完成时对应用系统的测试;测试后，仍然会有少量的设计变更。这种测试一般由最终用户或其他人员来完成，不能由程序员或测试员完成。?兼容性测试--测试人员 兼容性测试是指测试软件是否可以成功移植到指定的硬件或者软件环境中，例如在B/S项目中各个不同浏览器之间的测试。 ?用户界面测试-UI测试--测试人员 用户界面测试，英文是User interface testing。又称UI测试。 用户界面，英文是User interface。是指软件中的可见外观及其底层与用户交互的部分（菜单、对话框、窗口和其它控件）。 用户界面测试是指测试用户界面的风格是否满足客户要求，文字是否正确，页面是否美观，文字，图片组合是否完美，操作是否友好等等。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。
手机应用软件测试经验总结 随着科技的进步，手机款型可谓日新月异，功能也越来越丰富。相应的，越来越多的手机应用软件也伴随着手机功能的多样化应运而生。面对种类众多的手机应用软件，该如何进行测试，测试时又需要重点关注什么呢？本文档结合本人在产品手机项目测试过程中的经验，浅谈下手机应用软件测试相关知识。 对于产品的手机项目（应用软件），主要是进行系统测试。而针对手机应用软件的系统测试，我们通常从如下几个角度开展：功能模块测试，交叉事件测试，压力测试，容量测试，兼容性测试，易用性/用户体验测试等。 1、功能模块测试：首先应分析功能模块的功能项，测试每个功能项是否能够实现对应的功能。一般根据测试用例（Test Case）或软件本身的流程就可以完成基本功能测试（相对简单，故障也较容易发现、解决）。 2、交叉事件测试：又叫事件或冲突测试，是指一个功能正在执行过程中，同时另外一个事件或操作对该过程进行干扰的测试。例如通话过程中接收到短信或闹铃触发，应用软件运行过程中插拔充电器等。执行干扰的冲突事件不能导致应用软件异常、手机死机或花屏等严重问题。另外，还需要注意各交叉事件的优先级别，检验系统是否能依据各事件的优先级别依次进行处理。不能因执行优先级别高的事件而导致优先级较低的事件吊死。 交叉事件测试非常重要，一般能发现应用软件中一些潜在的问题。另外有中英文模式切换的手机要注意中英文模式切换后的功能实现存在的问题（这个主要针对手机应用软件支持语言自适应功能），这一点通常会被测试人员忽略。 4、压力测试：又叫边界值容错测试或极限负载测试。即测试过程中，已经达到某一软件功能的最大容量、边界值或最大的承载极限，仍然对其进行相关操作。例如连续进行短信的接收和发送，超过收件箱和SIM卡所能存储的最大条数，仍然进行短消息的接收或发送，以此来检测软件在超常态条件下的表现，进而评估用户能否接受。
手机软件测试规范
更多免费资料下载请进：https://www.doczj.com/doc/7b8862172.html, 好好学习社区 手机软件测试规范 1.目的: 用以规范和统一手机产品软件测试标准。
2.范围: 适用于所有手机产品的软件测试。 3. 职责 测试组负责对软件进行测试，产品项目部负责对软件存在的问题进行跟进和改善。 4.测试方法 4. 1、新机型T0试产后，借用试产机，用三天时刻重复测试各项功能，记录出现的异常。 4.2、总结测试中出现的异常现象，分不在每台机上验证，确认异常现 象出现的机率，拟制测试报告将其发送产品项目部，测试报告备案。 4.3、T1试产后，重新借用4台试产机，下载新软件，用二天时刻重复 测试各项功能，记录出现的异常情况，后用4台机分不验证，得出 测试结果。与第一次的测试结果比较，在测试报告中记录此次的改 善情况，将测试报告发送产品项目部。 4.4、紧密跟进软件修改进程，重复第3项操作步骤，直至软件改善的 符合企业标准或国家标准，再切入批量生产；如软件不能修正，结 合实际情况，请示上层决定是否放弃修正，能够量产。 4.5、紧密关注生产中出现的突发的软件问题，验证后反馈产品项目部 并请迅速修正。 4.6、量产过程中的软件更新，针对软件更新内容进行测试，操作同第 3、4项。 5定义 软件测试出现异常分三个方面 1、A类致命缺陷致命缺陷指用户使用手机的过程中有明显障碍的问题，客户投诉等，有以下几类：
（1）操作中出现重启、死机、键盘锁死、无网络、不开机等。 （2）手机无法实现菜单中所列的项目或要紧功能，或与用户手册讲明相冲突。 （3）手机参数或功能不能通过，可能会导致客户投诉。客户不易发觉但存在隐患规律。 （4）手机间或不能工作或出现异常，引起缘故不明但能够通过恢复出厂设置或复位电池恢复正常，测试较难重复。 2、B类轻微缺陷轻微缺陷是指该问题会阻碍用户使用手机，有以下几类： （1）手机界面不友好，不阻碍用户使用，但会导致手机界面异常。 （2）某项功能设计不合理不完整，但可不能对用户使用造成明显障碍问题。 （3）与方案公司达成共识以后待修改内容。 3、C类隐患缺陷隐患缺陷是指可能会造成用户投诉的问题，有以下几类 （1）由设计缺限存在的问题，出现的机率极低，客户不易发觉。 （2）问题存在不阻碍使用，部分用户能够同意，设计定义问题。 （3）因平台局限，无法修改的问题通过协调后关闭。 6、流程图: 新机型