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、结语

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

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

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

 

  • 2
    点赞
  • 7
    收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值