软件测试人员测试过程中如何分析定位常见BUG

当你在上班期间，听到不远处传来，这样的声音"你会不会提BUG，责任人都指派错了，能好好提吗？"

如果哪天开发对着你说出这句话

那么作为测早中试的你，此时心里是怎么想的？

确实，作为一名测试的我，一直认为测试人员提出一个BUG，就要有一定的专业性、严谨性

作为一名测试人员如果连常见的系统问题都不知道如何分析，频繁将前端人员问题指派给后端人员，后端人员问题指派给前端人员，那么在团队里你在开发中的地位显而易见 ，口碑、升值、加薪那应该是你遥不可及的梦!

但是作为测试人员来说，尽管你不能深入的去分析问题，但是你能发现系统存在的问题，这点也是值得肯定的，所以继续加油

所以今天给大家分享的主题是："软件测试人员测试过程中如何分析定位常见BUG"普及一些常用方法与技巧

首先当系统出现bug时，一定要将bug现象进行录制保留，保留现象时为了证明这个bug出现过，如果bug是必现还好说，如果该bug无法必现，那么保存的截图都是你直接证据，要养成良好的保存现场的习惯

提BUG这块，还是要体现出测试的专业性，标题简洁、问题环境标识清楚、问题详细描述清楚、系统错误表象贴图、接口传参返参贴图、必要时贴服务器日志，总结来说不该少的bug标签一个不要少

1、 小型产品，前后端一人统筹

一些小型程序，例如前后端都用node、php语言开发的，整个系统前后端是同一个开发的时候，那么我可以自信的给你说，系统出现问题时，bug大胆的提，往猝死的提，责任人错不了！

2. 常规系统，多人开发协同

前置：测试之前该测试人员对系统、业务、环境部署、开发人员等较为熟悉

在测试之前打开对应浏览器的F12直接开个新页签，或者使用抓包工具等，系统呈现出问题时，查看对应的请求、日志信息等我们才能去全面的定位是前端还是后端人员的问题，具体给大家介绍以下几个常用方法

（1）分析问题场景进行预判

先查看页面表象，根据问题表像判断问题可能出现的原因，进行缩小范围，并且准备好录制工具，录制问题

系统页面无法正常访问的提示5开头的找后端，4开头的先检查请求地址或者对应的权限，进入系统页面正常打开，提示异常代码错误的直接找后端

进入系统页面展示异常图片视频相关提示Flash等相关信息进行安装Flash如若还不行找前端，界面UI展示兼容性错误找前端

如若系统访问正常，进入 *** 作页面，功能性报错信息，就进入下面环节，抓包查看对应请求体，看日志等

4**开头的状态码一般都是客户端（前端）的问题；例如常见的404确认下是否是请求的地址有错，403确认是否有权限访问，具体可百度

5**开头的状态码一般都是服务端（后端）问题，例如常见的500，则表示是服务器内部错误，503网络过载导致服务端延时，502服务器崩溃等，具体可百度

通过访问报错的页面，加载错误请求时我们通过F12进行分析请求包，查看对应的入参以及响应数据

例如：请求入参错误，那么该bug属于前端的错误；入凯迹参标准可以根据前端页面的输入的内容或者选择的内容，进行核验，入参格式以及是否必填等可以对应接口文档去进行分析或跟开发确认

例如：请求未响应或者响应数据错误，那么该bug就属于后端的错误；一般是数据库查看报错，例如删了某个表查询报错误空指针等

如果请求的入参或者响应数据都没问题，可以跟开发反馈是不是浏览器解析的问题，可以换个浏览器测试

（4） 查看日志

针对服务端类型的报错，我们可以进行登录日志平台或者服务器对应Log目录下查看打印出的日志

常用查看日志命令tail ,/error进行快速检索关键词接口名等相关内容

拿到对应的日志,将日志文件贴进bug单，指派给后端，提高专业性，测试人员也要养成看日志的习惯，看着看着就懂了

（5） 经验法则

在系统前端页面当碰见服务器配置相关报错的信息例如Nginxxxx或者代码以及SQL相关的提示报错信息直接找后端处理，例如JAVAxxxx 、.PHP、SQL等异陆孙山常报错

前端字符校验、格式校验、等，浏览器界面UI兼容性以及插件，或者APP、小程序类调用手机相关功能拍照、语音无法正常调用直接找前端

记住以上的一些方法以及技巧减少将BUG责任人提错的概率，在提单方面整洁完整一些，长久以来，体现出你的专业性，相信开发会对你竖起大拇指

做一个既能发现问题还能协助开发解决的问题的测试人员，那也是你从初级跨入中级测试的一个标准

最后我也整理了一些软件测试学习资料，对于学软件测试的小伙伴来说应该会很有帮助，为了更好地整理每个模块

