测试流程及规范

上传人:ni****g 文档编号:510013234 上传时间:2023-03-04 格式:DOCX 页数:22 大小:370.85KB
返回 下载 相关 举报
测试流程及规范_第1页
第1页 / 共22页
测试流程及规范_第2页
第2页 / 共22页
测试流程及规范_第3页
第3页 / 共22页
测试流程及规范_第4页
第4页 / 共22页
测试流程及规范_第5页
第5页 / 共22页
点击查看更多>>
资源描述

《测试流程及规范》由会员分享,可在线阅读,更多相关《测试流程及规范(22页珍藏版)》请在金锄头文库上搜索。

1、1目的侧重测试工作流程及规范的控制,明确产品研发的各阶段测试组应完成的工作。测试技术和策略等问 题不在本文档描述范围内。本规范作为所有测试组成员工作前必须掌握的工作规范,也供给其它部门其它组查阅参考,以便于组 间的协调沟通,更好的合作完成产品的研发工作。2概念与术语在整个产品的研发过程中,测试类型按照先后顺序主要分为:单元测试、集成测试、系统测试及产品确认,整个过程如下面的 W莫型所示:集成测试执行集成测试绘图/编码走查/审核有关的测试类型的概念如下:1)单元测试:验证产品中的模块,测试依据主要为模块详细设计或模块的需求规格。能使问题及早 暴露,也便于问题的定位解决,单元测试属于早期测试,因而

2、错误发现后能明确知道是某一单元产生的, 单元测试允许多个被测单元的测试工作同时开展。根据公司研发流程的实际情况,此测试也可由设计研发 人员执行。2)集成测试是验证模块间接口及匹配关系,测试依据主要为概要设计。一般采用自底向上或自顶向 下的模块集成方法,逐步集成。在此环节中测试组还负责验收研发人员提供的转测试的材料,如果材料不 完备,测试组可以拒绝接收。3)系统测试是对系统的一系列的整体、有效性、可靠性的测试,测试依据主要为设计规格及产品需 求规格。目的是确认产品与设计规格、需求、行业标准及公司标准的符合性,同时还要确认性能和系统的 稳定性,与之前的集成测试应遵循“相同的被测对象不要做两遍相同的

3、测试”的基本原则。4)除单元测试、集成测试和系统测试之外,还应有“产品确认”环节,即在客户环境中或模拟客户 环境测试与验证产品,在有限的试用客户中或模拟客户环境中发现产品问题并加以妥善处理,保证产品质 量,提高客户满意度。确认与实验室内部测试的区别在于:实验室内部测试要尽可能多做,多发现问题; 确认要在达到质量目标的情况下尽可能少做;两者要在质量和成本之间权衡、综合考虑。5) TDD.全称 Mercury TestDirector , 一种测试管理工具。6)黑盒测试:黑盒测试也称功能测试,它是通过测试来检测每个功能是否都能正常使用。在测试中, 把程序看作一个不能打开的黑盒子,在完全不考虑程序内

4、部结构和内部特性的情况下,在程序接口进行 测试,它只检查程序功能是否按照需求规定正常使用,程序是否能适当地接收输入数据而产生正确的输 出信息。黑盒测试着眼于程序外部结构,不考虑内部逻辑结构,主要针对软件界面和软件功能进行测试。 黑盒测试是以用户的角度,从输入数据与输出数据的对应关系出发进行测试的。3职责角色名称相关主要责任测试主管组建测试小组协调测试小组内外部的沟通组织编制测试大纲(含测试用例)和计划组织测试准入检查测试过程中的进度控制、风险管理测试过程报告编写测试报告召集测试评审测试人员识别测试需求参与编制测试大纲(含测试用例)和计划协助测试准入检查执行测试用例,测试结果记录测试缺陷记录与跟

