系 统 测 试

 

• 定义

System Testing--是将已经集成好的软件系统,作为整个计算机系统的一个元素,与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起,在实际运行使用的环境下,对计算机系统进行系列的测试活动;

• 对象

1.产品级--软件+硬件

2.项目级--软件(也可能包含硬件)

• 完备性

如何保证系统测试的完备性?

1.尽可能所有需求都有对应的Test Case;

2.依据软件的质量特性,以不同的角度,测试需求;

3.依据不同的Test Case、方法,构造不同的测试数据及处理过程;

常用测试方法

1.1 功能测试(功能)

• 定义:

function Testing--依据SRS和测试需求列表验证产品的功能是否实现和是否符合产品需求规格

• 目标:

1.是否有不正确或遗漏了的功能?

2.功能是实现是否满足用户需求,和系统设计的隐式需求?

3.输入能否正确接受?能否正确输出结果?

1.2 性能测试(效率)

• 定义:

Performance Testing--测试该软件在集成系统中的运行性能。(大多使用工具测试)

• 目标:

度量系统相对与预定义目标的差距。

• 实施:

1.性能指标定义明确。

2.构造性能测试研究数据。

3.构造不同的性能测试场景。

4.执行性能测试 (一般>90%就通过)。

5.性能分析。

6.性能故障定位。

7.性能优化。

• 依据

1.资源占用性。

2.CPU响应时间。

• 区别:

1.压力测试--不强调施压量,只检查施压的状况。

2.容量测试--强调施压,施了多少压。

3.性能测试--施压后检验性能指标是否达到规定资源使用和响应时间的要求。

1.2.1 资源方面(资源占用情况)

• CPU使用情况。

• IO使用情况。

• 内存使用情况。

• 信道使用事情。

1.2.2 时间方面(CPU响应时间)

• 每个模块执行时间百分比。

• 一个模块等待IO完成的百分比。

• 指令随时间的跟踪路径。

• 每一组指令页换入和换出的次数。

• 系统反映时间。

• 系统吞吐量,即每个单元的处理数量。

• 所有主要指令的单元执行时间。

1.3 压力测试/极限测试(可靠性)

• 定义:

Stress Testing--系统在其资源超符合的情况下表现。

• 目标:

在极限或者恶劣的环境下,系统的自我保护能力。主要验证系统的可靠性。

• 实施:

1.同一时间,大量的用户登陆。

2.引入大量的操作。

• 目的:

1.是否存在内存泄露。

2.验证系统可靠性。

3.测试后给予用户一个明确的界定。

• 区别:

1.压力测试--不强调施压量,只检查施压的状况。

2.容量测试--强调施压,施了多少压。

3.性能测试--施压后检验性能指标是否达到规定资源使用和响应时间的要求。

1.4 容量测试

• 定义:

volume Testing--使系统能够承受超额的数据容量来发现它是否能够正确处理。

• 目标:

1.测试系统容量是否满足需求规定系统容量。

2.若无规定系统容量可以通过此测试给出明确容量界定。

• 实施:

1.构造一批大容量的测试数据输入到系统。

2.对系统整体构造不同业务场景,反复执行。

• 区别:

1.压力测试--不强调施压量,只检查施压的状况。

2.容量测试--强调施压,施了多少压。

      3.性能测试--施压后检验性能指标是否达到规定资源使用和响应时间的要求。

1.5 安全性测试(功能)

• 定义:

Security Testing--验证集成在系统内的保护机制能否在实际应用中保护系统不受到非法的侵入。

• 目的:

保证系统安全性,数据的完整性、保密性。

1.5.1 数据

完整性

• 数据存储的完整性。

• 数据保密的完整性。

保密性

• 数据存储的保密性。

• 数据访问的保密性。

1.5.2 权限

• 权限的分配

• 权限的使用

1.5.3 协议

多在手机测试用到。

1.5.4 其他

如LOG..

1.6 GUI测试(易用)

• 定义:

Graphical User Interface Testing--针对软件系统的界面进行的测试。

• 目标:

1.界面实现与界面设计的吻合情况。(界面设计)

2.确认界面处理的正确性。(针对不同的控件分析)

• 相关自动化测试工具

1.WinRunner

2.SilkTest

3.QaRun 

1.6.1 简单界面元素

• 定义:

指功能和属性相对比较单一的界面区域,即通常所指的各种控件。

• 方法:

主要关注他们的外观、表现行为。

1.6.2 组合类界面元素

• 定义:

一些复杂的界面元素,比如表格、各种文本编辑器等。

• 方法:

先将其分解为简单的界面元素,然后再进行处理。

1.6.3 完整界面(窗口)

• 定义:

由一系列界面元素通过适当的形式组合而成的界面形式,最为常见的为各种窗口。包括各种对话框、单文档窗口、多文档窗口,多文档子窗口等。

• 方法:

外观、布局、行为。

1.输入类界面元素:与要考虑其外观、输入时的特性比如回显、对齐原则、滚动原则等内容。

2.输出类界面元素:外观。

 

1.7 可用性测试(易用)

• 定义:

Usability Testing--为检测用户在理解和使用系统方面到底有多好。

• 目标:

1.考虑产品是否符合实际应用情况。

