CMMI5文档之测试规程.docx
- 文档编号:11885933
- 上传时间:2023-04-08
- 格式:DOCX
- 页数:31
- 大小:116.08KB
CMMI5文档之测试规程.docx
《CMMI5文档之测试规程.docx》由会员分享,可在线阅读,更多相关《CMMI5文档之测试规程.docx(31页珍藏版)》请在冰豆网上搜索。
CMMI5文档之测试规程
测试规程
文档编号:
FHI_CMMI_VER_PRD_TEST
文档信息:
测试规程
文档名称:
测试规程
文档类别:
CMMI规程
密级:
内部秘密
版本信息:
1.2
建立日期:
2016-1-5
创建人:
EPG
批准人:
李庆林
批准日期:
2016.2.25
存放位置:
集成公司组织资产库/组织标准过程
编辑软件:
MicrosoftOffice2003中文版
文档修订记录
版本编号或者更改记录编号
*变化状态
简要说明(变更内容和变更范围)
日期
变更人
批准日期
批准人
V1.0
C
创建
2016-1-5
张娜娜
2016-2-25
李庆林
V1.1
M
补充对测试策略的描述
2016-3-7
张娜娜
2016-3-7
李庆林
V1.2
M
文档编号去掉版本号
2016-4-17
邓沛沛
2016-4-17
李庆林
*变化状态:
C――创建,A——增加,M——修改,D——删除
1.简介
目的
软件测试是确保最终交给用户的产品的功能符合用户的需求,把尽可能多的问题在产品交给用户之前发现并改正。
软件测试包括系统测试、集成测试和单元测试,每个阶段对应软件生命周期的需求、设计和编码并检查他们的缺陷。
本文的目的是规范测试工作,为软件测试工作提供详细的指引。
以发现错误为目的,提高组织内部软件测试的管理水平,确保组织中开发产品的质量。
软件测试确保最终交给用户的产品的功能符合用户的需求,把尽可能多的问题在产品交给用户之前发现并改正。
具体地讲,测试一般要达到下列目标:
确保产品完成了它所承诺或公布的功能,并且所有用户可以访问到的功能都有明确的书面说明。
确保产品满足性能和效率的要求。
确保产品是健壮的和适应用户环境的。
适用范围(将范围具体化)。
本文档的适用范围为组织中的所有软件项目。
适用对象:
软件质量管理部、软件部
业务范围:
测试设计、测试用例、单元测试、集成测试、系统测试。
术语表(增加两种测试的解释)
驱动程序(Driver):
在单元测试和集成测试中,协调输入和输出的测试程序;
桩程序(Stub):
在单元测试和集成测试中,模拟被调用单元的测试程序;
冒烟测试(Smokingtest):
对通过创建的程序代码进行的通过性验证,以确定该版本是否具有可测性。
冒烟测试的目标是显示系统的稳定性、而不是发现系统的每个缺陷。
冒烟测试必须在系统测试环境中运行。
测试计划:
包含项目范围内的测试目的和测试目标的有关信息,确定了实施和执行测试时使用的策略,确定了测试所需资源。
测试用例:
为特定目标开发的测试输入执行条件和预期结果的集合。
测试脚本:
是自动执行测试过程或部分测试过程的计算机可读指令。
测试脚本可以被创建录制或使用测试自动化工具自动生成或用编程语言编程来完成,也可综合前三种方法来完成。
集成测试:
集成测试又称组装测试。
是对已经按设计要求和集成顺序完成组装的产品或产品构件的测试,以检查产品或产品构件的接口是否存在问题。
集成测试是针对设计的。
系统测试:
系统测试是将通过集成测试后的产品在实际运行环境或模拟环境下进行的功能性和非功能性测试。
系统测试是针对设计和需求的。
参考资料
无
2.过程总体描述
过程概述
软件测试开发、管理流程贯穿了项目的整个开发和测试生命周期,与整个软件开发过程基本上是并行进行并相互协调的。
测试流程如下:
1.测试人员参与需求分析和设计评审,确定需求的可测性,并贯穿开发的整个过程;
2.项目组编写开发计划书,如果需要进行性能测试,还需要提交《用户状况调查表》,测试人员据此产生测试计划书;
3.测试人员细化测试计划,产生测试计划书和测试用例;
4.测试计划作为项目开发计划的子计划提交评审,测试用例需要经过项目组内审查批准。
评审和审核通过的测试计划和测试用例,放入配置库。
5.开发人员完成单元模块编码,然后对单元模块经过一系列静态检查和动态测试;对代码要进行自查、项目经理走查、QA审计;
6.测试组执行集成测试,验证各通过单元测试的模块组合在一起的功能及其接口、数据传输的正确性,满足系统设计所规定的特性;
7.版本集成测试人员按集成或构造计划、从配置库中获得相应版本的源代码进行版本集成\构造活动,并对集成\构造版本进行管理;
8.测试人员对通过构造的工作产品执行冒烟测试,冒烟测试通过准则由测试人员和项目组事先约定,对冒烟测试未通过的系统,原则上由项目组当天解决问题,再次提交测试版本;
9.测试人员对完成集成的模块执行功能测试,即流程图所示功能集成测试;执行该过程实际上是对项目组集成测试的回归测试。
10.重复步骤5-9,直至该版本所有功能都完成开发和经过功能集成测试;
11.测试人员根据测试计划中定义的系统测试策略,完成其它约定内容的测试如性能测试、可使用性测试、安全性测试、安装/反安装测试等;
12.完成全部测试工作或根据事件驱动,测试负责人撰写测试分析报告;
13.对没达到测试出口准则的项目,由高层经理进行审批后,可作例外放行;
14.通过测试机构测试的项目,在公司范围内进行产品版本发布并移交产品管理部产品库。
过程结构描述
图1测试管理总流程图
软件测试数据流程图
图2测试数据流程图
角色及职责(建议修改成表格便于查看)
角色
职责及权限
测试机构主管
1.组织公司测试机构的日常工作。
2.指定测试负责人(主要是系统测试阶段),提供项目测试资源。
高层经理
1.审批项目的测试计划,处理项目中不能达成一致的缺陷问题。
项目经理
1.与测试负责人一起制定测试计划;审查测试用例;
2.进行缺陷的分配工作,督促开发人员对缺陷的修改;
3.监督测试计划的执行。
测试负责人
1.全面负责组织测试的计划、设计、实施、执行、评估过程;
2.检查项目测试工作完成和遗漏情况;对提交的缺陷进行有效性验证;
3.及时汇报测试进展情况和存在的问题;
4.负责对测试计划、测试用例、测试分析报告进行编写、修订等工作,并参与以上工作内容的评审;
5.单元测试与集成测试中测试负责人可以是项目经理或项目经理指定的负责人;
6.项目中测试负责人对项目经理负责。
集成测试人员
1.按集成\构造计划、从配置库中获得相应版本的源代码进行编译、联接等版本集成\构造活动,提交集成\构造结果给测试人员,并对集成\构造版本进行管理。
(在没有固定集成测试人员时,版本集成由开发人员或配置管理员兼任)
测试人员
1.执行测试、缺陷提交、跟踪验证、回归关闭;
2.完成测试负责人分配的相关工作。
(注:
单元测试与集成测试中测试人员可以由开发人员担任)
QA人员
1.测试过程质量保证,参与测试相关工作产品的审查,统计缺陷;
2.参与计划、设计及执行结果评审。
CM人员
1.参与测试过程中工作产品的配置工作,对测试文档及代码等相关配置项进行配置管理,按组织的配置管理过程执行。
测试分类(建议修改成表格便于查看)
根据面向过程软件测试所实施的操作类型可划分如下:
测试类型
说明
单元测试
单元测试是对最小的可测试软件元素(单元)实施的测试,它所测试的内容包括单元的内部结构(如逻辑和数据流)以及单元的功能和可观测的行为。
使用白盒测试方法测试单元的内部结构,使用黑盒测试方法测试单元的功能和可观测的行为。
单元测试由开发人员或测试人员执行。
集成测试
集成测试的目的是确保经过单元测试的各模块组合在一起后能够按既定意图协作运行。
它所测试的内容包括集成后的功能。
集成测试由测试组完成,测试组使用黑盒测试方法测试集成的功能。
系统测试
在实际(或模拟)使用环境下,针对系统需求书规定的所有功能和非功能需求的全面验证工作,测试整个系统,以证实它满足要求所规定的功能、质量和性能等方面的特性。
系统测试由测试组完成。
验收测试
在用户的实际环境中,以用户文档为依据,测试整个系统,以保证其达到可以交付使用的状态。
验收测试一般由用户进行测试设计和执行,本规程不详细说明。
3.过程元素描述
测试计划制定及管理
3.1.1.过程元素概述
根据批准的需求规格说明书和相关设计文档,确定项目测试阶段的目标和策略,确保测试工作有序、有效进行。
3.1.2.参与人员
请参见2.4章节内容
3.1.3.入口准则
客户需求已明确
3.1.4.输入
《软件需求规格说明书》
3.1.5.任务
15.确定系统的测试需求,如功能需求、性能需求、安全性要求、可使用性需求等需求说明书中说明的和潜在的需求;
16.测试负责人与项目经理协商,逐步确定测试项目的测试范围、测试粒度(覆盖标准)以及测试方案、测试阶段的出入口准则;
17.根据《软件估计规程》以及项目的复杂度和以往的测试数据初步估计测试项目工作量,制定测试计划的进度安排;测试进度安排中要留有合理的测试缺陷、用例管理时间;选择需要的测试工具;
18.形成测试计划书(单元、集成、系统阶段的计划可包括在内,也可在各阶段进行细化)并提交测试负责人、项目经理或高层经理审核。
批准人为项目经理。
审核批准通过则放入开发配置库;
19.当项目开发计划或测试需求发生变更时,测试计划应考虑是否需要变更。
3.1.6.出口准则
测试计划编写完成并批准;
3.1.7.输出
《测试计划》;
《项目问题日志》之《评审问题》。
3.1.8.资源和能力要求
测试人员接受过测试策略相关的培训;
测试人员具备制定测试计划的能力。
测试用例设计及管理
3.1.9.过程元素概述
根据批准的需求规格说明书和相关设计、计划文档,策划测试过程执行依据,确保测试范围有效并正确。
3.1.10.参与人员
请参见2.4章节内容。
3.1.11.入口准则
客户需求已明确。
3.1.12.输入
《用户需求说明书》;
《软件需求规格说明书》;
《概要设计说明书》或《系统设计说明书》;
《需求跟踪矩阵》。
3.1.13.任务
用例设计:
Ø测试人员参与需求评审,正确理解系统需求并确认需求的可测性,获取测试项目需求;
Ø根据批准的测试项目需求(在测试计划中有测试需求的详细描述)、测试目标的逻辑实现和约束、测试工具及其测试环境等限制条件,设计测试用例;并确定系统测试中自动测试和手工测试的范围。
Ø测试负责人根据系统的软件需求,组织测试人员编写系统测试用例;
Ø测试负责人根据系统的概要设计、详细设计,组织测试人员编写集成测试用例;在如下情况下集成测试用例可省略:
1、项目结构设计简单,无组件集成的需要;
2、各子系统、组件之间无互联关系,主程序对各子系统、组件的调用接口、功能调用等都是简单的页面连接,互不关联等;
3、系统集成的组件或子系统是公司成熟的产品,以前项目多次使用通过集成验证,集成测试用例可以是重用的。
Ø当第一个集成\构造版本提交后。
如果没有使用缺陷管理工具和自动化测试工具,则必须在测试用例相应栏目填写测试结果。
自动化功能测试脚本主要应用于冒烟测试和回归测试;
Ø测试负责人发起组织项目组成员进行测试用例评审,从而提高测试用例的质量;系统测试用例审核人可以是测试负责人、项目经理、测试机构主管,批准人为项目经理;
用例管理:
Ø测试负责人负责进行阶段测试用例的实施、跟踪及用例统计分析工作、改进测试用例等管理活动;
Ø当软件需求或设计变更引起测试需求变更时,将变更测试用例文档;
Ø测试负责人实时或定期根据缺陷数据、状态和测试用例执行情况进行分析,以确定是否需要对目前测试的模块设计新的测试用例,对不稳定的模块,测试负责人负责与项目经理讨论确定测试范围、粒度和执行方案等,并指定相关人员完成新增测试用例的编写;
Ø新增测试用例批准后由测试人员执行;
Ø是否需要书写某些功能模块的测试用例,要经过项目经理、质量保证员、测试负责人讨论,进行符合管理要求的裁剪,并形成会议纪要。
3.1.14.出口准则
测试用例必须已经项目经理批准通过。
3.1.15.输出
软件测试用例(包括集成、系统测试用例,单元测试用例可以省略部分功能的,对重要和关键部件的单元测试用例可详细设计,以代码走查、轮查代替);
《测试用例》经项目组审核通过;
更新后的《需求跟踪矩阵》。
3.1.16.资源和能力要求
测试人员接受过测试用例编写相关的培训;
测试人员具备使用测试工具的技能。
集成测试
3.1.17.过程元素概述
执行批准的测试计划和方案,验证各通过单元测试的功能模块的独立功能及其接口、数据传输的正确性,满足系统设计所规定的特性。
如有集成测试用例要逐项完成各集成测试用例。
3.1.18.参与人员
请参见2.4章节内容;
3.1.19.入口准则
阶段性的系统集成工作已完成;
3.1.20.输入
已组装完成并通过组装验证的产品或产品构件;
《概要设计说明书》或《系统设计说明书》;
《详细设计说明书》;
《测试计划》;
《集成测试用例》;
《需求跟踪矩阵》。
3.1.21.任务
开发人员搭建测试环境,测试环境使用前要由测试负责人进行验证。
测试人员在符合规定测试环境条件下,使用指定测试及管理工具,编码规则和集成测试用例;依据《产品集成过程》从配置库中提取需要集成的代码模块实施测试活动:
Ø测试人员根据《产品集成设计》,实施产品集成。
设计测试用例,由开发人员担任编写驱动程序和桩程序,测试人员执行测试用例;
记录、跟踪并修改发现的缺陷;
测试负责人组织编写测试报告;
●测试分析报告须得到项目经理确认\审批,并签字;
●测试负责人每周编写测试周报,向高层经理汇报项目测试阶段情况;
测试计划、集成测试用例(可选)、集成测试分析报告可参考其他过程元素如:
测试计划制定及管理、测试用例设计及管理、测试分析报告编写及管理。
3.1.22.出口准则
集成测试分析报告已完成;
3.1.23.输出
集成测试用例(可选);
通过审批后的《集成测试分析报告》;
●通过集成测试的产品或产品构件;
●更新后的《需求跟踪矩阵》。
3.1.24.资源和能力要求
系统测试
3.1.25.过程元素概述
执行系统测试用例,验证各已通过各阶段测试的功能模块已具有满足需求规格说明所规定的功能、质量和性能等方面特性。
3.1.26.参与人员
请参见2.4章节内容
3.1.27.入口准则
系统各功能模块均已实现
集成测试完成
3.1.28.输入
《软件需求规格说明书》;
已通过集成测试的产品;
《测试计划》;
《系统测试用例》;
《需求跟踪矩阵》。
3.1.29.任务
测试负责人组织制定系统测试计划;
开发人员搭建测试环境,测试环境使用前要由测试负责人进行验证。
脚本须即时放入配置库。
对于有测试脚本产生的自动化测试用例,应该在测试用例文档自动测试脚本一栏标明配置库存放路径;
测试实施全过程中,始终存在测试计划变更和测试用例变更以及缺陷管理过程。
可参考测试计划制定及管理、测试用例设计及管理、缺陷管理执行;
测试负责人定期对系统测试质量及效果、进度情况进行评估,确定测试覆盖完整性,检验测试结果是否达到测试出口准则或停止准则;测试负责人必须定期向高层经理、项目经理、测试机构主管、项目组成员、测试人员、QA等通报测试状况;
当测试实施过程中,对于测试出的问题有争议时,由测试机构主管充分参考高层经理的意见,进行最后仲裁;若对于仲裁的结果仍然有争议时,应继续上报上级经理,直至问题得到解决;
系统测试结束后,测试负责人负责汇总、分析测试结果,形成《测试分析报告》提交项目经理审批;
●测试负责人每周编写测试周报,向高层经理汇报项目测试情况;
●测试分析报告须得到项目经理的确认\审批并签字。
3.1.30.出口准则
系统测试分析报告已完成。
3.1.31.输出
审批后的《测试分析报告》;
通过集成测试的产品或产品构件;
●更新后的《需求跟踪矩阵》。
3.1.32.资源和能力要求
测试人员具备设计测试用例,执行测试用例的能力。
性能测试
3.1.33.过程元素概述
执行系统测试用例,验证已通过各阶段测试的功能模块是否具有满足需求规格说明所规定的功能、质量和性能等方面特性。
3.1.34.参与人员
请参见2.4章节内容;
3.1.35.入口准则
系统各功能模块均已实现;
集成测试完成。
3.1.36.输入
《软件需求规格说明书》;
已通过集成测试的产品;
已通过评审的产品资料;
《概要设计说明书》;
《测试计划》;
性能测试用例;
《需求跟踪矩阵》。
3.1.37.任务
开发人员搭建测试环境的。
测试环境使用前要进行验证,测试工具在使用前要确认其功能,必要时对测试工具进行验证。
测试环境应尽量模拟用户的实际运行环境;
性能测试开始前,要按照性能需求对被测产品或产品构件可能承担的业务量、数据量进行估算,导入测试数据,真实模拟用户数据量要求;
测试人员完成性能测试用例脚本的录制和调试及负载模型的建立,验证产品或产品构件的整体性能是否满足性能需求;
性能测试人员将测试缺陷记录;
测试负责人、需求人员、设计人员和测试人员共同对测试缺陷进行分析,确定缺陷原因。
测试人员修改测试的缺陷;
测试人员进行回归测试,直至缺陷关闭。
(每当被测试产品或产品构件及测试环境发生变化时,测试人员需要调整测试环境或测试用例和测试脚本的变更。
);
测试负责人汇总和分析测试结果,编写《测试分析报告》,完成后提交项目经理确认\审批。
3.1.38.出口准则
系统测试分析报告已完成。
3.1.39.输出
通过审批后的《测试分析报告》;
通过集成测试的产品或产品构件;
●更新后的《需求跟踪矩阵》。
3.1.40.资源和能力要求
测试人员具备设计测试用例,执行测试用例的能力。
缺陷管理
3.1.41.过程元素概述
包括对所发现缺陷的记录、审查、跟踪、分配、修改、验证、关闭、整理、分析、汇总以及删除等一系列活动状态的管理。
3.1.42.参与人员
请参见2.4章节内容
3.1.43.入口准则
执行测试的工作已开始。
3.1.44.输入
潜在缺陷内容。
3.1.45.任务
在公司内部测试的项目的缺陷一律采用缺陷管理工具TestDirector进行缺陷跟踪;
客户所在地开发项目的测试缺陷采用缺陷管理工具TestDirector,在无法使用TestDirector的情况下采用excel文档进行缺陷跟踪管理,缺陷放置到《软件缺陷报告模板.xls》中。
3.1.46.出口准则
对缺陷已经进行管理;
测试分析报告已完成。
3.1.47.输出
通过审批后的《测试分析报告》。
3.1.48.资源和能力要求
测试人员具备设计测试用例,执行测试用例的能力
测试分析报告编写及管理
3.1.49.过程元素概述
编写测试分析报告是一个评价测试活动和产品质量的活动过程。
通过分析缺陷的数量、性质、分布情况,评价软件的能力和限制。
同时总结软件测试计划的执行情况,作为同类项目测试计划和测试用例的编写参考依据。
3.1.50.参与人员
请参见2.4章节内容。
3.1.51.入口准则
缺陷数据已收集。
3.1.52.输入
缺陷数据。
3.1.53.任务
测试负责人从TD中统计分析缺陷的数量、性质、分布情况,提取相关数据,如:
总的缺陷数量;每个阶段产生的缺陷数量;缺陷的严重等级分布等。
并根据模版形成《测试分析报告》
测试负责人评价软件能力,包括缺陷和限制;
测试分析报告和缺陷报告入库,实行统一的配置管理过程。
3.1.54.出口准则
测试分析报告已完成。
3.1.55.输出
测试分析报告。
3.1.56.资源和能力要求
测试负责人具备编写测试分析报告和缺陷报告的能力。
4.测试停止准则
4.1.1.集成测试停止标准
1.集成测试用例应达到集成测试要求覆盖率的100%;
2.集成测试用例应通过评审;
3.集成测试中发现的错误修复率为1-High级缺陷修复率应达到100%;2-Mediumr级缺陷修复率应达到90%;3-Low级缺陷修复率应达到60%;4-Suggesion级缺陷根据项目组实际情况,项目组进行调整。
4.1.2.系统测试停止标准
1.系统测试用例设计应达到系统测试要求覆盖率的100%;
2.系统测试用例设计已经通过评审;
3.系统测试中发现的错误修复率为1-High级缺陷修复率应达到100%;2-Mediumr级缺陷修复率应达到100%;3-Low级缺陷修复率应达到80%;4-Suggesion级缺陷根据项目组实际情况,项目组进行调整。
4.1.3.性能测试停止标准
1.性能测试用例设计要达到性能测试覆盖率的100%;
2.性能测试用例设计已经通过评审;
3.性能测试结果达到预期要求(客户许可);如果测试结果经过调优后仍无法达到预期结果,需经客户与项目经理同意方可停止。
5.参考信息
测试策略
5.1.1.数据和数据库完整性测试
测试目标:
[确保数据库访问方法和进程正常运行,数据不会遭到损坏。
]
技术:
[调用各个数据库访问方法和进程,并在其中填充有效的和无效的数据(或对数据的请求)。
检查数据库,确保数据已按预期的方式填充,并且所有的数据库事件都已正常发生;或者检查所返回的数据,确保为正当的理由检索到了正确的数据]
完成标准:
[所有的数据库访问方法和进程都按照设计的方式运行,数据没有遭到损坏。
]
需考虑的特殊事项:
[测试可能需要DBMS开发环境或驱动程序在数据库中直接输入或修改数据。
进程应该以手工方式调用。
应使用小型或最小的数据库(记录的数量有限)来使所有无法接受的事件具有更大的可视度。
]
5.1.2.功能测试
编写说明:
对测试对象的功能测试应侧重于所有可直接追踪到业务功能和业务规则的测试需求。
这种测试的目标是核实数据的接受、处理和查询是否正确,以及业务规则的实施是否恰当。
此类测试基于黑盒技术,该技术通过图形用户界面(GUI)与应用程序进行交互,并对交互的输出或结果进行分析,以此来核实应用程序及其内部进程。
以下为各种应用程序列出了推荐使用的测试概要:
测试目标:
[确保测试对象的功能正常,其中包括导航、数据输入、处理和检索等功能。
]
技术:
[利用有效的和无效的数据来执行各个功能点,以核实以下内容:
在使用有效数据时得到预期的结果。
在使用无效数据时显示相应的错误消息或警告消息。
各业务规则都得到了正确的应用。
]
完成标准:
[所计划的测试已全部执行。
所发现的缺陷已全部解决。
]
需考虑的特殊事项:
[确定或说明那些将对功能测试的实施和执行造成影响的事项或因素(内部的或外部的)]
功能测试区分为两种方式:
详细测试和简单测试。
详细测试:
要求测试用例对测试对象的覆盖度达到100%;
简单测试:
要求测试用例对测试对象进行重点覆盖;
5.1.3.业务周期测试
编写说明:
业务周期测试应模拟在一段时间内对项目执行的活动。
应先确定一个时间段(例如一年),然后执行将在该时间段(一年内)发生的事务和活
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- CMMI5 文档 测试 规程