admin 《测试架构师》| 基于车轮图的测试分析方法
测试分析 vs 测试设计
测试分析是一种分析活动，输人可以是前期对系统、设计有帮助的任何信息，如需求、场景、架构、设计、规范、友商信息等。通过测试分析，我们希望对被测系统能有深入的理解，获得测试点，明确测试深度和广度。
测试设计是一种设计活动，是我们依据测试点按照一定的方法和规范要求，得到测试执行依据（即测试用例）的过程。
测试点 vs 测试用例
测试点：测试中需要关注的地方，包含测试条件、测试数据、测试观察点、测试预期、测试约束和限制等。
测试用例：测试执行的依据，一般包含预置条件、部署、标题、步骤、测试数据、预期结果等。
做测试分析的时候，思维是活跃、发散的，得到的测试点往往存在如下一些现象：
不同的测试点在内容上容易存在重复或者冗余
测试点的测试输入不明确
测试点不同但搭建的总是相似的环境，做类似的操作；
很多测试点之间都存在一定的顺序关系，需要把这类测试点放在一起测试，不仅可以提高测试效率，还有利于发现测试问题。测试点描述得太粗或太细，无法保证粒度的一致性
测试用例是一份能够详细指导测试执行的测试说明书，其应说明产品在怎样的条件下工作，预期是什么。要想得到测试用例，就需要对测试点进行再加工。
产品测试车轮图
一个测试者从需求出发，从设计着手，去分析产品并获得测试启发的过程，我们要从哪些方面(测试类型)用哪些方法(测试方法)去测试产品(质量属性)。 我们把这个关系用一个图表达出来，会发现这个图很像一个“车轮”，所以我们称这种图为产品测试车轮图(简称车轮图)。
通过车轮图来进行测试分析，就叫基于车轮图的测试分析方法，但这个测试设计分析法的本质是围绕质量、围绕产品设计是否满足需求来进行测试的。
产品测试车轮图可以解决产品测试中最为关键的两个问题:
如何保证测试的“全面性”，即“测试广度”：在产品测试车轮图中测试广度通过测试类型来保证。只要测试类型覆盖全面，就不会出现重大的遗漏。
如何保证测试的“有效性”，也就是“测试深度”：在产品测试车轮图中测试深度通过测试方法来保证。只要我们能够掌握足够多的测试方法，就能保证测试足够深。
产品测试车轮图还能帮助我们评估测试团队的能力。一个测试团队能够驾驭的测试方法越多，这个团队的测试能力就越强。这为我们解决团队能力提升问题提供了思路。
车轮图只描述到八大类质量属性和测试类型的对应关系，并没有细化到各个质量子属性的层面，测试类型和测试方法也并没有考虑业务特性。大家可以结合自己产品的业务特点，自己动手绘制更贴合自己测试业务特点的产品测试车轮图。
“团队能够掌握的测试方法”和“团队在测试中需要使用的测试方法”是两回事。测试不是越多越好，而是需要根据产品的实际情况(目标、价值、风险等)来确定当前需要测试的广度和深度，这就是测试策略。
测试车轮图的使用方法
第一种是在 MM图(也称为思维导图工具,如 Xmind)中直接使用，按照车轮图模型，从每个质量属性(或测试类型)和测试方法的角度，逐一对被测对象进行测试分析，这种使用方式的优势是快、灵活，缺点是不利于跟踪需求的覆盖情况。
第二种是使用测试分析设计表(excel表格)来进行，分析思路和第一种方式类似，但是可以做到对需求的跟踪。
MM图一般包含三层：
第一层是测试类型，如功能性测试、性能测试等
第二层建议是测试方法
第三层是分析被测对象该如何使用这些测试方法来进行测试，及测试分析的具体内容--测试点
测试分析设计表一般由三部分构成：
测试分析设计输入表:用于确定测试分析的输入，包括用户使用场景、需求包、需求规格、用户故事、架构设计、各种行业标准和规范要求等，并对这些输人进行整理、跟踪。
测试类型分析表:用于确定本次测试分析需要考虑的测试类型，并按照针对测试分析输人整理出来的内容，逐一进行测试类型分析。
功能交互分析表:用于确定本次测试分析的功能和系统的哪些功能存在交互关系，然后将这些放在一起进行考虑。
思考三问：
芯片的验证流程中，是否也有相应的验证分析方法和验证设计方法呢？
如果有验证分析和设计方法，那这些方法具体是什么呢？
'验证车轮图' 中应该包含哪些信息呢？8个质量属性是不是通用的呢？该8个质量属性对应到芯片领域的子属性是什么呢？
0条评论