需要的私信我关键字【555】免费获取哦 注意关键字是：555

全套软件测试自动化测试教学视频

300G教程资料下载【视频教程+PPT+项目源码】

全套软件测试自动化测试大厂面经

对于刚入行的软件测试新手迅速找出软件中的Bug思路如下：

1、

尽快熟悉公司的产品业务 比如你们公司做ERP软件的，你肯定要迅速熟悉EPR的业务流程；比如你们公司是做法院软件的，那么你一定要熟悉法院审判案件的流程，只有熟悉了产品的业务流程、你才能迅速找出软件中存在的一些重要的缺陷，你发现的软件缺陷才是有价值的。否则即使你能找到一些软件缺陷，那也是纯软件的缺陷，价值不大。

2、

把自己当成是用户 把自己当成是用户去使用该系统，比如在使用该系统过程中是这样 *** 作的吗？

（1） 比如在大量要求用户输入的软件界面中，有一些用户喜欢使用Tab键采用全键盘的输入；此时的正确的接口应该采取从左到右，从上到下的顺序。

（2） 比如有的用户喜欢使用快捷键 *** 作等（Ctr+C，Ctr+V，Ctr+F），但是实际情况下一些开发出来的软件的快捷键却根本不起作用。

（3） 比如软件在需要用户输入的信息的时候（特别是在填写个人资料的时候），必填项后面一律要用*等醒目的标示，要让用户知道这个地方时必须填写的。

（4） 下拉框不选值铅乎带的时候，应该有个默认值；并且要多检查程序中的多处下拉框，因为很多情况下下拉框取不到值。

3、

善于怀疑，不要迷信高手 世界上没有绝对正确的，总有错误的地方，具有叛逆心理，别人认为不可能发生的事，我却认为可能发生。别人认为是对的，我却认为不是对的。如果你认为某个或者某些程序员水平很高，他写的这个地方应该没问题吧，那么我要说你错了，这样很容易遗漏软件中的Bug。因为程序开发人员毕竟是普通的人，只要是人就会犯错误的。

4、

不要让程序开发人员的观点：“用户不会进行这样的 *** 作”而说服自己 遇到这样的情况，你要坚持你自己正确的想法，以后对方会明白你的。比如在一个录入员工基本信息的系统中，系统中对员工的年龄作为负值、而没有作为判断、也可以保存到数据库中，此时你不要被程序员的用户不会进行这样 *** 作的观点说服自己，你要坚持你正确的观点，把这种现象作为一个Bug吧，勇敢点！你的选择不会不错！

5、

在软件测试过程中要跟踪一条数据完整的流程 在软件测试的时候要跟踪一条数据完整的流程，保证数据的正确性这个真的是太重要了：假如你在测试一个销售的类型的软件的时候：你应该先做订货-à入库-à盘点-à销售-à查询。首先你要保证这个数据的流向是正确的无误的。假如你在测试法院审判软件的时候，你要先收案-à立案-à发送审批-à排期---审理审判-à结案判决-à归档-à查询。总之跟踪一条数据的流程，保证数据的正确性。如果经过你测试的软件在用户使用过程中业务流程上都走不通的话，那么这样的软件你说经过你的测试，但是在比人看来与没有测试有什么区别呢？

6、

回归测试要注意的细项 程序员提交新的程序版本后，作为测试人员应该立即与程序员沟通这个修改的功能、并且这个新修改的功能影响哪些功能。举个简单的例子来说明一下：比如在一款软件中，程序开发人员修改了某个“会员”的某个字段信息。作为测顷坦试人员首先你要测试“会员”的功能这个是你首先需要做的。另外你还要和程序员沟通询问他们新修改的这个会员的字段，会影响会员的销售功能吗？会对会员以前的销售记录的查询有影响吗？如果对这些功能有影响，那么这些功能都是你在回归测试的时候重点测试的地方，也是最容易产生Bug的地方了。

7、

与使用者互动的缺陷

（1）如填写资料错误应的时候，应该能够提示错误的位置，让用户知道是这个地方输入数据不对。

（2）删除数据之前给一定要给出是否删除确认提示。

（3）不要在软件中使用中英文混合的提示比如：比如对于用户某个 *** 作的错误提示，不要一会用“error”、一会用“错误”；一会用“succeed”另一会用“成功”，总之要统一。

当然要想简单省事并全面定位分析BUG，也可以直接交给成熟的第三方测试，TestBird的测试很全面，可以进槐芦一步了解下！

1 案例描述

作为Windows程序员，平时最担心见到的事情可能就是程序发生了崩溃（异常），这时Windows会提示该程序执行了非法 *** 作，即将关闭。请与您的供应商联系。呵呵，这句微软的“名言”，恐怕是程序员最怕见也最常见的东西了。

