间歇性Bug复现+探索性测试学习与整理（2020-11-09）

间歇性Bug复现+探索性测试学习与总结

1、Bug不可复现的原因

• 环境的变更造成了bug难以重现
• 没有找到真正会引发bug的操作序列（环境、代码和数据）
• bug必须使用特殊的数据才会出现，测试人员没有意识到他使用的数据的特殊性
• 测试人员由于错误操作，出现了误报
• 缺少操作录屏+log

2、常规的Bug复现技巧与方法

• 确保所有的步骤都被登记：

记录下所做的所有细节。无意间丢失一个步骤或者增加一个多余的步骤，可能导致无法再现软件缺陷。可以利用录制工具确切的记录执行步骤。所有的目标是确保导致软件缺陷所需的全部细节是可见的

• 详细记录BUG产生的相关信息

如重现频率，发生情况并有截图，操作步骤，软件的版本，发生错误时的各种变量、内存、存储器等存储的数据内容，软件出错时的软硬件环境等。

• 判断是否特定条件和时间

观察软件缺陷仅是不是在特定时刻出现、特定条件下产生。

• 针对特殊数据导致的偶现Bug可以通过

1、画出系统交互图，并识别出每种交互会有什么样的输入、输出数据和中间数据，识别出这些数据的规约和格式，这样就不会对数据有遗漏。
2、考虑数据的等价类、边界值，对这些输入进行组合，分析数据之间是否有耦合关系，如果有耦合关系，弄明白关系是什么，设计违背这些关系的用例。
3、最后采用组合测试工具初步生成测试集，再人工选取最可能出问题的数据集（直觉有时候非常管用）。

• 留意压力和负荷、内存和数据溢出相关的边界条件

执行某个测试能导致产生缺陷的数据被覆盖，而只有在试图使用脏数据时才会再现。在重启机器后，软件缺陷消失，当执行其他测试之后又出现这类的软件缺陷，需要注意某些软件缺陷可能是无意中产生的

• 考虑资源依赖性包括内存、网络和硬件共享的相互作用等

是否仅在其他软件并与其他硬件通信等“繁忙”系统上出现？软件缺陷可能最终证实和硬件资源、网络资源有相互的作用，审视这些影响有利于分离和再现软件缺陷

• 查看log/监控信息

比如系统提供的监控平台，监控日志；应用自己的监控平台、监控日志（如果有的话）；采用一些外部技术手段截取一些中间状态信息，如使用sniffer抓取通讯包，使用Fiddler截获HTTP报文内容；给运行程序插桩来查看内存，堆栈，线程，函数被调用情况等情况，如Jprofile，gpertool等等。

3、探索性测试

什么是探索性测试

• 探索式测试是一种测试方法或者是测试思维。探索测试将学习，测试设计和测试执行整合在一起，形成一种测试方法。从整体考虑网站/App探索性进行测试，不涉及细节的进行测试。是一种经过深思熟虑的测试方式，没有测试脚本，可以使你的测试已有用例以外的场景。能发现更深层的Bug以及模块之间的问题。
• 误区1：探索性测试=临时/随机测试。其实这不太正确的，临时测试是完全随机的测试方法，它和自由式探索性测试比较接近，但探索性测试除了自由式类型外还有其他更有价值的模式与方向，探索性测试更多地是要正式确定要测试的方案的。
• 误区2:探索性测试=回归测试。探索性测试更注重的是思考和学习，不断发现新的问题，而版本的回归测试，是对原有的功能的保证，为持续迭代构筑安全网。重复的功能回归测试应该尽量用自动化的方式来完成，这样，才有足够的人力来进行探索性测试。
• 误区3：探索性测试用来评估软件质量。尽管探索性测试是一种有效的测试方法，但是它不意味着是一种全面覆盖的测试方法。如果要评估测试是否全面，可能需要其他的手段。

如何进行探索性测试

