系统测试内容.docx

系统测试内容.docx

《系统测试内容.docx》由会员分享，可在线阅读，更多相关《系统测试内容.docx（11页珍藏版）》请在冰豆网上搜索。

系统测试内容

系统测试

[键入文档副标题]

JonMMx2000

[选取日期]

系统测试要根据软件设计需求来进行，但在实际测试中需要依据项目用户对软件的质量要求来有侧重点的进行。

系统测试一般应符合以下技术要求：

✧系统的每个特性应至少被一个正常测试用例和一个被认可的异常测试用例所覆盖。

✧应测试软件配置项之间及软件配置项与硬件之间的接口。

✧测试用例的输入应至少包括有效等价类值、无效等价类值和边界数据值。

✧应逐项测试系统/子系统设计说明规定的系统的功能、性能等特性。

✧应测试系统的输出及其格式。

✧应测试运行条件在边界状态和异常状态下，或在认为设定的状态下，系统的功能和性能。

✧对不同的实际问题应外加相应的专门测试。

✧对完整性级别高的系统，应对其进行安全性、可靠性分析，明确每一个危险状态和导致危险的可能原因，并对此进行针对性的测试。

✧应测试系统访问和数据安全性。

✧应按系统或子系统设计文档的要求，对系统的功能、性能进行强度测试。

✧应测试系统的全部存储量、输入/输出通道和处理时间的余量。

✧应测试设计中用于提高系统安全性、可靠性的结构、算法、容错、冗余、中断处理等方案。

✧对有恢复或重置功能需求的系统，应测试其恢复或重置功能和平均恢复时间，并且对每一类导致恢复或重置的情况进行测试。

国标GB/T16620针对系统测试的测试内容主要从：

适应性、准确性、互操作性、安全保密性、成熟性、容错性、易恢复性、易理解性、易学性、易操作性、吸引性、时间特性、资源利用性、易分析性、易改变性、稳定性、易测试性、适应性、易安装性、共存性、替换性和依从性等（有选择的）来考虑。

对具体的系统，可根据或项目计划及系统/子系统设计文档的要求对上述测试内容进行剪裁。

1.功能性

1.1.适应性

从适应性考虑，应测试系统/子系统设计文档规定的系统的每一项功能。

1.2.准确性

从准确性考虑，可对系统中具有准确性要求的功能和精度要求的项（如数据处理精度、时间控制精度、时间测量精度）进行测试。

1.3.互操作性

从互操作性考虑，可测试系统/子系统设计文档、接口需求规格说明文档和接口设计文档规定的系统与外部设备的接口、与其他系统的接口。

测试其格式和内容，包括数据交换的数据格式和内容；测试接口之间的协调性；测试软件对系统每一个真实接口的正确性；测试软件系统从接口接收和发送数据的能力；测试数据的约定、协议的一致性；测试软件系统对外围设备接口特性的适应性。

1.4.安全保密性

从安全保密性，可测试系统及其数据访问的可控制性。

测试系统防止非法操作的模式，包括防止非授权的创建、删除或修改程序或信息，必要时做强化异常操作的测试。

测试系统防止数据被讹误和被破坏的能力。

测试系统的加密和解密功能。

2.可靠性

2.1.成熟性

在成熟性，可基于系统运行剖面设计测试用例，根据实际使用的概率分布随机选择输入，运行系统，测试系统满足需求的程度并获取失效数据，其中包括对重要输入变量值的覆盖、对相关输入变量可能组合的覆盖、对设计输入空间与实际输入空间之间区域的覆盖、对各种使用功能的覆盖、对使用环境的覆盖。

应在有代表性的使用环境中、以及可能影响系统运行方式的环境中运行软件，验证系统的可靠性需求是否正确实现。

对一些特殊的系统，如容错软件、实时嵌入式软件等，由于在一般的使用环境下常常很难在软件中植入差错，应考虑多种测试环境。

测试系统的平均无故障时间。

选择可靠性增长模型，通过检测到的失效数和故障数，对系统的可靠性进行预测。

2.2.容错性

从容错性考虑，可测试：

✧系统对中断发生的反应。

✧系统在边界条件下的反应。

✧系统的功能、性能的降级情况。

✧系统的各种误操作模式。

✧系统的各种故障模式（如数据超范围、死锁）。

✧测试在多机系统出现故障需要切换时系统的功能和性能的连续平稳性。

注：

可用故障树分析技术检测误操作模式和故障模式。

2.3.易恢复性

从易恢复性考虑，可测试：

✧具有自动修复功能的系统的自动修复的时间。

✧系统在特定的时间范围内的平均宕机时间。

✧系统在特定的时间范围内的平均恢复时间。

✧系统的重新启动并继续提供服务的能力。

✧系统的还原功能的还原能力。

3.易用性

3.1.易理解

✧系统的各项功能，确认它们是否容易被识别和被理解。

✧要求具有演示功能的能力，确认演示是否容易被访问、演示是否充分和有效。

✧界面的输入和输出，确认输入和输出的格式和含义是否容易被理解。

3.2.易学性

