《探索式测试》读书笔记

最新推荐文章于 2024-08-30 00:16:28 发布

-Ming中注定-

最新推荐文章于 2024-08-30 00:16:28 发布

阅读量1.3k

点赞数 24

文章标签： python 压力测试开发语言

本文链接：https://blog.csdn.net/weixin_40750196/article/details/135843277

版权

第一章探索式测试的定义

一、探索式测试的概念

探索式测试（Exploratory Testing）是一种自由的软件测试风格，强调测试人员同时展开测试学习、测试设计、测试执行和测试结果评估等活动，
以持续优化测试工作，考虑到它所具备的即兴发挥、快速实验、动态调整等特征，其思维方法可以追溯到软件开发的最初岁月。

作者认为术语“探索式测试”的含义：

其内涵是一种软件测试风格和思考方法，不拘泥于具体的测试技术;其外延是一批在这种思考方法指导下发展出来的测试技术，包括测试设计方法、测试管理方法、测试辅助工具等。
探索式测试强调独立测试人员的自由和责任；
探索式测试建议在整个项目过程中，将测试相关学习、测试设计、测试执行和测试结果分析作为相互支持的活动，并行地执行。
1. 测试学习：学习任何可以指导测试的知识，可能要学习的内容包括行业背景、领域知识、技术平台、测试技术、产品缺陷、项目风险等。
2. 测试设计：安排测试计划，拟定测试策略，开发测试想法，制作测试支持材料；
3. 测试执行：执行测试并收集结果。测试可以手工执行，也可以自动执行。
4. 测试结果分析：分析并解读从测试中学到的知识，可能的活动包括判定测试是否通过、理解产品实现、发掘风险区域、评估测试方法是否有效等。

二、语境驱动测试的7条原则

