中企动力质量保证规范.docx

中企动力质量保证规范.docx

《中企动力质量保证规范.docx》由会员分享，可在线阅读，更多相关《中企动力质量保证规范.docx（20页珍藏版）》请在冰豆网上搜索。

中企动力质量保证规范

中企动力科技股份有限公司

软件测试方法与规范

（质量保证计划）

目录

1编写目的1

2参考文档1

3术语与缩写词1

4总体要求1

5测试工作组织和管理2

5.1测试工作规程2

5.2测试与软件开发各个阶段的关系3

6测试阶段的划分4

6.1计算机软件单元测试4

6.1.1测试对象4

6.1.2进入条件4

6.1.3测试内容4

6.1.4具体要求4

6.1.5实施步骤5

6.1.6测试评估5

6.1.7通过准则5

6.2计算机软件集成测试5

6.2.1测试对象5

6.2.2进入条件6

6.2.3测试内容6

6.2.4具体要求6

6.2.5实施步骤6

6.2.6测试评估6

6.2.7通过准则7

6.3计算机软件集成测试7

6.3.1测试对象7

6.3.2进入条件7

6.3.3测试内容7

6.3.4具体要求8

6.3.4.1功能测试8

6.3.4.2性能测试8

6.3.4.3外部接口和人机交互界面测试8

6.3.4.4可靠性测试8

6.3.4.5安全性测试9

6.3.4.6恢复性测试9

6.3.4.7边界测试9

6.3.4.8安装性测试9

6.3.5实施步骤9

6.3.6测试评估10

6.3.7通过准则10

7测试文档10

7.1测试文档的类型10

7.2测试文档的使用10

7.3测试文档的编制11

7.3.1“软件测试计划”编写规范11

7.3.2“软件测试说明”编写规范13

7.3.3“软件测试报告”编写规范14

1编写目的

本文档基于工程化思想提出了北京辰冲科技发展有限公司QA部门在软件测试工作中的总体要求，描述了软件开发过程中对测试工作的组织和管理，定义了不同的软件测试阶段以及在每个阶段应该提交的测试文档。

辰冲科技发展有限公司QA部门的软件测试工作将严格遵循文档中给出的描述，并根据软件开发的实际情况定义不同的软件测试流程。

2参考文档

·《软件工程》

清华大学出版社，郑人杰

·软件产品开发文件编制指南

GB8567—88

·软件工程术语标准

GB/T11457—89

·《辰冲公司QA部门组织架构与工作规范》

辰冲科技发展有限公司

·《辰冲公司软件开发文档编写规范》

辰冲科技发展有限公司

3术语与缩写词

·QA：

QualityAssurance质量保证

·DEV：

Developer开发人员

·SRD：

SoftwareRequirementsDocument软件需求文档

·HLD：

HighLevelDesigndocument概要设计文档

·LLD：

LowerLevelDesigndocument详细设计文档

·QAP：

QualityAssurancePlan质量保证计划

·UT：

UnitTesting单元测试

·IT：

IntegratedTesting集成测试

·ST：

SystemTesting系统测试

·TTD：

TestingToolDevelopment测试工具开发

4总体要求

软件测试就是在软件在投入运行前，对软件需求分析、系统设计和编码的最终复审，是软件质量保证的关键步骤，以发现软件中的错误为基本目的。

它根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例，并利用这批测试用例去运行程序，从而发现软件的错误。

基于上述描述，软件测试的总体要求如下：

·尽早地和不断地进行软件测试。

由于原始问题的复杂性，软件的复杂性和抽象性、软件开发各个阶段工作的多样性、以及参加开发各种层次的人员之间的配合关系等因素，使得开发的每个环节都可能产生错误。

所以不应把软件测试仅仅看作是软件开发的一个独立阶段，而应当把它贯穿到软件开发的各个阶段中。

坚持在软件开发的各个阶段的技术评审，这样才能在开发过程中尽早发现和预防错误，把出现的错误克服在早期，杜绝某些隐患，提高软件质量；

