0
点赞
收藏
分享

微信扫一扫

读《测试构架师修炼之道》-Chapter3 测试构架师应该做的事

流计算Alink 2022-03-23 阅读 20
功能测试

第三章 软件构架师应该做和不应该做的事

1、软件构架师需要关注和不需要关注的事

不论是传统的瀑布式开发还是迭代、敏捷的开发模式,产品测试都可以概括为:测试需求分析、测试分析和设计、测试执行和测试质量评估。测试的意义,不光在于发现bug,而同时需要预防缺陷,提高产品质量。

1.1 在需求分析中要做什么

简单的来说,在测试需求分析阶段需要做2件事情:(1)理解需求(2)制定一份总体测试策略,明确测试范围、测试目标、测试重点和难点、测试深度和广度。

按个人理解,这个阶段在操作时,可能会和"测试分析和设计"合一,但是书中特地拎出来说是有道理的。因为不论是产品经理还是开发测试,拿到需求后做的第一件事就是理解需求,在需求讨论阶段就能够充分讨论并达成一致,将为整个产品功能开发的交付打下基础。

下面我们具体的看一下,怎么样叫做"理解需求"。

(1)理解产品的商业目标

待补充一张图(了解商务、我的领域、公司、我的客户)

watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETkDnu4fpg6jph4zmspnlpbPmnIvlj4s,size_20,color_FFFFFF,t_70,g_se,x_16

这里我理解主要有2个作用,第1点是讨论这个需求能够带来的怎样的商业价值。比如说,本需求实现了某个功能,该功能竞争对手都还能未能推出,提前交付以后能够提升自身企业产品的竞争力。抑或是,本需求优化了系统的软件架构,能够推动新需求的快速交付,缩短新需求的研发周期,一样是有商业价值的看表现。

第2点则是决定该需求的测试投入,包含测试范围、目标、深度和广度,这些内容都是根据需求的优先级和重要程度决定的。举例来说,我们把需求简单地分为3类,(1)测试需求,优先级最低 (2)不紧急的商用需求,优先级其次 (3)紧急的商用需求,优先级最高。对于那些紧急的需求,一定是优先安排并要求测试得更加仔细。

(2)梳理用户使用场景

首先需要了解你的用户,用户的类型,用户如何能够从你的产品中获取收益?

产品的竞争对手提供了怎样的解决方案,对于该需求,业界是否已有成熟的解决方案,是否存在共识和规范?

通过了解如上的信息,测试构架师需要梳理出如下的测试场景

1)针对不同的用户,确定用户的使用习惯和关注点

2)分析用户的行为,根据分析结果建立产品的拓扑模型、配置模型、流量模型、抽象出典型场景

3)确定各个场景下的输入和输出(正常、异常、保护、覆盖专项测试场景等)

(3)输出产品整体测试策略

总体的测试策略包含如下几点

1)测试范围、目标

2)测试的重点,结合产品价值、质量要求、架构实现给出的判断

3)测试的难点,仅从测试设计和执行的角度考虑

4)测试的深度和广度,广度从覆盖的角度考虑(自身功能、组件借口、外围提供、集成产品/组件等),深度则是可以从测试方法的角度进行描述,比如单运行测试(这个不是完全理解,指的是单个子功能运行?不考虑外部交互)、多运行测试(重复运行的幂等操作?)、边界值和错误输入等

5)如何安排测试活动(包括测试分层),将一个大目标分解成一个个有重点的小目标

1.2 在测试分析和设计中要做什么

(1)制定阶段测试策略

这里老师还是按照测试分层的方法去详细表述各个阶段需要做的事情,用下图表现开发和测试的分层对应关系,从上到下的粒度逐渐变小,用例数量也逐步增多。

对于不同的需求,按照什么样的标准进行测试验收,需要设计哪些用例,就可以参照此模型进行测试。

开发维度                测试维度

需求分析                验收测试

概要设计                系统测试(ST)

详细设计                集成测试(FT)

编码                       单元测试(UT)

总的来说,阶段测试需要关注的内容主要包括:

# 每个阶段的测试对象、目标

# 每个阶段的出入口准则        (可以看作质量目标和验收标准,比如要求代码覆盖率,用例测试通过率等等)

# 如何选择测试用例

(2)落实测试设计策略

定好了策略之后,实际能够支撑测试工作的依然是测试用例,那么必然就需要考虑测试设计如何体现测试策略的设计,让输出的用例可读、简洁,这就要依赖整个团队的沟通协作。

1.3 在测试执行中要做什么

(1)制定版本测试策略

除去常规的测试执行,整个版本的测试策略必然是测试构架师需要考虑的事情,主要内容包括但不限于:

# 测试范围和计划相比的偏差

# 版本的测试目标

# 重点关注的内容

# 测试用例的选择

# 测试执行顺序

# 探索性测试策略

# 接收测试策略(注:不太理解

# 回归测试策略(老特性功能回归,由开发软件框架组件变更、特性反合分支等条件触发)

# 试探性的测试策略(注:同不理解

# 自动化测试策略

(2)跟踪测试执行

这个就不必多说,掌握版本的缺陷变化并调整策略,每日关注故障单和测试活动的进展。

(3)版本质量评估和建立版本质量档案

每个版本测试完之后,出具一份版本的质量报告,体现不同特性的交付情况,缺陷/用例比例,故障泄露,特性商用等维度的信息。

(4)测试质量评估

区别于版本质量评估,指的是阶段质量评估或者发布时的质量评估,需要给出“能否进入下一阶段测试”或者“发布”的结论。方法上依然可以使用软件产品质量评估模型进行评估。

注:这里待学习后继续完善,不是很明白。

2、产品测试经理和产品测试构架师的协作

最后补充一点作者关于测试经理和测试构架师职能的讨论:

(1)显而易见,测试经理和测试构架师分别关注的是测试计划和测试策略。测试策略说的更多是why what how,即为什么要测,测什么,怎么测,而测试计划则关注when who,在什么阶段测试,由谁去测。

经验丰富的测试经验一定具有深厚的测试设计功底,但为什么不由测试经理制定具体的策略,更多还是由于精力不够,有限的工作时间无法让测试经理分出经理了解每一个特性需求的细节,并据此制定策略。所以这时候,就由测试经理安排整体的测试节奏和基本的测试目标(比如特性交付、版本发布),具体的测试策略则由测试构架师负责。

(2)产品测试策略就是在为产品找到一条达到测试目标的“路”,达到目标的路不一定只有一条,测试构架师就是希望经过系统的分析,找到最“适合”的那条路。

举报

相关推荐

0 条评论