测试基本要求.docx

测试基本要求.docx

《测试基本要求.docx》由会员分享，可在线阅读，更多相关《测试基本要求.docx（10页珍藏版）》请在冰豆网上搜索。

测试基本要求

测试基本要求

文档记录

修订记录

本次修订日期：

下次修订日期：

版本号

修订日期

变更概述

作者

修订显示

0.1

2012-8-23

初始版本

批准者

此文档需要以下人员批准

姓名

职务

分发

此文档分发给以下部门或单位相关人员：

姓名

职务

1.文档简介

1.1文档说明

为了规范各个系统在建设和维护过程的测试活动和工作，确保测试活动切实发挥其验证与确认的作用，能够及时将问题和缺陷发现并跟踪解决，保证上线系统的质量，提高用户的使用体验，根据《测试及验收管理办法》，制定本文档，对测试活动和工作制定基本要求。

本文档将从测试中的主要工作内容，管理方式，关键检查点，输出文档要求等方面，规定最基本的要求。

这些要求适用与各个系统的各个阶段测试，包括由规划，管理，执行的测试活动（如单元测试，系统集成测试等）和由业务分析（BA）组/产品顾问和业务部门负责的测试活动（如验收测试等）。

本文档中定义的是测试工作中最基本的要求，也是在相关评审，验收，检查活动中对测试相关工作评估的依据。

但本文档中并不是对测试工作的全部要求，鼓励各项目组在满足此文档要求的基础上，持续对测试活动进行提升和改进。

2.测试的过程

2.1测试时间与测试执行时间

在应用开发的周期中或者项目计划中，都会给测试活动安排一定的时间，比如代码开发中要安排单元测试，单元测试完成后安排有系统测试和系统集成测试，系统集成测试完成后安排有用户验收测试等，这些活动的安排有先后顺序的要求，一个任务受另一个任务完成状况的制约。

就某项测试来说，比如用户验收测试，一般安排在系统集成测试之后，这里的之后，指的是用户验收测试的执行要在系统集成测试完成之后进行，但并不意味着所有的用户验收测试工作都必须等到系统集成测试完成之后进行。

因此，对于某项测试活动，要求尽早进行规划和准备，在前一阶段的开发或测试完成后，即可以进入此项测试的执行，并且，所有的准备工作要提前做好，确保测试执行的顺利进行和按计划时间完成，以保证整体项目的顺利和按计划实施。

2.2测试步骤划分

通常，一个阶段的测试，如系统测试,系统集成测试、用户验收测试等，都可以划分为四个主要步骤来进行，分别是：

Ø测试的计划

Ø测试的准备

Ø测试的执行

Ø测试的报告

其中，测试的计划是对这个阶段测试的规划过程；

测试的准备是为测试的执行做好方方面面的准备，确保进入测试执行阶段后可以按计划依次执行检验所有测试案例，不会因为某些环境或条件没有准备好而导致暂停或终止；

测试的执行阶段，通常严格依赖于整体项目的计划，而且时间有限，要确保在计划时间内，完成预定的测试任务，获得有效的测试记录和结果；

测试报告阶段是对这个阶段的测试记录，过程，结果进行汇总，分析，得出测试结论。

要求所有的测试活动和过程应该可以清晰的看出以上四个主要步骤，不能缺少某个步骤，如缺少测试计划步骤，直接进入准备。

具体步骤内的要求通过以下章节详细描述。

2.3测试计划

测试计划阶段的主要目的是对本阶段的测试活动进行策略上的定位和具体细节上的计划。

在测试计划阶段要考虑如下一些问题并制定出具体方案或结果：

Ø测试的范围：

本次测试的范围是什么，包括哪些要验证的需求，每个需求都要验证哪些方面，包括功能方面的，非功能方面的，还有是否从用户体验方面需要进行测试等。

Ø测试的策略：

对于测试范围内的各个方面，此次测试的关注领域或方面是什么，测试的重点和优先级是什么，测试要达到的目标和效果等

Ø例子：

“接口”类相关测试在不同测试阶段的重点：

Ø在系统集成测试阶段中，针对接口的正向、逆向及各种条件下的功能正确性等进行测试，并由测试组负责提供相关内容（系统集成测试案例，系统集成测试报告等）；此类交付件可通过验收测试准入检查会和其他集成测试质量管控点等进行落实。

Ø在验收测试阶段中，针对接口部分可通过端到端业务流程的测试场景进行验证。

Ø测试覆盖规划：

基于测试范围和策略，需要设计哪些测试场景，测试案例，以及这些测试场景，案例可以对要验证的需求实现怎样的覆盖率分析，此部分的分析可以参考RTVM模板和使用说明进行。

