如何做到测试场景不遗漏?

简介: 每一次提测就像一次质量问题的万箭齐发,稍不留意,中个一两箭算是小事,乱箭穿胸那也是经常的。如何做到无懈可击,仅仅靠闪是不够的。这个时候,测试分析,可以帮助你。通过对业务、经验、质量的深度理解和分析,结合测试工具,可以让你在这漫天箭雨中,有条有理,从容不迫,闲庭信步。

测试分析与设计

测试是一门精细的学科,新人同学很容易有的误区是认为做测试主要就是编写测试用例和执行测试用例,进阶能力是写自动化脚本或研发工具。而实际上,测试人员最难修炼的是测试分析能力,测试分析能力是衡量一位测试同学是否专业的分水岭。分析除了使用方法,还需要有对业务、经验、质量的深度理解。自动化或工具实际是对分析和设计结果的一种实现,分析和设计的有效会决定实现的效果。

分析与设计过程

测试分析要从业务需求最开始就要介入,流程覆盖业务整个生命周期。在做分析的过程要想清楚,整体后续的设计怎么做。

测试分析可总结为四步:

  • 建模 - 输出业务/系统流程(分析:业务流程 - 系统流程)
  • 设计 - 测试场景(设计:测试场景)
  • 细分 - 测试用例/数据(设计:测试用例)
  • 扩展 - 多类型测试(性能,安全,异常等等)(基于经验)

1.png

测试场景分析实施

测试场景和测试用例区别是什么?为什么先要设计测试场景?

上图也描述了,测试场景对应的是实际的业务场景,业务场景是业务流程中因不同的事件触发后的业务情景。比如银行取款的业务办理流程,会因为用户的身份(VIP与否)、取款金额(大额,小额)、卡内余额(足额取,不足额取)等诸多因素,导致最后取款的结果和过程分支产生不同。测试场景就是对这类事件触发时的业务情景在质量角度的描述。而测试用例是对测试场景在测试范围和测试点的详细覆盖。

第一步:根据业务的目标(价值)、类别、技术等输入,确定业务场景分析的范围。

业务分析就是需求分析的过程。这里不仅仅考虑需求的功能逻辑,还需要结合不同业务类型,根据历史业务经验沉淀和风险沉淀进行综合考虑。可以参考用下图进行前期梳理。

2.png

第二步:业务流程梳理(业务场景)

将需求说明转化为业务流程,完成事件流(基本流+备选流)以及业务分析过程和技术分析过程的梳理。细化出原子级别的场景分支。

事件流: 同一事件不同的触发顺序和处理结果形成事件流,事件流分为基本流和备选流

基本流: 程序从开始执行直到成功结束所经过的最短路径。
备选流: 一个备选流可能从基本流开始,在特定条件下执行,然后重新加入基本流中;也可起源于另一个备选流,执行后加入基本流或终止用例。根结点的备选流要具备原子性。
基本流和备选流:如下图所示,图中经过用例的每条路径都用基本流和备选流来表示,直黑线表示基本流,是经过用例的最简单的路径。备选流用不同的色彩表示,一个备选流可能从基本流开始,在某个特定条件下执行,然后重新加入基本流中(如备选流2和4);也可能起源于另一个备选流(如备选流4),或者终止用例而不再重新加入到某个流(如备选流1和3)。

3.png

5.png

第三步:场景串联

通过第二步中拆解的场景,根据沉淀后的场景集,用组合,合并等方法梳理出所有的事件流。事件流必须100%覆盖所有的基本流+备选流组合。

6.png

测试用例设计

测试用例的设计很多时候是测试数据设计的过程,根据事件流(基本流+备选流)、数据和根据不同的角色,进行用例覆盖。需要确保所有场景100%覆盖。

8.png

非功能性设计扩展

测试用例在设计上除了考虑功能性质量属性,还需要对非功能性进行覆盖,推荐一个四字法进行设计。

  • 多:针对测试用例进行大数据量覆盖测试
  • 并:针对测试用例进行大数据量同时执行,验证并发下的测试结果
  • 复:重复的参数对同一用例进行执行测试。验证幂等结果是否符合预期。
  • 异:用非正常输入值进行用例测试。验证结果的正确性。
    测试策略

策略其实考虑两个问题,过程和方法:“测什么”,“怎么测”。

  • 你的测试对象是什么?
  • 本次测试的目标是什么?
  • 测试中重点、难点、风险是什么?
  • 测试要覆盖的深度和广度
  • 如何安排各种测试计划(先测什么,再测什么,时间资源安排)
  • 如何准出(测试结果)
    测试策略可参考模版&样例
1. 业务整体概述

1.1 业务背景
业务背景介绍若干字……

