本文主要是介绍JamesBach启发式测试策略模型，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
1 概述
启发式测试策略模型（Heuristic Test Strategy Model，简称HTSM，以下使用HTSM），是JamesBach提出的（JamesBach曾经做过开发，后来转测试，是探索式测试、语境驱动测试学派的主要提出者、支持者，是测试领域的思想先驱），而HTSM自然也带有这位前辈的思想印记。从整体看，HTSM可以用下图表达：
HTSM模型
这个模型包含5个节点：大意是需要根据质量定义（Quality Criteria），项目环境（Project Environment），产品元素（Product Elements）选择测试技术（Test Techniques）进行测试，最终我们能够得到的是可感知的质量（Perceived Quality）。
2 测试技术
测试技术指的是为创建测试而进行的探索方法，是对HTSM模型中的项目环境、产品元素、质量定义的分析。以下列出9种“通用技术”。“通用技术”的含义是指这项技术是简单且可以广泛使用。很多特定的测试技术是基于一项或多项“通用技术”的。并且，这些“通用技术”能够与HTSM模型中其他模块的想法结合来产生更多的测试技术。
2.1 功能测试：测试它能做什么
1 产品能做哪些（功能和子功能）
2 你是如何判断一个功能是有效的
3 一次只测试一个功能
4 确认每项功能做了它该做的，并且没做它不该做的
2.2 领域测试：划分数据
1 关注产品处理的任何数据。盯紧输入和输出
2 决定测试使用的特定数据，考虑边界值、典型值、有效值、无效值、最具代表性的数据。
3 考虑将需要测试的数据进行组合
2.3 压力测试：使产品超负载
1 寻找在具有挑战性数据或者资源受限下，最脆弱的子系统和功能
2 识别与这些子系统和功能相关的数据和资源
3 选择或生成挑战性数据或者资源受限的条件进行测试。例如：大量或复杂的数据结构、高负载、长时间运行、大量测试用例运行、小的内存
2.4 流测试：按部就班
1 测试由多个处理步骤相连的流程，例如将某个状态模型走一遍
2 在相关操作或处理间不要重设系统
3 使时序发生异常，并且使用并发的线程
2.5 场景测试：测试用户故事
1 以围绕产品的方方面面进行思考为起点
2 设计真实和完整的交互过程的测试用例
3 好的场景测试是真实用户与产品交互的故事
2.6 要求测试：挑战每项要求
1 确认对产品的各项要求，包含显性和隐性的。例如：SLA条款、广告说明、特殊说明文档、帮助手册等
2 分析要求条款，使不明确的要求清晰化
3 测试软件是否与要求相符
4 如果你的测试有明确的说明要求，将其设为标准并测试软件。
2.7 用户测试：使用者测试
1 明确用户类别和角色
2 明确每一类用户将如何使用产品，他们认为产品的应该给他们带来的价值是什么
3 获取到真实用户的数据，或者将他们引入测试
4 否则，需要系统性地模拟用户。注意，这很容易错估用户的使用情况。
5 有效的用户测试需要包含一定量的用户和用户角色，而不是一个用户。
2.8 风险测试：想象一个问题，找出它
1 产品可能出现哪些问题
2 哪些问题是重要的。关注它们
3 当问题发生时，你如何发现问题
4 列出风险问题，并对其设计测试
5 咨询专家、参考设计文档、过往问题报告或者探索风险，将会有所帮助
2.9 自动检查：检查不同的事实
1 寻找或开发能够辅助测试活动的工具
2 考虑自动化的执行、测试结果检查、测试覆盖检测、变化监测、测试数据生成等工具
3 考虑能够使测试人员工作更有效的工具（不一定是开发或者测试工具）
3 项目环境
创建和执行测试是测试过程的核心。项目环境就是在测试过程中，那些会促进或阻碍测试活动的资源或约束条件。有时测试人员必须突破那些约束，有时也需接受它们。
3.1 任务：就你和你的客户所理解的测试目标
1 你是否知道你的客户是谁？谁的看法具有影响力？谁能从你的工作中获益？
2 你是否知道你的客户对你的在项目中的期望是什么？你是否认同这种期望？
3 也许你的客户对你需要测试哪些东西有自己的主张
4 也许他们之间（你的客户们）的期望是相互冲突的。你需要理顺它们。
3.2 信息：关于需要进行测试产品或项目的信息
1 可向谁咨询去了解这个项目
2 有哪些可用的项目文档？用户手册？在线文档？说明文档？用户故事？
3 这个产品是否有来历？已经修复或未解决的一些老问题？客户的投诉抱怨？
4 你的信息是最新的吗？你是如何知道新的或者变更的信息？
5 是否有可比性的产品或项目能够提供一些有用的信息？
3.3 开发者关系：你如何与程序员相处
1 开发团队是否表现出对产品的过度自信？
2 是否有哪个产品部分是开发者抵制进行测试的？
3 你与开发人员是否有良好的工作关系？
4 在需要时，你与开发人员是否能快速顺畅地沟通
5 开发人员对你的测试策略的看法如何？
3.4 测试团队：需要进行测试的每一个人
1 谁将开展测试？人手够吗？
2 哪些不是测试团队的人也能帮忙？经历过类似项目的人也许能提供一些建议
3 是否有要求测试人员拥有特殊技能或原因才会使用的特定的测试技术？
4 是否需要训练测试人员？是否有训练条件？
5 有哪些协作者？时区是否会成为一个问题？
3.5 设备和工具：硬件、软件或文档
1 是否有测试所需的设备？设备是否可用？
2 是否需要测试工具？工具是否可用？
3 处于测试时，是否需要工具来辅助检查产品的情况？
4 是否需要用文档来记录和追溯测试过程？
3.6 计划：顺序、持续期间、项目事件的同步性
1 你是否有充足的测试设计时间？是否有些测试晚一些设计比较好？
2 测试将何时执行？是否有些测试需要被重复执行，作为回归的目的？
3 哪些构建版本是可进行测试的、添加了新特性的、已封版的？
4 何时用户文档可以被查阅？
3.7 测试项目：被测的产品
1 产品哪些部分是在你的测试责任范围内，哪些不是？
2 你是有可测的产品了？测试平台是否可用？何时能得到新的构建版本？
3 产品是否处于不断地变更中？哪些需要被重新测试？
4 产品最近有哪些变更？
5 产品是否有充足的功能性和可靠性，能让你有效测试？
6 哪些测试需要被设计以便应用于将来发布的新特性的测试中？
3.8 交付物：测试过程中的可观察产品
1 你须要做哪些报告？你会分享你的工作日志还是最终的结果？
2 你的交付物是否作为产品的一部分？是否有其他人要运行你的测试？
3 你是否要遵循特定的测试文档标准？
4 你如何记录和交流你的报告？
4 产品元素
产品元素是指那些你需要进行测试的东西。软件产品是提供给用户的问题解决方案，具有复杂性和隐蔽性——软件产品有多个维度。测试需要覆盖产品的多个维度，测试那些重要的，而不仅是哪些容易观察到的。
4.1 结构：产品的组成部分
1 代码结构
2 硬件结构
3 非可执行文件，例如：多媒体文件、帮助文档等
4 附属产品，例如纸质文档、在线文档、打包文件、许可证书等
4.2 功能：产品做的每一件事
1 应用：产品的核心需求的功能
2 计算：产品功能中的算数功能或操作
3 时间相关：超时设定、每日或月末报告、夜晚批处理、时区、工作日节假日、利息计算、项目或权限有效周期、计时功能
4 变化：修改或变更某些东西，例如改变账户余额、修改订单状态等
5 启动和关闭：在请求、初始化以及退出服务时，注意方法和接口的处理
6 多媒体：声音、位图、视频等
7 错误处理：功能对错误的检测、从错误中如何恢复，还有错误的信息提示
8 交互：各服务、接口间的交互通讯
9 可测性：辅助测试的功能，例如诊断功能、日志文件、断言等
4.3 数据：产品处理的那些东西
1 输入：产品处理的输入数据
2 输出：产品的处理结构
3 预置：作为产品的一步的数据或者内置的数据，例如：数据库、程序中写死的或配置的默认值
4 持久：需要存储的数据，像记录、样式、状态等
5 顺序／组合：有序的数据，例如：字母顺序、已排序的数据等
6 基数：对象的个数或值域，例如取值范围从1到9，有限个枚举，唯一性
7 大和小：数据的变化区间和集合的最大最小值
8 杂音：无效或具有破坏性的数据、产生于不受控制的或错误的处理过程的数据。
9 生命周期：必须覆盖数据从生成、读取、修改、删除的生命周期。
4.4 接口：产品可用的通道
1 用户接口：让用户可以改变数据的元素，例如操作面板、按钮等
2 系统接口：与其他系统、磁盘、网络等交互的接口
3 api/sdk：可编程的接口或工具
4 导入／导出：可以提供打包数据的功能，导入其他数据的功能
4.5 平台：产品所依赖的
1 硬件：为了使产品能够提供服务的，非产品本身需要的硬件设备。例如负载均衡器、网络交换器、加密机等
2 软件：为了使产品能够提供服务的，非产品本身需要的软件设施。例如操作系统、驱动程序等
3 其他组件：库或者组件，是产品提供服务所需但产生于项目外部的。
4.6 操作：产品将如何使用
1 用户：每类用户使用产品的特征是什么
2 环境：产品将被使用的物理环境怎样？噪音、灯光、网络情况（APP测试特别需要关注）
3 通常的使用：产品通常遇到的输入的形式和操作顺序
4 不受欢迎的使用：不在意的、错误的、恶意的输入形式和操作顺序
5 极端的使用：具有挑战性的输入形式和操作顺序
4.7 时间：产品与时间的关系
1 输入输出：什么时候输入，什么时候输出，输入输出间延迟多少
2 快和慢：使用“快”和“慢”的输入操作
3 改变速率：一会快一会慢，例如平缓加快输入、突然加大输入、挂起处理导致瓶颈、中断操作）
4 并发：多用户、时间片、多线程、信号量、共享数据
5 质量定义
质量定义是定义了产品应该是什么样的需求条款，是测试人员能够更好地计划测试、更快速地发现重要问题、判断产品是否有问题的依据。质量定义通常是多个维度的、隐蔽的、甚至自相矛盾的。
5.1 能力：它是否能按照要求运行
要求：功能、性能
5.2 可靠性：在需要的场景下，是否能正常运行，防止失败
1 健壮性：在合理的条件下，产品持续运行而没有崩溃
2 错误处理：当发生错误时，产品能防止失败，优雅降级，从错误中恢复
3 数据完整性：系统中的数据应受到保护，防止丢失或污染
4 安全性：产品应当不会危及人的生命和财产安全
5.3 易用性：对真实用户来说有多简单
1 学习性：目标用户能够快速学会使用
2 操作性：能够以最小的付出完成操作
5.4 吸引力：产品有多吸引人
1 美学：产品对感观产生的吸引力
2 独特性：在一定程度上，产品是新颖的或者独特的
3 必备性：产品拥有用户特别期望的某种能力
4 有用性：产品能很好地解决某些重要问题
5 粘性：能使用户着迷、获得乐趣，完全融入其中
6 想象性：产品投射出用户的某种渴望
5.5 安全性：产品如何抵抗非授权使用和干扰
1 认证：系统确认用户身份的方式
2 授权：已认证的用户所拥被赋予的权限
3 私密：用户数据应受到保护，防止未授权的访问的
4 安全漏洞：系统不能保证安全的地方
5.6 扩展性：系统部署规模能否平滑扩大或缩小
5.7 匹配性：产品能否和外部组件和配置协同工作
1 应用匹配性：产品与其他软件系统协同工作
2 操作系统匹配性：产品与特定操作系统协同工作
3 硬件匹配性：产品与特定硬件协同工作
4 向后兼容：产品与老版本协同工作
5 资源使用：产品不会独占内存、磁盘和其他系统资源。
5.8 性能：运行效率与响应速度
5.9 安装性：在目标平台上，是否容易安装部署
1 系统要求：当必要的组件或资源丢失或不满足时，产品是否自动能识别
2 配置：安装后对系统哪些地方会产生影响？文件和资源存储在哪？
3 卸载：当产品被卸载后，是否能移除干净？
4 升级／补丁：是否容易添加新模块或升级新版本？是否会对已有配置造成影响？
5 管理：安装是否需要特定的人员角色或时间计划
5.10 开发：能否顺畅地进行开发、测试和修改产品
1 支持性：为用户提供支持需要花费多少成本
2 可测性：产品是否能有效地被测试
3 维护性：构建、修复和增强产品需要花费多少成本
4 可移植性：移植或复用技术的成本
5 本地化：在其他地方使用产品时，需要调整的成本
这篇关于JamesBach启发式测试策略模型的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
