探索性测试之启发式测试策略模型

2022-06-15 15:41:54

点击上方“WXCOP” 可以订阅哦！

文章简介

启发式测试策略模型是设计测试策略的一套模式，这个模型的直接意图是提醒测试人员在创建测试时应该要想到的一些内容。

一、探索性测试的定义

探索性测试(exploratory testing)这个词是由Cem Kaner在1983年提出。他将探索性测试定义为：一种强调个人自由与责任的测试方法，让独立的测试者可以借由不断的学习来改善测试的设计与测试的执行，而在测试的过程中也会同时的改善用例达到相辅相成的效果。

探索式测试是一种自由的软件测试风格，强调测试人员同时开展测试学习、测试设计、测试执行和测试结果评估等活动，以持续优化测试过程，它是一种软件测试的思路，而不是具体的软件测试技术。当软件开始测试流程后，一般测试者会使用预先设立好的测试用例来进行系统测试，而探索性测试则不依赖于预设的用例，边设计，边执行，就是为了弥补传统的用例测试的缺点而产生的。

那么在探索性测试过程中如何创建测试策略，如何进行测试管理呢？启发式测试策略模型和基于Session的测试管理给出了解答，本文介绍前者，下次课介绍后者。

二、启发式测试策略模型

启发式测试策略模型（Heuristic Test Strategy Model）是设计测试策略的一套模式。这个模型的直接意图是提醒测试人员在创建测试时应该要想到的一些内容。最终，这套模型要根据实际情况来定制，并用来在专业测试人员中促进交流、自学、并且更充分的进行有意识的测试。HTSM是一个结构化的、可定制的参考模型，从测试技术、产品元素、项目过程、质量标准等多个角度启发测试。

项目环境包括资源、约束、以及项目中有助于我们测试的其它强力因素，当然也包括阻碍我们做好工作的因素。当面对阻力时，先确认你是否利用了你所有可获得的资源。

产品元素就是你要测试的东西。软件是如此的复杂和不可见，以至于你要特别小心的确保你确实测试了产品中需要测试的所有部分。

质量标准是允许你作为一个测试人员来判断产品是否有问题的准则、价值观和来源。质量标准是多方面的，并且经常是隐藏的或者是自相矛盾的。

测试技术是创建测试时使用的策略。所有的测试技术都包括对项目环境、产品元素和质量标准的某种分析。

看得见的质量是测试的结果。你永远不可能知道一个软件产品的“实际”质量，但是通过对应用的各种各样的测试，你能对其质量做一个比较准确的评估。

1. 常用测试技术

测试技术就是创建测试的方法，通过对一种或几种常用技术来组合，就可以构建成无数的特殊测试技术。

1.1. 功能测试（Function Testing）

测试系统能够完成的功能。

Ø 找出产品能够做的事情（功能和子功能）。

Ø 判断你将怎么才能知道一个功能是否能正常工作。

Ø 测试每个功能，一次测试一个。

Ø 看看每个功能是否做了应该做的，而没有做不应该做的。

1.2. 域测试（Domain Testing）

从产品的输出和输出的角度对产品进行测试。

Ø 分析产品的输入输出数据集。

Ø 判断测试的特殊值。考虑边界值，典型值，常用值，无效值，以及最具代表性的值。

Ø 考虑需要在一起测试的数据的组合。

1.3. 压力测试（Stress Testing）

征服产品，在规定的规格条件或者超过规定的规格条件下，测试一个系统，以评价其行为。

Ø 找出在挑战性的数据或者压倒性的资源面前对超载或者“破坏”敏感的子系统和功能。

Ø 辨识出与那些子系统和功能相关的数据和资源。

Ø 选择或生成测试所需的挑战性的数据或约束条件的资源：例如，大量或复杂的数据结构，高负载，长时间运行，大量的测试用例，低速存储器的情况。

1.4. 工作流测试（Flow Testing）

做完一件事再做另一件。

Ø 定义把具体的多个活动首尾链接起来测试过程或者高水平的用例。

Ø 在两个测试之间不要重置系统。

Ø 改变时间和顺序，并且尝试并发的线程。

1.5. 场景测试（Scenario Testing）

作为一个强制性的故事来测试。

Ø 首先，思考与产品关联的每一件事。

Ø 设计把产品中有意义的和复杂的相互作用包括在内的测试。

Ø 一个好的场景测试是一个关于一些人或事可能对产品进行怎样的操作故事。

1.6. 约束测试（Claims Testing）

验证每一条约束。

Ø 在产品的参考资料中辨识出其包含的约束（隐藏的或直接的）。

Ø 分析单个的约束，并明确比较含混的约束。

Ø 验证产品的每条约束是否是正确的。

Ø 如果你测试的依据是详细的规格说明书，就很值得使用这个技术，并且会把产品做的比较标准。

1.7. 用户测试（User Testing）

涉及了用户的测试。

