探索式软件测试
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
O 错误处理程序（error handler）
1.
2.
方式
3.
输入筛选器 用户防止非法的输入值被传递给应用程序的功能代码。 确认开发人员是否正确实现了筛选器 确认是否可以绕过输入的屏蔽器 输入检查 通过if then else case select 等方式实现 测试人员关注错误提示信息，挖掘其他可以触发错误的
五要素之一-‐-‐-‐-‐-‐用用户输入入
软件的核心功能： 1. 接收输入 2. 产生输出 3. 存储数据 4. 进行运算 程序的错误处理程序是重点 大量的代码除了处理程序的正常逻辑之外， 还需要大量的代码处理各种错误和异常情况
五要素之一-‐-‐-‐-‐-‐用用户输入入
针对测试对象的局部内容进行测试的策略，例 如：一个页面、一个输入框等的测试策略。 O 全局探索式测试法 使用测试集用来确定软件是否已经满足正式发 布所需达到的质量标准。 测试集中的测试用例都是相互有联系的整体 确定了如何对软件进行探索式测试的整体方向
传统的测试和探索式测试
O 两者的关系为互补关系，而不是对立关系 O 传统测试通过收集来的各种信息和文档，
五要素之一-‐-‐-‐-‐-‐用用户输入入
O 使用输出来指导输入
把程序的主要输出结果列出来，确定哪些输入 会引发这些输出。 输入和输出配对，保证大部分场景都被测试过 考虑多次输入（相同值和不同值），对输出的 影响 从保存起来的输出结果思考，改动这些值或者 改变他们的功能（大小和类型等），可以测试该 值对此系统的一些影响
自动化测试
擅长找到的问题： 1. 程序崩溃 2. 系统死机 3. 程序挂起 4. 突发异常 5. 原有能用的功能出现问题 过度的依赖自动化测试会成为程序的最终成 功带来隐患
手工测试
O 由人来动手进行测试 O 手脑并用，充分发挥测试人员的聪明才智 O 设计出真实的用户情况 O 在真实的用户环境中使用真实的用户数据 O 可以识别出显而易见的缺陷和难以察觉的缺
在比较特殊的情况下才会发生，或者某些特殊条 件才会出发的输入。 例如：输入Ctrl+c、shift+c、esc、Alt、Ctrl键 操作系统的保留字 不同的字符集，本地化的问题
五要素之一-‐-‐-‐-‐-‐Fra Baidu bibliotek用户输入入
O 默认输入
在空白的文本框种不输入任何东西 程序界面元素设定的默认值 测试方法： 为空的时候直接提交程序处理 去掉页面默认值后，提交程序处理 修改默认值，增加？减少？变换类型 等方式
测试的目标
目标： 所有的重要任务都完成了，而剩下没做的事 情是比较次要的，我们做到这一点就可以尽 早尽可能地降低发布风险。 方法： 测试是一个不停进行抉择的过程。测试人员 必须理解运行测试用例时和分析现有信息所 涉及的各种复杂性，这有助于从多种可行方 案中做出正确的选择。
局部探索式测试法
O 测试人员不需要知道很多信息就可以完成测
五要素之一-‐-‐-‐-‐-‐状态
O 电话的状态： （接电话动作作为输入）
O 如果电话连接的电话网没有开通，电话就不
会有什么反应。或者发出一个错误的回应 O 如果当前电话没有在振铃，电话就会发出一 个拨号音 O 如果当前电话正在振铃，电话就会被接通， 用户可以和其他人通话
五要素之一-‐-‐-‐-‐-‐状态
编写出正式的测试用例，测试人员根据测 试用例来执行。 O 在执行正式的测试用例的同时，可以使用探 索式测试来让测试用例更加的丰富和富有 变化，提高测试代码的覆盖率，找到更多 的bug。
⺫目目前测试的现状
O 招聘广告：
急需一名软件测试人员，该职位要求根据那些 乱七八糟且只有半截的规格说明书（如果还找到 的话）来测试一个高度复杂且基本不带文档支持 的软件产品。不要指望当初的开发人员，他们基 本不远也不会帮助你。该产品的使用环境复杂， 支持多用户、多平台和多语言，和其他很多必须 支持的环境。我们不清楚如何定义它们，但安全 性和性能是最重要的，而且该软件发布后不允许 出现任何问题，否则我们就玩完了。
异常处理代码 错误的提示信息比较笼统 确认异常产生的输入，进行修改和引申变化，确认出现 异常的函数，通过运行调用此函数的测试用例，尝试查询是 否可以发现新的缺陷
五要素之一-‐-‐-‐-‐-‐用用户输入入
O 常规输入
没有特定的格式或含义，开发计划中的输 入，真实用户经常用的输入。 例如：输入字母和数字等 O 非常规输入
试任务，局部测试的重点是把测试经验、 专业知识、软件在操作环境下如何构建和 运行的知识结合在一起，使我们在测试过 程中做出正确的决定。
测试的无穷特性
测试运行时的表现是否符合设计预期 2. 用户为了某个功能而购买了软件，可是该软 件是否实现了这个功能？ 3. 软件运行时，是否足够快、足够安全、足够 稳定，等等？ 解决以上问题的方式：在某个特定操作环境中运 行该软件，并且模拟软件预期的使用方式来输入 这些值。 问题：输入的内容太多、组合方式太多、可运行 环境太多
O 使用状态信息来帮助寻找相关的输入
找到相关的输入值和状态信息，通过某种 方式确认使用哪些输入的组合，可以保证所 有重要的情况和变化都被测试到了。 O 使用状态信息来辨识重要的输入序列 当一个输入导致状态信息被更新后，紧接 着多次使用相同的输入，导致一系列的状态 变化。
五要素之一-‐-‐-‐-‐-‐代码路径
五要素之一-‐-‐-‐-‐-‐状态
状态: O 软件的一个状态就是状态控件中的一个点，它 由所有内部数据结构的取值来唯一确定。 O 通俗的说：当个输入、一些输入或者全部输入 会被软件“记住”，从而让软件看起来不同。 O 状态是软件所有变量的交叉积，状态的无穷尽。 应用程序和其运行环境进行交互和接收到的所 有输入导致软件状态发生变化。 O 可以使用等价类方法来进行一些状态测试
1.
缺陷检测
O 自动化测试
通过编写代码来测试一个应用 O 手工测试 使用程序的用户界面，手工输入数据进行测 试
关于自动化测试
O 需要测试人员编写代码---开发人员 O 花费太多的时间来开发测试代码，而减少了测试
项目的时间。 O 自动化测试很炫，可以重复执行很多次 O 自动化测试适合在测试环境中运行 O 预言家的难题： 如何才能知道被测试软件确实完成了他应完成 的任务？ 被测软件是否输出了正确的结果？ 在运行中是否会带来副作用
陷 O 善于发现应用程序业务逻辑相关的错误
手工测试
缺点： O 手工测试很慢，没有规律 O 不可反复使用 O 发现问题后也不能重现 O 测试人员的水平决定了手工测试的质量 O 使用细化的测试用例进行测试，则缺少变通 建议： 测试用例不要使用太细节的描述，而是描述一些 笼统的用户使用场景。 手工测试也可以使用自动化测试工具
指南测试法
测试人员通过阅读用书手册并严格遵守手册 的建议执行操作。 如果手册描述了某个特性以及如何使用该特 性，则需要进行详细测试 目的是尽量执行手册中提交的场景，验证软 件实现的软件特性，也验证了用户手册的准 确性
指南测试法-‐变种
O 博客测试法
遵循第三方的建议来测试 O 专家测试法 根据抱怨的或者吹毛求疵的用户评论来测 试 O 竞争对手测试法（适用于目前产品把竞争产 品作为自己追随的标杆）
软件一般要存储海量的数据。 测试环境中包含的数据应该和软件真实用户使用的数 据尽量相似，困难如下： O 真实用户的数据总是被不断添加和修改，组合无穷 尽 O 测试人员无法了解用户数据的关系和结构 O 海量数据，有可能无地方存放（受成本所限） O 使用真实的用户数据库，但是又被用户的隐私所困 扰 只能尽可能了解被测试系统，想办法构造尽可能真实 的用户数据模型，来进行数据层面的充分测试
1.
测试的原则
O 把测试工作简化为先在所有输入（或者运行
环境等）的全体集合中选择一个子集，然 后在输入时使用选中的子集，最后通过推 理认定是否这些输入已经足够多了。 O 最终产品发布后，在进行测试已经无法提高 已发布代码的质量了。 O 对于无限的测试，我们唯一的希望寄托于我 们选择了正确的输入和其他测试决策。 O 随机测试不是好的测试方法，因为他缺少必 要的策略
光荣之路软件测试培训 --吴老
大纲
O 自动化测试 O 手工测试 O 局部探索式测试法 O 全局探索式测试法 O 混合探索式测试技术 O 漫游与测试中的棘手问题
手手工工测试
软件缺陷（Bug）的根源： 来自软件开发本身！ 两种缺陷： 程序员引入的缺陷 运行环境导致的缺陷
缺陷预防和检测
设计更好的设计规范 2. 实施代码审核制度 3. 运行代码静态分析工具 4. 运行单元测试工具（自动化测试居多） 以上几点方式有些根本性问题： O 开发人员只能是个糟糕的测试者 O 处于静止状态的软件 O 缺乏数据
一条代码路径就是一连串的代码语句，它起 始于软件开始运行的语句，终止于一条特定 的语句。 O 一个程序有很多条代码路径，总量非常大。 O 测试人员必须清楚程序里面有哪些分支。 O 尽量测试所有知道的分支，尝试探索发现未 知的分支 O 可以分析代码覆盖率，基本评估自己的测试 覆盖程度
五要素之一-‐-‐-‐-‐-‐用用户数据
五要素之一-‐-‐-‐-‐-‐运行环境
五要素的前4个如果都被充分测试了，但是如果软件迁移到一个新的运行 环境，则一样有可能无法运行成功。 环境本身就是一种输入源 环境包含的要素很负责，列举一些： 操作系统 当前配置 其他应用程序 网络拓扑 驱动程序 文件系统 网络带宽 性能 测试环境很关键，很难测试
使用用竞争对手手的操作手手册来测试自自己己的应用用 程序
卖点测试法
软件中最核心的功能，用户希望使用的功能 就是卖点。 销售人员会花费大量时间来给用户演示这些 程序的卖点，他们会创造出很多出彩的使用 场景。 测试人员应该和销售人员保持好关系，获取 各种销售方面的信息，来进一步探索软件的 使用场景
地标测试法
O 使用指南测试法和卖点测试法，找到相关的
地标。 O 确定关键的软件特性，然后确定他们的前后 次顺序，然后从一个地标跳转到另外一个 地标来探索这些应用程序。 O 选择多个起始地标，开始探索 O 测试开始后，增加新的地标 O 改变地标的前后访问顺序
测试决策的5要素
1. 用户输入 2. 状态 3. 代码路径 4. 用户数据 5. 执行环境
五要素之一-‐-‐-‐-‐-‐用用户输入入
O 输入：
输入指的是由环境产生的一种刺激，该刺激导致被 测试的应用有所响应。 分类： 1. 原子输入 例如：输入一个数字 点击一个按钮 2. 抽象输入 例如：1-25535之间的任何一个原子输入长度值
探索式测试
完全抛开测试用例，使用定义的比较笼统的 测试用例，则称之为探索式测试。 特点： 1. 根据收集到的信息，天马行空，自由发挥 2. 测试结果、测试实例和测试文档在测试执 行时创建 3. 探索式测试适用于“敏捷开发过程” 4. 测试人员有可能没有测试重点
探索式测试方方法
O 局部探索式测试法
五要素之一-‐-‐-‐-‐-‐用用户输入入
O 考虑各种输入之间会相互影响 O 输入值的顺序
例如：
1. 单独搜索cd无问题，单独搜索视频无问题，
混合搜索视频和cd则有问题 2. a和b的输入，组合：ab，ba。 3. abc的组合输入：abc ，bac，bca等 4. 购物车测试，先买书，结账。为空的时候 结账，买一本后结账，然后再买一本。
局部探索式测试法
总结： O 五要素的内容组合无穷尽，我们在测试过程 中尽可能获取5要素种的各种信息，来为我 们的测试决策提供素材。 O 局部探索式测试的每一步都是根据软件过去 和当前的运行状况、软件在测试时表现出 来的各种行为和软件运行时的各种信息来 即时决定。
全局探索测试
探索测试的几个目标： O 理解应用程序如何工作，它的接口看起来怎样， 它实现了哪些功能 提供必要信息，给测试人员提供测试切入点 尽可能发现新的、没有被探索过的功能 O 强迫软件展示其全部能力 验证软件可以达到设计和发布要求 O 找到缺陷 探索各种软件的极端情况来发现潜在的问 题。发现未被测试过的功能或者是包含缺点多的 功能。
1.
2.
方式
3.
输入筛选器 用户防止非法的输入值被传递给应用程序的功能代码。 确认开发人员是否正确实现了筛选器 确认是否可以绕过输入的屏蔽器 输入检查 通过if then else case select 等方式实现 测试人员关注错误提示信息，挖掘其他可以触发错误的
五要素之一-‐-‐-‐-‐-‐用用户输入入
软件的核心功能： 1. 接收输入 2. 产生输出 3. 存储数据 4. 进行运算 程序的错误处理程序是重点 大量的代码除了处理程序的正常逻辑之外， 还需要大量的代码处理各种错误和异常情况
五要素之一-‐-‐-‐-‐-‐用用户输入入
针对测试对象的局部内容进行测试的策略，例 如：一个页面、一个输入框等的测试策略。 O 全局探索式测试法 使用测试集用来确定软件是否已经满足正式发 布所需达到的质量标准。 测试集中的测试用例都是相互有联系的整体 确定了如何对软件进行探索式测试的整体方向
传统的测试和探索式测试
O 两者的关系为互补关系，而不是对立关系 O 传统测试通过收集来的各种信息和文档，
五要素之一-‐-‐-‐-‐-‐用用户输入入
O 使用输出来指导输入
把程序的主要输出结果列出来，确定哪些输入 会引发这些输出。 输入和输出配对，保证大部分场景都被测试过 考虑多次输入（相同值和不同值），对输出的 影响 从保存起来的输出结果思考，改动这些值或者 改变他们的功能（大小和类型等），可以测试该 值对此系统的一些影响
自动化测试
擅长找到的问题： 1. 程序崩溃 2. 系统死机 3. 程序挂起 4. 突发异常 5. 原有能用的功能出现问题 过度的依赖自动化测试会成为程序的最终成 功带来隐患
手工测试
O 由人来动手进行测试 O 手脑并用，充分发挥测试人员的聪明才智 O 设计出真实的用户情况 O 在真实的用户环境中使用真实的用户数据 O 可以识别出显而易见的缺陷和难以察觉的缺
在比较特殊的情况下才会发生，或者某些特殊条 件才会出发的输入。 例如：输入Ctrl+c、shift+c、esc、Alt、Ctrl键 操作系统的保留字 不同的字符集，本地化的问题
五要素之一-‐-‐-‐-‐-‐Fra Baidu bibliotek用户输入入
O 默认输入
在空白的文本框种不输入任何东西 程序界面元素设定的默认值 测试方法： 为空的时候直接提交程序处理 去掉页面默认值后，提交程序处理 修改默认值，增加？减少？变换类型 等方式
测试的目标
目标： 所有的重要任务都完成了，而剩下没做的事 情是比较次要的，我们做到这一点就可以尽 早尽可能地降低发布风险。 方法： 测试是一个不停进行抉择的过程。测试人员 必须理解运行测试用例时和分析现有信息所 涉及的各种复杂性，这有助于从多种可行方 案中做出正确的选择。
局部探索式测试法
O 测试人员不需要知道很多信息就可以完成测
五要素之一-‐-‐-‐-‐-‐状态
O 电话的状态： （接电话动作作为输入）
O 如果电话连接的电话网没有开通，电话就不
会有什么反应。或者发出一个错误的回应 O 如果当前电话没有在振铃，电话就会发出一 个拨号音 O 如果当前电话正在振铃，电话就会被接通， 用户可以和其他人通话
五要素之一-‐-‐-‐-‐-‐状态
编写出正式的测试用例，测试人员根据测 试用例来执行。 O 在执行正式的测试用例的同时，可以使用探 索式测试来让测试用例更加的丰富和富有 变化，提高测试代码的覆盖率，找到更多 的bug。
⺫目目前测试的现状
O 招聘广告：
急需一名软件测试人员，该职位要求根据那些 乱七八糟且只有半截的规格说明书（如果还找到 的话）来测试一个高度复杂且基本不带文档支持 的软件产品。不要指望当初的开发人员，他们基 本不远也不会帮助你。该产品的使用环境复杂， 支持多用户、多平台和多语言，和其他很多必须 支持的环境。我们不清楚如何定义它们，但安全 性和性能是最重要的，而且该软件发布后不允许 出现任何问题，否则我们就玩完了。
异常处理代码 错误的提示信息比较笼统 确认异常产生的输入，进行修改和引申变化，确认出现 异常的函数，通过运行调用此函数的测试用例，尝试查询是 否可以发现新的缺陷
五要素之一-‐-‐-‐-‐-‐用用户输入入
O 常规输入
没有特定的格式或含义，开发计划中的输 入，真实用户经常用的输入。 例如：输入字母和数字等 O 非常规输入
试任务，局部测试的重点是把测试经验、 专业知识、软件在操作环境下如何构建和 运行的知识结合在一起，使我们在测试过 程中做出正确的决定。
测试的无穷特性
测试运行时的表现是否符合设计预期 2. 用户为了某个功能而购买了软件，可是该软 件是否实现了这个功能？ 3. 软件运行时，是否足够快、足够安全、足够 稳定，等等？ 解决以上问题的方式：在某个特定操作环境中运 行该软件，并且模拟软件预期的使用方式来输入 这些值。 问题：输入的内容太多、组合方式太多、可运行 环境太多
O 使用状态信息来帮助寻找相关的输入
找到相关的输入值和状态信息，通过某种 方式确认使用哪些输入的组合，可以保证所 有重要的情况和变化都被测试到了。 O 使用状态信息来辨识重要的输入序列 当一个输入导致状态信息被更新后，紧接 着多次使用相同的输入，导致一系列的状态 变化。
五要素之一-‐-‐-‐-‐-‐代码路径
五要素之一-‐-‐-‐-‐-‐状态
状态: O 软件的一个状态就是状态控件中的一个点，它 由所有内部数据结构的取值来唯一确定。 O 通俗的说：当个输入、一些输入或者全部输入 会被软件“记住”，从而让软件看起来不同。 O 状态是软件所有变量的交叉积，状态的无穷尽。 应用程序和其运行环境进行交互和接收到的所 有输入导致软件状态发生变化。 O 可以使用等价类方法来进行一些状态测试
1.
缺陷检测
O 自动化测试
通过编写代码来测试一个应用 O 手工测试 使用程序的用户界面，手工输入数据进行测 试
关于自动化测试
O 需要测试人员编写代码---开发人员 O 花费太多的时间来开发测试代码，而减少了测试
项目的时间。 O 自动化测试很炫，可以重复执行很多次 O 自动化测试适合在测试环境中运行 O 预言家的难题： 如何才能知道被测试软件确实完成了他应完成 的任务？ 被测软件是否输出了正确的结果？ 在运行中是否会带来副作用
陷 O 善于发现应用程序业务逻辑相关的错误
手工测试
缺点： O 手工测试很慢，没有规律 O 不可反复使用 O 发现问题后也不能重现 O 测试人员的水平决定了手工测试的质量 O 使用细化的测试用例进行测试，则缺少变通 建议： 测试用例不要使用太细节的描述，而是描述一些 笼统的用户使用场景。 手工测试也可以使用自动化测试工具
指南测试法
测试人员通过阅读用书手册并严格遵守手册 的建议执行操作。 如果手册描述了某个特性以及如何使用该特 性，则需要进行详细测试 目的是尽量执行手册中提交的场景，验证软 件实现的软件特性，也验证了用户手册的准 确性
指南测试法-‐变种
O 博客测试法
遵循第三方的建议来测试 O 专家测试法 根据抱怨的或者吹毛求疵的用户评论来测 试 O 竞争对手测试法（适用于目前产品把竞争产 品作为自己追随的标杆）
软件一般要存储海量的数据。 测试环境中包含的数据应该和软件真实用户使用的数 据尽量相似，困难如下： O 真实用户的数据总是被不断添加和修改，组合无穷 尽 O 测试人员无法了解用户数据的关系和结构 O 海量数据，有可能无地方存放（受成本所限） O 使用真实的用户数据库，但是又被用户的隐私所困 扰 只能尽可能了解被测试系统，想办法构造尽可能真实 的用户数据模型，来进行数据层面的充分测试
1.
测试的原则
O 把测试工作简化为先在所有输入（或者运行
环境等）的全体集合中选择一个子集，然 后在输入时使用选中的子集，最后通过推 理认定是否这些输入已经足够多了。 O 最终产品发布后，在进行测试已经无法提高 已发布代码的质量了。 O 对于无限的测试，我们唯一的希望寄托于我 们选择了正确的输入和其他测试决策。 O 随机测试不是好的测试方法，因为他缺少必 要的策略
光荣之路软件测试培训 --吴老
大纲
O 自动化测试 O 手工测试 O 局部探索式测试法 O 全局探索式测试法 O 混合探索式测试技术 O 漫游与测试中的棘手问题
手手工工测试
软件缺陷（Bug）的根源： 来自软件开发本身！ 两种缺陷： 程序员引入的缺陷 运行环境导致的缺陷
缺陷预防和检测
设计更好的设计规范 2. 实施代码审核制度 3. 运行代码静态分析工具 4. 运行单元测试工具（自动化测试居多） 以上几点方式有些根本性问题： O 开发人员只能是个糟糕的测试者 O 处于静止状态的软件 O 缺乏数据
一条代码路径就是一连串的代码语句，它起 始于软件开始运行的语句，终止于一条特定 的语句。 O 一个程序有很多条代码路径，总量非常大。 O 测试人员必须清楚程序里面有哪些分支。 O 尽量测试所有知道的分支，尝试探索发现未 知的分支 O 可以分析代码覆盖率，基本评估自己的测试 覆盖程度
五要素之一-‐-‐-‐-‐-‐用用户数据
五要素之一-‐-‐-‐-‐-‐运行环境
五要素的前4个如果都被充分测试了，但是如果软件迁移到一个新的运行 环境，则一样有可能无法运行成功。 环境本身就是一种输入源 环境包含的要素很负责，列举一些： 操作系统 当前配置 其他应用程序 网络拓扑 驱动程序 文件系统 网络带宽 性能 测试环境很关键，很难测试
使用用竞争对手手的操作手手册来测试自自己己的应用用 程序
卖点测试法
软件中最核心的功能，用户希望使用的功能 就是卖点。 销售人员会花费大量时间来给用户演示这些 程序的卖点，他们会创造出很多出彩的使用 场景。 测试人员应该和销售人员保持好关系，获取 各种销售方面的信息，来进一步探索软件的 使用场景
地标测试法
O 使用指南测试法和卖点测试法，找到相关的
地标。 O 确定关键的软件特性，然后确定他们的前后 次顺序，然后从一个地标跳转到另外一个 地标来探索这些应用程序。 O 选择多个起始地标，开始探索 O 测试开始后，增加新的地标 O 改变地标的前后访问顺序
测试决策的5要素
1. 用户输入 2. 状态 3. 代码路径 4. 用户数据 5. 执行环境
五要素之一-‐-‐-‐-‐-‐用用户输入入
O 输入：
输入指的是由环境产生的一种刺激，该刺激导致被 测试的应用有所响应。 分类： 1. 原子输入 例如：输入一个数字 点击一个按钮 2. 抽象输入 例如：1-25535之间的任何一个原子输入长度值
探索式测试
完全抛开测试用例，使用定义的比较笼统的 测试用例，则称之为探索式测试。 特点： 1. 根据收集到的信息，天马行空，自由发挥 2. 测试结果、测试实例和测试文档在测试执 行时创建 3. 探索式测试适用于“敏捷开发过程” 4. 测试人员有可能没有测试重点
探索式测试方方法
O 局部探索式测试法
五要素之一-‐-‐-‐-‐-‐用用户输入入
O 考虑各种输入之间会相互影响 O 输入值的顺序
例如：
1. 单独搜索cd无问题，单独搜索视频无问题，
混合搜索视频和cd则有问题 2. a和b的输入，组合：ab，ba。 3. abc的组合输入：abc ，bac，bca等 4. 购物车测试，先买书，结账。为空的时候 结账，买一本后结账，然后再买一本。
局部探索式测试法
总结： O 五要素的内容组合无穷尽，我们在测试过程 中尽可能获取5要素种的各种信息，来为我 们的测试决策提供素材。 O 局部探索式测试的每一步都是根据软件过去 和当前的运行状况、软件在测试时表现出 来的各种行为和软件运行时的各种信息来 即时决定。
全局探索测试
探索测试的几个目标： O 理解应用程序如何工作，它的接口看起来怎样， 它实现了哪些功能 提供必要信息，给测试人员提供测试切入点 尽可能发现新的、没有被探索过的功能 O 强迫软件展示其全部能力 验证软件可以达到设计和发布要求 O 找到缺陷 探索各种软件的极端情况来发现潜在的问 题。发现未被测试过的功能或者是包含缺点多的 功能。