BUG管理工具的使用及测试流程有哪些？

目录

1、概要

2、BUG管理工具的作用简介

3、TAPD的使用

4、工作流程

5、其他事项

6、结语

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数量增长，需要多方面分析原因。如代码修改是否影响到了更多的地方，测试力度每轮次都不一样。

6、结语

一切都为做出更高质量的产品努力

感谢每一个认真阅读我文章的人！！！

我个人整理了我这几年软件测试生涯整理的一些技术资料，包含：电子书，简历模块，各种工作模板，面试宝典，自学项目等。欢迎大家点击下方名片加入群聊与我一起学习交流，群里也会有大佬帮忙解答问题。