[ 测试思维 ] 转载：启发式测试策略模型(HTSM)

Posted 2020-10-03 Beng Dou

什么是HTSM    

  启发式测试策略模型（Heuristic Test Strategy Model，简称HTSM）是测试专家James Bach提出的一组帮助测试设计的指南（Guide line）。HTSM由一组指导性词语组成，它们构成一个

层次结构，让测试人员从高层抽象到底层细节对产品和测试进行思考。

为什么需要HTSM

  HTSM中指导性词汇是测试的指南，其作用不是教导如何具体地测试，而是启发测试人员的思维，发掘测试对象和测试策略，重点在于"启发式"。HTSM对于测试设计的意义：

  （1）测试设计以风险驱动。测试人员分析质量标准、项目环境、产品元素中的风险，设计有针对性的测试策略。

  （2）在测试设计时，质量标准启发测试先知（Oracles），项目环境启发测试过程（Procedures），产品元素启发测试覆盖（Coverage），观察到的质量启发测试报告（Reporting）。

  （3）对于测试，HTSM强调测试策略的多样性（Diversification），平衡代价和收益（Cost vs. Value），利用启发式方法（Heuristics）充分发挥测试人员的技能（Skill）。

 

HTSM的内容

 

    上图是HTSM的概要描述，测试人员利用质量标准（Quality Criteria）、项目环境（Project Environment）、产品元素（Product Element），指导测试技术（Test Techniques）的选择与应

用，并产生观察到的质量（Perceived Quality）。

    HTSM是层次结构，其顶层元素（质量标准、项目环境、产品元素、测试技术）可以分解为次层元素，而次层元素可进一步分解为第三层元素。本文只概要介绍次层元素，更多的细节请参考

James Bach的文档。

测试技术：生成测试的策略。有效地选择和实施测试技术，需要综合分析项目环境、产品元素和质量标准。

 功能测试(Function Testing):测试系统能够完成的功能。

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

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

  （3）测试每个功能，一次测试一个。

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

域测试(Domain Testing)

  （1）分析产品的输入输出数据集。

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

  （3）考虑需要在一起测试的数据的组合。

压力测试(Stress Testing)

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

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

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

工作流测试(Flow Testing)：做完一件事再做另一件。

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

  （2）在两个测试之间不要重置系统。

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

场景测试(Scenario Testing)：作为一个强制性的故事来测试。

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

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

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

约束测试(Claims Testing)：验证每一条约束。

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

  （2）分析单个的约束，并明确比较含混的约束。  验证产品的每条约束是否是正确的。

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

用户测试(User  Testing)：涉及了用户的测试。

  （1）分清楚用户的类别和角色。

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

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

  （4）否则，就要系统地模拟一个用户了（当心――想像你是一个用户很容易，但是实际上你并不是）。

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

风险测试(Risk Testing)：设想一个问题，然后去找到它。

  （1）这个产品会有哪些种类的问题？

  （2）哪种问题是最要紧的？关注那些问题。

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

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

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

自动化测试(Automatic Testing)：运行大量不同的测试。

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

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

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

 

项目环境：资源、约束和其他影响测试的项目元素。测试总是受到项目环境的约束。在某个团队运转良好的策略不一定适合另一个相似的团队，以往富有成效的方法未必适应当前的项目。有经验的

测试人员会根据当前语境（Context），在约束条件下充分运用资源，以高效地测试。

用户(Customers)：这个测试项目中作为客户的任何人。

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

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

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

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

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

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

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

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

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

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

开发者关系(Developer Relations)：你怎样同程序员相处。

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

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

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

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

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

测试团队(Test Team)：任何会执行或支持测试工作的人。

  （1）你知道谁会来测试这个项目？

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

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

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

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

设备与工具(Equipment & Tools)：管理测试所需要的硬件、软件或者文档。

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

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

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

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

进度(Schedule)：项目事件的顺序、持续时间和同步。

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

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

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

  （4）文档：用户文档什么时候可以评审？

测试项(Test Items)：被测试的产品对象。

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

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

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

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

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

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

交付件(Deliverable)：测试工程的可以看得见的提交物。

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

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

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

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

产品元素：需要测试的对象

 结构(Structure): 构成产品本身的任何东西。

  （1）代码。构成产品的代码结构，从可执行到独特的例程（from executables to individual routines）

  （2）接口。子系统间连接和通讯的点。

  （3）硬件。对产品必不可少的任何硬件组件。

  （4）非可执行的文件。与多媒体和程序不同的任何文件，例如文本文件，样品数据，或者帮助文件。 

  （5）附属品。产品中除了软件和硬件之外的任何其它部分，例如纸质文档，Web链接和内容，包装，许可声明，等等… 

