测试作业流程及标准规范.docx

1、测试作业流程及标准规范1目标侧重测试工作步骤及规范控制，明确产品研发各阶段测试组应完成工作。测试技术和策略等问题不在本文档描述范围内。本规范作为全部测试组成职员作前必需掌握工作规范，也供给其它部门其它组查阅参考，方便于组间协调沟通，愈加好合作完成产品研发工作。2概念和术语在整个产品研发过程中，测试类型根据前后次序关键分为：单元测试、集成测试、系统测试及产品确定，整个过程以下面W模型所表示：设计规格模块设计集成测试系统测试产品确定N概要设计需求规格单元测试三绘图/编码测试需求测试计划测试计划测试纲领走查/审核 实施单元测试实施集成测试 实施系统测试 产品试用图1相关测试类型概念以下： 1）单元测

2、试：验证产品中模块，测试依据关键为模块具体设计或模块需求规格。能使问题及早暴露，也便于问题定位处理，单元测试属于早期测试，所以错误发觉后能明确知道是某一单元产生，单元测试允很多个被测单元测试工作同时开展。依据企业研发步骤实际情况，此测试也可由设计研发人员实施。 2）集成测试是验证模块间接口及匹配关系，测试依据关键为概要设计。通常采取自底向上或自顶向下模块集成方法，逐步集成。在此步骤中测试组还负责验收研发人员提供转测试材料，假如材料不完备，测试组能够拒绝接收。3）系统测试是对系统一系列整体、有效性、可靠性测试，测试依据关键为设计规格及产品需求规格。目标是确定产品和设计规格、需求、行业标准及企业标

3、准符合性，同时还要确定性能和系统稳定性，和之前集成测试应遵照“相同被测对象不要做两遍相同测试” 基础标准。4）除单元测试、集成测试和系统测试之外，还应有“产品确定”步骤，即在用户环境中或模拟用户环境测试和验证产品，在有限试用用户中或模拟用户环境中发觉产品问题并加以妥善处理，确保产品质量，提升用户满意度。确定和试验室内部测试区分在于：试验室内部测试要尽可能多做，多发觉问题；确定要在达成质量目标情况下尽可能少做；二者要在质量和成本之间权衡、综合考虑。5）TD：全称Mercury TestDirector，一个测试管理工具。6）黑盒测试：黑盒测试也称功效测试，它是经过测试来检测每个功效是否全部能正常

4、使用。在测试中，把程序看作一个不能打开黑盒子，在完全不考虑程序内部结构和内部特征情况下，在程序接口进行测试，它只检验程序功效是否根据需求要求正常使用，程序是否能合适地接收输入数据而产生正确输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，关键针对软件界面和软件功效进行测试。黑盒测试是以用户角度，从输入数据和输出数据对应关系出发进行测试。3职责角色名称相关关键责任测试主管组建测试小组协调测试小组内外部沟通组织编制测试纲领（含测试用例）和计划组织测试准入检验测试过程中进度控制、风险管理测试过程汇报编写测试汇报召集测试评审测试人员识别测试需求参与编制测试纲领（含测试用例）和计划帮助测试准入检

5、验实施测试用例，测试结果统计测试缺点统计和跟踪帮助测试评审支持人员为测试工作提供技术支持，比如环境安装、版本布署、测试工具支持等备注：该角色可选，可依据项目实际情况设置，通常情况下由研发人员担任。【注】：当某个项目仅有一个测试人员时，该测试人员同时也为该项目内测试主管，需要担负起测试主管职责。4测试类型和测试方法测试类型测试工作通常分为4个类型，功效测试、联合测试、性能测试及稳定性测试。测试类型测试意义功效测试确保功效符合需求定义确保全部功效能够正常完成工作联合测试一个新产品或一个产品新版本公布时，要确保和之相配合产品能够正常配合使用性能测试在产品有性能要求部分，进行性能测试和调优，确保产品性

