异常测试实践与梳理

简介: 异常测试,是指通过人为制造异常,检测系统的处理是否符合逻辑。结合在A项目中的实践,梳理一下常见异常测试的类型、关注点及常用测试工具等。

A项目是一个典型的web前端+后台的项目,主要的业务是购买账号及注册账号。从实践来讲,我觉得一个项目的异常测试基本可以分为2大类:功能异常及服务端异常,功能异常按照先后执行顺序一般可以分为3种:单接口异常、web端异常及业务操作异常。下面来介绍一下功能异常,服务端异常在异常测试实践与梳理之服务端异常测试中介绍。

avatar


1、单接口异常测试

单接口异常测试主要的关注点是依赖服务调用异常时,业务代码能否容错及容错逻辑是否合理。

单接口异常测试一般也可以放到服务端异常测试阶段来做,但这个阶段常规功能测试已经做完,再回过头来对每个接口进行异常测试,还需要花一定时间去重新熟悉接口业务,且该阶段关注的重点是后台整体的异常,需要覆盖的异常点很多,从时间上来说一般会比较紧。所以,个人觉得单接口异常测试放在接口测试阶段比较合适,并且单接口异常测试可以为服务端异常测试做铺垫,把接口依赖分析都完成了。

单接口异常测试,主要包括输入异常、操作异常、依赖服务异常等,具体要视接口情况而定。输入异常及操作异常一般在接口测试时都会涉及,而依赖服务异常不一定。如果项目对可靠性要求比较高的话,且时间允许情况下,还是要争取覆盖一下。

在A项目的单接口异常中,依赖服务异常是重点。在执行测试之前,需要做一些准备工作。

  • 分析接口所有依赖的服务(需要咨询开发,或对业务和代码熟悉的可以直接看代码来了解) A项目中所有接口的依赖服务主要包括主系统(调用注册服务)、数据库(MySQL)、缓存(redis)等。
  • 了解各依赖服务的超时设置 如访问mysql、redis及http请求的超时时间。需要跟开发确认所有访问第三方依赖的http请求的连接参数设置是否相同。
  • 依赖第三方服务接口的异常返回码类型,及代码处理逻辑

A项目中有一个接口调用了主系统的注册接口,需要去了解,若注册接口调用失败而返回非200返回码,代码是否会进行重试,若重试依然失败,该接口最终的返回结果是什么?管理后台是否还有二次注册的接口?

avatar


在单接口异常测试执行时,只需要选择该接口对应的依赖服务进行测试就好。访问超时和丢包一般可以使用linux的tc命令来设置,服务挂掉一般通过改ip或端口来实现的,依赖第三方接口的异常返回码一般是用WireMock来模拟的。

2、web端异常测试

这里的web端异常测试,主要是指接口访问超时及返回异常返回码时的提示是否符合预期逻辑。

除了文字提示之外,一般通用的错误提示分为以下三种:toast(一段时间后自动消失)、错误页及alert(弹框提示)。

avatar


一般前端在开发时都会跟产品及交互定好每种异常情况下的文案规则,在UI测试阶段就对照这份规则来进行测试。下图就是A项目中页面初始化接口的文案规则:

avatar


有些异常情况只通过页面操作是不太好模拟,例如服务器异常、访问超时等等。一般UI测试是在接口测试完成之后才做的,异常返回码的模拟在接口测试阶段已经覆盖过,所以在UI测试阶段,推荐使用工具来进行异常返回码的模拟,而不需要进行复杂的后端操作来模拟,使用工具可以节省很多的时间。

windows的pc端推荐使用fiddler,这是一个http协议调试代理工具。在前端测试中,一般主要使用fiddler的2种功能,设置断点功能及请求自动重定向功能。下面简单介绍一下这两种功能,具体用法自行百度啊~~

1、设置断点
通过菜单栏“Rules/Automatic Breakpoints”给请求设置断点,可以选择Before Requests或After Responses。可以修改提交到服务器的数据信息(如:请求头或请求体等),也可以修改从服务器端返回的数据,还可以用来模拟请求超时。

2、请求自动重定向
这是fiddler最实用的功能,可通过自由设置规则,将符合条件的请求进行重定向,修改HTTP数据的特性。

3、业务操作异常测试

这部分一般是放在功能测试的后期,因为业务异常用例的设计需要对项目有一定的理解,是业务强相关的。
A项目是购买相关的,主要的业务操作异常集中在购买流程中,例如:购买时回退页面、支付超时、多人同时购买同一商品等等。一个人能想到的异常情况一般是有限的,所以在业务异常测试之前,测试人员可以先出一个大致的测试方案,然后跟开发同学一起开一个评审会,评估一下哪些异常测试用例是没有必要的,哪些是可能遗漏的,再对测试方案进行优化,保证测试的有效性。特别是对bug比较多的业务点要重点进行一些业务异常的测试,在进行bug发散的基础上,多分析和思考可能引起类似异常的操作。

