Bug属性规范及流程
目录
Bug属性规范及流程 (1)
1. 目的 (3)
2. 范围 (3)
3. 工具 (3)
4. 角色和职责 (3)
5. Bug属性定义 (4)
5.1．bug类型 (4)
5.2．bug严重性 (5)
5.3 bug优先级 (5)
6. Bug管理流程 (6)
6.1提交bug (6)
6.2分配bug (6)
6.3解决bug (7)
6.4验证bug (7)
6.5遗留bug (7)
6.5.1跟踪遗留bug (7)
6.5.2产品发布后发现的bug (8)
6.6bug分析 (8)
1.目的
本文档定义bug的整个生命周期，规范bug的解决方案及管理流程。Bug在流转的过程中有章可循。规范bug严重等级与bug解决优先级，使开发人员与测试人员能根据此文档准确判断bug的严重程度并加以解决；
2.范围
开发人员、测试人员
3.工具
禅道：
4.角色和职责
5.B ug属性定义
5.1．bug类型
5.2．bug严重性
5.3bug优先级
6.B ug管理流程
6.1提交bug
在提交一个缺陷的缺陷，首先尽量描述这个缺陷的属性。
当然，我们在提交一个问题之前首先应该保证，这个缺陷是没有被提过的，以免造成重复缺陷单。
提交后的bug状态为：激活
6.2分配bug
开发经理对bug进行初步评审，确定并指派到相应开发人员；
分配后的bug状态为：已确认
6.3解决bug
开发人员在确认完一个问题需要处理时，那么就对其进行处理工作。
解决后的bug状态为：已解决
6.4验证bug
回归缺陷对于测试人员来说是非常重要的工作，其有三个入口两个出口。
确认非缺陷问题：对于提交的一个缺陷，开人员处理为非问题或无法重现，然后直接转交给测试人员回归。测试人员再次确认，如果真如开发人员所说，则将问题关闭。如果非开发人员所说，是由于问题描述模糊或其它原因喂重现问题，则再次注明原因转给开发人员。
确认修复问题：对开发人员修复的问题再次进行确认，确认能过，则关闭问题。确认不通过，将问题再次打开并转给开发人员。
确认固定问题：有计划的对固定问题进行确认，有些固定问题随着时间的推移，版本的更新或已经不存在了，对这类问题应该及时关闭。有些固定问题依然存在且变得紧急，对于这类问题应该及时打开交给开发人员处理。
验收通过的bug状态为：已关闭；
验收不通过的bug状态为：激活；
6.5遗留bug
6.5.1跟踪遗留bug
对于让步发布的产品，需要跟踪产品发布后的允许情况。对遗留的bug跟踪记录并分析其影响范围，知道遗留bug形成解决结果。
6.5.2产品发布后发现的bug
产品发布后的bug来源有：客户、开发、测试人员。该类bug在发现后需要提交给项目组，纳入bug管理，该类bug的发现阶段标识为已发布，便于分析原因。
6.6bug分析
通过bug的数据分析，总结bug出现的原因、类型、规律，采取相应措施避免该类型bug 再次出现，提高产品质量。
1）统计项目组阶段bug的趋势图，用于分析产品的质量。
2）测试人员的每个项目的测试结束以后，将bug分析结果写在《测试报告》中。
技术中心管理制度 为了建立一个良好的激励机制, 更好地调动科技人员的工作积极性, 充分发挥大家的潜能, 科学、合理、高效地完成公司的新产品开发工作。特制订本管理制度, 本制度包括组织机构建设、总则、日常管理制度、课题管理制度、技术秘密管理制度。 一、组织机构的划分及职责 1.1产品市场开发研究室: 具体职能如下 1) 国内外相关产品市场调研与分析 2) 综合产品信息分析与研究 3) 课题( 项目) 可行性研究和咨询论证 4) 行业( 产品应用) 发展水平与趋势调研与分析, 对产品市场应用情况数据进行处理和统计分析 5) 经过市场调查、分析, 挖掘潜在的产品应用领域 6) 收集来自产品应用单位的信息, 提出新产品开发意见和建议 7) 负责编制新产品的研发方案 8) 负责新产品开发的标准化制定 1.2 产品研发行政事务研究室: 1) 负责研发人事管理制度
2) 对新产品试验进度安排及组织协调 3) 协助包装、标签、编码、送样等具体事项 4) 负责日常办公、试验物资的采购管理工作 5) 负责新产品的注册报批相关事项, 应用研究工作的组织联络、督促协调、质量监督、进度追踪等 1.3专利信息研究室: 负责本公司的专利工作。包括专利信息、专利说明书起草、申报等事项。 1) 产品行业政策法规咨询 2) 新产品咨询与评估 3) 文献收集、检索与资料翻译 4) 研发中心局域网的各种数据库的管理和维护等 5) 提出专利工作思路、专利文书的撰写及专利申报工作 6) 专利商标申报 7) 专利、商标权的维持和转让事务 8) 专利战略制定与组织实施 9) 专利、商标侵权监视与诉讼 10) 专利数据资料的管理与维护 11) 图书资料和期刊管理与维护
XXXX 公司研发中心管理办法 第一章研发中心组织结构与责权 第一节研发中心组织结构 一、技术研发中心组织结构图 图1-1技术研发中心组织结构图 二、研发中心岗位分布图 图1-2研发中心岗位分布图 在图1-1中，技改项目部一般是根据技术更新改造的实际需要而临时成立的组织，主要在技术总监的领导下，由技术部经理或其授权人担任技改项目经理。 研发中心 技改项目部 软件研发中心 研发调研部 技术总监 软件研发经理 技改项目经理 技术部经理 研发调研主管 网页设计工程师 软件测试工程师 高级研发工程师 调研专员 技改项目主管 SEO 工程师 软件研发工程师 数据库工程师
第二节研发中心职责与权力 一、研发中心职责 研发中心的具体职责如图1-3所示。 图1-3研发中心职责 二、研发中心权力 为更有效地实现上述职能，研发中心被赋予下列权力，具体如图1-4 所 示 。 职责1 建立并完善产品设计、新产品、标准化技术规程、技术信息管理制度 职责3 职责4 组织编制新产品开发计划、技术研究计划，并组织实施 职责5 按计划开展新产品设计、试验和研究、测试工作，负责产品的试验、鉴定工作，参与产品的认证和质量监督活动 职责6 根据设计要求编制先进、合理的产品方案、文件，对产品图样、技术文件进行审查 职责7 根据产品方案、文件，提供生产设备的参数，申请购置生产设备 职责8 职责9 组织编制部门管理制度 职责10 组织技术员参与产品服务，解决产品在使用过程中出现的技术问题 组织对技术文件和资料进行管理和控制，建立产品技术档案、文件档案 职责2 负责企业标准化工作，组织贯彻上级关于标准化工作的计划和方针、政策，组织贯彻上级发布的各种技术标准 负责完成权限范围内技术谈判工作，以及对所引进技术的消化和转化工作
研发中心 仪器设备管理制度 拟制审核批准受控状态 内控文件 更改记录 版本／次主要修改内容或更改单号更改人日期A/0 首次发放2005.10.20 A/1 依ISO9001:2008标准修订2010.10.21 A/2 封存设备增加停用日期记录2012.06.06 配发部门总经理室业务部研发中心生产部品质部采购部财务部仓库分发份数 3 1 1 1 1 1 1 1 一、目的和适用范围 为进一步规范公司设备管理流程，提高设备管理水平，确保设备安全、稳定、
高效的运行，结合公司经营管理实际情况，特制定本办法。 本办法对公司设备管理作了较为详细的规范，具体规定了公司设备管理的范围和职责，以及设备投资、运行、日常维护、润滑、检定、点检、维修等管理内容及要求。 本办法适用于公司研发中心的技术、生产和办公类设备，特种设备及集中空调、空压、水泵、通风、配电等动力类设备的日常管理、维护保养、维修、检定等由设备管理部门负责； 二、设备管理单位 1、负责组建设备维护、维修和管理队伍，做好设备的日常管理、使用和维护维修工作，以及维修备件的购置计划。 2、组织设备操作、维修人员的技术培训及安全教育工作。 3、负责新增设备的立项申请，认真做好设备资产台帐及实物管理，做到帐物相符。 4、组织维修技术人员完成设备安全操作规程、设备点检、设备完好标准、设备日常维护保养内容等的编制工作。 5、加强设备的现场管理，认真执行设备交接班制度和设备维护保养制度，做好各种原始记录的收集、整理和分析。 6、监督、检查和考核操作人员正确使用设备，排除各种安全隐患，防止人、机事故的发生。 三、前期管理 （一）设备立项 1、因生产、科研、经营需要增加设备时，由需求单位负责组织论证并提出专项申请报告，报公司主管领导批准后，按照规定程序填写《设备、仪器购置申请单》，完成审批手续。 2、申请报告应包含如下内容：项目提出理由，使用单位目前同类设备数量、品牌、型号、数量及分布、使用情况等，提供设备供货商技术实力、设备技术参数、可靠性、维修性、耐用性、节能环保性、成套性等资料。 （二）设备采购 1、因科研、生产急需启动的一般项目，由研发中心直接组织实施。 2、研发中心在完成审批手续后方可签订采购合同。 3、研发中心凭《设备购置申请单》和借款单到财务部借款支付货款，并建立购置台帐。财务部要按要求及时安排付款。 4、设备技术协议的更改须由使用单位书面申请，重大变更原则上应征得公司主管领导同意后，方可与供应商签订更改协议。 5、外购设备到厂后，设备管理单位应安排进行妥善保管，保持外包装完好。 6、研发中心组织相关人员进行设备开箱时，各单位应积极配合，参与对到货设备的开箱检查和确认，按设备装箱单清点核对技术资料、说明书、出厂检验、附件清单，及所有随同设备到货的备附件、工具和软件等并做好相应记录。 7、各单位按要求做好设备安装的各项准备工作，并配合设备供应商技术人员对设备进行安装、调试和验收。
Bug管理规范
一、概述 本规范是常规的bug管理流程，适用于项目过程中的bug管理
二、BUG周期
三、Bug的分类、状态、级别 3.1 bug分类 1. 功能 A.重复的功能；B.多余的功能；C.功能没有达到设计的要求；D.功能实现与设计要求不相符。 2. 易用性 A.界面不美观，控件排列、格式不统一，焦点控制不合理或不全面；B.缺少帮助信息，或者帮助信息不完全； C.功能操作复杂，提示信息不合理，易产生歧义。 3. 安全性 A.数据有效性检测不合理；B.重要数据在传输中没有加密；C.缺少身份认证机制或认证不合理； 4. 可靠性 A.数据存贮的可靠性；B.业务处理的可靠性； 5. 性能 A.并发量；B.吞吐量；C.响应时间。 6. 兼容性不同厂商的浏览器以及浏览器的不同版本，手机app指不同操作系统 3.2 bug状态 Bug的状态主要分为新建、已分派、已解决、重新打开、已关闭、挂起。 ?新建状态（NEW ）：Bug创建后的初始状态。 ?已分派状态（ASSIGNED）：经过确认为有效问题后分配给开发人员的状态。 ?已解决状态（RESOLVED）：开发人员对软件问题进行处理或修改后的状态。 ?重新打开状态（REOPENED）：对开发人员修改后软件问题，经过验证，如果仍然存在，则将其状态改为“重新打开”状态。 ?关闭状态（CLOSED）：Bug解决后测试人员验证通过，则将其状态修改为已关闭 ?挂起状态：经过项目经理确认延期修改的bug 3.3 bug严重等级和优先级定义 bug的严重级别定义：
BUG优先级定义： 四bug描述规范 bug描述要简洁明了，方便开发人员重现和后续跟踪。 版本：当前测试的版本号 平台：测试使用的平台说明 摘要：概要描述问题。 描述：应该描述问题发现的步骤、期望结果和实际结果 描述可分为“步骤”、“结果”（含：期望结果、实际结果）、“补充说明”三部分，各部分之间用空行隔开。“补充说明”部分可根据实际情况选择是否需要描述。具体格式如下： 步骤： 期望结果： 实际结果： 补充说明： 1. 如果多处出现类似问题，应描述出现该问题的所有模块或界面。 2. 如果不可重现，应说明 附件：添加错误附图或错误信息。
药业股份有限公司研发中心 内部管理制度 为了建立一个良好的激励机制, 更好地调动科技人员的工作积极性, 充分发挥大家的潜能, 科学、合理、高效地完成公司的新产品开发工作。特制订本管理制度, 本制度包括组织机构建设、总则、日常管理制度、课题管理制度、技术秘密管理制度五个部分。 1．适用范围: 本制度适用于研发中心所有人员 2．制订依据: 2.1公司《人事管理制度》、《新品研发工作程序及奖惩办法》 2.2公司《商业秘密安全管理条例》 2.3国家SDA《药品注册管理办法》 2.3国家SDA《药物非研究质量管理规范》 2.4国家SDA《药品研究实验记录暂行规定》 第一部分组织机构的划分及职责 1研究基地的组织机构: 1.1医学事务研究室: 具体职能如下 ––选择、联系临床研究单位及参试单位。
––研究者手册的编写, 起草并与临床研究单位共同完善新药研究试验方案; ––临床试验进度安排及组织协调。 ––制定临床试验的标准操作程序( SOP) 并监督实施。 ––提供临床试验用药量, 协助包装、标签、编盲、送药等具体事项。 ––收集来自临床试验单位的信息; 提出意见和建议。 ––对临床试验数据进行处理和统计分析。 ––临床试验质量控制和质量保证。 1.2 注册管理办公室: 负责新药的注册报批相关事项, 药理毒理研究工作的组织联络、督促协调、质量监督、进度追踪等。具体如下: 临床前研究工作 ?选择、联系临床前研究单位。 ?与临床前研究单位共同完善试验方案; ?试验进度安排及组织协调。 ?会同试验单位制定临床前试验标准操作程序并监督实施。 ?提供试验用药量、包装及标签 ?收集来自试验单位的信息, 提出意见和建议。 ?会同试验单位对试验数据进行处理和统计分析。 注册报批事项
b u g管理规范及流程 YKK standardization office【 YKK5AB- YKK08- YKK2C- YKK18】
bug管理规范及流程 1、概述 本文档定义bug的整个生命周期，规范bug的解决方案及管理流程。Bug在流转的过程中有章可循。规范bug严重等级与bug解决优先级，使开发人员与测试人员能根据此文档准确判断bug的严重程度并加以解决； 2、关键角色及职责 ?
3、Bug生命周期 4、Bug书写规范 BUG标题 1)以一个简短的句子描述某个模块存在的问题；或者某个操作导致了什么问
题； 2)描述问题时要简练、直接切入主题，但是要抓住要点； 3)偶现bug在主题前标注出现的次数； 4)有些模块功能比较多，可以在主题描述前标注上具体得操作； 示例： 【偶现3次】【账号切换】登录非本机手机号，切换回本机号码登录后，收不到消息 【偶现2次】添加载体库时程序停止运行 重现步骤 说明区域包括：步骤、预计结果、实际结果、测试环境、bug出现时间、截图、日志 1) 用数字编号，一步步的描述问题的重现步骤； 2) 不同的操作步骤产生不同的问题，需分别报bug；尽量做到一个bug汇报一个问题； 3) 偶现问题必须明确bug出现的时间、提供截图以及日志； 5、Bug解决方案 当天提交的新建状态bug，对应的开发人员需在2天内全部审核一遍，将bug分成以下3类：拒绝、进行中、延期、反馈（给产品）； 开发已修复的bug：将bug状态置为已解决；同时添加说明验证版本号、错误原因、解决办法； 示例： 验证版本：（1101表示在11月1号可以验证） 问题原因：未作条件判断 解决方法：进行合理边界判断
研发中心管理流程及规范 未经允许，文档内容不可全部或部分发表、复制、使用于任何目的。
版本修订历史
目录 1. 目的..................................................... 错误!未定义书签。 2. 适用范围................................................. 错误!未定义书签。 3. 研发中心组织结构......................................... 错误!未定义书签。 . 研发中心架构....................................... 错误!未定义书签。 . 组织结构........................................... 错误!未定义书签。 . 部门岗位........................................... 错误!未定义书签。 4. 岗位职责................................................. 错误!未定义书签。 . 软件部主管岗位职责................................. 错误!未定义书签。 . 硬件部主管岗位职责................................. 错误!未定义书签。 . 机械结构部主管岗位职责............................. 错误!未定义书签。 . 质量部主管岗位职责................................. 错误!未定义书签。 . 系统方案部主管岗位职责............................. 错误!未定义书签。 . 产品经理(项目经理)岗位职责......................... 错误!未定义书签。 5. 项目管理规范............................................. 错误!未定义书签。 . 项目流程概述....................................... 错误!未定义书签。 . 项目来源........................................... 错误!未定义书签。 . 立项............................................... 错误!未定义书签。 . 设计............................................... 错误!未定义书签。 . 实现............................................... 错误!未定义书签。 . 测试............................................... 错误!未定义书签。 . 发布............................................... 错误!未定义书签。 . 生产............................................... 错误!未定义书签。 . 实施细则........................................... 错误!未定义书签。 6. 资料管理规范............................................. 错误!未定义书签。 . 日常资料备份....................................... 错误!未定义书签。
运维技术研发管理规范 Company number：【WTUT-WT88Y-W8BBGB-BWYTT-19998】
目录
技术研发管理规范 第一章总则 第一条为规范运维技术和工具的预研和开发管理，有效提升公司运维服务能力，不断改进服务过程，为客户提供稳定、安全、高效运行的运维产品和工具，特制定本规范。 第二条本规范适用于在研发中心立项自研的运维系统项目和运维产品的设计和开发管理。第三方的运维系统项目和运维产品的集成技术管理，由事业部负责。 第三条本规范由研发中心负责解释和修订。 第二章技术研发经费管理 第四条技术研发经费管理原则 技术研发实行重视研发成本、促进研发进度、关注研发效益的经费管理原则，由集团财务部统一归口管理。 第五条技术研发经费管理职责 集团财务部负责建立研发经费管理制度，根据研发计划和费用预算，提前准备资金确保研发资金需求，同时有效监督研发经费的合理使用。研发中心负责按照研发计划制定并执行各项开发项目的研发预算，有效利用研发经费。 第六条技术研发预算管理 为规范集团的经营预算管理流程，提高预算管理的科学性，保证集团经营目标的实现，根据《公司法》等国家相关法律法规，结合《公司章程》，公司财务部制定了《经营预算管理制度》。 研发体系作为集团预算单位之一，对技术研发预算目标的实现承担经济责任，并享有相应的资源使用权，通过预算编制管理、预算执行管理和预算调整管理三个方面实施预算管理，其主要内容包括：编制和上报研发的经营预算草案，提供预算编制的各项基
础资料；严格执行下达的正式经营预算方案，在预算范围内开展经营活动；分解和落实研发预算指标，监督和保证研发预算得到执行；分析和报告研发预算执行情况；当发生特定情形时，提出经营预算调整申请；配合财务部做好各项预算管理工作；研发负责人对研发预算执行结果负责。 第七条技术研发核算管理 集团财务部为承担研发任务的研发中心设立台账归集核算研发费用，研发中心发生的各项开支均纳入研发费用管理。集团财务部协助研发中心做研发投入费用的预算编制和控制，对研发费用的入账方式进行规定，研发阶段的支出全部费用化，计入当期管理费，开发阶段的支出符合资本化条件的，按照财政部有关规定，确认无形资产；研发费用的纳税扣除，按照财政部、国家税务总局有关规定执行。集团每年在当年年度财务会计报告中，按照规定披露研发费用相关财务信息，包括研发费用支持规模及其占销售收入的比例，集中收付研发费用情况等。 第八条技术研发成本控制 技术研发成本主要包括研发物料成本、人力工资成本、差旅费用等，其中研发物料成本估算在技术研发项目任务书中体现，集团财务对项目成本进行控制、统计，同时，研发中心内部制定了《研发物料管理规定》和《关键物料导入管理规定》等规定，对研发物料成本实施监督管理；人力工资成本是技术研发成本的主要构成部分，即研发项目成本主要来源于项目实际工作量，通过项目管理对研发项目投入人工实施成本管理；差旅费用及其他费用按照集团财务部《借款和日常费用报销制度》和《研发中心费用管理制度》相关条款对费用执行进行监督和管理。 第三章技术研发环境管理
研发中心管理制度 公司图标 XX有限公司 20XX.xx.01
版本修订历史： 编写版本号日期 Xxx V1.00 20xx.03.01 Xxx V1.01 20xx.06.20 总经理批准：
目录 1前言 ---------------------------------------------------------------------------------------------------- 5 2指导思想 ---------------------------------------------------------------------------------------------- 5 2.1 制度建设----------------------------------------------------------------------------------------- 5 2.2 部门协作----------------------------------------------------------------------------------------- 6 2.3 队伍建设----------------------------------------------------------------------------------------- 6 2.4 环境建设----------------------------------------------------------------------------------------- 6 3建制及岗位责任 ------------------------------------------------------------------------------------- 7 3.1 建制 ----------------------------------------------------------------------------------------------- 7 3.2 研发中心职责----------------------------------------------------------------------------------- 7 3.3 岗位职责----------------------------------------------------------------------------------------- 8 3.3.1研发部部门经理 -------------------------------------------------------------------------- 8 3.3.2基础技术部部门经理 -------------------------------------------------------------------- 8 3.3.3数据库技术部部门经理 ---------------------------------------------------------------- 10 3.3.4质控部部门经理 ------------------------------------------------------------------------- 11 3.3.5项目经理/产品经理---------------------------------------------------------------------- 12 3.3.6架构师-------------------------------------------------------------------------------------- 13 3.3.7数据库管理员----------------------------------------------------------------------------- 14 3.3.8系统分析师-------------------------------------------------------------------------------- 15 3.3.9项目组长----------------------------------------------------------------------------------- 16 3.3.10高级程序员-------------------------------------------------------------------------------- 17 3.3.11程序员-------------------------------------------------------------------------------------- 18 3.3.12美工----------------------------------------------------------------------------------------- 19 3.3.13测试工程师-------------------------------------------------------------------------------- 20 3.3.14技术文案----------------------------------------------------------------------------------- 21 4日常管理程序 --------------------------------------------------------------------------------------- 22 5任务核定及考核 ------------------------------------------------------------------------------------ 22 5.1汇报------------------------------------------------------------------------------------------------- 22 5.1.1工作日志---------------------------------------------------------------------------------------- 22 5.1.2汇报 ---------------------------------------------------------------------------------------------- 23 5.2评价------------------------------------------------------------------------------------------------- 29 5.2.1评价项目组长---------------------------------------------------------------------------------- 29 5.2.2评价项目组成员------------------------------------------------------------------------------- 30 5.2.3评价项目经理---------------------------------------------------------------------------------- 31
Bug提交管理规范 修订历史
目录 1. BUG管理工具介绍 (3) 2. BUG定义 (3) 1. BUG分类 (3) 2. Bug等级 (3) 3. Bug状态 (4) 4. Bug优先级 (4) 3. BUG的生命周期 (4) 4. BUG管理规范 (5) 1) 项目的创建 (5) 项目名称及代号规范 (5) 项目的模块及版本划分规范 (5) 用户角色权限分配规范 (6) 2) BUG提交规范 (6) BUG的报告内容 (6) 主题，即BUG简要描述 (7) 严重程度选择 (7) 优先级选择 (8) 模块及版本选择 (8) 环境 (9) BUG详细描述 (9) 其他规范 (9) 3) BUG分配及处理 (10) BUG的分配 (10) BUG处理 (10) 4) BUG验证及关闭 (10)
1.BUG管理工具介绍 常用的BUG管理工具有JIRA、BugFree、Bugzilla、Mantis、XPWeb等。我们公司采用的是JIAR，JIRA是Atlassian公司出品的项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。 2.BUG定义 1.BUG分类 BUG 就是指系统存的各种缺陷，可以从很多角度对BUG进行分类。 1、从功能方面分，产生BUG的原因大体可以归结为以下四种： A.重复的功能； B.多余的功能； C.功能没有达到设计的要求； D.功能实现与设计要求不相符。 2、从易用性方面分，可以归结为三点： A.界面不美观，控件排列、格式不统一，焦点控制不合理或不全面； B.缺少帮助信息，或者帮助信息不完全； C.功能操作复杂，提示信息不合理，易产生歧义。 3、从安全性方面分，BUG可以划分为以下几类： A.数据有效性检测不合理； B.重要数据在传输中没有加密； C.缺少身份认证机制或认证不合理； D.数据产生缺乏随机性； E．网络安全性：开放端口、服务； F．系统日志、审计。 4、从可靠性方面分，BUG可划分为以下几类： A.数据存贮的可靠性； B.业务处理的可靠性； C．硬件可靠性：如打印机；D.应急处理措施； E．数据备份、恢复。 5、从性能方面考虑，BUG可划分为三种： A．并发量； B．吞吐量； C．响应时间。 6、从兼容性方面考虑，BUG有两种： A．硬件兼容性； B．软件兼容性。 7、从可维护性方面考虑，可划分为两种原因： A．可扩展性； B．方便升级。 2.Bug等级 BUG等级是根据BUG出现在系统中的严重程度来分的，主要定义如下5级： 1级——致命：系统重要功能无法正常使用，系统崩溃；系统设计存在重大隐患；导致用户利益受到重大损失。该级别需要程序员修改。 2级——严重：系统主要功能无法正常实现，系统业务受到严重影响；导致用户利益受到损失。该级别需要程序员修改。 3级——一般：系统次要功能无法实现；主要功能部分失效；系统业务受到影响；导致用户利益受到一定损失。该级别需求程序员修改。
密级：一般 拟定： 批准： 昆明康立信电子机械有限公司 技术研发中心[2006]系字第06号 技术研发中心保密管理办法为了加强技术信息、营销信息、生产信息、管理信息的监督、控制、管理、保密，特制定本办法。 一、技术信息保密管理办法 １技术信息的内容 技术信息指设计方案、思路、图纸、文件、资料、程序以及开发设计过程中形成的各种知识产权、记录、总结等。 ２适用范围 技术信息管理办法适用于技术研发中心所有科室及全体员工。 ３技术信息管理 １）传播途径管理 A 技术研发中心任何部门、任何人不得私自收集、存储、窃取其它人（部门）的技术信息，
也不能随意把技术信息交付、转告、复印、拷贝给与技术信息内容无关的人员； B 除职能部门以外，技术研发中心其它部门、个人不得把技术信息以任何方式向本公司以外的其它人员传递； C 新员工必须与公司签订《保密协议》后方可进行试用； D 员工离职时根据个人的工作性质及工作岗位，视重要程度签订《禁业协议》。 ２）职责与权限 A 技术信息持有人必须对该信息的完整性负责，并有义务跟踪信息的使用及传播情况，对于需要保密的信息，持有人必须对信息进行保密； B 任何人（部门）不得以保密为借口而拒绝工作之间的相互配合及资源共享； C 日常工作中，技术信息是否需要保密，一项重要原则就是看是否与工作有关，对于一件特定工作来说，与工作内容相关的人员（部门）之间必须相互配合、资源共享，而对无关的人员则实行保密； D 资料室及管理者由于工作性质的特殊性，往往持有较多技术信息，一方面必须对信息的完整性负责，同时必须对各项信息进行的保密。 ３）技术信息保密级别 A 绝密：保密级别中的最高级，是指最重要的公司秘密，泄露会使公司的权力和利益遭受特别严重的损害，一般针对公司经营管理决策； B 机密：机密是重要的公司秘密，泄露会使公司权益和利益遭到严重的损害，一般针对公司核心技术、重大营销策划等；
软件缺陷管理办法 1.目的 本文档定义了软件缺陷管理流程和相关规则，确保软件缺陷管理的系统性和规范性，以保证项目研发质量。 2.适用范围 适用于部门项目研发过程的缺陷管理，对各阶段的缺陷管理过程进行指导和规范。 3.定义 3.1 术语 缺陷（Defect）：存在于软件之中偏差，可被激活，以静态形式存在于软件内部。 Bug：缺陷一种表现形态，系统或程序存在的任何一种破坏正常运转能力的问题。 3.2 缺陷定义 （1）软件未达到需求规格说明书的功能； （2）软件出现了需求规格说明书指明不会出现的错误； （3）软件功能超出需求规格说明书的范围； （4）软件未达到需求规格说明书未指出但应达到的目标； （5）测试工程师认为软件难以理解、不易使用、运行速度慢，或者最终用户认为不好。 4.缺陷生命周期
4.1 缺陷生命周期图 4.2 缺陷状态说明 5. 缺陷处理过程 5.1 正常处理过程 （1）创建问题 在测试管理系统中，所有用户都可以创建新问题，包括需求问题和软件缺陷等。创建问题时，需要描述清楚，并选择正确的选项，详细请参考5.4和5.5。
（2）指派问题 创建问题时，创建者通常要指派给该项目开发负责人，再由其指派任务，或直接指派给相应模块的开发工程师。 如果指派人是错误的，或者需要他人确认或帮助，则可以重新指派给合适的工程师，写上相关备注。 （3）确认问题 通常开发工程师收到新问题后，需要分析和确认此问题是否为Bug。如果是Bug，则选择“确认状态”；如果认为非Bug，则注明原因并指派回创建者。 当创建者收到确认指派时，需要进行及时确认。如果同意为非bug，则及时关闭它；如果不同意，则需要注明理由并指派回相关工程师。 如果问题确认指派次数大于6次时，需要进入“争议处理”流程，详细请参考5.2。 （4）解决问题 此为开发工程师的主要职责，包括Bug的复现、修改和修改验证。 开发工程师需要及时对确认状态Bug进行分析和解决，并自己验证通过，则操作为解决状态，解决方案规则请参考5.4中解决方案定义部分，在缺陷管理系统中解决方案选择相应的选项，解决后系统将自动指派回给创建者。 如果Bug无法解决或修改影响比较大，可申请进入“延期解决”流程，请参考5.2中延期处理部分。 （5）验证问题 创建者需要及时对解决状态的Bug在对应版本上面进行验证。如果验证通过，则可关闭Bug；如果验证不通过，则激活此Bug，系统将自动指派回给解决者。
禅道Bug提交管理规范 修订历史
目录 目录 (2) 1. 目的 (3) 2. 禅道系统Bug流程图 (4) 3. Bug流程操作及其Bug相关信息解释 (5) 3.1.测试人员发现bug (5) 3.2.测试人员创建Bug (5) 3.3.开发人员设定Bug优先级别并确认Bug (7) 3.4.开发人员解决Bug (8) 3.5.测试人员验证Bug (9)
1.目的 本文档定义了bug管理流程及其bug相关信息内容。 本文档适用范围： ●本文档适用于新产品以及以后新产品的项目。原有项目的bug管理仍然用JIRA系 统进行管理。 ●本文档适用于新产品以及以后新产品的项目相关的测试人员和开发人员。
2. 禅道系统Bug流程图
3. Bug流程操作及其Bug相关信息解释 3.1.测试人员发现bug 3.2.测试人员创建Bug 测试人员登录禅道系统，创建Bug。Bug状态为激活（未确认） 创建Bug页面截图： 页面字段注释： 所属产品：选择发现Bug的产品，必填项。 所属模块：选择发现Bug的对应模块，必填项。 所属项目：选择测试所属的项目。必填项。 影响版本：选择发现bug的版本。必填项。 当前指派：选择指派的开发人员。必填项。 Bug标题：用简单明了的语句说明Bug内容，相当于BUG的中心语句。必填项。 在标题上注明bug出现的频率（稳定出现/经常出现/很少出现/出现一次）重新步骤：重现步骤格式如下。必填项。 [环境]：如果系统/浏览器信息不能够全部说明发现Bug的环境，需要在 重现步骤里详细描述环境信息，以便于开发定位和解决问题。 [步骤]：写明出现Bug的操作步骤，要求简单，去掉与Bug无关的步骤。 [结果]：写明操作的实际结果。
××××网络 产品版本管理规范[草稿]
目录 1. 引言..................................................... 错误!未定义书签。 . 目的............................................. 错误!未定义书签。 . 范围............................................. 错误!未定义书签。 . 术语定义......................................... 错误!未定义书签。 . 参考资料......................................... 错误!未定义书签。 . 版本控制记录..................................... 错误!未定义书签。 . 版本更新记录..................................... 错误!未定义书签。 2. 版本管理................................................. 错误!未定义书签。 . 版本标示方法..................................... 错误!未定义书签。 正式版本..................................... 错误!未定义书签。 . 目录结构......................................... 错误!未定义书签。 . 文档的存放....................................... 错误!未定义书签。 开发文档的存放............................... 错误!未定义书签。 源代码的存放................................. 错误!未定义书签。 SQL的语句存放............................... 错误!未定义书签。 发行文档的存放............................... 错误!未定义书签。 . 配置管理流程..................................... 错误!未定义书签。 . 权限控制的管理................................... 错误!未定义书签。 3. 更新管理................................................. 错误!未定义书签。 . 源程序的修改..................................... 错误!未定义书签。 . 版本升级......................................... 错误!未定义书签。 版本升级原则................................. 错误!未定义书签。 新版本发布................................... 错误!未定义书签。 . 文档的变更....................................... 错误!未定义书签。 4. 备份管理................................................. 错误!未定义书签。
BUG处理流程说明 一、B UG处理流程图： 流程描述： 1、测试人员发现bug提交给开发。 2、开发人员判断是否是bug。 3、如果是bug，进行修改，修改完成后更改bug状态为已解决。 4、如果不是bug，退回给测试人员并描述退回原因，或为设计如此，或为外部原因， 或者不能重现。
5、开发人员修改完成的bug，由测试人员进行验证，确认修改正确，关闭bug。 6、验证未通过的bug重新激活，开发人员继续修改，直至验证通过，关闭bug。 7、测试人员需要对开发人员退回的bug进行确认。 8、确认不是bug关闭。 9、如与开发人员意见不一致，认为是bug，需提交项目负责人仲裁。 10、项目负责人确认是bug由开发人员修改，不是bug由测试人员关闭。 注：除提交项目负责人仲裁环节外，其他环节都可以在禅道上完成。 二、各角色应关注的状态 1.开发人员：激活、重新打开 激活：开发人员要对处于激活状态的bug进行处理，处理后将其状态置成“已解 决”、“设计如此”、“无法重现”、“外部原因”、“重复bug”或“延期处理”。 重新打开：重新打开的bug是已解决的bug经过测试人员验证，未修改正确，需 要继续修改。 2.测试人员：已解决、无法重现、设计如此、外部原因、延期处理 已解决：测试人员发现状态为“已解决”的BUG，要及时验证，如果确实已解 决，要将其置为“关闭”。否则“重新打开” 无法重现：测试人员发现状态为“无法重现”的BUG，要及时修改，把步骤描 述清楚，并将其状态置为“重新打开”。 设计如此：测试人员发现状态为“设计如此”和“外部原因”的BUG，要及时 通知项目经理，由项目经理来决定是否修改；对“延期处理”的问题要进行定期 跟踪，如发现问题没有按注释进行修改要及时通知开发人员或汇报给相关负责 人。 3.项目经理：设计如此、外部原因、延期处理 设计如此：因为这些BUG都是测试人员和开发人员有争议的BUG，因此项目经 理必须及时关注这些BUG，及时给出合理的定夺，如果不需修改把状态置成“关 闭”，如果需要立刻解决置成“重新打开”，否则置成“以后解决”。同时，项目 经理也要关注“延期处理”的BUG，以免其被漏掉或遗忘从而影响到项目上线。 三、缺陷严重级别及类型定义 ◆致命错误包括： 1．造成系统崩溃、死机 2．造成程序非法退出、死循环、通讯中断或异常 ◆严重错误包括：
xxxxxxxxxxxxxxxxxxxxxxxxxx 测试组BUG管理规范
版本历史
目录 1BUG管理工具介绍 (3) 2BUG定义 (3) 2.1BUG分类 (3) 2.2Bug 等级 (4) 2.3Bug 状态 (4) 2.4Bug优先级 (5) 3BUG的生命周期 (5) 4BUG管理规范 (6) 4.1项目的创建 (6) 4.1.1项目名称及代号规范 (7) 4.1.2项目的模块及版本划分规范 (7) 4.1.3用户角色权限分配规范 (7) 4.2BUG提交规范 (7) 4.2.1BUG 的报告内容 (8) 4.2.2问题类型选择 (9) 4.2.3BUG 简要描述 (11) 4.2.4优先级选择 (11) 4.2.5模块及版本选择 (11) 4.2.6BUG 详细描述 (11) 4.2.7其他规范 (12) 4.3BUG分配及处理 (12) 4.3.1BUG 的分配 (12) 4.3.2BUG 处理 (13) 4.4BUG验证及关闭 (13)
1 BUG管理工具介绍 常用的BUG 管理工具有JIRA、BugFree、Bugzilla、Mantis、XPWeb 等。我们公司采用的是 JIAR ，JIRA 是Atlassian 公司出品的项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。 2 BUG定义 2.1BUG分类 BUG 就是指系统存的各种缺陷，可以从很多角度对BUG 进行分类。 1、从功能方面分，产生BUG 的原因大体可以归结为以下四种： A.重复的功能； B.多余的功能； C.功能没有达到设计的要求； D.功能实现与设计要求不相符。 2、从易用性方面分，可以归结为三点： A. 界面不美观，控件排列、格式不统一，焦点控制不合理或不全面； B .缺少帮助信息，或者帮助信息不完全； C.功能操作复杂，提示信息不合理，易产生歧义。 3、从安全性方面分，BUG 可以划分为以下几类： A.数据有效性检测不合理； B.重要数据在传输中没有加密； C.缺少身份认证机制或认证不合理； D.数据产生缺乏随机性； E.网络安全性：开放端口、服务； F.系统日志、审计。 4、从可靠性方面分，BUG 可划分为以下几类： A.数据存贮的可靠性； B.业务处理的可靠性； C.硬件可靠性：如打印机； D.应急处理措施； E.数据备份、恢复。 5、从性能方面考虑，BUG 可划分为三种： A .并发量； B .吞吐量； C .响应时间。