5、踪协助测试评审支持人员为测试工作提供技术支持,比如环境安装、版本布署、测试工具支持等备注:该角色可选,可根据项目实际情况设置,一般情况下由研发人员担任。【注】:当某个项目仅有一个测试人员时,该测试人员同时也为该项目内的测试主管,需要担负起测试主管的职责。4测试类型和测试方法4.1 测试类型测试工作通常分为 4个类型,功能测试、联合测试、性能测试及稳定性测试。测试类型测试意义功能测试确保功能符合需求定义确保所有功能可以正常完成工作联合测试一个新产品或一个产品的新版本发布时,要确保与之相配合的产品可以正常配合使用性能测试在产品有性能要求的部分,进行性能测试和调优,确保产品性能符合需求稳定性测试模拟

6、用户真正的使用情况,设计相应的测试用例,确保产品可以稳定可靠的长时间运行4.2 测试方法测试类型测试方法功能测试/联合测试以手工黑盒测试为主,手工执行功能测试用例。正规测试和随机测试相结合:根据需求文档撰写测试方案及测试用例来进行常规测试,考虑到测试用例有可能 写的不全面,所以在进行常规测试过程中,可以加入随机测试。同时,对预测试 出来的缺陷,将其执行过程写成一个测试用例,添加到测试用例集合中,以完善 测试用例;采用测试工具 TD进行测试用例的管理和缺陷记录、跟踪。性能测试性能测试要求满足两种情况:1)产品在特定工况卜可以达到的最高性能(例如:测试时将日志等影响性能的选项关闭);2)模拟用户真

7、正的使用环境(如:日志功能打开,在一定的用户数量的情况下),产品真实可以达到的性能;稳定性测试稳定性测试要求模拟用户真正的使用情况,设计相应的测试用例,确保产品可以稳定可靠的长时间运行【注】:黑盒测试过程的参考准则:(1)必须采用边界值分析法;(2)必要时采用等价类划分法补充测试用例;(3)采用错误判断法,追加测试用例;(4)对照程序逻辑,检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准,应当补充更多的测试用例;(5)测试数据应准备充分,应采用有效数据、无效数据、边界数据分别测试验证;5工作流程、模式及规范5.1 工作流程测试工作可划分为三个阶段,每个阶段由不同的活动组成。测试

8、需求5.2 测试提交文件及裁剪说明阶段提交文件必须提交模板定义裁剪条件说明测试需求测试需求分析报告否项目组自定义无特殊需求,可省略测试计划测试大纲是项目组自定义各项目组根据测试任务的规模可自定义模板测试计划否项目组自如果测试大纲或设计开发计划中已包括了测试计定义划的内容,则本文档可省略测试大纲计划评审记录否公司模板各项目酌情选用测试用例是公司模板采用公司统一测试用例模板测试用例评审记录否公司模板各项目酌情选用测试实施测试准入检查表否公司模板各项目酌情选用测试记录是项目组自定义各项目组根据测试任务的规模可自定义模板测试收尾测试报告是公司模板采用公司统一测试报告模板测试报告评审记录否公司模板各项目

9、酌情选用测试工作改进报告否项目组自定义各项目酌情选用测试成果提交否项目组自定义各项目酌情选用5.3 评审点评审点定义参照设计开发控制程序。5.4 敏捷测试模式5.4.1 敏捷测试概念敏捷测试即是不断修正质量指标,正确建立测试策略,确认客户的有效需求得以圆满实现和确保整 个生产的过程安全的、及时的发布最终产品。5.4.2 敏捷增量测试方法测试是敏捷开发过程重要的环节,自始自终测试贯穿于每个迭代。整个产品的敏捷开发生命周期可以 分为4个阶段,即初始阶段,项目的建设阶段,产品发布阶段和产品的维护阶段,在关键的项目建设阶 段中,测试被分成两个部分,验证测试和系统测试。验证测试:静态测试和关键的功能测试

10、。系统测试:功能测试、联合测试、性能测试、稳定性测试。5.4.3 敏捷测试流程敏捷测试流程依据业务场景制定测试策略。在每次敏捷测试的过程中包括验证测试和联合测试。并且不断的进行迭代测试。在系统的所有业务场景都经过敏捷测试过后,进入系统测试阶段。进行所有业务场景的功能测试、联合测试、性能测试、稳定性测试。根据业务场景制定测试策略流程图敏捷测试流程图测试计划敏捷测试系统测试条件测试是否通过测试通过NYY系统测试和回归测试进入下一次敏捷迭代测试总结根据缺陷性质来判断更新提交测试的依据:1)严重级别为Urgent和High的修改后立即更新,要保证更新后不能影响其他功能测试。2)功能级别为Medium以