Ø测试的准入和准出条件：

在计划阶段要根据测试的策略和项目的情况，定义具体的准入和准出条件。

关于准入准出的内容，可以参考制定的准入准出标准，并进行补充和裁剪。

Ø测试的环境，数据：

本次测试使用什么测试环境和测试数据，需要哪些准备和支持，使用那些测试工具，依赖哪些外部环境配合等等。

关于测试环境的要求，可以参考后续的专题章节。

Ø测试的人员：

本次测试需要多少测试人员，各自承担什么角色，负责什么工作。

Ø测试的时间计划：

不同任务的时间计划和安排，彼此先后顺序，制约关系，以及具体人员的安排等等。

测试计划阶段以上内容的结果将是整个测试过程的指导，因此需要将以上的计划结果使用文档详细准确的记录下来，生成测试方案或测试计划文档。

关于测试计划或测试方案文档样式，可以参考制定的相关模板。

要求在测试计划阶段须产出测试计划或测试方案文档，此文档中，应就以上在测试计划中需要考虑的内容有合理且明确的方案和结果描述。

2.4测试准备

测试准备就是为了测试执行做好方方面面的准备，主要包括如下一些发面：

Ø指派测试人员

Ø构建测试环境

Ø建立测试数据

Ø撰写测试案例

Ø追踪测试案例到需求

Ø审查

测试准备中，测试环境和测试数据的准备和要求等，请参考后续的专门章节。

测试准备另一个最主要的，有时也是最大的工作就是撰写测试案例脚本。

测试案例脚本是测试执行步骤的说明和参考，好的测试案例应该目标明确，内容清晰，步骤精简且详细，结果检验标准明确。

测试案例中一般应至少包括一些主要内容：

Ø测试案例的编号和标题

Ø测试案例的目的说明

Ø测试案例的参考文档和资料

Ø测试案例的执行前置条件

Ø测试案例所需数据的说明

Ø执行测试案例的每个步骤说明

Ø每个步骤的正确期望结果

Ø案例的作者，编写时间

Ø测试者，测试时间，测试结果，每个步骤的实际返回结果，返回结果的图像，数据等的预留记录位置等

测试案例的格式可以参考相关测试案例模板和编写说明文档。

测试准备阶段的最终效果是满足测试准入的全部条件，可以进入测试执行阶段。

要求，在测试准备阶段，应参考测试计划文档中的计划和准入条件，完成所有的准备工作；对于测试执行阶段所有测试测案例，应编写完成所有测试案例，所有案例应该具备上面所列出的基本内容。

2.5测试执行

测试执行会受到整体项目进度的制约，通常安排给测试执行的时间非常有限，而测试执行如果无法按计划完成，又会影响到项目后续工作的进行。

因此测试执行是测试过程中最紧张和关键的一个步骤。

为了保证测试执行的顺利进行，在测试执行前，需要对准入条件的满足情况进行检查，以确保不会因为某些条件不具备，影响到测试的执行。

准入检查通过后，即可以开始按计划进行测试执行。

测试执行就是按照每个测试案例脚本中的描述，依次执行各个步骤，并比较系统返回结果与期望结果。

其结果只有两个可能：

完全一致和不一致。

对于测试结果完全一致的测试案例，是测试通过的案例。

对于测试通过的案例，要求记录案例的测试结果记录。

对于测试结果有差异的案例，可能是因为操作，数据选择，前提条件不具备等因素引起的，这些案例需要进行相应的调整后重新测试。

如果不是因为外界原因引起，那么测试结果就是与期望结果不一致，则认为是一个缺陷，此时案例的测试结果是不通过。

对于没有通过的测试案例，应将不一致的页面，消息，数据等信息粘贴在相应的案例中进行保存，一是作为测试结果的一个记录，二是为问题原因分析提供详尽的信息。

对于发现的缺陷，也要求进行详细的记录并进行原因分析和解决。

相关缺陷的管理要求，请参考后续的专题章节。

缺陷的解决可能会引起代码的变化，从而需要重新部署测试环境中的待测应用，这部分要求，请参考后续的测试环境管理专题章节。

代码修改后，根据变化的代码和影响的功能，业务等，需要再次分析哪些案例需要重新测试，包括之前测试没有通过的，也包括之前测试已经通过的，但受到变化代码影响需要重新测试的。

并对需要测试的案例重新执行测试，重新记录结果（不要覆盖以前的结果）。

直至测试案例的执行率，缺陷的修复率等达到准出条件的要求，测试执行阶段可以结束。