·测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成。

测试以前应当根据测试的要求选择在测试过程中使用的测试用例。

测试用例主要用来检验程序员编制的程序，因此不但需要测试的输入数据，而且需要针对这些输入数据的预期输出结果。

如果对测试输入数据没有给出预期的测试输出结果，那么就缺少了检验实测结果的基准，就有可能把一个似是而非的错误结果当成正确结果；

·程序员仅负责对自己开发程序的模块测试（单元测试），而软件集成测试和系统测试应该由专门的、独立的测试人员来完成；

·在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。

合理的输入条件是指能验证程序正确的输入条件，而不合理的输入条件是指异常的、临界的、可能引起问题变异的输入条件。

在测试程序时，人们常常倾向于过多地考虑合法的和期望的输入条件，以检查程序是否做了它应该做的事件，而忽视了不合法的和预想不到的输入条件。

用不合理的输入条件测试程序，往往比用合理的输入条件进行测试更能发现问题；

·充分注意测试中的群集现象。

测试时不要以为找到了几个错误，问题就已解决，不需继续测试了。

经验表明，测试后程序中残存的错误数目与该程序中已经发现的错误数目或检错率成正比。

根据这个规律，应当对错误群集的程序进行重点测试，以提高测试的效率；

·严格执行测试计划，排除测试的随意性。

测试计划应包括：

所测软件的功能，测试内容，各项测试的进度安排，资源要求，测试资料，测试工具，测试用例的选择，测试的控制方法和过程等，对于测试计划，要有明确规定，不要随意解释；

·应当对每一个测试结果做全面检查。

有些错误的征兆在输出实测结果时已经明确出现了，但是如果不仔细地全面检查测试结果，就会使这些错误被遗漏掉。

所以必须对预期的输出结果明确定义，对实测的结果仔细分析检查，抓住征候，暴露错误；

·妥善保存测试计划，测试用例，出错统计和最终分析报告，为对软件开发质量的评价和维护工作提供证据和方便。

5测试工作组织和管理

5.1测试工作规程

每项软件测试必须经历下述测试流程：

·制定测试计划：

包括测试活动的范围、测试方法、进度、资源、功能验证的实施步骤、各级测试的详细规程、软件验收标准、测试报告和处理方法；

·产生测试用例集：

根据被测试特性，设计测试用例集结构，为每一测试用例决定软件输入、输出和控制方式（人工、半自动、自动），并制定相应的测试规程，获得并验证所需要的测试数据；

·执行测试：

按照测试规程执行测试用例，决定测试通过或失败，如果通过则进行下一步，否则，根据错误情况重新运行测试或修改软件设计、编码或文档的有关部分，然后再重新进行测试；

·评价：

按照评价标准评价测试工作和被测试软件，当发现测试工作不足时，应修订测试计划，重复开发测试工作规程，直到测试完备时为止；

·产生完整的测试文档：

包括测试计划、测试说明、测试报告或测试分析报告。

5.2测试与软件开发各个阶段的关系

软件开发过程是一个自顶向下、逐步细化的过程，首先软件在计划阶段定义了软件的作用域，然后进行软件需求分析，建立软件的数据域、功能和性能需求、约束和一些有效性准则。

接着进入软件开发，首先是软件设计，然后再把设计用某种程序设计语言转换成程序代码。

而测试过程则是依据相反的顺序安排的自底向上，逐步集成的过程。

低一级测试为上一级测试的准备条件，当然也不排除两者平行地进行测试，如果5.2.1所示。

图5.2.1软件开发过程

软件测试各阶段与软件开发各阶段间的关系如图5.2.2所示。

图5.2.2软件测试各个阶段与软件开发各个阶段间的关系

在图5.2.2中，系统测试包括概要设计和详细设计两个软件开发阶段。

6测试阶段的划分

基于软件工程开发的要求和辰冲科技发展公司的实际情况，软件测试可分为以下三个阶段：

·计算机软件单元测试

·计算机软件集成测试

·计算机软件系统测试

6.1计算机软件单元测试

