tapd怎么提交bug

你好，可以开启项目下的「缺陷」应用，提交bug。 *** 作路径是：项目设置-应用设置-添加应用。

如果在使用TAPD的过程中遇到什么问题，欢迎联系TAPD官网（tapd.cn）右下方智能客服，或者在TAPD官方社区（网页链接）反馈。

1.QC

QC的全称Quality center, 质量中心的意思，它是一款缺陷管理工具，可以组织和管理一个项目所有的测试阶段.

2.Bugzilla，

Bugzilla是一个Bug追踪系统设计用来帮助你管理软件开发。

Bugzilla是一开源Bug Tracking System，是专门为Unix定制开发的。但是在windows平台下依然可以成功安装使用.

3.Bugfree，

BugFree是借鉴微软的研发流程和Bug管理理念，使用PHP+MySQL独立写出的一个Bug

管理系统。简单实用、免费并且开放源代码(遵循GNU GPL)。

4.JIRA

JIRA是集项目计划、任务分配、需求管理、错误跟踪于一体的商业软件。

JIRA功能全面，界面友好，安装简单，配置灵活，权限管理以及可扩展性方面都十分出色。

JIRA创建的默认问题类型包括New Feature、Bug、Task和Improvement四种，还可以自己定义，所以它也一是过程管理系统。

Jira融合了项目管理、任务管理和缺陷管理，许多著名的开源项目都采用了JIRA。

JIRA 是目前比较流行的基于Java架构的管理系统，由于Atlassian公司对很多开源项目实行免费提供缺陷跟踪服务，因此在开源领域，其认知度比其他的产品要高得多，而且易用性也好一些。同时，开源则是其另一特色，在用户购买其软件的同时，也就将源代码也购置进来，方便做二次开发。

5.Mantis

Mantis是一个基于PHP技术的轻量级的缺陷跟踪系统，其功能与前面提及的JIRA系统类似，都是以Web *** 作的形式提供项目管理及缺陷跟踪服务。在功能上可能没有JIRA那么专业，界面也没有JIRA漂亮，但在实用性上足以满足中小型项目的管理及跟踪。更重要的是其开源，不需要负担任何费用。不过目前的版本还存在一些问题，期待在今后的版本中能够得以完善。

6.Readmine

Redmine是用ruby开发的基于web的项目管理软件，免费。JIRA收费

Redmine可以创建子任务，而jira不易创建子任务。

Redmine来管理项目，但它没有用例管理.

7.禅道

禅道项目管理软件是开源，集产品管理、项目管理、质量管理、文档管理、组织管理和事务管理于一体，是一款功能完备的项目管理软件，完美地覆盖了项目管理的核心流程。

8.TAPD

TAPD项目管理软件是基于敏捷开源，隶属腾讯开发出来的，集产品管理、项目管理、质量管理、文档管理、组织管理和事务管理于一体，是一款功能完备的项目管理软件，完美地覆盖了敏捷项目管理的核心流程。

9.TESTLINK

略

10.TD

略

如果想这块内容增强的小伙伴参考网上的相关知识(黑马程序员论坛等)

目的：为了控制开发节奏，并且及时获得反馈。迭代时间一般不进行固定周期，根据实际需要来定，但为了稳步推进特将以下规范整理如下：

常规迭代

时间周期与重要节点

分为：前期准备阶段、kick-off需求评审阶段（包含运营kick-off 以及开发kick-off时间）、研发阶段、测试阶段、产品发布 。整个周期大致为3周 共17个工作日。

迭代周期中第一周：产品准备阶段并完成需求评审

迭代周期中第2周和第三周为研发开发阶段和测试验收阶段。

节点：期间运营将需求在迭代周期的第三周前（即为最后一周前）反馈到产品，由产品进行消化整理，并最终确认。

与运营kick-off时间为版本上一期迭代周期的（第二周）进行kick-off

与开发kick-off时间为本期迭代周期（第一周前3天）进行kick-off

