BUG需求提交规范
提交bug的书写规范
提交bug的书写规范提交bug的内容书写规范：1. 标题：【项⽬名称——简短的bug说明】描述bug的最主要关键词，如xx项⽬——数据库输⼊输出数据不⼀致2. 项⽬名称：【项⽬名称+项⽬版本号】3. Bug所属项⽬/模块：Bug所属项⽬和模块，最好能较精确地定位⾄模块；4. 严重等级：【紧急，严重，⼀般，微⼩】l 紧急Bug：造成系统或应⽤程序崩溃(Crash)、死机、系统悬挂，或者造成数据丢失、主要功能完全丧失等。
l 严重的Bug：功能或者特性没有实现，主要功能部分丧失，次要功能完全丧失，或者致命错误声明。
l ⼀般的Bug：不太严重，虽然不影响系统的基本使⽤，但没有很好地实现功能，没有达到预期效果。
如：次要功能丧失，提⽰信息不太准确，或⽤户界⾯差，操作时间长等。
l 微⼩的Bug：对功能⼏乎没有影响，产品及属性仍可使⽤，如有个错别字、⽂字排列不整齐等。
5. 优先级：【P1，P2，P3，P4】P1：⽴即解决，导致系统⼏乎不能使⽤或测试不能继续，需要⽴即修复；P2：⾼优先级，严重，影响测试，需要优先考虑；P3：正常排队，需要正常排队等待修复；P4：可以在开发⼈员有时间的时候再纠正；6. Bug状态：【New，Open， Fixed， Rejected， Delay ，Closed， Reopen】l New: 新发现的bug，开发⼈员尚未确认；l Open：确实是bug，并认为需要修改，指派给相应的开发⼈员；l Fixed：开发⼈员进⾏修改后标识成修改状态，有待测试⼈员的回归测试验证；l Rejected：如果认为不是bug，则决绝修改；l Delay：暂时不修改或者暂时不能修改，则延后修改；l Closed：fixed状态的Bug经测试⼈员回归测试验证通过，则关闭Bug；l Reopen：fixed状态的Bug经验证仍然存在，则需要重新打开Bug，开发⼈员重新修改；7. 测试环境：【硬件设备环境，软件设备以及配置环境，具体到使⽤的版本号，类型号】测试⼈员要充分说明测试环境的情况，以便开发⼈员可以快速定位错误，防⽌出现因开发环境与测试环境不符，⽽⽆法重现bug的情况。
BUG管理规范
BUG管理规范一、引言在软件开发过程中，经常会出现各种各样的问题和错误，其中最常见的就是软件缺陷（BUG）。
为了有效地管理和解决这些问题，制定一套BUG管理规范是非常重要的。
本文旨在提供一套详细的BUG管理规范，以帮助团队成员更好地管理和解决BUG。
二、BUG管理流程1. 提交BUGa. 开发人员在发现BUG后，应及时记录并提交BUG报告。
b. BUG报告应包含以下内容：BUG的描述、复现步骤、期望结果、实际结果、BUG的严重程度、影响范围等。
c. 开发人员应尽量提供详细的复现步骤和截图等辅助信息，以便测试人员更好地理解和复现BUG。
2. 分类和优先级a. 测试人员在接收到BUG报告后，应对BUG进行分类和评估优先级。
b. 常见的分类包括功能性BUG、性能BUG、界面BUG等。
c. 优先级评估应根据BUG的严重程度和影响范围来确定，常见的优先级包括高、中、低三个级别。
3. 分配和跟踪a. 测试人员将已分类和评估优先级的BUG分配给相应的开发人员。
b. 开发人员在接收到BUG后，应及时确认并开始解决。
c. 开发人员应在解决BUG的过程中，及时更新BUG状态，并保持与测试人员的沟通。
4. 解决和验证a. 开发人员在解决BUG后，应及时更新BUG的解决方案，并提交给测试人员进行验证。
b. 测试人员应根据解决方案进行验证，并在验证通过后关闭相应的BUG。
c. 如果验证不通过，测试人员应重新打开相应的BUG，并提供详细的验证结果和反馈给开发人员。
5. 统计和分析a. 测试团队应定期进行BUG统计和分析工作，以便发现和解决常见的BUG问题。
b. 统计和分析的内容包括BUG的数量、解决速度、解决率等。
c. 根据统计和分析的结果，测试团队应及时调整和改进BUG管理流程，以提高BUG的解决效率和质量。
三、BUG管理工具为了更好地管理和追踪BUG，团队可以使用专业的BUG管理工具。
常见的BUG管理工具包括JIRA、Bugzilla、Mantis等。
软件测试BUG提交规范_模板
软件测试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.备注二、BUG提交注意事项1．请测试人员提交新缺陷时，尽量用最简洁的语言最清晰的描述出BUG的出处、操作步骤、现象、（建议），并尽量截图；2. 当你的BUG报告以“not repro（不可重现）”打回给你时，测试人员应该反复阅读它，集中剔除那些没有关系的步骤或词语，再检查是否有遗漏或清晰的步骤，再去找研发人员。
研发人员通常是在无法用BUG报告中的步骤重现BUG时才选择这个选项；3. 测试人员在精简空话的同时，应该再仔细检查报告是否会产生误解的地方。
测试人员应该尽量避免使用模糊的，会产生歧义的、主观的词语。
目标是使用能够表述事实、清楚的，不会产生争执的词语；4. 不要使用感叹号或其它表现个人感情色彩的词语或符号；5. 不要使用含糊的词语（例如，好像，似乎）或网络语言来描述发现的现象；三、需要注意的地方当你发现一个BUG时，请考虑如下问题：1. 同一软件中的相似功能是否有相同的问题？2.其他的浏览器是否有相同的问题？3. 其他的软硬件配置是否有相同的问题？4. 其他的区域是否有相同的问题？5.以前的版本是否有相同的问题？四、Bug的严重等级1.致命BUG，包括以下各种错误：1.由于程序所引起的死机,非法退出2.死循环3.导致数据库发生死锁4.因错误操作导致的程序中断5.严重的数值计算错误2.严重BUG，包括以下各种错误：1.功能不符2.数据流错误3.程序接口错误4.轻微的数值计算错误3.一般性BUG，包括以下各种错误：1.操作界面错误(详细文档)2.打印内容、格式错误3.简单的输入限制未放在前台进行控制4.删除操作未给出提示4.提示性BUG，包括以下各种错误：1.界面不规范2.辅助说明描述不清楚3.显示格式不规范4.长时间操作未给用户进度提示5.提示窗口文字未采用行业术语6.可输入区域和只读区域没有明显的区分标志7.系统处理未优化5.测试建议（非BUG）：界面重构、描述更改、流程改进。
JIRA 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)常用的BUG 管理工具有JIRA、BugFree、Bugzilla、Mantis、XPWeb 等。
我们公司采用的是JIAR，JIRA 是Atlassian 公司出品的项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求采集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。
BUG 就是指系统存的各种缺陷，可以从不少角度对BUG 进行分类。
A.重复的功能；B.多余的功能；C.功能没有达到设计的要求；D.功能实现与设计要求不相符。
A.界面不美观，控件罗列、格式不统一，焦点控制不合理或者不全面；B.缺少匡助信息，或者匡助信息不彻底；C.功能操作复杂，提示信息不合理，易产生歧义。
A.数据有效性检测不合理；B.重要数据在传输中没有加密；C.缺少身份认证机制或者认证不合理；D.数据产生缺乏随机性；E．网络安全性：开放端口、服务；F ．系统日志、审计。
A.数据存贮的可靠性；B.业务处理的可靠性；C．硬件可靠性：如打印机；D.应急处理措施；E ．数据备份、恢复。
A．并发量；B．吞吐量； C ．响应时间。
A．硬件兼容性； B ．软件兼容性。
A．可扩展性； B ．方便升级。
BUG提交规范
修改记录 是否需要修改结论
职责 提交 BUG 验证 BUG 激活 BUG 关闭 BUG 修改 BUG 更改 BUG 状态 说明修改 BUG 内容范围 确认设计性 BUG
确认 BUG 修改 BUG 说明修改 BUG 内容范围 确认 BUG 所属项目 确认 BUG 修改人员 解决 bug 冲突
3. BUG 提交规范
重现步骤： 步骤：接口名+请求的报文内容。 结果：实际响应的报文结果。 期望：期望响应的结果描述。
3.4、图例
4. BUG 跟踪和关闭
跟踪原则： 自从 BUG 提交之日起，测试人员要不断跟踪 BUG，直到 BUG 修正，问题解决为止。 规范： 1、1 级 BUG 必须要求开发当天)解决或给出解决方案，测试需在出版本后的 4 工作小时
3.1、AD 流程类 BUG
在 ERP 或者 OWMS 操作过程中发现的 BUG。在提交 BUG 过程中，提交后，为了方便开发定 位跟踪问题，需要提供页面操作后，服务器控制台输入的 log 日志串。
3.2、卖家网站或 PHP 类 BUG
3.2.1、页面类 BUG。
需要提供截图
3.2.2、与后台交互类 BUG
BUG 类型： 代码错误 界面优化 设计缺陷 配置相关 安装部署 安全相关 性能问题 标准规范 测试脚本
严重程度：
1、致命缺陷 2、严重缺陷 3、一般缺陷 4、提示/轻微缺陷
Bug 严重程度及优先级请参考《Bug 的严重程度及优先级.doc》
需要在备注信息中提供交互 soap 请求。
与后台交互类 BUG 一般确认方式： 卖家页面是没有连接 oracle 数据库的，一般存储在 ERP 的 oracle 数据库中的信息在卖家
页面只能通过调用 API 接口查询。卖家页面涉及到 ERP 后台数据的操作一般都为后台交互类 B。
禅道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.测试人员发现bug3.2.测试人员创建Bug测试人员登录禅道系统，创建Bug。
Bug状态为激活（未确认）创建Bug页面截图：页面字段注释：所属产品：选择发现Bug的产品，必填项。
所属模块：选择发现Bug的对应模块，必填项。
所属项目：选择测试所属的项目。
必填项。
影响版本：选择发现bug的版本。
必填项。
当前指派：选择指派的开发人员。
必填项。
Bug标题：用简单明了的语句说明Bug内容，相当于BUG的中心语句。
必填项。
在标题上注明bug出现的频率（稳定出现/经常出现/很少出现/出现一次）重新步骤：重现步骤格式如下。
必填项。
[环境]：如果系统/浏览器信息不能够全部说明发现Bug的环境，需要在重现步骤里详细描述环境信息，以便于开发定位和解决问题。
[步骤]：写明出现Bug的操作步骤，要求简单，去掉与Bug无关的步骤。
[结果]：写明操作的实际结果。
[期望]：写明操作的期望结果。
相关需求：选择与Bug相关的需求。
如果Bug关联测试用例，系统会自动关联测试用例的需求。
相关任务：选择与Bug相关的任务。
这里的任务是在『项目』->『任务』中创建的任务。
Bug类型如下：代码错误：功能性错误。
测试组bug提交规范
测试组bug提交规范.doc测试组Bug提交规范一、引言本文档旨在规范测试组在软件测试过程中发现Bug的提交流程，确保Bug的记录、跟踪和管理过程标准化、系统化，以提高问题解决的效率和质量。
二、Bug定义Bug是指软件产品中存在的缺陷，它导致软件不能按照预期的功能、性能、可靠性、安全性等要求正常工作。
三、Bug提交流程发现Bug：测试人员在测试过程中发现Bug。
记录Bug：在发现Bug后，立即记录Bug的详细信息。
验证Bug：对Bug进行复现，确保Bug的可复现性。
提交Bug：通过Bug跟踪系统提交Bug。
分配Bug：Bug跟踪系统将Bug分配给相应的开发人员。
修复Bug：开发人员修复Bug。
验证修复：测试人员验证Bug修复后的结果。
关闭Bug：确认Bug修复无误后，关闭Bug。
四、Bug提交要求标题：Bug标题应简洁明了，能够准确描述Bug现象。
描述：详细描述Bug的触发条件、现象、预期结果和实际结果。
重现步骤：列出重现Bug的具体步骤。
附件：提供相关的截图、日志文件或其他辅助材料。
严重性：根据Bug对产品的影响程度，划分Bug的严重性等级。
优先级：根据Bug的严重性和修复的紧迫性，确定Bug的优先级。
版本：指明发现Bug的产品版本。
模块：指明Bug所在的产品模块。
测试环境：描述测试时的硬件、软件和网络环境。
五、Bug跟踪系统选择系统：选择适合团队使用的Bug跟踪系统。
账号管理：为测试人员和开发人员分配账号。
权限设置：根据角色设置不同的权限。
数据备份：定期备份Bug数据。
系统维护：定期检查和维护Bug跟踪系统。
六、Bug管理Bug状态：定义Bug的不同状态，如新建、已分配、修复中、已验证、已关闭等。
Bug跟踪：跟踪Bug的修复进度和状态变化。
Bug统计：定期统计Bug的数量、类型、严重性等信息。
Bug报告：生成Bug报告，向管理层和团队成员报告Bug情况。
七、Bug沟通与协作沟通机制：建立Bug沟通机制，确保信息的及时传递。
BUG处理流程规范
BUG处理流程规范bug提出和处理流程规范1导言1.1目的提高检测和产品缺陷修改的效率，避免搁置和遗漏缺陷，从而提高产品质量，降低质量检验和缺陷修改的成本1.2适用范围适用于研发部、质保部，适用于flash部1.3定义缺陷：通过测试发现的产品缺陷；新建、打回、已确认、已指派、已解决、已关闭：测试中bug的不同状态，详细信息见本规范第3部分；1.4参考文献无错误提交和处理规范1、在测试人员提交bug的时候，必须对bug信息进的描述必须详细全面、清晰明确，如果有条如果你想捕获一张图片，你必须捕获JPG的全屏图像，但你不能以BMP格式将其上传到bug库。
如果有包捕获文件，则需要将其上载到bug库。
如果没有足够的空间，你需要把它放进去\\\\192.168.0.254\\qa\\测试\\bug日志目录中，标题以bug号区分；2.提交错误时，测试人员必须根据具体情况填写重要性、频率和优先级三栏目，而非测试人员不得对上述信息进行直接改变，如觉得这三个信息填写不恰当，可以在该在缺陷下的意见中提出意见，确认后“回电”给缺陷提交人或质量部经理进行修改；3、开发人员对bug进行处理后的变更状态成“打回”时，或“指派”给产品部门时以及变更成当“确认”时，必须对其进行描述和解释。
当状态发生变化时，必须指定具体的接收者；4、开发人员在注解中描述该bug计划什么时候解决或做其他阐述的时候，要明确写清承诺的具体版本号禁止使用“上一版”、“本版”、“下一版”等字样，以免产生误解或混淆；在修改后的错误注释中添加相关确认信息，如“xxreview and pass”。
5、如果已经是“关闭”状态的bug，测试人员在后期测试中又出现了需要重新打开，重开后的错误状态为“回调”，测试人员需要另一个操作，即“分配”给特定的研发人员。
6.如果在两轮（即两个版本）测试后仍然没有重新出现，则处于“返回”状态的错误可以关闭。
然而，这两轮测试必须在bug中进行注释，例如：“XX版本（特定要求）版本号）测试没有重现”，当第二轮测试仍没出现时也需要注释一次，即可进行关闭。
提交bug的标准及书写规范
提交bug的标准及书写规范Bug有效性1、交付过程中测试者需按照专家设定好的模块，对Bug进⾏归类提交；2、Bug的类型默认为UI问题、功能问题、崩溃问题，提交Bug时不能弄错；3、需求是否明确、前提条件是否满⾜、输⼊数据是否正确、操作步骤是否清楚、Bug是否唯⼀性；4、避免提交设计如此、操作错误、重复的、已知的Bug；5、尽量少花时间在边界值、页⾯显⽰问题上，多提业务逻辑功能、交互测试⽅⾯的问题；Bug标题Bug标题要求简明扼要的阐述问题本质，使查看⼈员能快速了解Bug内容。
需要写明在哪个页⾯执⾏什么操作出现什么现象。
特别提醒：1.标题中标点符号不能超过1个2.标题中不能含有测试流程步骤和模块信息测试设备：提交Bug要表明测试使⽤的设备、设备操作系统版本、测试环境、⽹络类型等等。
前提条件明确指出所提交的Bug是在怎么样的情况下出现的，当所发现Bug前提条件为空时，需要填【⽆】。
测试步骤要简明清晰分步骤描述如何复现Bug问题，步骤⽤序号编排。
要按照⾃⼰的操作的实际步骤写清楚每⼀步是怎么操作的，最后操作到哪个页⾯或者点击哪个按键。
如在特定情况下发⽣的问题，还需明确提供以下信息：1.准确写出连续点击次数，点击时长与上下滑动屏幕时长。
2.对于特定数据产⽣的问题，提供具体数据。
3.精准描述bug产⽣的路径后，再描述现象。
特别提醒：测试步骤中的点击要⽤->符号连接期望结果按照测试步骤应当得到的正确结果，按照产品需求的期望清晰准确的填写预期结果。
⽽且结果必须是肯定⽆疑义，可判定性的结果。
特别提醒：期望结果不要包含测试步骤，要是简单的⼀个结果实际结果按照测试步骤实际出现的错误结果，避免使⽤“不正常”，“有误”等模糊词汇，需要直接描述实际现象。
特别提醒：期望结果和实际结果要相互对应复现步骤描述及概率描述复现步骤中的页⾯切换为避免出现描述不清晰或者有歧义，需⽤“->”符号连接关于复现概率⼀定要在多次测试的基础之上填写，若必定复现则填写100%，若偶现，请执⾏多次后统计概率填写。
Bug提交与管理规范
Bug的状态
• 新建状态（ NEW ） Bug创建后的初始状态。 • 已分配状态（ASSIGNED） 经过确认为合法软件问题后分配给开发人员的状态。 • 待验证状态（RESOLVED） 开发部门对软件问题进行处理或修改后的状态。 • 重新打开状态（REOPENED） 对开发部门修改后软件问题，经过验证，如果仍然存在，则将其状态 改为“重新打开”状态。对于“关闭/延迟修改”状态的软件问题， 如果时机成熟，需要重新开发，则将其状态改为“重新打开”状态。 • 关闭状态（CLOSED） Bug生命周期的结束。 • 解决状态（VERIFIED） 经测试部门对修改后的软件问题进行验证并确认修改正确后的状态。 • 未经证实状态（UNCONFIRMED） 由开发人员自己提交的Bug，是一种初始状态，待测试人员确定后变 为“New”。
如还有问题，Reopened
验证bug
Verified bug
测试人员验证已修改的 Bug 1、测试人员查询开发者已修改的bug，即Status为 "Resolved",Resolution为"Fixed".进行重新测试。 2、经验证无误后，修改Resolution为VERIFIED 3、若还有问题，REOPENED，状态重新变为“New"，并发邮 件通知
实际结果 期望结果
出现频率 文字注释与 附图
描述实际测试后得到的结果。 描述满足设计要求的结果。
测试组bug提交规范
测试组Bug提交规范文档编号：{文档编号}当前版本号：0.10最初发布日期：2013-05-22最新修订日期：2013-05-22公司名称：深圳市海亚科技发展有限公司地址：深圳市龙岗区宝龙工业城诚信路8号亚深创新科技产业园办公楼9楼邮编：5180001.1 文档目的....................................................................... 错误！未定义书签。
1.2 文档范围....................................................................... 错误！未定义书签。
1.3 读者对象....................................................................... 错误！未定义书签。
1.4 参考资料....................................................................... 错误！未定义书签。
1.5 术语表........................................................................... 错误！未定义书签。
第2章Bug提交 ........................................................................ 错误！未定义书签。
2.1 Bug模块划分以及版本号选择.................................... 错误！未定义书签。
2.2 Bug严重程度及优先级................................................ 错误！未定义书签。
2.3 操作系统....................................................................... 错误！未定义书签。
BUG提交规范初稿
目录1、BUG管理系统 (2)2、BUG状态转换 (2)2.1 BUG全部状态 (2)2.2 BUG状态转换图 (2)3、BUG优先级确定 (3)4、特定BUG处理规则 (4)4.1选择已拒绝状态处理规则 (4)4.2选择打回状态使用规则 (4)4.3是否修复引起新BUG规则 (5)4.4 是否BVT_BUG规则 (5)4.5概率性BUG复现处理规则 (5)1、BUG管理系统http://190.15.252.126:8085/redmine/login 2、BUG状态转换2.1 BUG全部状态2.2 BUG状态转换图1、[新建状态] 测试人员新建BUG，提交到BUG系统里面，BUG状态为新建2、[已解决状态] 当开发人员修复了BUG，改状态为已解决3、[已关闭状态] 测试人员，搜索各自提交的BUG里面，状态是已解决的BUG，进行回归，如果彻底解决，则选择已关闭4、[挂起状态] 对有些问题，存在一些原因暂时不能修复，比如修复后影响到其他功能；修复成本很高；存在技术难题，一时没有找到好的方法进行修复；其他原因等，向上级领导反馈了这个情况，同意可以挂起，那么开发组长可以选择挂起状态。
5、[已拒绝状态] 凡是开发认为不需要修复BUG，都可以选择已拒绝状态。
这种状态产生，常常有这些情况，比如开发人员认为不是BUG；开发人员觉得不值得改，整个风格都是这样，不影响用户使用；设计如此；业务如此等。
6、[打回状态] 回归测试过程，如果已解决状态BUG没有修复，则选择打回状态。
7、[已拒绝状态] 需要指派给领导确认（张小强、张余祥、马春吉），必要时候，测试组组织拒绝BUG确认会，相关人员参与。
8、[挂起状态] 定期（两周）测试组人员进行汇总，进行过滤确认，邮件发给领导进行是否修复确认，如果修复，时间点的确认；如果不修复，测试人员关闭。
3、BUG优先级确定目前我们系统提交BUG优先级，根据我们实际情况，初步设定四种：紧急，高，普通，低BUG优先级选择，尽量尊重大众共识，依照大的原则，尤其是选择紧急，或高时，特别注意：（1）考虑出现的概率（2）出现BUG，其他操作方式是否可恢复，即恢复机制（3）如果功能没有办法用，有没有规避措施（4）用户使用程度主要从用户使用角度，频率，重要性，问题影响面等来确定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详细信息。
BUG管理规范
BUG管理规范一、引言在软件开发过程中，由于各种原因可能会出现各种BUG（缺陷、故障），为了保证软件的质量和稳定性，需要对BUG进行有效的管理和处理。
本文旨在制定一套BUG管理规范，以便团队成员能够准确、高效地管理和解决BUG。
二、BUG管理流程1. BUG提交项目成员在发现或遇到BUG时，应及时将其提交到BUG管理系统中。
BUG管理系统可以是专门的软件工具，也可以是团队内部自行搭建的系统。
BUG提交时应提供详细的描述，包括复现步骤、预期结果和实际结果等信息。
同时，可以附加相关的截图、日志或其他辅助材料。
2. BUG分类和优先级提交的BUG需要进行分类和优先级的划分。
常见的分类包括界面问题、功能问题、性能问题等。
优先级一般分为高、中、低三个级别，以确定处理的紧急程度。
3. BUG分析和确认项目负责人或质量保障人员负责对提交的BUG进行分析和确认。
他们需要验证BUG是否能够复现，并对其进行进一步的调查和分析。
如果发现BUG确实存在，将其确认为有效BUG，并进行相应的标记。
4. BUG分配和跟踪确认有效的BUG将被分配给相应的开发人员进行修复。
BUG管理系统应具备分配和跟踪功能，以便项目成员能够清晰地了解每个BUG的处理进度和责任人。
5. BUG修复和验证开发人员在接到BUG后，应及时进行修复工作。
修复完成后，需要进行验证，确保修复后的软件没有引入新的问题，并且BUG得到了有效解决。
6. BUG关闭和反馈经过验证的修复BUG将被关闭，并在BUG管理系统中进行标记。
同时，可以向提交BUG的成员反馈修复结果，以便他们了解问题的解决情况。
7. BUG统计和分析项目负责人或质量保障人员应定期对BUG进行统计和分析。
统计数据可以包括每个阶段的BUG数量、修复效率、修复质量等指标，以便评估项目的质量和进展情况。
三、BUG管理规范1. 提交规范- 提交BUG时，应提供详细的描述，包括复现步骤、预期结果和实际结果等信息。
BUG管理规范
BUG管理规范一、引言在软件开发过程中，不可避免地会出现各种各样的BUG（缺陷）。
为了有效地管理和解决这些BUG，提高软件质量和用户满意度，制定本BUG管理规范。
二、定义1. BUG：指软件中存在的错误、缺陷或异常行为。
三、BUG管理流程1. BUG提交a. 开发人员在开发过程中发现BUG，应立即将其提交至BUG管理系统。
b. 用户或测试人员在测试过程中发现BUG，应详细描述BUG并提交至BUG管理系统。
c. BUG提交时应包括以下信息：- BUG标题：简明扼要地描述BUG的内容。
- BUG描述：详细描述BUG的现象、复现步骤、影响范围等。
- 优先级：根据BUG的紧急程度和影响程度，分为高、中、低三个级别。
- 附件：如截图、日志等，有助于更好地理解和解决BUG。
2. BUG确认和分配a. 由BUG管理人员对提交的BUG进行确认，确保BUG的准确性和完整性。
b. 根据BUG的优先级和相关人员的负荷情况，将BUG分配给相应的开发人员。
c. 分配时应明确指定负责人，并在BUG管理系统中记录。
3. BUG解决a. 开发人员根据BUG描述和附件进行问题分析和定位。
b. 开发人员解决BUG并进行相应的代码修改。
c. 修改完成后，开发人员应在BUG管理系统中更新BUG的状态，并将解决方案和修改的代码提交。
4. BUG验证a. 测试人员根据BUG管理系统中的记录，验证开发人员提交的BUG解决方案是否有效。
b. 如果BUG仍然存在，测试人员应将BUG重新分配给开发人员，并要求其重新解决。
c. 如果BUG已经解决，测试人员应在BUG管理系统中更新BUG的状态，并进行相应的测试确认。
5. BUG关闭a. 当BUG经过验证后，确认已经解决且符合预期时，BUG管理人员将其关闭。
b. 关闭时应在BUG管理系统中记录相关信息，如关闭原因、解决方案等。
四、BUG管理系统1. 选择适合团队的BUG管理系统，如JIRA、Bugzilla等。
Bugfree提交BUG的书写规范_0907
Bug提交规范一、描述规范：执行哪几个操作步骤可以重现一个什么样的BUG(测试结果)，这个问题在需求或交付标准中是如何界定的（预期结果）！二、书写规范1. 每条错误报告只包括一个错误；2. 如果打开某个特殊的文档而产生的缺陷或错误，则必须附加该文档，从而可以迅速再现缺陷或错误。
3. 为了使缺陷或错误修正者进一步明确缺陷或错误的表现，可以附加个人的修改建议或注解。
4. 需与需求中要求的结果一致，若需求不明确需注明；5.对于无法重现之BUG需与测试负责人沟通确认是否提交6.对于难以重现的BUG需确认其出现几率，统计测试次数及BUG出现次数，记录测试环境及测试步骤，便于开发人员定位。
7.在BUG描述中不能出现不明确的字句，所有无法确认的结果都需要提交科学的测试数据，以数据体现其结果，以便定位问题。
三、明确责任人需明确BUG指派给谁，一般是直接指派给开发人员，当项目紧急仅需要部分重要bug时，可将所有bug指派给项目经理，有项目经理过滤优先级后再指派给具体的开发人员。
五、明确BUG 严重等级和优先级严重程度：①严重——引起系统崩溃，死机，卡死等情况的BUG②主要——影响系统功能操作，主要功能错误或未实现的BUG③次要——界面上或性能上的BUG④轻细——操作体验或建议性的BUG优先级：①紧急——需立即处理完成的BUG②尽量加快——需尽快处理完成的BUG③按时——正常等待按时处理的BUG④轻细——有时间再处理的BUG六、BUG修改者明确解决方案无效BUG：By Design——需求设计如此Duplicate——这个问题别人已发现，重复的BugNot Repro——无法复现的问题有效的BUG：Fixed——问题被修复External——外部原因（如浏览器、操作系统、其他第三方软件）造成的问题Postponed——发现的太晚，或问题在此版本不关注，可在下一个版本讨论是否解决Won’t Fix——是个问题，但不值得修复。
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流程及提交模板◆BUG流程常规流程1.发现一个缺陷，将其提交至Bugzilla。
此时Bug状态为confirmed（确定）。
如图：2.产品或开发人员修改Bug，修改后将Bug置为resolved fixed（已修改）状态。
如图：3.由测试人员严重该Bug，验证通过后改为verified fixed（验证通过）状态。
非常规流程以下四中情况请修改Bug人员特别注意，如图1.若提交的Bug不能算是Bug（即提交者提交错误），则将Bug置为Resolvedinvalid（不是Bug）状态。
并在下方添加备注说明不是Bug的原因。
2.若提交的Bug确实存在，但由于技术、时间有限在很长一段时间内不予修改或永久不修改，则将该Bug置为Resolved wontfix（不修改）状态。
并在下方添加备注说明不修改的原因。
3.若提交的Bug与另外一个Bug重复，则置为Duplicate（重复）状态，并将类似Bug的编号填写其中。
4.若提交的Bug在目前的版本或本地测试环境下无法重现，则置为Worksforme（无法重现）状态。
注：请确保已经和提交者或决策人经过沟通后，再将Bug置为非常规状态。
◆BUG提交原则1.清晰准确——解释到位，能够让其他人理解这个Bug是什么意思2.相同的Bug不能重复提交3.再微小的Bug也需要提交——因为小Bug有可能隐藏大隐患◆提交前准备1.将Bug在最新的版本上重现一遍，看是否已经被修改2.在Bugzilla中搜索一下，看这个Bug是否已经提交◆BUG模板Bug模板【项目阶段】【版本号】+标题：Bug的简要描述。
一定要能从标题就看出Bug的大概意思【测试网址】：测试用的服务器网址【详细描述】：Bug的详细描述，包括此Bug的重现步骤、具体现象、及可能有的影响。
如果有必要请添加图片。
【期望结果】：此Bug修复后期望的结果是什么。
请务必在明确期望结果的情况下再提交Bug。
【备注】：有另外需要说明的请在此处记录。
Bug报告提交规范
Bug报告提交规范⾸先声明，bug的测试规范应该在公司的正式⽂档建⽴。
本建议⾮正式⽂档，有些内容可能不正确，有些内容可能需要继续商榷，甚⾄有些内容同公司规范有冲突。
如果发现问题，直接忽略本⽂相应内容。
本帖本意仅就⼯作中的⼀些现象记录，可以通过简单规范让⼤家⼯作轻松，⾼效。
后续继续补充修改，也请⼤家补充修改。
其次，本帖也仅就填写bug报告的⾏为进⾏了⼀些梳理和建议，不能取代正式的bug测试流程或质量管理过程。
内容：填写bug报告，可能是专门的测试⼈员或者开发⼈员，甚⾄其他临时帮忙或者最终⽤户。
发现bug和解决bug是⼀件⾮常重要的⼯作。
⼤家的⽬的都是为了软件能够安全、稳定运⾏起来，提交bug的⼈同解决bug的⼈⽬标是⼀致的，⽽不是对⽴的，不是找⿇烦。
测试⼯作其实⾮常复杂和繁重，发现问题仅仅是第⼀步，更重要的是确定是bug，是不是可以重现，跟正确结果的差别在哪⾥。
最终提交的bug不要让修复者重复太多⼯作才能重现，也不要让修复者猜测或者试验⼒。
最快让修复者找到问题是关键。
如果修复者花费太长时间琢磨⼀个bug报告的重现，最好还是直接演⽰给他看，这是最有效的⽅式。
基于这些共识，我们希望达成⼀致的规范。
提交者规范建议：1.提交bug是针对真实存在的缺陷。
那些偶尔出现的bug，提交者尽量找到重现的真正原因。
如果可能，尽量在2个不同终端上可以确定重现。
如果没有2台终端，⾄少⽤2种浏览器或者2个虚拟机等⽅式模拟重现出来。
2.如果是浏览器兼容问题，确定重现步骤后，bug报告中尽量写清哪个类型浏览器，版本号，语⾔，以及设置⽅式。
3.描述清楚。
有些bug是需求没有满⾜，但是没有其他崩溃结果哦出现，尽量将“期待”的内容和“实际”的情形区别开，如，⼀个bug，⼀个按钮点击后的“需求”是打开窗⼝，实际运⾏结果是转到另外⼀个地址。
转移地址是错误的，就要告诉修复者。
⽽不是报告：这个点击按钮后转到了⼀个新地址。
修复者有时理解成需求是要转移到⼀个新地址，结果他看到的就是这个结果。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
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、问题图片：
D、解决方案：
7. 客户名称：茂名腾云电子（需求）
A、问题描述：手机客户端邮件来了无声音提醒，需要增加此功能。
B、问题出现操作步骤(问题出现操作步骤里面要包含客户目前版本号)：
4.6版本
C、问题图片：
D、解决方案：
8. 客户名称：茂名腾云电子（需求）
A、问题描述：编辑邮件时，勾选跟进能填写跟进文本内容，然后自动生成跟进记录。
B、问题出现操作步骤(问题出现操作步骤里面要包含客户目前版本号)：
4.6版本
C、问题图片：
D、解决方案：。