1.2 产品目标
产品目标介绍若干字……

1.3 架构目标
架构目标介绍若干字……

1.4 业务目标
业务目标介绍若干字……

2. 项目整体分析

2.1 功能性需求拆解
核心业务模块介绍,复杂度,测试点分析对应列表(此步骤为关键分析步骤)。测试分析功能点,要从产品质量标准的角度思考,针对质量特性进行功能点覆盖。

11.png

2.2 测试覆盖范围(涉及针对哪些质量要求的测试方法)
功能性、性能效率、兼容性、易用性、可靠性、安全性、易维护性、可移植性

12.png

2.3 测试对设计方案覆盖范围(根据开发设计文档罗列)

13.png

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 交付计划
主要是里程碑和大的时间点

测试报告

测试报告

测试报告实际就是一个质量评估的过程。内容的关键在于表达清晰两点:报告的对象是谁?报告的内容是什么?测试报告不是一个项目整体结束之后的产物,而是应该在项目整个生命周期随时同步的。

测试报告至少需要包括的信息:

  • 项目背景信息
  • 项目人员
  • 测试覆盖度(需求、功能性、非功能性)
  • 测试过程分析(执行情况)
  • 缺陷分析
  • 质量目标是否达到
  • 遗留风险以及应对措施

文章来源:AlibabaTechQA
开发者社区整理

相关文章
|
6月前
|
测试技术
测试遗漏是能力问题?
测试遗漏是能力问题?
36 1
|
6月前
|
前端开发 测试技术
可访问性测试清单/测试用例/场景
可访问性测试清单/测试用例/场景
可访问性测试清单/测试用例/场景
|
6月前
|
域名解析 JSON 测试技术
常见移动端APP测试场景
常见移动端APP测试场景
122 0
|
消息中间件 监控 测试技术
消息队列和应用工具产品体系-性能测试场景和工具
消息队列和应用工具产品体系-性能测试场景和工具
消息队列和应用工具产品体系-性能测试场景和工具
|
消息中间件 弹性计算 Java
使用阿里云性能测试工具 JMeter 场景压测 RocketMQ 最佳实践
使用阿里云性能测试工具 JMeter 场景压测 RocketMQ 最佳实践
1263 6
|
11天前
|
网络协议 关系型数据库 应用服务中间件
【项目场景】请求数据时测试环境比生产环境多花了1秒是怎么回事?
这是一位粉丝(谢同学)给V哥的留言,描述了他在优化系统查询时遇到的问题:测试环境优化达标,但生产环境响应时间多出1秒。通过抓包分析,发现MySQL请求和响应之间存在500毫秒的延迟,怀疑是网络传输开销。V哥给出了以下优化建议:
|
2月前
|
设计模式 SQL 安全
PHP中的设计模式:单例模式的深入探索与实践在PHP的编程实践中,设计模式是解决常见软件设计问题的最佳实践。单例模式作为设计模式中的一种,确保一个类只有一个实例,并提供全局访问点,广泛应用于配置管理、日志记录和测试框架等场景。本文将深入探讨单例模式的原理、实现方式及其在PHP中的应用,帮助开发者更好地理解和运用这一设计模式。
在PHP开发中,单例模式通过确保类仅有一个实例并提供一个全局访问点,有效管理和访问共享资源。本文详细介绍了单例模式的概念、PHP实现方式及应用场景,并通过具体代码示例展示如何在PHP中实现单例模式以及如何在实际项目中正确使用它来优化代码结构和性能。
45 2
|
2月前
|
JavaScript 前端开发 数据库
数据库测试场景实践总结
本文介绍了数据库超时和应用锁表SSDB测试场景的验证方法,通过锁定数据表模拟写入失败情况,并利用SSDB进行重试。测试需开发人员配合验证功能。同时,提供了SSDB服务器登录、查询队列数量及重启服务等常用命令。适用于验证和解决数据库写入问题。
34 7
|
4月前
|
测试技术
性能测试场景设计
**性能测试场景设计**涉及模拟用户行为和负载以评估系统在真实环境下的性能、稳定性和可靠性。常用的测试方法包括:**负载测试**,模拟实际使用以检查不同负载下的性能;**压力测试**,超负荷运行以检测系统极限;**稳定性测试**,验证系统长时间高负载的稳定性;**并发测试**,检查多用户访问时的性能和问题;以及**容量测试**,确定系统处理能力和资源利用率。测试场景多样,旨在确保系统应对未来增长需求的能力。
|
6月前
|
存储 测试技术 C++
P2P网络下分布式文件共享场景的测试
P2P网络下分布式文件共享场景的测试
292 6

热门文章

最新文章