计算机软件单元是指计算机软件在编码是实现过程中确定的能单独测试的一部分软件。

6.1.1测试对象

任一计算机软件单元。

6.1.2进入条件

计算机软件代码无错误地通过编译或汇编。

6.1.3测试内容

单元测试的主要内容包括：

·计算机软件单元的功能测试；

·重要的执行路径测试；

·局部数据结构测试；

·错误处理测试；

·边界条件测试；

·语句覆盖测试；

·分支覆盖测试。

6.1.4具体要求

单元测试的具体要求如下：

·在开始单元测试前，必须已经完成对软件单元的代码审查；

·被测试软件单元中每条可执行的语句都至少被一个测试用例或一个被认可的异常所覆盖，即语句覆盖率100%；

·软件单元中分支语句取真分支和取假分支至少执行一次占总分支的比率，即分支覆盖率，一般软件单元达到90%以上，核心软件单元单刀98%以上；

·每个软件特性必须至少被一个测试用例或一个被认可的异常所覆盖；

·对输入数据进行检查；

·对输出数据（包括信息）和输出格式进行检查；

·用假想的数据类型和数据值运行，测试排斥不规则输入的能力；

·单元测试由开发人员本人完成。

6.1.5实施步骤

单元测试的实施步骤如下：

·制定软件单元测试计划，应在详细设计阶段完成；

·建立软件单元测试环境，编写软件单元测试说明；

·执行软件单元测试用例，并详细记录执行信息；

·根据每个测试用例的预期输出结果和实际运行结果，判定该测试是否通过；

·如果测试不通过，在Bug跟踪工具中填写一个Bug报告单，描述错误产生的过程以及相关的环境，在错误修正后进行再测试，直到通过；

·完成单元测试报告。

6.1.6测试评估

根据详细设计说明书、软件单元测试结果和发现的错误信息，评价每个软件单元的设计及其实现。

6.1.7通过准则

单元测试的通过准则如下：

·完成并通过了对软件单元的代码审查；

·软件单元的功能与详细设计说明书中的描述一致；

·软件单元的接口与详细设计说明书中的描述一致；

·能正确处理输入和运行中的错误；

·单元测试中发现的问题均得到修改，并通过了有关测试；

·完成了单元测试报告。

6.2计算机软件集成测试

软件集成测试是指在软件单元测试的基础上，需要将所有模块按照系统设计的要求组装成为软件子系统。

6.2.1测试对象

集成测试适用于：

·软件单元的组装过程；

·软件单元组装得到的新的软件子系统；

6.2.2进入条件

在进入软件集成测试之前，要保证每个供组装的软件单元满足如下条件：

·完成软件单元测试；

·软件单元已经置于软件配置管理之下，进入受控库中；

6.2.3测试内容

集成测试的主要内容包括：

·软件单元间的接口测试；

·子系统功能测试；

·全局数据结构测试；

·边界和在人为条件下的性能。

6.2.4具体要求

集成测试的具体要求如下：

·必须对调用对进行100%的测试；

·功能测试参见6.1.4节中的第四到第七条中的要求；

·对子系统组装过程中的软件单元的输入/输出进行测试，验证其达到设计要求；

·测试子系统正确处理的能力和经受错误影响的能力；

·确认软件单元无错误连接；

·必要时，应测试在任意外部输入情况下，从外部接口采集和发送数据的能力，包括对正常数据及状态的处理，对接口错误、数据错误、协议错误的识别以及处理；

·应测试运行条件在边界的状态下，进而在人为设定的状态下子系统的功能和性能；

·集成测试中子系统组装过程由开发小组完成，组装完成后的测试由测试人员独立完成。

6.2.5实施步骤

集成测试的实施步骤如下：

·制定软件集成测试计划，应在概要设计和详细设计阶段完成；

·建立软件集成测试环境，编写软件集成测试说明；

·执行软件集成测试用例，并详细记录执行信息；

·根据每个测试用例的预期输出结果和实际运行结果，判定该测试是否通过；

