编写目的（此文非原创，只是忘了当初是谁写的了~）
主要明确测试团队在整个项目各阶段中的职责，并对测试团队的组织架构、职能划分进行说明，对日后各部门间配合及组内工作的正常开展起到规范的指导作用。（注：该文档在测试流程及规范部分主要针对测试团队来撰写，其他团队的职责仅略微描述。）
各角色职责
⦁ 测试经理
1）负责团队内部管理工作，各部门间协调工作；协助团队内部解决测试技术问题；
2）根据每次即将上线的版本内容制定测试范围、分配测试任务；
3）制定测试方案并推进实施加以改进，改善产品体验；
4）制定质量管理体系标准，严格保证并管控产品质量；
5）打造高效的测试团队，培养人才梯队，制订团队发展计划与培训机制，不断学习新技术；
6）优秀的执行力，面对挑战，能快速决策分析，调动资源集中突破；
7）负责测试人员招聘、组织架构划分、人员的绩效考核等。
⦁ 测试接口人
1）根据测试经理指派的任务，根据各组别职能协调小组内成员共同完成测试任务；
2）编写测试用例、测试计划、测试方案、测试报告并能指导测试工程师完成工作；
3）与产品、研发、运维团队进行有效的沟通，并负责组织测试用例评审工作；
4）验收各阶段测试工作，保质、保量、按时完成小组内的测试任务；
5）负责小组内的团队建设，探索并提升组内所需新技术，提高组内技术实力等。
测试开发工程师
⦁ 根据项目组需要，能够独立完成测试框架开发工作及所需工具；
⦁ 熟悉mock测试工具，完成mock测试开发；
⦁ 精通web端及客户端APP的自动化测试工具，如selenium、monkeyrunner等，能够熟练使用其做自动化测试；
⦁ 掌握持续交付理念、快速接受持续交付中自动化测试部分；
⦁ 掌握全业务流程，可以分析并提取出业务框架并实施开发；
⦁ 指导其他自动化测试人员，并通过组内培训分享自动化测试理念及方法，提升组内技术水平等。
性能自动化测试工程师
⦁ 有扎实的功能测试基础，能够根据独立编写性能测试方案及性能测试报告；
⦁ 熟练掌握LoadRunner、Jmeter等工具的使用及原理；
⦁ 与客户一起制定并分析性能指标、编写性能测试方案、定位性能瓶颈并找出解决方案；
⦁ 掌握linux命令、Sqlserver、Qracle、Mysql等数据库
⦁ 熟悉Apache、windows及linux平台；
⦁ 编写性能测试脚本并调试。
功能测试工程师
⦁ 服从上级安排，并通过指导能够胜任测试任务；
⦁ 参与需求评审，并对产品需求提出各方面建议及意见；
⦁ 按照需求文档设计测试用例、编写测试用例并严格按照测试计划及用例执行；
⦁ 参与用例内部评审及外部评审；
⦁ 按规定格式提交有效的软件bug，并对软件bug周期进行跟踪处理。
⦁ 测试流程及规范
⦁ 测试流程
1)计划与设计阶段
2)实施阶段
3)测试总结阶段
⦁ 计划与设计阶段
⦁ 项目立项
⦁ 项目立项主要是阐述项目背景、内容及意义，确定项目相关负责人、评估项目预算等；
⦁ 测试参与人员：测试经理；
⦁ 其他部门参与人员：研发总监、产品总监、产品经理等与项目相关的领导、高层。
⦁ 需求评审
⦁ 产品部门组织召开需求评审会议，以产品需求文档、原型设计、UI为输出条件；
⦁ 会议内容：测试团队对需求文档存在异议/需求不完整/不清晰的地方提出问题，相关人员进行解答；
⦁ 会议结束的标准：所有人员达成一致，对需求无异议，需求确定；
⦁ 测试参与人员：测试经理、模块测试负责人；
⦁ 其他部门参与人员：研发总监、模块研发负责人、产品总监、产品经理、UI设计等；
注：
⦁ 需求评审会议召开之前，产品需将产品需求文档、原型及UI设计图提前发给各个团队，以便测试团队预留出熟悉及理解需求的时间；
⦁ 测试团队参与人员由测试经理指定，包含测试模块负责人、测试设计人员、质量保证人员等。
⦁ 测试计划
⦁ 制定依据：需求文档、原型设计、UI设计、研发计划、概要设计及详细设计文档；
⦁ 内容：包含测试范围、测试环境、测试方法及策略、资源分配及进度安排、风险预估等；
⦁ 评审：研发、测试人员需对测试计划初稿进行评审，确认测试的侧重点。
⦁ 评审目的：确保测试计划的正确性、全面性、可行性。评审后完善测试计划，并形成终稿；
⦁ 测试参与人员：测试全体参加。
⦁ 用例设计
⦁ 设计依据：需求文档、原型设计、UI设计、研发概要设计及详细设计文档；
⦁ 测试用例设计
1）需求测试分析、分解需求功能模块、提取测试点后，根据以上文档采用边界值、等价类划分等方法设计测试用例 ；
2）包含测试用例的要素：
首页签：测试用例目录及链接、用例修订日期及修正模块等信息说明；上半部分：项目名称、版本号、编写人、编写时间、功能模块要点、联调测试要点（涉及哪些客户端的交互联调测试）；下半部分：用例ID、优先级、功能模块、用例名称、前置条件、输入数据、操作步骤、预期结果、实际结果、备注（关注点、bug号等信息）；
⦁ 测试参与人员：模块负责人、用例设计人员及用例执行人员。
⦁ 用例评审
⦁ 用例评审及标准：确保测试用例的全面性、需求覆盖率达到100%；
⦁ 测试参与人员：测试经理、模块负责人、用例设计人员及用例执行人员。
⦁ 测试实施阶段
⦁ 测试准备
⦁ 测试环境的准备：硬件环境、软件环境、网络环境、历史数据环境；可靠且可控的测试环境有利于bug重现、减少环境的变动对测试工作带来的不利影响；
⦁ 测试文档准备：产品需求文档、原型图、UI设计图、测试计划、测试方案、测试用例；
⦁ 测试数据准备：老数据与新数据的准备（数据迁移）、带有历史数据记录的数据（与程序判断有关）、与测试方法及策略有关的数据准备（安全测试、）；
⦁ 测试人员准备：根据测试方法及策略分配测试人员，合理安排进度。
⦁ 单元测试
⦁ 研发在编写代码后需进行单元测试且达到一定的覆盖率标准，才可交付给测试人员。
⦁ 冒烟测试
⦁ 单元测试后交付测试，测试人员进行冒烟测试，确保后续正式的测试工作可顺利进展；
⦁ 冒烟测试通过标准：实现所有主要功能，且无一级、二级bug，三级bug可根据产品迭代情况适当制定相应标准；
⦁ 冒烟测试用例：确定主要模块的主要功能，根据需求文档提取测试用例功能点并编写；
⦁ 冒烟测试执行人员：模块测试负责人员。
⦁ 功能细则测试
⦁ 业务功能细则测试：当冒烟测试通过后，进入正式功能测试；
⦁ 功能测试通过标准：需求覆盖度达到100%，且测试用例的粒度达到单个细小模块的校验，所有用例被严格执行且fix掉所有bug（或最终上线前产品、研发及测试评估优先级为三、四级bug是否全部fix）；
⦁ 功能测试执行：模块测试负责人员。
⦁ 集成测试
⦁ 集成测试是在单元测试基础上，对多模块组装联合起来的接口进行测试；
⦁ 集成测试细则：考虑各模块连接起来时，穿越接口的数据是否丢失、一个模块的功能是否影响另外一个模块的功能、子模块组装后是否满足父功能等；
⦁ 集成测试通过标准：所有集成测试用例被严格执行，且满足集成测试接口上的需求；
⦁ 集成测试执行人员：模块测试负责人员。
⦁ 系统测试
⦁ 系统测试是在集成测试基础上进行的测试，依赖于产品需求说明书中已经确定好的系统外设、硬件、网络等组成因素；
⦁ 系统测试分类：恢复性测试、安全性测试、压力测试等；
⦁ 系统测试通过标准：所有系统测试用例被严格执行，且满足产品需求及设计说明书；
⦁ 系统测试执行人员：模块测试负责人员。
⦁ 验收测试
⦁ 验收测试是软件正式上线前的最后一步测试；
⦁ 验收测试分类：正式测试、非正式测试（Alpha 测试）、Beta 测试；正式测试由测试人员与用户共同组成小组或完全由用户来组织验收测试；非正式测试多数由最终用户执行；Beta测试
⦁ 验收测试通过标准：产品最终需满足需求设计说明书的内容及对硬件、软件相关的规定；最终的体验以及功能、性能等方面用户可接受；无一级、二级bug（三级bug接受程度由用户或产品方与我们共同评估）；
⦁ 验收测试执行人员：测试人员、研发人员、产品、最终用户。
⦁ 回归测试
⦁ 需注意：回归测试贯穿于整个开发周期的各个阶段；
⦁ 修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的；
⦁ 回归策略：用例库维护、自动化脚本回归、手工测试辅助回归；
⦁ 在组织回归测试时需要注意两点，首先是各测试阶段发生的修改一定要在本测试阶段内完成回归，以免将错误遗留到下一测试阶段。其次，回归测试期间应对该软件版本冻结，将回归测试发现的问题集中修改，集中回归；
⦁ 回归测试执行人员：测试全体
注意：以上事实流程仅限于有足够的测试时间方可全方位实施，根据敏捷迭代的特性，在实施的各阶段需因环境变化而制定临时测试实施策略。具体详见敏捷迭代过程中各阶段的测试策略及计划报告。
⦁ 测试总结阶段
⦁ 测试报告
⦁ 把测试的过程和结果写成文档，对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础；
⦁ 测试报告内容要素：测试范围、测试方法、测试工具、测试环境、测试结果与缺陷统计与分析、测试结论与建议等；
⦁ 每个测试阶段或上线前用例及各环节执行完毕后都需要提供测试报告；
⦁ 测试报告撰写人：负责各阶段的测试人
⦁ 上线前review
⦁ 上线前产品、研发、测试共同review上线前需求完成度、用例覆盖度是否满足本次上线的要求，以及存在哪些风险点；
⦁ 上线前的标准是所有覆盖需求的用例执行达到100%，且无严重等级的bug挂起；
⦁ 上线前review执行人员：测试经理携测试全体
⦁ 测试归档
⦁ 测试归档是在测试验收结束宣布测试有效，结束测试后，对测试过程中涉及到各种标准文档进行归类，存档；
⦁ 涉及的文档：测试计划、测试用例、测试阶段性报告、测试总结报告；产品迭代需求说明、设计文档等，最好归类为一次版本上线的文件夹，日后有可追溯性；
⦁ 测试归档执行人员：测试组长/负责人。
⦁ 上线后总结
⦁ 上线后测试组内需对上线成功或经过一段时间线上反馈的问题做出总结；
⦁ 总结内容：对整个研发过程改进的建议、提高测试效率的方法、若出现问题需追溯出根本原因、测试过程出现问题的改进方法、对测试过程中好的一面予以肯定并继续推行等；
⦁ 上线后总结执行人员：测试组长携全体测试人员。
⦁ 缺陷跟踪
⦁ 测试过程中的缺陷跟踪及处理
⦁ Bug处理流程图
⦁ Bug严重等级定义
⦁ 一级: 系统“挂起”或“崩溃”的错误，使得整个测试工作无法继续进行，如：程序死机、死循环、非法退出、数据库死锁、程序无法登录等；
⦁ 二级: 软件功能未按产品需求文档规定的实现，导致功能报错，其他模块测试工作无法进行，如：功能不符、接口错误等；
⦁ 三级: 一般性错误：如界面UI不符/错误、错误未给出弹出框提示等；
⦁ 四级: 轻微bug，如：格式排版、个别文字错误等问题；
⦁ 五级：对软件的改进建议，如：需求说明中未明确但影响用户体验等；
⦁ Bug优先级定义
⦁ Priority 1—严重bug，需立即修复；
⦁ Priority 2—比较严重的bug，根据模块关联性依次修复；
⦁ Priority 3—一般性bug，可在优先级为1和2之后修复；
⦁ Priority 4—轻微性bug，经讨论后可决定是否在下一版修复；
⦁ Priority 5—针对软件改进建议可以修复或不修复，由产品最终决定；
注：Bug严重等级与Bug优先级一一对应，特殊情况可调整映射关系。
⦁ Bug提交规范
Bug提交所含内容如下：
⦁ Bug标题：环境-端名称-模块名称-简要概述Bug；
⦁ 模块路径：首先选择项目端名，其次选择版本号，如图：
⦁ 指派给：输入研发人员名字全拼或名字首字母，下拉框中会显示出研发人员的名字；
⦁ 抄送给：输入抄送人员名字全拼或名字首字母，下拉框中会显示出研发人员的名字，可按需要抄送给相关人；
⦁ 严重程度：Bug严重等级定义；
⦁ 优先级：Bug优先级定义；
⦁ Bug类型：根据Bug定位原因，并选择适当的类型，详见bugfree类型；
⦁ 如何发现：详细阐述bug发现的阶段；
⦁ 操作系统：详细描述操作系统；
⦁ 终端设备：指定某个终端，方便问题重现，准确定位；
⦁ 发现版本号：填写详细版本号；
⦁ 运行环境：阐述bug发现的运行环境；
⦁ 处理状态：bug当前状态；
⦁ 机器配置：描述机器配置；
⦁ 关键词：方便搜索；
⦁ Bug相关：相关联的bug与case；
⦁ 附件：可上传bug截图附件；
⦁ 复现步骤：分为前置条件、复现步骤、预期结果、实际结果、备注（账号密码等相关信息）。
⦁ 市场反馈的Bug跟踪及处理
⦁ Bug处理流程图
详见售后流程图
⦁ 软件发布标准
软件发布需满足以下标准
⦁ 完成发布计划中所有的工作；
⦁ 实现需求定义中所有功能特性；
⦁ 完成所有的测试工作（按测试计划严格执行）；
⦁ 严重缺陷都已修复；
⦁ Bug趋势图接近于零，新发现的缺陷；
⦁ 出具完整且权威的测试报告
⦁ 已达到验收标准
软件产品未经测试合格，有严重bug时，不允许发布。
⦁ 争议处理
若针对同一问题研发、测试团队对结论有争议，需项目组成员及产品共同讨论，项目经理给出最终结果，并衡定是否上线。