软件测试禅道是什么?如何使用?

发表于:2022-6-15 09:57

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:百度测试开发    来源:今日头条

  一、前言
  禅道是一个测试管理工具,可以在里面进行项目管理以及bug用例管理,是一个非常好用的管理工具。
  当测试环境搭建完成后,测试人员将在自己搭建的环境上执行测试用例,开展测试工作。
  测试人员在执行测试用例的过程中,如发现实际结果与预期结果不一致, 则意味着出现Bug (缺陷、错误、问题)。当测试人员发现了Bug之后,就需要把Bug提交给开发人员进行修复。
  二、目的
  1. 量化评估
  ·对个人的评估
  把工作拆分成一个一个的最细粒度任务,可以详细到小时的单位,并分配给开发人员。
  任务分配者(比如迭代负责人)注意每个任务难度、复杂度相近。管理者可以通过任务的完成数量,完成时间,对开发者有一个量化的工作量评估。
  通过所完成任务的 bug 的率的统计,可以对开发人员的代码质量有一个大概的评估。
  工作量和工作质量可以作为绩效评估的参考项之一。
  · 对团队的评估
  如果不能把握团队的工作量和完成情况,管理者往往只能靠感觉评估团队的需求处理能力。
  通过把所有的工作拆分成任务并在线上分配给开发人员,再结合一些统计报表,管理者对团队执行力可以有一个数据化的感知。
  方便管理者对外承诺,也可以作为团队是否需要扩张的参考依据。
  2、降低成本
  · 流程化管理
  标准流程可以大幅降低沟通成本。
  通过形成标准化的“产品需求管理”,“任务分配和追踪”,“测试用例管理”,“bug追踪”机制,可以省去大大小小的很多的沟通会议。
  有什么不明白的直接线上追踪就可以了。
  · 快速追踪
  线上项目管理,把“文档”,“产品”,“模块”,“需求”,“测试例”,“bug”,“开发分支”进行关联。
  每一个环节都可以往前往后进行追踪。免去了测试人员不知道bug应该提给谁、开发人员找不到产品人员、不知道某开发分支关联了那些需求、需求变更历史无法追溯等一些问题。
  · 内部协调
  各责任人根据“需求列表”为主线进行沟通协调。产品做完UE后,拆解成具体的的需求列表。
  测试人员可以根据需求列表中的每一项需求编写测试用例并执行; 迭代负责人可以通过需求列表进行任务的拆解和分配; 后端可以根据需求列表拆分成具体的API; 前端可以拆分页面上的功能点。
  · 打开持续优化通道
  有了标准流程,并且执行过程可视化,才能不断的优化流程或优化团队人员,最终达到提高整体团队效率的终极目的。
  三、使用禅道达到上述目的
  1、思想
  禅道的基本设计思想是,产品、开发、测试三权分立。
  产品人员负责创建产品、拆分需求、制定发布计划并发布产品;迭代负责人负责创建迭代、关联该迭代需要完成的需求、分解任务指派到人、制定发布版本,并提交测试。
  开发人员执行任务并完成任务;测试人员编写测试用例,提交bug,追踪bug。
  2、核心概念
  · 产品
  产品:对外交付的完整产品,比如,xx内部管理系统。
  模块:产品拆分成的功能模块,比如财务模块。
  需求:模块继续拆分成具体的需求点。
  计划:产品人员对外承诺的发布计划。发布计划关联一份需求清单,大多数情况下,迭代跟发布计划一一对应。
  发布:项目结束后产品人员创建发布,目的是告知公司其他部门新版本的产品可以投入使用。
  · 开发
  任务:根据需求拆分的开发任务。
  迭代:同敏捷开发的迭代(Sprint)。
  版本:任务执行完成之后,提测之前创建发布版本。根据版本提交测试单给测试人员。版本测试完成之后由产品人员进行发布。
  · 测试
  用例:测试人员根据需求创建的测试用例。
  bug:测试用例转的bug,或测试过程中发现的bug。
  · 其他
  文档库:保存相关的文档,UE、UI、架构设计、API设计等。文档可以是文件也可以是外部链接。
  统计报表:燃尽图等。
  组织:组织结构,可以根据自己部门的情况自定义,比如前端、后端、测试等。
  四、使用-主流程
  1、产品人员
  · 产品管理
  创建产品:产品人员创建产品。
  产品包括:名称、代号、产品负责人、测试负责人、发布负责人等属性。
  导入需求:产品人员把整个产品拆分成大的功能模块,然后将功能模块拆分成详细的需求列表。需求可以分层,建议不超过三层。
  发布计划:产品人员创建发布计划,并关联本次计划需要完成的需求列表或计划修复的bug。
  发布版本:开发人员完成某次迭代后,生成可测试版本。该版本经过测试后,由产品进行验收并提交发布。
  · 需求管理
  创建需求:需求包括需求来源、备注需求发起人、关联的产品、关联的模块、关联的计划、由谁评审等属性。
  变更需求:需求变更的时候,系统会记录下变更的内容。
  需求评审:指定评审人,由评审人员执行评审的操作。
  2、迭代负责人
  创建迭代,并拆分成细粒度的任务列表,并分配任务给开发人员。
  开发过程中,通过燃尽图等及时关注任务的执行情况。检查是否跟理想状态有所偏差,及时发现问题,并处理异常情况。
  开发完成后,创建版本(或分支),提交测试单给测试人员,测试人员会根据测试单进行测试。
  3、开发人员
  开发人员需要参与需求评估和需求拆分的会议。需求被拆分成具体的任务后,由开发人员认领各自的任务,进行开发,并维护该任务的生命周期。(开始、完成、挂起等)
  4、测试人员
  · 编写测试用例
  在产品人员导入产品/需求之后,测试人员就可以开始在需求上编写针对于该需求的测试用例。
  在开发人员提交测试单后,执行所有测试单中的测试用例。
  · 提bug
  提交bug给开发人员,根据需求所关联的开发人员,可以找到该bug指派的对象。
  bug创建后管理整个bug的生命周期。

  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号