1、概要
为形成合理、有效的工作流程体系，提高研发团队整体效率和输出质量，让问题可以追溯，BUG可以有效管理。现以测试作为入口，以TAPD工具为载体，建设适合本公司的测试流程体系。
2、BUG管理工具的作用简介
作用：有效的BUG跟踪检查，可以随时查看提交的BUG数据问题。对产品伙伴：了解产品存在哪些问题，有无设计缺陷，设计优化建议等。对研发伙伴：实时掌握BUG分布的模块，BUG的严重级别，已解决和未解决的区分，重点避免遗漏问题未修改。对测试伙伴：实时掌握BUG解决进度，延期解决的问题跟踪，高级别BUG修改的进度，BUG的整体管理和数据报表统计。
目的：问题可追溯，状态可跟踪，数据可统计
工具：TAPD、禅道、bugfree等
3、TAPD的使用
BUG生命周期及状态流转。
测试提起，状态：新BUG
研发解决后，状态：已解决
研发拒绝后，状态：已拒绝
研发需延期处理，状态：延期处理
测试验证后，状态：已关闭
详细流转请看截图：
测试篇
提交BUG时，要求写明操作步骤，实际产生的结果，预期的结果，[备注]主要用于填写部分代码截图，如接口请求/返回数据截图。
管理人：前端/后端，功能模块第一负责人，
模块：功能模块，
发现版本：根据测试版本填写，
优先级别/严重程度：由BUG等级进行区分，
软件平台：小程序，Android，Android大屏，IOS，WEB（视具体项目而定）
列表字段显示设置，方便查询问题，建议统一设置
勾选图中的显示字段，建议按截图右方顺序显示。方便有什么问题时，可以直接通过BUG单的ID号进行最快查询。
研发篇
在接收到新BUG时，可以选择以下状态：
正常修复BUG后：选择已解决，测试在验证问题的时候，以已解决状态的BUG进行验证
当前版本无法修复：选择延期处理，测试会跟踪延期处理问题，在有新版本发布后，会询问延期问题处理情况，若延期处理问题已经处理，研发需要即时更新状态为已解决
测试提交的非BUG：选择已拒绝，可能这个是需求问题，环境问题，外部原因引起，测试会对已拒绝问题重新审核质询。
注意：
1. 测试不能去定位每一个BUG是前端还是后端的问题，若提交到研发手上后，并非是自己所负责的模块问题，在TAPD可选人员的情况下，可以直接转给模块的负责人。（避免问题拒绝后，负责人不清楚问题的产生，到测试手上又需要重新去流转一次）
2.延期处理的问题，要确保是确实不能在当前版本解决的，才选择此状态。
产品篇
主要用于查看一些需求不明确，涉及优化建议，存在争议的问题。TAPD的其他功能如：需求、迭代等模块，视实际情况而定是否使用。以往的测试工作经验来看，其他功能实用性不高，可以暂时不考虑。
4、工作流程
需求评审>>编码>>测试>>回归验证>>上线>>维护
产品流程
由产品部门输出产品需求文档、UI设计图，并存储到SeaDrive云盘（以下简称云盘），需要按项目-版本号进行层级区分管理。版本编号由三位数字组成，如：V1.00，版本号迭代细节由实际情况而定。
新功能的增加、需求的变更，在产出了需求文档和UI原型图后，需要通知相关项目的研发人员和测试进行需求评审，评审后若有修改，修改后行车最终的需求变更文档，同步到云盘，通知研发、测试人员进行查看，做下一步工作。
测试流程
参与需求评审，拿到需求原型图/设计文档后，依据测试用例设计方法进行用例编写，完成后通知相关研发人员和产品进行测试用例评审，评审后若有修改，修改后形成最终的测试用例文档。
测试在接受到研发提交的送测单后，根据项目的轻重缓急先后顺序，依据TAPD的使用测试篇进行问题的提交，在测试完成一个阶段后，输出项目阶段性测试报告，用邮件的形式发送给产品、研发相关负责人。每提测一轮次，输出一阶段性测试报告，在项目整体系统测试完成后，输出用例执行报告，用于项目交付。
由测试进行送测单的管理，和项目提测次数、版本、日期的统计
研发流程
参与需求评审，拿到需求原型图/设计文档后，开始编码设计。必要的接口设计时，需要形成接口文档，主要用于后期测试做接口测试使用。主要3类接口形成文档：用户输入数据的接口，输出到其他系统的外部接口（A系统输出到B系统），接受外部系统数据的接口（B系统接收A系统数据的接口），接口文档包括：域名、API接口、参数类型限制、参数长度限制、（参数的逻辑关系：需要产品设计确认）
研发在提测前，尽量提前通知测试人员大概提测时间，测试好做任务的安排。提测前，需要进行自测（冒烟测试），作用：过滤掉致命的问题：如主流程不通，程序无法打开，轻量操作程序崩溃。目的：送测软件可以直接用于测试，不会被退回，避免退回影响研发/测试共同的时间。冒烟测试可向测试索要冒烟测试用例
提测时，需要填写送测单，写明项目名称、版本号、修改说明写测试的重点，例如修改了哪些内容需要着重测试、需要测试的模块，自测结果需要通过，技术指标可以填写涉及到的账号密码，或者需要访问的数据库地址，表名等
打包APK/IPA软件包时，根据项目的图标、名称、版本号进行打包。例：《测试》程序名：测试。包名：Android_CS_2018092901.apk（系统+缩写+日期+01）若当天提测两次就叠加到02，不能出现图标、名称和程序功能不符的情况
总体流程
产品发布需求后，研发开始编码设计，测试开始用例设计。研发提测提交送测单，测试接收到送测单后，根据送测单填写的重点内容，进行系统的测试，由TAPD进行问题的跟踪及反馈，一轮测试完成后，测试输出项目阶段性测试报告，邮件发送给相关负责人。
研发发起第N+1次提测时，要注意TAPD问题的解决情况和状态的更新，避免出现问题只修改了一半，又进行了第二次提测，因为有些问题会成为测试进行下一步操作的阻碍。影响测试对问题的反馈，和整体测试的效果
5、其他事项
各部门资料管理，建议都在云盘上进行，需求文档的管理，研发软件包、接口文档的管理，测试输出文档的管理。前期需要将云盘进行项目文件夹分层区分，版本号的区分。避免后面资料堆积过多，不好整理。
一个项目整体的测试情况：在没有新的需求或变更时，每提测一次，BUG的趋势应该是慢慢收敛的现象，若未收敛或者BUG数量增长，需要多方面分析原因。如代码修改是否影响到了更多的地方，测试力度每轮次都不一样。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
