第一篇：手机短信功能测试用例
可复用测试用例研究
0、引言
软件测试的关键环节是设计和执行测试用例。测试用例的质量与测试人员的技能、经验以及对被测软件的理解密切相关。如果测试人员对被测软件不甚了解，很难在短时间内设计出有效的测试用例;有的测试用例虽然面面俱到，但冗余现象严重，浪费时间、人力和物力。
随着软件复用技术的发展，测试复用引起了人们的极大关注，特别是对测试用例复用的研究。所谓测试用例复用，就是对一个软件的已执行的测试用例，将其不同程度地应用于该软件新的测试中或其他软件的测试中。测试用例复用是可行和必要的，表现在：1)软件测试对测试人员的经验和技能要求高，通过复用，可提高测试人员技能，解决其经验不足的问题，同时提高软件测试质量;2)软件测试是当前保证软件质量的一种有效手段，但其占用软件开发周期时间长，通过复用，可避免大量重复性劳动，缩短测试周期，提高效率;3)伴随着同一个软件的生存周期，软件经历了单元测试、集成测试、确认测试和系统测试，这一过程产生了成百上千的经过执行确认的高质量的测试用例，在前一测试阶段执行过的一些测试用例可在后续测试阶段中使用，包括在回归测试、维护阶段的版本升级和纠错测试中都可使用;4)同一领域或相同系统架构的不同软件，存在着测试用例复用的可能性，且随着软件复用技术的发展，很多有价值的组件可供使用，这也使测试用例复用成为可能。
由于软件的抽象性、复杂性和多样性，使得软件测试成为一项复杂的、需要智慧和创造性的工作，要实现测试用例复用并不是一件简单的事情。但测试用例复用是软件测试发展的一个必然趋势。本文从可复用测试用例的评估、描述、设计和使用四个方面对测试用例进行了系统研究，提出了可复用测试用例应具有的特性，为评估测试用例的可复用性提供准则;给出了可复用测试用例的系统描述要素，为规范和使用可复用测试用例提供了基础;提出了面向复用的测试用例设计过程和基于复用的软件测试模型，为测试用例复用提供了方法和实现策略。本文的研究内容在某类实时系统软件测试中进行了应用，证明是有效和科学的。
1、可复用测试用例特性
文献中定义了可复用测试用例的六个特性：通用性、简洁性、独立性、有效性、灵活性和检索方便。本文对大量测试用例和测试用例复用的各种应用情况进行了分析，认为可复用测试用例应具有以下特性：通用性、有效性、独立性、标准化和完整性，它们对可复用测试用例而言是充分的也是必要的。上述特性可作为评判一个测试用例是否具有可复用性的准则。
1)通用性。通用性是指可复用测试用例并不局限于具体的应用，不过分依赖于被测软件的需求、设计和环境，能够在某一类型、某一领域的相似软件的测试中广泛使用。
当前绝大多数的测试用例都不具有通用性，这样的测试用例只能用于被测软件和其当前环境，不可能用到其他软件中。
2)有效性。测试用例的目标是发现软件问题，因此，可复用测试用例也必须是能够发现软件问题的，并且是可靠和高效的。
3)独立性。可复用测试用例的独立性是指，对于测试需求R1和R2，测试用例集分别为cl和C2，c1和c2的交集为空，并且，每个可复用测试用例能够独立运行。测试用例是否具有独立性，决定了测试用例可复用能力的强弱。
如果测试用例之间存在着相互联系，或测试用例的运行环境取决于其他测试用例的执行状态，那么，其中的测试用例不能复用时，与之相关的测试用例的可复用性也不复存在。
如何将测试用例的关联性降至最低，是设计可复用测试用例必须解决的问题。首先，每个测试用例的目标应尽量独立、单一;其次，测试用例不包含过多的具体实现细节。
4)标准化。测试用例通常用自然语言来描述，充分体现了测试人员的创造性和个人风格。但对于可复用测试用例，太多的个人风格不利于其他测试人员对测试用例的理解，必然影响其复用。因此可复用测试用例的标准化程度也反映了其易理解和可复用的能力。为此可复用测试用例应遵循统一或规范的格式或结构，规范的命名规则，使用术语、用简明、易懂、无歧义的语言来描述，并且具有详细的文档。
5)完整性。每个可复用测试用例应包括全部应有的要素，不能有缺失，并且每个要素的描述是充分的。文献规定了测试用例应包括的要素，但对于可复用测试用例而言是不够的，应加以补充。
2、面向复用的测试用例设计过程
当前，测试用例设计都砥向不同的具体应用，与被测软件是紧耦合的。考虑到复用的目的，测试用例的设计应不同于以往。本文提出了面向复用的测试用例设计过程，给出了设计过程中应实施的各项活动，主要包括被测软件(系统)共性分析、测试策略分析、设计测试用例、测试用例评审、测试用例执行和修改、测试用例入库共六个步骤，如图l所示。该过程对现有测试用例的复用处理也是适用的。
2.1共性分析
同一领域或相同架构的软件存在着共性需求。通过共性分析或领域分析，并结合任务分析等方法，梳理出被测软件所属领域或相同类型软件的相同或相似特征及需求，例如，工作流程、共性场景、功能、性能等，从而挖掘出可复用点，例如，相对独立且类似的功能、相同的构件、相似的业务流程。该步骤实质上要抽象出被测软件应用领域的概念，类似于设计模式中的共性分析。
这项活动需要领域专家、软件专家、设计人员、测试专家等人员参与。
2.2 测试策略分析
针对共性分析挖掘出的可复用点，分析各复用点的测试策略，包括测试类型、测试方法、测试环境、测试覆盖率等内容。
2.3 设计测试用例
根据前两个步骤的分析结果对每个可复用点设计测试用例。在设计时，应使所设计的测试用例满足可复用测试用例的特性，特别要注意以下几方面：
1)每个测试用例的目的要尽量独立、单一，以满足可复用测试用例独立性的要求。
2)对一项明确的测试需求，应关注“测试思想”，即测试思路，以满足可复用测试用例通用性要求。当前，为了使测试用例是可操作的、可复现的，一般都要求测试用例要设计得非常详细，例如，每一操作步骤的输入数据、操作等信息都要具体描述。这样的测试用例和被测软件是紧耦合的，只有在同一软件的回归测试和版本升级维护测试中可能会复用到，在其他情况下复用是很困难的。在设计可复用测试用例时，测试用例的可操作性、可复现性要弱化，即，对测试用例进行通用化处理，排除和特定应用相关的具体信息，以降低测试用例和被测软件的相关度，例如，参数化或公式来代替具体的输入数据，抽象出共同或关键的操作等。但为了加强测试用例的可操作性和可复现性，在设计可复用测试用例时，应对一些差异之处进行预测，即进行可变性分析mJ，并用适当的方式描述出来。只有这样，当复用该测试用例时，测试人员可以在原有基础上对其进行完善，使其能够满足特定的测试情况。
3)将设计出的测试用例用规范而精炼的自然语言清晰地描述出来，保证其完整、标准。软件评测组织或机构应定义本组织使用的规范和术语。
需要说明的是，对于一个具体的测试项目，因为面向复用，所以以上所设计的测试用例可能不完全满足被测软件的测试需求，为此，应针对被测软件的需求补充新的用例或对现有用例进行充实完善。
2.4 测试用例评审
可复用测试用例设计完成后，组织领域专家、软件专家、测试专家、软件设计人员对其进行评审，确保所设计的测试用例是正确的，满足可复用测试用例的特性。
评审同时应关注以下几点：每个共性需求的测试策略是否合适;每个共性需求是否被可复用测试用例所覆盖;每个共性需求是否被可复用测试用例进行了充分测试，例如，某一共性功能，不能仅测试正常情况，还应测试边界和异常情况。如果测试用例没有通过评审，则需要重新回到设计测试用例步骤。
2.5 测试用例执行和修改
将通过评审确认的测试用例用于被测软件，寻找其不正确或不完善之处并纠正完善。
2.6 测试用例入库
将经过测试执行确认的可复用测试用例统一纳入测试用例库中，供测试人员在后续软件测试或以后的项目中查询使用。测试用例库应是按照一定的组织结构形成的测试用例集合。
3、基于复用的软件测试模型
文献给出了一个测试用例复用流程：首先定义被测软件的测试用例类型;再根据所定义的从测试用例库中检索是否有适合的用例;如果可以找到，则提取出测试用例，程序结束;否则，需要设计测试用例，验证其正确性，如果正确，则添加到库中以便再次复用，程序结束。这个流程只适用于完全不需要进一步完善的可复用的测试用例，由于可复用测试用例的通用性，该流程显然不适用于实际情况。文献[12]给出了另一个测试用例复用模型，该模型建立在没有测试用例库的基础上，且将测试用例分为内外两类，本文认为这种划分是不必要的。
本文提出了基于复用的软件测试模型。该模型面向一个软件测试项目，但不同于以往的测试模型，主要表现在模型中融合了面向复用的测试用例设计以及对测试用例的复用上，模型如图2所示。
“测试需求分析和共性分析”中，测试人员一方面要根据被测试软件需求分析、设计说明等文档或软件代码梳理出被测软件的测试需求，另一方面要针对被测软件所属领域及软件类型进行面向复用的共性分析。
“定义测试策略”中，测试人员根据测试目标和上一步的结果定义测试策略，包括测试方法、测试类型、测试环境等内容。
“定义测试用例”中，测试人员根据测试需求和共性分析结果及所定义的测试策略，定义所需要的测试用例。这里定义的测试用例只是给出一个测试用例名称及其测试目的。
“查询可复用测试用例库”中，测试人员用多字段检索功能从可复用测试用例库中查找满足要求的测试用例。对测试用例的查询是不确定的，查询结果通常是一个相似的测试用例集合。如果可以找到，则“提取测试用例”并对其进行分析，确定出最合适的测试用例;如果没有，则“设计”新的测试用例。找到的测试用例，往往因其通用性，并不能完全满足测试需求，要对其“补充完善”。在设计新的测试用例时，要考虑到上节“设计测试用例”要求。
在传统模型评审的基础上，本模型“测试评审”还包括对新设计的可复用测试用例是否满足要求的审查;对复用的测试用例是否补充完善的审查;所有测试用例是否满足被测软件的测试需求的审查。
“执行测试用例”中，测试人员将所设计的测试用例逐用例逐步骤地执行。在执行过程中，认真观察并详实地记录测试过程、测试结果和发现的错误，形成测试记录。如果在执行过程中发现测试用例有不正确和不完善之处，则纠正;如果测试用例不充分，则补充。
测试人员在“测试总结”中对所有测试结果进行分析总结，将通过测试执行验证的可复用测试用例放入可复用测试用例库中，以便后续复用。
该模型的优点为：1)对已有的可复用的测试用例进行了复用，避免了大量的重复性工作，提高了测试质量和效率;2)考虑了面向复用的测试用例设计，避免再次产生大量的不可复用的测试用例。
4、可复用测试用例描述要素
测试用例的输入、操作、预期结果和评估标准、前提条件是测试用例不可少的要素，但对于可复用测试用例而言，这是不够的。本文在文献规定的测试用例要素基础上，增加了新的内容。从而从多个角度完整地对可复用测试用例进行了描述，为可复用测试用例的标准化提供了模板，为建立可复用测试用例库并对测试用例实施有效管理提供了基础，也为测试用例检索提供了多个检索字段。
1)测试用例名称：名称能清晰且简洁地表达测试用例的功能。
2)ID：该ID在数据库中是唯一的。
3)版本号：用于测试用例的版本管理，每个测试用例应按照定义的规则设定一个版本号。
4)测试需求：对要验证的测试需求的描述和测试要求，例如，功能、性能等。
5)测试阶段：被测软件所处的测试阶段，包括单元测试、部件测试、配置项测试、系统测试，或者单元测试、集成测试、确认测试、系统测试。
6)测试方法：黑盒测试中的等价类划分、因果图，白盒测试中的语句覆盖、分支覆盖等。
7)测试类型：有功能测试、性能测试、安全测试、用户界面测试、接口测试、安装测试等，可选择多项。
8)应用领域：说明被测软件所属领域。
9)系统类型：描述被测软件所在系统的架构，如B/S、C/S、嵌入式软件、非嵌入式软件等。
lO)软件编码：描述被测软件的编码语言。
11)测试环境：描述该测试用例执行的软硬件环境。
12)前提条件：测试用例执行前必须满足的条件，或称之为约束条件。
13)测试输入：对输入值的抽象描述或参数化描述，不能是具体的数据值。
14)操作步骤：说明执行该测试用例的一系列相关联的操作。
15)预期结果：说明测试用例执行后的期望结果。每一操作步骤也可有自己的预期结果。
16)评估标准：描述评判测试用例执行中产生的中间和最后结果是否正确的准则。
17)附件：对测试用例附加的一些描述信息，可任意表示，例如文本、图像、模型、与测试用例有关的一些文档，方便测试人员进一步理解测试用例。
上述要素对可复用测试用例而言是必要的，不可缺少。而且要注意的是，测试人员在描述测试用例各要素时，应尽可能地使用规范语言和术语，以使测试用例规范化和易于理解。
5、应用
本文的研究内容在航天测控领域进行了应用。在航天测控计算机系统中，有一类实时系统软件。在不同型号任务中，该类软件的功能、性能、接口和运行环境都有区别，但不同任务对该类软件有共性需求。更多细节信息的子带图像予以了更多地保留，恢复了图像的边缘轮廓，而且经图像分解后的子带图像含有相同尺寸的大小，也更易于处理。本文算法的缺陷则是执行速度较慢，不如前三种算法，而且对分解后所得到系数处理也比较简单，这些都需作进一步的改进。
第二篇：APP测试流程,测试用例,计划,报告可参照（推荐）
移动APP测试流程及测试点
1. APP测试基本流程
1.1. 测试周期
测试周期可按项目的开发周期来确定测试时间，一般测试时间为两三周(即15个工作日)，根据项目情况以及版本质量可适当缩短或延长测试时间。正式测试前先向负责人确认项目排期。
1.2. 测试资源
测试任务开始前，检查各项测试资源。
--产品功能需求文档;
--产品原型图;
--产品效果图;
--行为统计分析定义文档;
--测试设备(ios7.1-ios9.2;Android4.0-Android6.0;);
--其他。
1.3. 日报、周报及APP上线报告
1)测试人员每天需对所测项目发送测试日报。
2)测试日报所包含的内容为：
--对当前测试版本质量进行分级(高中低);
--对较严重的问题进行例举，提示开发人员优先修改;
--对版本的整体情况进行评估。
3)APP上线前，测试人员发送APP上线报告。 4)上线报告所包含的内容为：
--对当前版本质量进行分级;
--附上测试报告(功能测试报告、兼容性测试报告、性能测试报告以及app可用性能标准结果);
--总结上线版本的基本情况。若有遗留问题必须列出并记录解决方案。 5)周报作为汇总本周所有的情况，以及开发人员修改情况与回归测试。
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)输人的密码将不以明文形式进行显示;
3)密码, 信用卡明细, 或其他的敏感数据将不被储存在它们预输人的位置上;
4)防止应用程序异常终止而又没有删除它的临时文件, 文件可能遭受人侵者的袭击, 然后读取这些数据信息;
5)当将敏感数据输人到应用程序时, 其不会被储存在设备中;
6)在数据删除之前，应用程序应当通知用户或者应用程序提供一个“取消”命令的操作;
7)“取消”命令操作能够按照设计要求实现其功能;
8)应用程序应当能够处理当不允许应用软件连接到个人信息管理的情况;
9)当进行读或写用户信息操作时, 应用程序将会向用户发送一个操作错误 的提示信息;
10)在没有用户明确许可的前提下不损坏删除个人信息管理应用程序中的任 何内容;
11)应用程序读和写数据正确;
12)应用程序应当有异常保护;
13)如果数据库中重要的数据正要被重写, 应及时告知用户;
14)能合理地处理出现的错误;
25)意外情况下应提示用户。
2.1.4. 通讯安全性
1)在运行其软件过程中, 如果有来电、SMS、EMS、MMS、蓝牙、红外等通讯或充电时, 是否能暂停程序，优先处理通信, 并在处理完毕后能正常恢复软件, 继续其原来的功能;
2)当创立连接时, 应用程序能够处理因为网络连接中断, 进而告诉用户连接中断的情况;
3)应能处理通讯延时或中断;
4)应用程序将保持工作到通讯超时, 进而发送给用户一个错误信息指示有连接错误;
5)应能处理网络异常和及时将异常情况通报用户;
6)应用程序关闭或网络连接不再使用时应及时关闭) 断开;
7) HTTP、HTTPS覆盖测试
--App和后台服务一般都是通过HTTP来交互的，验证HTTP环境下是否正常;
--公共免费网络环境中(如：麦当劳、星巴克等)都要输入用户名和密码，通过SSL认证来访问网络，需要对使用HTTP Client的library异常作捕获处理。
2.1.5. 人机接口安全性
1)返回菜单总保持可用;
2)命令有优先权顺序;
3)声音的设置不影响应用程序的功能;
4)应用程序必需利用目标设备适用的全屏尺寸来显示上述内容;
5)应用程序必需能够处理不可预知的用户操作, 例如错误的操作和同时按下多个键。
2.2. 安装卸载测试
验证App是否能正确安装、运行、卸载及操作过程和操作前后对系统资源的使用情况。
2.2.1. 安装
1)软件在不同操作系统(Android、iOS)下安装是否正常;
2)软件安装后的是否能够正常运行，安装后的文件夹及文件是否写到了指定的目录里;
3)软件安装各个选项的组合是否符合概要设计说明;
4))软件安装向导的UI测试;
5)软件安装过程是否可以取消，点击取消后，写入的文件是否如概要设计说明处理;
6)软件安装过程中意外情况的处理是否符合需求(如死机，重启，断电); 7)安装空间不足时是否有相应提示;
8)安装后没有生成多余的目录结构和文件;
9)对于需要通过网络验证之类的安装，在断网情况下尝试一下;
10)还需要对安装手册进行测试，依照安装手册是否能顺利安装。
2.2.2. 卸载
1)直接删除安装文件夹卸载是否有提示信息;
2)测试系统直接卸载程序是否有提示信息;
3)测试卸载后文件是否全部删除所有的安装文件夹;
4)卸载过程中出现的意外情况的测试(如死机、断电、重启);
5)卸载是否支持取消功能，单击取消后软件卸载的情况;
6)系统直接卸载UI测试，是否有卸载状态进度条提示。
2.3. UI测试
测试用户界面(如菜单、对话框、窗口和其它可规控件)布局、风格是否满足客户要求、文字是否正确、页面是否美观、文字、图片组合是否完美、操作是否友好等。
UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏觅功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。
2.3.1. 导航测试
1)按钮、对话框、列表和窗口等;或在不同的连接页面之间需要导航;
2)是否易于导航，导航是否直观; 3)是否需要搜索引擎;
4)导航帮助是否准确直观;
5)导航与页面结构、菜单、连接页面的风格是否一致。
2.3.2. 图形测试
1)横向比较。各控件操作方式统一;
2)自适应界面设计，内容根据窗口大小自适应;
3)页面标签风格是否统一;
4)页面是否美观;
5)页面的图片应有其实际意义而要求整体有序美观;
6)图片质量要高且图片尺寸在设计符合要求的情况下应尽量小;
7)界面整体使用的颜色不宜过多。
2.3.3. 内容测试
1)输入框说明文字的内容与系统功能是否一致;
2)文字长度是否加以限制;
3)文字内容是否表意不明;
4)是否有错别字;
5)信息是否为中文显示;
6)是否有敏感性词汇、关键词;
7)是否有敏感性图片，如：涉及版权、专利、隐私等图片。
2.4. 功能测试
根据软件说明或用户需求验证App的各个功能实现，采用如下方法实现并评估功能测试过程： 1)采用时间、地点、对象、行为和背景五元素或业务分析等方法分析、提炼App的用户使用场景，对比说明或需求，整理出内在、外在及非功能直接相关的需求，构建测试点，并明确测试标准，若用户需求中无明确标准遵循，则需要参考行业或相关国际标准或准则。
2)根据被测功能点的特性列丼出相应类型的测试用例对其进行覆盖，如;涉及输入的地方需要考虑等价、边界、负面、异常或非法、场景回滚、关联测试等测试类型对其进行覆盖。
3)在测试实现的各个阶段跟踪测试实现与需求输入的覆盖情况，及时修正业务或需求理解错误。
2.4.1. 运行
1)App安装完成后的试运行，可正常打开软件;
2)App打开测试，是否有加载状态进度提示;
3)App打开速度测试，速度是否可观;
4)App页面间的切换是否流畅，逻辑是否正确;
5)注册
--同表单编辑页面 --用户名密码长度;
--注册后的提示页面;
--前台注册页面和后台的管理页面数据是否一致;
--注册后，在后台管理中页面提示;
6)登录
--使用合法的用户登录系统;
--系统是否允许多次非法的登陆，是否有次数限制; --使用已经登陆的账号登陆系统是否正确处理;
--使用禁用的账号登陆系统是否正确处理;
--用户名、口令(密码)错误或漏填时能否登陆;
--删除或修改后的用户，原用户登陆;
--不输入用户口令和用户、重复点(确定或取消按钮)是否允许登陆;
--登陆后，页面中登陆信息; --页面中有注销按钮; --登陆超时的处理;
7)注销
--注销原模块，新的模块系统能否正确处理;
--终止注销能否返回原模块，原用户;
--注销原用户，新用户系统能否正确处理;
--使用错误的账号、口令、无权限的被禁用的账号进行注销。
2.4.2. APP前后台切换
1) APP切换到后台，再回到app，检查是否停留在上一次操作界面;
2) APP切换到后台，再回到app，检查功能及应用状态是否正常，安卓和IOS的版本的处理机制有的不一样;
3) app切换到后台，再回到前台时，注意程序是否崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候;
4) 手机锁屏解屏后进入app注意是否会崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候;
5) 当App使用过程中有电话进来中断后再切换到app，功能状态是否正常; 6) 当杀掉app进程后，再开启app，app能否正常启动;
7) 出现必须处理的提示框后，切换到后台，再切换回来，检查提示框是否还存在，有时候会出现应用自动跳过提示框的缺陷;
8) 对于有数据交换的页面，每个页面都必需要进行前后台切换、锁屏的测试，这种页面最容易出现崩溃。
2.4.3. 自动登陆
很多应用提供自动登录功能，当应用开启时自动以上一次登录的用户身份来使用app.
1) app有免登录功能时，需要考虑IOS与安卓版本差异;
2) 考虑无网络情况时能否正常进入免登录状态;
3) 切换用户登录后，要校验用户登录信息及数据内容是否相应更新，确保原用户退出;
4) 根据MTOP的现有规则，一个帐户只允许登录一台机器。所以，需要检查一个帐户登录多台手机的情况。原手机里的用户需要被踢出，给出友好提示;
5) app切换到后台，再切回前台的校验;
6) 切换到后台，再切换回前台的测试
7) 密码更换后，检查有数据交换时是否进行了有效身份的校验;
8) 支持自动登录的应用在进行数据交换时，检查系统是否能自动登录成功并且数据操作无误;
9) 检查用户主动退出登录后，下次启动app，应停留在登录界面
2.4.4. 数据更新
根据应用的业务规则，以及数据更新量的情况，来确定最优的数据更新方案。
1) 需要确定哪些地方需要提供手动刷新，哪些地方需要自动刷新，哪些地方需要手动+自动刷新;
2) 确定哪些地方从后台切换回前台时需要进行数据更新;
3) 根据业务、速度及流量的合理分配，确定哪些内容需要实时更新，哪些需要 定时更新;
4) 确定数据展示部分的处理逻辑，是每次从服务端请求，还是有缓存到本地， 这样才能有针对性的进行相应测试;
5) 检查有数据交换的地方，均有相应的异常处理。
2.4.5. 离线浏览
很多应用会支持离线浏览，即在本地客户端会缓存一部分数据供用户查看。
1) 在无网络情况可以浏览本地数据;
2) 退出app再开启app时能正常浏览;
3) 切换到后台再切回前台可以正常浏览;
4) 锁屏后再解屏回到应用前台可以正常浏览;
5) 在对服务端的数据有更新时会给予离线的相应提示
2.4.6. APP更新
1) 当客户端有新版本时，有更新提示;
2) 当版本为非强制升级版时，用户可以取消更新，老版本能正常使用。用户在下次启动app时，仍能出现更新提示;
3) 当版本为强制升级版时，当给出强制更新后用户没有做更新时，退出客户端。下次启动app时，仍出现强制升级提示。
4) 当客户端有新版本时，在本地不删除客户端的情况下，直接更新检查是否能正常更新;
5) 当客户端有新版本时，在本地不删除客户端的情况下，检查更新后的客户端功能是否是新版本;
6) 当客户端有新版本时，在本地不删除客户端的情况下，检查资源同名文件如图片是否能正常更新成最新版本。如果以上无法更新成功的，也都属于缺陷。
2.4.7. 定位、照相机服务
1) App有用到相机，定位服务时，需要注意系统版本差异;
2) 有用到定位服务、照相机服务的地方，需要进行前后台的切换测试，检查应用是否正常;
3) 当定位服务没有开启时，使用定位服务，会友好性弹出是否允许设置定位提示。当确定允许开启定位时，能自动跳转到定位设置中开启定位服务;
4) 测试定位、照相机服务时，需要采用真机进行测试。
2.4.8. 时间测试
客户端可以自行设置手机的时区、时间，因此需要校验该设置对app的影响。
--中国为东8区，所以当手机设置的时间非东8区时，查看需要显示时间的地方，时间是否展示正确，应用功能是否正常。时间一般需要根据服务器时间再转换成客户端对应的时区来展示，这样的用户体验比较好。比如发表一篇微博在服务端记录的是10：00，此时，华盛顿时间为22：00，客户端去浏览时，如果设置的是华盛顿时间,则显示的发表时间即为22:00,当时间设回东8区时间时，再查看则显示为10：00。(另：如果时间不统一，由于semp服务器的缘故，会导致APP无法正常使用，遇到这种情况，请及时更新手机时间，或者通知开发人员修改服务器时间，谢谢大家配合)。 2.4.9. PUSH消息推送测试
1) 检查push消息是否按照指定的业务规则发送;
2) 检查不接受推送消息时，检查用户不会再接收到push;
3) 如果用户设置了免打扰的时间段，检查在免打扰时间段内，用户接收不到PUSH。在非免打扰时间段，用户能正常收到push;
4) 当push消息是针对登录用户的时候，需要检查收到的push与用户身份是否相符，没有错误地将其它人的消息推送过来。一般情况下，只对手机上最后一个登录用户进行消息推送;
5) 测试push时，需要采用真机进行测试。
2.5. 性能测试
评估App的时间和空间特性：
1)极限测试：在各种边界压力情况下，如电池、存储、网速等，验证App是否能正确响应。
--内存满时安装App;
--运行App时手机断电;
--运行App时断掉网络;
2)响应能力测试：测试App中的各类操作是否满足用户响应时间要求。
--App安装、卸载的响应时间;
--App各类功能性操作的影响时间;
3)压力测试：反复/长期操作下、系统资源是否占用异常。
--App反复进行安装卸载，查看系统资源是否正常;
--其他功能反复进行操作，查看系统资源是否正常;
4)性能评估：评估典型用户应用场景下，系统资源的使用情况。
2.6. 兼容测试
主要测试内部和外部兼容性：
1)与本地及主流App是否兼容;
2)基于开发环境和生产环境的不同，检验在各种网络连接下(WiFi、GSM、GPRS、EDGE、WCDMA、CDMA1x、CDMA2000、HSPDA等)，App的数据和运用是否正确;
3)与各种设备是否兼容，若有跨系统支持则需要检验是否在各系统下，各种行为是否一致;
--不同操作系统的兼容性，是否适配;
--不同手机屏幕分辨率的兼容性;
--不同手机品牌的兼容性。
2.7. 回归测试
1)Bug修复后且在新版本发布后需要进行回归测试。
2)Bug修复后的回归测试在交付前、要进行全量用例的回归测试。
2.8. 用户体验测试
以主观的普通消费者的角度去感知产品或服务的舒适、有用、易用、友好亲切程度。 通过不同个体、独立空间和非经验的统计复用方式去有效评价产品的体验特性修改意见提升产品的潜在客户满意度。
1)是否有空数据界面设计，引导用户去执行操作;
2)是否滥用用户引导;
3)是否有不可点击的效果，如：你的按钮此时处于不可用状态，那么一定要灰掉，或者拿掉按钮，否则会给用户误导;
4)菜单层次是否太深;
5)交互流程分支是否太多;
6)相关的选项是否离得很远;
7)一次是否载入太多的数据;
8)界面中按钮可点击范围是否适中;
9)标签页是否跟内容没有从属关系，当切换标签的时候，内容跟着切换;
10)操作应该有主次从属关系;
11)是否定义Back的逻辑。涉及软硬件交互时，Back键应具体定义;
12)是否有横屏模式的设计，应用一般需要支持横屏模式，即自适应设计
2.9. 硬件环境测试
2.9.1. 网络环境测试
手机的网络目前主要分为2G、3G、4G、wifi。目前2G的网络相对于比较慢，测试时尤其要注意此块的测试。
1) 无网络时，执行需要网络的操作，给予友好提示，确保程序不出现crash; 2) 内网测试时，要注意选择到外网操作时的异常情况处理;
3) 在网络信号不好时，检查功能状态是否正常，确保不因提交数据失败而造成crash;
4) 在网络信号不好时，检查数据是否会一直处于提交中的状态，有无超时限制。如遇数据交换失败时要给予提示;
5) 在网络信号不好时，执行操作后，在回调没有完成的情况下，退出本页面或者执行其他操作的情况，有无异常情况。此问题也会经常出现程序crash。 2.9.2. 服务器垒机或者出现40
4、500的情况下测试
后台服务牵涉到DNS、空间服务商的情况下会影响其稳定性，如：当出现域名解析故障时，你对后台API的请求很可能就会出现404错误，抛出异常。这时需要对异常进行正确的处理，否则可能会导致程序不能正常工作。是否有友好的提示。
第三篇：图书管理系统用例建模报告(用例图、类图、时序图)
软件系统分析与设计
实验报告
学
院：计算机科学与技术学院
专
业：软件工程学
号：姓
名：实验名称：图书管理系统用例建模时
间：
1 / 9
********* ***
一、 实验内容与要求
本实验要求学生对学校的图书馆管理系统进行需求分析，对系统功能进行用例建模，画出用例图，类图以及相应的时序图。在使用UML对系统建模时，学会使用UML建模工具， 熟悉工具中的功能。
二、用例分析
1、读者“ 借书还书系统” 用例图
借书(from Use Cases)<>读者(from Actors)预约(from Use Cases)续借(from )还书(from Use Cases)
1.
1、 行为者：
主要行为者：读者。
1.
2、 前置条件：
读者进入图书管理系统。
1.
3、 事件流：
1.3.1、主要事件流：
1.3.1.1：读者检索所需图书信息，并查看;
1.3.1.2：读者检索到所需图书，登录系统，开始借书;
1.3.1.3：系统查询图书信息，图书数目是否可借;
1.3.1.3.1：图书显示可借，借书成功;
2 / 9
1.3.1.3.2：图书显示不可借，借书失败; 1.3.1.4：进入续借图书界面，续借图书; 1.3.1.5：系统查看预约记录，
1.3.1.5.1：没有冲突，续借成功;
1.3.1.5.2：有冲突，续借失败;1.3.3.1：
1.3.1.6：读者归还图书;
1.3.1.6.1：归还时间没有逾期，归还成功;
1.3.1.5.2：归还时间逾期，逾期处罚，归还成功;
1.3.2、备选事件流：
1.3.2.1：图书检索信息失败，未检索到图书，重新输入信息检索;
1.3.2.2：未曾检索到用户检索的图书，系统显示相关联的信息的图书;
1.3.2.3：用户名或密码输入错误，登录系统失败，重新输入用户名或密码登录;
1.3.2.4：系统显示图书不可借后，进入图书预约界面，输入信息预约图书;
1.3.3、异常事件流：
1.3.3.1：读者登录系统失败，未曾注册用户;
1.3.3.1.1：返回系统注册用户后，重新登录。
1.
4、 后置条件：退出系统。 1.
5、
1.
6、 扩展点：无。
2、“图书信息管理系统”用例图
新书信息录入(from Use Cases)<>预约通知管理员(from Actors)(from Use Cases)<>图书信息管理(from Use Cases)逾期处罚信息通知<>(from Use Cases)(from Use Cases)<><>读者信息管理(from Use Cases)逾期通知(from Use Cases)
3 / 9
2.
1、行为者：
主要行为者：管理员;
2.
2、前置条件：管理员打开图书信息管理系统;
2.
3、事件流：
2.3.1：主要事件流：
2.3.1.1：图书管理员输入管理员登录信息，登录系统;
2.3.1.2：进入图书信息管理界面，查看已有图书信息，是否有需要购入图书;
2.3.1.2.1：录入新购进图书信息，并确认;
2.3.1.3：进入读者信息管理界面，管理已有用户信息;
2.3.1.4：进入信息通知界面，查看已有用户图书借阅、预约情况;
2.3.1.4.1：查看读者所预约图书，自动查询图书信息，确认是否已有可借图书，有则通知读者;
2.3.1.4.2：查询读者已借图书信息，根据已借时间及归还时间分类;
2.3.1.4.2.1：所借图书即将逾期，启动系统提醒功能;
2.3.1.4.2.2：所借图书已经逾期，启动逾期及处罚通知功能;
2.3.2：备选事件流：
2.3.2.1：管理员用户名或登录名错误，重新登录;
2.3.2.2：需要购进新图书，存储信息，通知相关人员;
2.3.2.3：读者预约图书没有可借图书，不予通知;
2.3.2.4：预约通知提醒后，删除该预约记录;
2.3.2.5：读者所借图书距离归还时间仍很久，无需通知;
2.3.3：异常事件流：
2.3.3.1：登录失败超过一定次数后，系统冻结该用户名，一段时间后可以重用;
2.
4、后置条件：退出系统;
2.
5、扩展点：无。
三、“图书管理系统”类图及关系
4 / 9
1、 阅读者信息类：
1.1、类名：阅读者信息<<父类>>; 1.
2、属性名：
1.2.1、private： ID<<阅读者证件号>>
1.3、方法：未定。
2、 读者类：
2.1、类名：读者<<子类>>; 2.
2、属性名：
1.2.1、private：ID<<阅读者证件号>>
2.3、方法：未定。
3、 管理员类：
3.1、类名：管理员<<子类>> 3.
2、属性名：
1.2.1、private： ID<<阅读者证件号>>
3.3、方法：未定。
4、 Book类：
4.1、类名：book 5 / 9
类型：String;
类型：String;
类型：String; 4.2、属性名：
4.2.1、private： 书号<<图书编号>>
类型：String; 4.2.2、private： 书名<<图书名>>
类型：String; 4.2.3、private： 出版号<<图书出版编号>>
类型：String; 4.2.4、private： 出版社名<<图书出版社名>> 类型：String; 4.2.
5、private： 作者<<图书作者姓名>>
类型：String; 4.3、方法：未定。
5、 Copy_book类：
5.1、类名：copy_book; 5.
2、属性名：
5.2.1、private： 书号<<图书编号>>
类型：String; 5.2.2、private： 书名<<图书名>>
类型：String; 5.2.3、private： 出版号<<图书出版编号>>
类型：String; 5.2.4、private： 出版社名<<图书出版社名>>
类型：String; 5.2.5、private： 作者<<图书作者姓名>>
类型：String; 5.2.6、private：count<<图书数量>>
类型：String; 5.3、方法：未定。
6、 借还书记录类<<关联类>>：
6.1、类名：借还书记录; 6.
2、属性名：
6.2.1、private： 书号<<图书编号>>
类型：String; 6.2.2、private： 书名<<图书名>>
类型：String; 6.2.3、private：读者姓名<<>>
类型：String; 6.2.4、private： 出版社名<<图书出版社名>>
类型：String; 6.2.5、private： 作者<<图书作者姓名>>
类型：String; 6.2.6、private：borrowdate<<所借图书日期>>
类型：Date; 6.2.7、private：due_Date<<图书应还日期>>
类型：Date; 6.2.8、private：real_Date<<图书实还日期>> 类型：Date; 6.
3、方法：
6.3.1、private：getDate()
返回值：Date;
6.3.2、private：isOverDate()
返回值：bool;
6.3.3、private：opname()
返回值：void;
7、 预约类：
7.1、类名：Reservation; 7.
2、属性：
7.2.1：private：书名<<预约书名>>
类型：String;
7.2.2：private：作者<<图书作者>>
类型：String; 7.2.4：private：读者ID<<预约者ID>>
类型：String; 7.2.4：private：预约时间<<预约时间>>
类型：Date;
7.3、方法：未定。
6 / 9
四、图书管理系统时序图及分析
1)、时序图内容
时序图是显示对象之间交互的图，这些对象是按时间顺序排列的。该图书馆管理系统主要含有以下几个重要的时序图，其他对象的时序图和这些类似。
1、 借书时序图;
2、 还书时序图;
3、 预约时序图。
2)、时序图分析
1、借书时序图
：借书系统：loan读者copy_bookbookReservation<<预约>> : 读者需借书目 : 管理员login()show_reader()1:check()borrow()getreader()2:check()getbookinf()3:check()1:isBorrow()bulidinf()2:isBorrow()3:isBorrow()4:isborrow()
【借书时序图说明】
1、 login()：读者将需借书目交给管理员，管理员登陆系统。
2、 show_reader()：显示读者的信息的函数。
3、 check()：验证读者是否有借书的权利。
4、 borrow()：读者借书函数。
5、 getreader()：获取读者信息的函数。
6、 check()：检验读者是否符合借书条件函数。
7、 getbookinf()：获取书目信息函数。
8、 check()：检查书籍是否被预约的函数。
9、 isBorrow()：返回未被预约函数。
7 / 9
10、 builtinf()：建立借阅信息函数。
11、 isBorrow()：返回借阅信息函数。
12、 isBorrow():返回借阅成功函数。
13、 isBorrow：借阅成功，将书交给读者。
借书时，读者先将书拿予管理员，管理员对书籍和读者进行检验，若书籍和读者都符合借书条件，则借书成功。
2、还书时序图
还书界面 : 读者还书login()getbookinf() : 管理员bookloangetborrowinf()getborrowDate()getnowDate()isOverDate()work()returnreturn【还书时序图说明】
1、 login()：读者将书籍交给管理员，管理员登录系统。
2、 getbookinf()：管理员扫描条形码，获取书籍信息函数。
3、 getborrowinf()：获取借阅信息函数。
4、 getborrowDate()：获取借阅时间函数。
5、 getnowDate()：获取现在时间函数。
6、 isOverDate():是否超出借阅时间函数。
8 / 9
7、 work()：处理函数，处理时间差。
8、 return：消息返回。
还书时，读者先将书交给管理员，由管理员扫描书籍，若书籍没有过期等违规现象，还书成功。
3、预约时序图
图书管理系统bookcopy_bookReservation : 读者login()getbookinf()check()reservation()getbook()build()return result
【预约图书时序图说明】
1、 login()：登录系统。
2、 getbookinf()：获取图书信息函数。
3、 check()：检查是否有图书可借函数。
4、 reservation()：确定预约图书函数。
5、 getboook()：获取预约图书信息函数。
6、 built()：建立预约信息函数。
7、 return：消息返回。
读者在借书时，发现自己所需要借的书目无法借阅，进入预约界面，建立预约记录。
9 / 9
第四篇：测试手机短信MP3
短信
功能性：接收/发送信息，支持的语言
性能性：最大存储量，接收/发送信息的速度，
可靠性：手机突然关机/死机 正在发送/编写的信息还有没有 安全性：能否防止有人通过一些渠道窃取信息内容 可用性：输入法
维护性：
移植性：换一个手机/换一个SIM卡 之前的信息还在不在 重用性：
MP3
功能性：听歌，歌词显示，格式要求
性能性：最大存储量，最长时间，
可靠性：手机突然关机/死机 歌曲还有没有
安全性：
可用性：
维护性：
移植性：在不同的软件上 是否都能播放
重用性：
第五篇：门禁手机短信功能操作说明书
目录
1 2 控制器IP设置 ......................................................................................................................... 2 短信设置 ................................................................................................................................... 3 2.1 2.2 3 4 5 6 发送设置 ....................................................................................................................... 7 短信内容设置 ............................................................................................................... 8
用户手机设置 ......................................................................................................................... 10 权限设置 ................................................................................................................................. 10 短信接收 ................................................................................................................................. 12 短信发送时段设置 ................................................................................................................. 13 6.1 6.2 添加短信发送时段 ..................................................................................................... 13 启用短信发送时段 ..................................................................................................... 14 7 短信发送限次设置 ................................................................................................................. 15 7.1 7.2 添加短信发送限次 ..................................................................................................... 15 启用短信发送限次 ..................................................................................................... 16
深圳市赤道科技有限公司
门禁手机短信功能优势和应用场景：
1、门禁家校通 (小孩什么时候进校门?出校门?短信即时通知)
2、手机短信报警 (工厂、仓库、高级大厦，别墅„„仓库、厂区有异常，强行闯入、胁迫、火警等等，报警即时短信通知)
3、员工考勤 (刷卡即时收到短信!再也不用担心没刷到卡了)
手机接收短信基于短信平台，需先申请短信平台商。 以下说明以中国短信网(http://)为例。
进入网站，找网站客服人员索要账号密码进行测试使用，成功后再购买短信数量。 以下操作设置需先进入“专业智能门禁管理系统”。
软件版本要求是 V7.69 或以上版本，如果不是，请先升级软件。
控制器驱动版本要求是 V6.56 或以上版本，如果不是，请先升级控制器驱动。 通过“操作--总控制台--检测控制器”即可查询控制器驱动版本。
1 控制器IP设置
根据当前电脑的IP地址来设置控制器的IP地址，当前电脑必须能访问互联网。
如：当前能上网的电脑IP地址设置如下：
控制器IP地址的设置，操作如下：
单击【设置】>【控制器】>【搜索】，搜索到控制器后，选中需修改的控制器，单击【修改该控制器网络参数】。
输入【IP】、【子网掩码】、【默认网关】，输入的 控制器 【IP】、【默认网关】必须 与 电脑 “IP地址”、“默认网关”所在网段一致。
单击【确定】，控制器IP修改完成。
2 短信设置
单击【设置】>【控制器】，再单击【搜索】，进入【搜索控制器】界面，选中控制器，按鼠标右键，可看到【SMS短信设置】。
单击【SMS短信设置】，进入【短信设置】界面。
指定的控制器SMS短信设置成功，会提示：
将和短信平台客服索要到的账号密码输入 【账户名】：用户账户，输入时需加前缀“uid=”。 【密码】：用户密码，输入时需加前缀“pwd=”。 如：
输入测试手机号 如：
发送测试手机发送成功弹窗
如下：
2.1 发送设置
将特殊的记录以短信方式发送到指定的手机号上。
【特殊手机号】：将特殊记录发送到指定的特殊手机号，只能添加2个，用逗号分开。如：
【发出的事件类型】：可选，发送到手机上的短信内容。 如：将报警信息发送到手机上。
收到短信显示为
2.2 短信内容设置
将刷卡记录以短信方式发送到用户的手机上。
如：将刷卡信息发送到手机上，发送内容为【时间】、【用户名】、【是否通过】、【地点】。
收到短信显示为
3 用户手机设置
短信设置启用后，在用户表中会显示【手机】列，添加用户时输入手机号即可。 单击【设置】>【用户】，再单击【添加】，切换到【其他】，在【手机】栏内输入相应的手机号。
备注：用户信息添加或修改后，必需在【总控制台】>【上传设置】。
4 权限设置
单击【设置】>【权限】，进入到权限界面。
单击【添加删除权限】
先选用户，再选门，单击【允许】，提示
单击【确定】，权限添加完成。
权限设置完毕后，将指定门的设置上传给控制器，单击【操作】>【总控制台】，选定门，单击【上传设置】。
单击【确定】。
备注：更多的权限设置请参考“专业智能门禁管理系统操作说明书 第2章中的2.4.1章节 权限管理”。
5 短信接收
短信平台提供的测试账号接收到的短信是随机的手机号发送。
只有申请短信通道后接收到的短信才是专用通道号发送。
6 短信发送时段设置 6.1 添加短信发送时段
请先在【扩展功能】里启用【时段】功能。 单击【设置】>【时段】，进入时段界面。
单击【添加】。
单击【确定】。
设置了【短信发送时段】，仅在指定的时间范围内发送短信。
6.2 启用短信发送时段
【短信发送时段】启用后，只有星期一到星期五 08:0018:00这个时间段才会发送短信。
进入【SMS短信设置】界面，在【发送短信的时段约束】处选择【短信发送时段】。
设置完成后，必需在【总控制台】>【上传设置】。
7 短信发送限次设置 7.1 添加短信发送限次
请先在【扩展功能】里启用【时段限次功能】，同时启用【时段】功能。
单击【设置】>【时段】，再单击【添加】，进入时段设置界面。
单击【确定】。
设置了【短信发送限次】，仅在指定的时间范围内发送短信并限制发送次数。
备注：短信发送限次仅限于在有效时区内的次数限制。
7.2 启用短信发送限次
【短信发送限次】启用后，只有星期一到星期五 08:0020:00发送短信1次。
进入【SMS短信设置】界面，在【发送短信的时段约束】处选择【短信发送限次】。
设置完成后，必需在【总控制台】>【上传设置】。
【手机短信功能测试用例】相关文章：
用例图功能分析04-12
组队测试用例样式04-09
手机短信监控功能07-14
手机短信传播功能论文04-18
手机短信传播功能分析论文04-25
手机短信传播功能分析论文提纲11-15
手机测试项目经验范文04-10
Uml用例图心得04-09
饮料零售机用例图07-24
那些手机有nfc功能09-23