阿里QA导读:每一次提测就像一次质量问题的万箭齐发,稍不留意,中个一两箭算是小事,乱箭穿胸那也是经常的。如何做到无懈可击,仅仅靠闪是不够的。这个时候,测试分析,可以帮助你。通过对业务、经验、质量的深度理解和分析,结合测试工具,可以让你在这漫天箭雨中,有条有理,从容不迫,闲庭信步。 测试分析与设计测试是一门精细的学科,新人同学很容易有的误区是认为做测试主要就是编写测试用例和执行测试用例,进阶能力是写自动化脚本或研发工具。而实际上,测试人员最难修炼的是测试分析能力,测试分析能力是衡量一位测试同学是否专业的分水岭。分析除了使用方法,还需要有对业务、经验、质量的深度理解。自动化或工具实际是对分析和设计结果的一种实现,分析和设计的有效会决定实现的效果。 分析与设计过程测试分析要从业务需求最开始就要介入,流程覆盖业务整个生命周期。在做分析的过程要想清楚,整体后续的设计怎么做。 测试分析可总结为四步:
测试场景分析实施测试场景和测试用例区别是什么?为什么先要设计测试场景? 上图也描述了,测试场景对应的是实际的业务场景,业务场景是业务流程中因不同的事件触发后的业务情景。比如银行取款的业务办理流程,会因为用户的身份(VIP与否)、取款金额(大额,小额)、卡内余额(足额取,不足额取)等诸多因素,导致最后取款的结果和过程分支产生不同。测试场景就是对这类事件触发时的业务情景在质量角度的描述。而测试用例是对测试场景在测试范围和测试点的详细覆盖。 第一步:根据业务的目标(价值)、类别、技术等输入,确定业务场景分析的范围。 业务分析就是需求分析的过程。这里不仅仅考虑需求的功能逻辑,还需要结合不同业务类型,根据历史业务经验沉淀和风险沉淀进行综合考虑。可以参考用下图进行前期梳理。
第二步:业务流程梳理(业务场景) 将需求说明转化为业务流程,完成事件流(基本流+备选流)以及业务分析过程和技术分析过程的梳理。细化出原子级别的场景分支。 事件流: 同一事件不同的触发顺序和处理结果形成事件流,事件流分为基本流和备选流
基本流和备选流:如下图所示,图中经过用例的每条路径都用基本流和备选流来表示,直黑线表示基本流,是经过用例的最简单的路径。备选流用不同的色彩表示,一个备选流可能从基本流开始,在某个特定条件下执行,然后重新加入基本流中(如备选流2和4);也可能起源于另一个备选流(如备选流4),或者终止用例而不再重新加入到某个流(如备选流1和3)。 实例: 第三步:场景串联 通过第二步中拆解的场景,根据沉淀后的场景集,用组合,合并等方法梳理出所有的事件流。事件流必须100%覆盖所有的基本流+备选流组合。 例: 测试用例设计测试用例的设计很多时候是测试数据设计的过程,根据事件流(基本流+备选流)、数据和根据不同的角色,进行用例覆盖。需要确保所有场景100%覆盖。 例: 非功能性设计扩展测试用例在设计上除了考虑功能性质量属性,还需要对非功能性进行覆盖,推荐一个四字法进行设计。
测试策略策略其实考虑两个问题,过程和方法:“测什么”,“怎么测”。
测试策略可参考模版&样例1. 业务整体概述1.1 业务背景业务背景介绍若干字…… 1.2 产品目标产品目标介绍若干字…… 1.3 架构目标架构目标介绍若干字…… 1.4 业务目标业务目标介绍若干字…… 2. 项目整体分析2.1 功能性需求拆解核心业务模块介绍,复杂度,测试点分析对应列表(此步骤为关键分析步骤)。测试分析功能点,要从产品质量标准的角度思考,针对质量特性进行功能点覆盖。
2.2 测试覆盖范围(涉及针对哪些质量要求的测试方法)功能性、性能效率、兼容性、易用性、可靠性、安全性、易维护性、可移植性
2.3 测试对设计方案覆盖范围(根据开发设计文档罗列)
3. 业务流程分析3.1 被测功能总体概述介绍若干字…… 3.2 整体业务流程介绍若干字 3.3 业务模型图介绍若干字 3.4 风险分析介绍若干字 4. 测试场景覆盖范围4.1 测试场景根据上一步的业务或者系统流程图,完成测试用例场景的设计 4.2 测试用例设计(完善测试用例,补充测试数据)根据测试场景细化测试用例,测试用例必须对测试场景和测试覆盖范围进行100%的覆盖 4.3 测试数据要求介绍若干 4.4 其他测试补充介绍若干 5. 测试执行计划这部分信息通常也会放在最前面。 5.1 人员组织包括哪些人参与,测试边界等 5.2 测试实施计划包括提测时间,联调时间等 5.3 交付计划主要是里程碑和大的时间点 测试报告 测试报告测试报告实际就是一个质量评估的过程。内容的关键在于表达清晰两点:报告的对象是谁?报告的内容是什么?测试报告不是一个项目整体结束之后的产物,而是应该在项目整个生命周期随时同步的。 测试报告至少需要包括的信息:
- To Be Continued - 《技术质量新人手册》
|
|