软件测试规范Word文件下载.docx

软件测试规范Word文件下载.docx

《软件测试规范Word文件下载.docx》由会员分享，可在线阅读，更多相关《软件测试规范Word文件下载.docx（76页珍藏版）》请在冰豆网上搜索。

8　系统测试18

8.1　测试对象和目的18

8.2　测试的组织和管理19

8.3　技术要求19

8.4　测试内容19

8.5　测试环境22

8.6　测试方法22

8.7　测试过程22

8.8　文档23

9　验收测试23

9.1　测试对象和目的23

9.2　测试的组织和管理23

9.3　技术要求23

9.4　测试内容23

9.5　测试环境23

9.6　测试方法24

9.7　测试过程24

9.8　文档25

10　归回测试25

10.1　测试对象和目的25

10.2　单元回归测试25

10.3　配置项回归测试26

10.4　系统回归测试28

11　测试停止标准29

11.1　指标29

11.2　测试停止标准29

12　软件维护规范30

12.1　软件维护的内容与类型30

12.2　维护过程30

附录A（资料性附录）　软件测试方法32

附录B（资料性附录）　软件可靠性的推荐模型33

附录C（资料性附录）　软件测试部分模版34

附录D（资料性附录）　软件测试内容的对应关系35

上位机软件测试规范

1　范围

本标准规定了XXX公司上位机软件生存周期内各类软件产品的基本测试方法、过程和准则。

本标准适用于XXX公司上位机软件生存周期全过程。

本标准适用于上位机软件的开发机构、测试机构及相关人员。

2　规范性引用文件

下列文件对于本文件的应用是必不可少的。

凡是注日期的引用文件，仅所注日期的版本适用于本文件。

凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。

GB/T8566信息技术软件生存周期过程（GB/T8566-2007,ISO/IEC12207：

1995，MOD）

GB/T9386计算机软件测试文档编码规范

GB/T11457信息技术软件工程术语

GB/T16260.1软件工程产品质量第1部分：

质量模型（GB/T16260.1--2006，ISO/IEC9126-1：

2001，IDT）

GB/T18492信息技术系统及软件完整性级别（GB/T18492—2001,ISO/IEC15026:

1998,IDT）

GB/T20158信息技术软件生存周期配置管理（GB/T20158—2006，ISO/IECTR15846：

1998IDT）

3　术语和定义

GB/T11457中确立的术语和定义适用于本标准。

4　总则

4.1　测试目的

a）验证软件是否满足软件开发合同或项目开发计划、系统/子系统设计文档、软件需求规格说明、软件设计说明和软件产品说明等规定的软件质量要求；

b）通过测试，发现软件缺陷；

c）为软件产品的质量测试和评价提供依据。

4.2　测试类别

根据GB/T8566的要求，本标准对如下测试类别分别作详细描述：

a）单元测试；

b）集成测试；

c）配置项测试（也称软件和个性测试或确认测试）；

d）系统测试；

e）验收测试。

可根据软件的规模、类型、完整性级别选择执行测试类别。

回归测试可出现在上述每个测试类别中，并贯穿于整个软件生存周期，故单独分类进行描述。

4.3　测试过程

概述

软件测试过程一般包括四项活动，按顺序分别是：

测试策划、测试设计、测试执行、测试总结。

测试策划

测试策划主要是进行测试需求分析，即确定需要测试的内容或质量特性；

确定测试的充分性要求；

提出测试的基本方法；

确定测试的资源和技术需求；

进行风险分析和评估；

制定测试计划（含资源计划和速度计划）。

有关测试计划的内容和要求减GT/B9386。

测试设计

依据测试需求，分析并选用已有的测试用例或设计新的测试用例；

获取并验证测试数据；

根据测试资源、风险等约束条件，确定测试用例执行顺序；

获取测试资源，开发测试软件；

建立并校准测试环境；

进行测试就绪评审，主要是评审测试计划的合理性和测试用例的正确性、有效性和覆盖充分性，评审测试组织、环境和设备工具是否齐备并符合要求。

在进入下一阶段工作之前，应通过测试就绪评审。

测试执行

执行测试用例，获取测试结果；

分析并判定测试结果。

同时，根据不同的判定结果采取相应的措施；

对测试过程正常或异常终止情况进行核对，并根据核对结果，对未达到测试终止条件的测试用例，决定是停止测试，还是需要修改或补充测试用例集，并进一步测试。

测试总结

整理和分析测试数据，评价测试效果和被测软件项，描述测试状态。