·如果测试不通过，在Bug跟踪工具中填写一个Bug报告单，描述错误产生的过程以及相关的环境，在错误修正后进行再测试，直到通过；

·完成集成测试报告。

6.2.6测试评估

根据概要设计说明书、软件集成测试结果和发现的错误信息，评价每个软件结构的设计及其实现。

6.2.7通过准则

集成测试的通过准则如下：

·各软件单元无错误地连接；

·满足各项功能、性能要求；

·对错误输入有妥善处理的能力；

·对测试异常有合理的解释；

·达到规定的测试覆盖类和覆盖率的要求；

·人机界面正确无误；

·完成集成测试报告。

6.3计算机软件集成测试

软件系统测试是指将通过集成测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他元素结合在一起，模拟实际运行（使用）环境，对计算机系统进行一系列的组装测试和确认测试。

6.3.1测试对象

系统测试适用于对计算机软件系统的测试。

6.3.2进入条件

在进入软件系统测试之前，必须满足下述条件：

·完成并通过软件集成测试，如果没有软件集成测试阶段，则完成并通过软件单元测试；

·整个计算机软件系统可以运行在真实或仿真的环境下；

6.3.3测试内容

根据软件需求规格说明中定义的全部功能和性能要求以及软件系统测试计划，测试整个软件系统是否到达了要求，根据软件的复杂性、重要性和类型，选择进行以下测试，但必须包含功能测试、性能测试、边界测试：

：

·功能测试；

·性能测试；

·外部接口和人机交互界面测试；

·可靠性测试；

·安全性测试；

·恢复性测试；

·边界测试；

·安装性测试。

6.3.4具体要求

6.3.4.1功能测试

功能测试的具体要求如下：

·每一个软件功能必须至少被一个测试用例或一个被认可的异常所覆盖；

·用基本数据类型和数据值测试；

·用一系列合理的数据类型和数据值运行，测试超负荷、饱和及其它“最坏情况”的结果；

·用假想的数据类型和数据值运行，测试排斥不规则输入的能力；

·每个功能的合法边界值和非法边界值都必须被作为测试用例。

6.3.4.2性能测试

性能测试的具体要求如下：

·测试结果在获得定量结果时程序计算的精确性；

·测试程序在有其他性能要求时完成功能的时间；

·测试程序完成功能所能处理的数据量；

·测试程序各部分的协调性；

·测试软/硬件中因素是否限制了程序的功能；

·测试程序的负载能力；

·测试程序运行占用的系统资源。

6.3.4.3外部接口和人机交互界面测试

外部接口和人机交互界面测试的具体要求如下：

·测试所有外部接口，检查接口信息的格式及内容；

·测试所有人机交互界面提供的操作和显示界面，以非常规操作、误操作、快速操作来检验界面的可靠性，以最终用户为背景检验界面显示的清晰性；

·对照用户手册或操作手册，逐条进行操作或观察。

6.3.4.4可靠性测试

软件可靠性是在有使用代表性的环境中，为进行软件可靠性估计对该软件进行的功能测试。

软件可靠性测试的目的在于：

·通过在有使用代表性的环境中执行软件来验证软件需求的正确实现；

·为进行软件可靠性估计采集数据；

·通过软件可靠性测试找出所有对软件可靠性影响较大的错误。

软件可靠性测试必须：

·对软件的功能需求及其有关的可靠性要求有清晰的定义和明确的目标；

·对软件的使用和运行环境有充分的了解，明确软件的所有运行状态、状态转换条件、各种运行环境下的输入边界，并对输入的概率分布有大致的估计。

软件可靠性测试必须按照使用的概率分布随机地选择测试实例。

6.3.4.5安全性测试

安全性测试的具体要求如下：

·必须进行软件安全性分析，并且在软件需求中明确每一个危险状态及导致危险的可能原因，在测试中全面检验软件在这些危险状态下的反应；

·对安全性要求较高的软件组件，必须单独测试软件组件，以确认该软件组件满足安全性要求；

