【软件测试】遇到bug怎么分析?

文章强调了bug定位的重要性,它能减少误报,明确责任,提高问题解决效率,增强开发与测试间的协作。在定位问题前,应保存bug记录,排除低级问题和数据问题。定位问题时,通常按用户环境、展示层、逻辑控制、服务层和数据库层的顺序进行。区分前端/后端bug能避免开发间的推诿,提高团队效率。问题定位后,需确认问题的普遍性和原因,以确保修复的有效性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

01 为什么定位问题如此重要

可以明确一个问题是不是真的“bug”

很多时候,我们找到了问题的原因,结果发现这根本不是bug。原因明确,误报就会降低

多个系统交互,可以明确指出是哪个系统的缺陷,防止“踢皮球”,提高问题解决的效率

增强开发对测试的信任度,沟通更有效,配合的更好,开发修改bug时效增强

更有效的了解系统的内部逻辑、数据流处理流程,更能提高测试人员的水平,缺陷修复后,影响的测试范围评估更精准,复测更准确

可以降低缺陷率

这个可以说是最重要的。在bug系统中,会要求开发人员记录bug产生的原因。只有我们自己对bug有一个较全面的认识,才会判别出开发写的是不是真正的原因,也才能有助于我们后续对bug进行分析归类,根据bug分析,有针对性地未雨绸缪,进而提升产品质量,降低缺陷。

降低缺陷

02 定位原因之前

遇到问题时,先别急着去定位原因。

1、保存bug产生的记录:

首要做的是保存bug产生的记录,保证可以复现。

为什么要保存记录?因为如果以后不能复现,那就不能证明bug的存在。

2、排除低级问题:

然后是排除QA的低级问题,常见的低级问题:

【hosts不对】

hosts文件主要是加快某个域名或者网站的解析速度,从而达到快速访问的作用,也可以屏蔽网站。

hosts异常可能会导致部分网页无法访问,能够加载,但是网页无法正常显示。

【网络不通】:抓包、ping

工具的影响导致的,例如fiddler

以及操作姿势不正确等。

3、排除数据问题(脏数据):

有时候会遇到服务端报500错误,查看日志后,报空指针,那么很有可能就是数据库中关联表的数据被人为删掉导致的。

脏数据:从目标中取出的数据已经过期、错误或者没有意义,这种数据就叫做脏数据。

脏读:读取出来脏数据就叫脏读。

03 定位问题的思路

排查顺序:

用户环境层面 -> 展示层面 -> 逻辑控制层面 -> 服务层面 -> 数据库层面

1、用户环境层面

主要是指基础环境是否可以使用。比如:

网络是否ping通

ip和端口配置是否正确

jdk版本是否符合标准

有可能是由于jdk版本不兼容导致系统运行异常,这种问题根据实际情况来决定要不要兼容。

网络设了代理

弱网(如js/css未加载完全、请求超时)

浏览器不支持

系统版本不支持

数据库被删除

测试环境脏数据

项目配置开关

测试环境切了分支等

2、用户展示层

用户在使用过程中,通过查看等操作发现的一些问题:

页面样式(css样式问题)

交互过程中js的提示(js交互问题)

终端控制的提示信息

文本的展示(html文本问题)

3、逻辑控制层

用户操作过程中,业务的处理逻辑有没有按照前期的设计实施。或者中间环节出现异常,比如缓存服务器(如redis)、消息中间件(如rabbitMQ)、数据存取中间件等。

4、服务层

服务层往往检查服务器的配置,如可能是tomcat配置、nginx配置、jdbc配置等的问题。测试人员最好能够了解下它们的各项配置。

5、数据库层

可能出现测试环境和正式环境数据库版本不同,前后端数据格式、长度限制不同。用户操作完成后,交易流程非常顺畅,这样也不代表整个交易没有问题,还需要测试人员检查数据库登记的表和字段是否正确。

如果发现登记的字段与预期的结果不一致,则可以查看日志,检查请求报文送的字段是否正确,是否与前台填写的一致。