如，实际测试与测试计划和测试说明的差异、测试充分性分析、未能解决的测试时间等；

描述被测试软件项的状态，如，被测试软件与需求的差异，发现的软件差错等；

最后完成软件测试报告，并通过评审。

4.4　测试方法

静态测试法

静态测试法包括检查和静态分析法，对文档的静态测试方法以检查单的形式进行，而对代码的静态测试方法一般采用代码审查、代码走查和静态分析，静态分析一般包括控制流分析、数据流分析、接口分析和表达式分析。

应对软件代码进行审查、走查或静态分析；

对于规模较小、安全性要求很高的代码也可进行形式化证明。

动态测试方法

动态测试方法一般采用黑盒测试方法和白盒测试方法。

黑盒测试方法一般包括功能分解、边界值分析、判定表、因果图、状态图、随即测试、猜错法和正交测试法等；

白盒测试方法一般包括控制测试（语句覆盖测试、分值覆盖测试、条件覆盖测试、条件组合覆盖测试、路径覆盖测试）、数据流测试、程序变异、程序插桩、域测试和符号求值等。

在软件动态测试过程中，应采用适当的测试方法，实现测试目的。

配置项测试和系统测试一般采用黑盒测试方法；

集成测试一般采用黑盒测试方法，辅助以白盒测试方法；

单元测试一般采用白盒测试方法，辅助黑盒测试方法。

静态测试和动态测试的详细说明参见附录A。

4.5　测试用例

测试用例设计原则

涉及测试用例时，应遵循以下原则：

a）基于测试需求的原则。

应按照测试类别的不同要求，涉及测试用例。

如,单元测试依据详细设计说明，集成测试依据概要设计说明，配置项测试依据软件需求规格说明，系统测试依据用户需求（系统/子系统设计说明、软件开发计划等）；

b）基于测试方法的原则。

应明确所采用的测试用例方法。

为达到不同的测试充分性要求，应采用相应的测试方法，如等价类划分、边界值分析、猜错法、因果图等方法；

c）兼顾测试充分性和效率的原则。

测试用例集应兼顾测试的充分性和测试的效率；

每个测试用例的内容也应完整，具有可操作性；

d）测试执行的可再现性原则。

应保证测试用例执行的可再现性。

测试用例要素

每个测试用例应包括一下要素：

a）名称和表示。

每个测试用例应有唯一的名称和标识符。

b）测试追踪。

说明测试所依据的内容来源，如系统测试依据的是用户需求，配置项测试依据的是软件需求，集成测试和单元测试依据的是软件设计。

c）用例说明。

简明描述测试的对象、目的和所采用的测试方法。

d）测试的初始化要求。

应考虑下述初始化要求：

1）硬件配置。

被测系统的硬件配置情况，包括硬件条件或电器状态。

2）软件配置。

被测系统的软件配置情况，包括测试的初始条件。

3）测试配置。

测试系统的配置情况，如用于测试的模拟系统和测试工具等的配置情况。

4）参数配置。

测试开始前的设置，如标志、第一断点、指针、控制参数和初始化数据等的设置。

5）其他对于测试用例的特殊说明。

e）测试的输入。

在测试用例执行中发送给被测对象的所有命令、数据和信号等。

对于每个测试用例应提供如下内容：

1）每个测试输入的具体内容（如确定的数值、状态或信号等）及其性质（如有效值、无效值、边界值等）；

2）测试输入的来源（例如，测试程序产生、磁盘文件、通过网络接收、人工键盘输入等），以及选择输入所使用的方法（例如等价划分、边界值分析、差错推测、因果图、功能图方法等）；

3）测试输入是真实的还是模拟的；

4）测试输入的时间顺序或时间顺序。

f）期望的测试结果。

说明测试用例执行中由被测试软件所产生期望的测试结果，即经过测试，人为正确的结果。

必要时，应提供中间的期望结果。

期望测试结果应该有具体内容，如确定的数值、状态或信号等，不应是不确定的概念或笼统的描述。

g）评价测试结果的准则。

判断测试用例执行中产生中间和最后结果是否正确的准则。

对于每个测试结果，应根据不同情况提供如下信息：

1）实际测试结果所需的精度；

2）实际测试结果与期望结果之间的差异允许的上限、下限；

3）时间的最大和最小间隔，或事件数目的最大和最小值；

4）实际测试结果不确定时，再测试的条件；

5）与产生测试结果有关的出错处理；

6）上面没有提及的其他准则。

h）操作过程。

实施测试的执行步骤。