11、下的可以等待下一次提交敏捷测试的时候更新。5.5 传统瀑布模式5.5.1 测试需求分析过程要点详细说明启动条件需求阶段的工作启动工作内容由测试主管根据项目任务复杂程度组织或指定测试人员进行测试需求分析,从客户角度考虑软件测试需要达到的验证状态,并确定是否要形成测试需求分析报告结束条件需求分析完成例外对于简单设计更改、衍生产品等只需例行测试的,可不进行测试需求分析责任人项目经理参与人测试主管5.5.2 成立测试小组或确认测试人员过程要点详细说明启动条件测试任务明确,前期工作启动工作内容确认项目的测试人员,若整个项目的测试需要岩千个测试人员,则需要成立一个测试小组;为测试小组任命一名测试主管,若只

12、什-个测试人员, 则该测试人员同时也为该测试组的测试主管,同时确定测试小组的其它构成人选;小组内进行必要的培训。结束条件测试小组成立例外若以前的测试任务已成立过测试小组,则可以复用以前的组织人员和形式责任人项目经理参与人测试主管5.5.3 编制测试计划过程要点详细说明启动条件项目阶段,住计划确定需求规格说明书、详细设计说明书等已评审工作内容测试大纲至少包括以下关键内容:测试目标一一对本次测试的要求和要达到的目标测试范围一一需要测试小组测试的范围,和各个测试需求的测试优先级工作分工一一明确测试小组内部及外部配合方的相关责任和工作关系测试策略一一整体测试的总体测试策略、环境、方法和工具等完成标准一

13、一达到何种条件可以认为测试完成交付文件一一测试完成时应提交的文件,比如测试大纲(含测试用例)、测试报告等等测试计划至少应包括以下关键内容:主要任务一一每项任务的时间计划、前置条件及资源主要里程碑一一关键任务及完成时间点在项目研发过程中, 要适时的对测试计划进行跟踪,以评估此计划的完整性、可行性,在项目结束时还要最后评估一下测试计划的质量结束标准测试计划评审通过或得到相关各方的审批输出文件测试计划、测试计划评审记录例外对于多个系统参与的同一个测试任务,可由主项目组或牵头方统一编制测试大纲和计划,不用每个系统单独编制和出具测试计划可以在测试大纲中直接详细列明,而不用单独编制责任人测试主管参与人研发

14、总监、项目经理、测试人员5.5.4 编制测试大纲、设计测试用例在技术规格书评审通过以后,测试小组需要针对项目的测试范围编制测试大纲、设计测试用例。在实 际测试过程中,测试用例可根据实际需要进行更新和调整。在测试用例的设计过程中,具体的任务和责任 人如下:过程要点详细说明启动条件本次测试范围、业务需求已经明确需求规格说明是、详细设计说明书已通过评审工作内容准备本次测试的测试用例测试用例在该产品的测试用例库中进行选择,如有需要,可以进行增加;每个测试用例须包括用例编号、测试概述、测试数据、操作步骤说明、预期结果等要素;测试用例须覆盖所有的测试需求和功能点;采用统一的模板进行用例设计。结束标准测试用例覆盖所有的待测试需求或功能点,并且评审通过输出文件测试大纲、测试用例、测试大纲评审记录责任人测试人员参与人研发总监、研发人员、项目经理、测试主管5.6 测试实施阶段5.6.1 测试准入检查过程要点详细描述启动条件测试实施准备工作完成工作内容测试主管根据本项目的特点,事先确定测试准入标准中哪些条目可以进行裁剪,并与项目经理及研发人员商讨确认准入标准中“计划准入标准”是指编制测试

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 商业/管理/HR > 营销创新

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号