6、能符合需求稳定性测试模拟用户真正使用情况，设计对应测试用例，确保产品能够稳定可靠长时间运行测试方法测试类型测试方法功效测试/联合测试以手工黑盒测试为主，手工实施功效测试用例。正规测试和随机测试相结合：依据需求文档撰写测试方案及测试用例来进行常规测试，考虑到测试用例有可能写不全方面，所以在进行常规测试过程中，能够加入随机测试。同时，对估计试出来缺点，将其实施过程写成一个测试用例，添加到测试用例集合中，以完善测试用例；采取测试工具TD进行测试用例管理和缺点统计、跟踪。性能测试性能测试要求满足两种情况：1）产品在特定工况下能够达成最高性能（比如：测试时将日志等影响性能选项关闭）；2）模拟用户真正使用

7、环境（如：日志功效打开，在一定用户数量情况下），产品真实能够达成性能；稳定性测试稳定性测试要求模拟用户真正使用情况，设计对应测试用例，确保产品能够稳定可靠长时间运行【注】：黑盒测试过程参考准则：（1）必需采取边界值分析法；（2）必需时采取等价类划分法补充测试用例；（3）采取错误判定法，追加测试用例；（4）对照程序逻辑，检验已设计出测试用例逻辑覆盖程度。假如没有达成要求覆盖标准，应该补充更多测试用例；（5）测试数据应准备充足，应采取有效数据、无效数据、边界数据分别测试验证；5工作步骤、模式及规范测试提交文件及裁剪说明阶段提交文件必需提交模板定义裁剪条件说明测试需求测试需求分析汇报否项目组自定义无

8、特殊需求，可省略测试计划测试纲领是项目组自定义各项目组依据测试任务规模可自定义模板测试计划否项目组自定义假如测试纲领或设计开发计划中已包含了测试计划内容，则本文档可省略测试纲领计划评审统计否企业模板各项目酌情选择测试用例是企业模板采取企业统一测试用例模板测试用例评审统计否企业模板各项目酌情选择测试实施测试准入检验表否企业模板各项目酌情选择测试统计是项目组自定义各项目组依据测试任务规模可自定义模板测试收尾测试汇报是企业模板采取企业统一测试汇报模板测试汇报评审统计否企业模板各项目酌情选择测试工作改善汇报否项目组自定义各项目酌情选择测试结果提交否项目组自定义各项目酌情选择评审点评审点定义参考设计开发

9、控制程序。灵敏测试模式灵敏测试概念灵敏测试即是不停修正质量指标，正确建立测试策略，确定用户有效需求得以圆满实现和确保整个生产过程安全、立即公布最终产品。灵敏增量测试方法测试是灵敏开发过程关键步骤，自始自终测试贯穿于每个迭代。整个产品灵敏开发生命周期能够分为 4 个阶段，即初始阶段，项目标建设阶段，产品公布阶段和产品维护阶段，在关键项目建设阶段中，测试被分成两个部分，验证测试和系统测试。验证测试：静态测试和关键功效测试。系统测试：功效测试、联合测试、性能测试、稳定性测试。灵敏测试步骤灵敏测试步骤依据业务场景制订测试策略。在每次灵敏测试过程中包含验证测试和联合测试。而且不停进行迭代测试。在系统全部

10、业务场景全部经过灵敏测试过后，进入系统测试阶段。进行全部业务场景功效测试、联合测试、性能测试、稳定性测试。依据业务场景制订测试策略步骤图产品业务场景一业务场景二。业务场景N模块一模块二模块三三。模块N模块四三业务场景一缺点管理缺点管理业务场景三TR5业务场景二TR5业务场景NTR5业务场景四TR5灵敏测试步骤图测试传输项汇报灵敏测试测试总结测试经过进入下一次灵敏迭代测试计划提交测试N Y Y N 满足准入条件系统测试条件Y 软件测试总结软件评定满足公布条件产品公布测试案例维护系统测试和回归测试测试是否经过Y Y 依据缺点性质来判定更新提交测试依据：1）严重等级为Urgent和High修改后立即

