系统测试过程作业指导书

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

项目标准过程规范HB-ST-01系统测试过程作业指导书

[状态]

2014/1/1

目录

1.概述 (1)

2.作业指导 (1)

2.1.作业规范 (1)

2.2.交付物清单 (1)

2.3.适用范围 (1)

2.3.1.适用对象范围 (1)

2.3.2.适用项目范围 (1)

2.3.3.职责 (1)

2.3.4.名词解释 (2)

2.3.5.参考文档 (3)

2.4.测试流程与管理 (3)

2.4.1.需求评审 (3)

2.4.2.制定测试计划 (4)

2.4.3.测试用例 (5)

2.4.4.准备测试环境 (8)

2.4.5.准备测试数据 (8)

2.4.6.测试执行 (8)

2.4.7.缺陷管理 (10)

2.4.8.回归测试 (14)

2.4.9.测试报告 (14)

2.4.10.测试通过标准 (14)

2.4.11.结束 (15)

1.概述

“软件测试作业指导书”用于指导软件测试过程及流程规范,使各个项目测试流程更加规范,保证软件测试质量,。

2.作业指导

请参见《SPEC项目标准过程规范》

适用于质量控制部门负责人、测试主管、测试人员、项目经理、需求编写者、SQA

1.对于新产品开发,必须使用此过程进行系统设计。

2.现有产品主版本升级,必须使用此过程进行系统设计。

3.现有产品小版本更新和bug修复,需要识别受影响的内容,并使用此过程进行系统设计。

4.现有产品的客户化定制开发,需要识别受影响的内容,并使用此过程进行系统设计。

1.系统测试:是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起,进行信息系统的各种组装测试和确认测试,系统测试是针对整个产品系统进行的测试,目的是验证系统是否满足了需求规格的定义,找出与需求规格不符或与之矛盾的地方,从而提出更加完善的方案。系统测试发现问题之后要经过调试找出错误原因和位置,然后进行改正。是基于系统整体需求说明书的黑盒类测试,应覆盖系统所有联合的部件。对象不仅仅包括需测试的软件,还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。

2.测试用例:所谓测试用例设计就是将软件测试的行为活动,作为一个科学化的组织归纳。软件测试是有组织性、步骤性和计划性的,而设计软件测试用例的目的,就是为了能将软件测试的行为转换为可管理的模式。软件测试是软件质量管理中最实际的行动,同时也是耗时最多的一项。基于时间因素的考虑,软件测试的行为必须能够加以量化,才能进一步让管理层掌握所需要的测试过程,而测试用例就是将测试行为具体量化的方法之一。简单的说,测试用例就是设计一个情况,软件程序在这种情况下,必须能够正常运行并且达到程序所设计的执行结果。

3.等价类:等价类是指某个输入域的子集合。在该子集中,各个输入数据对于揭露程序中的错误都是有效的。并合理地假定:测试某等价类的代表就等于对这一类其他值的测试。

4.边界值分析法:边界值分析是一种补充等价划分的测试用例设计技术,它不是选择等价类的任意元素,而是选择等价类边界的测试用例。

5.错误推断法:错误推测法就是基于经验和直觉推测程序中所有可能存在的各种错误,有针对性地设计测试用例的方法。

6.因果图法:是一种适合于描述对于多种输入条件组合的测试方法,根据输入条件的组合、约束关系和输出条件的因果关系,分析输入条件的各种组合情况,从而设计测试用例的方法,它适合于检查程序输入条件涉及的各种组合情况。因果图法一般和判定表结合使用,通过映射同时发生相互影响的多个输入来确定判定条件。因果图法最终生成的就是判定表,它适合于检查程序输入条件的各种组合情况。

7.判定表:是分析和表达多逻辑条件下执行不同操作的情况的工具。在程序设计发展的初期,判定表就已经被用作编写程序的辅助工具了。它可以把复杂的逻辑关系和多种条件组合的情况表达得较明确。

8.正交试验设计方法:依据Galois理论,正交试验设计方法是从大量的试验数据中挑选适量的、有代表性的点,从而合理地安排测试的一种科学的试验设计方法。

9.场景法:现在软件几乎都是用事件触发来控制的流程的,事件触发的情景便形成了场景,而同一事件不同的触发顺序和处理结果就形成了事件流。这种在软件设计方面的思想也可引入到软件测试中,可以比较生动地描绘出事件触发时的情景,有利于测试设计者设计测试用例,同时使测试用例更容易理解和执行。

2.4.1.1.启动准则

1.项目已经立项

2.需求初稿已经完成

2.4.1.2.评审内容

测试主管,测试负责人及测试人员对《需求规格说明书》进行阅读和审查,与需求经理、项目经理沟通,根据系统功能复杂度,系统业务复杂度进行估算有效测试执行时间,为项目总计划和测试计划的制定提供参考和依据。

通过对文档分析,分解各功能模块,各功能点,为测试用例设计提供数据依据。

2.4.2.1.输入文档

1. 《需求规格说明书》

2. 《开发计划》

2.4.2.2.测试计划设计

当测试部接到测试项目任务时,根据项目计划、开发计划、开发文档(需求或概要设计等),由测试主管或测试主管指定的项目测试负责人制定测试计划。测试计划内容主要包括测试范围、测试策略,测试重点、测试时间、人员安排、任务安排,结束标准、测试风险等具体见《测试计划模板》。

测试计划在策略和方法方面说明如何计划、组织和管理测试项目。测试计划包含足够的信息使测试人员明白项目需要做什么,是如何运作的。测试计划不包括测试用例的细节和系统功能的详细信息。测试计划的制定请参阅《测试计划》模板。测试计划应附有测试功能点矩阵、测试性能点矩阵等。

2.4.2.

3.测试计划评审

测试计划编写完成后,应在项目组内先进行内部评审。内部评审通过后,在组织项目组人员评审,参与测试计划正式评审的人员包括:项目经理、测试主管、开发组长、测试组员等。

在测试计划进行审核时应注意以下几点:

1、时间安排合理性可用性

相关文档
最新文档