一起聊聊小团队测试体系的创建与进行？（更新中）
------------------------------------------------------------完美发分隔符----------------------------------------------------
- 测试流程
- bug管理工具
- 部署发布流程
- 团队管理规则
- 沟通要素
- 团队提升
--- 2018.6.27更新---
1. 测试流程
分成4个阶段：
1、计划阶段（需求阶段）
2、设计阶段
3、执行阶段
4、总结阶段
--计划阶段--
项目立项
⦁ 项目立项主要是阐述项目背景、内容及意义，确定项目相关负责人、评估项目预算等；
⦁ 参与人员: 测试经理、研发总监、产品总监、产品经理等与项目相关的领导、高层。
需求评审
⦁ 产品部门组织召开需求评审会议，以产品需求文档、原型设计、UI为输出条件；主要内容是测试团队对需求文档存在异议/需求不完整/不清晰的地方提出问题，相关人员进行解答，所有人员达成一致，对需求无异议，需求确定；
⦁ 参与人员：测试经理、项目参与测试人员、研发总监、项目研发人员、产品总监、产品经理、UI设计、市场等；
注意： 需求评审会议召开之前，产品需将产品需求文档、原型及UI设计图提前发给各个团队，以便项目人员预留出熟悉及理解需求的时间；
测试计划
⦁ 包含测试范围、测试环境、测试方法及策略、资源分配及进度安排、风险预估等（测试计划模版后续更新）；
⦁ 评审：项目研发人员、项目测试人员需对测试计划初稿进行评审，确认测试的侧重点。评审后完善测试计划，并形成终稿；
---设计阶段---
用例设计
⦁ 设计依据：需求文档、原型设计、UI设计、研发概要设计及详细设计文档；
⦁ 测试用例设计
1）需求测试分析、分解需求功能模块、提取测试点后，根据以上文档采用边界值、等价类划分等方法设计
测试用例 ；
2）包含测试用例的要素：（测试用例模版后续专栏更新）
用例评审
⦁ 用例评审及标准：确保测试用例的全面性、需求覆盖率达到100%；
⦁ 参与人员：测试经理、模块负责人、用例设计人员及用例执行人员，也可邀请项目其他人员。
测试方案
---执行阶段---
测试准备
⦁ 测试环境的准备：硬件环境、软件环境、网络环境、历史数据环境；
⦁ 熟悉文档：产品需求文档、原型图、UI设计图、测试计划、测试方案、测试用例；
⦁ 测试数据准备：老数据与新数据的准备（数据迁移）、带有历史数据记录的数据（与程序判断有关）、
与测试方法及策略有关的数据准备（安全测试、）；
⦁ 测试人员准备：根据测试方法及策略分配测试人员，合理安排进度。
单元测试
⦁ 研发在编写代码后需进行单元测试且达到一定的覆盖率标准，才可交付给测试人员。
冒烟测试
⦁ 单元测试后交付测试，测试人员进行冒烟测试，确保后续正式的测试工作可顺利进展；
⦁ 冒烟测试通过标准：实现所有主要功能，且无一级、二级bug，三级bug可根据产品迭代情况适当制
定相应标准；
⦁ 冒烟测试用例：确定主要模块的主要功能，根据需求文档提取测试用例功能点并编写；
⦁ 冒烟测试执行人员：模块测试负责人员。
功能细则测试
⦁ 业务功能细则测试：当冒烟测试通过后，进入正式功能测试；
⦁ 功能测试通过标准：需求覆盖度达到100%，且测试用例的粒度达到单个细小模块的校验，所有用例
被严格执行且关闭所有bug（至少评估后需关闭的都要全部关闭）；
集成测试
⦁ 集成测试是在单元测试基础上，对多模块组装联合起来的接口进行测试；
⦁ 集成测试细则：考虑各模块连接起来时，穿越接口的数据是否丢失、一个模块的功能是否影响另外一个模块的功能、子模块组装后是否满足父功能等；
⦁ 集成测试通过标准：所有集成测试用例被严格执行，且满足集成测试接口上的需求；
系统测试
⦁ 系统测试是在集成测试基础上进行的测试，依赖于产品需求说明书中已经确定好的系统外设、硬件、网络等组成因素；
⦁ 系统测试分类：恢复性测试、安全性测试、压力测试等；
⦁ 系统测试通过标准：所有系统测试用例被严格执行，且满足产品需求及设计说明书；
验收测试
⦁ 验收测试是软件正式上线前的最后一步测试；
⦁ 正式测试由测试人员与用户共同组成小组或完全由用户来组织验收测试；非正式测试多数由最终用户执行；Beta测试
⦁ 验收测试通过标准：产品最终需满足需求设计说明书的内容及对硬件、软件相关的规定；最终的体验以
及功能、性能等方面用户可接受；无一级、二级bug（三级bug接受程度由用户或产品方与我们共同评估）；
⦁ 验收测试执行人员：测试人员、研发人员、产品、最终用户。
回归测试 (需注意：回归测试贯穿于整个开发周期的各个阶段)
⦁ 在组织回归测试时需要注意两点，首先是各测试阶段发生的修改一定要在本测试阶段内完成回归，以
免将错误遗留到下一测试阶段。其次，回归测试期间应对该软件版本冻结，将回归测试发现的问题集中修
改，集中回归；
缺陷跟踪
BUG生命周期
⦁ Bug严重等级定义 （更详细的请看其他分享）
⦁ 一级: 系统“挂起”或“崩溃”的错误，使得整个测试工作无法继续进行，如：程序死机、死循环、非法退出、
数据库死锁、程序无法登录等；
⦁ 二级: 软件功能未按产品需求文档规定的实现，导致功能报错，其他模块测试工作无法进行，如：功能
不符、接口错误等；
⦁ 三级: 一般性错误：如界面UI不符/错误、错误未给出弹出框提示等；
⦁ 四级: 轻微bug，如：格式排版、个别文字错误等问题；
⦁ 五级：对软件的改进建议，如：需求说明中未明确但影响用户体验等；
注：Bug严重等级与Bug优先级一一对应，特殊情况可调整映射关系。
Bug提交
尽可能以最简短最清晰的语言描述bug以便开发人员更快的定位问题，如有报错信息截图需附图，如有视频可附上。
Bug处理流程图
（不同的工具处理流程可配置，根据BUG的生命周期来）
⦁ 软件发布标准
软件产品未经测试合格，有严重bug时，不允许发布。
⦁ 争议处理
若针对同一问题研发、测试团队对结论有争议，需项目组成员及产品共同讨论，项目经理给出最终结果，并衡
定是否上线。
---总结阶段---
⦁ 测试报告内容要素：测试范围、测试方法、测试工具、测试环境、测试结果与缺陷统计与分析、测试
结论与建议等；（测试报告模版）
⦁ 每个测试阶段或上线前用例及各环节执行完毕后都需要提供测试报告；
⦁ 测试归档 是在测试验收结束宣布测试有效，结束测试后，对测试过程中涉及到各种标准文档进行归类，存档；
涉及的文档：测试计划、测试用例、测试阶段性报告、测试总结报告；产品迭代需求说明、设计文档等，最好归类为一次版本上线的文件夹，日后有可追溯性；
⦁ 测试归档执行人员：测试组长/负责人。
⦁ 上线后总结
⦁ 上线后测试组内需对上线成功或经过一段时间线上反馈的问题做出总结；
⦁ 总结内容：对整个研发过程改进的建议、提高测试效率的方法、若出现问题需追溯出根本原因、测试过程出现问题的改进方法、对测试过程中好的一面予以肯定并继续推行等；