有的一个操作会登记多张表,所以要检查多张表登记或者更新的是否正确,测试人员也需要对被测系统的数据表结构熟悉

6、经验法则

有经验的测试人员对于有部分bug已经见过多次,能够很快找到根源,直奔主题,迅速报告或者解决bug。

7、其他

常见的bug可能还有构建方面的原因

比如代码本身没错,但是合并代码到主干后出现了问题

比如代码存在冲突时手动解决的情况

04 如何区分前端/后端bug

为什么要区分前端/后端BUG?

如果是一个多人开发的系统,不能明确定位到这个bug是谁造成的,容易提交给错误的开发人员。

同时提交给前后端开发人员,每个人都会有依赖心理,bug会像皮球一样被开发踢来踢去,耽误开发解决bug的时间。

另外,如果团队规模较大,或者由各地的项目组拼凑而成,势必会增加沟通成本,这更需要我们在类似禅道或者Jira等项目管理软件中提交bug时,先指明是谁的bug,避免互相踢皮球的现象。

所以测试必须要自己学会区分出是前端还是后端bug,经过bug分类处理,整个团队的效率都会有所提高。

05 定位完问题后

在发现问题或者定位到问题原因后,一定要进行一步,就是再次确认问题。所谓确认问题,就是弄清楚问题是否每次都发生,还是概率事件,或者是工具相关的问题:

比如换个浏览器是否依然出现?如果换个浏览器不出现的话,很可能就是前端的兼容性问题。

比如翻页控件,待测的系统有很多页面都有翻页控件,那么就要看下是否每个页面都会出现这个问题,进而报bug时进行统一说明,也更加方便开发人员批量处理,防止漏改。

最后: 下方这份完整的软件测试视频学习教程已经整理上传完成,朋友们如果需要可以自行免费领取 【保证100%免费】
在这里插入图片描述
这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!
在这里插入图片描述

### 如何解决软件测试中的常见BUG及应对策略 #### 定义清晰的测试策略 为了有效地处理和预防Bug,在一定软件测试标准、测试规范指导下制定合理的测试原则、方式和方法至关重要[^1]。这不仅有助于提高测试效率,还能确保尽可能多地发现并修复程序中存在的问题。 #### 增强沟通与协作机制 针对开发人员未经许可擅自部署代码的情况,建立有效的沟通渠道和技术评审制度显得尤为重要[^2]。通过加强团队间的交流互动以及实施严格的变更控制流程来减少此类事件的发生频率。 #### 编写详尽全面的测试计划 一份优秀的软件测试计划对于成功完成整个项目有着不可替代的作用。其核心价值在于有效管理测试活动的同时揭示更多隐藏于产品之内的错误或不足之处;为此,需保证所设计出来的方案具备广泛的功能覆盖面,并采用实际操作性强的技术手段来进行验证工作[^3]。 #### 合理运用不同类型的测试技术 根据实际情况灵活选用合适的检测模式——无论是基于外部行为表现(即黑盒法),还是深入探究内部逻辑结构(即白盒法)。前者侧重考察应用程序对外界请求响应是否符合预期目标;后者则更关注源码层面可能存在的隐患点位,从而实现精准定位故障原因的目的[^4]。 ```python def find_bug_in_code(code_snippet): try: # 对传入的代码片段执行静态分析或其他形式的初步筛查 analysis_result = perform_static_analysis(code_snippet) if not analysis_result['success']: raise Exception(f"Static Analysis Failed: {analysis_result['message']}") # 如果静态分析未发现问题,则继续运行动态测试案例集 test_results = run_dynamic_tests(compile_and_run(code_snippet)) for result in test_results: if not result.passed: return f"A bug was found during dynamic testing: {result.error_message}" return "No bugs detected." except Exception as e: return str(e) # 这里仅提供了一个简单的函数框架用于说明概念, # 实际应用中应结合具体场景定制化开发相应的工具链。 ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值