如何发现及准确描述BUG报告
提高Bug报告的简洁度和准确度
提高Bug报告的简洁度和准确度Bug报告是软件开发过程中必不可少的一环，它能帮助开发人员快速定位和修复软件中存在的问题。
然而，有时候我们会发现一些Bug报告过于冗长或者不够准确，导致开发人员难以理解和处理。
为了提高Bug报告的简洁度和准确度，本文将分享一些有效的方法和技巧。
一、简洁的Bug报告格式简洁的Bug报告格式能够让开发人员更加清晰地理解并快速定位问题。
以下是一种常用的Bug报告格式示例：1. 摘要描述Bug的简洁而准确的标题，概括问题的关键信息。
2. 重现步骤详细描述导致Bug出现的具体步骤，包括操作流程、输入数据和预期结果。
3. 实际结果描述实际出现的问题或错误，并提供相关的错误提示或日志信息。
4. 期望结果清晰明确地说明你希望的正确行为或结果是什么。
5. 系统环境提供Bug出现的系统环境信息，包括操作系统版本、浏览器类型和版本、设备型号等。
6. 附加信息如果有其他相关信息，如截屏、录屏、日志文件等，可以在此附上。
确保文件大小适中，不要过大。
通过以上简洁的Bug报告格式，开发人员可以快速了解问题的来源和关键信息，加快Bug的定位和解决速度。
二、编写准确的Bug描述准确的Bug描述是提高Bug报告准确度的关键。
以下是一些建议：1. 使用明确的语言使用直观、明确的语言来描述问题，避免使用模糊或歧义性的词汇，以免引起误解。
2. 提供详细的重现步骤尽可能详细地描述导致Bug出现的具体步骤，包括操作流程、输入数据和预期结果。
这有助于开发人员重现问题，并快速找到根本原因。
3. 区分实际结果和期望结果清晰地描述实际出现的问题或错误，并明确说明你期望的正确行为或结果是什么。
这有助于开发人员更好地理解Bug的关键点。
4. 提供必要的系统环境信息在Bug报告中提供Bug出现的系统环境信息，如操作系统版本、浏览器类型和版本、设备型号等。
这能够帮助开发人员更好地定位问题。
5. 避免主观推测和假设在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报告里，要设法搞清什么是事实（例如：“我点击了XX”和“XX出现了”）什么是推测（例如：“我想问题可能是出在……”）。
如果愿意的话，您可以省去推测，但是千万别省略事实。
当您报告bug的时候（既然您已经这么做了），一定是希望bug得到及时修正。
所以此时针对策划以及程序员的任何过激或亵渎的言语（甚至谩骂）都是与事无补的——因为这可能是他们的错误，也有可能是您的错误，也许您有权对他们发火，但是如果您能多提供一些有用的信息（而不是激愤之词）或许bug会被更快的修正。
“程序不好用，设计不完美！”策划、程序员不是弱智：如果程序一点都不好用，他们不可能不知道。
他们不知道一定是因为程序在他们看来工作得很正常。
所以，或者是您作过一些与他们不同的操作，或者是您的环境与他们不同。
他们需要信息，报告bug也是为了提供信息。
信息总是越多越好。
在我们公司，任何一个已经开发了，或者正在开发的项目都会公布一个“已知bug列表”。
如果您找到的bug在列表里已经有了，那就不必再报告了，但是如果您认为自己掌握的信息比列表中的丰富，那无论如何也要与策划联系。
您提供的信息可能会使程序员更简单地修复bug。
上面说的，没有哪一条是必须恪守的准则。
不同的策划，程序员会喜欢不同形式的bug报告。
如果策划或者程序附带了一套报告bug的准则，一定要读。
如果它与本文中提到的规则相抵触，那么请以它为准。
“演示给程序，策划看”报告bug的最好的方法之一是“演示”给程序员或者策划看。
让他们站在电脑前，运行游戏，指出游戏里的错误。
Bug报告的结论性总结
Bug报告的结论性总结Bug报告是在软件开发过程中不可避免的一部分。
在软件测试过程中，发现和记录Bug是非常重要的，因为它们可以帮助开发人员定位和解决问题。
在这篇文章中，我们将对Bug报告的结论进行总结，并提供一些相关的建议。
总的来说，Bug报告的结论应该包含以下几个方面：1. Bug的描述：在报告中，应该准确地描述Bug的现象和影响。
这包括Bug出现的具体步骤、错误信息或日志、Bug对系统功能的影响等。
通过清晰而详细地描述Bug，可以帮助开发人员更快地理解并修复问题。
2. Bug的重要性和紧急性评估：在报告中，应该评估Bug的重要性和紧急性。
这可以基于Bug对系统功能的影响和用户体验的程度来确定。
在给Bug分配优先级时，可以使用标准的缩放比例，例如低、中、高、紧急等级别。
3. Bug的原因分析：在报告中，应该尽可能地提供有关Bug产生原因的分析。
这可能涉及到代码审查、系统日志分析、环境配置等。
通过找出Bug产生的根本原因，可以提供给开发人员有价值的信息，帮助他们更好地修复问题。
4. Bug修复建议：在报告中，应该提供关于如何修复Bug的建议。
这可能是一个针对Bug的临时修复方案，以便在正式修复出现之前，能够继续系统的正常运行。
此外，还可以提供一些修改源代码的建议，以便长期解决问题。
在撰写Bug报告的结论时，还应该注意以下几点：1. 提供足够的支持材料：包括截图、日志、错误信息等。
这些材料可以帮助开发人员更好地理解和重现问题。
2. 使用客观和明确的语言：在报告中，应该使用客观和明确的语言来描述Bug。
避免使用主观和含糊不清的表达方式，这有助于确保开发人员对问题的准确理解。
3. 结论要简明扼要：在报告中，结论应该简明扼要地总结问题和解决方案。
这有助于开发人员快速了解报告的核心内容。
4. 文档整洁美观：在撰写Bug报告时，注意文档整洁美观。
通过合适的排版、字体和段落分割，提高文章的可读性和颜值。
总而言之，Bug报告的结论性总结需要准确描述Bug的现象和影响，评估其重要性和紧急性，分析Bug产生的原因，并提供修复建议。
如何发现及准确描述BUG
如何发现及准确描述BUG 安网测试二部郭晨2014/05/24目标•什么是BUG•如何发现BUG•如何准确清晰的描述BUG什么是BUG•什么问题能定义为BUG？产品说明书规定要做的，却没有实现；产品说明书规定不要做的，却实现了；产品说明书没有提到的事情，也实现了的；产品说明书中没有提到但是是必须要做的事情，没有实现；很难理解，很难去使用，速度超慢，测试人员站在最终用户的角度看到的问题是平常的但不是正确的。
如何发现BUG首先，要有好奇心。
其次，要坚信：我测的东西一定有BUG。
如何发现BUG将分为常规方法、特殊方法和高速法三个个方面介绍。
如何发现BUG•一、常规方法：• 1.1 命令行测试1.1.1列出模块所有待测的命令行，举例：1.新增的配置命令。
address-family IPv6 unicastredistribute { connected | ospf | rip | static }[ metric < 0 –4294967295 >]neighbor { X:X:X:X::X | A.B.C.D }{ activate | default-originate | description | ebgp-multihop | fall-over | filter-list | next-hop-self | password | peer-group | remote-as | route-map | sedn-community | shutdown | timers |update-source }2.新增的show命令。
show ip bgp ipv6 unicast { vrouter vrname| x:x:x:x::x/0-128}show ip bgp ipv6 unicast neighborshow ip bgp ipv6 unicast summary3.新增的debug命令。
优质Bug报告的七个关键元素
优质Bug报告的七个关键元素Bug报告是软件开发过程中不可或缺的环节，它是软件测试人员在发现问题时向开发人员提供的详细说明，以便开发人员进行修复。
一个优质的Bug报告要能够准确地描述问题，并提供必要的信息以支持开发人员进行定位和修复。
以下是优质Bug报告的七个关键元素：1. 清晰明确的标题Bug报告的标题应该简洁明了，能够准确描述问题的关键特征。
一个好的标题能够帮助开发人员快速理解问题，并提高问题分析、解决的效率。
2. 详细的问题描述在Bug报告中，对问题进行准确和详细的描述非常重要。
报告者应该清楚地说明问题的发生场景、复现步骤以及预期与实际结果的差异。
此外，还可以提供相关的屏幕截图、日志或其他辅助信息，以帮助开发人员更好地理解问题。
3. 环境信息Bug报告中应该包含软件或系统的环境信息，如操作系统版本、硬件配置等。
这些信息有助于开发人员在不同环境中重现问题，并可能与其它因素（如特定硬件或操作系统）相关。
4. 重现步骤和测试数据Bug报告应该包含重现该问题所需的步骤和测试数据。
该部分应该详细、有条理地列出，以确保开发人员能够按照报告者的步骤重现问题，并进行问题定位和修复。
5. 预期和实际结果在Bug报告中，需要清晰地描述问题出现后对软件预期和实际结果的影响。
这有助于开发人员更好地理解问题，并判断问题的严重程度和紧急程度。
6. 错误信息和日志如果在软件运行过程中生成了错误信息或日志，报告者应该将其精确地提供给开发人员。
这样，开发人员能够根据错误信息和日志进行问题分析，并定位潜在的代码缺陷。
7. 附加信息除了以上关键元素外，Bug报告可能还需要提供其他附加信息，以补充问题的描述和背景。
例如，相关的设计文档、用例等资料，或报告者自己的分析和观察。
综上所述，一个优质的Bug报告应当具备清晰明确的标题、详细的问题描述、环境信息、重现步骤和测试数据、预期和实际结果、错误信息和日志，以及其他附加信息。
通过提供充分、准确的信息，报告者能够帮助开发人员快速定位和解决问题，从而提高软件质量和用户体验。
写出高效的Bug测试报告的9点建议
写出高效的Bug测试报告的9点建议1.清晰地描述Bug：描述Bug时要用简短的陈述句并能准确指出问题所在。
描述中可能需要提供一些步骤来重现这个Bug，同时这个简短Bug描述必须能够准确地表达出问题的本质所在。
例如，假如针对一个来自服务器的错误，Bug描述要对当完成什么操作时，这个服务器错误就会发生做详尽的说明。
2.不要放过你判断：虽然你满怀信心地确信你发现的Bug的真实性，但你没写到Bug报告中，这好像代表你正放过这个发现的Bug。
很可能会发生一起论战，这将反映出你作为测试人员的优越感。
你主要的目标应该是让你的Bug报告令人信服，以支持你发现的Bug，唯一的目的是让Bug 最终关毕。
在Bug报告中试着使用外交的表达方式，而不要使用官方的表述来赞成这个Bug，这样你的报告反而会令人不愉快。
最好的方法是使用建议的方式。
愉快的方式总能被采用。
3．重现的步骤：如何利用对条件设置的解释以重现并获得Bug的精确点，这必须要在Bug报告中讲述清楚。
例如，对于一个绘图软件，测试人员在找Bug之前，需要和开发人员就他已经做了什么进行交流。
细节必须详细说明，像按什么顺序，点击了哪个按钮。
对于按照提示输入命令而运行的程序，在测试Bug 之前，应该详细地说明输入命令的详细信息。
4.使用简洁的语言：人们不喜欢读包含复杂的专业术语和绕口的大段的段落。
一个好的Bug报告要包含短的但是表达清晰的语子。
它应该只包含与Bug有关的论述。
不必要把Bug报告做的过于复杂和写太多事实而篇幅过于长。
避免解说过多对重现Bug没有任何帮助的细节。
大家都普遍知道的事，就不必写在Bug报告中了。
5.引用相关的例子：大部分情况下，要重现一个特殊的Bug，必须输入一些特殊的数据。
但是不要做模糊的表述，像提供一个联系表中无效的人名并保存，应该说在名字域中输入像035bbb@$%这样无效的输入并点击保存。
为了使Bug能快速得到处理，测试人员必须努力提供所有相关的、关键的信息来帮助开发人员。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
如何发现及准确描述BUG 安网测试二部郭晨2014/05/24目标•什么是BUG•如何发现BUG•如何准确清晰的描述BUG什么是BUG•什么问题能定义为BUG？产品说明书规定要做的，却没有实现；产品说明书规定不要做的，却实现了；产品说明书没有提到的事情，也实现了的；产品说明书中没有提到但是是必须要做的事情，没有实现；很难理解，很难去使用，速度超慢，测试人员站在最终用户的角度看到的问题是平常的但不是正确的。
如何发现BUG首先，要有好奇心。
其次，要坚信：我测的东西一定有BUG。
如何发现BUG将分为常规方法、特殊方法和高速法三个个方面介绍。
如何发现BUG•一、常规方法：• 1.1 命令行测试1.1.1列出模块所有待测的命令行，举例：1.新增的配置命令。
address-family IPv6 unicastredistribute { connected | ospf | rip | static }[ metric < 0 –4294967295 >]neighbor { X:X:X:X::X | A.B.C.D }{ activate | default-originate | description | ebgp-multihop | fall-over | filter-list | next-hop-self | password | peer-group | remote-as | route-map | sedn-community | shutdown | timers |update-source }2.新增的show命令。
show ip bgp ipv6 unicast { vrouter vrname| x:x:x:x::x/0-128}show ip bgp ipv6 unicast neighborshow ip bgp ipv6 unicast summary3.新增的debug命令。
如何发现BUG• 1.1.2命令行测试的关注点测试命令行的自动补齐功能。
测试命令行大小写，以及大小写混用。
测试命令行的在线帮助功能。
测试命令行的参数边界值，合法输入和非法输入，输入不完整和输入完整时的检查。
测试show（包括新增的show命令和show running config）命令显示。
所有命令都配置后保存配置并重启。
命令行测试较少出现bug，但属于用户常用操作，需要覆盖完全。
相较而言较容易出现bug的地方：在线帮助信息不正确、规范；非法输入时系统异常；边界值或越界时系统异常；show 命令输出信息不规范、缺失；重启后配置丢失。
如何发现BUG• 1.2功能验证• 1.2.1功能测试一功能覆盖：根据设计实现进行功能覆盖。
测试的重心在于此，Bug 的最多产出也在于此。
测试根据用例执行，但不应限于用例，我们需要随时保持一个发散的思维。
模块集成、组合测试：强相关模块的组合测试，例如NAT和ALG、NAT和IPSecVPN。
异常、容错性测试：✓异常的输入（非命令行的非法输入）或流量，如异常的分片报文、无效的ICMP code/type、无效的用户名、密码登陆；✓超负荷运行，如超过系统容忍的并发连接；隧道场景：功能相关流量在tunnel 中的转发。
如何发现BUG• 1.2.2功能测试二HA场景：AP、AA模式下功能相关配置、状态能够正确同步，主备倒换时流量是否中断。
基于流的考虑：例如ALG的FTP控制报文为分片报文时，能否正确创建pinhole、非对称路由。
VLAN场景：在二层流量下报文带tag时对模块的影响。
VSYS场景：若支持，进行功能验证；若不支持，查看配置是否屏蔽。
与SOC互通：……Bug产出多在功能测试，覆盖的粒度和bug 数量成正比。
BUG如何发现• 1.3平台相关性考虑功能支持的平台类型：通常是全平台，在功能测试时组网考虑多种平台的覆盖。
低端平台考虑：低端平台由于内存、CPU的限制，在一些场景下更容易出现问题。
测试环境中最好能有一台低端平台。
如何发现BUG• 1.4模块化平台相关测试在不同板卡不同槽位不同接口上功能下发或流量转发。
例如，第一个槽位的第一和最后一个接口；最后一个槽位的第一和最后一个接口；正面板槽位和后面板槽位等。
如何发现BUG• 1.5多CPU架构考虑有的平台CPU为奇数，有的平台CPU为偶数。
大部分程序在偶数核时都能正常运行，但奇数核有时会因为代码没有考虑到而导致设备异常。
BUG 如何发现• 1.6License控制测试License是否生效。
License限制值是否生效。
License 的时效。
如何发现BUG•二、特殊方法• 2.1压力测试长时间测试。
反复操作，反复的配置操作，如配置增、删、改。
配置的压力测试对一般模块基本都适用，属于必选测试项。
大量并发操作，如大量用户同时上、下线。
资源使用极限条件下功能模块的工作情况测试，这些极限条件可能是：高CPU、内存利用率等。
批量操作，如一条命令导致的大量信息的添加、删除（no xxx all）等。
压力测试常能发现较为严重的bug 。
如何发现BUG• 2.2规格测试规格数量下的配置的保存和加载。
保存后查看配置是否丢失，加载时观察是否有配置无法加载。
重启查看配置是否丢失。
验证规格数量下功能的正常工作。
如10000个VPN隧道（假设规格为10000个VPN）能否建立并转发流量，有些功能如果无法验证规格数量下功能工作情况，则至少应该选取其中部分实体进行验证，如配置1024个地址薄后，检查其中任意被引用的地址薄工作是否正常。
通常这里都是有bug的，而且都是4-5级bug 。
如何发现BUG• 2.3性能测试性能对比：通常要求新建、吞吐、时延比上主线版本下降小于5%。
性能评估：对版本在不同平台上的性能进行摸底测试，输出性能评估报告。
如果性能下降较多，说明代码需要优化，必须报bug 。
如何发现BUG• 2.4内存检查找到触发内存申请、释放的地方进行测试，并进行压力测试，防止有内存泄漏的情况；了解功能的内存使用基本单位，（如：创建一条session将占用内存x字节）计算该功能最大消耗内存的数值，可能是其满负荷运行或达到规格数时处于最大内存占用点，在这个点进行测试；测试在d-plane内存剩余很小的情况下，模块申请内存失败后是否能够正确处理或返回。
如dp memory剩余很小的时候创建QoS IP queue失败，是否能够正确返回；由于每种硬件平台的内存配备不同，因此需要针对不同平台考虑测试。
如内存配置小的平台更容易达到内存使用极限。
内存泄露也是常见的严重bug，常会导致进程、系统异常，最终导致功能不可用。
BUG如何发现• 2.5通用性检查选用上一个主线版本或者不支持该特性的版本进行配置的降级验证。
正常情况下不支持的特性的配置应该是加载失败，如果出现其他情况都是异常。
如何发现BUG• 2.6Debug测试模块相关的debug是否存在；模块相关的debug是否可以开关；模块相关的debug输出的信息是否具有高可读性、语法正确；模块相关的debug是否能够导出到相关指定的位置：buffer、terminal、syslog 等。
如何发现BUG• 2.7易用性测试从易用性角度考虑功能实现上可以增强的地方，包括用户界面的友好性、操作的高效、适时的用户指导和帮助信息。
这一类bug需要测试人员足够的敏感和站在客户角度考虑问题。
通常这一类bug 在功能上没有问题，只是不符合人们使用习惯、操作不便等。
如何发现BUG• 2.8互通性测试与友商设备（如，cisco、华为）互联，功能验证；与同平台不同版本互联，功能验证。
前面所有测试都只是保证在同一个版本上功能的可用性，但不能忽视和友商之间的互联，现网中充斥着各个厂商的设备，如果我们的实现或者友商的实现不符合规范将导致连通性的问题，只有在互通性测试时才能发现。
经验不够丰富的测试人员通常会遗漏这个测试点。
如何发现BUG•三、高速法：•查看QC系统中的BUG，学习别人的思路。
发散思路常能发现bug 。
祝大家好运！•如何准确清晰的描述BUG•发现bug后该做些什么？不确定问题原因甚至不确定是否是bug及bug很严重，如，进程crash时应找开发人员定位；若能够明确认定是bug，需要找复现条件，确认是否是必现bug；若非必现，则需要多次复现bug，准确描述复现概率。
•明确bug阅读对象是谁？修改该bug的开发：模块开发人员、开发经理；验证该bug的测试：自己或回归该bug的测试人员、测试经理；所有对bug感兴趣的人员：前端、PM 、文档等。
•如何准确清晰的描述BUG•一个例子：最后再来讨论•如何准确清晰的描述BUG •Summary（摘要）该如何写？简单明了，便于理解长度一般不超过30个字尽可能讲明：什么情况，导致了什么问题•如何准确清晰的描述BUG•Description（描述）该如何写？1)复现步骤（Actions）详细描述重现该问题的关键步骤；省略无关的操作，力求做到：所有重现步骤是充分的和必要的；容易理解的常规步骤，可以一句话带过，比如以管理员身份登录，进入后台用户管理页面；与环境有关的问题，给出特定的条件，比如：某某操作系统，某某浏览器。
2)实际结果（Actual Result）描述实际出现的错误结果；可借助截屏来表达；不是总能重现的Bug，给出发生频率或规律；3)预期结果（Expected Result）当设计文档上没有对实现结果做详细要求时，用于测试人员表达自己的看法，一般是对比常规做法或其他模块的类似实现。
•如何准确清晰的描述BUG •（Attachment）截屏/附件针对文字难以表达的或UI方面的问题；图片格式使用JPG格式；Windows画图工具的默认BMP图片太大，不建议使用；在图片上用醒目的颜色，标出问题所在区域；也可考虑配上简短的文字或截图的文件名中描述。
•如何准确清晰的描述BUG•（other）其它注意事项：对于多人同时测试同一模块的情况，报Bug前先检查是否已有类似的Bug。
Bug严重程度(Severity)必须准确。
Bug优先级(Priority)必须准确（我们QC系统无此项，不需关注）。
项目中共性的问题，纳入Common Module。
多个相同的问题，如是一个开发负责修改的，撰写一个缺陷报告把级别响应调高就可以，但须指出问题发生的多个位置。
对于Reject的有争议的Bug，尽可能和开发当面沟通。
•如何准确清晰的描述BUG 一个例子：共同讨论已做和可优化THANK YOU！。