从易学性考虑，可测试系统的在线帮助，确认在线帮助是否容易定位，是否有效；还可以对照用户手册或操作手册执行系统，测试用户文档的有效性。

3.3.易操作性

✧输入数据，确认系统是否对输入数据进行有效性检查。

✧要求具有中断执行的功能，确认它们能否在动作完成之前被取消。

✧要求具有还原能力（数据库的事务回滚能力）的功能，确认它们能否在动作完成之后被撤销。

✧包含参数设置的功能，确认参数是否已选择、是否有缺省值。

✧要求具有解释的消息，确认它们是否明确。

✧要求具有界面提示能力的界面元素，确认它们是否有效。

✧要求具有容错能力的功能和操作，确认系统能否提示出错的风险、能否容易纠正错误的输入、能否从差错中恢复。

✧要求具有定制能力的功能和操作，确认定制能力的有效性。

✧要求具有运行状态监控能力的功能，确认它们的有效性。

注：

以正确操作、误操作模式、非常规模式和快速操作为框架设计测试用例，误操作模式有错误的数据类型作参数、错误的输入数据序列、错误的操作序列等。

如有用户手册或操作手册，可对照手册逐条进行测试。

3.4.从吸引性

从吸引性考虑，可测试系统的人机交互界面能否定制。

4.效率

4.1.时间特性

从时间特性考虑，可测试系统的响应时间、平均响应时间、响应极限时间，系统的吞吐量、平均吞吐量，系统的周转时间、平均周转时间、周转时间极限。

注：

响应时间指系统为完成一项规定任务所需的时间；平均响应时间指系统执行若干并行任务所需的平均时间；响应极限时间指在最大负载条件下，系统完成某项任务需要时间的极限；吞吐量指在给定的时间周期内系统能成功完成的任务数量；平均吞吐量指在一个单位时间内系统能处理并发任务的平均数；极限吞吐量指在最大负载条件下，在给定的时间周期内，系统能处理的最多并发任务数；周转时间指从发出一条指令开始到一组相关的任务完成的时间；平均周转时间指在一个特定的负载条件下，对一些并发任务，从发出请求到任务完成所需要的平均时间；周转时间极限指在最大负载条件下，系统完成一线任务所需要时间的极限。

在测试时，应标识和定义适合于软件应用的任务，并对多项任务进行测试，而不是仅测一项任务。

注：

软件应用任务的例子，如在通信应用中的切换、数据包发送、在控制应用中的事件控制，在公共用户应用中由用户调用的功能产生的一个数据的输出等。

4.2.资源利用性

从资源利用性考虑，可测试系统的输入/输出设备、内存和传输资源的利用情况：

✧执行大量的并发任务，测试输入/输出设备的利用时间。

✧在使输入/输出负载达到最大的系统条件下，运行系统，测试输入/输出负载极限。

✧并发执行大量的任务，测试用户等待输入/输出设备操作完成需要的时间。

✧注：

建议调查几次测试与运行实例中的最大时间与时间分布。

✧在规定的负载下和在规定的时间范围内运行系统，测试内存的利用情况。

✧在最大负载下运行系统，测试内存的利用情况。

✧并发执行规定的数个任务，测试系统的传输能力。

✧在系统负载最大的条件下和在规定的时间周期内，测试传输资源的利用情况。

✧在系统传输负载最大条件下，测试不同介质同步完成其任务的时间周期。

5.维护性

5.1.易分析性

从易分析性考虑，可设计各种情况的测试用例运行系统，并监测系统运行状态数据，检查这些数据是否容易获得、内容是否充分。

如果软件具有诊断功能，应测试该功能。

5.2.易改变性

从易改变性考虑，可测试能否通过参数来改变系统。

5.3.易测试性

从易测试性考虑，可测试软件内置的测试功能，确认它们是否完整和有效。

6.可移植性

6.1.适应性

从适应性考虑，可测试：

✧软件对诸如数据文件、数据块或数据库等数据结构的适应能力。

✧软件对硬件设备和网络设施等硬件环境的适应能力。

✧软件对系统软件或并行的应用软件等软件环境的适应能力。

✧软件是否已移植。

6.2.易安装性

从易安装性考虑，可测试软件安装的工作量、安装的可定制性、安装设计的完备性、安装操作的简易性、是否容易重新安装。

　　注：

安装设计的完备性可分为三级

　　a）最好：

设计了安装程序，并编写了安装指南文档。

　　b）好：

仅编写了安装指南文档。

　　c）差：

无安装程序和安装指南文档。

　　注：

安装操作的简易性可分为四级。

　　a）非常容易：

只需启动安装功能并观察安装过程。

　　b）容易：

只需回答安装功能中提出的问题。

　　c）不容易：

需要从表或填充框中看参数。

　　d）复杂：

需要从文件中寻找参数，改变或写它们。

6.3.共存性

从共存性考虑，可测试软件与其他软件共同运行的情况。

6.4.易替换性

当替换整个不同的软件系统和用同一软件系列的高版本替换低版本时，在易替换性，可考虑测试：

　　a）软件能否继续使用被其替代的软件使用过的数据。