·对软件设计中用于提高安全性的结构、算法、容错、冗余，中断处理等方案，必须进行针对性测试；

·测试应尽可能在符合实际使用的条件下进行；

·除在正常条件下测试外，应在异常条件下测试软件，以表明不会因可能的单个或多各输入错误的导致不安全状态；

·必须包含硬件以及软件输入故障模式测试；

·必须包含边界、界外以及边界结合部的测试；

·必须包含在最坏情况配置下的最小和最大输入数据率，以确定系统的固有能力以及对这些环境的反应；

·操作员接口测试必须包含在安全性关键操作中的操作员错误，以验证安全系统对这些错误的响应；

·应测试防止非法进入系统并保护系统数据完整性的能力；

·对于测试中发现的缺陷，必须纠正，以消除所有危险或将其风险降到可接受水平。

纠正后的软件应在同样的条件下重新测试，以确保消除危险和不会出现其它危险。

6.3.4.6恢复性测试

对有恢复或重置（RESET）功能的软件，必须验证恢复或重置功能，对每一类导致恢复或重置的情况进行测试。

6.3.4.7边界测试

测试程序在输入域（或输出域）、数据结构、状态转换、过程参数、功能界限等的边界或端点情况下的运行状态。

6.3.4.8安装性测试

验证按安装规程进行安装的正确性，包括参数装订、程序从安装介质装入计算机。

6.3.5实施步骤

系统测试的实施步骤如下：

·制定软件系统测试计划，应在软件需求分析和设计阶段完成；

·建立软件系统测试环境，编写软件系统测试说明；

·执行软件系统测试用例，并详细记录执行信息；

·根据每个测试用例的预期输出结果和实际运行结果，判定该测试是否通过；

·如果测试不通过，在Bug跟踪工具中填写一个Bug报告单，描述错误产生的过程以及相关的环境，在错误修正后进行再测试，直到通过；

·完成系统测试报告。

6.3.6测试评估

根据需求规格说明、软件系统测试结果和发现的错误信息，评价软件功能、性能及其他需求的设计及其实现。

6.3.7通过准则

系统测试的通过准则如下：

·没有影响软件系统主要功能运行的错误；

·每300行代码中不多于一个Bug；

·满足软件需求规格说明中所规定的所有功能、性能、约束及限制要求；；

·完成系统测试报告。

7测试文档

软件测试文档描述要执行的软件测试及测试的结果。

软件测试是一个很复杂的过程，需要在测试真正开始前对测试过程进行详细的定义和描述，这对于保证软件的质量和软件测试的正确运行有着重要意义。

因此，必须把对软件测试的要求、过程及测试结果以正式的文件形式写出，测试文档的编写是测试工作规范化的一个重要组成部分。

测试文档的编写不只是在测试阶段才去考虑，它在软件开发的需求分析阶段就开始着手，与软件开发过程同步进行。

测试文档对于测试阶段工作的指导与评价作用更是非常明显的，需要特别指出的是，在已开发的软件投入运行的维护阶段，常常还要进行再测试或回归测试，还要用到这些测试文档。

7.1测试文档的类型

根据测试文档所起的作用不同，通常包括：

·软件测试计划：

详细规定测试的要求，包括测试的目的和内容、方法，以及测试的准则等。

由于要测试的内容可能涉及到软件的需求和软件的设计，因此必须及早开始测试计划的编写工作。

不应在着手测试时，才开始考虑测试计划，软件测试计划给出了软件的测试需求；

·软件测试说明：

详细描述软件测试过程，由测试用例组成。

软件测试说明文档在软件测试计划的基础上，详细说明如何实现软件测试计划中提到的软件需求；

·软件测试报告：

用来对测试结果的分析说明，经过测试后，证实了软件具有的能力，以及它的缺陷和限制，并给出评价的结论性意见，这些意见即是对软件质量的评价，又是决定该软件能否交付用户使用的依据。

7.2测试文档的使用

　　测试文档的重要性表现在以下几个方面：

·验证软件需求和软件设计的正确性：