在一个大型软件的测试过程中，初期出现程序崩溃似乎成了不可避免的事。其实测闭绝试中出现程序崩溃并不可怕，反而是测试的成功。作为开发的我们更需要关心的是程序中的哪个函数或哪一行导致了系统崩溃，这样才能有针对性的进行改正。

本文描述了自己总结的几种定位崩溃的办法。

2 案例分析

以下是几种常见的崩溃现象及对应的处理办法：

1．对于Release版本必现的崩溃且在Debug版本上也崩溃的程序。

解决思路：去掉所有断点，直接在Debug版本上运行程序，在程序崩溃时，VC会自动跳转定位到崩溃代码行， 这种方法最简单也最常用。

2．对于在Debug版本上不崩溃但Release版本崩溃的程序，很有可能是Debug和Release版本的差异。例如Debug版本所有成员在构造时会被清0，而Release版本所有成员在构造时是内存里面的原始值，而且Debug有运行时库做保护，这些都会导致某些程序在Debug正常而Release崩溃。

解决思路：1）在程序中加打印，通过程序崩溃之前的打印定位出错位置； 2）逐段注释代码，直到程序不崩溃为止。这种方法耗时较长，对程序员要求较高，而且对于那种不是必现的bug或者很难搭建执行环境的情况就较难处理了。

3．对于在客户现场崩溃的情况，显然不适合直接带一台电脑去调试。

解决思路：应该有文件记录下崩溃信息，客服人员可以将崩溃信息文件发送给程序员，以便程序员查询崩溃原因，然后利用编译时生成MAP文件（工程信息文件，存放在版本编译机中）的信息来定位问题函数或问题代码行。下面就这种方法展开讨论一下：

3 解决过程

对于上节第三种情况，也是最难解决的情况，解决过程如下：

1. 崩溃回调注册，拦截Windows程序崩溃；

2. 在回调处理中，输出崩溃原因，崩溃内存地址，崩溃堆栈；

3. 工程输出map文件；

4. 通过崩溃内存地址以及map文件找出崩溃的函数。

5. 使用COD文件精确定位崩溃行

3.1 崩溃回调注册

实际上，只靠Windows的错误消息对话框提供的信息量是很有限的。用SetUnhandledExceptionFilter注册自定义错误处理回调函数，可银态首以替换Win32默认的异常锋数处理过滤器(top-level exception filter)，而且能打印出崩溃堆栈，这对定位崩溃原因非常有用。

SetUnhandledExceptionFilter的函数原型：

LPTOP_LEVEL_EXCEPTION_FILTER SetUnhandledExceptionFilter(

LPTOP_LEVEL_EXCEPTION_FILTER lpTopLevelExceptionFilter )

功 能：注册和注销异常处理回调；

用 法：第一次调用注册异常处理回调，第二次调用注销；

返回值：返回当前的exception filter。需要保存这个函数指针，在注销异常处理回调的时候，以此为参数再次调用SetUnhandledExceptionFilter。打印异常处理也需要此值。

参数： 异常处理的回调函数；

3.2 输出崩溃信息

崩溃信息在异常回调函数中打印，输出到程序执行目录下的文件：

异常处理回调的函数原形：

LONG WINAPI CallBackDebugInfo ( EXCEPTION_POINTERS *pException)

功 能：异常处理回调处理，打印崩溃信息；

用 法：注册自定义错误处理回调：SetUnhandledExceptionFilter (CallBackDebugInfo)；

返回值：EXCEPTION_CONTINUE_EXECUTION – 错误已经被修复,从异常发生处继续执行

EXCEPTION_CONTINUE_SEARCH– 继续查找异常过滤器

EXCEPTION_EXECUTE_HANDLER – 正常返回

参数： 崩溃信息结构，包含崩溃原因、崩溃模块、崩溃地址、崩溃堆栈等；

常见崩溃原因有：

EXCEPTION_ACCESS_VIOLATION = C0000005h 读写内存错误

EXCEPTION_INT_DIVIDE_BY_ZERO = C0000094h 除0错误

EXCEPTION_STACK_OVERFLOW = C00000FDh 堆栈溢出或者越界

EXCEPTION_GUARD_PAGE = 80000001h 由Virtual Alloc建立起来的属性页冲突

EXCEPTION_NONCONTINUABLE_EXCEPTION = C0000025h不可持续异常,程序无法恢复执行,异常处理例程不应处理这个异常

EXCEPTION_INVALID_DISPOSITION = C0000026h在异常处理过程中系统使用的代码

EXCEPTION_BREAKPOINT = 80000003h 调试时中断（INT 3）

EXCEPTION_SINGLE_STEP = 80000004h 单步调试状态(INT 1)

3.3 输出map文件

map文件记录程序的全局符号、源文件和代码行号信息，是整个程序工程信息的静态文本。通过文本阅读工具如Ultra Edit或记事本就可以打开Map文件。