相关文章
|
9月前
|
数据采集 监控 机器人
浅谈网页端IM技术及相关测试方法实践(包括WebSocket性能测试)
最开始转转的客服系统体系如IM、工单以及机器人等都是使用第三方的产品。但第三方产品对于转转的业务,以及客服的效率等都产生了诸多限制,所以我们决定自研替换第三方系统。下面主要分享一下网页端IM技术及相关测试方法,我们先从了解IM系统和WebSocket开始。
200 4
|
1月前
|
机器学习/深度学习 自然语言处理 API
query改写:大模型应用测试离不开的实践
queryrewrite 是一个用于大模型应用测试的 Python 库,专注于查询(query)的改写与验证。它支持多种改写方法,包括大型语言模型(LLM)、词汇表替换和同义词替换,同时提供多种验证方法如 ROUGE-L、BLEU、帕累托最优和LLM语义相似度,以确保改写后的查询在语义上保持一致。该项目特别优化了对中文文本的处理,涵盖分词和相似度计算。用户可通过 pip 安装,并支持扩展不同的 LLM 模型,如 OpenAI、Ollama 等。
458 87
query改写:大模型应用测试离不开的实践
|
1月前
|
JSON 自然语言处理 算法
大模型应用测试必备技能:问题对生成实践
本文介绍了利用LangChain的QAGenerationChain从文本生成问题-答案对(QA pairs)的方法,旨在解决LLM应用开发中测试数据生成的格式不统一、库版本过时、模型输出异常及代码可维护性差等问题。文中提供了完整的代码实现,并对生成结果进行了有效性评估,包括语义相似度检查、关键词匹配和重复性检测,确保生成的QA对质量可靠,适用于知识库测试与评估。
281 86
|
12天前
|
Java 测试技术 API
自动化测试工具集成及实践
自动化测试用例的覆盖度及关键点最佳实践、自动化测试工具、集成方法、自动化脚本编写等(兼容多语言(Java、Python、Go、C++、C#等)、多框架(Spring、React、Vue等))
53 6
|
12天前
|
人工智能 边缘计算 搜索推荐
AI产品测试学习路径全解析:从业务场景到代码实践
本文深入解析AI测试的核心技能与学习路径,涵盖业务理解、模型指标计算与性能测试三大阶段,助力掌握分类、推荐系统、计算机视觉等多场景测试方法,提升AI产品质量保障能力。
|
21天前
|
人工智能 自然语言处理 测试技术
AI测试平台的用例管理实践:写得清晰,管得高效,执行更智能
在测试过程中,用例分散、步骤模糊、回归测试效率低等问题常困扰团队。霍格沃兹测试开发学社推出的AI测试平台,打通“用例编写—集中管理—智能执行”全流程,提升测试效率与覆盖率。平台支持标准化用例编写、统一管理操作及智能执行,助力测试团队高效协作,释放更多精力优化测试策略。目前平台已开放内测,欢迎试用体验!
|
1月前
|
人工智能 资源调度 jenkins
精准化回归测试:大厂实践与技术落地解析
在高频迭代时代,全量回归测试成本高、效率低,常导致关键 bug 漏测。精准化测试通过代码变更影响分析,智能筛选高价值用例,显著提升测试效率与缺陷捕获率,实现降本增效。已被阿里、京东、腾讯等大厂成功落地,成为质量保障的新趋势。
|
1月前
|
搜索推荐 Devops 测试技术
避免无效回归!基于MCP协议的精准测试影响分析实践
本文揭示传统测试的"孤岛困境",提出MCP(Model Context Protocol)测试新范式,通过模型抽象业务、上下文感知环境和协议规范协作,实现从机械执行到智能测试的转变。剖析MCP如何颠覆测试流程,展示典型应用场景,并提供团队落地实践路径,助力测试工程师把握质量效率革命的新机遇。
|
1月前
|
人工智能 缓存 自然语言处理
大模型性能测试完全指南:从原理到实践
本文介绍了大模型性能测试的核心价值与方法,涵盖流式响应机制、PD分离架构、五大关键指标(如首Token延迟、吐字率等),并通过实战演示如何使用Locust进行压力测试。同时探讨了多模态测试的挑战与优化方向,帮助测试工程师成长为AI系统性能的“诊断专家”。
|
3月前
|
人工智能 Java 测试技术
SpringBoot 测试实践:单元测试与集成测试
在 Spring Boot 测试中,@MockBean 用于创建完全模拟的 Bean,替代真实对象行为;而 @SpyBean 则用于部分模拟,保留未指定方法的真实实现。两者结合 Mockito 可灵活控制依赖行为,提升测试覆盖率。合理使用 @ContextConfiguration 和避免滥用 @SpringBootTest 可优化测试上下文加载速度,提高测试效率。
255 6

热门文章

最新文章