功能(Functions)：产品能做的任何事情。

  （1）用户界面。用来给用户交互数据的任何功能（例如，浏览器，显示界面，数据输入窗口）。

  （2）系统接口。用来给不同于用户的其它事物交互数据的任何功能，例如，其它程序，硬件，网络，打印机，等等。

  （3）应用。用来定义或区分产品或者实现核心需求的任何功能。

  （4）算法。任何计算的功能或者算法的操作嵌入在其它功能里面的。

  （5）与时间有关的。暂停时间设置；每日或每月报告；每晚的批处理作业；时区；商业假日；利息算法；条款和担保期；以及要求精确的功能。

  （6）改变。修改或改变某些东西的功能（例如，设置字体，插入剪贴画，从账户中取钱）

  （7）startup/shutdown。启用和初始化或者退出产品时需要用到的任何方法与接口。 

  （8）多媒体。声音，图片、视频、或者嵌入在产品中任何图形化的显示。

  （9）出错处理。侦测错误并从错误中恢复的任何功能，包括所有的错误信息。

  （10）集成交互。产品的功能之间的任何交互或接口。

  （11）可测性。提供的可以用来帮助测试的任何功能，例如诊断(diagnostics)，日志文件，断言，测试的菜单，等等

数据(Data)：产品处理的所有东西

  （1）输入。产品要处理的任何数据。

  （2）输出。产品处理过的结果数据。

  （3）预设值：作为产品的一部分提供的任何数据，或者直接在产品中创建的数据，例如初始化数据库，系统默认值，等等。

  （4）配置项：任何内置的并且会在多个操作持续使用数据。包括产品的状态或样式，例如参数设置，视图模式，文档目录，等等。

  （5）数据排序：数据的任何顺序或排列，例如文字的排序，分类或未分类的数据，测试顺序。 

  （6） 数据规模(Big and little)：数据的大小和聚集的变化量。 

  （7）异常数据：以不受控制或不正确的方式产生的无效的、被破坏掉的、或者产生的任何数据或者状态。

  （8）生命周期：在数据实体的整个生命周期中的变化，包括创建、访问、修改和删除。

平台(Platform)：产品所依赖的所有事物

  （1）外部硬件。并不是要交付的产品的一部分，但是是为了保证产品运行的必须的硬件组件和配置（或者是可选的）：CPU，内存，键盘，外设，等等。

  （2）外部软件。并不是要交付的产品的一部分，但是是为了保证产品运行的必须的软件组件和配置（或者是可选的）：

  （3）操作系统。同时执行的应用程序，驱动，字体，等等。

  （4）内部组件。被嵌入在你的产品中，但是不是由你的项目生产的库或者其它组件。既然你不能控制它们，你必须决定如果它们失效了该做些什么来解决问题。

操作(Operations)：产品将会被怎样的使用

  （1）用户：各种不同的用户的属性。

  （2）环境：产品操作所在的物理环境，包括例如噪音、灯光、和分心的事物这样的元素。

  （3）正常操作(Common Use)：产品输入的模式和顺序可能会与通常的使用习惯冲突。这根据用户的不同而不同。

  （4）异常操作(Disfavored Use)：由不了解、误解、不小心或者恶意的使用产生的输入模式。

  （5）极端操作(Extreme Use)：挑战与产品期望的使用方法一致的输入模式和顺序。

时序(Time)：产品与时间之间的任何关系。

  （1）输入/输出：什么时候提供输入，什么时候创建输出，以及他们之间的时间联系（延迟、间隔，等等）。

  （2）快/慢：用“快速”输入或者“慢速”输入来测试；最快和最慢；快和慢结合起来测试。 

  （3）变化率：加速和减慢（峰值、突然爆发、中止、瓶颈、中断）。

  （4）并发：一次发生超过一件事情（多用户，分时，线程、信号、和共享数据）。

 

质量标准之操作性标准（Operational Criteria）：面向用户和运营团队

能力(Capability): 产品是否能完成需要的功能

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

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

  （2）数据完整性。业务数据避免丢失或者被破坏

可用性(Usability): 对于一个真实用户来使用这个产品到底有多容易？

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

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

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

安全性(Security): 在保护产品不受到非法的使用或入侵上做得有多好？

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

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

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

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

可伸缩性(Scalability): 产品按照比例放大或缩小的部署表现得有多好？

性能(Performance): 系统有多快的响应速度？

可安装性(Installability): 产品安装到目标平台上有多容易？

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

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

  （3）卸载。当产品被卸载时，是否可以干净的移除？

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

兼容性(Compatibility): 同外部组件和配置一起运行得有多么好？

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

   （2）OS兼容性。产品运行在特定得操作系统上。

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

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

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

 

质量标准之开发标准（Development Criteria）：面向开发团队

可支持性(Supportability): 是否可以很经济的为产品用户提供支持？

可测试性(Testability)：产品如何能够被有效的测试？

可维护性(Maintainability)： 是否可以很经济的对产品进行打包、修复或者增强？

可移植性(Portability)： 是否可以很经济在其它地方移植或重用该技术？

本地化(Localizability)： 产品是否可以很经济的适应其它地方？

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

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

  （3）货币。产品能够支持多币种么？币种汇率呢？

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