因此，在测试执行阶段的要求是，所有测试过的案例应记录结果并保存，多轮测试的结果应分别保存。

对于所有发生的缺陷应进行记录，并跟踪处理，记录处理过程和结果。

对于代码的变更应分析需要再次测试的案例并重新进行测试，并同样记录结果和新的缺陷，直至满足准出中的相应条件。

2.6测试报告

测试报告是整个测试过程的总结，通常测试报告的主要读者是管理方，业务方或项目中下一个任务的负责人，阅读测试报告的主要目的是了解并确认当前的测试结果。

因此，测试报告需给出明确的测试结论以及支持测试结论的相关过程记录和统计数据。

通常测试报告要包括以下主要内容

Ø本次测试的目标

Ø本次测试的范围和关注点

Ø测试的组织，人员

Ø测试所用的环境和数据

Ø测试过程中使用的方法，工具

Ø测试的计划和执行情况

Ø实际的案例执行率和需求覆盖情况

Ø缺陷的发生和解决情况

Ø本次测试的结果分析和结论

Ø风险分析和建议等

对于测试报告的参考样式，可以参考相关测试报告模板。

除了测试报告外，还应提供测试案例的实际测试结果记录，实际执行的测试案例对需求覆盖情况分析记录，所有缺陷的记录和解决跟踪记录等供必要情况下的检查。

要求：

测试执行结束后应完成包含以上信息的测试报告，并提供支持报告内容和结论的过程记录文档。

最后，对照准出检查列表，检查所有准出条件的满足情况，所有条件满足后，此阶段测试可以结束。

3.缺陷管理

3.1缺陷管理的主要目的

缺陷的处理是和测试执行并行进行的，发现的缺陷需要尽快进行识别，分析，修正并进行重新验证，这些工作都需要在测试执行阶段内完成。

缺陷的处理过程不但涉及测试人员，也要引入开发人员，因此，如果在缺陷处理上管理不到位，会出现沟通不畅，处理效率低，进展慢，甚至有些缺陷无人处理的状况，会影响整个测试执行的进展和质量。

缺陷管理的目的是确保在测试执行过程中发现缺陷后能够按照预定的规则，进行有效的处理，避免因为管理，沟通等问题，导致某些缺陷被遗漏，忽略，或处理缓慢等情况。

3.2缺陷管理的一些基本要求

在缺陷管理过程中，应满足以下一些基本要求

缺陷的记录：

所有测试执行阶段发现的缺陷应该在第一时间记录下来，缺陷记录应包含：

缺陷的标识，内容描述，涉及的案例，发现人，时间以及相关的测试记录，拷屏等内容以及缺陷的分级。

缺陷的分级：

根据缺陷的影响范围，严重程度，缺陷应该划分严重等级。

不同的严重等级缺陷，其处理时效，关注程度也不同。

缺陷的分级应遵循统一的标准。

缺陷管理流程：

一套基本有效的流程对缺陷进行管理，确保缺陷可以被有效地分析，解决。

缺陷的状态：

缺陷在管理过程中应用不同的状态进行标识，以表明缺陷处于什么样的解决步骤中。

缺陷状态与所用的缺陷管理和流程相关。

缺陷处理的记录：

对缺陷的分析，处理等动作，应将相关的处理方式，结果，时间，处理人等信息记录下来，以可以跟踪缺陷处理的过程。

缺陷报告：

可以清晰准确的了解所有缺陷的关键统计信息，包括缺陷的严重等级分布，状态分布等情况。

缺陷管理应满足以上的一些基本要求，缺陷数据将作为测试报告中的关键输入，而缺陷的解决过程，解决结果和细节记录将成为测试结论的关键参考因素和支撑证明。

注：

缺陷的分类与属性请参考《缺陷管理指南》，缺陷的处理流程请参考《缺陷管理流程》

3.3缺陷管理工具

缺陷处理是一个多组织，多人员协作的过程，管理和沟通的要求比较高，特别是对于人员较多的大系统，大项目更是如此。

因此，缺陷管理通常需要使用适当的工具进行支持。

现阶段使用JIRA工具进行缺陷管理工作，未来可能采用RTC工具进行管理。

4.测试环境管理

4.1测试环境管理的主要目的

测试环境是执行测试案例的条件，测试环境的有效性，稳定性和可信性直接影响到测试案例的可执行性和测试结果的可信性。

因此测试环境的搭建，准备和在测试执行期间的管理是确保测试执行顺利进行，测试结果准确可信的关键。

4.2测试环境管理的主要内容

测试环境管理工作的主要内容包括：

Ø测试用服务器和设备的搭建

Ø基础操作系统，软件的安装配置

