精华内容
下载资源
问答
  • 禅道Bug提交管理规范

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

    千次阅读 2020-07-29 11:43:31
    一、BUG提交规范 目前所使用的JIRA系统中,BUG的内容主要包括以下要素: 元素 说明 缺陷ID BUG的唯一标示,由JIRA自动生成 项目名称 每个要测试的软件项目都有唯一的名称 问题类型 选择是BUG还是新功能...

    一、BUG提交规范

    目前所使用的JIRA系统中,BUG的内容主要包括以下要素:

    元素说明
    缺陷IDBUG的唯一标示,由JIRA自动生成
    项目名称每个要测试的软件项目都有唯一的名称
    问题类型选择是BUG还是新功能,子任务等
    主题简明的对BUG进行概要描述
    严重程度BUG的严重程度
    优先级BUG解决的优先级
    到期日BUG需要处理的截止日期
    模块BUG所属的组织模块
    影响版本产生BUG的版本号
    解决版本解决BUG的版本号
    分配人需要指派处理的人员,如不清楚统一给项目负责人
    报告人报告BUG的人员
    环境描述当前测试的软硬件环境
    描述在详细描述中,可对BUG产生的前提条件、操作步骤、实际结果、预期结果等进行描述
    附件提交BUG时,可上传必要的附件。(截图,日志等)

    具体提交规范如下:

    1. 现象描述

    详细描述BUG的现象;

    2. 测试环境

    说明发现BUG的测试环境;

    3. 前提条件

    详细描述BUG产生的前提条件。例如浏览器,操作系统,移动设备组件版本,软件版本等;

    4. 操作步骤

    详细描述发现BUG的操作步骤;

    5. 期望结果

    描述预期正确的结果;

    6. 实际结果

    描述实际不正确的结果;

    7. BUG严重性等级

    初步判定BUG的严重性等级;

    8. BUG优先级

    判定BUG被修复的优先级别;

    9. 附件

    包括:BUG现象截图、操作产生的系统日志等;

    注:严重等级以上BUG必须带有附件,一般性BUG则附件可选。

    10. 备注

    BUG补充说明信息,如:测试分析意见、其它设备有无类似情况等;

    附BUG提交范例:

    【前提条件】

    操作系统:Win7

    浏览器:IE10,Firefox 47.0.1

    【操作步骤】

    1. 首页,点击“我要注册”;
      
    2. 打开注册页面,输入未注册过的手机号和密码
      
    3. 点击 注册按钮;
      

    【实际结果】

    注册不成功,停留在当前页面

    【预期结果】

    注册成功,跳转至首页

    二、BUG提交注意事项

    1. 测试人员提交新缺陷时,尽量用最简洁的语言最清晰的描述出BUG的出处、操作步骤、现象、(建议),并尽量截图;

    2. 当你的BUG报告以“不可重现”打回给你时,测试人员应该反复阅读它,集中剔除那些没有关系的步骤或词语,再检查是否有遗漏或清晰的步骤,再去找研发人员。

    3. 测试人员在精简空话的同时,应该再仔细检查报告是否会产生误解的地方。测试人员应该尽量避免使用模糊的,会产生歧义的、主观的词语。目标是使用能够表述事实、清楚的,不会产生争执的词语;

    4. 不要使用感叹号或其它表现个人感情色彩的词语或符号;

    5. 不要使用含糊的词语(例如,好像,似乎)或网络语言来描述发现的现象;

    三、Bug的类型

    1. 文档缺陷:术语不一致,文档缺失,不易理解等;

    2. 设计缺陷:需求不明确,操作便捷性等;

    3. 配置缺陷:安装部署不成功,配置文件错误等;

    4. UI 缺陷:风格不一致,界面不友好等;

    5. 数据校验:数据长度,类型缺失校验;

    6. 查询统计:查询结果列表异常等;

    7. 功能缺陷:功能不可用;

    8. 可靠性 :用户权限错误等;

    9. 性能缺陷:查询性能,并发处理等;

    10. 流程缺陷:流程不能流转,流程错误结束等;

    11. 语言质量:字符未本地化,标点符号,商标符号错误;

    12. 用户互动:与使用者互动不良;

    四、Bug的等级划分

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

    1. 致命BUG,包括以下各种错误:

    1.1 由于程序所引起的死机,非法退出

    1.2 死循环

    1.3 导致数据库发生死锁

    1.4 因错误操作导致的程序中断

    1.5 严重的数值计算错误

    2.严重BUG,包括以下各种错误:

    2.1 功能不符

    2.2 数据流错误

    2.3 程序接口错误

    2.4 轻微的数值计算错误

    3.重要BUG,包括以下各种错误:

    3.1 操作界面错误

    3.2 打印内容、格式错误

    3.3 简单的输入限制未放在前台进行控制

    3.4 删除操作未给出提示

    4.轻微BUG,包括以下各种错误:

    4.1 界面不规范

    4.2 辅助说明描述不清楚

    4.3 显示格式不规范

    4.4 长时间操作未给用户进度提示

    4.5 提示窗口文字未采用行业术语

    4.6 可输入区域和只读区域没有明显的区分标志

    4.7 系统处理未优化

    5.微小BUG:

    5.1 界面重构、描述更改、流程改进

    五、 Bug优先级划分

    危机:要求立即修改,作为修改最高等级;

    紧急:要求重点修改,产品发布前必须修复;

    中等:需要尽快进行修改,产品发布前必须修复;

    尽快:需要修改,如果时间允许应该修改;

    不急:可能要修复,时间空余情况下进行修改。

    六、其他注意事项

    当发现一个BUG时,请注意下面的问题:

    1. 同一软件中的相似功能是否有相同的问题?

    2. 其他的浏览器是否有相同的问题?

    3. 其他的软硬件配置是否有相同的问题?

    4. 其他的区域是否有相同的问题?

    5. 以前的版本是否有相同的问题?

    展开全文
  • bug时的注意事项 (1) 发现一个问题时,不必急着提交,可以先做验证(包括复现、对比测试等)进行证实, 看是概率性问题还是每次必现的问题,需要时也应使用不同版本不同机器做对比验证,当然,如果已经很确信是一...

    交bug时的注意事项

    (1) 发现一个问题时,不必急着提交,可以先做验证(包括复现、对比测试等)进行证实,

    看是概率性问题还是每次必现的问题,需要时也应使用不同版本不同机器做对比验证,当然,如果已经很确信是一个bug了,也就不用浪费时间去对比验证了。

    (2) 描述要清晰、准确,不要使用含糊的词语(例如,好像,似乎)来描述发现的现象。

    关于这点,如测试某款软件时,提交一个bug描述为“软件帮助说明中好像有错别字”,并没有说出哪一页哪一行以及具体哪个字错了,应该修改成什么样的。因此就不能说是个好的描述。

    (3) 要考虑开发人员的感受,有些问题尤其是有些主观性比较强的问题,在问题描述

    中一般不要出现带强烈感情色彩的词语标点符号,如“要求”、“必须”和感叹号等(特殊情况除外)。在提交此类问题时可以使用一些诸如“建议……”、“希望……”、“请……”之类比较委婉些的词语。

    (4) 不能确认一个现象是不是一个bug的时候可以向其他人或者开发人员进行确认,

    然后再去提交。

    (5) 概率性的问题,测试过程中难免遇到一些概率性问题,很难找出其产生的规律,

    甚至该问题在测试过程中只出现一次,对于此类问题也一定要提交,并补充说明无法复现或者无规律。

    (6) 描述问题时,要实事求是,不要夸大,比如概率性问题,本来出现的概率只有10%,

    你把它写成50%都是不应该的。

    (7) 提交bug时,应该在描述清楚问题点的时候把正确的预期输出结果写明,即正确

    的结果应该是什么样的,这点很重要。现在我们提交的bug中有些测试和开发双方都知道该修改成什么样子了,而在bug描述中未写出修改成什么样子的,如“来电时按挂机键不能拒接来电”这样描述一个bug,并没有写明该如何修改,一般这样描述大家一看就知道该如何修改,所以写不写预期正确结果大家都可以接受。但对于有些bug的描述一定要把预期的正确结果给写进去,否则开发人员会无所适从,不知道该修改成什么样子的。

    (8) 很多时候,提交的bug都需要重现,而有的bug是在测试过程中偶然间发现的,

    时间一长,会对发现bug时的特定数据或环境模糊,导致不能重现bug。所以提交bug时描述的越详细越好。如果语言文字难以清楚的描述出发现的问题,最好能附件图片或者log记录等做辅助说明。

    (9) 提交测试bug的时候,如果该问题在某一特定环境下才能出现,一定要将该问题

    产生的环境(硬件、软件)描述清楚。

    (10) 提交问题前要清楚的知道软件需求、规格定义。相信很多人都遇到过这样的尴尬

    情况,提交了一个重要问题后,却被告知其实那并不是一个问题,软件就是那样设计的或者需求就要求那样处理的。

    (11) 有些问题出现了,不一定就是我们测试软件本身的问题,也可能是其他一些问题

    展开全文
  • 提交Bug的标准及书写规范

    千次阅读 2020-08-06 13:13:16
    Bug探索提交Bug的标准及书写规范 讲解规范的同时,我们会有具体实例展现给大家 Bug有效性 1、交付过程中测试者需按照专家设定好的模块,对Bug进行归类提交; 2、Bug的类型默认为UI问题、功能问题、崩溃问题,...

    Bug探索提交Bug的标准及书写规范

    讲解规范的同时,我们会有具体实例展现给大家

     

    Bug有效性

    1、交付过程中测试者需按照专家设定好的模块,对Bug进行归类提交;

    2、Bug的类型默认为UI问题、功能问题、崩溃问题,提交Bug时不能弄错;

    3、需求是否明确、前提条件是否满足、输入数据是否正确、操作步骤是否清楚、Bug是否唯一性;

    4、避免提交设计如此、操作错误、重复的、已知的Bug;

    5、尽量少花时间在边界值、页面显示问题上,多提业务逻辑功能、交互测试方面的问题;

     

    Bug标题

    Bug标题要求简明扼要的阐述问题本质,使查看人员能快速了解Bug内容。需要写明在哪个页面执行什么操作出现什么现象。

    不明白的可以看一下下面的例子:

    正确示例:

    在我的设置页面不填写任何内容点击保存后,客户端崩溃

    错误示例:

     

    设置页面保存问题(过于概括)

    设置页面崩溃(缺少导致现象的关键步骤)

    客户端崩溃(只有现象而无法定位问题位置)

     

    特别提醒:

    1.标题中标点符号不能超过1个

    2.标题中不能含有测试流程步骤和模块信息

    测试设备:

    提交Bug要表明测试使用的设备、设备操作系统版本、测试环境、网络类型等等。

    前提条件

    明确指出所提交的Bug是在怎么样的情况下出现的,当所发现Bug前提条件为空时,需要填【无】。

    正确示例:

    WIFI网络正常且已登录

    测试步骤

    要简明清晰分步骤描述如何复现Bug问题,步骤用序号编排。

    要按照自己的操作的实际步骤写清楚每一步是怎么操作的,最后操作到哪个页面或者点击哪个按键。

    如在特定情况下发生的问题,还需明确提供以下信息:

    1.准确写出连续点击次数,点击时长与上下滑动屏幕时长。

    2.对于特定数据产生的问题,提供具体数据。

    3.精准描述bug产生的路径后,再描述现象。

    正确示例:

    1.打开客户端进行首页->点击“我的”页面->点击用户头像进入个人资料页

    2.个人资料页点击头像选择拍照->拍照后点击保存头像

    3.从个人资料页返回 “我的”页面,查看头像是否更新

    错误示例:

    左上角菜单栏->登录->新用户注册->输入手机号->输入昵称->输入密码->点击“获取验证码”

    特别提醒:测试步骤中的点击要用->符号连接

    期望结果

    按照测试步骤应当得到的正确结果,按照产品需求的期望清晰准确的填写预期结果。而且结果必须是肯定无疑义,可判定性的结果。

    正确示例:我们以一个取消点赞功能为例

    同步显示已经取消点赞

    特别提醒:期望结果不要包含测试步骤,要是简单的一个结果

    实际结果

    按照测试步骤实际出现的错误结果,避免使用“不正常”,“有误”等模糊词汇,需要直接描述实际现象。

    正确示例:还是以上一个点赞功能为例,出现bug后我就可以写

    还显示已点赞

    特别提醒:期望结果和实际结果要相互对应

    复现步骤描述及概率

    描述复现步骤中的页面切换为避免出现描述不清晰或者有歧义,需用“->”符号连接

    正确示例:

    首页->我的->我的订单->未支付,点击一个未支付订单,进入订单详情页

    关于复现概率一定要在多次测试的基础之上填写,若必定复现则填写100%,若偶现,请执行多次后统计概率填写。

    截图和附件

    UI类型:Bug需要上传截图,并且增加相应的红框标识;

    功能类型:问题必须上传视频文件,上传格式MP4为主;

    崩溃类型:bug则需要上传视频和log并且log不得超过10分钟。

     

    展开全文
  • 二、BUG提交注意事项 1. 测试人员提交新缺陷时,尽量用最简洁的语言最清晰的描述出BUG的出处、操作步骤、现象、(建议),并尽量截图; 2. 当你的BUG报告以“不可重现”打回给你时,测试人员应该反复阅读它,...

    Bug提交规范及注意事项:

    一、BUG提交规范

    目前所使用的JIRA系统中,BUG的内容主要包括以下要素:

    缺陷ID

    BUG的唯一标示,由JIRA自动生成。

    项目名称

    每个要测试的软件项目都有唯一的名称。

    问题类型

    选择是BUG还是新功能,子任务等。

    主题

    简明的对BUG进行概要描述。

    严重程度

    BUG的严重程度

    优先级(缺少)

    BUG解决的优先级

    到期日

    BUG需要处理的截止日期

    模块

    BUG所属的组织模块

    影响版本

    产生BUG的版本号

    解决版本

    解决BUG的版本号

    经办人

    需要指派处理的人员,如不清楚统一给项目负责人

    报告人

    报告BUG的人员

    环境

    描述当前测试的软硬件环境

    描述

    在详细描述中,可对BUG产生的前提条件、操作步骤、实际结果、预期结果等进行描述

    附件

    提交BUG时,可上传必要的附件。(截图,日志等)

    备注

    其他需要注意的地方;

    具体提交规范如下:

    1.  现象描述

     详细描述BUG的现象;

    2.  测试环境

    说明发现BUG的测试环境;

    3.  前提条件

    详细描述BUG产生的前提条件。例如浏览器,操作系统,移动设备组件版本,软件版本等;

    4.  操作步骤

    详细描述发现BUG的操作步骤;

    5.  期望结果

    描述预期正确的结果;

    6.  实际结果

    描述实际不正确的结果;

    7.  BUG严重性等级

    初步判定BUG的严重性等级;

    8.  BUG优先级

    判定BUG被修复的优先级别;

    9.  附件

    包括:BUG现象截图、操作产生的系统日志等;

    注:严重等级以上BUG必须带有附件,一般性BUG则附件可选。

    10.     备注

    BUG补充说明信息,如:测试分析意见、其它设备有无类似情况等;

    附BUG提交范例:

    【前提条件】

    操作系统:Win7

    浏览器:IE10,Firefox 47.0.1

    【操作步骤】

    1.     首页,点击“我要注册”;

    2.     打开注册页面,输入未注册过的手机号和密码

    3.     点击 注册按钮;

    【实际结果】

    注册不成功,停留在当前页面

    【预期结果】

    注册成功,跳转至首页

    二、BUG提交注意事项

    1. 测试人员提交新缺陷时,尽量用最简洁的语言最清晰的描述出BUG的出处、操作步骤、现象、(建议),并尽量截图;

    2. 当你的BUG报告以“不可重现”打回给你时,测试人员应该反复阅读它,集中剔除那些没有关系的步骤或词语,再检查是否有遗漏或清晰的步骤,再去找研发人员。

    3. 测试人员在精简空话的同时,应该再仔细检查报告是否会产生误解的地方。测试人员应该尽量避免使用模糊的,会产生歧义的、主观的词语。目标是使用能够表述事实、清楚的,不会产生争执的词语;

    4. 不要使用感叹号或其它表现个人感情色彩的词语或符号;

    5. 不要使用含糊的词语(例如,好像,似乎)或网络语言来描述发现的现象;

     

    三、Bug的类型

    1.    文档缺陷:术语不一致,文档缺失,不易理解等;

    2.    设计缺陷:需求不明确,操作便捷性等;

    3.    配置缺陷:安装部署不成功,配置文件错误等;

    4.    UI  缺陷:风格不一致,界面不友好等;

    5.    数据校验:数据长度,类型缺失校验;

    6.    查询统计:查询结果列表异常等;

    7.    功能缺陷:功能不可用;

    8.    可靠性  :用户权限错误等;

    9.    性能缺陷:查询性能,并发处理等;

    10. 流程缺陷:流程不能流转,流程错误结束等;

    11. 语言质量:字符未本地化,标点符号,商标符号错误;

    12. 用户互动:与使用者互动不良;

     

    四、Bug的等级划分

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

    1. 致命BUG,包括以下各种错误:

    1.1 由于程序所引起的死机,非法退出

    1.2 死循环

    1.3 导致数据库发生死锁

    1.4 因错误操作导致的程序中断

    1.5 严重的数值计算错误

    2.严重BUG,包括以下各种错误:

    2.1 功能不符

    2.2 数据流错误

    2.3 程序接口错误

    2.4 轻微的数值计算错误

    3.重要BUG,包括以下各种错误:

    3.1 操作界面错误

    3.2 打印内容、格式错误

    3.3 简单的输入限制未放在前台进行控制

    3.4 删除操作未给出提示

    4.轻微BUG,包括以下各种错误:

    4.1 界面不规范

    4.2 辅助说明描述不清楚

    4.3 显示格式不规范

    4.4 长时间操作未给用户进度提示

    4.5 提示窗口文字未采用行业术语

    4.6 可输入区域和只读区域没有明显的区分标志

    4.7 系统处理未优化

    5.微小BUG:

    5.1 界面重构、描述更改、流程改进

    五、 Bug优先级划分

    危机:要求立即修改,作为修改最高等级;

    紧急:要求重点修改,产品发布前必须修复;

    中等:需要尽快进行修改,产品发布前必须修复;

    尽快:需要修改,如果时间允许应该修改;

    不急:可能要修复,时间空余情况下进行修改。

    六、其他注意事项

    当发现一个BUG时,请注意下面的问题:

    1. 同一软件中的相似功能是否有相同的问题?

    2. 其他的浏览器是否有相同的问题?

    3. 其他的软硬件配置是否有相同的问题?

    4. 其他的区域是否有相同的问题?

    5. 以前的版本是否有相同的问题?

    转载于:https://my.oschina.net/u/3697699/blog/1569967

    展开全文
  • bug流程&提交规范

    千次阅读 2016-03-23 14:04:44
    1、 有效bug数是指出现过fixed,deferred状态的bug数。 2、 bug的最终状态是closed 、deferred。 3、 明确认为不是缺陷的,则状态可置为rejected。 4、 确认是缺陷,但本次不进行修复的,则PM在注释内...
  • 【测试】提交BUG的标准规范

    千次阅读 2017-12-02 23:38:30
    我们在软件测试过程中,发现了BUG后,如何提交一个高质量的BUG, 其实我们可以总结一下规范的,文章主要从以下几方面讨论: Bug有效性 提交Bug必须是有效的,就要求我们在提交Bug时,确认:  1、交付过程中测试...
  • 禅道BUG提出及处理流程规范

    万次阅读 多人点赞 2019-09-27 11:41:31
    禅道BUG提出及处理流程规范 版本说明 版本 作者 时间 备注 1.0 _冷冷 2019/9/27 首版本提交 ...7.2 BUG书写注意事项 2 7.3 BUG关键信息释义 2 8 BUG处理流程 5 8.1 BUG生命周期 5 8.2 BU...
  • 禅道BUG编写及处理流程规范

    千次阅读 2020-09-12 17:06:21
    本文档规范bug的提出及管理流程,定义BUG的整个生命周期。帮助测试、研发等人员了解BUG的处理流程。提高测试人员工作效率以及产品缺陷修复效率,避免出现搁置和遗漏的缺陷,从而提高产品的质量,降低质量检查和缺陷...
  • Bug编写规范及要求

    2021-12-08 17:40:20
    Bug编写规范及要求 标题规范: 出现bug的模块或页面,可用一句话完整描述问题现象 一个合规的bug: 按照复现步骤可复现bug; 涉及造数据的部分须在复现步骤中写明; 及时跟踪bug状态,密集测试期间应以天为单位,...
  • bug管理规范及流程

    万次阅读 2017-02-16 13:46:20
    1 概述 本文档定义bug的整个生命周期,规范bug的解决方案及管理流程。Bug在流转的过程中有章可循。 规范bug严重等级与bug解决优先级,使开发人员与测试人员能根据此文档...1. 根据规范提交bug; 2. 及时验证bug是否已
  • bug处理流程规范

    2021-04-15 16:27:10
    本文档定义bug的整个生命周期,规范bug的解决方案及管理流程。Bug在流转的过程中有章可循。规范bug严重等级与bug解决优先级,使开发人员与测试人员能根据此文档准确判断bug的严重程度并加以解决; 2关键角色及职责...
  • 其实commit规范不管是前端还是后端也好,我觉得吧,在任何的工程化的项目中都是不可或缺的部分啦,commit 提交规范,项目维护和管理起来是极其麻烦的,毕竟每个人都具有自己的个性,commit的格式也是参差不齐 ...
  • git提交代码规范

    2021-02-01 22:17:59
    在我们向github仓库提交代码时,git commit命令是不可缺少的。我们在commit时需要附带一些提交信息,否则将禁止提交。我们一般都简短的写一下本次提交的内容,但是我们对于代码...
  • 一条Bug记录最基本应包含: bug编号; bug严重级别,优先级; bug产生的模块; 首先要有bug摘要,阐述bug大体的内容; bug对应的版本; bug详细现象描述,包括一些截图、录像…等等; bug出现时的测试环境,产生的...
  • Git提交说明规范

    2021-04-14 17:08:32
    规范介绍 git commit信息格式介绍 type(scope): subject type(必须): commit 的类别,只允许使用下面几个标识: feat: 新的功能, fix: 修复Bug, docs: 只有文档变更, style: 空格, 分号等格式修复, refactor: ...
  • bug分支:万一正式环境出现严重bug妨碍使用时需要创建个bug分支进行修改,然后同步到release分支进行测试。测试后再同步到master分支发布,然后还要同时同步到iteration分支、develop分支 release分支:测试环境上的...
  • SVN提交代码需要注意的地方

    千次阅读 2015-06-15 10:24:22
     一、提交之前先更新 ...如果别人和自 己更改的是同一个文件,那么update时会自动进行合并,如果修改的是同一行,那么合并时会产生冲突,这种情况就需要同之前的开发人员联系,两个人一起协商解决冲突
  • git 提交代码规范

    千次阅读 2019-03-07 16:50:18
    用commit message最好是能有规范和工具的约束。 每次提交,Commit message 都包括三个部分:header,body 和 footer。 其中,header 是必需的,body 和 footer 可以省略。 不管是哪一个部分,任何一行都不得...
  • git commit 提交规范 & 规范校验

    万次阅读 多人点赞 2018-06-06 14:03:17
    在多人协作项目中,如果代码风格统一、代码提交信息的说明准确,那么在后期协作以及Bug处理时会更加方便。 因此,在本文章中,我会介绍怎么使用下面这个工具,在git push 代码之前检测commit messages: ...
  • Git规范:Git提交规范

    2021-01-08 10:21:29
    ② fix/to:修复bug,可以是QA(Quality Assurance)发现的BUG,也可以是研发自己发现的BUG。 备注: fix:产生diff并自动修复此问题。适合于一次提交直接修复问题。 to:只产生diff不自动修复此问题
  • husky commit 提交规范

    千次阅读 2019-03-15 12:58:32
    先来介绍本人公司采用的commit规范 Commit message格式 <type>: <subject> 注意冒号后面有空格。 type 用于说明 commit 的类别,只允许使用下面7个标识。 feat:新功能(feature...
  • git提交规范

    千次阅读 2018-08-16 10:43:43
    教程: ...fix: 修复 bug docs: 仅仅修改了文档,比如 README, CHANGELOG, CONTRIBUTE等等 style: 仅仅修改了空格、格式缩进、逗号等等,不改变代码逻辑 refactor: 代码重构,没有加新功能或者修复 b...
  • bug管理流程

    2021-10-18 16:02:30
    我们的职责就是,发现这些Bug,并提交给开发,让开发去修改。 2、bug类型 要确定一个bug的类型, 需要对项目(或产品) 有比较深的理解。这个划分对于开发定位问题影响很小,但对于问题类型的统计就比较重要了。—测试...
  • commitlint提交规范

    千次阅读 2019-05-31 15:43:18
    目前项目提交信息写的比较随意 只能看到开发人员每次备注的信息 为了后期协作以及处理Bug时会更加方便 引入commit规范,每次commit时,commitlint会用在git的hook回调中,最简单的就是和 husky一起使用 commit ...
  • git规范与日志规范

    千次阅读 2019-08-01 14:16:37
    因为要分享git规范,所以今天也顺便做一个总结,这个仅限于对git的开发中和部署时的规范提交时的日志规范做总结。本文章分两个部分总结git规范,一个是从分支讲解在开发 目录 分支构成 永久分支-master,develop ...
  • 最近又接受一个项目,上面的eslint各种规范真的是稍不注意就会出问题。也是在网上找了很多,感觉下面的总结很好的解决了我的困境。记录一下。方便下次查看。 一、为什么需要规范? 无规矩不成方圆,编程也一样。 ...
  • git commit提交规范

    千次阅读 2019-01-02 17:56:35
    git commit提交规范 代码提交信息的说明,能够使项目在后期协作以及Bug处理时更加容易理解 【1】commit message格式  <type>: <subject>  注意:冒号后面有空格 【2】type ...
  • 前言在多人协作项目中,如果代码风格统一、代码提交信息的说明准确,那么在后期协作以及Bug处理时会更加方便。Git 每次提交代码,都要写 Commit message(提交说明),否则就不允许提交。一般来说,commit message ...
  • BUG描述规则

    千次阅读 2019-09-27 11:25:46
    1. Bug的基本概念 2. Bug的生命周期 3. BUG的描述规范 4. BUG的跟踪规范 5. BUG的审核

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 27,046
精华内容 10,818
关键字:

bug提交需要注意哪些规范