主要明确测试团队在整个项目各阶段中的职责，并对测试团队的组织架构、职能划分进行说明，对日后各部门
间配合及组内工作的正常开展起到规范的指导作用。（注：该文档在测试流程及规范部分主要针对测试团队来
撰写，其他团队的职责仅略微描述。）
各角色职责
⦁ 测试经理
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接受程度由用户或产品方与我们共同评估）；
⦁ 验收测试执行人员：测试人员、研发人员、产品、最终用户。
⦁ 回归测试
⦁ 需注意：回归测试贯穿于整个开发周期的各个阶段；
⦁ 修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试
将大幅降低系统测试、维护升级等阶段的成本。回归测试作为软件生命周期的一个组成部分，在整个软件测
试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，
新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。
因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的；
⦁ 回归策略：用例库维护、自动化脚本回归、手工测试辅助回归；
⦁ 在组织回归测试时需要注意两点，首先是各测试阶段发生的修改一定要在本测试阶段内完成回归，以
免将错误遗留到下一测试阶段。其次，回归测试期间应对该软件版本冻结，将回归测试发现的问题集中修
改，集中回归；
⦁ 回归测试执行人员：测试全体
