共计 5767 个字符，预计需要花费 15 分钟才能阅读完成。
测试，没有剖析与设计就失去了灵魂；
测试人员在编写用例之前，该如何进行测试剖析与设计呢？上次在《测试的底层逻辑》中讲到了【输入输出测试模型】，还讲到了【2W+1H 测试分析法】，但 2W1H 分析法是初步的分析方法，具体在测试中如何落地，还须要更细的设计。
明天就给大家介绍一下由测试领域专家 James Batch 总结的测试剖析与设计模型，HTSM 启发式测试策略模型。
什么是 HTSM？
HTSM 是一套测试思路启发的办法，旨在帮忙测试人员更好地思考测试策略，领导测试人员在进行测试剖析和设计的时候如何去思考，思考哪些点。HTSM 包含四个重点畛域：测 试技术、我的项目环境、产品元素和质量标准。James Batch 倡议：你能够随便地应用它们，它对任何类型的软件都是通用的，另外在落地利用的时候，倡议依据理论场景调整模型的内容，以适应本人的组织环境。
James Batch 原文解释：TheHeuristic Test Strategy Modelis 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 与2W1H 比照：
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 危险测试
1）思考产品可能会呈现哪些问题、危险？
2）哪种问题呈现的可能性会最多？专一于这些呈现几率较多的问题
3）如果它们存在，你将如何检测并发现它？
4）列出这些问题并设计相应的测试用例，专门用来开掘他们
5）另外还能够征询相干的专家、查看设计⽂档、过来的缺点报告或应⽤⻛险启发式⽅法，这些可能都会有所帮忙
User Testing 用户测试
1）辨认用户的类别和角色
2）确定每个类别的用户日都都会做什么操作，他们个别会如何操作，他们重点应用的性能有哪些？
3）获取实在的用户数据，或引⼊实在的用户，提前应用零碎进行测试
4）系统地模仿实在用户应用场景（尽管你不是实在用户，但也很容易把本人设想成用户去应用）
5）最好的用户测试是波及多种用户角色，并且多用户并行、穿插操作，不仅仅是繁多一种用户或一个用户操作。
作者：京东批发 张强
内容起源：京东云开发者社区
