一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？
我要个人想法的答案
按投票排序
测试条件：软件（平台、版本等）、硬件配置；测试现象/结论、分析、建议等；重现步骤：如何让开发人员重现你提的BUG。这几条是最主要的。此外，还应当尽量包括：重要度、紧急度、BUG产生阶段（需求、设计、实现、文档）。
缺陷编号、名称、提交人、测试版本、测试环境、缺陷的时间、优先级、严重等级、发现缺陷的操作步骤、附件（步骤截图、详细说明）
缺陷管理的作用在于，一是记录以便以后满足统计分析等需要，二是有助于重现问题以便定位及解决问题。从这个角度出发，缺陷报告自然是能够记录越多的细节越好，包括测试环境、软件版本、所用工具及版本号、测试用例的信息、出错前所执行的操作步骤、出错时相关信息和日志，等等很多。但是要真正做到捕获的都是有用的信息是非常困难的，因为我们只能从故障现象入手去记录相关信息，而问题的根源可能与之相隔甚远，来回折腾其实是非常耗时、耗资源的。最好的办法就是发现问题之后马上debug，开发测试在一块来解决问题，这是最经济实惠的办法。我个人非常喜欢敏捷软件开发的方式，开发测试在同一个团队里面。发现缺陷后可以即刻查看、定位、调试修复问题。而后在不得已的时候，例如短时间内无法解决此问题，再进行记录。此时由于已经经历过多次定位、尝试修复、重现的过程，对于故障的相关信息捕捉也会更加的得心应手，记录到缺陷追踪系统中的信息也能更加精确和有效。
根据Defect 软件Clarify的设置，有以下这些：Bug描述（summary）环境信息：操作系统/数据库/浏览器/软件版本 (OS/Database/Project/Build/Release)所属Feature：哪个功能模块的问题 (可附带选择操作命令)测试/开发人员严重等级(1-5)客户优先级开发人员修复的工作量风险程度状态重现步骤实际结果语气结果有没有Workaround是不是回归问题分析
已有帐号？
社交帐号登录
无法登录？
社交帐号登录& 愿做一个Bug，只为你在Coding时能多看我一眼…
愿做一个Bug，只为你在Coding时能多看我一眼…
同数字游戏，用代码作诗，
用几行命令，写一段情书，
给想嫁给程序员的你。 &
Java程序员的情书
我能抽象出整个世界..
但是我不能抽象你..
因为你在我心中是那么的具体...
所以我的世界并不完整.
我可以重载甚至覆盖这个世界里的任何一种方法...
但是我却不能重载对你的思念...
也许命中注定了.你在我的世界里是永远的烙上了静态的属性...
而我不慎调用了爱你这个方法..
当我义无返顾的把自己作为参数传进这个方法时...
我才发现爱上你是一个死循环..
它不停的返回对你的思念压入我的心里的堆栈..
在这无尽的黑夜中...&
我的内存里已经再也装不下别人...
我不停的向系统申请空间..
但却捕获一个异常--我爱的人不爱我...
为了解决这个异常...
我愿意虚拟出最后一点内存..
把所有我能实现的方法地址压入堆栈..
并且在栈尾压入最后一个方法--将字符串"我爱你,你爱我吗 "传递给你..
如果返回的值为真--我将用尽一生去爱你...
否则---我将释放掉所有系统资源...&
C++程序员的情书
茫茫内存里,你我不曾相见;&
寥寥代码中,命运注定良缘.&
当编译开始,我们齐手共建&
--中国软件的春天!&
虽然我们是不同的对象,都有隐私的一面,&
但我相信你会找到我的接口,把我的最真给你看!&
因为我是你的指针,在茫茫内存的堆栈中,&
永远指向你那片天空,不孜不倦!&
我愿做你的内联,供你无限次的调用,直到海枯石烂!&
我愿做你的引用,和你同进退共生死,一起经受考验!&
只是我不愿苦苦地调试你的心情,最终沦为你的友元!&
而我更不愿始乱终弃,删不清借你用的空间,&
最后一拍两散,搞得内存混乱...&
如今我们已被MFC封装--事事变迁!&
如今我们已向COM走去--
不知你可曾记得那已经褪色却仍然绽放光芒的三个字：
std::count&&“我”&&“爱”&&“你”&&std::
VB程序员情书
If you.isMM() then
　 me.Rose2(you)
　 if you.isSingle() and you.pretty()
　　　me.invite(you)
　　　if me.success then
　　　　 me.haveAGreatValentine(me and you)&
　　　　 me.happy you.happy&
　　　end if&
　 end if&
　 me.sayHello2(you)&
　 me.sayBye2(you)&
数据库程序员情书
每次你微笑的看着我，都会引发使我心跳加速的触发器，我发现自己已深深地爱上了你，无法逃避，因为我们在同一个Database里。
经过我长期的查询分析，对你表结构的了解也越来越清晰，你温柔美丽，高雅贤淑，简直就是我心目中的BCD。
我多想JOIN你，但找不到合适的id.If你能和我在一起，你就是我的unique，我决不会三心二意，去找其他的foreign key。
为了你，我会DELETE自己所有的坏脾气，也会时常UPDATE自己。你交给我的transaction,无论@@error等于几，我都会commite，尽心尽力。我会紧紧地FETCH，我们在一起的美好回忆，将它变成加密的存储过程，而不是转瞬即逝tempdb。
我将这份日志sp_sendmail给你，向你declare了我的心意,如果你set nocount off，我就认为你default了我们的实体关系,不要再犹豫迟疑，相信自己的select，我一定会爱你，直到系统死机。让我们挑一个服务器空闲的日子，参加批处理婚礼，由sa为我们见证，从此紧紧地union在一起，永不分离，共同create一片美好的天地。
程序猿眼中的女人有哪些类型呢？
有的女人就像Windows虽然很优秀，但是安全隐患太大。
有的女人就像UNIX她条件很好，然而不是谁都能玩的起。
有的女人就像C#长的很漂亮，但是家务活不行。
有的女人就像C++,她会默默的为你做很多的事情。
有的女人就像JAVA,只需一点付出她就会为你到处服务。
有的女人就像JAVAscript，虽然对她处处小心但最终还是没有结果。
有的女人就像SQL，她会为你的发展带来莫大的帮助。
有的女人就像ASP，满街到处都是，成熟漂亮和稳重的只有极少数。
有的女人就像PHP，饱经沧桑（开源），无论经验和内涵都非常的丰富。
有的女人就像dotNet，没有点积蓄还真养不起！
有的女人就像Ajax，使用起来感觉就是爽。
有的女人就像JSP,看起来很高贵,可是你玩不起!
有的女人就像HTML,虽然不高贵,也不好看,但是她是助长美好爱情的根基
有的女人就像DOM，长的很有层级，虽不是长期的助手，但在你有危机的时候，他会挺身而出
有的女人就像DOS,虽然她不美,也不实用,但是她必定是你的初恋女友!
有的女人就像汇编虽然很麻烦，但是有的时候还得求它。
程序员的爱情诗
我不是诗人，所以，只能够把爱你写进程序，
当作不可解的密码，作为我一个人知道的秘密
我以为你是我的唯一，过了很久才发现，你不是我独占的服务器
我可以传递，却什么都不能够取回，大师说，此算法不可逆
我想析构我自己，却没有多少勇气，只能够注释掉关于你的记忆
想寻找你的信息，突然发现，你已经不在我的域
我想重载爱的定义，把你我封装在一起，
在我的名字空间里，再也找不到你，
爱情的管道，已经关闭
我有的，只剩下从爱继承的颓废
爱的模板，已经解不开我们的僵局
我已经成为异常的容器，无法容下与你无关的东西
我以为我们该是一个联合体，原来只是松散的内聚
直到分开很久，你才返回操作失败的信息
你告诉我，我只是你的友元类
独自一个人难醉，我慢慢明白，我们不是来自相同的基类
你很久前抛出的异常，我笨得不能够体会
你说我不是你的适配器，你不需要一个通用程序
我是你堆栈的顶部，你要弹出我选择原来的奇遇
多希望可以写出一个函数，拷贝从前的你
可是等了很久，还是没有奇迹
只能够继续开一个心的端口，监听你的信息
我的悲伤与快乐，都装进黑盒里
不需要让你知道，我仍然爱你
程序员的烦恼
为了程序没日没夜的研究学习
为了程序整天灌输OO思想
为了自己的爱好拼命的敲着代码
张口闭口的类和对象
这些都值得吗？
到头来把对象给实例化了
自己的对象没找着
典型的宅男
处对象总找不着合适的话题
久而久之成了老光棍
程序员可以在社会上运行的时间只有短短几年光阴
职业性的思想已经嵌入灵魂无法磨灭
和女孩在一起的时候肯定是要讲一些高兴且有趣的事
现在唯一让我兴奋的是完成项目后的那种心情
当我滔滔不绝的讲完了实现思路和关键代码的时候
我发现对方的眼皮已经快抬不起来了
这个缺点我知道，我会改
但让我不解的是：
为什么现在的女孩都喜欢油腔滑调的
为什么都喜欢吊儿郎当的
难道真的是男人不坏女人不爱吗？
好一点的女孩根本看不上咱这样家境一般、长相偏差的人
我很费解，也很苦恼
一程序猿用C语言写给女友的一封情书，代码很简单，就是全部用宏定义进行替换，但是以为引用了中文，需要Unicode码的支持，能在VS2005及其以上版本编写调试&&↓↓↓
把我们写进finally，即使偶尔发生异常跳出try进入catch，最终也要执行finally&↓↓↓
永远说不出来的爱……俗称暗恋↓↓↓
两个人的世界，一封无言的情书， 短暂的停留却换来长久的回忆，只想说句：我想你。
丢失的信件/被删除的记忆/虚无的世界/不曾存在的停留/空有一句我想你/却终将换来void/return nothing&↓↓↓
世界上最甜蜜的事情，是你在循环条件里，我在循环体里，我只为见你下一次而默默等候……↓↓↓&(via @祁特 )
程序猿的爱情和幸福在哪里↓↓↓
我用尽所有的数据结构，都储存不了，你那一笑的璀璨明眸。↓↓↓（via @FD张江团工委总楼委 ）
下面是一段代码反映出一个程序猿的爱情，是程序员的，看代码应该都懂的！！不懂代码的，看下面带注释的！尼玛的，程序员伤不起啊！！！（via @silence-蔡某人 ）
if ( you.Love(Me) || !you.Love(Me) ) { love++; love--; } //你爱，或者不爱我，爱就在那里，不增不减 ↓↓↓（@王居士 ）
某程序猿QQ签名写了一段这样的东西：(x^2 + (9/4)y^2 + z^2 - 1)^3 - x^2z^3 - (9/80)y^2z^3 == 0&
为MM量身定做的C语言程序！↓↓↓
年度最佳的三行情书~↓↓↓
代码情书，我们用C表达爱&↓↓↓ &
爱情就是死循环，一旦执行就陷进去了。爱上一个人，就是内存泄露–你永远释放不了。真正爱上一个人的时候，那就是常量限定，永远不会改变。
手机扫描上方二维码 关注PHP新手官方微信号phpxs8 聊聊编程技术 聊聊程序人生。
本文固定链接:
转载请注明：转载必须在正文中标注并保留原文链接
编辑：放飞梦想
有人的地方，就有江湖；有网络的地方，就有PHP新手。IT人的家园，IT界的烟火。
学习编程5个常见的疑问
相关： 猜您喜欢一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？_百度知道
一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？
：1) 通用UI要统、准确缺陷报告UI要与测试软件UI保持致便于查找定位2) 尽量使用业界惯用表达术语表达使用业界惯用表达术语表达保证表达准确体现专业化3) 每条缺陷报告包括缺陷每条缺陷报告包括缺陷使缺陷修者迅速定位缺陷集精力每修缺陷校验者每校验缺陷否已经确修4) 重现缺陷要报告首先缺陷报告必须展示重现缺陷能力重现缺陷要尽力重现若尽力仍能重现仍要报告缺陷报告要注明再现缺陷现频率5) 明确指明缺陷类型根据缺陷现象总结判断缺陷类型例即功能缺陷、界面缺陷、数据缺陷合理化建议见缺陷或缺陷类型其形式缺陷或缺陷属于其某种形式6) 明确指明缺陷严重等级优先等级刻明确严重等级优先等级间差别高严重问题能值解决装饰性问题能作高优先级7) 描述 (Description) 简洁、准确完整揭示缺陷实质记录缺陷或缺陷现位置描述要准确反映缺陷本质内容简短明便于软件缺陷管理数据库寻找制定测试缺陷包含缺陷发用户界面（UI）良习惯例记录框标题、菜单、按钮等控件名称8) 短行间使用自数字序号使用相同字体、字号、行间距短行间使用自数字序号使用相同字体、字号、行间距保证各条记录格式致做规范专业9) 每步骤尽量记录操作保证简洁、条理井容易重复操作步骤10) 确认步骤完整准确简短保证快速准确重复缺陷完整即没缺漏准确即步骤确简短即没余步骤11) 根据缺陷选择否进行图象捕捉直观观察缺陷或缺陷现象通需要附加缺陷或缺陷现界面图片形式作附件附着记录附件部节省空间能真实反映缺陷或缺陷本质捕捉缺陷或缺陷产全屏幕窗口局部区域迅速定位、修缺陷或缺陷位置通要求附加文照图 附加必要特殊文档建议注解打某特殊文档产缺陷或缺陷则必须附加该文档迅速再现缺陷或缺陷使缺陷或缺陷修者进步明确缺陷或缺陷表现附加修改建议或注解12) 检查拼写语缺陷提交每条缺陷或缺陷前检查拼写语确保内容确确描述缺陷13) 尽量使用短语短句避免复杂句型句式软件缺陷管理数据库目便于定位缺陷要求客观描述操作步骤需要修饰性词汇复杂句型增强读性概括报告测试缺陷规范要求随着软件测试要求同测试者经期测试积累相应测试经验逐渐养良专业习惯断补充新规范书写要求外经阅读、习其测试工程师测试缺陷报告结合自前测试缺陷报告进行比思考断提高技巧14) 缺陷描述内容缺陷描述内容包含缺陷操作步骤实际结期望结操作步骤便发员再现缺陷进行修些发再现缺陷能力差虽明白所指缺陷再现特别系统熟悉新加入发员介绍步骤便再现实际结让发明白错误期望结让发解确结应该何希望楼主采纳 谢谢
缺陷管理的作用在于，一是记录以便以后满足统计分析等需要，二是有助于重现问题以便定位及解决问题。从这个角度出发，缺陷报告自然是能够记录越多的细节越好，包括测试环境、软件版本、所用工具及版本号、测试用例的信息、出错前所执行的操作步骤、出错时相关信息和日志，等等很多。
但是要真正做到捕获的都是有用的信息是非常困难的，因为我们只能从故障现...
其他类似问题
为您推荐：
其他2条回答
1.BUG应软件版本2.发借口员测试员3.BUG优先级4.BUG严重程度5.BUG能属于模块6.BUG标题7.BUG描述8.BUG截图9.BUG状态10.BUG错误类型（数据界面）
在您以往的工作中，一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？ 1. 在传统的BugZilla中，BUG描述应该包括以下
软件缺陷的相关知识
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁从BUG库看一个开发团队的自我修养 - 简书
下载简书移动应用
写了34036字，被270人关注，获得了222个喜欢
从BUG库看一个开发团队的自我修养
程序员不喜欢BUG，每当有人说这里有个bug的时候，就不自觉的启动了自我防御机制，开始在想是不是这家伙不会用什么的，其实恰恰是程序员创造了bug；如果每个程序员都能写出完美的代码，测试人员早该灭绝了，事实是测试人员越来越重要。人无完人，首先承认自己的不完美，接受bug的存在；程序不可避免的会存在bug，但这不妨碍程序员不断的最求完美，努力写出高质量代码。BUG不可避免，因此记录BUG的系统就不可或缺。我经常说，看一个团队够不够专业只要看他们的BUG系统就可以了。如果一个开发了近半年的项目还没有一个BUG库，或者BUG系统里记录的内容乱糟糟的，你又如何能认为这样的团队能开发出高质量的产品。一个BUG的生命周期关心BUG的就有测试，开发，项目经理，他们在一个BUG的一生中扮演着自己的角色。提出BUG（提出者）－》解决BUG（开发者）－》证实BUG是否解决（测试）－》已解决（测试人员）－》已发布（项目经理，SCM）提出BUG的可以是任何人，产品开发内部人员以及外部人员；比方，内部人员有测试，项目经理，开发人员，测试团队。外部人员，比方老板，客户，用户。事实说明，外部人员无法专业的描述一个bug，建议专门建立一个面向外部的bug录入系统，可以由测试人员，或技术支持来管理整个系统里的BUG。如果确实是BUG，再由测试人员和技术支持人员录入到内部BUG系统中。项目经理会进一步指派谁解决某个BUG，以及解决的优先级。项目经理判断的依据有，1，根据bug所属的模块，指定最属性这一块的开发者；2，根据大家手里的任务的多少，指定一个开发者；3，根据一个bug的影响程度，严重的bug需要优先解决，测试，立即上线。接着就是开发人员进行bug的修复，开发人员首先要做的是，仔细阅读bug的描述（具体格式如下），并在开发环境中重新bug，有的时候可能需要专门配置对应的开发环境；重现问题后，分析问题，解决问题，并在开发环境中验证问题是否的确解决了。然后测试人员从某个开发分支获取相应的补丁，有的时候也可能直接在开发搭建的环境中，进行bug修复验证；首先要做的是，仔细阅读开发人员解决bug的描述（如下），然后开始测试验证，注意的是，如果代码影响的范围很多，需要做相关模块的回归测试，防止引入新的问题。测试没有问题，那么就可以标示为“已解决”。项目经理或SCM从开发分支上获取已验证的代码合并到主干，然后发布新的版本，同时将bug状态标示为“close”。测试人员必须完整的描述一个BUG看一下BUG里的描述，就能看出开发团队的素养：专业程度，是否足够负责任：
BUG标题：简洁且突出重点，好比给一篇文章起个好名字
所属的功能模块：
复现的前提条件：
复现的步骤：
提供问题的截图以及日志：
附加描述：
测试人员面临一个难题，一个测试发现的BUG究竟应该指派给谁呢？究竟属于后端问题，还是客户端的问题？将BUG指派给正确的人可以有效提高效率，也能避免来自开发的抱怨。这里的几个有效的方法来判别谁是问题的责任人：1，就是通过对比，你可以同时对比andriod端和iphone端的表现，如果在这两个客户端上都有问题，说明很可能是后端的问题；2，通过抓网络包看接口数据，或者查看数据库来判别：页面呈现的内容都是基于对数据的加工和解释，如果你能直接从数据层切入，也帮助进一步确定问题的根源。3，咨询你信得过的前端和后端的工程师。但不管怎样，测试人员无论如何也无法确认这到底是前端问题，还是后端问题。在这里开发人员也需要给予谅解，如果发现这并非自己的问题，完全可以加上一些说明后，转给对对应的责任人。开发人员简明扼要的说明一个BUG的解决情况详细填写以下内容可以迫使自己做全面思考，也可以给予测试必要的信息，在确认的时候能了解问题发生的原因，并能就修改涉及的其他内容也做检查。
问题发生的前提条件：
严重程度：从发生的频率，对系统的影响程度，对用户的影响程度几个方面进行评估。
问题原因：
解决方案：
代码影响到的模块：
如何确认问题是否已解决：从日志里确认？开发环境测试？
总结：系统中其他地方是否存在类似问题？引入该问题的原因？下次如何避免类似问题？
开发解决问题要避免“打地鼠”式，大家都见过打地鼠游戏，就是那种你按下了这边，那边又冒出了只地鼠；所有，必须要注意：1，确定解决了这个问题，不要引起另外的问题。2，其他地方是不是存在类似问题。解决完问题后，一个问题作为一个代码提交单位；每次提交，注明解决的BUG号，以及BUG的标题。BUG的流动可能会在不同角色间流动，比方分配给某个开发的BUG，他通过了解发现BUG描述不清楚无法开始工作，他会把BUG重新分配给测试人员。也有可能测试发现开发并没有解决问题，就把BUG再转给开发。我认为，正常的流动是必须的，特别是大型系统中，各个开发团队负责一部分内容，所以要果断将不属于自己能力范围内的bug及时转给对的开发人员；也有可能，问题的表象是发生在了客户端，比方字段的显示不对，但根源是在服务器端。那么开发人员必须留下必要的备注说明自己分析的内容，然后及时转给对应的负责人。特别忌讳的是不健康的流动，不加上自己的分析备注就转给他人（不说明来意），或者对测试提的bug吹毛求疵，粗鲁对待。记得，bug系统的存在是为了提高协作效率，不要推诿责任，必要的时候可以直接走到别人的座位上，问清楚原因。我们提倡有益而又健康的流动，拒绝无谓的，纯粹推诿的流动。终结一个BUG除了确实是bug，且被解决了这个happy ending，bug还有其他可能的命运；
1，确实是个bug，但是影响很小，而且修复工作量巨大，导致影响到其他模块，所以不予修复；
2，需求未能定义清楚，导致测试和开发的理解有不同，需要明确需求；
3，是个问题，但有BUG提到了同样的bug，所以需要合并处理；
4，是个bug，但在本次版本中不予修复；
5，是个bug，但始终不能复现，开发人员长时间无法进行调研，所以暂时关闭；
... 总结来说，不是所有的BUG都是BUG，不是所有的BUG都必须解决。谁是BUG系统的负责人俗话说一山难容二虎，也就是说一件事只能有一个负责人；那么谁是BUG系统的负责人？我认为，测试人员应该是BUG系统当仁不让的负责人，BUG系统是测试人员的主战场：1，保证录入的bug质量，检查每个bug描述是否完整准确；2，以及检查开发人员解决bug的备注是否完整，解释又是否合理；如果解释不合理，必须要求开发人员重新填写。3，保证每次发现的问题及时录入到系统中，建议测试过程中发现的问题截图收集完日志后，简单用笔记录下。全部完成测试后再一次性记录到BUG系统中。4，追踪BUG修复的情况：BUG是否在修复中了；及时测试已被修复BUG。BUG系统的其他重要作用需求变更库：很多公司不但把BUG系统也称作为需求变更管理库，这就意味着不但可以录入bug，有些小功能，小需求，小的用户体验改进也可录入。我非常推荐这种做法。测试用例库：像禅道就可以记录测试用例子；我觉得测试最核心的能力之一在于设计测试用例的能力，具体测试的过程，只是一个按测试用例执行的过程。禅道里可以在项目进入开发阶段时，就开始设计并录入测试用例。而且还可以把发现的某个bug转变为一个测试用例。与版本管理相关联：一个bug的解决意味着代码的提交，所以可将bug管理系统和版本管理系统相结合和关联。如，clearquest与clearcase关联，禅道和svn关联（注：收费功能，我没用过 呵呵）。经验教训库：这里的每个内容都是一个你犯过的错误，你在这里也记录的总结和反思；随着系统开发不断往前迭代，BUG的内容也会越来越丰富，沉淀了越来越多的经验，帮助我们了解错误原因所在，避免再犯。当前流行的BUG管理系统大公司会使用clearquest，IBM rational出品，适合管理超大型项目。简单项目管理有bugfree，国产的禅道，都是开源的，下载下来后自己安装。还有一些系统无需安装，只要申请账号既可以直接使用，具体笔者没有自己使用过，需要大家自己去找一下。必要要说的是，一个团队要强大起来，先从自己的BUG系统开始做起。
如果觉得我的文章对您有用，请随意打赏。您的支持将鼓励我继续创作！
打开微信“扫一扫”，打开网页后点击屏幕右上角分享按钮
被以下专题收入，发现更多相似内容：
产品经理的实战
· 11385人关注
弱水三千，只取一瓢饮
· 1111人关注
分享移动开发技术、专题、干货。
· 448人关注
如果觉得我的文章对您有用，请随意打赏。您的支持将鼓励我继续创作！
选择支付方式：