把测试的操作过程定义为一系列按照执行顺序排列的相对独立的步骤，对于每个操作应提供：

1）每一步所需的测试操作动作、测试程序的输入、设备操作等；

2）每一步期望的测试结果；

3）每一步的评价准则；

4）程序终止伴随的动作或差错提示；

5）获取和分析实际测试结果的过程。

i）前提和约束。

在测试用例说明中施加的所有前提条件和约束条件，如果没有特别限制、参数偏差或异常处理，应该标识出来，并要说明它们对测试用例的影响。

j）测试终止条件。

说明测试正常终止和异常终止的条件。

4.6　测试管理

过程管理

软件测试应由相对独立的人员进行。

根据软件项目的规模等级和完整性级别以及测试类别，软件测试刻有不同机构组织实施。

应对测试过程中的测试活动和测试资源进行管理。

有关管理要求见GB/T8566。

一般情况下，软件测试的人员配备见表1。

表1软件测试人员配备情况表

工作角色

具体职责

测试项目负责人

管理监督测试项目，提供技术指导，获取适当的资源，制定基线，技术协调，负责项目的安全保密和质量管理

测试分析员

确定测试计划、测试内容、测试方法、测试数据生成方法、测试（软、硬件）环境、测试工具，评价测试工作的有效性

测试设计员

设计测试用例，确定测试用例的优先级，建立测试环境

测试程序员

编写测试辅助软件

测试员

执行测试、记录测试结果

测试系统管理员

对环境和资产进行管理和维护

配置管理员

设置、管理和维护测试配置管理数据库

注1：

当软件的提供方实施测试时，配置管理员由软件开放项目的配置管理员承担；

当独立的测试组织实施测试时，应配备测试活动的配置管理员。

注2：

一个人可承担多个角色的工作，一个角色可由多个人承担。

测试的准入准出条件如下：

a）准入条件

开始软件测试工作一般具备下列条件：

1）具有测试合同（或项目计划）；

2）具有软件测试所需的各种文档；

3）所提交的被测软件受控；

4）软件源代码正确通过编译或汇编。

b）准出条件

结束软件测试工作一般应达到下列要求：

1）已按要求完成了合同（或项目计划）所规定的软件测试任务；

2）实际测试过程遵循了原定的软件测试计划和软件测试说明；

3）客观、详实的记录了软件测试过程和软件测试中发现的所有问题；

4）软件测试文档齐全、符合规范；

5）软件测试的全过程自始自终在控制下进行；

6）软件测试中的问题或异常有合理解释或正确有效的处理；

7）软件测试工作通过了测试评审；

8）全部测试软件、被测软件、测试支持软件和评审结果已纳入配置管理。

配置管理

应按照软件配置管理的要求，将测试过程中产生的各种软件工作产品纳入配置管理。

由开发组织实施的软件测试，应将测试工作产品纳入软件项目的配置管理；

由独立测试组织实施的软件测试，应建立配置管理库，将被测试对象和测试工作产品纳入配置管理。

配置管理要求减GB/T20158。

评审

测试就绪评审

在测试执行前，对测试计划和测试说明等进行评审，评审测试计划的合理性、测试用例的正确性、完整性和覆盖充分性，以及测试组织、测试环境和设备工具是否齐全并符合技术要求等。

评审的具体内容要求应包括：

a）评审测试文档内容的完整性、正确性和规范性；

b）通过比较测试环境与软件真实运行的软件、硬件环境的差异，评审测试环境是否正确合理，满足测试要求；

c）评审测试活动的独立性；

d）评审测试项选择的完整性和合理性；

e）评审测试用例的可行性、正确性和充分性。

测试评审

在测试完成后，评审测试过程和测试结果的有效性，确定是否达到测试目的。

主要对测试记录、测试报告进行评审，其具体内容和要求应包括；

a）评审文档和记录内容的完整性、正确性和规范性；

b）评审测试活动的独立性和有效性；

c）评审测试环境是否符合测试要求；

d）评审测试记录、测试数据以及测试报告内容与实际测试过程和结果的一致性；

e）评审实际测试过程与测试计划和测试说明的一致性；

f）评审未测试项和新增测试项的合理性；

g）评审测试结果的真实性和正确性；

h）评审对测试过程中出现的异常进行处理的正确性。

4.7　测试文档

软件测试文档一般包括测试计划、测试说明（需要时进一步细分为测试设计说明、测试用例说明和测试规范说明）、测试项传递报告、测试日志、测试记录、测试问题报告（也称测试事件报告）和测试总结报告（部分软件测试模板参见附录C），测试文档的基本内容和要求见GB/T9386.

