| 编辑推荐: |
本文章主要向大家介绍了探索性测试的定义、探索性测试的设计理念、探索性测试的典型技术以及敏捷测试与探索性测试。
本文来自于博客折翼の翅膀，由火龙果软件Anna编辑、推荐。 |
|
1 测试决策5要素
测试目标：所有的重要任务都完成了，而剩下没做的事情是比较次要的，我们做到这一点就可以尽早尽可能地降低发布风险。
测试方法：测试是一个不断抉择的过程，测试人员必须理解运行测试用例时和分析现有信息所涉及的各种复杂性。
测试决策5要素：用户输入、状态、代码路径、用户数据、执行环境。
输入：环境产生的刺激，该刺激导致被测试的应用有所响应。主要分原子输入(输入一个数字、按钮)和抽象输入（1-25535之间的任何一个原子输入长度值，类似于等价类划分）两类。
考虑各种输入之间会相互影响：单独输入、混合输入。
输入值的顺序：组合输入。
核心功能：接收输入、产生输出、存储数据、进行运算。[正向测试、逆向测试]
错误处理程序[error handler]：输入筛选器、输入检查、异常处理代码。
常规输入[字母和数字]、非常规输入[比如输入ctrl+c、shift+c、esc、ctrl键、alt、操作系统的保留字、不同的字符集，本地化的问题]
默认输入[空格、空白、默认值]
使用输出来指导输入。
- 状态：状态控件中的一个点，由所有内部数据结构的取值进行决定。
代码路径：一连串的代码语句[基于白盒]。
用户数据：测试数据尽量与上线环境的数据保持一致。
执行环境：操作系统、当前配置、其他应用程序、网络拓扑、驱动程序、文件系统、网络带宽、性能。
2 缺陷检测
- 1.自动化测试：通过编写代码来测试一个应用。（擅长找到的问题：程序崩溃、系统死机、程序挂起、突发异常、原有能用的功能出现问题）
- 2.手工测试：使用程序的用户界面，手工输入数据进行测试。（缺点:速度慢、没有规律、不可反复使用、发现问题也不能重视、人员水平决定测试质量、使用喜欢的测试用例又缺乏变通）。测试用例的编写不要太使用细节的描述，尽量描述一些用户使用场景，同时结合自动化测试工具进行使用。
1.需要测试人员编写代码。
2.花费太多的时间来开发测试代码，而减少了测试项目的时间。
3.自动化测试可以重复运行。
3 探索性测试
探索性软件测试模型图：
3.1 探索性测试的定义
探索性测试：测试学习、测试设计、测试执行、测试结果评估等活动同时进行的软件测试技术。
1.测试学习：学习任何可以指导测试的知识，可能要学习的内容包括行业背景、领域知识、技术平台、测试技术、产品缺陷、项目风险等。
2.测试设计：安排测试计划，拟定测试策略，开发测试想法，制定测试支持材料。
3.测试执行 ：执行测试并收集结果。
4.测试结果分析：分析并解读从测试中学到的知识，可能的活动包括判定测试是否通过、理解产品实现、发掘风险区域、评估测试方法是否有效等。
简单说就是事先不进行计划和设计的一种特殊类型的测试，由有经验的测试人员根据实际情况，凭借自身的测试经验和对系统的认识来进行测试。即完全抛开测试用例，使用定义的比较笼统的测试用例。
探索性测试是一种新的测试思维方式，强调系统软件学习、测试设计、测试执行的同时进行。本质上是敏捷，可以很好地应用于敏捷项目。
探索性测试目标：
1.理解应用程序如何工作，接口看起来怎样，实现哪些功能，提供必须信息，给测试人员提供测试切入点。
2.展示其全部能力：验证软件可以达到设计和发布要求。
3.找到缺陷：探索各种软件的极端情况来发现潜在的问题，发现未测过的功能或者包含缺点多的功能。
探索性测试特点：
1.在测试过程中不断学习被测系统，在根据学习的内容来指导测试，是一循环过程。
2.软件系统学习、测试设计、测试执行同时进行。
3.探索式测试适用于"敏捷开发过程"。
4.测试人员有可能没有测试重点。
强调测试者的主观能动性，以及测试设计和测试执行的同时性。
3.2 探索性测试方法
探索性测试包含4种方法：自由式探索、基于场景的探索性能测试、基于策略的探索性测试、基于反馈的探索性测试。
3.2.1 探索性测试方法
包含2种方法：局部探索性测试法和全局探索性测试方法。
- 局部探索性测试法：测试人员不需要知道很多信息就可以完成测试任务，重点：测试经验、专业知识、软件在操作环境下如何构建和运行的知识结合在一起，使我们在测试过程中做出正确的决定。
1.使用测试集用来确定软件是否已经满足正式发布所需达到的质量标准?/p>
2.测试集中的测试用例都是相互有联系的整体。
3.确定了如何对软件进行探索式测试的整体方向。
探索性测试主要用的方法：
指南测试法：通过阅读用户手册并严格遵守手册的建议执行操作。尽量执行手册中提交的场景，验证软件实现的软件特性，也验证了用户手册的准确性。[比如博客测试法、专家测试法、竞争对手测试法]
卖点测试法：用户希望使用的功能。
地标测试法：使用指南测试法和卖点测试法，找到相关的地标。
权限测试法：向软件提出很多难以回答的问题。
快递测试法：测试人员专注与数据，确定哪些存储起来的数据，跟随他们走遍软件。
深夜测试法：非卖点的功能在夜间或系统非繁忙的时刻执行。
遍历测试法：选定一个目标，然后使用发现的最短路径访问目标包含的所有对象。
历史区测试类型：恶邻测试法[80%的测试放在20%的模块]、博物馆测试法、上一版本测试法。
娱乐区测试法：配角测试法、深巷测试法、通宵测试法。
旅游区测试类型：收藏家测试法、长路径测试法、超模测试法。
混合探索式测试技术：讲述用户故事、描述需求、演示产品功能、演示集成场景、描述设置和安装、描述警告和出错场景。
单个特性测试方法：
交互特性测试方法：
系统测试方法：
3.2.2 探索式软件测试的测试方法
1.头脑风暴法
2 车轮图测试法
车轮图测试法：结合ISO 225000的6个要素，及功能性、可靠性、易用性、效率、可维护性和可移植性进行的测试方法。
3 wiki法
wiki指的是一种超文本系统，支持面向社群的协作式写作，同时也包括一组支持这种协作。在公司可以建立内部的以测试设计技巧为内容的wiki网站，把自己的软件测试经验书写在这里，方便其他同事的使用和学习。
4 阅读bug报告和测试日志
定期到缺陷管理工具中阅读别人发现的缺陷以及阅读别人书写的测试日志，是提高自己 测试能力的一个有效手段。由于探索式测试本身就是一种基于经验的测试，每个人都有自己
的测试经验，因而通过阅读别人的缺陷和日志可以提高自己的测试设计的水平，也可以更好地了解测试的软件产品质量情况。
5．利用思维导图工具
在进行软件探索式测试的时候，我们也可以借助于思维导图工具。
3.3 探索性测试的核心优势
核心优势：有助于学习，是指学（获取知识 ）与习（应用知识）的持续过程。
软件测试是一个持续学习并实践的过程，学习范围主要包括行业知识、用户角色、软件产品、计算平台、开发技能、测试技术、程序缺陷、开发团队。
- 行业知识：为什么需要这个软件？软件如何帮助使用它的人和团体去获得成功？
- 用户角色：目标用户是谁，有什么特点，有什么期望，如何帮助他们去获得个人成就？
- 软件产品：产品是一种解决方案，解决了行业和用户所面临的问题吗？
- 计算平台：只有深刻理解理解软件所依赖的计算平台（如操作系统、中间件、网络协议），才能更好的进行测试。
- 开发技能：理解项目所使用的具体计算，知晓典型的技术缺陷，具备测试开发的能力
- 程序缺陷：研究已知的软件缺陷，提炼错误模式，制定缓解或预防方案。
3.4 如何评估探索性测试的测试效果
评估探索性测试结果的前提：测试记录。测试记录主要包括：测试目标、测试范围、测试策略、缺陷列表、疑问、复用的测试资源、耗时、时间分配。
- 测试范围：本次测试覆盖了哪些功能、模块、用户情景？
- 可以复用的测试资源：被测试软件配置、测试数据、测试脚本等。
- 测程的时间分配：在测试设计与执行、缺陷调查与报告、测程的启动与结束和非测试活动上各花费了多少时间。
测程：在一个固定的时间窗口内（60~120分钟），根据预设的测试目标，对软件Z探索性测试。类似于科学实验，主要分三个阶段：测试计划、测试执行、测试分析。
- 2.测试执行：设计并执行测试用例，记录测试所发现的一切。
- 3.测试分析：分析并总结测试所发现的信息，为下一次测试提供目标。
4 传统的测试和精益与探索式测试区别
4.1 传统的测试与探索式测试的区别
1.两者互补，不是对立关系。
2.传统的测试通过收集来的各种信息和文档，编写出正式的测试用例，测试人员根据测试用例来执行。探索性测试是一种新的测试思维，强调的是测试过程中要有更多的发散思维。
3.在执行正式的测试用例的同时，可以使用探索性测试来让测试用例更加的丰富和富有变化，提高测试代码的覆盖率，找到更多的bug。
在探索式软件测试中基于测程的管理方法是基本的管理方法：
第一个测程：测试开始是测试分析、设计、执行一起进行，测试过程中随时进行记录。比如测试过哪些模块，使用了哪些方法，遇到了哪些问题。一个测程一般在
0.5～ 3 小时。
一个测程测试完毕后测试工程 师与测试经理及其他测试工程师一起讨论测试记录总结如下内容：
1.需要进一步学习哪些专业知识、业务知识和其他知识。
2.系统中这次发现的哪些问题是有效的缺陷，讨论后填写到缺陷管理软件中去。
3.下一次需要重点测试哪些模块，使用哪些方法和技巧。
然后进入下一轮测程。
4.2 探索式测试与精益
软件测试的目的有4个方方面：发现缺陷、增加信心、为领导者做出决策以及预防缺陷。
精益的思想：在探索式初期采用地毯式浅层测试的策略。初期测试阶段是为了探索哪些模块存在缺陷以及缺陷的严重程度，所以我
们必须采取“地毯式”的方法，把所有模块都均匀地摸一遍。采用“浅层”测试由于现在是 侦察兵介入，熟悉一下缺陷在软件中的分布情况，大规模的测试还没有开始，所以这个时候
采用“深入”的测试是没有必要也是不科学的。通过第一次探索式测试，我们对缺陷在软件中的分布情况有了八九不离十的了解，可以计划在下几次测程计划中采用不同的测试策略和测试方法进行测试。同样在每次测程结束，对测试过程的结果进行不断的总结与反馈，指定下一次测程的计划，这种方法其实就是精益思维方式。
精益中一些工具在探索式软件测试中的使用，比如：OODA 环，OODA包括探索、判断、决策、行动
4 个活动构成的环。在探索式测试中“观察”可以理解为观察前一个测程中的测试结果，然后通过“判断”来对测试结果进行分析，结合公司文化、以前的测试遗产、新发现的问题和以前的经验来判断下一个测程的测试“决策”，从而进入下一轮探索式测试行动。
精益企业产品从产生到衰败的过程也正体现了探索式软件测试中发现缺陷的分布情况，在探索测试初期随着测试的深入发现的缺陷越来越多，而到了后期发现的缺陷逐步呈现出衰退的趋势。"创新者"与"早期采纳者"阶段正是那些很容易被发现的缺陷，探索测试在这个时期正处于深入探索的阶
段，通过这个阶段的探索，我们可以更加深入地了解产品质量情况、缺陷分布、缺陷类型等 信息。"早期大多数"是指基本上了解了产品本身的一些特征，在这个阶段大量的缺陷被发现出来。"晚期大多数"为一些隐藏得比较深的缺陷被逐步地发现。"滞后者"是指一些深层次的、不容易被发现的，甚至没有被测试出来的缺陷。
探索式测试也可以分为增长期、成长期、成熟期、衰退期、灭亡期。探索式测试的成熟度周期与发现缺陷的生命周期是一致的。
在探索式软件测试前期，由于对产品不是很了解，我们主要的精力在于理解探索产品中缺陷的分布以及缺陷的类型，这个时候的投资回报率是负的，随着对产品质量的逐步了解，探索式测试的投资回报率突破零点，并且达到正回报率，从而取得效益。
5 如何实施探索性测试
探索性测试鼓励测试人员依据当前语境选择合适的测试流程与技术。SMART原则提供了指导：
Specifi(具体的):测试需要一个具体的目标。
Measurable（可度量的）：有明确的指标可以评估目标是否达成。
Attainable(可实现的)：目标应该是可实现的，要求将一个大目标分解成多个小目标，且每个小目标也是具体的、可度量的、可实现的。而且，追踪小目标的完成情况提供了整体进度的可度量性。
Relevant（相关的）：符合团队利益。
Time-boxed(有时间限制的)：为每个目标设定一个合理的最后期限。
测试人员可按SMART原则展开探索性测试：
1.测试人员制定测试计划。分析被测试应用，确立若干个具体的测试使命（Mission）,每个使命针对一个可能的产品风险。
2.测试人员将测试使命分解成一系列测试任务，每个任务都有明确的退出条件和时间限制。
3.在短暂的测试计划之后，根据优先级选择一个任务，在一个固定的时间窗口中执行探索性测试。（测程：一般窗口长度为60-120分钟，一般90分钟）
4.测试结束后，休息，放松思维
5.反思当前测试进展，并优化测试计划，追加一个测程，开始新一轮探索性测试。
根据国外的一些实践理念，采用session来进行测试范围的确定：主要需要了解几个关键词：session、charters、UC。
charter:探索性测试过程中使用到的一个非常清晰的任务列表，指出了要测试什么、怎么测试（测试策略）、要寻找什么样的bug，有哪些bug，要去检查什么文档等。
sessions:一个基本的测试工作单元，一般对应1-2个UC。探索性测试者所有进行的探索性测试都是基于Session的。
1.大概花1-2小时时间看PRD和原型（了解目的和产品背景）
2.大概花1-2H时间确定下有哪些主要的功能模块和贡献性的功能模块
3.与项目组测试人员沟通哪个功能模块发现bug最多，哪个最小，哪块存在的风险比较大。
4.确定Session的个数，并指出每个session大概花多长时间，一般是1.5-2H。
5.制定探索性测试计划，包含所有session的名称和测试时间以及缓冲情况。
6.根据探索性测试计划，边学习产品需求，边测试，发现问题立马记录问题描述，最后发送测试报告。
7.与项目组测试人员沟通探索性测试的效果以及该产品存在的风险，从用户易用性角度给该产品总体评价，同时跟踪确认bug的fix情况。
6 基本测试用例[编辑、输入框、翻页]
Base64编码：基于64个可打印字符来表示二进制数据的方法，常用于处理文本数据的场合，表示、传输、存储一些二进制数据。在Base64中的字符包括：A-Z,a-z,0-9,+,/
6.1 编辑有效、无效的功能
6.2 输入框有效、无效查询
6.3 翻页功能
|
