软件系统测试与验收方案.doc
- 文档编号:11873019
- 上传时间:2023-04-07
- 格式:DOC
- 页数:12
- 大小:133KB
软件系统测试与验收方案.doc
《软件系统测试与验收方案.doc》由会员分享,可在线阅读,更多相关《软件系统测试与验收方案.doc(12页珍藏版)》请在冰豆网上搜索。
软件系统测试与验收方案
1.1系统测试
1.1.1测试范围
系统的测试范围包括以下阶段:
ü单元测试(功能测试和性能测试)
单元测试是针对于每个界面或报表的测试,主要是考察单个界面或报表所能完成的功能,如数据录入、查询、数据完整性等,确保界面与用户之间能够正常交互。
ü联调测试(功能测试)
联调测试是用户根据自己的业务需求,按照业务流程对系统进行的一种测试,主要是要确定系统功能是否能够满足自己的业务需求,并且能够按照业务流程顺利运行的过程。
ü系统测试(性能测试)
系统测试是对整个系统的运行性能进行的测试,主要是确定系统运行的稳定性、安全性等。
1.1.2测试需求
下表列出了系统中需要测试的对象和测试所要达到的目标:
对象
测试目标
数据
数据是否完整。
数据是否准确。
功能按钮
各按钮是否能完成其相应的功能。
菜单
菜单是否能完成其相应的功能或到达相应的连接。
界面
内容是否完整且各字段是否符合行业标准或用户习惯。
添加、修改、删除、查询数据是否方便。
同一界面的操作是否连贯。
使用无效数据时是否显示相应的错误消息或警告消息。
涉及到计算的数据是否准确。
报表
内容是否完整。
数据是否准确。
格式是否合理。
业务流
操作是否连贯。
各操作人员是否能够准确、及时地接收和发送数据信息。
是否能够完成整个业务周期。
业务周期结束后的数据结果是否正确。
系统
系统运行是否正常。
系统权限是否完整、合理。
系统在最大客户量,同时查询大量数据时是否能操作。
系统在突然停电或其他不正常情况下是否能再正常启动。
系统是否和其他应用软件存在冲突。
其他
根据具体情况而定。
1.1.3测试方案
ü功能测试
对测试对象的功能测试侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。
这种测试的目标是核实数据的接受、处理和检索是否正确,以及业务规则的实施是否恰当。
此类测试基于黑盒技术,该技术通过图形用户界面(GUI)与应用程序进行交互,并对交互的输出或结果进行分析,以此来核实应用程序及其内部进程。
以下为各种应用程序列出了推荐使用的测试标准:
测试目标:
确保测试对象的功能正常,其中包括导航、数据输入、处理和检索等功能。
技术:
利用有效的和无效的数据来执行各个用例、用例流或功能,以核实以下内容:
1、在使用有效数据时得到预期的结果。
2、在使用无效数据时显示相应的错误消息或警告消息。
3、各业务规则都得到了正确的应用。
完成标准:
1、所计划的测试已全部执行。
2、所发现的故障已全部解决。
需考虑的特殊事项:
确定或说明哪些将对功能测试的实施和执行造成影响的事项或因素(内部的或外部的)
ü用户界面测试
用户界面(UI)测试用于核实用户与系统软件功能之间的交互。
UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。
另外,UI测试还可确保UI中的对象按照预期的方式运行,并符合企业的标准。
测试目标:
核实以下内容:
通过测试对象进行的浏览可正确反映业务的功能和需求,这种浏览包括窗口与窗口之间、字段与字段之间的浏览,以及各种访问方法(Tab键、鼠标移动、和快捷键)的使用。
窗口的对象和特征(例如,菜单、大小、位置、状态和中心)都符合标准。
技术:
为每个窗口创建或修改测试,以核实各个应用程序窗口和对象都可正确地进行浏览,并处于正常的对象状态。
完成标准:
成功地核实出各个窗口都与基准版本保持一致,或符合可接受标准。
需考虑的特殊事项:
并不是所有定制或第三方对象的特征都可访问。
ü性能评测
性能评测是一种性能测试,它对响应时间、事务处理速率和其他与时间相关的需求进行评测和评估。
性能评测的目标是核实性能需求是否都已满足。
实施和执行性能评测的目的是将测试对象的性能行为当作条件(例如工作量或硬件配置)的一种函数来进行评测和微调。
注:
以下所说的事务是指“逻辑业务事务”。
这种事务被定义为将由系统的某个操作者通过使用测试对象来执行的特定用例,例如,添加或修改给定的合同。
测试目标:
核实所指定的事务或业务功能在以下情况下的性能行为:
正常的预期工作量。
预期的最繁重工作量。
技术:
使用为功能或业务周期测试制定的测试过程。
通过修改数据文件来增加事务数量,或通过修改脚本来增加每项事务的迭代数量。
脚本应该在一台计算机上运行(最好是以单个用户、单个事务为基准),并在多个客户机(虚拟的或实际的客户机,请参见下面的“需要考虑的特殊事项”)上重复。
完成标准:
单个事务或单个用户:
在每个事务所预期或要求的时间范围内成功地完成测试脚本,没有发生任何故障。
多个事务或多个用户:
在可接受的时间范围内成功地完成测试脚本,没有发生任何故障。
需考虑的特殊事项:
综合的性能测试还包括在服务器上添加后台工作量。
可采用多种方法来执行此操作,其中包括:
直接将“事务强行分配到”服务器上,这通常以“结构化查询语言”(SQL)调用的形式来实现。
通过创建“虚拟的”用户负载来模拟许多个(通常为数百个)客户机。
此负载可通过“远程终端仿真”(RemoteTerminalEmulation)工具来实现。
此技术还可用于在网络中加载“流量”。
使用多台实际客户机(每台客户机都运行测试脚本)在系统上添加负载。
性能测试应该在专用的计算机上或在专用的机时内执行,以便实现完全的控制和精确的评测。
性能测试所用的数据库应该是实际大小或相同缩放比例的数据库。
ü负载测试
负载测试是一种性能测试。
在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。
负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。
此外,负载测试还要评估性能特征,例如,响应时间、事务处理速率和其他与时间相关的方面。
注:
以下所说的事务是指“逻辑业务事务”。
这种事务被定义为将由系统的某个最终用户通过使用应用程序来执行的特定功能,例如,添加或修改给定的合同。
测试目标:
核实所指定的事务在不同的工作量条件下的性能行为时间。
技术:
使用为功能或业务周期测试制定的测试。
通过修改数据文件来增加事务数量,或通过修改测试来增加每项事务发生的次数。
完成标准:
多个事务或多个用户:
在可接受的时间范围内成功地完成测试,没有发生任何故障。
需考虑的特殊事项:
负载测试应该在专用的计算机上或在专用的机时内执行,以便实现完全的控制和精确的评测。
负载测试所用的数据库应该是实际大小或相同缩放比例的数据库。
ü强度测试
强度测试是一种性能测试,实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。
如果内存或磁盘空间不足,测试对象就可能会表现出一些在正常条件下并不明显的故障。
而其他故障则可能由于争用共享资源(如数据库锁或网络带宽)而造成的。
强度测试还可用于确定测试对象能够处理的最大工作量。
注:
以下提到的事务都是指逻辑业务事务。
测试目标:
核实测试对象能够在以下强度条件下正常运行,不会出现任何错误:
1、服务器上几乎没有或根本没有可用的内存(RAM和DASD)。
2、连接或模拟了最大实际(实际允许)数量的客户机。
3、多个用户对相同的数据或账户执行相同的事务。
4、最繁重的事务量或最差的事务组合(请参见上面的“性能测试”)。
注:
强度测试的目标可表述为确定和记录那些使系统无法继续正常运行的的情况或条件。
技术:
使用为性能评测或负载测试制定的测试。
要对有限的资源进行测试,就应该在一台计算机上运行测试,而且应该减少或限制服务器上的RAM和DASD。
对于其他强度测试,应该使用多台客户机来运行相同的测试或互补的测试,以产生最繁重的事务量或最差的事务组合。
完成标准:
所计划的测试已全部执行,并且在达到或超出指定的系统限制时没有出现任何软件故障,或者导致系统出现故障的条件并不在指定的条件范围之内。
需考虑的特殊事项:
如果要增加网络工作强度,可能会需要使用网络工具来给网络加载消息或信息包。
应该暂时减少用于系统的DASD,以限制数据库可用空间的增长。
使多个客户机对相同的记录或数据账户同时进行的访问达到同步。
ü安全性和访问控制测试
安全性和访问控制测试侧重于安全性的两个关键方面:
应用程序级别的安全性,包括对数据或业务功能的访问。
系统级别的安全性,包括对系统的登录或远程访问。
应用程序级别的安全性可确保:
在预期的安全性情况下,用户只能访问特定的功能或用例,或者只能访问有限的数据。
例如,可能会允许所有人输入数据,创建新账户,但只有管理员才能删除这些数据或账户。
如果具有数据级别的安全性,测试就可确保“用户类型一”能够看到所有客户消息(包括财务数据),而“用户二”只能看见同一客户的统计数据。
系统级别的安全性可确保只有具备系统访问权限的用户才能访问应用程序,而且只能通过相应的网关来访问。
测试目标:
应用程序级别的安全性:
核实用户只能访问其所属用户类型已被授权访问的那些功能或数据。
系统级别的安全性:
核实只有具备系统和应用程序访问权限的用户才能访问系统和应用程序。
技术:
应用程序级别的安全性:
确定并列出各用户类型及其被授权访问的功能或数据。
为各用户类型创建测试,并通过创建各用户类型所特有的事务来核实其权限。
修改用户类型并为相同的用户重新运行测试。
对于每种用户类型,确保正确地提供或拒绝了这些附加的功能或数据。
系统级别的访问:
请参见以下的“需考虑的特殊事项”
完成标准:
各种已知的用户都可访问相应的功能或数据,而且所有事务都按照预期的方式运行,并在先前的应用程序功能测试中运行了所有的事务。
需考虑的特殊事项:
必须与相应的网络或系统管理员一起对系统访问权进行检查和讨论。
由于此测试可能是网络管理或系统管理的职能,可能会不需要执行此测试。
1.1.4测试文档
ü测试计划
测试总体计划由软件组提供,要求明确人员、时间和测试内容。
测试的详细计划由测试设计人员编写,要求明确人员、时间、测试内容、测试方法及测试所需的数据等。
推荐的测试记录表格如下:
单元测试计划
编号:
编制时间:
计划人:
序号
项目
内容
1
测试对象
2
测试对象描述
3
测试时间
4
测试地点
5
测试人员
6
测试类型
(可多选)
7
测试依据
8
测试目标
9
测试技术
10
测试内容
11
说明
测试计划一式三份,经项目经理签字后生效。
流程测试计划
编号:
编制时间:
计划人:
序号
项目
内容
1
测试对象
2
测试对象描述
3
测试时间
4
测试地点
5
测试人员
6
测试类型
(可多选)
7
测试依据
8
测试目标
9
测试技术
10
流程分解
11
需使用
系统界面
12
需要的
用户角色
13
需要的数据
14
测试内容
15
说明
测试计划一式三份,经项目经理签字后生效。
ü测试报告
用来记录测试的过程和结果,推荐的测试报告表格如下:
单元测试报告编号:
序号
项目
内容
1
测试对象
2
测试对象描述
3
测试地点
4
测试类型
(可多选)
5
测试依据
6
测试目标
7
测试技术
8
测试过程
9
测试结果
10
说明
测试报告一式三份,由项目经理负责审核签字。
测试人
测试时间
流程测试报告编号:
序号
项目
内容
1
测试对象
2
测试对象描述
3
测试地点
4
测试类型
(可多选)
5
测试依据
6
测试目标
7
测试技术
8
流程分解
9
使用的
系统界面
10
使用的用户角色
11
使用的数据
12
测试内容
13
测试结果
14
说明
测试报告一式三份,由项目经理负责审核签字。
测试人
测试时间
ü故障报告
用来汇报测试过程中软件存在的故障,推荐的故障报告表格如下:
故障测试报告编号:
序号
项目
内容
1
测试对象
2
测试对象描述
3
测试类型
(可多选)
4
测试依据
5
测试目标
6
采用的
测试技术
7
软件存在的故障
8
建议更改方式
9
说明
故障报告一式三份,由项目经理和软件实施方负责系统的更改工作。
报告人
报告时间
1.2系统验收
1.2.1功能验收
系统安装调试完毕后,开始进入试运行验收(功能验收),验收合格系统即进入试运行状态。
实施人员将在现场观察并不断调整,使系统保持一种最优工作状态。
功能验收的主要依据是系统测试结果,系统测试包括功能测试、用户界面测试、性能测试、负载测试、强度测试、安全性测试、访问控制测试等,测试的通过标志着系统功能已经按照设计进行了完整实现,信息技术人员及参与测试用户在功能验收明细表中逐项签字确认。
测试中出现的问题进行分级管理,影响系统运行和业务使用的应立即得到修正,并进行回归测试;不影响使用或无法短期解决的非关键问题列表记录,作为功能验收的遗留问题在试运行过程中进行解决。
以上工作完成后双方签署《系统功能验收报告》。
1.2.2系统验收
试运行结束后,可启动系统验收(最终验收)工作。
系统验收的主要工作包括系统和文档的验收测试,系统验收测试基于功能验收时的测试情况及问题列表进行,以验证系统正确性为主要目的。
验收测试中的遗留问题汇总成遗留问题清单,由投标方限期解决,对于影响系统运行和业务正确性的问题必须在系统验收前解决。
文档是软件的重要组成部分,也是软件质量保证和软件配置管理的重要内容。
文档测试主要通过评审的方式检查文档的完整性、准确性、一致性、可追溯性和可理解性。
主要复审以下几点:
Ø确定文档的重要性和项目文档需求,比如,用户文档(用户手册、操作手册、维护手册、联机帮助文件)显得特别重要。
Ø检验文档完整性,主要是文档的种类和内容的完整性。
Ø检验文档的一致性和可追溯性,主要是:
软件的设计描述是否按照需求定义进行展开的;应用程序是否与设计文档的描述一致;用户文档是否客观描述应用程序的实际操作;关于同一问题的描述是否存在不同的说法。
Ø检验文档的准确性,主要是文档的描述是否准确,有无歧义,文字表达是否存在错误。
Ø检验文档的可理解性,主要审核文档是否针对特定的读者群体,表达是否详细。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 系统 测试 验收 方案