测试方案
-
测试需求
下面列出了那些已被确定为测试对象
的项目（用例、功能性需求和非功能性需求）
。此列表
说明了测
试的对象。
[
在此处输入一个主要测试需求的高层次列表。
]
测试方案
[
测试方案提供了推荐用于测试对象的方法。上一节“测试需求”中说明了将要测试哪些对
象，而本节则要说明如何对测试对象进行测试。
对于每种测试，都应提供测试说明，并解释其实施和执行的原
因。
如果不实施和执行某种测试，则应该用一句话加以说明，
并陈述这样做的理由。例如，
“将
不实施和执行该测试。
。该测试不合适。
”
制定测试策略时所考虑的主要事项有：将要使用的方法以及判断测试何时完成的标准。
下面列出了在进行每项测试时需考虑的事项，
除此之外，
测试还只应在安全的环境中使用已
知的、受控的数据库来执行，可按实
际需要进行删减。
]
测试类型
数据和数据库完整性测试
[
数据库和数据库进程应作为
<
项目
名称
>
中的子系统来进行测试。
在测试这些子系统时，不应将测试对象的用户界面用作
数据的接口。对于数据库管理系统
(DBMS)
，还需要进行深入的研究，以确定可以支持以下测试的工具和方法。
]
测试目标：
方法：
[
确
保数据库访问方法和进程正常运行，数据不会遭到损坏。
]
[
调用各
个数据库访问方法和进程，并在其中填充有效的和无效
的数据或对数据的请求。
检查数据库，确保数据已按预期的方式填充，并且所有
数据
库事件都按正常方式出现；或者检查所返回的数据，确保为
正当
的理由检索到了正确的数据
] <
/p>
[
所有的数据库访问方法和进程都按照设计的方式运行，数据没有
遭到
损坏。
]
[
测试可能需要
DBMS
开发环境或驱动程序以便在数据库中直
接
输入或修改数据。
进程应该以手工方式调用。
应
使用小型或最小的数据库（其中的
记录数很有限）来
使所
有无法接受的
事件具有更大的可见性。
]
完成标准：
需考虑的特殊事项：
功能测试
[
测试对象的功能测试应该侧重于可以被直接追踪到用例或业务功能和业务规则的所有测试
需求。
这些测试的目标在于核实能否正确地接受、
处理和检索数
据以及业务规则是否正确实
施。这种类型的测试基于黑盒方法，即通过图形用户界面
(GUI)
与应用程序交互并分析输<
/p>
出结果来验证应用程序及其内部进程。以下列出的是每个应用程序推荐的测试方法概要：<
/p>
]
测试目标：
方法：
[
确
保测试对象的功能正常，
其中包括导航、
数据输入、
处理和检索等。
]
[
利
用有效的和无效的数据来执行各个用例、用例流或功能，以核实以
下内容：
在使用有效数据时得到预期的结果。
在使用无效数据时显示相应的错误消息或警告消息。
各业务规则都得到了正确的应用。
]
[
所计划的测试已全部执行。
所发现的缺陷已全部解决。
]
[
确定或说明那些将对功能测试的实施和执行造成影响的事项或因素<
/p>
（内部的或外部的）
]
完成标准：
需考虑的特殊事项：
业务周期测试
[
业务周期测试应模拟在一段时间内对
<
项目名称
>
执行的活动。应先确定一段时间（例如
一年）
，然后执行将在
该时段内发生的事务和活动。这种测试包括所有的每日、每周和每月
的周期，以及所有与
日期相关的事件（如备忘录）
。
]
测试目标
方法：
[
确
保测试对象及后台进程都按照所要求的业务模型和时间表正确运
行。
]
[
通过执行以下活动，测试将模拟若干个业务周期：<
/p>
将
修改或
增强对测试对象进行的功能测试，以增加每项功能的执
行次数，从而在指定的时段内模拟若干个不同的用户。
将使用有效的和无效的日期或时段来执行所有与时间或日期相关
的功能。
将
在适当的时候执行或启动所有周期性出现的功能。
在
测试中还将使用有效的和无效的数
据，以核实以下内容：
在
使用有效数据时得到预期的结果。
在使用无效数据时显示相应的错误消息或警告消息。
各业务规则都得到了正确的应用。
[
所计划的测试已全部执行。
所
发现的缺陷已全部解决。
}
[
系统日期和事件可能需要特殊的支
持活动
需
要通过
业务模型来确定相应的测试需求和测试过程。
]
完成标准：
需考虑的特殊事项：
用户界面测试
[
通过用户界面
(UI)
测试来核实用户与软件的交互。
UI
测试的目标在于确保用户界面向用
户提供了适当的访问和浏览测试对象功能的操作。除此
之外，
UI
测试还要确保
UI
功能内
部的对象符合预期要求，
并遵循公司或行业的标准。
]
测试目标：
[
核实以下内容：
通
过浏览测试对象可正确反映业务的
功能和需求，这种浏览包括
窗口与窗口之间、字段与字段之间的浏览，以及各种访问方法
（
Tab
健、鼠标移动和快捷键）的使用
窗口的对象和特征（例如：菜单、大小、位置、状态和
中心）
都符合标准。
]
[
为每个窗口创建或修改测试，以核实各个应用程序窗口和对象都可正
确地进行浏览，并处于正常的对象状态。
]
[
证实各个窗口都与基准版本保持一致，或符合可接受标准
]
[
并不是所有定制或第三方对象的特征都可访问。
]
方法：
完成标准：
需考虑的特殊事项：
性能评价
[
性能评价是一种性能测试，它对响应时间、事务处理速率和其他与时间相关的需求进行评
测和评估。
性能评价的目标是核实性能需求是否都已满足。
实施
和执行性能评价的目的是将
测试对象的性能行为当作条件（例如工作量或硬件配置）的一
种函数来进行评价和微调。
注：以下事务均指“逻辑业务事务
”
。这种事务被定义为将由系统的某个主角通过使用测试
对象来
执行的特定用例，例如，添加或修改某个合同。
]
测试目标：
[
核实所指定的事务或业务功能在以下情况下的性能行为：
正常的预期工作量
预期的最繁重工作量
]
[
使用为功能或业务周期测试制定的测试过程。
通过修改数据文件来增加事务数量，或通过修改脚本来增加每项
事务的迭代次数。<
/p>
脚本应该在一台计算机上运行（最好是以单个用户、单个事务为
基准）
，并在多台客户机（虚拟的或实际的客户机，请参见下面
的“需考虑的特殊事项”
）上重复。
]
[
单个事务或单个用户：在每个事务所预期或要求的时间范围内
成功地完成测试脚本，没有发生任何故障。
]
[
多个事务或多个用户：在可接受的时间范围内成功地完成测试
脚本，没有发生任何故障。
]
方法：
完成标准：
需考虑的特殊事项：
[
综合的性能测试还包括在服务器上添加后台工作量。
可采用多种方法来执行此操作，其中包括：
直接将“事务强行分配到”服务器上，这通常以“结构化查询语
言”
(SQL)
调用的形式来实现。
通过创建“虚拟的”用户负载来模拟许多个（通常为数百个）客
户机。
此负载可通过“远程终端仿真”
(Remote
Terminal
Emulation)
工具来实现。
此技术还可用于在网络中加载“流
量”
。
使用多台实际客户机（每台客户机都运行测试脚本）在系统上添
加负载。
性能测试应该在专用的计算机上或在专用的机时内执行，
以便实
现完全
的控制和精确的评测。
性能测
试所用的数据库应该是与实际大小相同或等比例缩放的数据
库。
]
负载测试
[
负载测试是一种性能测试。在这种测试中，将使测试对象承担不同的工作量，以评测和评
估测试对象在不同工作量条件下的性能行为，
以及持续正常运行的能力。
负载测试的目标是
确定并确保系统在超出最大预期工作量的情况下仍能正常
运行。
此外，
负载测试还要评估性
能特
征，例如，响应时间、事务处理速率和其他与时间相关的方面。
]
[
注：以下事务均指“逻辑业务事务”
。这些事务被定义为
将由系统的最终用户通过使用应用
程序来执行的具体功能，例如，添加或修改某个合同。
]
测试目标：
方法：
[
核
实所指定的事务或商业理由在不同的工作量条件下的性能行为时
间。
]
[
使用为功能或业务周期测试制定的测试。
通过修改数据文件来增加事务数量，或通过修改测试来增加每项
事务发生的次数。
]
完成标准：
需考虑的特殊事项：
[
多个事务或多个用户：在可接受的时间范围内成功地完成测试，没有
发生任何
故障。
]
[
负载测试应该在专用的计算机上或在专用的机时内执行，以便
实现完全的控制和精确的评测。
负载测试
所用的数据库应该是与实际大小相同或等比例缩放的数
据库。
]