浅谈探索性测试
探索性测试的实施与理解
探索性测试的方法探讨陕西西安XXXX学院XXXX摘要传统的面向故障的软件测试方法存在限制条件高精确程度与低误报率无法兼得的瓶颈效果。
而高误报率直接导致软件测试成本的增加和效率的低下。
本文通过对探索性测试方法的研究中得出该方法的使用场合与特点，从而希望能在有限的软件测试成本内找出与脚本测试相结合的最佳方法，利用探索性测试，能显著提高软件测试的效率。
关键词软件测试探索性测试测试方法缺陷效率引言随着软件测试技术的不断发展，各种新颖的测试技术越来越受到软件测试人员的关注。
探索性软件测试是其中一种比较前沿的理论，尤其适用于那些要求在短时间内发现被测软件一些重要缺陷或事先没有能够进行详细测试设计的情况。
探索性软件测试强大的缺陷发现效率是其得到众多青睐的重要原因之一。
如何选择合适的测试方法?我们针对三种测试方法(脚本测试，探索性测试和自动化测试)区别以及他们之间的合作关系展开一定的讨论。
1调研目的1．1软件测试现状和问题软件测试是软件开发生命周期中不可或缺的用来保证软件质量、提高软件可靠性的重要阶段。
基于传统理论的软件测试，理论上都要求尽可能早地引入软件测试过程。
而在实际的测试过程中，我们所遇到的问题很多：首当其冲的就是长期处于瀑布模型下的软件工程，将测试工作安排并推迟到了开发周期结束阶段进行，导致大量的测试工作，包括功能测试、集成测试以及性能测试都堆积到了末期进行。
其次，没有有效地利用自动化测试这一先进技术也是目前软件质量备受质疑的关键因素。
虽然很多公司都非常推崇软件测试自动化这一理念。
可真正用到实处能够事半功倍的毕竟不是很多。
第三，需求变更得频繁性也是一个让项目经理头大的问题。
客户一改再改的情况，绝对不是少数。
再加上项目进度、客户压力等其他其他因素，测试工作的时间和内容被一压再压地缩减。
这样恶性循环，谁也不敢保证软件质量。
如何在减少重复性的测试工作的同时，发现尽可能多的软件缺陷，并利用有效的自动化测试降低成本，同时还能够及时高效的覆盖到这些变更的需求。
软件测试中的随机化技术与探索性测试
软件测试中的随机化技术与探索性测试随着软件应用的不断增加和复杂性的提高，软件测试在保证软件质量方面变得越发重要。
传统的测试方法往往只能涵盖一部分场景，而无法覆盖全部可能出现的异常情况，因此，为了提高测试的全面性和有效性，软件测试中的随机化技术与探索性测试应运而生。
随机化技术是指在测试过程中使用随机的数据或者随机的测试序列来模拟实际使用的环境，以发现潜在的软件缺陷。
随机化技术可以被广泛应用在软件测试的各个阶段，包括单元测试、集成测试和系统测试等。
它通过引入随机性，能够生成更多样化的测试用例，从而提高了测试的覆盖率。
随机化技术的一个重要应用是生成随机测试数据。
传统的测试用例设计方法通常是基于经验和规则来选择测试数据，而随机化技术可以在一定范围内随机生成测试数据，以覆盖更多的边界和异常情况。
通过引入随机性，随机测试数据能够更好地模拟实际使用中的各种情况，从而增加软件测试的全面性。
随机化技术还可以应用于模糊测试。
模糊测试是一种基于随机化的黑盒测试方法，通过输入模糊的、随机的测试数据来检测软件的漏洞和异常行为。
模糊测试通过向软件输入各种无效、异常或随机的数据，包括错误的输入类型、长度变化、边界测试等，以发现潜在的缺陷。
通过随机化生成测试用例，模糊测试可以挖掘出许多传统的测试方法无法涵盖到的异常情况，从而提高测试的可靠性。
除了随机化技术，探索性测试也是一种非常重要的测试方法。
探索性测试是一种灵活的测试方法，通过对软件的不同方面进行探索和试错，以发现潜在的问题。
探索性测试通常由经验丰富的测试人员来执行，他们在测试过程中通过灵活的思维和创造性的方式来设计测试用例和执行测试。
相比于传统的测试方法，探索性测试更加注重测试人员的直觉和发现能力，能够发现一些隐藏的问题或缺陷。
探索性测试在软件测试中发挥着重要作用。
它能够帮助测试人员从不同的角度来审视软件，从而发现更多的潜在问题。
在探索性测试中，测试人员可以根据自己的经验和理解来挖掘软件的潜在缺陷，从而提供更完善和可靠的软件产品。
探索性测试在功能测试中的应用
探索性测试在功能测试中的应用功能测试是软件开发过程中不可或缺的一环，旨在验证软件是否满足规格说明书中规定的各项功能要求。
然而，在传统的功能测试中，由于测试人员主要关注于已知的功能点，往往容易忽略一些潜在的问题。
而探索性测试（Exploratory Testing）则是一种适用于功能测试的补充方法，可以帮助发现更多的潜在问题以提升软件的质量。
一、什么是探索性测试探索性测试是一种以自由和灵活的方式进行的测试活动，测试人员在测试过程中不仅关注已知的功能点，还通过探索和试错的方式发现新的测试点。
这种测试方法注重测试人员的直觉和经验，通过不断的实践来逐渐发现潜在的问题。
探索性测试的目标不仅限于找出缺陷，更重要的是以用户的视角去评估软件的可用性、易用性和性能等方面。
二、探索性测试的优势1. 发现潜在问题：通过探索性测试，测试人员可以从不同的角度和场景出发，去发现一些传统功能测试中容易被遗漏的潜在问题。
2. 适应变化：探索性测试可以应对需求变更的情况，当需求发生变化时，测试人员可以根据新的需求进行进一步的探索和测试，确保软件的适应性和可靠性。
3. 优化测试计划：通过探索性测试，测试人员可以根据实际情况根据重要性和风险程度对测试进行调整，优化测试计划和资源分配，提高测试效率。
4. 提高测试人员的技能：探索性测试依赖于测试人员的直觉和经验，通过实践不断提升测试人员的技能水平，使其成为专业的测试从业者。
三、探索性测试的实施步骤1. 确定测试目标：在进行探索性测试之前，首先需要明确测试的目标，这可以是要测试的功能点、用户故事或者重要的业务场景。
2. 制定测试策略：在进行探索性测试时，测试人员需要制定相应的测试策略和测试方案，包括测试的范围、测试的方法和技巧等。
3. 执行测试：测试人员按照测试策略进行测试，通过尝试不同的输入、操作和数据，发现可能存在的问题并记录下来。
4. 总结和评估：测试人员对测试过程进行总结和评估，分析测试的结果和发现的问题，并形成测试报告和改进建议。
探索性原因分析探索性测试
探索性原因分析:探索性测试疯狂代码 / ĵ:http://SoftwareTesting/Article35232.html探索性测试可以说是种测试思维技术它没有很多实际测试思路方法、技术和工具但是却是所有测试人员都应该掌握种测试思维方式探索性强调测试人员主观能动性抛弃繁杂测试计划和测试用例设计过程强调在碰到问题时及时改变测试策略对探索性测试最直白定义是:同时设计测试和执行测试探索性测试有时候会和即兴测试(ad hoc testing)混淆即兴测试通常是指临时准备、即席Bug搜索测试过程从定义可以看出谁都可以做即兴测试由Cem Kaner提出探索性测试相比即兴测试是种精致、有思想过程在对测试对象进行测试同时学习测试对象并设计测试在测试过程中运用获得有关测试对象信息设计新更好测试这个有趣过程如下图所示er" height="317" src="/WebFiles/20092/246c32f2-fffe-4fb2-b094-c34add7378dd.jpg" width="637" alt="" />探索性测试探索性测试强调测试设计和测试执行同时性这是相对于传统软件Software测试过程中严格“先设计后执行”来说测试人员通过测试来不断学习被测系统同时把学习到有关软件Software系统更多信息通过综合整理和分析创造出更多有关测试主意1．探索性测试基本过程探索性测试基本过程包括如下:识别软件Software系统目；识别软件Software系统提供功能；识别软件Software系统潜在不稳定区域；在探索软件Software系统过程中记录有关软件Software信息和问题；创建个测试纲要使用它来执行测试注意:上面过程是个循环过程并且没有很严格执行顺序完全可以先创建测试纲要执行测试然后在测试中学习软件Software系统；也可以先探索软件Software系统各个区域然后再列出需要测试要点探索性测试强调创新测试思维在测试过程中不断地出现许多有关测试新想法因此就像把叉下图就是个所谓“探索叉”(exploratory forks)探索性测试强调测试过程中要有更多发散思维这也是和传统测试方式最大区别传统测试方式强调设计完善测试用例测试人员严格按测试用例执行测试这多少限制了测试人员测试思维测试人员往往缺乏主观能动性er" height="373" src="/WebFiles/20092/0a17c2f2-bbee-4aad-8764-253a44f3a5e3.jpg" width="317" alt="" />探索叉下图展示了个发散思维过程探索性测试强调发散但并不是盲目地发散在适当时候还要收敛回来例如当发现在个测试分支路径上已经花了很长时间也没有找到问题答案时则可以考虑先放弃那个区域探索还有个主线测试任务er" height="161" src="/WebFiles/20092/43cee943-fbc5-4f2b-a400-81398dd38724.jpg" width="418" alt="" />发散思维探索性测试尤其适合于那些需求不是很明确测试任务或者是名刚刚接手项新测试任务测试人员使用2．探索性测试管理探索性测试是种不是很严谨测试思路方法缺乏可管理性和度量性因此James Bach提出了基于任务测试管理(Session-Based Test Management)Session-Based测试管理是用于度量和管理探索性测试种思路方法测试人员在采用探索性测试思路方法测试过程中应该及时记录下所谓“测试故事”把所有测试中学习到有关软件Software系统知识要点、问题和疑问、测试主意、进行了怎样测试等相关信息记录下来然后周期性地和测试组长或其他测试人员基于记录“测试故事”展开简短讨论测试组长基于这些记录结果来判断测试充分性测试人员通过讨论可以共享学习到软件Software系统相关信息交流测试主意整理总结测试经验激发测试人员拿出更多测试主意从而指导下次测试任务执行在这种方式测试管理中测试组长就像名教练但是需要参和到测试实际任务中指导测试人员测试方向和重点提供更多有关软件Software系统相关信息给测试人员授予测试人员更多测试技术介绍说明:未必需要完全采用探索性测试思路方法但是可把探索性测试方式作为传统测试方式补充在每项测试后留下定时间给测试人员做探索性测试以弥补相对刻板传统测试方式不足应该更多地采用探索性测试思维方式应用在日常测试工作中2009-2-12 5:08:04疯狂代码 /。
什么是探索性测试？
注意：上面的过程是一个循环的过程，并且没有很严格的执行顺序，完全能够先创建测试纲要，执行测试，然后在测试中进修软件系统;也能够先探索软件系统的各个区域，然后再列出需要测试的要点。
探索性测试强调创新的测试思维，在测试过程中不断地出现许多关于测试的新想法，因而就像一把叉，下图就是一个所谓的“探索叉”(exploratory forks)。
探索性测试强调测试过程中要有更多的发散思维，这也是与保守测试方式的最大区别。
保守测试方式强调设想完善的测试用例，测试人员严格按测试用例执行测试，这多少限制了测试人员的测试思维，测试人员往往缺乏主观能动性。
下图展示了一个发散思维的过程，探索性测试强调发散，但并不是盲目地发散，在适当的时候还要收敛回来。
例如，当发觉在一个测试的分支路径上已经花了很长时间也没有找到问题的答案时，则能够考虑先放弃那个区域的探索，因为还有一个主线的测试任务。
探索性测试尤其适合于那些需求不是很明确的测试任务，或者是一名刚刚接手一项新的测试任务的测试人员使用。
3、探索性测试的价值3.1、探索性测试可以用来找到深层次的BUG。
因为探索性测试人员是优秀的观察者，他们观察不正常和不期望的结果，并进行认真的思考，这种状态和按部就班的执行用例是不一样的，因此，它更容易发现一些隐藏的很深的问题。
3.2、探索性测试可以加深测试人员对被测系统的了解。
探索性测试强调对被测试对象的学习，并且是在测试过程中的学习，并在此基础上设计测试，因此，它使测试人员更容易深入的理解被测系统。
4、探索性测试的误区4.1、不要将探索性测试和随机测试混淆。
探索性测试不是在键盘钱坐下并敲击，没有熟练技能，不会认真思考的“黑盒”测试人员所做的并不是探索性测试，一个合格的探索性测试人员需要认真思考和分析结果，并且在探索测试的过程中做记录。
4.2、不要将探索性测试和回归测试混淆。
探索性测试更注重的是思考和学习，不断发现新的问题，而版本的回归测试，是对原有的功能的保证，为持续迭代构筑安全网。
浅谈探索性测试
浅谈探索性测试软件开发面临着快速交付的压力，一些企业开始尝试实践敏捷开发方法，有些测试人员开始接触探索性测试，以适应于敏捷开发过程。
什么是探索性测试？它能够给测试工作带来哪些好处？通常在开始实践探索性测试又易于陷入哪种误区？本文将带你一起探讨这些问题。
探索性测试不是具体的某种测试技术或测试方法，而是一种测试风格或测试思维，它貌似即兴的漫游测试，但是又有着本质的不同。
探索性测试是有目的的漫游测试，即带着使命在某个空间中漫游，但没有预先确定的路线，探索包括对产品与技术的深入研究和基于成果的应用实践。
换句话讲，在探索性测试思维中，没有把测试用例的设计和执行完全分离开，而是强调了两者在一定程度上的并行，二者相辅相成，测试用例设计指导测试执行，同时基于对测试执行结果的分析同时要改进和补充测试用例的设计。
先来看一下探索性测试产生的由来，即测试工作中的哪些问题导致了人们最终提供并实践了探索性测试。
很多企业软件测试工作都面临类似这样的问题：测试人员严格地按照测试过程，进行测试用例设计、测试用例的评审，测试执行时又百分百地全覆盖，可是产品到了用户那里依然问题不少。
要寻找“罪魁祸首”，好像大家都很无辜，测试用例设计人员说了，我可是按照测试策略和计划要求对各测试项进行了设计，并且还经过了专家的有效评审；测试执行人员更是理直气壮，所有测试用例都执行了，而且有完整的测试记录和测试报告。
问题到底出在哪里呢？传统的测试思维其实是建立在一种假设上，即在测试执行前是可以设计出全面的、无误测试用例，自然按照这样的用例执行完测试是可以放心地把产品交给客户。
然而，这样的假设真的成立吗？非也。
正是大量的测试实践告诉我们，在没有执行测试前，通常这时也没有看到实际的产品是什么样子，仅仅根据软件需求规格说明书很难设计出全面、有效的用例，如果测试执行过程中，不对测试用例进行动态的调整，仅仅以跑完之前所设计的用例作为测试执行的目标，产品的质量根本无法保证。
什么是探索性测试
一、概念对探索性测试的最直白的定义是：同时设计测试和执行测试，一边测试一边探索。
这与剧本化的测试方法相反（预先定义好测试步骤）。
探索性测试不像剧本化的测试，不会预先定义，不会严格按照计划开展。
探索性测试有时候会与即兴测试(ad hoc testing)混淆。
即兴测试通常是指临时准备的、即席的bug搜索的测试过程。
从定义可以看出，谁都可以做即兴测试。
由Cem Kaner提出的探索性测试，相比即兴测试是一种精致的、有思想的过程。
二、与ST测试的区别及优点不同于探索性测试（ET），基于测试用例的测试方法（ST）存在以下几个缺点：●测试文档（计划和设计和用例）必须非常详细和明确●测试设计和测试用例对于开发的文档的依赖非常大●测试执行的时候对于测试用例的依赖非常大●测试执行的时候对于需求变更的应对力较差下面我们对于ET和ST进行了一些简单的比较：ET作为一个比较现代的测试方法，肯定有其非常重要的优势：1.它可以鼓励测试人员的创造性2.它增加了发现新的或者难以发现的bug。
3.它允许我们有更多的时间去测试感兴趣的和比较复杂的用例4.它可以更有效率的驱使测试人员在一个很短的时间内找到更多的bug和对AUT做一个快速的评估5.它显示了一个产品是如何被使用的6.它具有非常好的适应性，灵活性，多样性7.它比ST更有乐趣8.它可以促使测试人员快速的学习一个产品9.它可以check其他测试人员的测试工作10.它可以很好的应用在敏捷测试项目11.它允许我们不用花很多时间在编写那些简单和繁琐的测试用例三、ET测试在项目中常见的应用模式1、根据探索性测试在总测试中占有的比例不同，分为三种模式：1）Freestyle ET，也就是自由式的ET即纯ET测试，没有任何测试文档；不需要记录任何东西（bug除外）；测试执行之前不需要任何准备。
2）Pure Scripted，也就是基于传统瀑布式开发的纯ST测试，所有的测试执行都是基于详细的测试用例和步骤来做的。
探索性测试（ExploratoryTesting）概述
探索性测试（ExploratoryTesting）概述在敏捷测试（Agile testing）中，探索性测试是作为⼀个重要组成部分⽽出现的，把“对系统的探索”和“对系统进⾏测试”结合在⼀起，敏捷测试可以利⽤探索性测试达成“敏捷”的⽬标。
探索性测试并不是⼀个最近才被提出来的测试技术，也不是⼀种很深奥的技术——事实上，许多测试⼯程师在⾃觉或不⾃觉地使⽤这种技术。
那么，究竟什么是探索性测试呢？对探索性测试的理解本⾝会存在⼀些争议，因此，很难给出探索性测试的准确定义，不过，⼀般来说，探索性测试具有这样的⼀些特点：1、探索性测试强调测试设计和测试执⾏的“同时”性——这个“同时”是相对于传统软件测试过程中严格的“先设计，后执⾏”来说的；2、测试⼯程师通过测试来不断学习被测系统；3、探索性测试的重点是创造；探索性测试的出发点是“测试者如果没有真正使⽤过系统，就不可能真正理解和掌握系统，也就不可能真正有效地测试该系统”，相信所有有过测试实践的测试⼯程师都会承认这⼀点，确实，在我们没有接触到⼀个真正的系统之前，很难完全认识到这个系统，虽然可以在测试计划阶段按照需求或是设计的要求写出测试⽅案和⽤例，但总觉得这些⽤例不可能具有太强的可操作性。
事实上，探索性测试给出的另⼀个测试的思路：“如果我们可以在对系统的测试中逐渐深⼊地学习系统，测试是否会更加有效率？”在我看来，这个问题的答案是显然的，如果测试⼯程师能够在测试中对系统越来越深⼊地了解，那么，利⽤这些逐渐增加的了解，⾃然可以让测试变得更加有效率。
探索性测试只是⼀种⽅法和思路，并不是⼀个确定的过程。
因此，在使⽤探索性测试时，⽆法回避的是When的问题，也就是说，在什么时候进⾏探索性测试更加有效呢？我的答案是“在你认为合适的时候”：）因为，探索性测试可以针对不同的测试层⾯，例如，针对业务场景的探索性测试、针对功能点的探索性测试，甚⾄是头脑风暴式的探索性测试，都能够在测试中发挥积极主动的作⽤。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
浅谈探索性测试
软件开发面临着快速交付的压力，一些企业开始尝试实践敏捷开发方法，有些测试人员开始接触探索性测试，以适应于敏捷开发过程。
什么是探索性测试？它能够给测试工作带来哪些好处？通常在开始实践探索性测试又易于陷入哪种误区？本文将带你一起探讨这些问题。
探索性测试不是具体的某种测试技术或测试方法，而是一种测试风格或测试思维，它貌似即兴的漫游测试，但是又有着本质的不同。
探索性测试是有目的的漫游测试，即带着使命在某个空间中漫游，但没有预先确定的路线，探索包括对产品与技术的深入研究和基于成果的应用实践。
换句话讲，在探索性测试思维中，没有把测试用例的设计和执行完全分离开，而是强调了两者在一定程度上的并行，二者相辅相成，测试用例设计指导测试执行，同时基于对测试执行结果的分析同时要改进和补充测试用例的设计。
先来看一下探索性测试产生的由来，即测试工作中的哪些问题导致了人们最终提供并实践了探索性测试。
很多企业软件测试工作都面临类似这样的问题：测试人员严格地按照测试过程，进行测试用例设计、测试用例的评审，测试执行时又百分百地全覆盖，可是产品到了用户那里依然问题不少。
要寻找“罪魁祸首”，好像大家都很无辜，测试用例设计人员说了，我可是按照测试策略和计划要求对各测试项进行了设计，并且还经过了专家的有效评审；测试执行人员更是理直气壮，所有测试用例都执行了，而且有完整的测试记录和测试报告。
问题到底出在哪里呢？传统的测试思维其实是建立在一种假设上，即在测试执行前是可以设计出全面的、无误测试用例，自然按照这样的用例执行完测试是可以放心地把产品交给客户。
然而，这样的假设真的成立吗？非也。
正是大量的测试实践告诉我们，在没有执行测试前，通常这时也没有看到实际的产品是什么样子，仅仅根据软件需求规格说明书很难设计出全面、有效的用例，如果测试执行过程中，不对测试用例进行动态的调整，仅仅以跑完之前所设计的用例作为测试执行的目标，产品的质量根本无法保证。
因此，有人提出了探索性测试的思维，这种思维是建立在另一种假设之上，即我们无法在一开始就设计出完美的测试用例，在测试执行过程中，随着测试人员在测试执行过程中对产品不断深入理解，而不断地调整或重新设计测试用例，从而更加有效地发现产品缺陷，保证产品质量。
不少测试人员在刚开始接触了探索性测试之后兴奋不已，认为终于可以摆脱了测试相关的各种文档编写之苦了。
这种想法正是很多人对探索性测试认识上的普遍误区，探索性测试不是即兴测试（ad hoc testing），更不是给你混乱的测试工作过程起一个好听的名字。
首先，探索性测试同样需要一份经过精心设计的测试策略和测试计划，测试策略告诉我们测试的目标在哪里，哪些是测试的重点，准备应用哪些测试的方法和工具，等等；测试计划为后续工作有效的组织提供输入，也是不可少的。
那么测试用例文档就不必写了吧？非也，测试用例文档一点都不少，只不过写的过程有所不同。
传统的风格下，测试用例一蹴而就，后面改动很小，而采用探索性测试思维，测试用例编写与测试执行交叠在一起。
首先在测试没有执行前，要根据当前对产品的认识设计出部分用例，这时不要尝试设计出所有的用例，因为由于当前对产品认识不够，你所设计的很多用例有可能到执行时没有丝毫用途，浪费了宝贵的时间。
在测试执行过程，要不断地对测试结果进行思考和总结，加深对产品的应用和操作场景的理解，再设计用例以发现之前用例无法发现的问题。
或许你还是在纠结为何要把测试用例写出来，难道不写不可以吗？可以，但是承担不写的代价。
众所周知，同一个测试点要被多次重复测试的，如回归测试会导致重复测试，版本升级后也会导致大量的重复测试，如果测试用例没有文档化，如何保证下次测试时不遗漏？如何保证测试人员变换后仍然执行了
你在头脑中所设计用例？
探索性测试是一种新生的测试思维，在不误用和滥用探索性测试的前提下，在某些情况下它不失为更合适的一种工作风格，它消除了过去“官僚式”的作为，下达命令（设计测试用例），然后执行，而是给测试执行人员更大的权力，当然能力要求也更高，并且把过去枯燥被动的执行测试活动变成了有趣的、充满创意的工作。