11、更新，要确保更新后不能影响其它功效测试。2）功效等级为Medium以下能够等候下一次提交灵敏测试时候更新。传统瀑布模式测试需求分析过程关键点具体说明开启条件需求阶段工作开启工作内容由测试主管依据项目任务复杂程度组织或指定测试人员进行测试需求分析，从用户角度考虑软件测试需要达成验证状态，并确定是否要形成测试需求分析汇报结束条件需求分析完成例外对于简单设计更改、衍生产品等只需例行测试，可不进行测试需求分析责任人项目经理参与人测试主管成立测试小组或确定测试人员过程关键点具体说明开启条件测试任务明确，前期工作开启工作内容确定项目标测试人员，若整个项目标测试需要若干个测试人员，则需要成立一个测试小组；为

12、测试小组任命一名测试主管，若只有一个测试人员，则该测试人员同时也为该测试组测试主管，同时确定测试小组其它组成人选；小组内进行必需培训。结束条件测试小组成立例外若以前测试任务已成立过测试小组，则能够复用以前组织人员和形式责任人项目经理参与人测试主管编制测试计划过程关键点具体说明开启条件项目阶段性计划确定需求规格说明书、具体设计说明书等已评审工作内容测试纲领最少包含以下关键内容：测试目标对此次测试要求和要达成目标测试范围需要测试小组测试范围，和各个测试需求测试优先级工作分工明确测试小组内部及外部配合方相关责任和工作关系测试策略整体测试总体测试策略、环境、方法和工具等完成标准达成何种条件能够认为测试

13、完成交付文件测试完成时应提交文件，比如测试纲领（含测试用例）、测试汇报等等测试计划最少应包含以下关键内容：关键任务每项任务时间计划、前置条件及资源关键里程碑关键任务及完成时间点在项目研发过程中，要适时对测试计划进行跟踪，以评定此计划完整性、可行性，在项目结束时还要最终评定一下测试计划质量结束标准测试计划评审经过或得到相关各方审批输出文件测试计划、测试计划评审统计例外对于多个系统参与同一个测试任务，可由主项目组或牵头方统一编制测试纲领和计划，不用每个系统单独编制和出具测试计划能够在测试纲领中直接具体列明，而不用单独编制责任人测试主管参与人研发总监、项目经理、测试人员编制测试纲领、设计测试用例在技

14、术规格书评审经过以后，测试小组需要针对项目标测试范围编制测试纲领、设计测试用例。在实际测试过程中，测试用例可依据实际需要进行更新和调整。在测试用例设计过程中，具体任务和责任人以下：过程关键点具体说明开启条件此次测试范围、业务需求已经明确需求规格说明是、具体设计说明书已经过评审工作内容准备此次测试测试用例测试用例在该产品测试用例库中进行选择，如有需要，能够进行增加；每个测试用例须包含用例编号、测试概述、测试数据、操作步骤说明、预期结果等要素；测试用例须覆盖全部测试需求和功效点；采取统一模板进行用例设计。结束标准测试用例覆盖全部待测试需求或功效点，而且评审经过输出文件测试纲领、测试用例、测试纲领评

15、审统计责任人测试人员参与人研发总监、研发人员、项目经理、测试主管测试实施阶段测试准入检验过程关键点具体描述开启条件测试实施准备工作完成工作内容测试主管依据本项目标特点，事先确定测试准入标准中哪些条目能够进行裁剪，并和项目经理及研发人员商讨确定准入标准中“计划准入标准”是指编制测试计划、测试纲领、测试用例设计时就需要含有前提条件，应提前进行检验；“实施准入标准”是指在实施测试之前需要进行检验。以上两类检验应分两次进行测试主管和测试人员依据测试准入标准，逐项进行检验，并填写测试准入检验表对于不满足条件检验项，要求相关方面进行处理，处理后重新进行检验必需要经过检验项，而没检验经过，视为准入检验不经过

