1、这个bug我这边重现不了

解决办法

Bug应该简明扼要，重点突出。如果描述存在歧义，一定要总结并尽快改进。有时会遇到概率性的bug，要告诉开发概率是多少，尽可能多的提供重现的条件。

在复现问题时，希望能大致判断几个问题点，然后和测试人员沟通下，需要如何捕获信息，捕获那类信息？是不是提供debug版本进行复现，或者根据预判的点增加打印信息版本进行复现？

2、这个不是代码问题，需求这么定义的

解决办法

需求也是人定的，如果觉得有异议，可以找需求人员询问清楚，为什么这样定义，把自己的想法告诉他们，看他们怎么决定。如果被需求说服了当然是最好的，如果自己还是不同意需求的看法，需求又不同意我的提议，那只能听他的，毕竟权力在他那里。但是我们可以保留交流的记录，证明曾经在这里发生过歧义。

3、这块是别人负责的，我负责的部分没有问题

解决办法

如果bug是由开发的项目经理来分发到程序员，那就是项目经理来面对这样的问题，而不是测试。当然，项目经理当然有项目经理的处理办法。可是，测试遇到这样的问题怎么办呢，把负责相关内容的开发都邀请到一个讨论组里，让他们自己讨论，这样更清楚，不必在测试这里中转。如果他们都觉得代码没问题，而我也有强有力的截图和真相，那就只有上交给上级领导，让他们来决定怎么解决。

4、有问题吗？（也就是开发不认为这是个问题）

解决办法

测试人员一定比开发要敏感，对bug的容忍度也要低一些。特别是一些不符合用户习惯的bug，开发总觉得无大碍。比如，一个列表默认的宽度太小了，导致初次打开，有一些内容被隐藏在后面，但是这个宽度可以手动调节。开发觉得问题很小，不影响功能，而且也有解决办法，所以不认为是bug。这个时候，就要发挥测试的本事了，嘴甜一点，说说好话，态度柔和一些。因为既然是小问题，解决起来一定不难，耐心地催开发的改过来就好。催一次不行催两次，记住态度一定要好。

5、用户不会像你这样操作的！

解决办法

用户怎么操作，谁都预料不到。我们不可能覆盖所有可能性，但是大多数用户会出现的操作，我们当然要测试。慢慢地把开发从代码的世界里带出来，带到用户的世界里，让他换个角度思考问题，毕竟软件开发不是为了实现功能，是要满足用户需求的。如果最后还是没能说服他，第一向上级反映，第二做好沟通的记录，将来备份在测试报告里。

以上就是软件测试中遇到的常见问题及沟通方法，如果觉得麻烦可以考虑用一些APP自动化测试工具

在软件测试中，ZBB阶段出现严重BUG怎么办？

测试过程中，不管是在什么阶段，如果出现严重性的BUG首先是要提交给相关的人员，然后评估此BUG对整个软件的进程有多大影响，需要开发、产品、测试三方人员共同协调好。

出现这种情况的时候不是考虑个人责任的时候，而是应该考虑整体计划是不是会被打乱，通过充分协调，尽量避免计划延误。

软件测试：提交一个BUG 开发不承认怎么办

先要确认功能与规格说明书是否一致

提交的bug 是否能复现

和负责测试的组长或经理沟通

并和项目经理沟通

也可以和QA 沟,QA 也有上报渠道

如何保证软件测试过程中，发现的BUG深度的问题？

先给深度做个定义吧，或者说认为什么样的问题才算是有深度的呢？？比如发现架构问题算有深度，那么你要了解结构；发现代码隐形问题算是深度，你要了解代码；发现内存泄露算是深度问题，要了解什么是内存泄露，什么引起内存泄露……

软件测试， 当程序遇到BUG的时候,你选择怎样处理.。。软件工程师的面试题+笔试题，希望有经验者指教指教

1.首先确认这个问题到底是不是bug

2.如果是。记录下这个问题的测试环境和测试步骤，实际结果，期望结果

3.将这个问题上传到缺陷管理软件中，并告知相关的开发人员

