测试建模，以测试为目的建立产品模型。实际上，所有的测试都基于模型。
4.1从组合测试看建模的重要性
4.1.1组合测试简介
组合测试是一种测试用例生成方法。测试人员将被测对象抽象为一个受到多个变量影响的系统，其中每个变量的取值是离散且有限的。
两因素组合测试（也称配对测试、全对偶测试）生成的测试集可以覆盖任意两个变量的所有取值组合。
多因素组合测试生成的测试集可以覆盖任意N个变量的所欲取值组合。
为了按时完成测试，测试人员常用组合测试来生成规模较小的测试集。
4.1.2根据语境来完善组合测试的模型
本节介绍一些组合测试
可能遇到的问题，并讨论如何完善测试模型来解决问题。
问题1：组合测试的理论没有讨论如何建立其数学模型
如果测试设计
遗漏了重要的变量，那么组合测试也会
错失重要的测试用例；
确定每个变量的取值集合，如果变量值取值集合
不够好，组合测试的效果就会
大打折扣；
确定
检查方法，不严谨的检查可能
遗漏已经暴露的缺陷；
组合测试面临的挑战：纯粹的数学模型远离产品的业务模型和代码的实际模型，不能直接用于测试。测试人员需要完善组合模型，使之符合业务模型和实现模型。测试人员需要深入地研究业务领域、产品续期、代码实现、测试技术等内容，付出持续的努力且无捷径可走。
问题2：组合测试可能会
错过最重要的取值集合
如果测试人员不仔细分析产品，只依赖组合测试工具，可能
错过重要的测试用例。
应对办法：1、将默认设置对应的取值组合加入测试集；2、对于默认值，每次修改其中一个单选框，获得一批取值组合，将他们加入测试集；3、考虑到大多数用户不修改默认值或者只修改1个设置，测试用例集已经足够好，可以付诸测试。
问题3：组合测试的数学模型没有描述变量之间的
关系
组合测试数学模型中，每个变量的取值是相互独立的；但是，大多数被测对象的变量之间存在约束关系。
应对办法：PICT模型中，加入
约束语句，定义约束关系
问题4：组合测试用例可能被
卫哨语句处理
两个应对办法：1、将非法取值从模型中去掉，增加用例覆盖非法取值；2、PICT模型中
特殊符号标记非法取值，保证有效值会被覆盖，同时任意非法值与有效值的组合也会覆盖。
问题5：组合测试可能没有提供足够的测试
覆盖
两因素组合也许不能发现隐藏在“末枝”中的缺陷。因此，多因素组合覆盖可能进一步提高错误发现率。
问题6：全组合测试可能是
更好的测试策略
利用软硬件的强大性能，将测试模型替换为全组合测试可能更好；另一种接近全组合测试的方法是每次回归测试都使用全新的测试集；
4.1.3测试建模的基本点
合理的测试模型可以准确地描述产品，使测试更有针对性，且避免了测试遗漏和浪费。
多角度考察产品，重要的切入点包括业务领域、软件实现和项目环境。
业务领域：恰当的模型应该切合产品的业务领域；
软件实现：好的测试模型具有很强的针对性，能够清晰地描绘被测产品的特征；
项目环境：好的测试模型不一定复杂，但一定实用，能够切合当前项目环境，充分利用资源。
一方面，测试建模是一个持续的过程；另一方面，测试模型应该在测试小组中分享。模型的表达方式分为形式化模型和非形式化模型两种。形式化模型可以被工具软件读取；非形式化模型包括自然语言表达的文字、列表、草图等。模型的价值取决于发现缺陷的效率。可行的策略是构建一个简单的模型，用它指导测试设计，并根据测试反馈来改进它。在测试迭代中，模型会逐步成长，日趋成熟。
4.2常用测试建模方法
4.2.1启发式测试策略模型
测试人员需要一个相对完整、可以定制、容易扩展的风险列表或参考模型，来帮助他们发现产品风险。启发式测试策略模型（HTSM）是James Bach提出的一个结构化的、可定制的参考模型，从测试技术、产品元素、项目过程、质量标准等多个角度启发测试设计。
顶层元素（质量标准、项目环境、产品元素、测试技术）可以分解为次层元素，而次层元素可进一步分解为第三层元素。
测试技术：生成测试的策略。
功能测试；域测试；压力测试；流测试；情景测试；声明测试；用户测试；风险测试；自动测试；
项目环境：资源、约束或其他影响测试的元素。
使命；信息；开发者关系；测试团队；设备与工具；进度；测试条目；交付品；
产品元素：需要测试的对象。
结构；功能；数据；接口；平台；操作；时间；
质量标准：产品需要考虑的质量特性。
能力；可靠性；可用性；魅力；安全性；可伸缩性；兼容性；性能；可安装性；面向研发团队的特性；
HTSM对于测试设计的意义：
1、测试设计以
风险驱动；
2、测试设计时，质量标准启发
测试先知，项目环境启发
测试过程，产品元素启发
测试覆盖，观察到的质量启发
测试报告；
3、对于测试，HTSM强调测试策略的
多样性，
平衡代价和收益，利用启发式方法充分发挥测试人员的技能。
测试人员需要
修改它，加入自己的测试元素，才能真正掌握它；另一种方法是
综合HTSM中的多个元素，开发测试策略。
构建模型是
简化和聚焦的过程，应用模型则是
扩展和发散的过程。
4.2.2输入与输出模型
输入与输出模型是最基本的测试模型，它将被测对象视为一个整体，分析并列举该对象的
输入变量和输出变量。
输入方面，值得考虑的因素包括：
有意的输入；无意的输入；程序状态；系统状态；配置与系统资源；来自协作的进程、客户端或服务器的输入；
输出方面，值得考虑的因素包括：
被监控的输出；未被监控的输出；程序状态；系统状态；对相连设备和系统资源的影响；发给协作的进程、客户端或服务器的输出。
隐藏变量，供读者参考：
操作系统事件；设备事件；中断事件；用户输入方式；数据类型；数据大小；相对位置；容量；本地化和国际化；时间；
4.2.3系统生态图
测试一个
复杂的软件系统时，测试人员需要分析系统的内部结构、外部依赖和访问接口。测试人员可以绘制一幅图来描述系统的生态环境，综合了传统的语境图和部署图，可以帮助测试人员系统地探索整个系统。
测试专家Michael Bolton和James bach针对部署图，提出了一些测试指导词，对于测试设计有很高的参考价值，基本元素是节点、组件和路径。
节点是系统的组件，是测试设计的基本对象。
缺失和退出；额外和干扰；错误；时间和顺序；内容和算法；条件行为；局限；错误处理；
线条连接了组件，测试人员需要针对组件之间通信设计测试。
缺失和退出；额外和分支；错误；时间和顺序；状态通信；数据结构；
路径是线条构成的通路。
最简单；常用的；关键的；复杂的；病态的；挑战的；错误处理；周期的；
4.2.4实体关系模型
实体关系模型（ER）是一种
数据库建模方法。广泛地用于关系型数据库的分析和设计，并被推广到普通软件的数据分析。
实体是系统中的名词，代表了业务领域的一类对象，这些对象拥有独立的含义和可被识别的标识。
关系往往视为动词，联系了两个或多个实体。
黑盒测试的角度看，测试人员可以使用ER模型来建立软件的数据模型。获得ER模型后，测试人员可以综合使用CRUD、出租车漫游、快递漫游、沙发土豆漫游等手段来实施测试。
4.2.5状态机模型
状态机是一种常见的软件建模方法，是基于模型测试的重要技术之一。
获得状态图之后，测试人员可以从以下角度设计测试用例。
设计测试用例以覆盖所有状态；设计测试用例以覆盖所有状态变迁；设计测试用例以覆盖所有触发事件；
状态机建模第一步是
识别状态。
参考以下技巧，识别软件状态。
如果软件展现了新的界面，允许执行更多的命令，那么它进入了另一个状态；如果软件展现了新的界面，可执行的命令变少，那么它进入了另一个状态；如果相同的操作导致了不同的结果，那么软件进入了另一状态；分析需求文档和用户界面，寻找“当...的时候”“在...之后”“在...之前”的表述，常常暗示软件处于特定的状态；如果软件显示等待提示符或进度条，那么软件正在进行某项任务，这段时间可以看作一个状态。
测试人员还需要发掘
隐藏的变迁，以下是一些基本的观察点：
用户命令会触发变迁；软件自身会触发变迁；软件的外部环境会触发变迁；时间会触发变迁。
在整个建模过程中，测试人员可以考虑如下策略来加速探索和测试：
使用出租车漫游和出租车禁区漫游来发现更多的状态和变迁；状态图是一种联通图，状态和变迁构成了一组路径，可以参考路径测试指导词来测试系统；程序员在编写代码时，常常会忽略一些可能发生的事件，从而导致软件不能应对复杂的应用场景，为此，测试人员考虑打断该状态会不会导致故障；当测试人员获得一个相对完整的状态图后，可以将其转化为状态表；
4.2.6多种多样的模型
测试人员需要多种模型，从不同角度考察软件。
可视化头脑中的模型是更好的策略。
记录模型可以帮助模型的演化，简单的模型在测试过程中会发展成丰富的模型；
一些测试模型可以应用于多个测试对象和产品，记录并复用这些模型能够提高测试效率；
将模型记录下来，可以将它分享给测试小组；
用纸笔、思维导图软件等工具，测试人员可以灵活地记录模型；
从测试建模的角度：
第一、所有的模型都是对软件的
简化，是片面的、不完整的；
第二、正因为模型总是
不完整的，测试人员不必追求完美的模型；
第三、在注重实用性的前提下，测试人员需要发现并消除模型的
错误；
4.3小结
不论测试人员是否有意识的建模，任务测试都基于模型，然而，认真去构建好的模型将提高测试过程的质量。
测试建模的基本任务是建立被测对象的模型，以帮助理解软件和设计测试。
纯粹的通用模型远离业务领域和设计实现，需要做因地制宜的改良，才能发挥作用。改良的基本方法是使用业务需求、产品元素、项目环境的信息去丰富和调整模型。
构建模型需要简化和聚焦，使用模型需要扩展和发散。
好的测试模型必须经过测试迭代的淬炼。
本质上，所有的模型都是错的，但是有些是有用的。
不要追求完美的模型，要创建注重实效的模型。模型是测试设计的工具，好的模型将有力支持测试设计。
不要依赖单一的模型，要综合多个模型，以避免认知偏差，不要完全信赖任何模型，要通过测试去质疑并改进模型。
启发式测试策略模型是一个指导测试设计和风险分析的概念框架，测试人员需要根据项目语境对其进行裁剪和丰富。
在测试中，功能列表（针对软件能力）、输入与输出模型（针对软件与外界交互）、系统生态图（针对软件结构）、实体关系模型（针对数据关系）、状态机模型（针对软件状态）、质量特性列表（针对多样化的质量）等是常见的测试模型。
测试人员可以针对特定领域或测试对象开发出多种多样的模型。
条件分析是一种启发测思路的常见方法。