　　b）软件是否具有被其替代的软件中的类似功能。

6.5.依从性

当软件在功能性、可靠性、易用性、效率、维护性和可移植性遵循了相关的标准、约定、风格指南或法规时，应酌情进行测试。

上述基于软件质量特性/子特性的系统测试内容对应到传统的软件测试类型如下所示：

✧功能测试

目标：

对产品的功能进行测试，检验是否实现、是否正确实现；

方法：

覆盖产品的功能；

工具：

回归测试时候可以使用工具。

✧性能测试

目标：

对产品的性能进行测试，检验是否达标、是否能够保持；

方法：

覆盖系统的性能需求，一般和负载测试结合使用；

工具：

在需要大访问量时候尤其需要使用工具。

✧负载测试

目标：

在人为设置的高负载（大数据量、大访问量）的情况下，检查系统是否发生功能或者性能上的问题；

方法：

人为生成大数据量，并利用工具模拟频繁并发访问；

工具：

一般需要使用工具。

✧压力测试

目标：

在人为设置的系统资源紧缺情况下，检查系统是否发生功能或者性能上的问题；

方法：

人为减少可用的系统资源，包括：

内存、硬盘、网络、CPU占用、数据库反应时间等；

工具：

一般需要使用工具。

✧疲劳测试

目标：

在一段时间内（经验上一般是连续72小时）保持系统功能的频繁使用，检查系统是否发生功能或者性能上的问题；

方法：

人为设置不同功能的连续重复操作；

工具：

一般需要使用工具。

✧易用性测试

目标：

检查系统界面和功能是否容易学习、使用方式是否规范一致，是否会误导用户或者使用模糊的信息；

方法：

可以采用用户操作、观察（录像）、反馈并评估的方式，一般与功能测试结合使用。

✧安装测试

目标：

检查系统安装是否能够安装所有需要的文件/数据并进行必要的系统设置，检查系统安装是否会破坏其他文件或配置，检查系统安装是否可以中止并恢复现场，检查系统是否能够正确卸载并恢复现场，检查安装和卸载过程的用户提示和功能是否出现错误。

有时候将安装测试作为功能测试的一部分。

✧配置测试

目标：

在不同的硬件配置下，在不同的操作系统和应用软件环境中，检查系统是否发生功能或者性能上的问题；

方法：

一般需要建立测试实验室。

✧文档测试

目标：

检查系统的文档是否齐全，检查是否有多余文档或者死文档，检查文档内容是否正确/规范/一致等；

方法：

一般由单独的一组测试人员实施。

✧安全测试（包括病毒、加密、权限）

目标：

检查系统是否有病毒，检查系统是否正确加密，检查系统在非授权的内部或外部用户访问或故意破坏时是否出现错误。

✧恢复测试

目标：

在人为发生系统灾难（系统崩溃、硬件损坏、病毒入侵等）的情况下，检查系统是否能恢复被破坏的环境和数据。

✧回归测试

定义回归测试是一种选择性重新测试，目的是检测系统或系统组成部分在修改期间产生的缺陷，用于验证已进行的修改并未引起不希望的有害效果，或确认修改后的系统或系统组成部分仍满足规定的要求；目标检查系统变更之后是否引入新的错误或者旧的错误重新出现，尤其是在每次Build之后和稳定期测试的时候；一般使用工具，一般依赖于测试用例库和缺陷报告库。

✧健全测试

目标：

检查系统的功能和性能是否基本可以正常使用，来确定是否可以继续进行系统测试的其他内容；

方法：

正常安装，并使用正常情况下的测试用例对主要功能进行测试；同时检查系统文档是否齐全。

✧交付测试

目标：

关闭所有缺陷报告，确保系统达到预期的交付标准；

方法：

一般需要结合回归测试，并谨慎处理新出现的Bug。

交付测试也称为稳定期测试，有时候与系统测试独立划分。

✧演练测试

目标：

在交付给用户之前，利用相似的用户环境进行测试。

例如：

奥运会MIS系统在2008年前用于其他比赛。

✧背靠背测试

目标：

设置一组以上的测试团队，在互相不进行沟通的情况下独立进行相同的测试项目，用来评估测试团队的效果并发现更多的错误。

开始用于测试外包，现在也用于内部测试。

✧度量测试

目标：

在系统中人为地放入错误（播种），并根据被发现的比例来确定系统中遗留的错误数量。

开始用于测试外包，现在也用于内部测试。

✧比较测试

目标：

与竞争产品及本产品的旧版本测试同样的内容，来确定系统的优势和劣势。

严格地说，比较测试属于系统测评的内容，BenchMarking是一种特殊的比较测试。

上述测试内容并非需要一起进行，实施项目测试时，依据项目测试目标、测试资源、软件系统特点和业务环境等信息，在制定测试策略和测试计划的时可有侧重地进行灵活调配。

所有测试最好由独立第三方进行。

因为进行独立测试的目的是进一步加强软件质量保证工作，提高软件的质量，并对软件产品进行客观评价。

而进行第三方独立测试通常有发挥专业技术优势和独立性优势，能够有效地促进承办方的工作等的优势。