Ø被测应用的安装，部署

Ø被测应用的版本变更与管理

Ø测试工具的部署和配置

Ø测试系统与外围系统或接口的连接与调试

Ø测试系统外围接口的模拟

Ø测试环境的备份，变更与恢复等

测试环境管理包括很广泛的内容，因此测试环境的搭建，准备等工作是相当多的。

测试环境的规划与设计应该基于整个系统的长期需要或者多个系统的综合需要进行，而不是只为某次测试而从头准备，这样才能提高测试环境的质量和降低每次测试在测试环境上的准备工作。

而每次的测试将需要考虑对使用测试环境的策略，对测试环境的要求，需要的调整或准备，以及在测试过程中如何管理等内容。

4.3测试环境的管理要求

为了保证对测试的支持和保证测试结果的可信性，对于测试环境的管理应具备以下基本要求：

Ø应该具备专门用于测试的环境。

测试所使用的环境应该是专用的环境，不能是用于开发活动或者生产运行的环境。

开发环境无法满足测试对环境的稳定性和安全性要求，而测试环境的风险又有可能对生产造成影响。

Ø测试环境应与未来的生产环境有可比性，除测试代码版本外，对于功能测试，测试环境的操作系统，软件及其版本，配置参数等应与生产环境尽量一致。

对于性能测试等非功能测试，测试环境的容量等方面也要与生产环境相对比，以决定对测试的影响。

Ø在测试的计划步骤中，应该考虑到对测试环境的需求，以及准备测试环境的策略（如使用哪个已有的测试环境，是否需要搭建新的环境，现有环境需要哪些调整，对外围接口有哪些要求，是否可用等等），在测试准备阶段需要根据计划，对测试环境进行准备，并在测试准入检查中进行检查确认。

Ø测试环境的应用版本应进行有效的控制和管理，在测试案例的执行过程中，被测应用的代码，配置等不允许进行变更和调整。

对于因缺陷修复需要调整代码的，应在条件允许情况下，积累到一定数量（通常是一轮测试执行结束）后进行。

变更时应对明确需要变化的代码，并分析其对功能或案例影响，决定哪些案例需要重新进行测试。

5.测试数据管理

5.1测试数据管理的主要目的

测试数据是执行测试案例所需要的输入和运行的条件，不同的测试数据，可能导致测试案例执行的成功或失败。

因此测试案例在设计需要对测试数据有一定的要求。

在测试案例执行时，相关的测试数据需要准备好。

但如果依靠每个测试人员各自准备自己的测试数据，则工作量大，数据的质量不一，还会导致大量的测试数据重复，甚至冲突。

另外，对于性能测试等非功能测试，也需要大量的测试数据或者特别设计的测试数据。

因此需要根据测试的目的，需求和整体的测试案例情况，统一进行测试数据的规划和准备，并指导测试人员在测试执行时，选择使用适当的测试数据。

测试数据的管理除了关注于测试数据的准备效率，数据质量外，如果测试数据是来源于生产的话，还应关注与测试数据中敏感信息的问题，对于涉及到安全（账号，密码，密钥）和用户信息，特别是用户敏感信息的生产数据，不能直接用于测试环境中使用，应获得管理方的批准并进行脱敏处理后才可以用于测试环境。

5.2测试数据管理的主要内容

测试数据管理工作的主要内容包括：

Ø测试数据的需求分析

Ø测试数据的规划，准备

Ø从生产中提取数据的脱敏处理

Ø测试数据的导入，验证

Ø测试数据的调整

Ø测试数据的备份，恢复等

有效的测试数据的管理也可以考虑长远的使用，因此除设计，规划从长远考虑外，在管理过程中也需要采用一些长远的，可逆的措施，例如，测试数据准备好后，进行及时的备份，这样当一次测试完成后，需要重新测试或者下一次测试时，可以快速地进行恢复，从而提高测试数据的准备效率。

5.3测试数据的管理要求

为了确保测试案例的正确和顺利执行，确保测试结果的可信性，对与测试数据的管理应具备以下基本要求：

Ø在设计测试场景和测试案例时，应该考虑到测试场景和案例对测试数据的需求。

Ø在测试设计阶段，制定测试数据的来源和准备策略，制定测试数据准备所需的工作和所需的人员。

Ø在测试准备阶段，统一考虑测试数据的整体需求，并进行相应的准备工作。

在测试准入阶段检查测试数据的准备情况。

Ø对于来自于生产的数据，必须进行相应的脱敏过程，才能导入测试环境使用。

Ø通过备份恢复等手段，实现测试数据的反复使用，避免大量的重复的准备工作，提高测试数据准备效率。