16、，不能进入下一阶段工作结束条件测试准入检验经过输出文件测试准入检验表责任人测试主管参与人测试人员、项目经理、研发人员实施测试用例过程关键点具体描述开启条件测试实施阶段准入检验经过工作内容测试人员依据计划，实施对应测试用例，并做好测试统计测试人员进行缺点登记，并跟踪处理情况，立即复测，关闭缺点测试主管跟踪测试用例实施情况，了解影响测试用例实施原因，立即跟进相关协调、汇报测试状态测试主管依据项目标情况，选择相关汇报形式，将测试进展情况立即通报给相关各方结束条件测试用例实施完成责任人测试人员、测试主管参与人研发人员、项目经理回归测试在每轮测试结束以后，当研发人员处理完相关问题，重新提交，进行回归测试

17、。过程关键点具体描述开启条件在每轮测试中，按现有测试用例没有新缺点被发觉，测试汇报中全部活动缺点全部被处理工作内容测试组将根据测试计划中对于回归测试策略对产品进行回归测试，回归测试用例属于测试用例一部分或是全部测试用例，但不能超出原先预定测试用例范围结束条件回归测试所运行用例全部经过责任人测试人员参与人研发人员、项目经理缺点管理过程关键点具体描述开启条件测试用例开始实施工作内容测试人员在测试过程中，统计被测产品缺点，跟踪缺点分析、处理过程研发人员立即分析处理缺点，并按要求统计缺点分析处理信息，更新缺点状态，填制缺点起源；对需要其它人员参与分析处理时候，需立即将缺点分配给下一步骤人员测试人员对待

18、验证缺点需立即进行复测，测试经过后关闭缺点结束条件测试用例实施完成，而且缺点跟踪完成责任人测试人员、研发人员、测试主管参与人项目经理测试收尾阶段测试实施阶段结束或立即结束时，测试小组能够开始着手准备进行总结汇报及收尾工作。编制测试汇报在测试实施完成以后，测试主管或测试人员需依据实施测试情况，编制测试汇报。过程关键点具体描述开启条件测试小组完成了全部测试实施工作或测试时间已结束工作内容测试主管或测试人员依据测试结果，根据测试汇报文档模板编写测试汇报，测试汇报必需包含以下关键内容：测试用例实施情况分析 测试阶段用例实施数量、轮次、经过率等测试过程中已发觉缺点分析分析缺点数量、分布、起源等未实施用例

19、风险分析分析未实施用例对系统形成风险未关闭缺点风险分析分析未关闭缺点对系统形成风险测试结论评价测试纲领中定义测试完成标准是否达成，被测系统质量评价，存在风险，和相关提议结束条件测试汇报评审经过，发送给相关人员输出文件测试汇报、测试汇报评审统计责任人测试主管、测试人员参与人研发总监、研发人员、项目经理测试工作过程改善测试过程改善在测试实施阶段工作全部结束以后进行。它目标是评定此次测试工作，总结经验，使下一次工作做得愈加好。本项工作不是一个必需过程，各项目可依据情况采取。 过程关键点具体描述开启条件测试实施阶段结束工作内容测试主管召集测试参与人员，讨论此次测试过程得和失，总结经验，提出改善方法和意

20、见编写测试工作过程改善汇报结束条件测试工作过程改善汇报编制完成输出文件测试工作改善汇报责任人测试主管参与人测试人员测试结果提交 测试资产提交在测试实施阶段工作结束以后进行，对测试过程中包含到多种标准文档进行归类，存档。过程关键点具体描述开启条件测试实施阶段结束工作内容提交此次测试过程产生，能为其它项目或本项目后续测试提供借鉴，测试用例等结束条件全部结果归档完成输出文件测试结果清单例外假如结果内容不多，结构清楚，则能够省略测试结果清单责任人测试主管参与人测试人员软件测试实施模式现在采取3+1模式。即三轮系统测试加一轮回归测试。6缺点管理机制缺点经过测试管理工具TD进行管理测试团体 研发团体提交缺

