jira培训文档

所以，测试提交bug时，请

1.摘要主要用于指明Bug发生的地点、在什么条件下发生什么现象。 2.尽可能的加上描述字段： 1）描述Bug发生的地点、所用账号类型、操作步骤、期望值、实际值，尽量描述更多的环境参数， 如操作系统等。 2）一个Bug不会包含多个问题，会尽量单一化，便于跟踪处理及统计 3）对于很难描述清楚的Bug需截屏作为附件上传，并在描述中写明参照附件。 4）尽量减少重现的步骤以达到用最少的步骤来重现问题； 5）不要使用完全的大写形式，那样会让人感觉象控诉。不要使用感叹号或其他表现个人感情色彩的 词语或符号。 6）不要使用含糊的词语（例如，好像，似乎）来描述发现的现象。 7）在BUG提交前，测试人员应该反复阅读它，集中剔除那些没有关系的步骤或词语。隐含的或模糊 的说明和那些由于对没有任何关系的细节或者那些在重现错误过程中不需要的步骤。 8）如果是概率性的BUG,尽量重现BUG,找到BUG产生的条件，如果找不出BUG产生的原因必须写明 BUG发生的概率大约是多少。

JIRA是Atlassian公司出品的项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理 等工作领域。


JIRA中配置灵活、功能全面、部署简单、扩展丰富，其超过150项特性得到了全球115个国家超过19,000家客户的认可。


问题管理
自定义问题类型，适应组织管理的需要 自定义字段，可选择字段类型超过20种，在此基础上还支持插件进一步扩展 自定义问题安全级别，可以限制指定用户访问指定的问题 如果多个问题需要同时修改同一字段值或执行同一工作流动作，你可以使用批量操作功能一次性完成 效率 登记问题预计完成时间、实际工作时间，就可以了解该问题预计还剩多长时间才能解决。甚至可以出具时间跟踪报告，了解用户的工作 如果一个问题需要多人协作，可以将问题分解为多个子任务，分配给相关的用户 将相关或有依附关系的问题建立链接，以便于用户快速了解 为JIRA的问题添加附件，可以帮助技术人员快速解决问题，当上传图像文件时，JIRA自动显示图像缩略图。




9）BUG如果在特定条件下产生的，必须写明产生的条件和操作步聚。
针对开发的需求－任务（task）


需求－需求拆分的过程：
由测试人员把大的需求拆分成细节的功能点，然后再把功能点细化，到更具 体的一条条case－task。然后录入到JIRA。
Case1
功能1 Case2
需求1
功能2
Biblioteka Baidu
功能3
开发需要解决case导成的task

跟报bug不一样的地方：

测试人员提交的task到JIRA，开发人员需要review后，认同所有的task必须要 解决完成，作为开发代码准出的标准。也就是说，只有所有的task都开发，自 测完成通过，才可以进入到后续的活动。 一旦认同task，开发人员不可以直接关闭。 开发，自测完成后，开发人员解决对应的task。但是不关闭，测试人员也不去关 闭。只关注项目下有多少完成的task，多少没有完成。 所有的task都完成后，开发人员提交代码，测试人员开始进行大规模的测试活动。
奥克巴尔－JIRA培训
针对测试部门的BUG和需求任务管理
2015-12
一，JIRA的链接地址，账号

地址：http://jira.aokebaer.com/secure/Dashboard.jspa 默认管理员：王宁，马永飞，王磊

打开JIRA后请设置自己的密码，并且保存为书签，方便以后使用
JIRA的历史，特性等
JIRA特性： 每个项目都有自己的概览页面包括：项目详细信息、最新更新情况以及一些报告的快捷方式 在项目界面中查看按照状态、是否解决等条件设置的分类统计报告 查看项目最新的活动情况 查看项目的热门问题 可以设置项目类别，将项目分组管理 可以为每个项目设置单独的邮件通知发件地址 自定义安全级别，指定用户对问题的访问 指定组件/模块负责人



如何提高效率，提一个好的问题

试想一下，如果你是一名开发人员，面对着一个bug只有一句话描述的很不 清楚，里面有一些模糊的信息，没有复现步骤，没有log没有重现概率，没 有截图…你会花很多时间去自己调研么？如何才能提高效率？ 一个bug，是否已经有其他测试人员已经提交过了问题，是否有类似问题已 经被标记。Bug必要信息：发生错误的简单描述作为标题，错误发生的版本， 影响到了哪个版本，发生在哪个模块，应该谁来负责解决，具体的描述， 期望结果，实际结果，是否有log，截图，视屏，需要何时解决，是否在特 定条件下才能出现比如特定的手机版本，等等。


Agile, Kanban
先介绍JIRA的Bug管理流程

一般的bug管理流程，如图：
Bug处理流程的说明：

1、测试过程中发现问题在JIRA上新建Bug分配Bug给相关经办人Bug为 Open状态 2、接收到邮件通知后可能会重新将Bug分配给相应开发人员Bug保持Open 状态 3、开发人员若需要修改将Bug状态改为In progress若不需要修改直接将Bug状 态改为Closed(Won't Fix ) 4、开发人员修改Bug完毕后将Bug状态变更为Resolved(Fixed)，并且附上说 明。 5、测试对状态为Resolved的Bug进行验证，若验证通过，将Bug状态改为 Closed，并且说明bug已经解决。若验证不通过，将Bug状态改为Reopen 6、对于Reopen状态的bug，重新按上面3-5步骤进行处理，直至问题Closed