测试，没有分析与设计就失去了灵魂；
测试人员在编写用例之前，该如何进行测试分析与设计呢？上次在《测试的底层逻辑》中讲到了【输入输出测试模型】，还讲到了【2W+1H 测试分析法】，但 2W1H 分析法是初步的分析方法，具体在测试中如何落地，还需要更细的设计。
今天就给大家介绍一下由测试领域专家 James Batch 总结的测试分析与设计模型，HTSM 启发式测试策略模型。
什么是 HTSM？
HTSM 是一套测试思路启发的方法，旨在帮助测试人员更好地思考测试策略，指导测试人员在进行测试分析和设计的时候如何去思考，思考哪些点。HTSM 包括四个重点领域：测试技术、项目环境、产品元素和质量标准。James Batch 建议：你可以随意地使用它们，它对任何类型的软件都是通用的，另外在落地应用的时候，建议根据实际场景调整模型的内容，以适应自己的组织环境。
James Batch 原文解释：The*Heuristic Test Strategy Model*is a set of patterns for designing and choosing tests to perform. The immediate purpose of this model is to remind testers of what to think about during that process.
下面是 HTSM 和 2W1H 分析法进行的对比，通过对比可以看出 HTSM 可以与 2W1H 进行对应，通过分析项目环境，了解为什么测试这个项目，了解项目背景；通过分析产品元素，确定了我们的测试范围，明确我们要测什么；然后通过测试技术和质量标准指导了我们该怎么去测。
HTSM 与２W１H 对比：
HTSM 模型概览：
在 HTSM 模型中，项目环境、产品元素、质量标准、测试技术每一项都列出了很多子项；其中【项目环境】和【产品元素】不需要按照模型提供的子项进行全量的分析，所以大家可以作为参考，挑选对自己有用的信息进行分析即可。
我也会结合自己的经验增加一些内容；【质量标准】和【测试技术】参考的价值会更大一些，我对原文进行了详细的翻译；因为只是模型，所以作者也不会对每一种测试方法或测试标准进行详细的讲解说明，只是作者根据他的经验进行的总结，大家都可以结合自己的经验总结更具体的方法；但测试技术和质量标准的每一个子项是可以作为测试人员进行测试设计的参考标准，质量标准也可以参考 ISO9126 软件质量模型。
总之，模型不是详细的知识讲解，而是指导大家进行测试分析和设计的思路方法集合。
ISO9126 软件质量模型
下面分别讲解 HTSM 的四个领域：项目环境、产品元素、质量标准、测试技术。大家也可以按照这个顺序去使用 HTSM，按照 2W1H 的方法去分析，参考 HTSM 提供的子项和经验，最终形成完整的测试方案。
测试第一步：【项目环境】，测试之前一定要先了解项目背景，了解我们为什么做这个项目？
项目产生背景：为什么要做这个项目？项目产生的背景原因是什么？
所解决的问题：这个项目解决了什么问题？
通过了解背景，能够更好的帮助我们分析需求，了解最原始的需求和目的；了解了最原始的需求，才能去分析 PRD 中的功能设计是否能够满足用户最原始的需求，也才能更好的理解业务，理解需求，从而可以去挖掘需求文档中存在的问题或不足。
项目所属级别：是战略项目？还是技术维护升级项目？了解项目的级别也就是重要程度，也决定了我们应该投入的资源；对质量的要求是什么级别，用户对质量的要求是什么样的。
项目期望完成的时间：对完成时间的了解，可以决定我们后续会采取什么样的测试策略，哪些测试方法是必须采用的，哪些可以不用或者上线后再使用等等。比如时间特别紧张，最重要的还是要保障功能，其他性能可以根据上线的方案决定；是一上线就会有大量用户使用还是只有少部分种子用户；兼容性是否可以上线后进行，还是说针对 C 端的，兼容性必须保障；自动化测试可能就无法做了，也或者自动化技术已经非常成熟，有录制相关的工具，且经验丰富，那这个时候自动化录制工具或录制回放工具就可以起到很大的作用。
系统用户情况：系统的用户是谁？用户量有多大？关注用户量，第一是了解系统是否有性能压测方面的需求，第二是了解系统的用户量级是几个，几十个、几百个人还是成千上万？用户的数量不同，他的价值必然不同。
系统客户是谁：系统的客户是谁？客户最原始的述求是什么？
下面的是 HTSM【项目环境】的具体内容，部分内容我做了补充和调整。
测试第二步：【产品元素】，就是我们计划要测试的内容；测试人员必须保证覆盖所有的产品元素，而且不仅仅是我们所看到的部分。
产品最终就是为客户提供的一种经验或解决方案；产品有多个维度，要测试好，我们覆盖的维度必须要全面。每一个维度都代表了产品独特的一个面。如果测试只是覆盖了一部分，就有可能错过严重的 bug。分析产品的元素，就是分析我们的测试范围，有哪些方面或内容是需要我们测试的。一般人确定测试范围都来自于需求文档，其实需求文档之外还有很多东西需要我们关注，需要我们测试。下面是 HTSM 的【产品元素】：
HTSM 模型【产品元素】列出的内容比较多，也比较复杂，这些内容可以作为我们的参考，绝不是要求完全按照下面的内容进行测试。
Structure 结构：产品所包括的一切；
这一部分我觉得是我们最容易忽略的，我们大部分时间都是在测试软件，硬件部分很容易忽略；另外容易忽略的就是非执行文件，例如帮助文档、许可协议等，这些虽然很多都是业务提供，但出于对公司负责、对产品负责、对用户负责，我们还是需要再检查一下这些非执行的文档；帮助文档是否简单易懂，是否有缺失，是否有错误或与系统功能不符；因为上线前对系统最熟悉的不是产品经理，也不是研发，而是测试人员。
另外分享一下我的一些经验；首先，测试范围的确定是非常重要的，大部分人会忽略这一步，这样就有可能会导致漏测。这一步容易忽略，是因为我们的测试依据就是 PRD，所以测试范围都在 PRD 里；但实际情况是，大部分测试范围都在 PRD 里，还有一部是在设计文档中，或者在文档之外。
对于从 0 开始的新项目，可以从两个角度去考虑测试范围：
一、产品角度，通过分析 PRD 基本就够了；当然有些内容 PRD 可能也会疏忽遗漏，我们就需要对需求进行分析，挖掘出可能存在的隐性需求。
二、技术角度，除了用户看到的可以操作的功能，有些功能是用户无法直接用到的，或者是给其他系统技术开发用户使用的；例如对外提供的接口服务、系统后台异步处理的任务、定时执行的任务、上线前刷的基础数据、前置数据等。
从 1.X 到 1.（X+1）或 2.0 的升级维护项目：
除了正常的测试范围评估，最重要也是最难的就是回归测试范围的评估了，也就是对原有系统的影响范围是最难评估的。
对于回归测试范围的确定，其实就是成本与质量的博弈；对于质量要求非常高的软件，每一次测试都会要求进行全量的回归，所以这种场景下，自动化回归测试是非常重要的；对时间要求非常紧急质量风险可承受或可控的，回归范围可以缩小到本次修改的相关功能即可；但大部分场景是时间要求比较紧，但质量也不能出现问题。这时如何圈定范围，首先是本次修改的相关功能的回归必不可少；其次就是要守住系统的底线，也就是确定这个系统哪些功能是不能出问题的，这些功能就需要作为这个系统每一次回归的必选范围。另外还可以通过代码 diff 的功能，分析本次改动点，影响到的功能。
除了功能回归范围的评估，对于升级项目，一定要注意对原有数据的兼容验证；大概有以下几种情况：
1）功能变化，对原有进行中的数据的操作是否会影响；
2）流程变化，对流程中的数据或驳回重新提交的数据是否可以正常进行；
3）数据传输对象（PO、VO、DTO 等）发生变化，进行中的数据或重新编辑后的数据是否能正常操作，最主要时要验证数据的传输或存储。
4）底层数据库表发生变化，是否影响原有数据的展示、操作；新增字段是否需要刷数；刷数后功能是否正常。
测试第三步：【质量标准】，确定具体的测试策略，明确系统应该进行什么类型的测试；
质量标准就是产品定义的应该满足的一些要求，测试人员判断一个系统是否验证通过的规则；通过考虑不同类型的标准，你可以更好地规划测试，并可以快速发现重要问题。下面的每一个类型都可以被视为是潜在的⻛险区域。
功能性（Capability）：系统功能是否正确，是否满足了用户需求？
可靠性（Reliability）：在任何情况下是否都可以正常工作？
- 健壮性（容错性）：系统在出现故障时，是否能够自动恢复或者忽略故障继续运行。
- 错误处理：产品在出现坏数据的情况下能够抵抗失败，在失败时能保持优雅，并易于恢复。（在失败时，也能够给出准确的提示信息，并告知用户如何进行处理解决）
- 数据完整性：系统中的数据是受保护的，不会发生数据丢失或数据损坏。
- 安全性：系统发生故障后，不会造成较大金额上的损失。
易用性（Usability）：真实用户使用产品是否很容易？
- 易学性：产品的操作可以被⽬标⽤⼾快速掌握
- 易操作：产品可以轻松操作
- 可访问：产品符合相关的可访问性标准，并与 O/S 可访问性功能配合使⽤。
安全性（Security*）：* 产品对未经授权的使⽤或⼊侵的保护程度如何？
- 身份验证：登录用户是否经过系统验证
- 授权：用户的权限是否进行了控制，根据不同角色或级别进行授权
- 隐私：客⼾或员⼯数据是否进行了加密保护
可扩展性（Scalability*）：* 是否有合理的规划，应对系统的增长（数据量、流量、复杂性）
兼容性（Compatibility*）：* 与外部的组件以及配置等是否可以兼容，正常工作？在不同的硬件平台上、不同的应用软件之间、不同的操作系统中、不同的网络环境中是否可以正常的运行。
- 应⽤程序兼容性：该产品与其他软件产品是否可以协同⼯作。
- 操作系统兼容性：产品是否能够在不同类型的操作系统中工作。
- 浏览器的兼容性：产品是否能够兼容不同类型、不同版本的浏览器。
- 硬件兼容性：该产品适⽤于特定的硬件组件和配置。
- 向后兼容性：产品可与⾃⾝的早期版本是否可以同时使⽤，数据、功能是否能够兼容。
性能（Performance*）：* 系统的响应速度是否够快？
性能测试很多时候是由专门的性能测试人员负责，但作为功能测试人员也一定要关注；性能测试除了常见的并发压测，其实更多的场景是由于系统的数据量大，最终导致查询、导入、导出等功能响应很慢；尤其再同时发生并发，或多任务并行，最终就很有可能导致一个导出任务，需要几天之后才能完成。
易安装性（Installability*）：* 系统是否能够很容易得安装到对应的平台。
- 系统要求：产品是否能够识别某些必要组件缺失或不⾜？
- 配置：系统的哪些部分会受到安装的影响？⽂件和资源存储在哪里？
- 卸载：产品卸载时，是否能够清除干净？
- 升级/补丁：可以轻松添加新模块或升级新版本吗？他们是否会影响现有的配置吗？
- 管理：安装是否是由专⻔的管理⼈员处理，还是按照特殊的时间表进行的？
易维护性（Development*）：* 系统是否容易进行开发、测试、维护？
- 可⽀持性：是否可以以较低的成本向产品用户提供协助支持
- 可测试性：是否可以用尽可能简单的方法进行快速测试
- 可维护性：构建、修复或增强产品的难易程度及成本如何？
- 可移植性：在其他地⽅移植或复⽤该技术的经济性如何？
- 可本地化：将产品应⽤于其他地⽅的经济性如何？
测试第四步：【测试技术】，确定我们怎么来测，通过哪些手段、方法进行测试，以保障系统的质量符合质量标准、要求。
测试技术就是进行测试的策略分析，常用的测试技术有下面九种。
**Function Testing 功能测试：** 对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。
**Claims Testing 约束测试：** 挑战每⼀项声明！保证用户看到的任何资料中提到的功能的正确性及一致性。
1）明确相关的参考资料，如 SLA、⼴告、说明书、 帮助⽂本、操作⼿册等 ；（_SLA_一般指服务级别协议。 服务级别协议是指提供服务的企业与客户之间就服务的品质、水准、性能等方面所达成的双方共同认可的协议或契约。）
2）参照上面的资料，测试产品的每⼀项声明
Flow Testing 流测试：按照一定的顺序操作执行的测试
测试由多个处理步骤相连的流程
在相关操作或处理间不要重设系统
改变时间和顺序，并且进行并发操作
Domain Testing 领域测试：
1）分析产品任何可能的输入、输出
2）确定测试采用的数据进行测试。例如边界值、典型值、常用值、无效值、以及最具代表性的值。
3）考虑测试的数据的组合。
Scenario Testing 场景测试
1）⾸先考虑可能发⽣的⼀切实际场景
2）设计测试用例，包括对产品有意义的功能，以及复杂交互的场景
3）⼀个好的场景测试是⼀个引人入胜的故事，讲述⼀个重要的⼈如何 做⼀些对他来说很重要的操作
Stress Testing 压力测试
1）确定压测的范围，这个子系统或功能可能会承受量非常大的数据压力，或由于资源受限，出现大并发导致系统过载或 “损坏”；
2）识别与这些⼦系统和功能相关的数据和资源；
3）选择或⽣成具有挑战性的数据，或限定条件下的资源；例如，大型或复杂的数据结构、⾼负载、⻓时 间的测试运行、大量测试⽤例的执行、低内存情况下运行
Automatic Checking 自动化测试
Risk Testing 风险测试
１）思考产品可能会出现哪些问题、风险？
２）哪种问题出现的可能性会最多？专注于这些出现几率较多的问题
３）如果它们存在，你将如何检测并发现它？
４）列出这些问题并设计相应的测试用例，专门用来挖掘他们
５）另外还可以咨询相关的专家、查看设计⽂档、过去的缺陷报告或应⽤⻛险启发式⽅法，这些可能都会有所帮助
User Testing 用户测试
1）识别用户的类别和角色
2）确定每个类别的用户日都都会做什么操作，他们一般会如何操作，他们重点使用的功能有哪些？
3）获取真实的用户数据，或引⼊真实的用户，提前使用系统进行测试
4）系统地模拟真实用户使用场景（虽然你不是真实用户，但也很容易把自己想象成用户去使用）
5）最好的用户测试是涉及多种用户角色，并且多用户并行、交叉操作，不仅仅是单一一种用户或一个用户操作。
作者：京东零售 张强
内容来源：京东云开发者社区