对于一个r \ u0026研发团队的目的，标准化的工作流程资产不可或缺的一部分，特别是对于初创的r \ u0026研发团队方面。很多r \ u0026研发管理是不够完整。如何理解的研发团队中的各种角色，充分利用现有资源团队，为了确保最终用户的需求和产品管理是开发管理者需要考虑的问题。
測试流程就是须要标准化的协作流程中的一种，是一套用于规范需求、开发和測试人员进行服务公布质量控制的流程性指南和说明，确保整个团队对产品质量保证有一个统一认识。促进过程的可记录性和可跟踪性，提高团队协作的信息透明和工作效率。本文面向的是10人下面规模的小型研发团队，流程尽量清晰和简洁。是一种轻量级过程控制的体现。
一．流程说明
内部測试流程通常须要基于持续公布思想，整合版本号控制、配置管理、持续集成、过程自己主动化和部署流水线等多个project实践，实施过程中须要对以上各点有所了解。同一时候对开发/測试环境独立性等外部环境因素进行把控。
本文中提到的内部測试流程使用上须要基于一个带有Ticket系统的管理平台，如Redmine、Jira等等，假设使用多个平台可能会导致流程闭环的中断或运行效率的减少；同一时候。本流程仅仅适用生命周期较长（一个月左右或以上）的产品开发，一两周之内的项目不建议使用，由于流程和管理本身也须要成本；在分布式开发模式下，信息传递和有效沟通是团队协作的一个瓶颈，能够通过使用该流程确保协作的有效性。
内部測试流程中涉及的主要角色及其职责例如以下：
- PO：产品经理。负责产品规划、方案设计和功能分解
- DEV：研发人员。负责功能实现、进度控制
- QA：測试人员，负责产品质量控制、服务公布
内部測试流程中主要使用例如以下工具确保流程的运转和信息的传递：
- 邮件：过程数据记录、流程阶段性成果和终于闭环达成的消息传递机制。
- Ticket系统：问题跟踪、范围/时间控制和团队协作统一平台
- Jenkins：系统构建、版本号控制和服务公布统一平台
二．流程展开
Ticket系统上的问题我们统称为一个Issue。一个Issue具有5大状态。包括各个状态转变过程和责任人的Issue完整生命周期例如以下：
结合Ticket系统上Issue的生命周期。内部測试流程整体流程图例如以下，当中背景为红色的流程须要通过邮件进行信息传递和同步：
2.1 新增Issue到Ticket 系统(PO+QA)
Ticket系统上与測试相关的Issue来源有两大块，新增Issue的状态为“New”：
- Feature：即功能点，来自于每次需求会议。由PO负责进行录入
- Bug：即缺陷，能够包含重大缺陷（Bug）和小问题（Defect）。前者直接影响服务的公布。后者可视情况排除在公布范围之内。由QA负责进行录入
2.2 Issue开发 (DEV)
DEV依据Ticket系统上指派给自己的Issue进行开发。开发过程中Issue状态为“InProgress”。
2.3 更新Issue完毕状态(DEV)
DEV开发完对应的Issue之后设置其状态为“Resolved”。
2.4 通过Jenkins平台构建服务(DEV)
DEV通过Jenkins持续集成平台进行server端、表现端服务自己主动化构建，构建结果会产生对应的部署和安装包。
2.5 发送提交測试邮件到QA(DEV)
DEV整理本次測试须要提交给QA的測试范围、各种部署资源以及部署步骤和注意点，并发送正式的提交測试邮件到QA相关负责人以告知本次測试需求的正式提交。邮件的标题注明測试的系统名称、測试日期和该日期下的提交測试序号，如：XXX update(X)@2014-XX-XX，表示哪个系统服务哪天的第几次提測：待測Issue列表：
1. 100
2. 101
3. 102
4. 103
5. XXX
部署资源列表：
1. server包：服务端Jenkins构建链接
2. client包：clientJenkins构建链接
3. 数据库脚本：SVN链接
部署步骤：
1. server包部署步骤
2. client包部署步骤
3. 数据库脚本部署步骤
4. 其它部署步骤
部署注意点：
1. 注意点1
2. 注意点2
部署有问题请与我联系。測试过程中需求有问题请与PO联系，功能測试和反馈依照既定内部測试流程进行。
2.6 部署服务到測试环境(QA)
QA使用DEV提供的部署步骤将相关服务资源到測试环境，假设部署过程中不论什么问题。QA须要与DEV确认部署资源和步骤。
2.7 发送服务部署成功邮件到DEV(QA)
服务部署成功后，QA发送服务部署成功邮件给DEV以告知本次測试工作正式启动。该邮件中须要提供相关服务版本号信息供DEV进行确认。确保部署过程的正确性。
2.8 更新Issue測试状态(QA)
QA依据本次測试范围更新Ticket系统相关Issue状态为“In Test”，并指派Issue为QA人员自身。
2.9 Issue測试(QA)
QA依据需求进行Issue測试，測试过程中依据情况创建新的Issue并对有问题的已有Issue须要又一次设置其状态为“In Progress”并将其指派给开发者。
測试过程中假设对需求有疑问，QA须要与PO进行沟通确认。
2.10 发送測试结果邮件(QA)
QA依据本次測试范围完毕測试工作之后发送測试结果邮件给DEV以告知本次測试过程正式结束。该邮件除起到闭环告知作用之外，简要列举本次測试新建/重开的Issue数量。
測试结果邮件模板可參考：
本次測试结束（未通过）：
Test Result:REJECT
1bug in progress
2bugs new
详细请參考Tickct系统上更新。
或者（通过）：
Test Result:ACCEPTED
至此一个完整的内部測试流程闭环结束。也意味着下一个測试流程開始启动。
三．小结
内部測试流程从下面几个方面强化流程的运行力：
- 闭环管理：通过对三个消息的相互作用，利益相关者了解节点测试的范围和时间
- 团队分工：了解利益相关方和责任分工，每一步都可以浏览到相关责任人
- 信息透明度：流程跟踪和可追溯性，，根据提供的数据召回
- 远程协作：使用引起的地理位置还原过程和平台沟通障碍