技术分享 | Bug定位方法

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 技术分享 | Bug定位方法

通常情况下 Bug 分为四个类型,分别是功能、性能、安全和专项质量。功能级别关注于业务流程是否正确。性能级别关注于业务流程是否顺畅。安全方面判断是否存在漏洞,是否符合安全标准与规范。专项质量通常关注于用户体验 UX、兼容性、稳定性和可靠性。

为什么需要掌握bug定位

软件测试人员的首要任务就是发现 Bug ,发现之后提交 Bug 给开发人员进行修复。掌握 Bug 定位可以在提交 Bug 时追加更多有用信息,方便研发更快解决问题。通过分析 Bug 的形成原因,更有效率的进行溯源并建立特征进行批量追踪。

bug表现层

  • 条件:测试数据;
  • 过程:测试步骤;
  • 结果:测试结果。

技术架构层次

软件从技术架构层次分析一般分为三层,即视图层 View、控制层 Controller 和模型层 Model。而 web 和 app 在具体的层次关注的技术方向也是不同的,具体如下:

  • 视图层 View:
  • web:UI HTML CSS;
  • app:activity view;
  • 控制层 Controller
  • web:chrome、devtool;
  • app:dalvik art objectc-runtime;
  • 模型层 Model:
  • 模型的传递方式:http tcp rpc 串口;
  • 模型的形式:json xml binary;
  • 模型定义:schema。

MVC三层分析法

Bug 的定位往往也会依照软件技术架构层次采用 MVC 三层分析方法,分析 View 层、Controller 层和 Model 层的运行平台、应用调试机制和链路。

View 层常见的问题是 UI(User Interface)用户界面和 UE(User Experience)用户体验。目前常采用人工测试和自动化测试,通过人工校验为主自动化校验为辅的方式检验界面交互的准确性以及用户体验感受。此外利用 UI 的 Diff 对比分析界面变化,定位更深层次的问题。

Controller 层通过平台自主提供的日志(log)以及应用程序本身提供的应用调试日志(debug trace hook profile)分析代码层次的逻辑问题。

Model 层根据运行平台的 log、app 调试机制以及链路来具体分析问题。

web bug 分析方法

界面展示主要依赖于 html、css、js,可以使用 chrome 开发者工具的 elements 和 style 两个板块来分析,elenments 可以展示具体控件,控件格式通过 style 来确定,由此来判断是否是样式、布局或输出方面的问题。

1080×578 109 KB

界面展示是 javascript 根据操作流程对代码进行修改的结果,底层逻辑的错误在 console 板块会展示出详细的出错信息。而 source 模块可以对错误进行定位通过 debug 分析问题的上下文,找到代码问题的根源所在。

1080×426 146 KB

基于运行平台的 log,例如 chrome 的 network 模块分析请求方式和数据的具体情况。链路分析使用代理工具 proxy,常用的有 fiddler、charles 和 mitmproxy 以及网络层的嗅探,常用的有 tcpdump 和 wireshark。

1080×704 330 KB

app bug 分析方法

app 的 UI 界面交互和 UX/UE 用户体验目前常用的是人工校验的方式,以自动化作为辅助工具以及 UI Diff 的方式分析,尝试发现界面中存在的问题,其中人工测试能够发现未知特征的 bug,自动化测试可以断言常用功能是否正常,通过 UI Diff 可以发现界面结构细节的问题。

1080×2337 132 KB

通过 logcat 分析 app runtime 日志。

1080×516 242 KB

1080×537 221 KB

根据平台本身提供的 log 或者运行平台的调试工具,利用应用的日志分析以及建立追踪模式分析链路的问题,通过代理抓包 charles、fiddler、mitmproxy 或者嗅探抓包,wireshark、tcpdump 的方式分析链路。

安卓提供的工具,对 app 交互发生的网络请求进行中间过程的分析。

1080×562 265 KB

当工具本身不可调试时,可以使用代理工具分析。

1080×825 156 KB

通过 tcpdump 抓包,导入 wireshark 进行分析。

1080×654 375 KB

性能 bug 分析方法

H5的性能问题通常对网页加载的过程进行分析,通过 w3c 定义的 performance api 对每个阶段发生的问题进行统计,需要各个浏览器支持对性能方面的分析。

964×412 263 KB

分析应用运行时代码的具体时间。

总结

定位 Bug 首先要明确 Bug 问题的现象和复现步骤,通过分层分析关键过程的数据与问题特征,积累 Bug 特征与问题根源特征,丰富测试经验,提高 Bug 发现的能力。


更多技术文章:  https://qrcode.ceba.ceshiren.com/link?name=article&project_id=qrcode&from=hwyun&timestamp=1649923865

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
6月前
|
SQL 前端开发 测试技术
软件测试/测试开发|如何定位bug,一篇文章告诉你
软件测试/测试开发|如何定位bug,一篇文章告诉你
|
测试技术
《游戏测试》经典BUG解析001--002
《游戏测试》经典BUG解析001--002
|
消息中间件 运维 监控
线上踩坑记:项目中一次OOM的分析定位排查过程!
线上踩坑记:项目中一次OOM的分析定位排查过程!
麒麟系统开发笔记(十一):在国产麒麟系统上使用gdb定位崩溃异常方法流程进阶定位代码行数及专项测试Demo
上一篇,通过研究,可以定位到函数,本篇进一步优化,没有行数,程序较为复杂的时候,就无法定位,所以进一步定位。   本篇做了qBreakpad的研究,但是没有成功,过程也还是填出来,后来突然注意到gdb出现行数的方法,并通过了几轮测试以及实战,确实可以定位到行数,所以为了大家方便,把国企麒麟上的Qt崩溃方法分享出来。   本篇文章比较长,就不分篇了,同时还做了专项测试。
麒麟系统开发笔记(十一):在国产麒麟系统上使用gdb定位崩溃异常方法流程进阶定位代码行数及专项测试Demo
|
SQL BI 数据库
记一次bug分析定位过程
其实很多时候,我们在测试过程中发现的很多bug,并不是由于开发人员编码能力不好,或者粗心大意造成,而是在项目开发实施过程中,没有遵循一些必要的项目流程,没有充分认识到质量的重要性;如果能做好这方面的工作,关注流程,而不是喊口号,人人重视质量,人人为结果负责,那么,会有很多问题、不只是bug,都将“被扼杀在摇篮里”......
记一次bug分析定位过程
|
Web App开发 移动开发 前端开发
技术分享 | Bug定位方法
技术分享 | Bug定位方法
|
测试技术
软件测试面试题:软件上线后有bug怎么处理?
软件测试面试题:软件上线后有bug怎么处理?
198 0
|
Java 程序员
这个Bug的排查之路,真的太有趣了。 (上)
这个Bug的排查之路,真的太有趣了。 (上)
133 0
这个Bug的排查之路,真的太有趣了。 (上)
|
Java
这个Bug的排查之路,真的太有趣了。 (中)
这个Bug的排查之路,真的太有趣了。 (中)
131 0
这个Bug的排查之路,真的太有趣了。 (中)
|
Arthas Java 测试技术
这个Bug的排查之路,真的太有趣了。 (下)
这个Bug的排查之路,真的太有趣了。 (下)
387 0
这个Bug的排查之路,真的太有趣了。 (下)