在 VC 中，打开“Project Settings”选项页，选择 C/C++ 选项卡，并在最下面的 Project Options 里面输入：/Zd ，然后选择 Link 选项卡，选中“Generate mapfile”复选框。并在最下面的 Project Options 里面输入：/mapinfo:lines，表示生成 map 文件时，加入行信息。

最后编译就可以生成 MAP 文件，可以在工程的Debug或Release目录下找到刚刚生成的MAP文件，文件名为“工程名.map”。

3.4 使用map文件找出崩溃函数

　通过上面的步骤，已经得到了 MAP 文件，那么我们该如何利用它呢？下面一步步演示使用MAP文件定位程序崩溃行的过程。

1.我们先在代码中加入非法内存 *** 作（最常见的异常）的代码：

BOOL CMainFrameDlg::OnInitDialog()

{

::SetProp(m_hWnd, AfxGetApp()->m_pszExeName, (HANDLE)1)

s32 *p = NULL

*p= 123

2.执行程序，程序在开始就异常，在异常打印文件中打印了如下信息：

======================== 崩溃信息 ==========================

崩溃时间： 2009/06/02 16:58:22

崩溃原因： 非法内存 *** 作

异常代码 = c0000005

异常地址 = 0x0045a76f

异常模块: E:\ccroot\liuxiaojing_Enterprise\Enterprise_VOB\70-nms1\pcmt2\prj_win32\Release\pcmt2.exe

Section name: .text - offset(rva) : 0x0005976f

---------------------- Trips of Stack ----------------------

E:\ccroot\liuxiaojing_Enterprise\Enterprise_VOB\70-nms1\pcmt2\prj_win32\Release\pcmt2.exe

name : pcmtver - location: 2bef

3. 确定崩溃地址是：0x0005976f，在Map文件中定位函数：

0001:00059420 ?OnCreate@CMainFrameDlg@@IAEHPAUtagCREATESTRUCTA@@@Z 0045a420 f MainFrameDlg.obj

0001:00059460 ?SetTooltips@CMainFrameDlg@@AAEXXZ 0045a460 f MainFrameDlg.obj

0001:00059700 ?OnTranslate@CMainFrameDlg@@IAEJIJ@Z 0045a700 f MainFrameDlg.obj

0001:00059730 ?OnInitDialog@CMainFrameDlg@@MAEHXZ 0045a730 f MainFrameDlg.obj

0001:00059a10 ?OnSysCommand@CMainFrameDlg@@IAEXIJ@Z 0045aa10 f MainFrameDlg.obj

0001:00059c20 ?OnPaint@CMainFrameDlg@@IAEXXZ 0045ac20 f MainFrameDlg.obj

根据00059730<0005976f <00059a10 ，确定是在CMainFrameDlg 的OnInitDialog函数中的某一行产生了异常。

3.5 使用map代码行定位崩溃行区间

Line numbers for .\Release\MainFrameDlg.obj(E:\ccroot\liuxiaojing_Enterprise\Enterprise_VOB\70-nms1\pcmt2\source\MainFrameDlg.cpp) segment .text

498 0001:00059647 499 0001:00059667 501 0001:0005966e 502 0001:000596af

503 0001:000596ed 506 0001:00059700 507 0001:00059703 508 0001:00059708

510 0001:0005970f 511 0001:00059720 512 0001:00059723 515 0001:00059730

516 0001:0005974e 521 0001:0005976d 524 0001:0005977e 526 0001:0005978b

我们在map文件的代码行信息里查找不超过计算结果0x0005976f，但可以找最接近的数。发现是 MainFrameDlg.cpp 文件中的：521 0001:0005976d，而程序实际崩溃行在519（注释行和空行也要计算在内），非常接近实际崩溃行了，考虑到程序实际执行的是汇编指令，我们可以在(516 ~524)行区间内寻找到实际崩溃行。

3.6 无法定位崩溃的情况

但是这种输出文件的方法也不能定位所有崩溃问题，俗话说得好：没有万能的救世主。

例如我们有时会碰到下层编解码器崩溃，崩溃打印如下表：

======================== 崩溃信息 ==========================

崩溃时间： 2009/05/07 09:48:17

崩溃原因： 非法内存 *** 作

异常代码 = c0000005

异常地址 = 0x02163b32

异常模块: C:\WINDOWS\system32\kdg7221.acm

Section name: .text - offset(rva) : 0x00002b32

---------------------- Trips of Stack ----------------------

C:\WINDOWS\system32\kdg7221.acm

这时可以看出是我们的音频解码器kdg7221.acm崩溃了，此时就要考虑我们的音频编解码参数是否设置错了，如果没有设错，bug可以转到媒体处理层或者软件一部处理。

---