测试文档中规定了用以验证软件需求和软件设计的测试条件，研究这些测试条件对弄清用户需求的意图和开发者的设计是十分有益的；

·检验测试资源：

测试文档不仅要用文件的形式把测试过程规定下来，还应说明测试工作必不可少的资源，进而检验这些资源是否可以得到，即它的可用性如何。

如果某个测试文档已经编写出来，但所需资源仍未落实，那就必须及早解决；

·明确任务的风险：

有了测试文档，就可以弄清楚测试可以做什么，不能做什么，了解测试任务的风险有助于对潜伏的可能出现的问题事先作好思想上和物质上的准备；

·生成测试用例：

测试用例的好坏决定着测试工作的效率，选择合适的测试用例是作好测试工作的关键。

在测试文档编制过程中，按规定的要求精心设计测试用例有重要的意义；

·评价测试结果：

测试文档包括测试用例，即若干测试数据及对应的预期测试结果。

完成测试后，将测试结果与预期的结果进行比较，便可对已进行的测试提出评价意见；

·再测试：

测试文档规定的和说明的内容对维护阶段由于各种原因的需求进行再测试时，是非常有用的；

·决定测试的有效性：

完成测试后，把测试结果写入文档，这对分析测试的有效性，甚至整个软件的可用性提供了依据。

同时还可以证实有关方面的结论。

7.3测试文档的编制

7.3.1“软件测试计划”编写规范

本节给出“软件测试计划”文档的编写规范，该编写规范适用于《单元测试计划》、《集成测试计划》和《系统测试计划》的编写。

在实施软件开发过程中，开发者可根据实际情况对文档编写内容进行剪裁。

1概述

1.1编写目的

说明编写这份软件测试计划的目的，指出预期的读者。

1.2背景

描述本项目的开发背景，包括：

·待开发的软件系统的名称；

·本项目的任务提出者、开发者、用户及实现该软件的场地；

·该软件系统同其他系统或其他机构基本的相互来往关系。

1.3术语和缩写词

列出本文档中用到的专门术语的定义和外文首字母组词的原词组。

1.4参考资料

列出编写本文档时使用的参考资料，如：

·本项目的经核准的计划任务书或合同、有关负责人的批文；

·属于本项目的其他已发表的文档；

·本文档中各处引用的文档、资料，包括所要用到的软件开发标准。

列出这些文档资料的标题、文档编号、发表日期和出版单位，说明能够得到这些文档资料的来源。

2软件测试环境

分节描述完成软件测试所需的各种资源（包括软件、硬件）的获取和控制计划。

2.1软件环境

标识用于执行软件测试所需的各种软件（如操作系统、编译器、配置管理工具、测试工具，软件开发工具等），必要时，应对有关软件项的保密处理和安全性问题作出说明。

2.2硬件环境

标识用于软件测试环境的计算机硬件、接口设备等。

必要时，应对有关硬件项的保密处理和安全性问题作出说明。

3测试计划描述

分节对每个软件测试计划项进行说明。

3.1总体测试要求

描述适用于每个软件测试项的要求。

例如，每个软件测试项都需满足下列一般要求：

·被测试对象已相对稳定；

·使用一些虚假值、最大值和错误值对被测试对象进行测试；

·对被测试对象进行错误检测和出错恢复测试。

对不同的实际情况，应外加相应的专门测试。

3.2测试定义

分节描述各类测试，每小节描述一个测试类，测试人员可根据项目的实际情况选取其中一部分编写测试计划。

每个测试类应包括以下内容：

·测试目的；

·测试项命名规则；

·特殊要求（如24小时设备连续运行）；

·测试级别（单元测试、集成测试、系统测试）；

·测试序号；

·测试标题；

·该测试项所涉及的软件需求规格说明的引用；

·被记录的数据类型；

·假定和约束条件。

为便于描述，每个测试类均可用表格方式来说明。

3.2.X测试类名及其唯一标识

从3.2.1开始编号，每一节描述一个测试类，测试的分类如下：

·功能