Ø 分清楚用户的类别和角色。

Ø 判断每类用户会执行什么样的用例，怎样来执行，以及这样做的价值。

Ø 获得真实的用户数据，或者让真实的用户来测试。

Ø 否则，就要系统地模拟一个用户了（注意：想象你是一个用户很容易，但是实际上你并不是）。

Ø 非常有效的用户测试应该要涉及各种各样的用户和用户角色。而不是仅仅一个。

1.8. 风险测试（Risk Testing）

设想一个问题，然后去找到它。

Ø 这个产品会有哪些种类的问题？

Ø 哪种问题是最要紧的？关注那些问题。

Ø 如果真有这些问题，你将怎样来侦测？

Ø 做一个有趣的问题的列表，并特别设计一些测试来发现这些问题。

Ø 可能需要一些帮助，包括咨询顾问、设计文档、以前的缺陷报告、或者使用风险启发法。

1.9. 自动化测试（Automatic Testing）

运行大量不同的测试。

Ø 寻找适合自动的生成大量的测试的机会。

Ø 开发一套自动化的、高速评估的机制。

Ø 写程序来生成、执行并评估这些测试。

2. 项目环境

创建和执行测试是测试项目的核心所在。然而，在你决定要创建什么样特定的测试时，项目环境中有很多因素都是关键性的。对于下面的每个类别中的因素，都要考虑它们可能会怎样帮助或阻碍你的测试设计进程。试着利用好每一个资源。

2.1. 客户

这个测试项目中作为客户的任何人。

Ø 你知道谁是你的客户么？谁的意见要紧？谁从你做的工作中受益或者利益收到损害？

Ø 你同你的客户联系和交流过了么？可能他们对你的测试有帮助。

Ø 可能你的客户对你要创建和运行的测试有很强烈的想法。

Ø 可能客户之间对测试有相冲突的期望。你可能不得不帮着分析清楚并解决这些冲突。

2.2. 信息

关于需要被测试的产品或项目的信息。

Ø 有任何的可获得的工程文档么？用户手册？网上的资料？

Ø 这个产品有历史渊源么？有已经被修复或者遗留的老问题么？客户有经常抱怨什么？

Ø 在你知道怎么测试该产品之前，你需要更熟悉该产品么？

Ø 你的信息是最新的么？你怎样得知新的或者修改的信息？

Ø 看起来信息好像异乎寻常少的产品中有任何复杂或者富有挑战性的部分么？

2.3. 与开发人员的关系

你怎样同程序员相处。

Ø 傲慢型：开发团队看起来对于产品的任何方面都过于自信？

Ø 防卫型：产品中存在开发人员似乎很奇怪地反对进行测试的部分？

Ø 融洽：你同开发人员发展出了一种伙伴合作关系？

Ø 反馈环路：你能同程序员根据需要进行快速交流么？

Ø 反馈：开发人员对你的测试策略怎么想？

2.4. 测试团队

任何会执行或支持测试工作的人。

Ø 你知道谁会来测试这个项目？

Ø 有不在 “测试团队”中，但可能会有帮助的人么？有人以前测试过类似的产品，并可能提供一些建议么？作者？用户？还是程序员？

Ø 你有足够的有正确的技能来执行一个合理的测试策略的人么？

Ø 这个团队有没有基于一些特殊技能或者动机地需要，来刻意执行使用一些测试技术？

Ø 需要任何的培训么？可以获得一些什么培训？

2.5. 设备和工具

管理测试所需要的硬件、软件或者文档。

Ø 硬件：我们有执行测试所需要的所有的设备么？是否已经安装好，并准备运行了？

Ø 自动化：需要使用任何的自动化测试工具么？工具是否都准备好了？

Ø 探测器：在测试产品时，需要任何辅助性的工具来帮助我们观察么？

Ø 矩阵和一览表：有需要跟踪或者记录测试的进程的任何文档么？

2.6. 时间表

项目事件的顺序、持续时间和同步。

Ø 测试设计：我们有多少时间？这些测试晚一点创建是否会好一点？

Ø 测试执行：测试应该什么时候执行？是否有些测试要被重复的执行，比如说，在回归测试中？

Ø 开发：版本什么时候可以来测试，增加了功能，代码冻结，等等？

Ø 文档：用户文档什么时候可以评审？

2.7. 测试要素

被测试的产品对象。

Ø 范围：在你的测试职责范围中，包含产品中的哪一部分功能，不包含哪些？

Ø 可用性：你有需要被测试的产品么？

Ø 易变性：产品是否在不断的变化？再次测试时需要些什么？

Ø 新元素：最近，产品中新增或者修改了些什么？

Ø 可测试性：产品的功能和可靠性是否足够让你能有效的来进行测试？

Ø 将来的版本：你测试中哪部分，如果有的话，必须被设计来应用到产品的将来的版本中？

2.8. 可提交物