按照GB/T18492，根据软件的完整性级别和软件规模等级经行合理的取舍与合并，其要求见表2。

表2测试文档的取舍与和并要求

文档

性质

规模（巨、大、中）

规模（小、微）

完整性级别（A、B）

完整性级别（C、D）

测试计划

√

·

测试说明

测试报告

测试记录

测试问题报告

注：

√表示选取，·

表示合并

表2中支出文档的合并，在两个文档或多个文档合并时，具有相似内容的文档的第1、2、3章只用一次，即进行合并，后续的章条号一次编排。

4.8　测试工具

测试工具分类

软件测试工具可分为静态测试工具、动态测试工具和其他支持测试活动的工具，没类测试工具在功能和其他特征方面具有相似之处，支持一个或多个测试活动（见表3）。

应根据测试要求选择合适的工具。

表3软件测试工具分类

工具类型

功能和特征说明

举例

备注

静态测试工具

对软件需求、结构设计、详细设计和代码进行评审、走查和审查的工具

复杂度分析、数据流分析、控制流分析、接口分析、句法和语义分析等工具

针对软件需求、结构设计、详细设计的静态分析工具

动态测试工具

支持执行测试用例和评价测试结果的工具，包括支持选择测试用例、设置环境、运行所选择测试、记录执行活动、故障分析和测试工具有效性评价等

覆盖分析、捕获和回放、存储器测试、变异测试、仿真器及性能分析、测试用例管理等工具

测试捕获和回放及数据生成器可用于测试设计

支持测试过程活动的其他工具

支持测试计划、测试设计和整个测试过程的工具

测试计划生成、测试进度和人员安排评估、基于需求的测试设计、测试数据生成、问题管理和测试配置管理等工具

复杂度分析可用于测试计划的制定、捕获和回放、覆盖分析可用于测试设计与实现

测试工具选择

软件测试应尽量采用测试工具，避免或减少人工工作。

为让工具在测试工作中发挥应有的作用，应确定工具的详细需求，并制定统一的工具评价、采购（开发）、培训、实施和维护计划。

选择软件测试工具应考虑如下因素：

a）软件测试工具的需求及确认：

1）应明确对测试工具的功能、性能、安全性等需求，并据此进行验证或确认；

2）可通过在实施运行环境下的演示来确认工具是否满足需求，演示应依据工具的功能和技术特征、用户使用信息（安装和使用手册等）以及工具的操作环境描述等进行。

b）成本和收益分析：

1）估计工具的总成本，除了最基本的产品价格，总成本还包括附加成本，如工具的挑选、安装、运行、培训、维护和支持等成本，以及为使用工具而改变测试过程或流程的成本等；

2）分析工具的总体收益，如工具的首次使用范围和长期使用前景、工具应用效果、与其他工具协同工作所提高的生产力成都等。

c）测试工具的整体质量因素：

1）易用性；

2）互操作性；

3）稳定性；

4）经济实用型；

5）维护性。

4.9　软件完整性级别与测试的关系

根据失效所造成后果的危害程度，计算机软件的完整性级别被分为A、B、C、D四个等级（其定义J见GB/T18492）。

不同完整性级别的安全要求不同，对软件的测试内容、测试要求和测试所采用方法也有所不同。

针对各种不同的软件测试类型，应有安全性方面的考虑。

5　单元测试

5.1　测试对象和目的

测试对象

软件单元测试的对象是可独立编译或汇编的程序块（或称为软件构件或在面向对象设计中的类）。

测试目的

软件单元测试的目的是检查每个软件单元能否正确地实现设计说明中的功能、性能、接口和其他设计约束等要求，发现单元内可能存在的各种差错。

5.2　测试的组织和管理

一般由软件的提供方或开发组织并实施软件单元测试，也可委托第三方进行软件单元测试。

软件单元测试的人员配置见表1。

软件单元测试的技术依据是软件设计文档（或称软件详细设计文档）。

其测试工作的准入条件应满足4.6.1a）的要求，测试工作的准出条件应满足4.6.1b）的要求。

软件单元测试的工作产品一般应纳入软件的配置管理中。

5.3　技术要求

软件单元测试一般应符合以下技术要求：

a）对软件设计文档规定的软件单元的功能、性能、接口等应逐项进行测试；

b）每个软件特效应至少被一个正常测试用例和一个被认可的异常测试用例覆盖；

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

d）在对软件单元进行行动态测试之前，一般应对软件单元的源代码进行静态测试；