21、点缺点分析缺点修复复测缺点是否修复关闭缺点测试人员提交缺点到TD，提交缺点状态为open，并制订严重等级研发部门对测试人员提出缺点进行分析，确定是否对缺点进行修改修改后将缺点置为fixed，不进行修复或不是缺点问题应该修改缺点状态。测试人员在新一轮测试时复测研发修复缺点测试过程中发觉修复缺点仍然存在问题，缺点状态置为reopen，重新提交至研发部门。测试验证后不出现问题缺点，即可关闭。缺点严重等级和怎样分类严重等级描述5-Urgent阻碍步骤、系统瓦解造成重大任务不能正常进行缺点，比如：1、因为程序所引发死机，非法退出。2、死循环4-High1、数据库发生死锁2、错误操作造成程序中止3、严重计

22、算错误4、和数据库连接错误5、数据通讯错误等3-Medium缺点造成失去系统关键功效，基础功效不能完整使用。比如：1、功效不符2、程序接口错误3、数据流错误4、轻微数据计算错误等2-Low操作性错误、错误结果、遗漏功效等影响系统要求或基础功效实现。比如：1、界面错误2、打印内容、格式错误3、简单输入限制未放在前台进行控制4、删除操作未给出提醒5、数据输入没有边界值限定或不合理6、错别字等1-suggest提议，不影响使用瑕疵或愈加好实现等。7新产品测试步骤新产品测试输入输出测试步骤输入输出测试准备需求分析阶段产品需求分析文档评审结果软件开发设计阶段概要设计阶段具体设计阶段评审结果测试方案和测试

23、计划软件测试设计阶段概要设计具体设计测试方案和测试计划测试案例测试环境准备概要设计具体设计测试方案和测试计划测试环境清单测试环境准备完成测试实施冒烟测试测试项传输汇报冒烟测试结果系统测试和回归阶段测试方案和测试计划测试案例测试项传输汇报测试日志轮次总结测试汇报测试分析和维护软件测试总结系统测试总结汇报软件评定系统测试总结汇报评定结果软件测试维护测试案例修改新产品测试步骤图需求调研阶段需求规格说明书概要设计具体设计测试方案和测试计划测试案例编写评审结果评审结果单元测试和集成测试测试结果提交测试经过冒烟测试和送测清单系统测试和回归测试测试是否经过软件测试总结软件评定满足需求产品公布测试案例维护走新

24、增或修改需求步骤Y N N N Y Y N Y N N N Y Y 8生产缺点测试步骤生产缺点测试输入和输出测试阶段输入输出测试准备阶段生产缺点描述和处理措施测试方案和测试计划简报测试实施阶段测试项传输汇报测试总结简报软件评定测试总结简报评定结果测试案例维护测试案例修改生产缺点测试步骤图 生产缺点调研生产缺点描述和处理措施准入条件生产缺点测试软件评定是否满足用户要求测试总结简报测试是否经过测试结束提交测试Y N N Y Y 9新增和修改需求测试步骤新增和修改需求测试输入和输出测试阶段输入输出测试准备阶段新增和修改需求调研新增和修改需求概要设计和具体设计测试方案和测试计划测试实施阶段测试项传输汇

25、报测试总结汇报软件评定测试总结汇报评定结果测试案例维护测试案例修改新增和修改需求测试步骤图新增和修改需求调研概要和具体设计是否满足准入条件系统测试和回归测试 软件评定是否满足用户要求测试总结汇报测试是否经过测试结束测试方案和测试计划提交测试N Y Y N Y N 10公布评定标准检验合格依据:遗留问题中不能有Urgent、High等级问题； 遗留问题中Medium等级问题数要小于等于8，而且经过研发、测试及产品经理讨论一致同意。软件达成设计性能指标。软件稳定性测试经过，没有不稳定现象。联合测试经过，无Bug。满足以上五点，视为产品检验合格。假如产品不满足上述五点，但还需要公布，则应该取得软件总监同意。11问题处理如研发团体对测试结论有争议，应经过评审处理。12相关文件设计开发控制程序设计更改控制程序研发评审要求研发测试要求13相关统计 测试计划测试纲领测试用例测试统计测试汇报缺点跟踪汇报评审统计评审汇报文件修订信息页编号章节名称修订内容简述修订日期订前版本订后版本拟制审核同意12345678910111213141516