作为一个技术术语，“探索式测试”是测试专家 Cem Kaner 博士在 1983 年提出的，并受到了语境驱动测试学派(Context Driven Testing School')的支持。

原则一：任何实践的价值都取决于其语境（Context）;
原则二：在特定语境下存在好的实践，但不存在最佳实践；
原则三：人，在一起工作的人，是项目语境中最重要的部分；
原则四：项目的发展往往难以预料；
原则五：产品是一种解决方案，如果问题没有被解决，他就是无用的（Doesn't Work）。
原则六：好的软件测试是一个具有挑战性的智力过程；
原则七：只有通过判断和技能，并在整个项目过程中协同练习（Exercise Cooperatively）它们，我们才能在正确的时间做正确的事，以有效地测试我们的产品。

三、有关探索式测试的常见问题

问题一：探索式测试中的“探索”该如何理解?
- 所谓探索是指有目的的漫游，即带着使命在某个空间中漫游，但没有预先确定的路线，探索包括对产品与技术的深入研究和基于研究成果的实践应用。

问题二：探索式测试是否只适用于功能测试？
- 适用于各种类型的测试

问题三：如何评估探索式测试的测试效果？
- 探索式测试者常常在一个固定的时间窗口内（60-120）分钟根据预设的测试目标，对软件进行探索式测试。这样的测试活动被称为测程(Session)。
  - 测试计划：明确测试。测试是获得信息的过，那么此次测试要获得什么信息？
  - 测试执行：涉及并执行测试用例，记录测试所发现的点点滴滴；
  - 测试分析：分析并总结测试所发现的信息，为下一次测试提供目标。
  - 详细的实验记录是科学实验的基本要求之一。
- 同理，详略适当的测试记录也是测试执行的自然结果，是测试评估的基本要求。通常，测试记录可以包含如下内容。
  - 测试目标：本次测试要提供什么信息?
  - 测试范围：本次测试盖了哪些功能、模块、用户情景?
  - 测试策略：本次测试使用了何种测试方法?
  - 缺陷列表；
  - 在测试过程中发现的疑问，它们值得进一步探索；
  - 可以复用的测试资源，被测试软件配置、测试数据和测试脚本等；
  - 测程的耗时。
  - 测程的时间分配:在测试设计与执行、缺陷调查与报告、测程的启动与结束和非测试活动上各花费了多少时间。

测试记录可以转化为测试备忘录，供今后的测程参考。测试记录也可以提炼为测试报告，反映当前项目的进展。更重要的是，测试记录是测试评审的素材。基于测试记录，测试团队可以开发出符合项目语境的评估方法，对测程进行专家评审和定量度量。这有助于度量探索式测试结果，并提出改进方案。

问题四：如何实施探索式测试？
- 依据当前的语境选择合适的测试流程和技术，遵循SMART原则：Specific、Measurable、Attainable、Relevant、Time-boxed
  - 测试人员制订测试计划。分析被测试应用，确立若个具体的测试使命(Mission)，每个使命针对一个可能的产品风险。
  - 测试人员将测试使命分解为一系列测试任务(Charter)，每个任务都有明确的退出条件和时间限制。
  - 在短暂的测试计划之后，测试人员根据优先级选择一个任务，在一个固定的时间窗口中执行探索式测试（窗口的长度是 60~120 分钟，以90分钟为宜）这样一个时间窗口被称为一个测程(Session）。在该测程中，测试人员设计测试、执行测试、评估测试结果。他会根据获得的知识和发现的疑问再设计测试用例，以拓展测试的广度和深度
  - 在测程结束后，测试人员适当休息，放松思维。
  - 随后，他会反思当前的测试进展，并优化测试计划。也许他会为当前任务追加一个测程；也许他会再增加一个新的任务以弥补先前测试计划的不足；也许他会删除一些任务以反映他对测试对象的最新认知。

这时，他会更有自信地开始新一轮探索式测试。以上只是一种可能的探索式测试实施方法，负责人的测试人员一定会选择他自己的方式展开测试，因为只有作为领域专家的他，才能做出最符合语境的决策。此外整合整个团队的力量，进行同行评审、头脑风暴、结对测试等活动，有助于产生更好的测试结果。

问题五：如果探索式测试是硬币的正面，那么硬币的反面是什么?
- 探索式测试的对立面是脚本测试(Scripted Testing)。脚本测试要求预先编写好测试脚本(Script)，脚本规定了如配置被测试软件、如何输入、如何判断软件输出了正确的结果。编写详细的脚本往往需要大量的测试资源。如果运用得当，脚本测试可能有如下收益：
  - 测试人员可以仔细地思考被测试软件。
  - 测试脚本可以被项目关系人(Stakeholder)评审
  - 测试脚本可以被复用。
  - 测试团队可以度量测试脚本的执行情况，以评估测试进度。

问题六：探索式测试的核心优势是什么？
- 探索式测试的核心优势是有助于“学习”。此处的学习是指学(获取知识)与习(应用知识)的持续过程。对于测试人员，软件测试是一个持续学习并实践的过程。他的学习范围如下:
  - 行业知识：为什么需要这个软件? 软件如何帮助使用它的人和团体去获得成功
  - 用户角色：目标用户是谁?他们有什么特点，有什么期望? 软件如何帮助他们去获得个人成就？
  - 软件产品：产品是一种解决方案，它解决了行业和用户所面临的问题吗?
  - 计算平台：只有深刻理解软件所赖的计算平台《如操作系统、中间件和网络协议等)，才能更好地进行测试。
  - 开发技能：理解项目所使用的具体技术，知晓典型的技术缺陷，具备测试开发的能力。
  - 测试技术：针对当前项目，选择合适的测试技术，并能够熟练地应用。
  - 程序缺陷：研究已知的软件缺陷，提炼错误模式，制订缓解或预防方案。
  - 开发团队：语境决定策略和实践。在一起工作的人，是所有项目语境中最重要的组成部分。
  - 测试人员不需要在项目之初就掌握所有知识，他可以通过每天的工作去逐步理解用户、项目、技术和团队。
  - 更重要的是，他需要在每天的工作中实践所学的内容:规划测试方案、创建并执行测试用例分析测试结果和编写测试报告。实践是练习，是“学”的自然延伸。知行合一才构成“学习”的完整内核。

四、总结

探索式测试不是一种特定的测试技术或者测试方法，它是一种测试风格、思维方式，它遵循的是一定是符合其语境或者符合一定场景下的测试原则。对我们今后的测试工作来说，从项目中任意功能模块作为切入点，从测试计划、测试设计、测试用例，以及质量分析各阶段进行记录、评审，并在每一个测程中不断的更新、调整测试方案，从而拓展测试的广度和深度，持续优化测试价值。

第二章探索式测试设计概论

本张可以学到的是：

探索式测试的思维模型；
测试先知、测试过程和测试覆盖等测试要素；
以启发式测试策略模型总结全章内容。

思维模型

因为在产品设计之初、需求评审之初都无法了解到所有可能出现缺陷的地方，所以有场景缺失属于正常现象。那为了发现更多bug，需要在测试的过程中，根据测试反馈，不断的优化测试模型，调整测试思路。
测试专家艾瑞克.彼得森提出了探索式测试模型包含：整理、排序、调查、实验。
整理(Collation):尽最大可能收集关于被测产品的信息，去了解和理解它们。
排序(Prioritization):确定所有测试任务的优先级
调查 (Investigation):对即将执行的测试任务进行仔细的分析并确定测试输入和预期输出。
实验(Experimentation):实际地去测试，验证我们的预测是否正确，检查我们在整理阶段获取到的信息是否正确。根据实验结果，测试人员将收集更多的信息，并调整测试任务的优先级。

小结：探索式测试过程中，测试学习、测试设计、测试执行和测试评估是互相支持和驱动的活动。

测试先知是一组信息，用于确定测试过程中发现的问题是否为软件缺陷。需要了解两大类情况：①测试人员的情况；②被测产品的情况。

测试过程

在实验过程中，测试人员可以利用如下思路实施探索
1、充分利用自己现有的资源，包括用户、文档信息、开发人员关系、同事设备和工具和计划等；
2、综合使用多种测试技术，包括功能测试、域测试、压力测试、场景测试用户测试、风险测试、声明测试(针对重要客户的声明内容进行测试)和自动化测试等
3、利用自己实际能够做的东西，包括自己擅长的技术、最容易暴露问题的数据问题和可利用的硬件资源等。

测试学习通常包含如下几个步骤
(1)形成一个关于产品功能的模型
(2)了解这个产品旨在完成什么任务。
(3)列出需要测试的产品元素；
(4)尝试构建多个测试知，例如参考HICCUPPS(F)启发式规则开发一批战队当前产品的测试先知。
(5)产生测试数据；
(6)考虑被测产品的可测试性和尝试不同的测试工具；
(7)尝试用多种不同的方法去实验；
(8)报告所发现的产品缺陷；

测试过程中，可能会遇到困惑的地方，可以通过以下方法来接触疑惑：
1、简化自己的测试思路；
2、保留测试现场并寻求帮助；
3、不断重复执行自己的操作；
4、返回到一个已确认过的状态；
5、一次只考虑一个因素，一次只修改一个因素；
6、做出精确的观察。

测试覆盖
1、结构覆盖；
2、功能覆盖；
3、数据覆盖；
4、平台覆盖；
5、操作覆盖；
6、时间覆盖。

启发式测试策略模型HTSM

学习了前面的测试先知、测试过程和测试覆盖，所以需要一个完成的策略模型将其串起来，质量标准、项目环境、产品元素、指导测试技术的选择与应用，产生观察到的质量。具体内容如下：
1、测试技术；功能/域/压力/流/场景/声明/用户/风险/自动测试；
2、项目环境；资源、约束和其他影响测试的项目元素，比如：用户、信息、开发者关系、测试团队、设备与工具、进度、测试条目、交付品；
3、产品元素；包括：结构、功能、数据、平台、操作、时间；
4、质量标准之操作性标准；能力、可靠性、可用性、安全性、性能、可安装性、兼容性；
5、质量标准之开发标准；可支持性、可维护性、可测试性、可移植性、本地化能力；
小结：通过上述测试指南，启发测试人员的思维，发掘测试对象和测试策略。

在实际应用中，面对复杂的场景，启发式提问可以帮助测试人员更深入的测试产品：
1、该元素与哪些元素相关；
2、元素的组合有没有揭示出新的风险？
3、如何设计测试，以同时测试这些元素？
4、能否让来自元素A的信息帮助元素B的测试？

第三章单特性测试方法

本张主要讨论探索式测试在功能测试上的典型技术和方法。

联想输入模型

先在所有输入的全集中生成分类子集，然后根据测试对象选择一个子集进行测试，接着评估测试输入是否提供了足够的测试覆盖。如果测试覆盖有待提高，则继续选择测试自己进行测试。
实际应用场景：
1、原子输入；eg：单个事件，简单的输入。
2、抽象输入；eg：将多个单个事件组合在一起，构成抽象输入。
3、输入筛选器；eg：防止非法的输入值被传递给应用软件的功能代码。
4、输入检查：eg：功能代码的一部分，通常用if-else实现。
5、异常处理代码；把整个测程作为整体进行异常处理并产生通用的出错信息

非常规的输入：
1、与Ctrl、Alt、ESC按键组合的字符；
2、特殊字符、特殊字符集、当地语言；
3、平台特殊字符：OS、语言、浏览器、保留字符；

应用：
测试专家通过输入三边长度，来判断是否是三角形、是什么类型的三角形，因为没有确定明确3边的界限，所以通过不同输入值来确定这个功能的模型，一步一步探索、实验、不断变化原子的输入值来应用联想输入模型。

互联网测试模型

功能测试模型：
页面动作：

翻页；
文件上传；
表单清空；
表单提交；
全选/反选；
重置

基本操作：

单个查询操作；
级联查询操作；
新增操作；
修改操作；
删除操作；
数据导入操作。

搜错查询操作：

特殊字符；特殊字符或系统/HTML保留字符输入；
超时异常；大数据量下的严重超时或页面JS加载异常；
参数异常；考虑搜索查询传入参数的正确和完整性；
结果异常；考虑查询项在查询前后的变化或查询结果边界的情况。

数据库键/字段/数据类型

键的唯一；
键的边界；
键的属性；
分库分表；

漫游测试模型

I.基础测试方法

方法1 卖点测试法
方法2 恶邻测试法；测试人员找到那些缺陷数目比较多的功能特性，并对临近功能特性进行重点测试；
方法3 配角测试法；有助于提高产品的正确性和完整性；
方法4 超模测试法；测试人员只关心产品的界面显示，测试用户界面上的各种因素，包括友好型、美观性、性能等；
方法5 懒汉测试法；测试人员减少输入或者操作流程，如接受所有默认值，保持某些字段为空、不点击相关操作按钮等，以检查程序处理默认值的能力。
方法6 反叛测试法；测试人员输入最不可能的数据，或已知的恶意数据，没意义的数据，从而检查程序的健壮性和容错性；
方法7 强迫症测试法；输入同样的数据，反复执行同样的操作，从而检查程序的健壮性和容错性

II.进阶测试方法

方法1 极限测试法；对于某个特性提出很多难以回答的问题，运行程序查看结果是否正确；
方法2 麻烦测试法；对于某个特性故意设置各种障碍来看产品如何应对，思路就是采用一些非正常的使用方式；重点是产品的应变能力；
方法3 通宵测试法；连续不断的使用某个特性或将文件一直保持打开状态，让某些特性的运行时间特别长；目的是为了提高系统的稳定性和可靠性；
方法4 测一送一测试法；测试人员同时运行同一个应用层序的多个实例，多个用户同时使用同一个特性，类似于多线程测试模型；
方法5 取消测试方法；测试人员启动某些功能操作后再停止它运行，对所有提供取消选项的功能或需要较长时间才能完成的功能执行取消操作，检查程序的自我清除能力；
方法6 破坏测试法；试图利用每个可能的机会暗中破坏产品，人为地创建恶劣的运行环境（内存少、无权限、断网、故障注入等）。

第四章交互特性测试方法

本张对交互特性测试进行分析，并主要关注探索式测试在这个层次上如何进行测试设计和测试执行的。

场景操作模型

方法1 插入步骤-增加更多数据；
方法2 插入步骤-适用附加输入；
方法3 插入步骤-访问新的界面；
方法4 删除步骤-删除部分步骤；
方法5 替换步骤-替换部分步骤；
方法6 重复步骤-重复部分步骤；
方法7 替换数据-替换部分数据；
方法8 替换环境-替换硬件；
方法9 替换环境-替换容器；
方法10 替换环境-替换版本；
方法11 替换环境-修改本地设置；

漫游探索模型：

本节把漫游测试法和测试场景进行组合和变化，以产生更多的复杂变化的测试思路和衍生场景。

方法1 地标测试法；找到主要关键特性，确定前后顺序，然后探索多个特性的交互过程
方法2 快递测试法；找到某个特性所使用的的内部数据，并且通过操作软件是的该数据走遍其相关特性；
方法3 遍历测试法；
方法4 博物馆测试法；测试人员查看代码库和程序集文件，找到遗留代码，针对最近被修改的遗留代码进行测试；
方法5 上一版测试法；
方法6 深港测试法；关注哪些最不易被发现，不吸引用户的小功能特性；
方法7 长路径测试法；测试人员选择某个特性并进行长路径的漫游，例如测试经过多次操作或多个页面才能完成的任务、测试跨多个业务特性的长流程业务等。

第五章系统交互测试方法

本章所讨论的系统交互测试方法不是传统意义上的系统测试阶段的测试方法，而是将整个被测产品合理地划分成单个特性和多个特性的测试方法。该过程也有助于制定合理的测试计划和测试策略。单个特性测试 → 交互特性测试 → 系统交互测试，循序渐进一次展开至第三个层次。

一、通用功能性与稳定性测试过程

1、确定产品的目的和功能；

所谓功能是指产品为了实现其目标而提供的一组能力，它们帮助用户达成其使命。因此，评价功能的重要出发点是检查它们是否符合产品目标，是否能协助或取悦用户。

一般来讲，测试人员会花大部分时间测主要功能，少部分时间测贡献性功能，至于怎么分类，需要依据上下文语境（产品目的、用户能力、项目目标等）

决定一个产品的功能是不是主要还是要看产品的目的、用户侧观察出的产品价值。如果主要功能缺失，将导致解决方案（产品）失败，用户不能完成任务，不能实现目标。如果贡献性功能缺失将导致解决方案有缺点，用户可以完成使命，但需要额外付出更多的努力。

测试人员如果只考虑用户交互，就很难识别出一些隐含功能。有些功能与系统服务、其他程序、文件系统等进行交互，而用户在产品界面上并不能直接观察到这些功能的作用。因此，测试人员需要与开发人员和产品经理密切合作，挖掘出完整的功能列表，并重视那些重要的且被隐藏的功能。通常，测试人员会测试所有的主要功能，但可能没有足够的时间去测试所有的贡献性功能。这对于某些阶段或某些目的的测试是允许的。如果测试人员不能测试所有功能，他需要生成一份记录文档，以记载测试了哪些功能、没有测试哪些功能、做出这些决定的理由等，从而让管理层明确知道本次测试的范围。测试人员要确保在产品发布前覆盖所有待测功能。

2、确定潜在的不稳定区域；

在探索被测产品的时候，测试人员需要重点测试那些稳定性较差的功能。这时可以选择5~10个功能或功能组专门实施定性测试。如果“贡献性的功能”特别容易失败，那就选择它们，但更应该关注不稳定的“主要的功能”。

以下是一些在软件中常见的不稳定因素：

与其他产品进行交互的功能。
会消耗大量内存的功能。
与操作系统交互特别紧密的功能。
很复杂的功能。
需要改变一些操作参数配置的功能。
需要改变操作系统配置的功能
捕获错误的和从错误中恢复的功能
替代了基本的操作系统功能的功能。
涉及了多线程工作的功能。
同时操作多个文件的功能。
需要从网络上打开文件的功能

针对不稳定的功能，可以参考以下有挑战性的数据和测试想法：

文档：大的文档、同时打开许多文档或文档中包含许多不同的对象。
记录：长的记录、很大数量的记录或复杂的记录。
列表：长的列表、空的列表或多列的列表。
字段：输入大量字符和非常大的值。
变化：新增和删除一些东西、编辑但没有保存或编辑成功
负载：使大量进程同时运行、大量进行批处理或在很短时间内做很多操作。
无推断：在窗口中随意点击、随意输入字符或输入无期望的值。
异常和恢复：多次破坏进程、取消操作、使用错误数据触发错误处理。

3、测试产品的功能性和稳定性；

很多测试团队在测试执行的时候应会把测试设计和测试用例全部编写并传承下去。该做法会导致一个问题:详细地记录所有测试用例需要投入太多的时间，而且还会打断探索式测试的测试执行思路。其结果是测试人员产生了大量的文档,但实际执行的测试却很少。另一种注重实效的做法是，测试人员只简要地记录测试范围、驱动测试设计的测试策略和关键性发现，而不必详细记录测试设计与测试用例。此外，测试人员也可以有选择性地记录测试点和测试数据，为后续的回归测试和经验分享提供素材。总之，测试笔记只需要记录必要的内容。当测试人员自己阅读或者他向其他同事解释测试笔记时，简单的记录可以唤醒他的记忆，并能够满足备忘和交流的要求。

二、漫游地图模型

1、漫游地图模型简介；

漫游地图模型将产品比喻成一个城市来划分区域地图，能够帮助测试人员更好地制定测试计划、测试范围和测试策略。

2、漫游地图思维架构；

需要在整体上分析和把握被测产品的需求和目的他可以使用一些图元来标识功能的特性和测试的注意点。

3、肥皂剧测试模型

特征：

源于真实生活；肥皂剧测试通过聚焦用户的使用场景来伸张用户权益。那些看似极端、却可能真实发生的故事，往往能揭示产品的深层次错误。此外，通过编写肥皂剧测试用例，测试人员可以更好地学习并理解被测产品。
夸张；夸张的测试用例有助于软件应对现实难题；
浓缩；浓缩的情节可以在较短的时间内测试多个功能，提高了测试小类
乐趣；有趣的测试过程会激发测试者的创造力，使他们始终热情高涨、思维活跃，激发审阅者、测试者的灵感，让他们发展出更高的支线和细节。

第六章探索式测试的工具

一、测试计划

测试活动分为：测试计划、测试设计与执行、软件监控、缺陷记录、测试评估

eg：notepad++ 、sublime、 Markdown、思维导图、Excel、印象笔记等

1、可以将所有资料放置于一个分区(分区) 中，便于统一管理。
2、利用页(Page)的父子关系表示资料之间的逻辑关系，使得资料组织直观明了。
3、也可以容纳文档、图片、链接、文字和图表等多种元素，能够将相关主题的内容一网打尽；

测试过程会产生大量的信息和想法，测试人员需要记录其中重要的部分。一方面，笔记使得重要的信息不会被遗漏、瞬间激发的想法不会被遗忘;另一方面，笔记减轻了认知负荷，使得测试人员可以放心大胆地探索，专注于当前的思路，而不必惦记着其他有价值的想法。

二、测试设计和执行；

1、了解产品的代码及模型；

2、掌握一门动态语言

3、测试评估

测试工具：

HutoHotKey ; AutoHotKey是一个开源的鼠标与键盘宏工具(Mouse and Keyboard MacroProgram)，它在后台运行，用户可以根据键命令或鼠点击触发事先编写好的脚本，以自动完成一系列操作。
NotePad2；开元、轻量级的文本编辑器；
winMerage；文件比对和合并的工具；
winbg 用于调试window引用、驱动、服务和windows操作系统的调试器；比较难学
Process Explorer；Process Explorer 是 Windows Sysinternals Suite 的成员之一Sysinternals Suite23是微软提供的一套系统工具，用于 Windows 系统和应用的管理、诊断、调试和监控，在Windows平台的开发者和管理员中拥有盛名。
Process Monitor；也是一个调试、监控的工具；
Firebug；调试后端代码，进行分析，还可实时修改HTML数据，绕过客户端的输入限制，将攻击性的数据直接提交给服务，提高测试效率；
fiddler；一个网页端的后端接口的调试、抓包工具，还有wireshark

第七章探索式测试与自动化测试

测试自动化(TestAutomation)是为了完成测试使命而实施的开发与维护活动。随着软件开发技术的发展，测试自动化得到了普遍重视与采纳。在一些研发团队，它已经成为最重要的质量保证手段之一。

探索式测试自动化测试用例
1. 准备、执行、检验、清理和报告，最终形成自动化套件；
2. 优秀的测试人员将手工和自动化相互支持，持续优化测试结果；
自动化测试用例的开发目标
1. 第一，自动化测试用例应该有助于提高质量。
2. 第二，自动化测试用例应该迅速找出重要的程序问题。
3. 第三，自动化测试用例应该易于编写和维护[Meszaros07]。
4. 第四，自动化测试开发应该具有较高的投资回报率。
综合运用探索测试和脚本测试
1. Karen的案例表明探索式测试和脚本测试可以有机地结合在一起，并相互辅助。探索式测试人员会阅读特定功能的测试脚本，以产生测试思路。
探索式的自动化测试用例开发
1. 实践1:选择或开发适合的测试框架；
2. 实践2:收集并理解规格说明。
3. 实践3:开发基本测试用例。
4. 实践4：阅读被测软件的源代码；
5. 实践5：用探索去解决困惑；
6. 实践6：增加测试用例来记录对软件的理解；
7. 实践7：利用测试覆盖率来增强测试套件；不解
8. 实践8：重构测试代码；
探索式自动化测试案例
1. 盖特伍德的单肩包提示测试人员自问：测试自动化的投资回报率如何?是那些投入最多的测试在创造最多的价值吗?我们遵循了“要事第一”(First Thing First)的原则吗?我们的主要精力是投入在最有价值的事情上吗?现有的流程、框架、基础设施中，有哪些部分不是必需的？能用更轻量的方法替代吗?
2. 从简单的测试先知开始，利用测试反馈持续完善测试先知。Harry 将这种选代式的测试开发过程称为涌现式测试
探索式自动化测试的意义
1. 自动化测试用例对回归测试很有帮助，对测试设计能提供有益的信息，但是对其他活动支持有限。为了更好地测试，测试者需要放宽测试自动化的视野，在整个开发周期合理地利用计算机的强大能力。

第八章探索式测试的组织与实施

对于一个公司而言，测试团队如果尝试采用探索式测试的方式来进行测试，就需要将探索式测试方式融入现有的测试流程，并了解探索式测试是如何控制测试进度和质量的。另外，有些测试团队希望采用探索式的思路去实践某些项目，做一些小尝试，他们也渴望了解是否存在一些比较简单的探索式测试的组织方法，以及实践过程中需要注意哪些因素等。以上一系列问题是本章讨论的重点。