• 测试之前一定会有一个全局的方针战略，即整体的测试计划，它可以避免走错大方向、该测的部分没有覆盖到或者投入了大量时间到计划之外的部分。
• 测试一旦开始，没有固定的思路，测试人员不受任何先入为主的条条框框约束，根据测试途中获取的信息，指导各自走不同的路径，最终目的就是发现潜藏的缺陷。

探索性测试类型与方向

1、基于场景的探索性测试

基于场景的探索性测试是指用户浏览并测试特定场景或功能时的情况。基于对网站或应用程序的学习和观察及其功能，测试人员可以使用探索性测试技术来探索和发现不同情况下的缺陷。他们倾向于使用基于方案的探索性测试来检查不同的可能性。

2、基于策略的探索性测试

这种类型的探索性测试的方法基于诸如边界值分析，风险评估，等效技术之类的策略。要执行基于策略的探索性测试，测试人员必须熟悉网站或应用程序功能，以便能够高效地进行操作以获得更好的结果。

3、自由式探索性测试

自由式探索性测试主要用于测试人员想要进行快速冒烟测试的情况。顾名思义，它没有任何明确的测试方法，场景或测试范围，相反，测试人员以自由方式进行调查缺陷。为了能够有效地进行自由式探索性测试，测试人员必须熟悉网站或应用程序，才能在没有任何详细计划的情况下轻松掌握缺陷。

4、基于反馈的探索式测试

a.基于反馈的探索式测试缘于自由式测试，但是随着测试历史的形成，测试人员们就会利用反馈来指导今后的探索。“覆盖”就是典型的例子。一名测试人员通过咨询那些覆盖指标(代码覆盖、用户界面覆盖、特性覆盖、输入覆盖或者其中的某一些组合)来选中新的测试用例，以使这些覆盖指标得以提高。覆盖指标只是收录反馈信息的标志之一。我们也会看其他标志，如代码改动数量和软件缺陷密集程度等。
b.基于反馈的探索式测试时一种“上一次测试”：在上一次我根据应用程序的最后状态选了每某一个输入之后、下一次我就会选中另外一个输入。或者是，在上一次遇到这个界面时我用A属性，这一次我就会用B属性。
c.基于反馈的探索式测试工具是非常有价值的，它可以是测试人员保存、搜索测试历史并据此采取实时行动。不幸的是这样的工具很少。

探索性测试的优缺点

• 缺点

1、覆盖范围不全面
2、依赖测试人员的技能：测试执行都取决于测试人员的技能和能力；需要测试人员具备良好的领域知识和更好的指令，才能深入研究产品并找出错误和缺陷；
3、没有测试用例，可能会难以追溯：缺乏文档，经常要追溯缺陷是一项艰巨的任务
4、无法保证最重要的程序错误一定被发现；

• 优点

1、节省时间：不需要大量且完善的测试计划
2、针对短期项目或者是修改较多的项目非常有效
3、可以和敏捷软件开发并驾齐驱：适合敏捷团队、初创企业
4、可以发现包含在使用其他技术进行测试时仍未被发现的错误
5、不依赖需求文档：可以快速接手新需求

探索性测试的价值

• 探索性测试可以加深测试人员对被测系统的了解

探索性测试强调对被测试对象的学习，并且是在测试过程中的学习，并在此基础上设计测试，因此，它使测试人员更容易深入的理解被测系统。

• 探索性测试可以用来找到深层次的BUG

因为探索性测试人员是优秀的观察者，他们观察不正常和不期望的结果，并进行认真的思考，这种状态和按部就班的执行用例是不一样的，因此，它更容易发现一些隐藏的很深的问题。

4、开发排查的优化流程

• 1.先能稳定的复现错误。

• 2.设桩，打印出一些中间状态来分析，看到那一块儿错了。

• 3.摘除不相干的代码，慢慢迭代，定位错误。

• 4.如果发现调用第三方依赖跟你想的不一样，先读文档，然后再测试第三方依赖。

• 5.单元测试覆盖度

学习资源有点久了，忘记出处。后续找找补上