4.跟踪这个问题的状态，直至这个问题修复

软件测试中如何提交高质量bug

1、唯一性。一个bug说明一个问题，如果有能力的话，一个bug说明一类问题，这一类问题一定要能判断出是一条代码错误引起。 2、可重现。提供这个bug的精确步骤，使开发人员容易看懂。 3、一致性。bug描述及所有信息要前后一致，不可有歧义。 4、完整性。最好能抓图，一目了然；测试环境和特定条件一定要描述清楚，许多软件功能在通常情况下没有问题，而是在某种特定条件下会存在缺陷，所以软件缺陷描述不要忽视这些看似细节但又必要的特定条件。 5、简洁性。通过使用关键词，可以使软件缺陷的标题描述短小简练，又能准确解释产生缺陷的现象。 6、跟踪性。也许随着版本的变化，或者测试的深入，对bug有了新的认识或者新的判断，及时补充相关信息，能够提供给开发更有用的信息。 7、客观性。软件缺陷描述不要带有个人观点，不要对开发人员进行评价，软件缺陷报告是针对产品的。 其实在平时测试中，经常会遇到不能重现的bug，这些问题有不能提交bug，如果放过往往上线后出现的概率很大，问题也一般比较不可接受。所以我觉得对于重现不可重现的bug是做好测试很重要的能力。 1、保留信息。遇到问题，最好抓图，搜集错误日志，保留测试现场环境，一旦发现此问题不可重现，这些数据和信息将很重要。 2、提高意识。很多人在遇到这类问题时，往往觉得后来操作不可重现了，因此就忽视了。这样往往会把此类bug遗留到产品发布后。欠的帐总要还得。 3、自我分析。对于自己分析这类问题，其实对自己的提高是最大的。分析思路：环境问题和操作顺序。 4、寻求帮助。如果研发可以帮忙，并且研发是负责任的话，只有信息全，研发分析往往是最快的途径。如果研发忙或者不乐意做，也是不可厚非的。但就要寻求组内能力强的人员或者组内讨论分析，集中大家的力量往往可以事半功倍。 在我的经历中，通过上面的方法，几乎能把所有的不可重现的问题变成可重现的并且提交bug。

软件测试发现bug怎么处理

一是项目经理通过和客户的交流，完成需求文档，由开发人员和测试人 员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地 方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合 开发人员，测试人员以及客户的意见，完成项目计划。然后sqa进入项目，开始进行统计和跟踪。

二是开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内容包括是否有遗漏或 者双方理解不同的地方。测试人员完 成测试计划文档，测试计划包括的内容上面有描述。

三是测试人员根据修改好的需求分析文档开始写测试用例，同时开发人 员完成概要设计文档，详细设计文档。此两份文档成为测试人员撰写 测试用例的补充材料。

四是测试用例完成后，测试和开发需要进行评审。

五是测试人员搭建环境

六是开发人员提交第一个版本，可能存在未完成功能，需要说明。测试 人员进行测试，发现 bug 后提 交给 bugzilla。

七是开发提交第二个版本，包括 bug fix 以及增加了部分功能，测试人员进行测试。

八重复上面的工作，一般是 3-4 个版本后 bug 数量减少，达到出货 的要求。

九是如果有客户反馈的问题，需要测试人员协助重现以及回归测试。

在传统的 bugzilla 中，bug 描述应该包括以下的信息：① 和 bug 产生对应的软件版本；② 开发的接口人员；③ bug 的优先级；④ bug 的严重程度；⑤ bug 可能属于的模块，如果不能确认，可以用开发人员来判断；⑥ bug 标题，需要清晰的描述现象；⑦ bug 描述，需要尽量给出重新 bug 的步骤；⑧ bug 附件中能给出相关的日志和截图。

高质量的 bug 记录就是指很容易理解的 bug 记录， 所以，对于描述的要求高，能提供的信息多且准确，很好的帮助开发人员定位。

转载请注明出处51数据库 » 软件测试中严重bug案例 软件测试碰到的问题举个例子