测试工程的可以看得见的提交物。

Ø 内容：你要提交哪种报告？你会分享你的工作记录，还是只有结果？

Ø 目的：你的提交物是不是作为产品的一部分？有别的其他人要运行你的测试么？

Ø 标准：你有要遵循的一些特别的测试文档标准么？

Ø 媒体：你要怎样记录和并与其它人交流你的报告？

3. 产品元素

一个产品，最终是要提供给客户一种体验或者是一个解决方案。产品是有很多尺度的。因此，为了获得好的测试结果，我们必须检验这些尺度。下面所列的每一类，都代表着一个产品的重要的并且是独一无二的一个方面。测试人员如果对这些方面关注得很少的话，很可能会错过很重要的Bug。

Ø 结构：构成产品本身的任何东西。

Ø 功能：产品能做的任何事情。

Ø 数据：产品处理的所有东西。

Ø 平台：产品所依赖的所有事物（并且也是你项目的外部环境）

Ø 操作：产品将会被怎样的使用。

Ø 时间：产品与时间之间的任何关系。

4. 质量标准类别

质量标准是一些定义产品应该是什么样的需求。通过对不同种类的标准的观察和思考，你会能够比较好的制定一个快速发现重要问题的测试计划。下面每一个列表中的条目都可以被认为是一个潜在的风险区域。对于下面的每一个条目，判断对于你的项目是否是重要的，然后思考你怎样得出产品是否运行得很好还是很差的结论。

4.1. 操作标准（Operational Criteria）

Ø 能力。是否能完成需要的功能？

Ø 可靠性。是否运行得很好并且在所有需要的情况下都不会失效？

出错处理：产品在出错的时候抵制失效，并很快恢复，这在失效时是非常棒的。

数据完整性：系统中的数据避免丢失或被破坏。

安全：产品失效也不会对生命和财产造成威胁和伤害。

Ø 可用性。对于一个真实用户来使用这个产品到底有多容易？

可学习：产品的预期用户能够很快的掌握其操作。

可操作：产品操作起来不会很费劲，也不会很麻烦。

可接近：产品接近相关的标准，并且与操作系统的相关标准比较接近。

Ø 安全。在保护产品不受到非法的使用或入侵上做得有多好？

证明：系统验证用户的确是她所说的那个人的方式。

授权：授予被证明的用户不同程度的权限级别的权利。

隐私：客户或雇员数据避免受到未授权的人的危害的方式。

安全漏洞：系统不能保证安全的方式（例如社会工程的脆弱性）

Ø 可度量。产品按照比例放大或缩小的部署表现得有多好？

Ø 性能。系统有多快的响应速度？

Ø 可安装。产品安装到目标平台上有多容易？

系统需求：如果一些必须的组件缺失或者无效，产品是否能够识别？

配置：系统的哪一部分会受到安装的影响？这些文件和资源都保存在什么地方？

卸载：当产品被卸载时，是否可以干净的移除？

升级：新模块或者版本是否能很容易的增加？它们是否不改变已有的配置。

Ø 兼容性。同外部组件和配置一起运行得有多么好？

应用兼容性：产品和其它软件产品一起运行。

操作系统兼容性：产品运行在特定得操作系统上。

硬件兼容性：产品运行在特定的硬件组件和配置上。

向后兼容性：产品同自身早期的版本一起运行。

资源利用：产品没有使用不必要的大量内存、存储空间，或者其它系统资源。

4.2. 开发标准（Development Criteria）

Ø 可支持性。是否可以很经济的为产品的用户提供支持？

Ø 可测试性。产品能够被如何有效的测试？

Ø 可维持性。是否可以很经济的对产品进行打包、修复或者增强？

Ø 可移植性。是否可以很经济在其它地方移植或重用该技术？

Ø 本地化。产品是否可以很经济的适用于其它地方，比如：

规则：是否有超越州或国家边界的不同的规则或报告的需求？

语言：产品能容易适应更长信息,从右到左或者表意字的字体么？

货币：产品能够支持多币种么？币种汇率呢？

社会或文化差异：顾客可以发现文化参考资料中有令人费解的或者侮辱的吗?

三、HTSM的应用

HTSM由一组指导性词语（guide word）组成，它们构成一个层次结构，让测试人员从高层抽象到底层细节对产品和测试进行思考。这些指导性词汇是测试的指南，其作用不是教导如何具体地测试，而是启发测试人员的思维，发掘测试对象和测试策略。

在定制化之前，HTSM对测试人员的帮助很小，因为此时的HTSM是“James Bach的模型”，而不是符合当前语境的模型。HTSM是通用的模型，虽然能够普遍使用，但是不能快速、高效地指导具体的测试工作。测试人员需要根据产品的属性需要将其“本地化”，才能发挥其威力。

点击阅读更多干货

ET的发展和演进

探索性测试 之 启发式测试策略模型

探索性测试之启发式测试策略模型