ISTQB知识体系中的测试过程及其要点

ISTQB知识体系中定义的测试过程及其要点

ISTQB中定义的测试过程包括如下几个阶段:测试计划->测试分析->测试设计->测试实施->评估出口准则及报告->测试阶段；除此之外还包括 测试监督和控制，它贯穿于整个测试过程之中。下面将分别总结每个阶段的定义和要点：

一.测试计划阶段：

测试计划阶段关注如下几方面内容：测试策略(较高层级的)、测试资源、风险应对预案、出口准则、理清关系、时间节点。

1.测试策略：

策略概括的说就是考虑:“测什么”、“怎么测”的问题:

1.1“测什么”：

定义测试活动；测试范围（测试广度和深度);考虑测试分层策略（即单元测试、集成测试、系统测试…怎么做？由谁来做？）。

1.2“怎么测”:

测试所依赖的测试技术（基于规格说明的?基于经验的?具体采用哪些？）、测试优先级(较高层级的)。

2.测试资源:

1>规划支撑测试策略的人力资源；
2>分析测试所需要的软硬件环境，定义环境规格，并考虑如何去获得（可获得性）。
3>识别外部依赖及其SLA(承诺的服务级别协议)

3.理清关系:

1>理清测试工作强相关的相关团队，考虑其协作关系。
2>理清与后续测试分析相关的测试依据有哪些?与测试条件（TCON）之间的关系。
3>理清测试团队与相关团队（如：开发组）工作产品之间的关联性。

4.出口准则：

产品的交付物、；项目达到的需求覆盖率、缺陷遗漏率 等等度量指标。

5.时间节点：

项目达到特定目标时的时间节点。

6.风险应对预案：

略

二.测试监督与控制：

需要建立测试进度计划和监督框架以便对照计划跟踪测试工作产品和资源。此框架应该包括将测试产品的状态和活动、计划和战略目标相关联所需的详细的度量项和目标。

测试控制是一个持续行为，包括实际进度与测试计划之间的比较，在需要的时候采取措施。（保证实际进度与计划的一致性。）

要点：

1>将工作状态和活动与测试依据关联起来非常重要。

2>正确配置可追溯性，包括通过可追溯性报告状态的能力。（测试对于目标覆盖的一致性与完整性）

3>干系人要求监督的详细度量项和目标有时与系统功能或规格说明不直接相关。

4>业务干系人在项目早期参与有助于确定这些度量项与目标。

三.测试分析

测试分析解决要“测什么”的问题，即通过测试依据通过分析识别测试条件的过程。

1.测试依据：

风险、需求相关的直接或间接信息。案例库、历史缺陷库；需求文档、方案文档、设计文档；与项目干系人口头交流，邮件…等方式获取的碎片化信息。

测试依据的收集和整理即邰晓梅 MFQ&&PPDCS 的KYM过程。

2.测试条件：

测试条件（TestCondition） 在ISTQB AL-TM知识体系中讲的非常含糊

测试条件即一个需要覆盖的测试条目。对应的是 结合邰晓梅 MFQ&&PPDCS 知识体系中的TCO（测试覆盖大纲）。识别出需要覆盖的M(单功能)、F(功能交互)、Q(质量属性)

要点

1>影响测试条件详细程度的因素:

• 测试对象：

测试级别；测试依据的详细程度与质量；测试依据之间的关系；对测试设计和其他测试工作产品进行说明和文档化的程度。系统与被测试软件的复杂度；项目和产品风险。

• 测试过程：

所使用软件开发生命周期（迭代？瀑布）；测试测试管理工具；测试过程和组织自身的成熟度；

• 测试人员：

测试分析人员的技术和知识；能提供咨询的其他项目干系人的可用性（协作）。

2>详细测试条件的优点和缺点：

• 优点：

有助于测试依据与测试条件的可追溯性。

有助于风险和缺陷的识别，缺陷预防（在KYM、TCO过程中来识别风险）。

有助于覆盖详细的度量项，度量目标。

有助于"解释产品"（测试分析的产物TCO可以结合需求实例化，来解释产品）。

有助于指导其他测试活动及开发活动（将识别出来的TCON作为AT用例，驱动开发进行TDD）。

• 缺点：

痛点参照 MFQ&&PPDCS 中的TCO的维护
随着产品的迭代/更新，测试条件是需要不断更新的，维护是有难度和相当成本的。

需要整个团队来进行定义和实施，难道达到良好的统一性，容易流于形式。

3>详细测试条件的使用场景与少用的场景:

• 适用场景：

复杂的系统，安全强相关的系统（有必要做深入测试分析，项目能够投入的资源和成本也相对较大）。

开发周期与交付压力大，采用轻量测试设计文档的方法（TCON代替详细测试用例、检查表）。

没有或只有很少的正式需求或其他开发工作产品作为测试依据。（不太理解？）

• 很少采用的场景：

组件级别的测试。（开发的单元测试，一般不要求做详细的测试分析）

简单的项目。

可借助于用例来定义测试的验收测试。（这里的用例应该指的是需求片段，需求实例化）

四.测试设计

测试设计定义的是“如何测试”的过程。它是将测试条件细化输出逻辑测试用例 并分析需要覆盖的测试场景、测试数据的过程。

根据测试监督、控制和追溯的方法，可以将测试用例直接（或通过测试条件间接）与测试依据规定的目标相关联。

五.测试实施

将逻辑测试用例用测试数据进行填充，得到实际测试用例、脚本的过程。测试经理和测试分析师还将定义测试执行顺序（测试规程）。

要点

• 定义测试规程：

测试实施过程中要定义测试规程（测试执行顺序）。识别测试执行的限制条件，与环境和数据的依赖关系。

• 测试早期实施的优缺点：

缺陷：

脚本不可靠或有更高的维护成本（过早介入可能接口没有稳定）；需求的变更可能对于测试分析和测试设计结果的波及。

优点：

具体的测试提供了一些工作例子，用来说明如果按照测试依据所编写的内容，软件应该有何种行为。比抽象的业务规则更容易发现软件需求规格中的不足。提供启发性的说明。

需求实例化的AT验收测试用例？

六.测试执行

执行测试用例、脚本

要点

• 多样化的测试策略：
  基于需求和规格的测试技术 与 基于经验的测试技术结合。

• 测试监督：
  测试经理在这个阶段要按照测试计划监督进展、控制和引导测试任务、目标向着成功的方向发展。

七.评估出口准则及报告

略

八.测试结束

测试结束活动包括如下几方面内容：

检查测试是否完成；

检查交付物；

测试结果、记录报告等工作产品的归档；

总结经验和教训:

• 预料之外的缺陷机器。
• 估算的准确性。
• 缺陷趋势、根因。
• 改进机会改进点。
• 与计划的偏差，后续调整的策略。