精华内容
下载资源
问答
  • bug提交规范

    2012-06-26 15:08:08
    bug提交规范 1. 标题准则 2. 详细描述书写准则 3. 各项目页面分类列表
  • BUG提交规范

    2018-08-21 11:39:01
    BUG提交规范 1. 请把所有bug都提交到禅道,地址为:xxxx 2. 如下图创建bug,所有bug都指派给 项目临时负责人,严禁指派给研发其他人员 例如:迎新项目负责人易粮坤。 然后负责人指派给研发同事。 缺陷类型 ...

    BUG提交规范
    1. 请把所有bug都提交到禅道,地址为:xxxx
    2. 如下图创建bug,所有bug都指派给 项目临时负责人,严禁指派给研发其他人员
    例如:迎新项目负责人易粮坤。
    然后负责人指派给研发同事。

    缺陷类型
    缺陷类型 描述
    代码错误 需求规格说明书明确提出来,但研发未能够达到需求要求实现
    系统错误 存在或产生于所开发的项目之外的软硬件错误
    设计变更/新增需求 项目需求变更;设计不合理;导致的问题信息
    界面优化 排版不整齐,不美观,相同或相近功能风格不统一等
    缺陷严重程度(Severity)
    缺陷标识 严重等级 描述
    1 严重缺陷 不能执行正常业务功能或重要功能,使系统崩溃或资源严重不足。
     由于程序所引起的死机,非法退出
     死循环
     数据库发生死锁,与数据库连接错误
     错误操作导致的程序中断
     严重的数值计算错误
     数据通讯错误
     数据丢失等
    2 较严重缺陷 严重地影响系统要求或基本功能的实现,且没有办法更正。
    (重新安装或重新启动该软件不属于更正办法)
     功能不符
     重要功能未完全实现
     程序接口错误
     数据流错误
     轻微的数值计算错误
    3 一般性缺陷 非重要功能无法正确执行,实现不正确、不完全,但是不影响总体功能;影响系统要求或基本功能实现,但存在合理更正办法。
     界面错误
     打印内容、格式错误
     简单的输入限制未放在前台进行控制
     删除操作未给出提示
     数据输入没有边界值限定或限定不合理
     某个不重要的菜单不起作用
    4 较小缺陷 操作界面的错误,使操作者不方便或遇到麻烦,但它不影响执行工作或功能的实现。
     辅助说明描述不清楚
     显示格式不规范
     系统处理未优化
     长时间操作未给用户进度提示
     提示窗口文字未采用行业术语
     提示信息显示有误
     可输入区域和只读区域没有明显的区分标志
    缺陷优先级(Priority)
    等级 缺陷优先级
    1 需要立即解决问题
    2 需要在指定时间内解决的问题
    3 产品项目计划时间内解决的问题
    4 资源充沛时解决的问题
    缺陷状态(Status)
    缺陷状态 描述
    激活 提交的缺陷,等待处理
    已解决 缺陷被修复
    已关闭 确认被修复的缺陷,将其关闭。

    填写步骤
    打开禅道,点击“测试”模块,再点击“BUG”

    点击“提BUG”

    填写说明
    字段 说明
    所属产品 根据不同的产品选择不同的产品信息
    例如:迎新是属于蜂巢产品的,就选择蜂巢2.0
    所属模块 根据不同的服务选择不同的模块信息,默认可以选择主干
    例如:迎新就选择:微服务/迎新服务
    所属项目 根据不同的项目学校选择不同的项目信息
    例如:西城就选择【项目部】西南科技大学城市学院
    影响版本 如果是用户版APP,就选择主干;如果是微服务,请选择具体的微服务
    当前指派 所有bug都指派给沈阳或项目临时负责人,严禁指派给研发其他
    人员例如:迎新项目负责人易粮坤。
    BUG类型 详情请查看”缺陷类型”

    操作系统 不填写
    浏览器 按照实际出现问题的浏览器进行填写,如涉及到多浏览器,可以选择全部。
    BUG标题 清晰简洁的描述问题所在
    严重程度 详情请查看“缺陷严重程度”

    优先级 详情请查看“缺陷优先级”

    重现步骤 填写详细的问题信息
    抄送给 必须抄送给罗江(研发测组长)

    点击保存即可

    展开全文
  • 一、BUG提交规范 目前所使用的JIRA系统中,BUG的内容主要包括以下要素: 元素 说明 缺陷ID BUG的唯一标示,由JIRA自动生成 项目名称 每个要测试的软件项目都有唯一的名称 问题类型 选择是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. 以前的版本是否有相同的问题?

    展开全文
  • 一份BUG提交规范

    2019-08-02 14:47:00
    1,BUG全部提交到http://XXX.XXX.XXX.XXXBUG论坛上2,创建的问题的时候,“概要”--用简单明了的语句说明白你这个BUG,就相当与BUG的中心语句3,BUG优先级分为4种情况 致命问题:系统任何一个主要功能完全丧失、用户...

    1,BUG全部提交到http://XXX.XXX.XXX.XXXBUG论坛上

    2,创建的问题的时候,“概要”--用简单明了的语句说明白你这个BUG,就相当与BUG的中心语句

    3,BUG优先级分为4种情况
       致命问题:系统任何一个主要功能完全丧失、用户数据受到破坏、系统崩溃、悬挂、死机,或者危及人身安全
       严重问题: 系统的主要功能部分丧失、数据不能保存,系统的次要功能完全丧失,系统所提供的功能或服务受到明显的影响
       一般问题:  系统的次要功能没有完全实现,但不影响用户的正常使用。
       建议性问题:不影响功能的、有关易用性的、文字、操作可以提出一些建议的问题

    4,然后选择你提交的BUG所以那个模块,并选择提交问题时测试程序的影响版本

    5,选择这个BUG所属模块是属于那个开发人员 ,并把问题指派给他

    6,环境:填写你当时出这个BUG的现场环境,如:操作系统是winxp,测试的终截者是那天的版本等(这个根据实况进行填写,可写也可不写)

    7,另外可以通过上传截图或附件,可以进行简单明了的说明BUG存在,也可做为BUG证据

    8,最重要的在填写描述: 最好是把BUG产生的步骤一步一步写清楚,可以用以下方法写(如果一句话就可以说明的BUG,就不必要分步骤了)
         1,。。。
         2,。。。
         3,。。。
         4,。。。
        写清楚,然后写出测试出的结果和你期望的结果,如:
        测试结果:。。。。。
        期望结果:。。。。。

    9,BUG验证/关闭问题说明:
       当BUG由open变为FIXed,你就应该进行回归测试,如果回归测试后该问题被解决,则你就closed该BUG,并在注释中填写如下信息:
                验证通过:是
                验证日期:。。。
                验证版本:。。。
       如果回归测试验证不通过,则Reopend该BUG,并在注释中填写你验证的版本

    10,关于研发人员解决问题
        研发人员解决BUG写的注释一定要有以下几点:
          1,说清楚BUG产生的原因
          2,写出BUG产生的文件
          3,修改后该文件的版本号
      如果研发解决问题的注释上只写“已解决”这样的话,就一定要叫他们加上上面的信息

       可能这个要根据不同的公司进行修改,我们分配问题就是直接分给相关开发人员,而不用通过经理再去分配任务。

    转载于:https://www.cnblogs.com/nlry901/p/11288537.html

    展开全文
  • Bug提交规范及注意事项: 一、BUG提交规范 目前所使用的JIRA系统中,BUG的内容主要包括以下要素: 缺陷ID BUG的唯一标示,由JIRA自动生成。 项目名称 每个要测试的软件项目都...

    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提交和回归规范

    2020-11-20 14:05:35
    bug提交规范: bug回归规范
  • BUG提交和管理规范

    千次阅读 2018-06-27 22:14:24
    在测试理论基础面试,或者带新人的过程中,有一件事情必不可少,就是如何提交BUG,...BUG提交规范 【所属功能】bug出现的功能模块,比如个人中心。 【主题】一句话描述问题产生的模块、现象、错误现象及正确结果。...
  • bug提交及管理规范

    2015-08-31 15:28:50
    bug提交规范 缺陷概述,缺陷操作步骤,预期结果,实际结果,已解决,已关闭,重新打开
  • 禅道Bug提交管理规范

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

    2013-05-12 17:16:46
    对于开发后人员进行测试的一些建议,对于bug规范处理
  • Bug报告提交规范

    2014-12-17 18:02:00
    首先声明,bug的测试规范应该在公司的正式文档建立。本建议非正式文档,有些内容可能不正确,有些内容可能需要继续商榷,甚至有些内容同公司规范有冲突。如果发现问题,直接忽略本文相应内容。本帖本意仅就工作中的...
  • Bug管理规范及流程

    2018-09-03 17:12:12
    Bug管理规范及流程:整理测试流程,bug提交规范,bug属性定义
  • 实际上在我们日常软件测试过程中,提交一个bug,不仅仅是这6要素这么简单的事情。以下是个人总结了日常测试工作中常见的一些问题: 需求未设计?需求不明确? 服务端/前端的数据错误? 开发无法重现?能帮开发...
  • bug流程&提交规范

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

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

    2019-04-03 19:57:17
    背景说明 为了减少开发、测试在Bug上花费不必要的沟通成本,同时为迭代总结会提供... 根据规范提交bug; 2. 及时验证bug是否已解决; 3. 及时关注开发拒绝bug,和相关人员沟通讨论解决方式; ...
  • 测试流程及测试规范文档,以及BUG提交文档 说明: 此文档使用offic2007编辑的,请下载下来后使用2003兼容程序或2007打开
  • Bug探索提交Bug的标准及书写规范 讲解规范的同时,我们会有具体实例展现给大家 Bug有效性 1、交付过程中测试者需按照专家设定好的模块,对Bug进行归类提交; 2、Bug的类型默认为UI问题、功能问题、崩溃问题,...
  • 【测试】提交BUG的标准规范

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

    2020-05-11 15:57:55
    BUG标准规范 ** 1、描述内容标准 测试环境 前置条件 操作步骤 预期结果 实际结果 其他信息:项目信息、问题截图、日志或报文 2、BUG提交级别标准 2.1 Block问题(Highest)标准 新功能导致的严重回归问题 基本...
  • 1、交付过程中测试者需按照专家设定好的模块,对Bug进行归类提交; 2、Bug的类型默认为UI问题、功能问题、崩溃问题,提交Bug时不能弄错; 3、需求是否明确、前提条件是否满足、输入数据是否正确、操作步骤是否清楚...
  • 提交Bug的标准及书写规范 讲解规范的同时,我们会有具体实例展现给大家 ...
  • bug提单规范

    2018-09-05 10:23:00
    一。提单模板 标题:【项目组】【模块】【子模块】【发生原因】问题简要描述描述:【预置条件】 有就写清楚,没有就写无【操作步骤】1.XXXXX2.XXXXXX3.XXXXX【实际结果】 XXXXX【预期结果】 XXXXXX...在上述提交bug...
  • 一。提单模板标题:【项目组】【模块】【子模块】【发生原因】问题简要描述描述:【预置条件】有就写清楚,没有就写无【操作步骤】1.XXXXX2.XXXXXX3.XXXXX【实际结果】XXXXX...偶现bug在上述提交bug要求上添加:1.填...
  • bug管理规范及流程

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

    2021-03-17 17:07:13
    git 提交规范type关键字 type关键字 提交类型 type 用来描述一次提交行为的改动方向,type 的可选值如下: • feat: 新增功能 • feature: 新增功能 • fix: 修复 bugbugfix: 修复bug • docs: 文档相关的改动 ...
  • Git提交规范

    2021-03-29 22:30:55
    Git提交规范 commit提交信息能有效地表明本次提交所更改的事件 主要分为以下几类: build: 影响构建系统或外部依赖的更改(npm) chore: `日常事务`,`例行工作`(不在本文中规范的类别的都放在chore里面) docs: ...
  • 7. Bug管理规范

    2019-09-06 12:33:49
    测试人员发现bug提交,待修改状态。 Bug初始状态 Resolved 开发人员修改完bugbug变更为已解决状态。 Bug中间态 Closed 测试人员回归通过,变更为已通过状态。 Bug完成态 Postpone 经确认不需要在本次发布...
  • Bug的标准及书写规范 交付过程中测试者需按照设定好的模块,对Bug进行归类提交Bug的类型默认为UI问题、功能问题、崩溃问题,提交Bug时不能弄错; 需求是否明确、前提条件是否满足、输入数据是否正确、操作步骤...

空空如也

空空如也

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

bug提交规范