jira_bug管理系统使用说明.docVIP

你一定要坚强，即使受过伤，流过泪，也能咬牙走下去。因为，人生，就是你一个人的人生。 ============================================================================ 命运如同手中的掌纹，无论多曲折，终掌握在自己手中 ============================================================== Jira bug 管理系统使用说明 1.登陆jira系统 Jira的外网访问地址是 58:8001 内网访问地址是 11:8001 注：内网访问速度会快很多，但是考虑到工程师经常出差，所以将外网同时开放了。 管理员为软件二部的每位工程师都注册了一个用户名，用户名是 工程师的中文名字，初始密码是szclou，请各位再首次登陆时修改自己的密码 2.JIRA 系统的使用 2.1提交问题 2.1.1新建问题 点击提交问题，选择项目和问题类型 问题类型分为两种： 缺陷 ：产品中的错误，生产环境使用中和测试报告的。 需求变更：原有功能不够完善，不够好用而进行的修改 针对两种不同的问题类型，填写的详细资料也不同，先做如下说明 缺陷 填写的详细资料 问题描述：尽量简短地描述故障 优先级：分为危急严重一般次要轻微5个级别 截止日期：问题解决的最后期限 模块： 选择项目种对应的模块 受影响版本:当前出问题的版本 修复版本: 规划要解决的版本，一般为出问题的版本 分派给：选择分配给特定的人，如果不指定，则分选自动。 报告人：提交问题的人 环境:例如操作系统，软件信息，硬件规格（包括适用于本任务单的）等等信息。一般地，我们在这里添上联系人，联系方式等信息。 详细描述：详细描述，越详细越好。。。。。提供需要什么时候完成等等信息。最后能够附上出问题的URL地址，以方便追查故障。 详细描述包括如下内容 场景：问题对应的功能项 预期结果：程序应该输出的结果 结果：程序实际输出的结果 分析：程序不过出现的原因（可选项） 注意事项：补充说明（可选项） 需求变更 填写的详细资料 和缺陷填写的详细资料一样，只是 详细描述的格式不一致 详细描述包括如下内容 变更内容：简要描述需求的内容 变更原因：需求变更的原因 变更影响相关程序：影响的模块（中心控制或者web等） 基本路径：填写基本的业务流 补充说明: （可选项） 2.1. 提交问题完成之后我们可以给提交的问题添加附件和截图。 进入项目中的问题列表，选择刚刚添加的问题，左边操作有添加附件和上传屏幕截图，可以把相关日志，截图添加给任务单： 2.2任务单（问题）处理流程 任务单处理流程、状态变更和各角色参与见下图。 任务单的5个状态是 打开，处理中，已解决，关闭，重打开 其中，任务单提交者提交任务单后 状态为打开； 开发人员看到打开的任务单可做如下处理，如果确认是问题，则 将状态置为 处理中，如果认为不是问题则将状态置为 已解决（并写明不是问题的原因） 开发人员 将状态为 处理中 的任务单处理完成了之后 将任务单状态置为 已解决 任务单提交者看到状态为 已解决 的任务单，进行回归测试，若问题已解决，则将任务单状态置为 关闭，若 问题未解决，则将任务单 的状态置为 重打开 重打开的状态和打开的状态一样，处理流程和打开状态一样 2.2.1任务单的分配 任务单在新建的时候，可以分配给某个开发/维护人员处理。 系统管理员可以修改任务单，把它分配给某个开发/维护人员处理。 开发/维护人员可以自己申请把一个状态为开放（OPEN）的任务单分配给自己。 2.2.2开发人员处理 任务单分配给一个开发/维护人员，那么这个开发人员就必须按任务等级开始处理任务单。 点击 开始处理 开始处理任务单，任务单的状态则变为处理中。 当处理完毕之后，点击 解决问题 ，并填写相关处理信息。任务单状态则变为已解决。 2.2.3测试与发布 任务单提交者发现任务单状态变为Resolve（已解决），那么他可以按照开发人员的指示对平台进行测试并更新。 测试更新成功则关闭任务单Close Issue，并反馈信息到任务单中（添加注释） 如果测试更新还发现有问题，则把任务单Reopen（重开放），提供信息指定开发人员再进行处理。 2.2.4其他人的参与（相当于bbs功能） 其他开发人员和管理员可以对任务单添加注释，提供帮助和指示给当前处理的开发人员。 3．提交缺陷的实例 Bug的生命周期：提交问题——解决问题——关闭问题 3.1提交bug 如：测试工程师 测试发现问题，点击bug管理系统上的 提交问题 选择项目，缺陷类型，点击下一页 填写bug信息，点击 创建 创建完毕之后如有截图，则