软件测试方案.docx
- 文档编号:9662297
- 上传时间:2023-02-05
- 格式:DOCX
- 页数:10
- 大小:19.51KB
软件测试方案.docx
《软件测试方案.docx》由会员分享,可在线阅读,更多相关《软件测试方案.docx(10页珍藏版)》请在冰豆网上搜索。
软件测试方案
一、功能性测试
适应性测试
从适应性考虑,应测试系统/子系统设计文档规定的系统的每一项功能。
准确性测试
从准确性考虑,可对系统中具有准确性要求的功能和精度要求的项(如数据处理精度、时间控制精度、时间测量精度)进行测试。
互操作性测试
从互操作性考虑,可测试系统/子系统设计文档、接口需求规格说明文档和接口设计文档规定的系统与外部设备的接口、与其他系统的接口。
测试其格式和内容,包括数据交换的数据格式和内容;测试接口之间的协调性;测试软件对系统每一个真实接口的正确性;测试软件系统从接口接收和发送数据的能力;测试数据的约定、协议的一致性;测试软件系统对外围设备接口特性的适应性。
安全保密性测试
Ø从安全保密性,可测试系统及其数据访问的可控制性。
Ø测试系统防止非法操作的模式,包括防止非授权的创建、删除或修改程序或信息,必要时做强化异常操作的测试。
Ø测试系统防止数据被讹误和被破坏的能力。
Ø测试系统的加密和解密功能。
二、可靠性测试
成熟性测试
在成熟性,可基于系统运行剖面设计测试用例,根据实际使用的概率分布随机选择输入,运行系统,测试系统满足需求的程度并获取失效数据,其中包括对重要输入变量值的覆盖、对相关输入变量可能组合的覆盖、对设计输入空间与实际输入空间之间区域的覆盖、对各种使用功能的覆盖、对使用环境的覆盖。
应在有代表性的使用环境中、以及可能影响系统运行方式的环境中运行软件,验证系统的可靠性需求是否正确实现。
对一些特殊的系统,如容错软件、实时嵌入式软件等,由于在一般的使用环境下常常很难在软件中植入差错,应考虑多种测试环境。
测试系统的平均无故障时间。
选择可靠性增长模型,通过检测到的失效数和故障数,对系统的可靠性进行预测。
容错性测试
从容错性考虑,可测试:
Ø系统对中断发生的反应。
Ø系统在边界条件下的反应。
Ø系统的功能、性能的降级情况。
Ø系统的各种误操作模式。
Ø系统的各种故障模式(如数据超出范围、死锁等)。
Ø测试在多机系统出现故障需要切换时系统的功能和性能的连续平稳性。
注:
可用故障树分析技术检测误操作模式和故障模式。
易恢复性测试
从易恢复性考虑,可测试:
Ø具有自动修复功能的系统的自动修复的时间。
Ø系统在特定的时间范围内的平均宕机时间。
Ø系统在特定的时间范围内的平均恢复时间。
Ø系统的重新启动并继续提供服务的能力。
Ø系统的还原功能的还原能力。
三、易用性测试
易理解测试
Ø系统的各项功能,确认它们是否容易被识别和被理解。
Ø要求具有演示功能的能力,确认演示是否容易被访问、演示是否充分和有效。
Ø界面的输入和输出,确认输入和输出的格式和含义是否容易被理解。
易学性测试
从易学性考虑,可测试系统的在线帮助,确认在线帮助是否容易定位,是否有效;还可以对照用户手册或操作手册执行系统,测试用户文档的有效性。
易操作性测试
Ø输入数据,确认系统是否对输入数据进行有效性检查。
Ø要求具有中断执行的功能,确认它们能否在动作完成之前被取消。
Ø要求具有还原能力(数据库恢复能力)的功能,确认它们能否在动作完成之后被撤销。
Ø包含参数设置的功能,确认参数是否已选择、是否有缺省值。
Ø要求具有解释的消息,确认它们是否明确。
Ø要求具有界面提示能力的界面元素,确认它们是否有效。
Ø要求具有容错能力的功能和操作,确认系统能否提示出错的风险、能否容易纠正错误的输入、能否从差错中恢复。
Ø要求具有定制能力的功能和操作,确认定制能力的有效性。
Ø要求具有运行状态监控能力的功能,确认它们的有效性。
注:
以正确操作、误操作模式、非常规模式和快速操作为框架设计测试用例,误操作模式有错误的数据类型作参数、错误的输入数据序列、错误的操作序列等。
如有用户手册或操作手册,可对照手册逐条进行测试。
吸引性测试
从吸引性考虑,可测试系统的人机交互界面能否定制。
四、效率测试
时间特性测试
从时间特性考虑,可测试系统的响应时间、平均响应时间、响应极限时间,系统的吞吐量、平均吞吐量,系统的周转时间、平均周转时间、周转时间极限。
注:
响应时间指系统为完成一项规定任务所需的时间;平均响应时间指系统执行若干并行任务所需的平均时间;响应极限时间指在最大负载条件下,系统完成某项任务需要时间的极限;吞吐量指在给定的时间周期内系统能成功完成的任务数量;平均吞吐量指在一个单位时间内系统能处理并发任务的平均数;极限吞吐量指在最大负载条件下,在给定的时间周期内,系统能处理的最多并发任务数;周转时间指从发出一条指令开始到一组相关的任务完成的时间;平均周转时间指在一个特定的负载条件下,对一些并发任务,从发出请求到任务完成所需要的平均时间;周转时间极限指在最大负载条件下,系统完成一线任务所需要时间的极限。
在测试时,应标识和定义适合于软件应用的任务,并对多项任务进行测试,而不是仅测一项任务。
注:
软件应用任务的例子,如在通信应用中的切换、数据包发送、在控制应用中的事件控制,在公共用户应用中由用户调用的功能产生的一个数据的输出等。
资源利用性测试
从资源利用性考虑,可测试系统的输入/输出设备、内存和传输资源的利用情况:
Ø执行大量的并发任务,测试输入/输出设备的利用时间。
Ø在使输入/输出负载达到最大的系统条件下,运行系统,测试输入/输出负载极限。
Ø并发执行大量的任务,测试用户等待输入/输出设备操作完成需要的时间。
注:
建议调查几次测试与运行实例中的最大时间与时间分布。
Ø在规定的负载下和在规定的时间范围内运行系统,测试内存的利用情况。
Ø在最大负载下运行系统,测试内存的利用情况。
Ø并发执行规定的数个任务,测试系统的传输能力。
Ø在系统负载最大的条件下和在规定的时间周期内,测试传输资源的利用情况。
Ø在系统传输负载最大条件下,测试不同介质同步完成其任务的时间周期。
五、维护性测试
易分析性测试
从易分析性考虑,可设计各种情况的测试用例运行系统,并监测系统运行状态数据,检查这些数据是否容易获得、内容是否充分。
如果软件具有诊断功能,应测试该功能。
易改变性测试
从易改变性考虑,可测试能否通过参数来改变系统。
易测试性测试
从易测试性考虑,可测试软件内置的测试功能,确认它们是否完整和有效。
六、可移植性测试
适应性测试
从适应性考虑,可测试:
Ø软件对诸如数据文件、数据块或数据库等数据结构的适应能力。
Ø软件对硬件设备和网络设施等硬件环境的适应能力。
Ø软件对系统软件或并行的应用软件等软件环境的适应能力。
Ø软件是否已移植。
易安装性测试
从易安装性考虑,可测试软件安装的工作量、安装的可定制性、安装设计的完备性、安装操作的简易性、是否容易重新安装。
注:
安装设计的完备性可分为三级
Ø最好:
设计了安装程序,并编写了安装指南文档。
Ø好:
仅编写了安装指南文档。
Ø差:
无安装程序和安装指南文档。
注:
安装操作的简易性可分为四级。
Ø非常容易:
只需启动安装功能并观察安装过程。
Ø容易:
只需回答安装功能中提出的问题。
Ø不容易:
需要从表或填充框中看参数。
Ø复杂:
需要从文件中寻找参数,改变或写它们。
共存性测试
从共存性考虑,可测试软件与其他软件共同运行的情况。
易替换性测试
当替换整个不同的软件系统和用同一软件系列的高版本替换低版本时,在易替换性,可考虑测试:
Ø软件能否继续使用被其替代的软件使用过的数据。
Ø软件是否具有被其替代的软件中的类似功能。
依从性测试
当软件在功能性、可靠性、易用性、效率、维护性和可移植性遵循了相关的标准、约定、风格指南或法规时,应酌情进行测试。
上述基于软件质量特性/子特性的系统测试内容对应到传统的软件测试类型如下所示:
Ø功能测试
目标:
对产品的功能进行测试,检验是否实现、是否正确实现;
方法:
覆盖产品的功能;
工具:
回归测试时候可以使用工具。
Ø性能测试
目标:
对产品的性能进行测试,检验是否达标、是否能够保持;
方法:
覆盖系统的性能需求,一般和负载测试结合使用;
工具:
在需要大访问量时候尤其需要使用工具。
Ø负载测试
目标:
在人为设置的高负载(大数据量、大访问量)的情况下,检查系统是否发生功能或者性能上的问题;
方法:
人为生成大数据量,并利用工具模拟频繁并发访问;
工具:
一般需要使用工具。
Ø压力测试
目标:
在人为设置的系统资源紧缺情况下,检查系统是否发生功能或者性能上的问题;
方法:
人为减少可用的系统资源,包括:
内存、硬盘、网络、CPU占用、数据库反应时间等;
工具:
一般需要使用工具。
Ø疲劳测试
目标:
在一段时间内(经验上一般是连续72小时)保持系统功能的频繁使用,检查系统是否发生功能或者性能上的问题;
方法:
人为设置不同功能的连续重复操作;
工具:
一般需要使用工具。
Ø易用性测试
目标:
检查系统界面和功能是否容易学习、使用方式是否规范一致,是否会误导用户或者使用模糊的信息;
方法:
可以采用用户操作、观察(录像)、反馈并评估的方式,一般与功能测试结合使用。
Ø安装测试
目标:
检查系统安装是否能够安装所有需要的文件/数据并进行必要的系统设置,检查系统安装是否会破坏其他文件或配置,检查系统安装是否可以中止并恢复现场,检查系统是否能够正确卸载并恢复现场,检查安装和卸载过程的用户提示和功能是否出现错误。
有时候将安装测试作为功能测试的一部分。
Ø配置测试
目标:
在不同的硬件配置下,在不同的操作系统和应用软件环境中,检查系统是否发生功能或者性能上的问题;
方法:
一般需要建立测试实验室。
Ø文档测试
目标:
检查系统的文档是否齐全,检查是否有多余文档或者死文档,检查文档内容是否正确/规范/一致等;
方法:
一般由单独的一组测试人员实施。
Ø安全测试(包括病毒、加密、权限)
目标:
检查系统是否有病毒,检查系统是否正确加密,检查系统在非授权的内部或外部用户访问或故意破坏时是否出现错误。
Ø恢复测试
目标:
在人为发生系统灾难(系统崩溃、硬件损坏、病毒入侵等)的情况下,检查系统是否能恢复被破坏的环境和数据。
Ø回归测试
定义回归测试是一种选择性重新测试,目的是检测系统或系统组成部分在修改期间产生的缺陷,用于验证已进行的修改并未引起不希望的有害效果,或确认修改后的系统或系统组成部分仍满足规定的要求;目标检查系统变更之后是否引入新的错误或者旧的错误重新出现,尤其是在每次Build之后和稳定期测试的时候;一般使用工具,一般依赖于测试用例库和缺陷报告库。
Ø健全测试
目标:
检查系统的功能和性能是否基本可以正常使用,来确定是否可以继续进行系统测试的其他内容;
方法:
正常安装,并使用正常情况下的测试用例对主要功能进行测试;同时检查系统文档是否齐全。
Ø交付测试
目标:
关闭所有缺陷报告,确保系统达到预期的交付标准;
方法:
一般需要结合回归测试,并谨慎处理新出现的Bug。
交付测试也称为稳定期测试,有时候与系统测试独立划分。
Ø演练测试
目标:
在交付给用户之前,利用相似的用户环境进行测试。
Ø背靠背测试
目标:
设置一组以上的测试团队,在互相不进行沟通的情况下独立进行相同的测试项目,用来评估测试团队的效果并发现更多的错误。
开始用于测试外包,现在也用于内部测试。
Ø度量测试
目标:
在系统中人为地放入错误(播种),并根据被发现的比例来确定系统中遗留的错误数量。
开始用于测试外包,现在也用于内部测试。
Ø比较测试
目标:
与竞争产品及本产品的旧版本测试同样的内容,来确定系统的优势和劣势。
严格地说,比较测试属于系统测评的内容,BenchMarking是一种特殊的比较测试。
上述测试内容并非需要一起进行,实施项目测试时,依据项目测试目标、测试资源、软件系统特点和业务环境等信息,在制定测试策略和测试计划的时可有侧重地进行灵活调配。
所有测试最好由独立第三方进行。
因为进行独立测试的目的是进一步加强软件质量保证工作,提高软件的质量,并对软件产品进行客观评价。
而进行第三方独立测试通常有发挥专业技术优势和独立性优势,能够有效地促进承办方的工作等的优势。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 测试 方案