Bug不能重现的原因分析及其对策
案例：如何解决难以重现的BUG
案例：如何解决难以重现的BUG我时不时会去逛逛，学些诊断软件问题的技巧。
Mark的博客有⼀个特点，他有很多案例，专门分析在⽇常使⽤电脑时碰上的各种问题，⾥⾯有很多分析、解决问题的技巧是颇值得学习的。
我在想，从事软件开发这么多年来，⾃⼰也积累了⼤量的经验，如果能把这些经验做些整理写出来，对⾃⼰是⼀份很好的总结，对别⼈应该也有借鉴作⽤。
因此我也打算写⼀些实际⼯作中遇到的⽐较典型的案例。
这⼀篇谈谈解决随机BUG的⼀些经验。
我这⾥说的随机BUG是指那些你没法通过⼀些确定的步骤可靠地重现的BUG。
我想做软件开发的⼈都会同意，即使不是最难，随机BUG应该也是最难解决的BUG类型之⼀。
有⼈也许说，只要找到问题的根源就⼀定能可靠地重现问题，不能重现只是因为你还没找到问题的根源。
这话也许没错，但也还是存在⼀些情况，即使找到了问题的根源也没法可靠地重现，⽐如我碰上的这个就属于这种情况。
问题是这样的，我们是⼀家设备制造商，有⾃⼰定制的主板，在主板上开发系统软件（Kernel+Drivers），再在系统软件上构建应⽤软件－这在嵌⼊式系统开发中是⽐较典型的⼀种模式。
我们有⼀款产品使⽤的平台是StrongArm SA1110+Windows CE 4.1（这在当年是很常见的⼀种解决⽅案）。
问题出在关机时，有时候屏幕已经⿊了，看起来设备已经完全下电，但其实内部主板的电还没掉，这时按开机键没有反应－系统lockup了。
结果是只能拔掉AC电源和电池让主板下电然后才能重新开机。
恶劣的情况是，如果⽤户只使⽤电池供电，⽽且他没意识到系统处于 lockup状态，过不了多久电量耗尽电池就会报废。
要找出这个问题，当然必须搞清楚系统挂在了哪⾥，然后才能寻找对策。
因此⾸先搞清楚系统关机的机制。
在Windows CE中，关机操作触发后，下电过程由电源管理模块执⾏，⼤概是这样：1. ⼴播关机消息给关注该消息的Application和Driver；2. 挂起图形界⾯⼦系统（GWES）；3. 通知所有⾮块设备驱动（non-block drivers，这些driver可能需要访问注册表或⽂件因此需要在块设备驱动停⽌之前处理）；4. 给Kernel发送IOCTL_HAL_PRESUSPEND消息(OEM开发商可以利⽤这⼀消息做⼀些关机前处理）；5. 禁⽌除电源管理模块以外的所有其他模块使⽤注册表和⽂件系统；6. 通知所有块设备驱动（block drivers）；7. 关闭图形⼦系统；8. 关闭⽂件系统；9. 调⽤OEMPowerOff。
如何处理难以重现的缺陷
如何处理难以重现的缺陷在测试执行过程中，经常会碰到一些不可重现或者很难重现的缺陷，特别是在进行系统的非功能性测试的时候，例如：稳定性测试、压力测试、满配置测试，兼容性测试等。
在非功能性测试过程中发现的缺陷往往是严重程度比较高的，例如：系统不稳定、系统不稳定、系统在不可预测的时候重启等。
假如软件产品交付给用户之后，在用户现场或者系统运行过程中出现由于这样的缺陷而导致的失效，那么将会大大影响用户对产品的信心。
虽然有的组织和项目可能不统计无法重现或很难重现的缺陷，甚至忽视难以重现的缺陷。
但是笔者认为，针对难以重现的缺陷，可以采取尸位素餐措施改进测试的效率和有效性：1）尽量获取系统的打印信息和缺陷信息2）测试人员应该报告不可重现的缺陷3）在产品操作指南（使用说明）中明确告知客户4）缺陷报告中明确该缺陷能够重现的可能性1、尽量获取系统的打印信息和缺陷信息尽管测试人员在测试过程中经常会碰到一些难以重现的缺陷，但是，系统出现异常行为的时候，通常总是会存在一些蛛丝马迹的。
这就需要测试人员需要有足够的耐心和细心。
同时，测试人员在测试测试人员在测试过程中，应该养成有些良好的习惯，例如：打开系统的缺陷端口，不断捕获系统的打印信息，特别是信息中提示错误和告警的信息，从而帮助开发人员跟踪和定位缺陷发生的原因，从而有利于开发人员解决这种类型的缺陷。
例如：在测试过程中，测试人员经常会碰到系统重启的问题。
对于这样的问题，我们可以从下面几个方面对该问题进行分析：1）仔细分析缺陷端口中打印的错误和告警信息，例如：信息是系统级别的，还是模块级别的？系统什么情况下会出现这样的信息？2）分析系统在什么情况下会出现重启，例如：灵气的溢出、野指针、堆栈溢出。
通过分析原因，可以更好的分析导致缺陷的根本原因。
2、测试人员应该报告不可重现的缺陷即使是不可重现的缺陷，笔者认为，测试人员也应该报告这样的缺陷。
假如组织内要求测试人员报告不可重现的要求，可以推动测试人员对这样的缺陷进行仔细的研究和分析；报告不可重现的缺陷可以形成项目的不可重现的缺陷数据库，定期浏览这些缺陷，并进行集中的分析，可能会在不同的缺陷描述中发现一些共同的或者可能有联系的信息，有助于问题的解决。
测试过程中遇到了不能复现的bug的时候你该怎么办
测试过程中遇到了不能复现的bug的时候你该怎么办
偶然性问题的处理
在测试执⾏过程中，⼀旦系统出现异常信息，我们第⼀时间要做的是截图，保存证据；
确定是偶然性的bug之后，收集相关的⽇志，连同截图⼀并提交过单位开发
如果缺陷在当前版本⽆法复现，且缺陷的影响程度⽐较低，我们会跟踪三个版本，如果后三个版本都⽆法复现，就可以关闭该缺陷；
如果很严重的Bug,除了要及时反馈给上级之外，最后还要写到测试报考中，说明出现了什么现象，但⽆法再现！
详细记录预期与实际的不⼀致，如果不⼀致，要从多个⾓度多测试⼏次，尽量详细的定位软件出错的位置和原因，并测试出因为这个错误会不会导致更严重的错误出现，最后把详细的输⼊和实际的输⼊，以及对问题的描述写到测试报告中。
因为在⼀个项⽬组中，项⽬的开发时间是有效的，如果我们测试时能把问题描述详细⼀些，那么开发⼈员就会很容易的重修这个问题，也就能更快的解决问题，节省项⽬时间。
提交缺陷时与开发的关系处理
坚持原则
对事不对⼈，拿证据说话
尊重对⽅的劳动成果，平时和开发⼈员打好关系，不要把关系搞僵。
深入剖析Bug的根本原因
深入剖析Bug的根本原因在软件开发和测试的过程中，我们经常会遇到各种各样的Bug。
它们可能造成软件功能异常、性能下降甚至导致系统崩溃。
为了能够更好地理解和解决Bug，我们有必要深入剖析其根本原因。
本文将从软件开发的不同阶段和层面分析Bug产生的根本原因，并提出相应的解决策略。
1. 需求阶段在软件开发的需求阶段，Bug的根本原因通常源于需求不清晰或不完整。
这可能导致开发人员根据错误或模糊的需求编写代码，进而产生Bug。
为了解决这一问题，我们应该加强需求分析和沟通，确保各方对需求有清晰的认识和理解。
同时，使用合适的工具和技术进行需求管理和跟踪，可以帮助开发团队更准确地理解需求，从而减少潜在的Bug。
2. 设计阶段在设计阶段，Bug的根本原因可能与设计不合理或设计缺陷有关。
设计不合理可能包括模块之间的接口定义错误、数据结构设计不恰当等。
而设计缺陷可能涉及到算法逻辑错误、边界条件处理不完善等问题。
为了避免这些Bug，我们应该进行充分的设计评审和测试，确保设计的正确性和完备性。
同时，使用常见的设计原则和模式可以提高软件的可维护性和可扩展性，减少潜在的Bug产生。
3. 编码阶段在编码阶段，Bug的根本原因可能是编程错误和不规范的代码风格。
编程错误包括语法错误、逻辑错误等，而不规范的代码风格可能导致程序的可读性和可维护性下降。
为了减少编码阶段引入的Bug，我们应该遵循良好的编码规范和标准，使用合适的工具进行静态代码分析和自动化测试。
此外，进行持续集成和代码审查也可以有效地发现和修复Bug。
4. 测试阶段在测试阶段，Bug的根本原因通常是测试用例不充分或测试过程不严谨。
测试用例不充分可能导致一些潜在的Bug未被发现，而测试过程不严谨可能导致一些已修复的Bug再次出现。
为了更好地进行测试，我们应该制定全面而充分的测试计划，并使用多样化的测试技术和工具。
同时，进行回归测试以验证已修复的Bug是否彻底解决也是非常必要的。
如何在Bug报告中提供有效建议
如何在Bug报告中提供有效建议在软件开发过程中，Bug报告是不可或缺的一部分。
它是开发团队快速了解、定位和修复软件中存在的问题的重要依据。
然而，单纯地提出问题并不足以帮助团队解决Bug。
为了更高效地协助开发团队解决问题，我们应该在Bug报告中提供有效的建议。
本文将探讨如何在Bug报告中提供有效建议的方法。
一、详细描述Bug的现象在提供有效建议之前，首先需要详细描述Bug的现象。
描述应尽量准确、清晰，并包含相关背景信息。
例如，软件的版本、操作系统，以及操作步骤。
这些信息有助于开发团队复现问题，从而更好地理解和定位Bug。
二、重现Bug并记录步骤为了帮助开发团队更好地理解和定位问题，我们应该尽可能详细地记录重现Bug的具体步骤。
这包括所需的输入、操作顺序以及预期结果。
这样的记录可以提供开发团队在解决问题时的参考和指导。
三、分析问题的根本原因在提供建议之前，我们需要先对问题进行分析，尝试找出问题的根本原因。
这可以通过检查日志、错误信息等途径进行。
定位问题的原因有助于我们提供更有针对性的建议。
四、提出改进建议基于对问题的分析，我们可以提出改进建议。
建议应具体、明确，并可以解决Bug所引发的问题。
建议中可以包括代码调整、功能改进、界面优化等各种方面。
此外，还可以提供相关的示例代码或截图，以便开发团队更好地理解和实施建议。
五、阐述建议的优势和意义在提出建议时，我们应清晰地阐述建议的优势和意义。
这有助于开发团队更好地评估建议的价值，并决定是否采纳。
通过清晰地阐述建议的优势，我们可以提高建议被接受的可能性，从而更好地推动问题的解决和软件的改进。
六、总结和再次强调在报告中，我们还可以进行总结和再次强调。
总结可以将之前提到的问题、现象和建议整合在一起，提供全面的视角。
再次强调可以帮助开发团队更好地关注和理解我们提供的建议。
结论在Bug报告中提供有效建议是解决问题的关键步骤。
通过详细描述问题、记录步骤、分析原因以及提出明确的建议，我们可以帮助开发团队更好地理解、定位和解决问题。
偶然性不可重现的BUG怎么处理
偶然性不可重现的BUG怎么处理?一、一定要提交!!1. 记得有这么个缺陷，以后再遇到的时候可能就会了解发生的原因。
2. 尽力去查找出错的原因，比如有什么特别的操作，或者一些操作环境等。
3. 程序员对程序比测试人员熟悉的多，也许你提交了，即使无法重新，程序员也会了解问题所在。
4. 无法重现的问题再次出现后，可以直接叫程序员来看看问题。
5. 对于测试人员来说，没有操作错误这条.既然遇到，就是问题。
即使真的操作错了，也要推到程序员那里，既然测试人员犯错误，用户也可能会犯同样的错误。
错误发生的时候，Tester最大。
二、程序不是测试人员写的，出问题也不是测试人员的原因。
至于无法重现，可能的原因很多，因为测试人员看到的只是程序的外部，无法深入程序内部，所以把责任推给测试人员是不对的。
测试人员的任务只是尽力重现问题，而不是必须重现!!三、下次再遇到的时候，拉他们来看就可以了。
因为问题如果无论如何无法重现，程序员确实也没有什么好的解决方法。
而且此类问题即使程序员说修改了，测试员也没有好的方法去验证是不是。
: )四、你可以告诉程序员，测试过程是没有错误的。
测试人员只是检查程序中可能存在的问题，虽然测试人员使用一定的手段方法努力去覆盖所有的情况，但这些都是理论的推测。
在实际中，可能因为人员、环境、配置等种种原因出现各种各样的问题，在测试人员这里发现问题是公司内部的事情，程序发到外面可就是公司的形象问题了。
需要让程序员理解，测试人员是帮助他们的，不是害他们的。
客户那里发现问题比测试员发现问题结果要严重的多。
五、测试部门是独立与开发部门的呀，真的打交道，也是经理对经理。
在我们这里，工作上面的事情，和程序员相互只能商议解决，并没有谁高谁低。
问题无法重现，也要提出，程序员那里可以回复无法再现。
问题放在那里，等到再次出现的时候，就立刻叫程序员过来查看。
实在没有再次出现，最后可以写到报告中，说出现了什么现象，但无法再现(比较严重的问题才如此处理，小问题经理之间商量商量可能就算了)。
软件项目Bug案例分析及防治举措
软件项目Bug案例分析及防治举措软件项目Bug是软件产品没有达到预期设计目标，在软件内部存在的一种缺陷。
在不影响用户和系统正常运行的情况下处于隐蔽状态，没有表现出来，当Bug发生运行错误时，对银行的影响主要表现在三个方面：一是影响正常的业务需求开发，有不少业务需求都是各个专业部门在争夺客户过程当中亟待开发投产的，一旦停下来，势必对业务发展造成大的影响;二是带有Bug软件造成的错误给银行带来烦恼，工作人员要为此付出大量的精力去处理客户的不满;三是受到影响的客户，一直在做着反面宣传，使银行的信誉会受到损失。
本文总结分析以往软件项目研发工作中出现的Bug案例，同时提出防治措施与大家交流分享。
一、软件项目Bug案例分析(一)软件项目Bug案例1、软件设计Bug。
在某版本投产后，发现零售项目的监控文件导入事后监控系统，由于文件没有排序导致运行时间很长，影响了事后监控系统的工作效率，造成业务人员无法正常操作交易。
经过技术人员跟踪分析，造成该问题的原因是在系统设计时，设计人员只是关注了该零售项目主机处理功能的实现，遗漏了对其他系统的影响。
2、软件编码Bug。
某版本投产后，营业网点反映某联机交易的反交易日志错误，导致账务横向不平。
经过技术人员跟踪分析，原因是程序员在编码时，没有意识到程序之间的相互关联，忘记了对公共程序的修改，结果造成当柜员办理两笔相同金额的业务时，如果冲正其中一笔时，会同时将另一笔冲掉。
3、软件测试Bug。
某版本投产后，网点柜员发现远期结售汇系统中一个展期交易，当贷方账号输入的不是基本结算账户时交易报错。
经过技术人员跟踪分析，原因是测试人员在编制测试案例时，贷方账号输入时，只考虑基本结算账户，未考虑其他账户类型企业结算账户。
4、软件文档Bug。
某版本投产后，网点发现国际卡柜面取款后网点报表双倍挂帐。
经过技术人员跟踪分析，发现造成该问题的原因是投产使用的参照表模板中，将该取款交易分离代码记录方向为借方，错误的设置为贷方。
关于bug分析与异常处理的一些思考
关于bug分析与异常处理的⼀些思考前⾔：⼯作三年了，⼯作内容主要是嵌⼊式软件开发和维护，⽤的语⾔是C，毕业后先在⼀家⼯业⾃动化控制公司⼯作两年半，⽬前在⼀家医疗仪器公司担任嵌⼊式软件开发⼯作。
软件开发中，难免不产⽣bug；产品交付客户使⽤后，难免不产⽣问题，那么关于bug分析和异常处理则是软件开发和维护中⽆法躲避的⼯作内容。
⼯作⾄今，我⼀直在思考关于bug分析和异常处理，有没有⼀些原则性、规律性的东西可循，以减少bug，提⾼bug分析的效率，对于⼀些异常，基于什么原则进⾏处理，才能达到客户的要求。
这些问题每个⾏业、每个职位上的⼈都会有不同的想法，但是⼤家的⽬的是⼀样的，即提⾼产品的稳定性、可靠性、可⽤性和易⽤性。
我暂且说说，⾃⼰的⼀些想法吧，不⼀定正确，但是算是⾃⼰想法的⼀种梳理吧，其实⾃⼰希望通过这种梳理增强⾃⼰关于这些问题的认识，促进⾃⼰的进⼀步思考。
备注：因为只是⾃⼰的⼀些想法，就暂且不考虑⾏⽂了，呵呵原则⼀：⾃⼰写的软件中肯定存在bug这⼀原则适⽤于软件开发和编码阶段，她让⾃⼰保持⼀颗谦虚谨慎的⼼，那么⾃⼰在设计和编码阶段就会考虑可能出现的问题，对于可能出现的问题，采取防御式编码。
譬如：在嵌⼊式软件中，不使⽤动态分配内存，这样就杜绝了内存泄露的问题，虽然这样做浪费了内存资源，但是相⽐后续分析内存泄露的问题带来的资源消耗和产⽣的严重产品问题，浪费的这点内存还是很划算的；不要相信⾃⼰是个没有“笔误”的家伙，因此，在书写if判断的时候，⾃⼰总是会按照if(42 == a)这样的⽅式去写；不要相信⾃⼰的是个“仔细”的家伙，因此，每写完⼀段代码，我都会习惯性地ctrl+s和编译，这样就可以及时发现语法错误和警告，此时，代码修改的不多，因此问题很好被定位和解决，如果等到⾃⼰码完⼏百⾏代码以后，再去编译，处理编译错误和警告，可能会花费更长的时间。
我相信迭代式的编译，步步为营是个不错的想法，呵呵；其实，也要采取迭代式的测试，即每实现⼀个功能就要去测试，待测试通过后，再去实现其余的功能，最好不要等到所有功能都实现以后，再开始测试，否则，⾃⼰花在调试和测试的时间会远远超过⾃⼰的预期。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Bug不能重现的原因分析及其对策
摘要：本文简要分析了无法重现的Bug的可能产生原因，包括环境不一致、缺少最准确的描述和浏览器的不当设置。
针对这些原因，本文给出了相应的对策。
通过这些措施，可以重现许多以前认为不可重现的Bug。
关键词：重现；Bug；环境
在测试人员提交bug后，最不希望看到的结果是它们被标记为INVALID，尽管你坚信这一定是Bug。
开发人员查看了bug的Description后，最不希望的结果是你无法重现它们，尽管他使用了所有可能的方法去重现它。
一旦出现这样的情况，测试人员会很伤心，开发人员也会对测试人员有意见。
这就使得关系本来就不怎么融洽的测试人员和开发人员之间的关系更加紧张。
这对于关系紧张的测试人员和开发人员来说，无异于是火上浇油。
为了减少这种情况的出现，非常有必要分析一下Bug不能重现的原因。
根据我的测试经验，Bug不能重现的原因有：
一、环境不一致
这是bug不能重新的最主要的原因。
在开发人员认为这是无效的bug 里面，估计至少有80%的Bug 是因为环境不一致的原因造成的。
这既包括开发环境和测试环境的不一致，也包括开发环境和系统的实际运行环境不一致。
Bug产生是有一定原因的，它的重现也需要一定的环境。
如果没有相应的环境，那么你可能很难这个Bug。
从广义上来说，保证或影响系软件的任何因素都是环境。
例如，硬件的配置、软件的设置、网络的带宽、网速等。
通常，环境中的软件因素有：系统的Build、Application Server的类型和Version、Operation System 的语言和Version、浏览器的语言和Version等。
下面是我的一些有趣的经历：某个Bug 只出现在WebSphere 6.0.2.15上，按照开发人员的要求，把WebSphere升级到6.0.2.17 后，此Bug就自动消失了。
因此，此Bug是因为WebSphere的版本不一致引起地。
几个图片在某个Build上莫名其妙地消失了，刚开始怀疑是开发人员修改别的Bug而引起的错误。
后来经过仔细认真地测试才发现，原来是操作系统的语言搞的“鬼”：测试人员使用的机器的操作系统语言是简体中文，开发人员使用的是繁体中文。
Bug的Description里面缺少重现bug 的最准确的操作,下图是测试系统在增加一个Role时的页面：
图1：增加Role的页面
测试人员在输入某些数据、然后点击Save后，“一不小心”就出现了ng.NullPointerException 的错误。
说一不小心，是因为这是测试人员在无意中发现了，并且出现这个错误后，你再也无法增加任何Role了（当然也无法重现此Bug了）。
最糟糕的是，别的与Role有关的许多功能点也无法验证。
尽管不知道为什么发生了这个错误，也无法重现此Bug，但考虑到此Bug的严重性，测试人员还是把此Bug提交到Bug库里去了（事后证明这是非常明智的举动）。
在测试下一个Build的时候，我要求测试人员重点关注此Bug。
后来在DBA的帮助下找到了产生此Bug的真正原因：输入Role Code后，如果Role Name为空，页面没有进行检查（前台没有检查）；但点击Save后，数据需要保存到数据库时，Role所在的Table要求Role Code和Role Name都不能为空。
因此就出现了ng.NullPointerException这个错误信息。
找到此Bug发生的原因后，我建议开发人员把Role Code当作Role Name，如果用户输入Role Code 而没有输入Role Name。
经过测试，此Bug就再也不会出现了
二、浏览器的不当设置
对于Web测试来说，IE的设置又是对重现Bug起着重要的作用。
下面的几个图片说明了浏览器的几个关键设置：
图2：Internet临时文件的设置
下页链接
图3：“高级”选项的设置
说明：在“高级”选项中，对测试起重要作用的是“禁止脚步调试”（不选择，即前面不要有勾）和“显示每个脚本错误的通知”（选择它，即前面要出现勾）。
这些设置对重现有关脚本错误的Bug起着重要的作用。
根据这些脚本错误的通知，开发人员可以快速发现代码中的错误，并及时修复它。
三、内存泄露
某些系统长期运行后出现运行速度慢、反应迟钝等现象，其中一个主要的原因就是内存泄露。
有的开发人员没有养成及时回收内存的习惯，结果系统在不断地申请内存空间，却没有一点内存释放。
这类错误在短期内不会出现，但当系统长期运行时就会出现，并且由此会引发一系列的问题。
此类问题只有经过长时间的运行测试，才可能会被发现。
四、函数接口类型不匹配
此类错误难以重现，并且难以发现它的真正原因，一般只有在查看源代码后才能发现。
某些类型的数据会被系统自动转换，一般也不会出现错误；但有些数据被截断或被强制转换成另外一种数据类型时，会出现一些潜在的错误。
在集成测试时此类错误最有可能发生。
既然分析出了这些Bug不能重现的原因，我们就可以对症下药了：
1. 测试人员要有重视测试环境的意思，并在Bug Report里面增加对测试环境的准确描述，特别是影响重现此Bug的那些环境因素。
2. Bug的Step要准确说明操作步骤。
为了重现一个Bug，测试人员可能需要对几个Build进行连续跟踪、测试和定位产生这个Bug的最根本原因。
3. 正确设置浏览器的选项。
4. 对性能有要求的软件或系统一定要进行长期负荷测试(Loading Testing )，以发现内存泄露等需要长期运行才能出现的问题。
根据微软的测试经验，如果软件能通过72小时的强力测试，则该软件72小时后出现问题的可能几率微乎其微。
因此只需对软件进行72小时的强力测试即可。
5. 集成测试时一定要注意函数接口类型是否匹配。
6. 测试人员要与开发人员、DBA等保持良好的关系。
遇到问题要及时、主动与他们沟通，听取他们的意见。
在他们的帮助下，你可以更容易地找到问题的关键所在之处。
根据上面的这些建议，我相信大多数不能重现的Bug都可以重现了。
当然由于测试的系统的开发语言、开发平台等因素的不同，恕笔者不能一一列举出无法重现的Bug发生所有原因。
如果还是遇到某些严重的、却又无法重现的Bug，那么也不必惊慌，你可以按照下面的操作去查找产生Bug的原因：
1. 积极回忆Bug的症状和所有的环境因素，一丝一毫的细节都不要错过。
2. 与开发人员、DBA、系统设计人员、项目经理等一起分析那些环境因素，根据以往的经验分析影响此Bug重现的重要因素，并在相同的环境上安装同样的系统进行测试，以验证所做的猜测。
另外，对于某些无法重现、但严重程度不是很高的Bug，可以暂时只作记录、而不必花费大量的人力和物力去分析。
如果下次又出现了，那么根据发生的频率再去分析是否需要跟踪此Bug。
如果需要跟踪它，那么在它又出现后一定要立刻对当时的环境进行截图，如错误信息、界面、日志等。
这样也利于开发人员定位、分析它，从而准确、快速地修复它。
如果条件允许，测试人员应立即保护现有环境，并邀请相关的开发人员和系统分析人员一起研讨产生此问题的原因和解决方法。