2022年测试流程规范.pdf

XXXX 测试流程规范文件状态 草稿 正式发布 正在修改当前版本拟 制刘刚日期2017-07-03审 核日期批 准日期XXXX国际电子商务有限公司2017 年 7 月精品资料 - - - 欢迎下载 - - - - - - - - - - - 欢迎下载 名师归纳 - - - - - - - - - -第 1 页，共 13 页 - - - - - - - - - - 修订历史记录A - 增加M - 修订D - 删除变更版本号日期变更类型（A*M*D ）修改人摘要备注2017-07-03A刘刚建立初始稿精品资料 - - - 欢迎下载 - - - - - - - - - - - 欢迎下载 名师归纳 - - - - - - - - - -第 2 页，共 13 页 - - - - - - - - - - 目录1 概述 . 错误 !未定义书签。介绍 . . 错误 !未定义书签。适用范围 . . 错误 !未定义书签。定义、缩写词和缩略语. . 错误 !未定义书签。2 流程规范 . . 错误 !未定义书签。需求阶段 . . 错误 !未定义书签。流程图 . . 错误 !未定义书签。流程说明 . . 错误 !未定义书签。测试输入及输出产物. . 错误 !未定义书签。研发阶段 . . 错误 !未定义书签。流程图 . . 错误 !未定义书签。流程说明 . . 错误 !未定义书签。测试输入及输出产物. . 错误 !未定义书签。测试阶段 . . 错误 !未定义书签。流程图 . . 错误 !未定义书签。流程说明 . . 错误 !未定义书签。测试输入及输出产物. . 错误 !未定义书签。上线阶段 . . 错误 !未定义书签。流程图 . . 错误 !未定义书签。流程说明 . . 错误 !未定义书签。测试输入及输出产物. . 错误 !未定义书签。自动化测试阶段. . 错误 !未定义书签。流程图 . . 错误 !未定义书签。流程说明 . . 错误 !未定义书签。测试输入及输出产物. . 错误 !未定义书签。3 测试文档管理规范. . 错误 !未定义书签。测试文档范围. . 错误 !未定义书签。测试文档归档要求. . 错误 !未定义书签。4 补充 . 错误 !未定义书签。精品资料 - - - 欢迎下载 - - - - - - - - - - - 欢迎下载 名师归纳 - - - - - - - - - -第 3 页，共 13 页 - - - - - - - - - - 1 概述1.1介绍XXXX 测试流程规范主要用于规范各类测试工作，指导各类测试工作有序规范进行，从流程上避免测试的随意性，更好的保证测试质量。流程规范非一次性能制定出最优的，需要经历实践的锤炼， 在实际工作中不断进行优化，才可逐步形成最优的测试流程方案。1.2适用范围本文档适用于 XXXX 测试小组进行各类测试工作时用于工作流程规范指导。各阶段的测试工作需要参考该规范进行，除特殊情况外， 各类测试工作原则上要遵照该规范进行。1.3定义、缩写词和缩略语定义、缩写词和缩略语描述自动化测试自动化测试是通过自动执行测试脚本，使测试人员在更短的时间内能够更快地完成更多的软件测试，并提供以更高的频率执行测试的能力，从而有效降低测试成本、提高测试效率。测试方案重新定义方案，猎鹰工品所用方案包括：测试计划、方案、测试需求、测试点。归整到一个文档，方便管理。测试报告测试报告分为多种：功能测试报告、接口测试报告、性能测试报告、安全测试报告等精品资料 - - - 欢迎下载 - - - - - - - - - - - 欢迎下载 名师归纳 - - - - - - - - - -第 4 页，共 13 页 - - - - - - - - - - 2 流程规范2.1需求阶段2.1.1流程图产品需求阶段测试人员产品人员产品需求召开需求评审会学习、熟悉产品需求+参加需求评审会+组内培训等参与评审会制定测试方案（含计划 +测试需求+测试要点）初稿评审测试方案（含计划+测试需求 +测试要点）定稿否是2.1.2流程说明1、 项目启动后，负责该测试任务的测试负责人积极与产品人员沟通交流，熟悉本次产品需求。2、 在有需求评审会时，测试负责人必须积极参与，无特殊情况不得缺席。3、 根据产品需求，测试负责人要提取测试需求，并不是简单照搬产品需求，要形成测试自己的测试list。4、 产品需求熟悉完毕后，必须编写出具测试方案，方案含测试计划、测试精品资料 - - - 欢迎下载 - - - - - - - - - - - 欢迎下载 名师归纳 - - - - - - - - - -第 5 页，共 13 页 - - - - - - - - - - 需求、测试要点等。5、 测试方案必须经过评审，原则需要产品人员、开发人员、其他测试人员共同参与，如无条件，至少经过测试组内评审。6、 测试方案评审通过后才可进入下一阶段。7、 需求变更优化，建议 通过禅道提需求 +邮件通知形式 进行，便于需求的追踪。8、 中间需求变动，测试方案跟进更新。2.1.3测试输入及输出产物测试输入：产品需求文档、 原型、UI 设计图、项目开发计划等其他相关可用于测试参考的文档。输出产物：测试方案（含测试计划 +测试需求 +测试要点） 精品资料 - - - 欢迎下载 - - - - - - - - - - - 欢迎下载 名师归纳 - - - - - - - - - -第 6 页，共 13 页 - - - - - - - - - - 2.2研发阶段2.2.1流程图研发阶段测试人员开发人员提测文档+提测邮件开发设计+编码实现编写测试用例评审测试用例否是单元测试单测通过单测未通过发布版本2.2.2流程说明1、 测试人员根据测试方案输出测试用例，要求测试用例必须覆盖测试需求。2、 在时间十分紧张或需求十分不具体的情况下，用例编写可推迟到测试中后期补充，用例评审可延后评审。3、 用例评审原则上需要产品人员、开发人员、其他测试人员共同参与，如无条件，至少经过测试组内评审。4、 本阶段可与后续的测试阶段交替进行，测试工作最早可从模块测试阶段介入，前提开发人员必须先完成单元测试，否则测试拒绝介入。精品资料 - - - 欢迎下载 - - - - - - - - - - - 欢迎下载 名师归纳 - - - - - - - - - -第 7 页，共 13 页 - - - - - - - - - - 2.2.3测试输入及输出产物测试输入：测试方案（含测试计划 +测试需求 +测试要点） 输出产物：提测文档、提测邮件、测试用例、提测版本2.3测试阶段2.3.1流程图测试阶段测试人员开发人员产品人员提测文档+提测邮件开发设计+编码实现获取版本tar，搭建测试环境环境确认否单元测试单测通过单测未通过发布版本提测文档+提测邮件修复bug单元测试单测通过单测未通过发布版本产品需求验证测试是否符合产品预期需求产品测试不通过初次发版，先提交产品测试产品测试通过执行测试冒烟测试通过冒烟不通过提交bug，进入缺陷流程Bug修复类提测可直接进入冒烟执行并维护测试用例探索测试交叉测试持续优化维护2.3.2流程说明1、 测试组负责部署测试环境，经开发、运维确认部署无误后，开始进行后续测试工作。2、 针对初次发版的功能模块要先经过产品人员的需求验证测试，验证测试通过后再交付测试人员进行后续测试工作。此举目的是避免测试人员做无用功，加快测试效率，提早发现需求类问题。3、 产品人员的需求验证测试可以提前到开发环境验证。测试环境部署后，测试人员直接进行冒烟测试加快测试进度。精品资料 - - - 欢迎下载 - - - - - - - - - - - 欢迎下载 名师归纳 - - - - - - - - - -第 8 页，共 13 页 - - - - - - - - - - 4、 执行测试阶段，时间条件允许下，强烈建议做三类测试：执行用例测试、探索测试、交叉测试。 时间紧张情况至少也要进行：执行用例测试和探索测试。5、 新部署的测试版本，先进行冒烟测试，冒烟不通过直接打回开发人员进行单元测试，通过后再重新提交测试。6、 测试用例要在执行过程中应持续优化维护，保证用例的全面性、正确性、规范性。最晚测试阶段后期必须完成用例维护并执行通过。7、 缺陷流程采用禅道管理，依据禅道流程进行。2.3.3测试输入及输出产物测试输入：测试方案（含测试计划 +测试需求 +测试要点） 、 测试用例、 提测文档+提测邮件、提测版本输出产物：测试用例、 测试缺陷精品资料 - - - 欢迎下载 - - - - - - - - - - - 欢迎下载 名师归纳 - - - - - - - - - -第 9 页，共 13 页 - - - - - - - - - - 2.4上线阶段2.4.1流程图上线阶段运维人员开发人员测试人员产品人员获取最终版本tar，部署生产环境环境确认否修复 bug单元测试单测通过单测未通过发布版本产品验收测试验收是否通过执行测试冒烟测试通过执行主要测试用例探索测试是测试报告 +完善用例版本回滚清理测试数据，正式上线测试是否通过发送测试通过邮件是否发送验收通过邮件，准许上线是否否重走测试阶段流程未通过否2.4.2流程说明1、 上线版本的部署由运维人员负责安装部署。2、 上线版本依次经过测试回归和产品验收后，出具测试通过和验收通过的邮件后才可正式上线。3、 上线版本在线上环境验证失败后， 如果发现是程序上有问题， 需要退回版本，重走测试阶段，配置上的问题可以依据具体情况可在线上修改再继续验收测试。4、 在上线阶段的测试，原则上无需执行全量测试用例，需要提前筛选主要用例进行回归测试，后续引入自动化后，部分用例可自动化执行，加快测试回归效率。精品资料 - - - 欢迎下载 - - - - - - - - - - - 欢迎下载 名师归纳 - - - - - - - - - -第 10 页，共 13 页 - - - - - - - - - - 2.4.3测试输入及输出产物测试输入：主要测试用例、上线版本输出产物：测试报告、 测试缺陷、 测试用例、上线邮件2.5自动化测试阶段2.5.1流程图自动化测试阶段测试人员输入制定自动化测试方案总体测试计划功能测试用例评估是否适合自动化结束否是评审编制测试脚本执行自动化测试缺陷管理流程维护测试脚本通过不通过发现 BUG需要维护脚本无需回归需要回归无需维护脚本自动化测试报告2.5.2流程说明1、 采用自动化前需要综合考虑项目自身情况是否适合采用自动化。不能强行采用自动化，避免得不偿失。2、 自动化测试成本 =测试工具成本 +测试脚本的创建成本+测试脚本的维护成精品资料 - - - 欢迎下载 - - - - - - - - - - - 欢迎下载 名师归纳 - - - - - - - - - -第 11 页，共 13 页 - - - - - - - - - - 本。3、 自动化适用于项目周期长、项目上线后需要不断升级维护、需求和设计都比较明确4、 自动化脚本要注意在测试过程中实时维护，保证脚本最新可用，并且脚本要注意规范留档，以备后面测试使用。2.5.3测试输入及输出产物测试输入：总体测试计划、功能测试用例输出产物：自动化测试报告、 测试缺陷、自动化测试脚本、自动化测试用例。3 测试文档管理规范精品资料 - - - 欢迎下载 - - - - - - - - - - - 欢迎下载 名师归纳 - - - - - - - - - -第 12 页，共 13 页 - - - - - - - - - - 3.1测试文档范围测试主要需要管理的文档类型如下：测试方案（含测试计划 +测试需求 +测试要点）、提测文档、测试用例、测试缺陷、提测版本、测试脚本、测试报告、需求类文档3.2测试文档归档要求所有测试文档在测试项目结束后，必须尽快汇总整理上传到“测试SVN ”对应项目目录下，以备后面查阅，测试组长负责审核，确保测试文档正确归档。归档目录参考如下：说明：1）测试脚本单独归档在“测试脚本”对应目录下，分为：UI 自动化脚本、接口自动化脚本、性能脚本。2）其它测试文档，放置在对应产品线目录下，新建一个以项目简称命名的文件夹来归档， 项目简称前注意标记项目开始时间，方便日后查阅。4 补充暂无精品资料 - - - 欢迎下载 - - - - - - - - - - - 欢迎下载 名师归纳 - - - - - - - - - -第 13 页，共 13 页 - - - - - - - - - -