Bug提交文档
BUG提交文档
Bug _1
问题相关信息
问题描述
用户填写，增加插图引起问题的原因杰狮填写。
软件测试BUG提交规范_模板
BUG提交模板和注意事项 一、BUG提交模板 1.现象描述 <详细描述BUG现象> 2.组网环境 <组网图及简要说明：机箱、板卡（型号、序列号和槽位）、测试仪、连接线缆等描述> 注：简单组网环境或一般性BUG情况下，可只简要描述组网环境，无需组网图。 3.版本信息 <被测设备所有组件版本信息> 软件版本： 硬件版本： 芯片版本： CPLD版本： MCU版本： uboot版本： 4.操作步骤 <详细描述发现BUG的操作步骤> 注：说明发现BUG对应用例名称编号或为非用例发现BUG。 5.期望结果 <预期正确的结果> 6.实际结果 <实际不正确的结果> 7.BUG严重性等级 <初步判定BUG的严重性等级>
8.开发确认情况 <开发确认BUG情况描述及确认人> 注：严重等级以上BUG必须要有开发人员确认 9.附件 <包括：组网图、BUG现象截图、操作产生的系统日志等> 注：严重等级以上BUG必须带有附件，一般性BUG则附件可选。 10.备注
JIRA bug提交管理规范
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级——一般：系统次要功能无法实现；主要功能部分失效；系统业务受到影响；导致用户利益受到一定损失。该级别需求程序员修改。
禅道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无关的步骤。 [结果]：写明操作的实际结果。
JIRA的BUG编写规范
?一、摘要 ?二、名词解释 ?三、目的 ?四、范围 ?五、Bug编写规范 o 1. 主题 o 2. 描述 o 3. 环境 o 4. 截图 o 5. 其他 ?六、注意事项 一、摘要 本文档主要描述了技术产品部测试人员提交Bug时需要遵守的规范。 二、名词解释
?JIRA JIRA是Atlassian公司出品的项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。 三、目的 规范Bug编写，一方面，可以方便开发人员根据Bug描述快速进行定位问题原因，减少沟通成本，另一方面，可以帮助测试经理、非技术人员、产品经理、开发经理及其他测试人员等了解Bug，第三，可以体现测试团队的专业性、严谨性。 四、范围 该文档适合技术产品部测试人员使用，适合于任何产品和项目。 五、Bug编写规范 1. 主题 为了节约开发阅读Bug时间，同时考虑到开发人员容易通过Bug标题来猜想Bug，所以，Bug标题显得尤为重要。以下为Bug标题编写时需要遵守的规范。1）用简短的语句描述问题，主题文字过多，增加开发阅读Bug时间。2）格式：在什么位置，在什么条件下，做什么操作，操作的结果。 ?在什么位置：问题所在的路径，格式为“XX-页面：”
?在什么条件下：如果问题为兼容性Bug，比如浏览器兼容或者分辨率兼容。格式为“在IE11浏览器下，”，如果Bug不属于兼容性问题，不用加此描述。 ?做什么操作：问题触发的动作，比如：“执行审批通过”。 ?操作的结果：即问题的表象，比如：字段“报送时间”取值不对、报404错误。格式举例：采购中心-招标计划详情：在IE11浏览器下，展开“查看参与人员”，内容错乱。 3）除了第二点描述的格式，对于Bug描述，除了描述实际的结果外，有时候我们会直接描述期望结果，比如，集采销售-招标计划列表：列表字段“填报时间”应该修改为“报送时间”。 4）描述无歧义。Bug描述如果有歧义，开发容易因为改错Bug，导致增加Bug修复成本。 5）涉及界面UI的文字，用双引号标注，比如：集采销售-招标计划列表：列表字段“报送时间”取值错误。 2. 描述
JIRA的BUG管理规范
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 .响应时间。
Bug定义规范
BUG定义规范Revision History
1.目的 对BUG概念、BUG提交和验证、BUG状态、BUG严重程度等内容进行定义和规范，以便进一步指导我们的测试工作 2.概念 BUG:软件中存在的瑕疵，可能会导致软件失效。简单的说就是软件系统中存在的可能导致系统出错、失效、死机等问题的错误或缺陷 3.BUG管理工具 以Quality Center 9.0为提交、跟踪等工具 4.BUG提交和验证要求 以QC中的字段为准 提交时必选字段有：摘要，跟踪类型，检测者，检查日期，计划关闭版本，可重现，分 派给，严重程度，状态，描述 验证后，需要修改字段：关闭于版本，关闭日期，状态BUG描述模板如下： [问题概要]: [重现步骤]: 步骤1. 步骤2. [隔离分析]: [期望结果]: [重现概率]: [Test Case No.]:（若没有用例，则标注‘NA’，若是地区版本上的问题，则标注地区名称） [Test Case]:（若没有用例，则标注‘NA’，若是地区版本上的问题，则标注地区名称） QC中优先级和严重程度的区别：优先级由软件开发人员填写，严重程度由测试人员填写 计划关闭版本定义： 有2重含义：1.由测试人员填写当前发现bug的版本号；2.开发人员必须在此版本上修改 5.BUG验证 开发人员必须提供修改此bug会涉及到的功能点列表，并将此信息填写到bug描述中。 测试人员除验证此bug外，还需要将开发列出的功能点逐一验证，同时写入自己考虑到的功能点验证情况 来自需求和测试自己提交的问题，测试人员都需要验证，并填写测试结果，其中来自自己的bug，若验证通过，则修改状态为“关闭”；来自需求人员的bug，则修改状态为“验证完毕”，由需求人员来关闭（适用于胜算组）。 6.BUG状态流程 在正在BUG生命周期中，可能会经历很多状态，如：新建、提交验证、已关闭、重新打开、已挂起、重复提交等。 新建：新发现的问题 提交验证：开发修改bug后，会将状态变为提交验证，让测试工程师来执行验证操作已关闭：测试工程师经过验证后，发现此问题已经被修复，则修改状态为已关闭
bug定义规范
Bug定义规范 1、bug类型的划分 功能类： 1、重复的功能 2、多余的功能 3、功能实现与设计要求不符合 4、功能使用性、方便性、易用性不够 5、功能未实现 界面类： 1、界面不美观 2、控件排列、格式不统一 3、焦点控制不合理或不全面 数据处理类： 1、数据有效性检测不合理 2、数据来源不正确 3、数据处理过程不正确 4、数据处理结果不正确 流程类： 1、流程控制不符合要求 2、流程实现不完整 提示信息类： 1、提示信息重复或出现时间不合理 2、提示信息格式不符合要求 3、提示框返回后焦点停留位置不合理 建议类： 1、功能性建议 2、操作建议 3、检校建议 4、说明建议 2、bug等级定义 Level 1-致命的bug：100%程序崩溃、重启、死机，自动退出，用户数据丢失，缺少主要功能。 1、程序无法正常使用，在正常操作流程中（特别是操作步骤不复杂，用户很容 易就用到）出现崩溃、死机现象 2、100%导致用户数据丢失的问题 3、被测试数据系统频繁崩溃，程序出错，使功能不能继续使用 4、性能与需求不一致 5、系统资源引发性能问题 6、系统配置引发错误 7、安全性问题
Level 2-严重的bug：所产生的问题导致系统瘫痪，重要功能未实现，严重影响用户使用的问题，关键用户需求未实现或软件功能与需求严重不符。 1、功能与需求不一致，或功能未实现 2、功能有错误 3、数据传输有错误 4、安装与卸载有问题 Level 3-一般的bug：所产生的问题会导致系统部分功能不正常，虽然产生的问题严重，但不影响下一步的测试，严重的界面提示问题。 1、功能有错误，但不影响使用 2、重要界面的显示问题 3、内存泄露导致某些功能无法正常使用，释放内存重启后系统恢复正常 4、复现率较低的死机、重启问题，步骤多用户不易操作到 5、边界条件出错 Level 4-轻微的bug：轻微界面显示问题，对用户使用无影响的问题。 1、微小功能问题，如闪烁中间界面、界面刷新慢 2、轻微的界面显示错误，界面设计不规范，交互不友好 3、消息、提示信息不准确 4、用户可以接受，对功能不影响 5、某些次要功能，在进行某些很特殊的操作后某些功能不能正常响应 Level 5-建议性bug：功能运作正常，可是有改进的空间，建议性问题所产生的问题不会导致系统任何问题。 1、可以忽略不计的问题，对用户使用没有任何影响，但有改进空间 2、软件设计有问题 3、文档不完整或不准确 4、其他建议性问题 3、BUG状态 （初始状态） 1、已提交：测试人员员发现BUG后提交到BUG管理系统中的状态。 2、已修改：开发人员在修改了BUG后提交到BUG管理系统中的状态。 3、不修改：程序员或产品人员根据需求分析、概要设计、详细设计说明书等经过考虑后决定对BUG不进行修改。其BUG的状态为不修改，需要说明理由。 4、延迟：根据目前项目进程或计划等情况，暂时延期的状态 5、待讨论：需要进行讨论后才能决定是否需要修改的BUG的状态。 6、已验证：已经解决的并经过测试员复测的BUG的状态。 7、关闭：完全解决了，只供以后备查的状态 8、重新打开：重新出现在新的版本中，重新打开以前关闭的BUG的状态
BUG需求提交规范
BUG\需求提交规范 1．客户名称：广州方泰电子（需求） A、问题描述：客户为防止业务飞单，想设置权限隐藏邮件模块客户的发件地址，不让业务员直接接触客户。（客户已设置所有业务必须先建客户资料才允许发邮件） B、问题出现操作步骤(问题出现操作步骤里面要包含客户目前版本号)： 4.6版本 C、问题图片： D、解决方案： 2. 客户名称：广州方泰电子（需求） A、问题描述：客户想在客户自定义模块设置一栏，可以统计客户其他自定义几项之和或乘积。 B、问题出现操作步骤(问题出现操作步骤里面要包含客户目前版本号)： 4.6版本 C、问题图片：
D、解决方案： 3. 客户名称：茂名腾云电子（需求） A、问题描述：邮箱模块搜索功能太繁琐，需要搜索框默认根据主题、附件名、正文、邮箱账号任一条件搜索！ B、问题出现操作步骤(问题出现操作步骤里面要包含客户目前版本号)： 4.6版本 C、问题图片： D、解决方案： 4. 客户名称：茂名腾云电子（需求） A、问题描述：邮箱模块无置顶功能 B、问题出现操作步骤(问题出现操作步骤里面要包含客户目前版本号)： 4.6版本 C、问题图片：
D、解决方案： 5. 客户名称：茂名腾云电子（需求） A、问题描述：写邮件时设置提醒功能，到时间能自动提醒，根据提醒链接能查看提醒内容。 B、问题出现操作步骤(问题出现操作步骤里面要包含客户目前版本号)： 4.6版本 C、问题图片： D、解决方案： 6. 客户名称：茂名腾云电子（需求） A、问题描述：左侧选择对应客户，选择编辑客户资料时，右侧不能立刻同步客户资料信息。 B、问题出现操作步骤(问题出现操作步骤里面要包含客户目前版本号)： 4.6版本 C、问题图片：
BUG处理流程规范
BUG提出和处理流程规范 1引言 1. 1目的 提高测试以及产品缺陷修改效率，避免出现搁置和遗漏的缺陷，从而提高产品的质量，降低质量检查和缺陷修改成本 1. 2适用范围 适用于研发部门（Confernece、Flash、监控），质量保证部门 1.3 定义 bug：通过测试检查出的产品缺陷； 新建、打回、已确认、已指派、已解决、已关闭：测试中bug的不同状态，详细信息见本规范第3部分； 1. 4参考资料 无 2 BUG提交和处理规范说明 1、在测试人员提交bug的时候，必须对bug信息进的描述必须详细全面、清晰明确，如果有条 件，需要描述使用的环境，在BUG出现前的具体操作，如果抓图，必须抓取jpg全屏图象，但不能使用BMP格式上传到BUG库中，有抓包文件需要上传BUG库，空间不够需要放到\\192.168.0.254\qa\测试\bug日志目录中，标题以BUG号区分； 2、在测试人员提交bug的时候，必须按具体情况，填写重要级别、出现频率、优先级别三个栏 目，而非测试人员不得对上述信息进行直接改变，如觉得这三个信息填写不恰当，可以在该bug下的注解中提出意见，并“打回”给bug提交人员或质量部经理处，经过确认后修改；
3、开发人员对bug进行处理后的变更状态成“打回”时，或“指派”给产品部门时以及变更成 “已确认”时必须进行必要的描述和说明,在状态变更时，必须要指定具体接收人； 4、开发人员在注解中描述该BUG计划什么时候解决或做其他阐述的时候，要明确写清承诺的 具体版本号，禁止使用“上一版本”、“本版本”、“下一版本”等字样，以免造成误会或混淆； 修改完成的BUG注释中加入相关的确认信息，如“XXX Review并通过。 5、如果已经是“关闭”状态的BUG，测试人员在后期测试中又出现了需要重新打开，重开后 的BUG状态为“打回”，测试人员需要再多一个操作，即“指派”给具体的研发人员。 6、一直处于“打回”状态的BUG，测试人员需要经过两轮（即两个版本）测试后仍然没有重 现的，可以关闭。但是此两轮测试在该BUG中必须有注释，比如：“XX版本（要求有具体版本号）测试没有重现”，当第二轮测试仍没出现时也需要注释一次，即可进行关闭。 3 Mantis Mantis是PHP/MySQL/Web-based缺陷跟踪系统。 其特点： 个人可定制的Email通知功能，每个用户可根据自身的工作特点只订阅相关缺陷状态邮件； 支持多项目、多语言； 权限设置灵活，不同角色有不同权限，每个项目可设为公开或私有状态，每个缺陷可设为公开或私有状态，每个缺陷可以在不同项目间移动； 主页可发布项目相关新闻，方便信息传播； 支持上传文件，提供进一步的bug信息； 支持上传项目文档； 方便的缺陷关联功能，除重复缺陷外，每个缺陷都可以链接到其他相关缺陷； 缺陷报告可打印或输出为CSV格式。支持可定制的报表输出，可定制用户输入域； 有各种缺陷趋势图和柱状图，为项目状态分析提供依据，如果不能满足要求，可以把数据输出到Excel 中进一步分析； 流程定制不方便，但该流程可满足一般的缺陷跟踪。 在提交bug时需要填写相关信息，还可以上传相关文件（如出错的log或者截图等），对于bug添加注释（允许再次更新）。下面是基本信息的介绍 [出现频率] 可重现-- 稳定地能重现 经常-- 比较经常出现 偶尔-- 偶尔出现 不可重现-- 无法重现 N/A -- 其他情况 [严重性] 不合理或别扭-- 使用不方便，吹毛求疵的标准 文本错误-- 文本错误 崩溃死锁-- 导致死机的bug 严重错误-- 导致功能无法正常运行下去
bug规范文档
1 测试用例规范
此规范定义了测试用例的属性、级别、撰写以及执行等规范。
1.1 用例级别属性（Keywords）
此字段主要是用来标识用例的级别， 通过对用例的级别定义， 可以使整个测试过程分级 式管理，从而指导测试流程的顺序、突出重点问题、选择性测试，节约了测试成本，同时也 便于更好的表述和分析测试结果。 也是我们定义开始测试标准、 停止测试标准以及回归测试 标准的一个依据。所有的用例将被定义的状态如下： 1、Base（基础，可测用例） 此级别为基础型， 表述了能保证系统可以运行的基本条件， 同时也定义了此安装包可以 进行下一步测试的标准。
如：是否有遗漏功能、安装测试、基本功能点是否没有问题、各项服务是否都是正常运 行、提交制品是否相符等等。
2、Important （重要，可测用例） 此级别为重要型，在完全通过了 Base 类型用例的测试后，首先要测试的用例，这些用 例表述了系统能正常运行的条件和此版本发布必需要满足的条件。 此类型的用例将符合以下 标准之一：
涉及整个功能模块的用例，如果此用例不通过，将导致功能模块不可使用或功能不正常的用例。如： 注册用户、注册服务等等。 能表明某项功能基本满足需求的用例。 涉及到共性问题的用例，如： 发送消息等。 在 release Note 声明解决的 bug。 用户在正常使用中，出现频繁情况的用例。
3、Normal（普通用例） 此级别为普通型， 测试用例的主体。 该类型的用例主要针对在保证系统正常运行的前提
下，对功能行用例进行完善，对功能性用例进行扩展。另外还有测试系统对特殊情况、异常 情况、异常操作情况的处理能力，从细微找出系统漏洞，从而更加完善系统的抗压性和稳定 性。 4、Extend（扩展用例） 此级别为建议型， 该类型用例针对不影响系统正常运行的建议， 力图完善系统现有功能 或提出对系统功能的展望。如：界面显示信息明 确、系统退信的语言规范等
1.2 用例书写规范
1、Test Case Title 命名规则 用例命名时用例应该能够描述出用例的测试目的。 2、Summary 详细信息
Summary 标签，概述了用例的基本情况，应包含以下信息：
测试目的。概述此用例的测试重点和容易出现问题的地方（必写项） 。 前提条件。描述此用例能够执行的基本条件（必写项） 。 测试数据。描述此用例使用的测试素材，包括：输入字符串、大小等数据。 备注。选择填写，可在此项描述用例的测试历史，曾经出现的 bug 等需要表述给测试人员的信息。
3、Steps 设计步骤 此标签为执行用例的主要步骤标签，详细的描述了用例执行的方法步骤和应有的结果。 对此标签的撰写做以下规范：
每一步操作都对应唯一的功能点。避免没有对应功能点的无用步骤，同时也避免一个步骤对应多个功 能点的情况 每一操作步骤的 Expected Result 必须填写。且只能出现描述结果的语言，不能出现描述操作的语言
4、Attachments 附件 此标签为已有的用户添加附件。通过附件可以更加清楚或方便的表述用例内容，如：通 过 Excel 文件批量添加用户、上传本地数据库文件等。
Bug处理规范
Bug处理规范
目录 Bug处理规范 (1) 目录 (2) 1目的 (3) 2适用范围 (3) 3 Bug处理流程 (3) 4测试部相关活动定义 (4) 4.1测试部Bug (4) 4.1.1新建 (4) 4.1.2关闭 (5) 4.1.3 Reopen (6) 4.1.4已知问题 (7) 4.2工程部Bug (8) 4.2.1验证通过 (8) 4.2.2验证不通过 (9) 5研发部相关活动定义 (10) 5.1测试部的Bug (10) 5.1.1转移/分配 (10) 5.1.2接受 (11) 5.1.3打回 (12) 5.1.4解决 (13) 5.1.6挂起 (14) 5.1.7已知问题 (15) 5.2工程部的Bug (16) 5.2.1转移/分配 (16) 5.2.2接受 (17) 5.2.3打回 (18) 5.2.4解决 (19) 5.2.5挂起 (20) 6工程部相关活动定义 (21) 6.1新建 (21) 6.2关闭 (22) 参考 (24) 1严重程度的定义 (24) 2挂起的标准 (24) 3打回的标准 (24)
1目的 本文档规范了测试人员、工程人员、研发人员如何对公司Bugfree系统中的缺陷进行处理的规则，涉及Bug的各个活动。所有人员应严格遵循本规范所制定的规则，对Bug进行及时地、规范化地处理。 本规范会根据施行过程中发现的问题不定期进行修正，修正结果将及时公布。 2适用范围 本文档是指导测试人员、工程人员、研发人员进行Bug处理时的指导性文档，适用于测试部、研发部和工程部所有人员进行Bug处理。 3 Bug处理流程
JIRA的BUG管理规范
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)
1BUG管理工具介绍 常用的BUG管理工具有JIRA、BugFree、Bugzilla、Mantis、XPWeb等。我们公司采用的是JIAR，JIRA是Atlassian公司出品的项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。 2BUG定义 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．响应时间。 6、从兼容性方面考虑，BUG有两种：
Bug提交标准规范
Bug提交标准规范 JIRA管理软件提交的bug做到：言简意赅，语意明确 bug报告内容： 产品模块选择产品模块 项目选择项目 主题填写该缺陷名称，在提交bug时，bug主题要描述言简意赅，语 意明确，让开发人员一眼看出哪里有问题。 优先级选择优先级 所属项目选择所属项目 影响版本 当前指派选择指派给开发人员 Bug标题填写该缺陷名称，在提交bug时，bug标题要描述言简意赅，语 意明确，让开发人员一眼看出哪里有问题。 如：龙旅在线前台系统->修改个人资料，修改用户名姓名“XX”改为“张三” 重现步骤步骤自动生成，可进行修改，内容需尽可能详细，使开发人员可 以重现该bug。 如有前置条件请说明前置条件：如特定的操作方式，特殊的用户，特殊的浏览器等，能有利于bug复现的操作尽量进行提供。 如：前置条件：系统登录成功，使用登录账号：zhangcui 密码：asd123 浏览器：firefox 操作步骤：1、点击“修改个人资料” 2、修改姓名为“张三” 3、点击“保存” 预期结果：保存成功，姓名修改为“张三” 实际结果：提示保存失败！
数据库存储相关的bug（和设计的字段不符合，和设计的长度不符合等）需要 以bug记录。其他存储，如redis相关的需要以bug进行记录。 相关需求：有相关需求则选择相关需求，么有则不选择 相关任务：有相关任务则选择相关任务，没有则不选择 类型/严重程度：选择问题类型，根据bug定义规则判断问题严重程度（如：1：致命缺陷；2：严重缺陷；3：一般缺陷；4：轻微缺陷） 系统/浏览器：选择当前测试所属系统及浏览器 抄送给：可以选择要抄送的人员 关键词：填写该缺陷需要注意的事项 添加附件：（如：图片、word、excel、txt等文档）当有bug描述说明不清楚时，可附上截图加以说明（类型分为：1、不容易描述清晰的；2、有特殊性的 如需要特殊的数据日子截图） 注：bug致命和严重问题必须全部解决，一般问题不能超过3个，轻微问题小 于5个方可达到上线（视情况而定）
bug管理规范及流程
bug管理规范及流程 1、概述 本文档定义bug的整个生命周期，规范bug的解决方案及管理流程。Bug在流转的过程中有章可循。规范bug严重等级与bug解决优先级，使开发人员与测试人员能根据此文档准确判断bug的严重程度并加以解决； 2、关键角色及职责
3、Bug生命周期 4、Bug书写规范 4.1 BUG标题 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提出者；同时注明拒绝理由； 示例：
Bug提交规范说明
Bug提交规范说明 文档编号： Bug提交规范说明 密级： [内部资料] 部门：测试部 版本编写人/修改人日期说明 V1.0 王宝静2006-04-07 初稿 V1.1 王宝静2006-07-28 更新 V1.2 刘丽2007-01-08 修改文档适用于BUGZILLA 修改BUG状态
bug提交规范目录 一引言 (2) 1.1 编写的目的 (2) 1.2 定义 (2) 二Bug的组成因素 (2) 2.1 产品名称和组件名称 (3) 2.2 版本 (3) 2.3 Bug类型（由研发部标识） (3) 2.4 关键字 (3) 2.5 Bug状态 (4) 2.6 Bug优先级（由产品部标识） (4) 2.7 Bug摘要 (4) 2.8 Bug描述 (5) 2.8.1 能重现的bug (5) 2.8.2 不能重现的bug (5) 2.9 附件 (6) 三提交格式规范 (6) 四引发问题追朔版本标准 (7) 五附录 (8) 1 引言 1.1 编写的目的 RedOffice产品的多元化发展，bug数量的日益增多，那么提交bug的规范要求自然就要孕育而生。 经与研发部门相关负责人沟通后，制定了以下提交bug的一系列规范，希望测试人员能够严格按照此规范提交问题。 1.2 定义 我们一般把操作过程中发现不正确结果的问题称为bug。
2 Bug的组成因素 为了便于bug的管理、修改、查看，每条bug必须包含以下因素： 产品名称+组件名称+版本+产生时版本+类型+关键字+操作系统+级别+Bug 摘要+Bug描述+附件 其中红色字因素书面的测试报告中不必包含，蓝色字因素提交到Bugzilla 中时不必包括，但书面报告中要求涵盖。 2.1 产品名称和组件名称 产品名称：针对不同项目的不同立项； 组件名称：针对不同项目所划分的不同测试方向； 其中有关RedOffice的项目涉及到的组件名称，参见 “svn://172.20.69.219/test/TTech/测试控制文档/测试规范”目录下的《RO40 Component.mht》。 “产品名称”和“组件名称”由项目经理统一制定，测试人员提交bug时只需选择所测试的项目及对应的模块名称即可。 2.2 版本 版本：不同产品的内部过渡版本号。 其中Office项目版本的制定标准：平台简称（W/L）+产品名称（RO/OO）+产品生产日期：年月日（060412），如：WRO060412。 “版本”由项目经理统一制定，测试人员提交发现的bug时，只需选择所测试的内部测试版本的版本号。 产生时版本：该问题在Office版本的存在状况及引发问题时的版本。 当该问题在OpenOffice能重现，则在Bug描述的备注中写入OpenOffice相应的版本号； 当该问题在OpenOffice不能重现，则在Bug描述的备注中写入，该问题开
bug提交说规范
Bug 提交规范 如图 BUG发现处理流程（WOStore）： 1）提交BUG 指派给：Active 抄送：（此处目前不需要） 2）BUG分配 由郝伟琪负责根据模块不同的负责人，分配到不同开发人员。 3）BUG修复 由分配的开发人员负责修复BUG。并将状态更改为已经修复同时将指派给更改为BUG提交者。 4）BUG验证
由BUG提交者验证BUG是否已经解决，如果已经解决则将BUG状态更改为已经解决和关闭。 说明： 1.Build Version 填写格式 其中版本号由3位版本序列号和BUILD日期构成，例如：V0.1.2(2010-07-29) 查看版本号：黄色为软件版本号，可以在软件的“关于”中找到 红色部分为此版本发布的日期 2.机器配置格式 此处填写所测手机的品牌+型号（例如：dopod S610） 3.Bug严重级别(Severity，Bug级别)：是指因缺陷引起的故障对软件产品的影响程度。由测试人员指定。开发和测试统一成一个bug级别分类，取消bug优先级。 类型描述举例 1级我们的软件产品错误导致了死机、产品失败（“崩溃”）、造成软件运行受阻无法运行。与移 动产品规范不符合。1.死机，重启，飞信登陆失败 2.web：页面无法打开 2级产品中出现的一般性问题，主要是造成功能失效，或者会引起操作上重大误解的。1.输入法引起用户的误操作 2.Web：页面链接无法打开 3级产品在设计和开发中由于考虑不周引起的问题，即可能会造成系统在使用中会出错的隐患 或造成使用中会产生歧义的。1.输入法对于有键盘的手机和无键盘的手机区别 2.LG手机高亮之后字体颜色和背景颜色一样。 3.应该输入数字的地方能够输入英文或者字符。 4.web：页面排版问题 4级错误是表面化或微小的（提示信息不太准确友 好、错别字、罕见故障等），对功能几乎没有影 响，产品及功能仍可使用； 错别字 4.Bugfree中一个Bug的处理过程 新建一个Bug后，或者查询出符合条件的Bug们点击一个后，【右栏】显示该Bug详细信息。在中间的四个Action按钮，你可以： 1 Edit(编辑) 该动作允许你改动这个Bug所有可以改动的信息。最常见的是把这个Bug指派给(Assign To)某同事，同时在描述信息中加上你的新注释。 2 Resolve(解决) 一个Bug有7种解法： 当程序员看到BUG时要点击”解决”介入界面,填写修改BUG的意见和引起它产生的原因. (注:一定要写上你的修改的意见,以便测试人员在以后的测试中抓住问题的实质而不是停留在表象,给程序员在分析BUG时造成困扰;这些信息也是以后绩效考评的重要的参考) ?By Design - 就是这么设计的，无效的Bug ?Duplicate - 这个问题别人已经发现了，重复的Bug ?External - 是个外部因素(比如浏览器、操作系统、其他第3方软件)造成的问题
BUG规范
1、概述 Bug 系统主要的目的是实现项目组有效的管理开发过程应用程序的Bug，帮助项目经理和QA更好的定义项目最终结果的质量。 2、角色与职责 3、b ug 生命周期图 仍然按照现有qa的流程，不引入closed状态
4、新建bug 1、bug标题为包含关键字的简单问题摘要 如：20081030-1420:网络不通时，注册后的页面显示不规范。 2、指定正确的模块及产品信息 3、Bug指定给：选择具体的处理人，多为研发人员，需求相关可以指定给产品 4、抄送给：选择抄送给产品，开发负责人，测试负责人（） 5、严重程度，bug报告者指定，按如下标准指定 严重性： Critical（非常严重） 表现：导致机器蓝屏、死机、重启等；严重的安全性问题，重要数据丢失等； 影响：使用户无法正常使用机器，给用户的重要信息造成无法恢复的影响 举例：如重要数据丢失，不断重启机器
Block：（致命） 影响：阻碍开发和测试的继续工作。必须立即修改甚至重新评估开发。 表现： 1．需求书中的重要功能根本未实现； 2．由程序本身造成的系统崩溃、死机, 并且不能通过其它方法实现功能； Major（严重） 表现：主要功能完全丧失；主要逻辑错误、异常等 影响：导致用户无法使用系统的主要功能 举例：无法添加用户，无法对恶意软件进行查杀 Normal（一般） 表现：一般功能丧失；一般逻辑错误、异常等 影响：导致用户无法使用系统的非主要功能； 举例：添加用户后无法发送通知邮件，恶意软件查杀不干净；注意：如果通知邮件只是起备忘作用那是Normal，如果邮件是密码的唯一获取方式，那应该是Major Mini（小） 表现：小功能问题；小逻辑错误、异常；UI相关等 影响：并没有给用户带来很大的影响，基本不影响用户正常使用系统 举例：数据提交后显示半个字，本应该在新窗口打开却在原窗口打开，页码显示错误等； enhancement（建议） 表现：产品改进方面 影响：没有导致系统功能及其他方面的错误 举例： 提建议务必enhancement，要特别区分bug和enhancement 综上：判断bug的严重性遵循如下原则：结合被测系统，依据出现的现象对用户机器、整个系统以及给用户感受带来影响的大小进行判断。 6、优先级，bug报告者指定，按如下标准指定（不做严格要求） P1：尽快修复，已经阻止了相关功能的进一步测试，须在下个提交测试的版本修正 P2：发布之前必须修改 P3：问题比很小或问题出现几率很小，不影响发布。时间允许尽量修改，或许可以延期P4：所有建议enhancement选择P4级 7、Bug类型 Function（功能错误） 业务逻辑，程序逻辑，安装、升级更新等功能等 Links（链接相关问题）
BUG编写标准和管理办法
BUG编写标准和管理办法 1、目的 BUG的编写标准的规范，主要为是为了规范测试人员提交BUG的格式；可以使开发人员快速根据BUG进行定位，根据BUG现象迅速定位问题的本质，同时也方便测试人员对BUG进行重现，在回归版本发布后能够根据BUG描述有效的进行回归测试。 2、范围 此文档适合测试人员内部使用，适合于任何产品和项目。 3、BUG编写标准及方法 3.1、产品名称：每个要测试的软件项目都有唯一的名称，在bug管理工具中添加测试的项目，在录入bug时先自行选择所测试的项目。 3.2、缺陷ID:bug的唯一标识，由bug管理工具自动生成。 3.3、测试版本：报告错误时，一定要正确填写产生错误的软件版本号，录入bug时可选择相应的版本号。 3.4、基本信息：bug的类型、严重程度以及处理的优先级；bug所属模块；测试者名称；测试时间；指派的开发人员；这些项都在bug录入时进行选择。 3.5、缺陷标题：简明扼要地对bug进行概要描述。 3.6、bug详细描述： A、环境：缺陷应该描述缺陷测试的基本环境，因为在某种特定的环境下，才能重现缺陷，所以环境对于一个BUG来说非常重要。软件环境：操作系统和其他必要的软件程序（比如：操作系统：Windows XP Professional SP3 32 位；浏览器：Microsoft Internet Explorer 8.0）；硬件环境：测试计算机和其他设备的配置信息（比如：处理器（CPU:英特尔酷睿；速度：3.20GHz）；内存： 3.47GB；屏幕分辨率：1024 x 768；可用硬盘空间：100G）。 B、步骤：测试人员需要详细描述BUG产生的步骤，是因为什么样的操作步骤才会产生对应的操作步骤；如果不按照测试人员描述的操作步骤，是不能