2.是否符合用户习惯或特殊要求。

3.操作方式是否方便合理、设备和用户见交互信息是否准确易于理解、是否遵从行业习惯、外观/界面是否美观等。

• 一般关注的可用性问题:

1.过分复杂的功能或指令。

2.困难的安装过程。

3.错误信息过于简单。

4.用户被迫去记太多信息。

5.语法、格式和定义不一致。

 

1.8 安装测试

• 定义:

根据软件测试特性列表、软件安装、配置文档,设计安装过程的测试用例,发现软件在安装过程中的错误。

• 被测对象:

1.软件本身。

2.软件安装文档。

1.8.1 安装测试前要检查的工作

1.安装文档是否齐全。

2.安装软件的程序文件是否齐全。

3.被测软件的安装文件是否齐全。

4.软件的安装说明文档是否齐全。

5.检查软件的文件格式是否与安装说明文档中要求的文件格式相符。

1.8.2 安装测试过程中的工作

1.所有的预置数据是齐全。

2.软件环境配置是否合理。

3.硬件环境配置是否合理。

4.用户选择的一套任选方案是相容。¦

5.安装过程中:

A.系统提供的缺省参数值进行安装测试。

B.指定由人工完成安装过程,列出每一步安装步骤所需的工作,并仔细检查每一安装步骤所完成工作的正确性。

C.安装测试过程中要设计异常的安装测试用例,包括配置参数的异常、安装选项和安装路径的异常。

6.安装文档的测试。

1.8.3 安装后要做的检查工作

1.所有文件是否都已产生并确有所需的内容。

   A.程序文件的目录是否正确产生。

   B.各目录及子目录下的程序文件是否都正确产生。

   C.是否存在无用的目录、子目录、程序文件以及无用的子目录。

   D.目录、子目录、以及程序文件本身的权限是否正确。

   E.对于Windows 还要检查与应用软件相配套的动态链接库文件齐全。

2.安装日志的检查。

3.安装完成后,要进行程序的运行,联结验证。

4.软件的卸载测试。

1.8.4 安装测试中软件的升级测试

1.软件通过重新安装来达到升级的目的。

2.通过Patch的方式实现软件的升级。

3.在线升级。

 

1.9 配置测试

• 定义:

系统在各种软硬件配置、不同参数配置下系统具有的功能和性能。

• 目标:

验证全部配置的可操作性,有效性。

 

1.10 异常测试/恢复性测试(可靠)

• 定义:

容错性测试。通过人工干预手段产生异常,能检验系统的容错、恢复能力,是系统可靠性评价的重要手段。

• 异常处理

1.系统自动处理。

2.人工干预处理。

• 注意

1.系统的异常还与系统的指标测试有关,当系统的服务能力大于系统的设计指标时,也属于系统的异常情况。

2.系统的可靠性是设计出来的,而不是测试出来的。测试出的数据有助于为我们进一步的系统优化设计积累经验,设计和测试是一个相互反馈的过程。

 

1.11 备份测试(可靠)

恢复性测试的一个补充,验证软件或硬件失败中备份他数据的能力。

1.12 健壮性测试(可靠)

Robustness Testing 用于测试系统在故障时,是否能够自动恢复或者忽略故障继续运行。

1.13 文档测试

Documentation Testing 测试文档的正确性,保证操作手册的过程能够正常工作。

1.14 在线帮助测试

Online Help Testing 检测时实在线帮助的可靠性和正确性。

1.15 网络测试

网络环境下和其他设备对接,进行系统功能、性能与指标方面的测试,保证对接的正确性。

1.16 稳定性测试

在一定负荷情况下能持续运行的时间。

 

2 系统测试测试过程

2.1 计划阶段

明确what目标、why测试目的、when可控时间、where测试范围、how如何开展.主要活动有:参与开发人员软件需求的分析,SRS评审,通过后写ST计划,进行ST计划评审。

• 入口准则:SRS完成并确定需求规格基线

• 输入:SRS|SDP|SVVP

• 出口准则:ST计划评审通过

• 输出:

2.2 设计阶段

主要活动有:组织人员依据测试计划编写测试方案,并进行系统方案的评审

• 入口准则:  ST计划评审通过

• 输入:         ST计划|SRS

• 出口准则:  ST方案评审通过

• 输出:         ST方案

 

2.3 实现阶段

主要活动有:组织人员依据ST方案编写测试用例、测试规程及预测试项,并对其进行评审

• 入口准则:  ST方案评审通过

• 输入:         ST计划|SRS|ST方案

• 出口准则:  测试用例、测试规程及预测试项评审通过

• 输出:         测试用例、测试规程及预测试项

 

2.4 执行阶段

主要活动有:组织测试执行活动、负责缺陷报告返回给开发部门修改、组织进行测试报告的编写、组织进行测试报告的评审

• 入口准则:  测试用例、测试规程及预测试项的评审通过

• 输入:         ST计划|ST方案|ST用例|ST规程|ST预测试项

• 出口准则:  ST报告评审并通过

• 输出:         ST预测试报告|ST测试报告|缺陷报告

 

posted on 2015-05-03 17:47  2班&王艺蓉  阅读(192)  评论(0编辑  收藏  举报