A. 软件测试中，BUG 提交不了有什么原因造成的呢根据是什么呢
Hi, 你说的提交不了是指bug已经确认可以提交，然后管理软件出问题了提交不了还是指有人报了这个bug，但是因为一些原因不能去提交？
若是前者，请截图或是说更详细一些，让我们能了解问题
若是后者，那么bug不能被提交可能有以下问题：
1 这个bug本身就不是bug
2 目前的阶段还没有正式开始，所以还不能报bug
3 这个bug影响非常的小，对于用户没有太大影响，但是开发人员则要费大力气去修改，这个问题就不会去提交
4 成本不允许，或是开发人员想要后期才去解决这个问题
5 目前阶段处于测试的后期，一些不是很严重的bug就不会去上报了
6 之前已经报过了，然后被标称 willneverfix之类的就不会上报了
B. 软件测试提交bug时包括哪些内容
Bug的标题（Title）和详细描述（Descriptions）:
标题是对你所提交的Bug进行简明描述；详细描述是对Bug进行详细描述，例如在什么情况下发生等；也可以直接将标题作为描述部分。
回归（Regression）：
是测试前一个版本有没有此类bug（称为回归测试）。
Bug测试环境（Environment）：
发现的这个bug的环境，例如：什么系统，哪个版本等。对于bug环境的描述可以通过简单的罗列即可。
复现的详细步骤（Repro Steps）：
将测试的过程简单的写一下，从你开始测试软件的最开始到你发现bug的时为止。
实际结果（Actual Results）和预期结果（Expected Results）：
实际结果是在测试软件的过程中，软件所表现出来的特征或者行为；预期结果就是软件需要设计所要求达到的结果或者目标。
备注（Notes）:
对bug的一些补充，例如：其它系统也发生，上个版本不发生等需要补充的内容。
内容还包括bug的严重等级、优先等级等，对于不同的bug，要做出相应的提交内容
C. 详解BUG（又名：BUG的生命周期）
测试人员最本质的工作就是寻找bug，提交bug、验证bug、推进bug的解决，直至软件达到发布的标准，提高软件的质量，及研发的工作效率和质量。
软件的BUG,狭义概念是指软件程序的漏洞或缺陷，广义概念除此之外还包括测试工程师或用户所发现和提出的软件可改进的细节、或与需求文档存在差异的功能实现等。
生命周期中 缺陷状态 ：新建-->指派-->已解决-->待验-->关闭
发现BUG-->提交BUG-->指派BUG-->研发确认BUG-->研发去修复BUG-->回归验证BUG-->是否通过验证-->关闭BUG
1、发现bug
1）按照测试用例进行操作，发现和测试用例的预期结果不一致的,都可以被称之为Bug。
2）测试用例不可能穷尽，总有超出你预料之外的因素,或者是神操作出现的bug。
3）成本问题，没有充足的时间编写测试用例，发现的bug
2、提交bug
在提交一个缺陷的缺陷，首先尽量描述这个缺陷的属性。Bug重现环境，bug类型，bug等级，bug的优先级以及详细的重现步骤，结果与期望等。
当然，我们在提交一个问题之前首先应该保证，这个缺陷是没有被提过的，以免造成重复缺陷单。
3、指派bug
这一步不是必须的，跟项目模式有关，有些公司测试部门与开发部门独立，那么测试人员就不确定自己测试的模块是由哪位开发人员负责的，在这种情况下，测试人员统一把问题指派给项目组长或经理，由项目组长（或经理）对问题进行确认后再次分配给相应的开发人员。
有些测试人员是穿插到不同研发团队中的，所以对不同的开人发员负责的开发模块非常清楚，这个时候就可以将问题直接指派给相应的开发人员。
也有一种情况，本来此问题应该由A开发人员负责，但由于A开发人员的调离或辞职，些问题为转交给其它人员处理。“分配”强调是上级对下级；“转交”强调的是平级之间。
4、 确认缺陷
当开发人员接到一个缺陷时，首先是对其进行分析与重现，如果对其进行分析发现不是缺陷（可能由于测试人员不了解需求）或无法对此问题进行重现，那么就需要将此问题反回给测试人员，并注明原因。如果确认为缺陷则需要对其进行处理。
5、修复BUG
推迟处理
在处理问题之后，还需要进行一次判断，是否需要推迟处理，有些需求已经确认了是问题，由于其可能在极端情况下才会出现，或需要对系统架构进行改动，或其优先级非常低，所以暂时不需要对此问题进行处理（或到下个版本进再进行修复）。
固定
对于推迟处理的问题可以暂时进行固定（“固定”为QC中的叫法。）一般固定的问题需要经过项目经理与测试经理协商后才能固定。
处理缺陷
开发人员在确认完一个问题需要处理时，那么就对其进行处理工作。（例如，redmine 是支持处理人时时更新问题处理进度的，如 已处理30% ，已处理80% 等，当然，对于短时间内可以修复的问题就没必要时时的去更新处理进度。）
6、回归验证BUG
回归缺陷对于测试人员来说是非常重要的工作，其有三个入口两个出口。
确认非缺陷问题：对于提交的一个缺陷，开人员处理为非问题或无法重现，然后直接转交给测试人员回归。测试人员再次确认，如果真如开发人员所说，则将问题关闭。如果非开发人员所说，是由于问题描述模糊或其它原因喂重现问题，则再次注明原因转给开发人员。
确认修复问题：对开发人员修复的问题再次进行确认，确认能过，则关闭问题。确认不通过，将问题再次打开并转给开发人员。
确认固定问题：有计划的对固定问题进行确认，有些固定问题随着时间的推移，版本的更新或已经不存在了，对这类问题应该及时关闭。有些固定问题依然存在且变得紧急，对于这类问题应该及时打开交给开发人员处理。
7、关闭缺陷
对于已经修复的缺陷进行关闭，这也是一个缺陷的最后一个状态。
在做接口测试的时候可以使用国产的接口测试和接口文档生成工具 apipost
D. 地下城BUG提交怎么填写完了交不上去啊 什么都填了啊我。图片也对啊。
很明显的问题，不是所有玩家的意见都会被处理的。就好先据报外G一样。你看TX现在掉线外G这两大问题都解决不了哪还有心思去解决别的问题呢。另外，如果你像提交BUG，只有测试服会好一点。
E. 一条软件缺陷（或者叫Bug）记录都包含了哪些内容如何提交高质量的软件缺陷（Bug）记录
你好：
1) 通用UI要统一、准确
缺陷报告的UI要与测试的软件UI保持一致，便于查找定位。
2) 尽量使用业界惯用的表达术语和表达方法
使用业界惯用的表达术语和表达方法，保证表达准确，体现专业化。
3) 每条缺陷报告只包括一个缺陷
每条缺陷报告只包括一个缺陷，可以使缺陷修正者迅速定位一个缺陷，集中精力每次只修正一个缺陷。校验者每次只校验一个缺陷是否已经正确修正。
4) 不可重现的缺陷也要报告
首先缺陷报告必须展示重现缺陷的能力。不可重现的缺陷要尽力重现，若尽力之后仍不能重现，仍然要报告此缺陷，但在报告中要注明无法再现，缺陷出现的频率。
5) 明确指明缺陷类型
根据缺陷的现象，总结判断缺陷的类型。例如，即功能缺陷、界面缺陷、数据缺陷，合理化建议这是最常见的缺陷或缺陷类型，其他形式的缺陷或缺陷也从属于其中某种形式。
6) 明确指明缺陷严重等级和优先等级
时刻明确严重等级和优先等级之间的差别。高严重问题可能不值得解决，小装饰性问题可能被当作高优先级。
7) 描述 (Description) ，简洁、准确，完整，揭示缺陷实质，记录缺陷或缺陷出现的位置
描述要准确反映缺陷的本质内容，简短明了。为了便于在软件缺陷管理数据库中寻找制定的测试缺陷，包含缺陷发生时的用户界面（UI）是个良好的习惯。例如记录对话框的标题、菜单、按钮等控件的名称。
8) 短行之间使用自动数字序号，使用相同的字体、字号、行间距
短行之间使用自动数字序号，使用相同的字体、字号、行间距，可以保证各条记录格式一致，做到规范专业。
9) 每一个步骤尽量只记录一个操作
保证简洁、条理井然，容易重复操作步骤。
10) 确认步骤完整，准确，简短
保证快速准确的重复缺陷，“完整”即没有缺漏，“准确”即步骤正确，“简短”即没有多余的步骤。
11) 根据缺陷，可选择是否进行图象捕捉
为了直观的观察缺陷或缺陷现象，通常需要附加缺陷或缺陷出现的界面，以图片的形式作为附件附着在记录的“附件”部分。为了节省空间，又能真实反映缺陷或缺陷本质，可以捕捉缺陷或缺陷产生时的全屏幕，活动窗口和局部区域。为了迅速定位、修正缺陷或缺陷位置，通常要求附加中文对照图。
附加必要的特殊文档和个人建议和注解
如果打开某个特殊的文档而产生的缺陷或缺陷，则必须附加该文档，从而可以迅速再现缺陷或缺陷。有时，为了使缺陷或缺陷修正者进一步明确缺陷或缺陷的表现，可以附加个人的修改建议或注解。
12) 检查拼写和语法缺陷
在提交每条缺陷或缺陷之前，检查拼写和语法，确保内容正确，正确的描述缺陷。
13) 尽量使用短语和短句，避免复杂句型句式
软件缺陷管理数据库的目的是便于定位缺陷，因此，要求客观的描述操作步骤，不需要修饰性的词汇和复杂的句型，增强可读性。
以上概括了报告测试缺陷的规范要求，随着软件的测试要求不同，测试者经过长期测试，积累了相应的测试经验，将会逐渐养成良好的专业习惯，不断补充新的规范书写要求。此外，经常阅读、学习其他测试工程师的测试缺陷报告，结合自己以前的测试缺陷报告进行对比和思考，可以不断提高技巧。
14) 缺陷描述内容
缺陷描述的内容可以包含缺陷操作步骤，实际结果和期望结果。操作步骤可以方便开发人员再现缺陷进行修正，有些开发的再现缺陷能力很差，虽然他明白你所指的缺陷，但就是无法再现特别是对系统不熟悉的新加入开发人员，介绍步骤可以方便他们再现。实际结果可以让开发明白错误是什么，期望结果可以让开发了解正确的结果应该是如何。
希望楼主采纳 ，谢谢！
F. QQBUG提交！
1.先卸载原来的qq 2.清理注册表(优化大师或超级兔子) 3.下载新软件安装(建议到官方网站下载比较有保障 http://im.qq.com/ ) 4.“QQ程序出错，请重新安装”这类QQ故障在很多用户都产生了这种类似的现象，其主要原因如下： (1)电脑引导区，染上了病毒，需要进行彻底杀毒（建议在DOS下用杀毒软件DOS引导盘进行查杀） (2)、针对腾讯公司推出的QQ2008base2类型的版本，其稳定性以及Bug修复方面并未完善，只注重了实用性，并未深入考虑稳定性。 建议修改密码
满意请采纳
G. 提一个bug需要写哪些必要的因素
BUG被提交到了BUG系统后，应该先改哪些BUG呢？在普元，对于BUG的修复有以下几条规则：产品刚进入测试阶段时，BUG的修复先后顺序由开发人员依据BUG的严重程度，以及测试人员的要求，自行决定先修复哪些BUG，主要原则是保证基本用例能够通过，不阻碍测试进度；到了接近产品发布的里程碑时，比如发布Alpha版，Beta1版，Beta2版等里程碑版本时，则必须根据每个里程碑版本的发布目标，由产品经理、项目经理和开发Leader需要共同商定，结合每个BUG的影响程度，来分配每个BUG修改的优先级，BUG优先级定义的规则如下：
P0级，必须要尽快修复的BUG，这些BUG直接影响到产品发布进度和最重要的功能使用，这些BUG不修复，将会阻碍其他任务的完成，项目组必须组织人力，马上进行修复；
P1级，在每个里程碑结束前必须修复的BUG，对修正的要求不是非常迫切，但是必须在里程碑版本发布之前修复掉；
P2级，如果时间允许就修正的BUG，这样的BUG一般来说不会影响里程碑版本的使用，是否需要修复根据项目组的时间和资源情况考虑，如果时间允许，就会修正；
P3级，很低优先级的BUG，可以根据项目组时间和资源情况，决定是否修复，或遗留到产品发布后作为遗留BUG进行修复，在下一个版本中进行发布。
同时项目经理为每个版本制定出一份BUG修复计划，明确每个BUG的修复优先级、修复时间、修复版本，这时开发人员就必须按照这个计划进行BUG修复；
我们团队现在直接在日事清内进行“bug管理”，提bug人员将bug输入到“收集”状态，由产品助理集中处理，视bug具体情况将bug拖拽到其他集中状态。如果拖拽到“确认”，在该bug下添加相应技术人员让其处理，技术人员会在日事清协作系统内收到通知并且bug同步到其收纳箱，方便技术人员集中处理，解决后由技术人员拖拽到“已解决”状态卡片。
H. bug的概念和分类
大家好，我是十一。
前面篇我们都在讲测试用例设计的案例、设计方法、工具。本篇呢我们来聊聊bug，程序里的小虫子。
所谓“（Bug）”，是指程序中隐藏的错误或者缺陷。
早在 软件测试的工作周期 一文附录中我们就已经对bug来源做了解释，感兴趣的点击链接回顾。
一条Bug记录最基本应包含：
※bug编号：bug的唯一id，以方便尽快找到此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修改的先后顺序（“缺陷的轻重缓急”）。
具体划分方法各个公司不尽相同，但是通用原则大体一样：
※ 严重性 ：表示软件缺陷的恶劣程度，当用户碰到该缺陷时影响的可能性和程度。
※ 优先级 ：表示修复缺陷的重要程度和紧迫程度。
下面我们给出严重性和优先级的常用划分方法，需要注意的是，我们这个只是示例，每个公司划分方法也都不尽相同，多多少少有些改变，大家作为参考即可。
严重性：
a.系统崩溃、数据丢失、数据毁坏、安全性被破坏、核心功能未实现（比如QQ 没有做聊天功能）、主体功能实现与需求不符（比如QQ聊天功能只能发消息不能收消息）
b.操作性错误、结果错误、功能模块的某个点未实现（比如QQ没有做消息提醒）,兼容性错误
c.小问题、拼写错误，UI布局不美观、特定情况下的罕见bug
d.一些易用性的建议（也可以归为3）
优先级：
a.立即修复，阻止了进一步测试
b.在产品发布之前必须修复
c.如果时间允许应该修复
d.可能会修复，不影响发布。
再次重申，上述清单只是范例，具体的缺陷划分规则还要依据实际项目、应用场景来制定。比如：通常我们认为毁坏用户数据的缺陷比简单的拼写错误缺陷严重。但是如果数据毁坏仅在用户几乎用不到的罕见特例中出现，而拼写错误导致所有用户安装软件产生问题呢？此时数据毁坏与拼写错误的优先级和严重性就不言而喻了，必然是拼写错误的严重性和优先级高于数据毁坏的。
严重性和优先级对于审查缺陷报告并决定哪些软件缺陷应该修复，以何种顺序修复的人员极为重要。如果一个程序员受命修复10个缺陷，他就应该先从严重性为1 、优先级为1这样的缺陷着手，而不是优先修复简单的，有简到难。
同样，两个项目经理--一个管理广告门户网站/游戏软件，一个管理医院检测仪/性能检测类软件，对待同样的问题就会做出两种选择，比如同样都是页面美观问题，在前者那优先级可能就是2，在后者那可能就是3或者4了。
好了，今天到此结束。如有任何问题请留言及时与我沟通，我会尽快回复大家！谢谢大家~我们下次再见！
I. 我经常看到手机的某个版本的BUG少，麻烦给我解释一下BUG是什么
BUG就是缺陷 漏洞想意思
“BUG”的由来：
Bug一词的原意是“臭虫”或“虫子”。但是现在，在电脑系统或程序中，如果隐藏着的一些未被发现的缺陷或问题，人们也叫它“Bug”，这是怎么回事呢？
原来，第一代的计算机是由许多庞大且昂贵的真空管组成，并利用大量的电力来使真空管发光。可能正是由于计算机运行产生的光和热，引得一只小虫子�Bug钻进了一支真空管内，导致整个计算机无法工作。研究人员费了半天时间，总算发现原因所在，把这只小虫子从真空管中取出后，计算机又恢复正常。后来，Bug这个名词就沿用下来，表示电脑系统或程序中隐藏的错误、缺陷或问题。
与Bug相对应，人们将发现Bug并加以纠正的过程叫做“Debug”，意即“捉虫子”或“杀虫子”。遗憾的是，在中文里面，至今仍没有与“Bug”准确对应的词汇，于是只能直接引用“Bug”一词。虽然也有人使用“臭虫”一词替代“Bug”，但容易产生歧义，所以推广不开。
所谓“（Bug）”，是指电脑系统的硬件、系统软件（如操作系统）或应用软件（如文字处理软件）出错。硬件的出错有两个原因，一是设计错误，一是硬件部件老化失效等。软件的错误全是厂家设计错误。那种说用户执行了非法操作的提示，是软件厂商不负责的胡说八道。用户可能会执行不正确的操作，比如本来是做加法但按了减法键。这样用户会得到一个不正确的结果，但不会引起bug发作。软件厂商在设计产品时的一个基本要求，就是不允许用户做非法的操作。只要允许用户做的，都是合法的。用户根本就没有办法知道厂家心里是怎么想的，哪些操作序列是非法的。
从电脑诞生之日起，就有了电脑BUG。第一个有记载的bug是美国海军的编程员，编译器的发明者格蕾斯·哈珀（GraceHopper）发现的。哈珀后来成了美国海军的一个将军，领导了着名计算机语言Cobol的开发。
1945年9月9日，下午三点。哈珀中尉正领着她的小组构造一个称为“马克二型”的计算机。这还不是一个完全的电子计算机，它使用了大量的继电器，一种电子机械装置。第二次世界大战还没有结束。哈珀的小组日以继夜地工作。机房是一间第一次世界大战时建造的老建筑。那是一个炎热的夏天，房间没有空调，所有窗户都敞开散热。
突然，马克二型死机了。技术人员试了很多办法，最后定位到第70号继电器出错。哈珀观察这个出错的继电器，发现一只飞蛾躺在中间，已经被继电器打死。她小心地用摄子将蛾子夹出来，用透明胶布帖到“事件记录本”中，并注明“第一个发现虫子的实例。”[1]
从此以后，人们将计算机错误戏称为虫子（bug），而把找寻错误的工作称为（debug）。
J. 测试中遇到不可重现的Bug怎么办
测试中遇到不可重现的Bug处理办法：
一、一定要提交。
1． 记得有这么个缺陷，以后再遇到的时候可能就会了解发生的原因。
2． 尽力去查找出错的原因，比如有什么特别的操作，或者一些操作环境等。
3． 程序员对程序比测试人员熟悉的多，也许你提交了，即使无法重新，程序员也会了解问题所在。
4． 无法重现的问题再次出现后，可以直接叫程序员来看看问题。
5． 对于测试人员来说，没有操作错误这条.既然遇到，就是问题。即使真的操作错了，也要推到程序员那里，既然测试人员犯错误，用户也可能会犯同样的错误。错误发生的时候，Tester最大。
二、程序不是测试人员写的，出问题也不是测试人员的原因。
至于无法重现，可能的原因很多，因为测试人员看到的只是程序的外部，无法深入程序内部，所以把责任推给测试人员是不对的。测试人员的任务只是尽力重现问题，而不是必须重现。
三、下次再遇到的时候，拉他们来看就可以了。
因为问题如果无论如何无法重现，程序员确实也没有什么好的解决方法。而且此类问题即使程序员说修改了，测试员也没有好的方法去验证是不是。
四、你可以告诉程序员，测试过程是没有错误的。
测试人员只是检查程序中可能存在的问题，虽然测试人员使用一定的手段方法努力去覆盖所有的情况，但这些都是理论的推测。在实际中，可能因为人员、环境、配置等种种原因出现各种各样的问题，在测试人员这里发现问题是公司内部的事情，程序发到外面可就是公司的形象问题了。
五、问题无法重现，也要提出，程序员那里可以回复无法再现。问题放在那里，等到再次出现的时候，就立刻叫程序员过来查看。实在没有再次出现，最后可以写到报告中，说出现了什么现象，但无法再现（比较严重的问题才如此处理，小问题经理之间商量商量可能就算了）。