开发加内部测试时间共2周（12个工作日）。

关于需求分类：

运营需求在tapd中分为3类：活动需求、优化和新需求、客户反馈需求

需求记录规范：

活动需求：即为运营想要举办某个活动产生的需求，都将记录在活动需求。

记录中需要包含以下内容：

活动时间

活动详情

需要提供的支持

想要达到的效果

优化和新需求：即为对产品使用中发现可以调整后让用户体验变得更好的需求，都将记录在优化需求中。以及所需要的新功能都在优化需求中进行记录。

管理后台的使用都可以记录在【优化和新需求】分类中，记录时区分 管理后台和用户后台。

记录规范一：

现在的实现方式：

造成的问题：

想要实现的方式：

原因是（如果有数据，可以直接粘图）：

解决的问题：

记录规范二：

1. 这个需求要解决什么问题: 

2. 用户 *** 作的前置条件或场景是什么：

3. 用户的 *** 作是什么(描述下需要的功能或是使用流程):

4. 还需要什么补充规则: 

客户反馈需求：运营人员在客户维护过程中收集到的需求，都将记录在客户反馈需求中

客户反馈需求记录规范：

1. 客户反馈的原句或截图 

2. 相关产品或功能

3. 客户反馈途径

4. 是否需要产品回访(如建议回访，请包含客户的联系⽅式) 

处理优先级 与 流转机制

产品处理优先处理顺序为客户反馈需求->活动需求->优化和新需求

需求流转机制：

1、新->规划中（产品规划该需求）->实现中（开发正在实现该需求）->已实现（开发已经实现该需求）->测试中（产品和运营测试验收该需求）->已发布（线上正式环境已完成）

2、新->已关闭（该需求将不予实现，并注明关闭原因）

3、新->规划中->已拒绝（技术认为无法实现或实现代价过高）

Bug如何记录与处理机制

记录位置：tapd中缺陷

bug记录规范：

1. 缺陷位置: 

  页⾯链接

  相关账号、⽤户名、业务编号(如订单流⽔水号、财务流⽔水号)

  关键 *** 作步骤(截图)

2. 预期结果 

3. 实际情况 

Bug处理流程和反馈机制 

1.暂不处理->给出暂不处理的原因【产品】 

2. 延缓处理->给出缺失的资源或需要的处理条件【产品】 

3. 即时处理->产品将tapd指定给处理⼈【相应处理⼈员】 

4.处理完成后，指向相应的创建人和产品

5.创建人进行验证，确认bug已处理将状态更改为【已验证】

注意：无法复现的bug，将直接进行关闭。【产品】

bug响应时间：一个工作日内给出反馈

bug修复时间：研发评估后及时给出修复的结束时间，一般bug修复时间尽量在3日内完成

时间无法预估的bug修复需要注明原因。

关于重要需求临时讨论处理机制

重要需求讨论将提前三天将信息共享给所有干系人，并在第2天组织讨论。

关于大版本的迭代周期与需求对接流程：

大版本迭代周期为7周

具体分为3周准备阶段、期间产品需要完成（需求确定、概念设计、范围层确定、完成与运营的讨论确定）

研发kick-off  开发阶段 测试阶段 发布上线

沟通与管理

目的：项目所有干系人做到对整个项目有最清晰的了解和认知统一化。

遇到需求变更以及研发实现过程中出现问题时影响到开发进度，需及时进行邮件告知所有干系人【产品、技术】

与研发kick-off结束后，时间周期需要以邮件的形式告知所有干系人【产品】

运营遇到紧急需求需要在迭代周期内进行临时增加需求时，需要以邮件形式告知所有干系人【运营、产品】

测试完成并上线，以论坛形式在全公司进行通知【产品】

以上是我在公司中与业务或者运营人员进行协作的机制，希望可以帮到大家与其他业务部门建立起良好可持续的协作机制，最后还是希望大家持续关注，微信公众号中搜索“小宝谈产品”，让我们一起在产品和运营的路上不断前行～

---