精华内容
下载资源
问答
  • bug管理规范

    2018-04-17 15:36:22
    bug管理规范一、概述本规范是常规的bug管理流程,适用于项目过程中的bug管理 二、BUG周期 三、Bug的分类、状态、级别 3.1 bug分类功能 A.重复的功能;B.多余的功能;C.功能没有达到设计的要求;D.功能实现与设计...

    一、概述

    本规范是常规的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的严重级别定义:

     

    严重等级
    描述
    对应的优先级
    S严重影响用户使用,且需要立即修复的线上bug,通常对应A、B级的线上bugP1
    A软件崩溃、严重丢失数据或严重的内存泄露P1
    B功能没有实现,主流程bugP1
    C一般的错误,普通的 bugP2
    D轻微的错误,不至于影响软件的使用,而且应该很容易解决P3

     

    BUG优先级定义:

     

    优先级
    描述
    备注
    P1需要马上修复的bug。 
    P2应该尽快修复的bug,但不是很急 
    P3可以以后修复的bug 

     

     四bug描述规范

    bug描述要简洁明了,方便开发人员重现和后续跟踪。
    版本:当前测试的版本号
    平台:测试使用的平台说明
    摘要:概要描述问题。 
    描述:应该描述问题发现的步骤、期望结果和实际结果
    描述可分为“步骤”、“结果”(含:期望结果、实际结果)、“补充说明”三部分,各部分之间用空行隔开。“补充说明”部分可根据实际情况选择是否需要描述。具体格式如下:
    步骤:

    期望结果:
    实际结果:

    补充说明:

    1. 如果多处出现类似问题,应描述出现该问题的所有模块或界面。
    2. 如果不可重现,应说明
      附件:添加错误附图或错误信息。
    展开全文
  • BUG管理规范BUG管理规范BUG管理规范BUG管理规范BUG管理规范BUG管理规范BUG管理规范BUG管理规范BUG管理规范
  • Bug管理规范及流程

    2018-09-03 17:12:12
    Bug管理规范及流程:整理测试流程,bug提交规范,bug属性定义
  • BUG管理规范

    2009-11-09 11:01:00
    合理的bug流程管理有助于提高整个项目的效率与质量,首先我先介结一下BUG相关概念。 一、BUG分类BUG 就是指系统存的各种缺陷,可以从很多角度对BUG进行分类。1.从功能方面分,产生BUG的原因大体可以归结为以下四种...

     合理的bug流程管理有助于提高整个项目的效率与质量,首先我先介结一下BUG相关概念。

     

    一、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.方便升级。

    二、Bug等级

        BUG等级是根据BUG出现在系统中的严重程度来分的,主要定义如下5级:

    1级——轻微的(Low):不影响正常使用,轻微、微小的问题,对功能几乎没有影响,产品及属性仍可使用,如有个错别字。修改优先级为低,该级别建议程序员修改。

    2级——一般的(Medium):系统能够正常使用,但有潜在风险;系统业务受到轻微影响。如提示信息不完整。该级别需要程序员修改。

    3级——较高的(High):系统次要功能无法实现;主要功能部分失效;系统业务受到影响;导致用户利益受到一定损失。该级别需求程序员修改。

    4级——严重的(Very High):系统主要功能无法正常实现,系统业务受到严重影响;导致用户利益受到损失。该级别需要程序员修改。

    5级——致命的(Fatal):系统重要功能无法正常使用,系统崩溃;系统设计存在重大隐患;导致用户利益受到重大损失。该级别需要程序员修改。

    三、Bug状态

          BUG状态标记BUG当前所处的状态,是用来处理BUG流程的主要参数,我们QC缺陷管理平台有以下一些状态:

    新增(New):测试人员新发现的系统Bug

    打开(Open):测试人员通知开发人员需要修改的BUG

    修改(Modify:开发人员正在修改的BUG

    固定(Fixed:开发人员通知测试人员已修复的BUG

    跟踪(Trace:测试人员短时间内很难确定是否已经修复的BUG

    已关闭(Close:测试人员经回归测试后确定已修复的BUG

    已否决(Rejected:被开发人员否决了的BUG

    重新打开(Reopen):Bug未被修复,重新出现在新的测试版本中;

    延迟修改(Wait):因为种种原因需要等待延期修复的Bug

    四、Bug优先级

    1级——建议的:建议修改,对应bug等级为1级轻微的;

    2级——一般的:需要修改,对应bug等级为2级一般的和3级较高的;

    3级——高等的:重点修改,对应bug等级为4级严重的;

    4级——紧急的:立即修改,对应bug等级为5级致命的。

    五、BUG处理流程

    1.测试人员添加BUGQC平台,初始状态为新建,测试员会把状态置为打开状态,通知开发人员修改;

    2.开发人员双击自己负责的BUG,状态置为修改’,修改好BUG后在注释框内加以说明,填上修复日期,把缺陷状态置为固定状态;

    若开发人员觉得没必要改,就把状态置为已否决

    3.测试人员看到固定状态的BUG会进行验收测试,通过后就把状态置为已关闭状态;若验收不通过则状态置为重新打开

    4.对被置为已否决状态的BUG,测试人员与开发人员协商后同意关闭,则置为已关闭;若测试人员不同意关闭则提交到项目负责人处,由他来决定是否要修改;

    若要修改,则把BUG状态置为‘重新打开’ ,然后开发人员继续修改;若不用再修改则置为‘已关闭’;若延期处理则置为‘延迟修改’。

     5.到能够修改这个BUG的时候,开发人员再置为‘修改’,进行修复。

     

    展开全文
  • 7. Bug管理规范

    2019-09-06 12:33:49
    1. Bug状态管理 状态 描述 备注 Active 测试人员发现bug并提交,待修改状态。 Bug初始状态 Resolved 开发人员修改完bugbug变更为已解决状态。 Bug中间态 Closed 测试人员回归通过,变更为已通过状态。...

    1. Bug状态管理

    状态 描述 备注
    Active 测试人员发现bug并提交,待修改状态。 Bug初始状态
    Resolved 开发人员修改完bug,bug变更为已解决状态。 Bug中间态
    Closed 测试人员回归通过,变更为已通过状态。 Bug完成态
    Postpone 经确认不需要在本次发布范围之内修改,变更为推迟修改状态/挂起状态。 Bug中间态
    Rejected 开发人员确认不是bug,变更为非bug状态。 Bug中间态
    Obsolete 重复和非bug的,经过测试人员确认后,变更为废弃状态。 Bug完成态

    2. Bug生命周期流转

    Resolve
    Fail
    Pass
    Not a bug/Duplicated
    Confirm
    Active
    Resolved
    Closed
    Rejected
    Obsolete
    Postpone

    3. Bug等级与优先级

    • Bug等级与优先级的定义

      Bug严重程度 描述 优先级与紧急程度
      P1,致命的 阻塞测试、引起系统崩溃、其他功能不可用和造成数据丢失等缺陷。 最高优先级,紧急,必须立即解决(可以设定时间标准,比如必须2小时内解决,供参考)。
      P2,严重的 主要功能未实现、未达标、不可用,可能还会引起其他部分功能失效。 高优先级,紧急,需要尽快解决。
      P3,一般的 一般的缺陷,不影响主要功能和流程的实现。 一般优先级,不紧急。
      P4,提示的 优化建议,最好修改,但不是必须的,不影响上线发布;或者是本轮挂起的,但是后面再修改的。 低优先级,可以暂不处理。

    4. Bug类型

    • 从测试类型上来分:功能性缺陷、性能缺陷、易用性缺陷、安全性缺陷等;

    • 从缺陷引发的阶段类型来分:需求缺陷、设计缺陷、编码缺陷、环境问题、数据配置问题、测试操作问题等。

      Bug类型的归类,是质量分析的重要参照物,可以根据当前项目质量分析的程度,来决定要不要启用。

    5. Bug提报规范

    1. Bug提报原则

      • 规范问题单提报的目的,是为了提高问题处理效率。
      • 所有问题都要提单,有条件重现,无规律重现,难重现的一样提单。
      • 问题出现需要先定位,抓包、日志、数据库、截图。
      • 问题初步定位后,及时提单,避免遗忘,也给开发留有充足的时间修复。
      • P1级别Bug及时通知开发,尽快修正,避免阻塞其他测试。
      • 其他级别的Bug直接跟踪,不需要挨个确认。
      • 低级别bug(文字符号、提示信息等)可以汇总一起提个单,在描述中分条目列出;这种情况要跟开发说清楚,避免看bug时遗漏
    2. Bug提报格式

      • 项目
      • 主题:【xx需求】xxx问题
      • 报告人
      • 描述
        • 【预置条件】
        • 【测试步骤】
        • 【期望结果】
        • 【实际结果】
        • 【问题描述】
        • 【截图】
        • 【日志】
      • 经办人
      • Epic Link
      • Sprint
      • bug状态
      • Bug优先级
      • Release to
    3. Bug信息填写规范

      • 项目:Bug归属的项目组

      • 主题:简明扼要地描述是什么问题,归属哪个业务

      • 详细描述:

        • 测试步骤/问题描述:
          • 对于简单的问题,简明扼要地描述测试步骤或直接描述问题;
          • 对于复杂的问题,需要细化测试步骤、预期结果和实际结果,以便开发人员能更好的理解问题。
        • 测试数据:提供测试数据,以便开发人员可以重现问题。
        • 截图/日志:有截图提供截图,有日志提供日志,截图和日志可以帮助开发人员花较少的时间来定位问题。
        • 问题分析:测试人员通过抓包、日志、检查数据库等工具和手段来初步定位出问题,主要目的是帮助开发人员快速定位出问题。(实际情况下,测试人员一方面要培养自己定位问题的能力,另一方面也要合理安排自己的测试进度,避免出现死磕一个问题,而影响整体测试进度的情况。)
      • 报告人:bug提出人

      • 经办人:开发对象

      • Bug优先级(严重等级):

        Bug优先级(严重等级) 描述 紧急程度
        致命P1 阻塞测试、引起系统崩溃、其他功能不可用和造成数据丢失等缺陷; 紧急,需要立即解决
        严重P2 主要功能未实现、未达标、不可用,可能还会引起其他部分功能失效; 紧急,尽快解决
        一般P3 一般的缺陷,不影响主要功能和流程的实现; 一般
        提示P4 优化建议,最好修改,但不是必须的,不影响上线发布。 不紧急
      • Bug状态:

        Bug状态 描述
        Active 测试人员发现bug并提交,待修改状态。
        Resolved 开发人员修改完bug,bug变更为已解决状态,可验证。
        Closed 测试人员回归通过,变更为已通过状态。
        Obsoleted 重复和非bug的,经过测试人员确认后,变更为废弃状态。
      • Sprint:当前的迭代信息。

      • Epic:项目有Epic时,关联相应的Epic,方便统计。

      • Release to:没有Epic时,关联story,方便统计。

    6. Bug管理与跟踪

    1. Bug的解决时效根据优先级来跟踪。
    2. Bug的状态需要及时更新。
    3. 原则上,有未解决的Bug不能发版,需要经过项目经理、开发测试leader和产品一起评估后,才能决定是否将Bug挂起。
    4. 挂起的Bug要在迭代结束后确认好解决版本,并修改相应信息。
    展开全文
  • bug管理规范及流程

    万次阅读 2017-02-16 13:46:20
    本文档定义bug的整个生命周期,规范bug的解决方案及管理流程。Bug在流转的过程中有章可循。 规范bug严重等级与bug解决优先级,使开发人员与测试人员能根据此文档准确判断bug的严重程度并加以解决; 2 关键角色及...

    1      概述

    本文档定义bug的整个生命周期,规范bug的解决方案及管理流程。Bug在流转的过程中有章可循。 规范bug严重等级与bug解决优先级,使开发人员与测试人员能根据此文档准确判断bug的严重程度并加以解决;


    2     关键角色及职责

    角色

    职责

    测试工程师

    1. 根据规范提交bug;

    2. 及时验证bug是否已解决;

    3. 及时关注开发拒绝bug,和相关人员沟通讨论解决方式;

    测试经理

    1. 审核测试工程师提交的bug;

    2. 定期review bug,报告现状,并给出解决意见;

    开发工程师

    1. 以优先级为依据分析解决bug

    开发主管

    1. 定期 review bug,对bug多的模块加强code review和单元测试;

    2. 分析bug解决进度,对产品质量及进度进行风险评估;

    产品

    1、当开发和测试存在意见分歧时,进行需求确认

    2、从产品角度划分bug修改的优先级;

     

      

    3     Bug生命周期

     

     


     

    4     Bug书写规范

    4.1 主题

    1)   以一个简短的句子描述某个模块存在的问题;或者某个操作导致了什么问题;

    2)   描述问题时要简练、直接切入主题,但是要抓住要点;

    3)   偶现bug在主题前标注出现的次数;

    4)   有些模块功能比较多,可以在主题描述前标注上具体得操作;

    示例:

         【偶现3次】【账号切换】登录非本机手机号,切换回本机号码登录后,收不到消息

         【偶现2次】添加载体库时程序停止运行

     

    4.2描述

      说明区域包括:步骤、预计结果、实际结果、测试环境、bug出现时间、截图、日志

    1)   用数字编号,一步步的描述问题的重现步骤;

    2)   不同的操作步骤产生不同的问题,需分别报bug;尽量做到一个bug汇报一个问题;

    3)   偶现问题必须明确bug出现的时间、提供截图以及日志;

    5     Bug解决方案

    当天提交的新建状态bug,对应的开发人员需在2天内全部审核一遍,将bug分成以下3类:拒绝、进行中、延期、反馈(给产品);

     

    开发已修复的bug:将bug状态置为已解决;同时添加说明验证版本号、错误原因、解决办法;

    示例:

         验证版本:V1.0.1.1101(1101表示在11月1号可以验证)
             
    问题原因:未作条件判断
             
    解决方法:进行合理边界判断

     

    开发认为不是bug:将bug状态置为已拒绝;指派给bug提出者;同时注明拒绝理由;

    示例:

          参考XXX设计,测试人员理解错误;

     

    bug缺乏必要的信息:bug状态置为已拒绝;指派给bug提出者;同时注明拒绝理由;

    示例:

          缺少必须日志;

     

    开发已修复,测试验证通过的bug将bug状态置为已解决,并注明通过版本号;

    示例:

         V1.0.1.1103验证通过

     

    开发已修复,测试验证不通过的bug:将bug状态置为打回,并根据实际情况注明反馈理由;

    示例:

         V1.0.1.1103版本验证此问题仍然存在;

         步骤:XXX

         出现时间:XXX

         测试环境:XXX

         截图、日志;

     

    测试、开发有争议的bug:将跟踪类别置为需求,状态置为反馈;指派给对应产品,进行讨论确认修改方案;并注明反馈理由;

    示例:

         测试认为ip地址设置错误,应该提示用户,而不应该程序出现停止运行;

     

    无法修复的bug:将bug状态修改为公认,并注明公认理由;

     

    无法重现的bug:主要依赖日志分析问题原因,然后进行对应的修改;开发修改后,测试追溯3个版本、或者使用测试工具反复测试,如没有重现则先关闭;并注明关闭版本号;

    示例:

         V1.0.1.1103暂未复现,先关闭;

     

    需延期的bug:将bug状态修改为低,计划完成日期修改为计划解决bug的日期;并注明延期理由;

    示例:

         需求变更,改动量很大,影响版本发布时间;

     

    产品确认需要修改的bug:将bug状态修改为打回,指派给对应的开发人员,并注明修改内容;

     

    产品确认不需要修改的bug:将bug状态修改为已解决,并注明不需要修改原因;

     

    不是本端的bug:由bug所在端(本端)人员给出分析说明,转给对应端和开发人员,并口头通知;

     

    6     Bug跟踪类别

    bug:测试人员判定为bug的问题;

    优化:功能已实现,需要做性能优化的问题;

    建议:测试对于产品的一些改进建议;

    需求:需要产品重新梳理的需求问题;


    7     Bug状态

    新建:测试人员新提交的bug、优化或者建议的问题状态;

    进行中:开发人员已确认是bug,需要修改的问题状态;

    已解决:开发人员已修复的问题状态;

    已关闭:测试验证,确定已解决的问题状态;

    已拒绝:开发认为不是bug,拒绝给测试的问题状态;

    反馈:反馈给产品确认的问题状态;

    公认:确认是bug,但是无法解决的问题状态;

    打回:测试验证已解决bug,仍然没有修复的问题状态;

     

    8     Bug严重程度

    致命:不能执行正常的功能操作,或者因产品原因导致系统死机,需马上修复的问题

    示例:

           程序无法启动,或者登录;

           程序崩溃、停止运行,系统死机,无法进行下一步的操作

               

    严重:部分功能存在严重缺陷,尚可继续测试,不影响产品稳定性;

    示例:

          偶现的程序崩溃、停止运行

          功能未实现

          数据不同步

          功能错误,无法进行后续操作

    一般:次要功能或者界面存在的一些错误,不影响正常测试;

    示例:

          界面UI显示和效果图不一致;

          提示语不正确;

          错别字;

          查询结果显示错误

     

    建议:测试对于产品的一些改进建议;


    9     Bug优先级

    低:对产品的影响比较小,在时间不允许的情况下可以暂时不修改;

    中:必须修改,不一定马上修改,需讨论确定在某个特定的里程碑前修改完;

    高:必须在版本发布之前修改完;

    紧急:影响测试,需立即或者下一个版本修复;

    10  其他注意事项

    1)   开发人员没有关闭bug的权限,所有问题均需经过测试验证无误后才可关闭;

    2)   开发、测试双方有争议的bug,必须经过产品的确认才可进行下一步的操作;

    3)   测试需及时验证已修复bug;

    4)   产品人员可以根据产品的阶段性需求重新分配bug解决的优先级;

    5)   重新指派bug后,需要口头或者QQ告知对方;

    6)   bug的优先级划分比较重要;

    展开全文
  • 请正视bug管理规范

    2017-08-25 11:03:28
      bug状态流转示意图     bug状态变迁及操作规则示意图    
  • 软件测试Bug管理规范

    2020-11-13 21:07:25
    本文档定义bug的整个生命周期,规范bug管理流程。Bug在流转的过程中有章可循。规范bug严重等级与bug解决优先级,使开发人员与测试人员能根据此文档准确判断bug的严重程度并加以解决。 适用范围 本文档适用项目...
  • BUG管理规范 BUG管理规范 BUG管理规范 BUG管理规范 BUG管理规范 BUG管理规范
  • BUG提交和管理规范

    千次阅读 2018-06-27 22:14:24
    在测试理论基础面试,...这是之前给团队定的的BUG提交和BUG管理规范,供参考。 BUG提交规范 【所属功能】bug出现的功能模块,比如个人中心。 【主题】一句话描述问题产生的模块、现象、错误现象及正确结果。...
  • 禅道Bug提交管理规范

    2019-01-23 15:41:42
    禅道Bug提交管理规范 测试流程管理。 本文档定义了bug管理流程及其bug相关信息内容。
  • BUG管理流程规范.doc

    2019-09-03 13:42:46
    开发、需求、测试在执行测试阶段对bug处理相互间形成良好的沟通,对bug管理形成统一的规范,保证bug有效快速的被修复,保证相互间工作正常进行,提供参考文档
  • 1.禅道简介 禅道是一个基于“敏捷开发”模式的软件开发全生命周期管理软件,在国内的...2.Bug管理规范 2.1角色及人员 一般来说,禅道用于需求/Bug管理方面,在用户角色上,是分为这么几个角色: 1、公司/部门管...
  • BUG描述规范管理

    2018-01-08 11:18:00
    BUG:软件系统中存在的可能导致系统出错、失效、死机等问题的错误或缺陷。 描述一个缺陷,需要以下核心要素 标题:用简洁的话描述该缺陷,主要让开发知道这是一个什么样的缺陷 参数设置:Bug的类型(功能/性能/...
  • 测试BUG流程管理规范

    2016-07-20 09:32:05
    BUG单描述模板,开发和测试工作配合流程。
  • bug提交及管理规范

    2015-08-31 15:28:50
    bug提交规范 缺陷概述,缺陷操作步骤,预期结果,实际结果,已解决,已关闭,重新打开
  • 测试规范-Bug管理(文档) 测试规范-Bug管理(文档)
  • 缺陷管理流程图是为了有效的跟踪,管理bug的处理情况,指导测试团队和开发人员有效的处理相关的bug。 不同角色的人,对bug处理的权限不一样,我们需要借助类似缺陷管理工具比如:QC进行实施。下面就不同角色的人...
  • bug规范

    千次阅读 2009-02-19 10:56:00
    以前对新员工写的一份BUG提交规范,可以写的比较随意化,口头语太多,我们用的缺陷管理工具是JIRA。 1,BUG全部提交到http://XXX.XXX.XXX.XXXBUG论坛上 2,创建的问题的时候,“概要”--用简单明了的语句说...
  • bug管理

    2019-09-20 16:18:47
    BUG提交规范 1、标题 2、步骤描述 ①、步骤使用序号编排 ②、在特定情况下发生的问题,还需提供准确的前提条件 ③、精准的描述bug产生的路径后,再描述现象 如: >打开客户端进行首页->点击“我的...
  • bug处理流程规范

    2021-04-15 16:27:10
    本文档定义bug的整个生命周期,规范bug的解决方案及管理流程。Bug在流转的过程中有章可循。规范bug严重等级与bug解决优先级,使开发人员与测试人员能根据此文档准确判断bug的严重程度并加以解决; 2关键角色及职责...
  • bug类型划分 bug类型 内容说明 备注 功能缺陷 1.程序功能无法实现2.程序功能实现错误 ...1.操作界面错误2....界面不规范   系统缺陷 1.由于程序引起...
  • BUG描述语言规范

    2014-03-19 11:07:38
    规范测试BUG描述,对于初学者比较有好处,规范管理BUG,增加,删除,查询,修改的操作都是有帮助的
  • 1 BUG严重程度   严重程度 描述 Blocker 系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常 退出、无法测试、造成系统不稳定。 Cratical 影响系统功能或操作,...
  • bug规范初稿

    2017-06-13 20:32:31
    一、背景 bug是开发和测试质量的重要指标,从bug数量、严重性等可以看出RD的开发质量,从发现问题的阶段...各端都将bug管理工作迁移到效率云,正好可以在客户端各端建立统一的规则,既便于各端的质量分析,又便于横向

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 741
精华内容 296
关键字:

bug管理规范