e）语句覆盖率达到100%；

f）分支覆盖率要达到100%；

g）对输出数据及其格式进行测试。

对具体的软件单元，可根据软件测试合同（或项目计划）以及软件单元的重要性、完整性级别等要求对上述内容进行裁剪。

5.4　测试内容

总则

当静态测试时，所测试的内容与选择的测试方法有关。

如，采用代码审查方法，通常要对寄存器的使用（近限定在机器指令和汇编语言时考虑）、程序格式、入口和出口的连接、程序语言的使用、存储器的使用等内容进行检查；

采用静态分析法，通常要对软件单元的控制流、数据流、接口、表达式等内容进行分析。

详细内容可参见第A.1章中各种静态测试方法的描述。

当动态测试时，通常对软件单元的功能、性能、局部数据结构、独立路径、出错处理、边界条件和内存使用情况进行测试。

通常对软件单元接口的测试优先于其他内容的测试。

对具体的软件的单元，应根据软件测试合同（或项目计划）、软件设计文档的要求及选择的测试方法确定测试的具体内容。

接口

测试接口一般应包括以下内容：

a）调用被测单元的实际参数与该单元的形式参数的个数、属性、量纲、顺序是否一致；

b）被测单元调用子模块时，传递给子模块的实际参数与子模块的形式参数的个数、属性、量纲、顺序是否一致；

c）是否修改了只作为输入值的形式参数；

d）调用内部函数的参数个数、属性、量纲、顺序是否正确；

e）被测单元在使用全局变量时是否与全局变量的定义一致；

f）在单元有多个入口的情况下，是否引用了与当前入口无关的参数；

g）常数是否当作变量来传递；

h）输入/输出文件属性的正确性；

i）OPEN语句的正确性；

j）CLOSE语句的正确性；

k）规定的输入/输入格式说明与输入/输出语句是否匹配；

l）缓冲区容量与记录长度是否匹配；

m）文件是否先打开后使用；

n）文件结束条件的判断和处理的正确性；

o）对输入/输出错误是否进行了检查并做了处理以及处理的正确性。

局部数据结构

测试软件单元内部的数据结构能否保持其完整性，包括内部数据内容、格式及相互关系。

应设计测试用例以检查如下差错：

a）不正确或不一致的数据类型说明；

b）错误的变量名，如变量名拼写错误或缩写错误；

c）使用尚未赋值或尚未初始化的变量；

d）差错的初始值或差错的缺省值；

e）不一致的数据类型；

f）下溢、上溢或是地址差错；

g）全局数据对软件单元的影响。

独立路径

独立路径是指在程序中至少进一个新的处理语句集合或一个新条件的任一路径。

在程序的控制流图中，一条独立路径是至少包含一条在其他独立路径中从未有过的边的路径。

应设计适当的测试用例，对软件单元中的独立路径进行测试，特别是对独立路径中的基本路径进行测试。

基本路径指在程序控制流图中，通过对控制构造的环路复杂性分析而导出的基本的、可执行的独立路径集合。

边界条件

应测试软件单元在边界处能否正常工作，如，测试处理数组的第1个和最后一个元素；

测试循环执行到最后一次；

测试取最大值或最小值；

测试数据流、控制流中刚好等大、大于或小于确定的比较值等等。

差错处理

测试软件单元在运行过程中发生差错时，其出错处理措施是否有效。

良好的单元设计要求能预见到程序投入运行后可能发生的插错，并给出相应的处理措施。

这种出错处理也应当是软件单元功能的一部分。

一般若出现下列情况之一，则表明软件单元的出错处理功能包含插错或缺陷：

a）差错的描述难以理解；

b）在对差错进行处理之前，差错条件已经引起系统的干预；

c）所提供的差错描述信息不足以确定造成差错的位置或原因；

d）显示的出错提示与实际差错不符；

e）对差错条件的处理不正确；

f）意外的处理不当；

g）联机条件处理（即交互处理等）不正确；

功能、

应对软件设计文档规定的软件单元的功能逐项进行测试。

性能

按软件设计文档的要求，对软件单元的性能（如精度、时间、容量等）进行测试。

内存使用

检查内存的使用情况，特别是动态申请的内存在使用上的错误（如指针越界、内存泄漏等）。

5.5　测试环境

测试环境包括测试的运行环境和测试工具环境。

测试的运行环境一般应符合软件测试合同（或项目计划）的要求，通常是开发环境或仿真环境。

测试工具一般要求是经过认可的工具。