软件测试人员测试过程中如何分析定位常见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主要还是在大家“游戏”的过程中，对游戏的每个功能进行游玩时发现的问题，因为游戏是经过编程制作的，每个动作和功能对应着相应的程序，发现BUG去找程序即可发现编程的问题。

1、需求分析、需求评审需求分析和评审就是分析客户的需求可不可行，需要怎么进行测试。

2、编写测试计划编写测试计划通俗一点讲就是什么人在什么时间做什么事，最后产出什么东西。那也就是测试人员要测试哪些模块、在什么期限内，提交哪些文档。

注意事项：

执行测试、提交bug、回归测试Bug就是缺陷，发现bug之后，要提交给开发人员让他们去修改，然后进行回归测试，验证开发人员有没有改好。编写测试总结报告Bug都改好了之后，要编写测试总结报告，这款软件的质量如何。

软件测试的主要目的在于发现软件存在的错误(Bug)，对于如何处理测试中发现的错误,将直接影响到测试的效果。只有正确、迅速、准确地处理这些错误，才能消除软件错误，保证要发布的软件符合需求设计的目标。在实际软件测试过程中，对于每个Bug都要经过测试、确认、修复、验证等的管理过程，这是软件测试的重要环节。

错误跟踪管理系统

为了正确跟踪每个软件错误的处理过程，通常将软件测试发现的每个错误作为一条条记录输入制定的错误跟踪管理系统。

目前已有的缺陷跟踪管理软件包括Compuware公司的TrackRecord软件（商业软件）.Mozilla公司的Buzilla软件（免费软件），以及国内的微创公司的BMS软件，这些软件在功能上各有特点，可以根据实际情况选用。当然，也可以自己开发缺陷跟踪软件，例如基于Notes或是ClearQuese开发缺陷跟踪管理软件。

作为一个缺陷跟踪管理系统，需要正确设计每个错误的包含信息的字段内容和记录错误的处理信息的全部内容。字段内容可能包括测试软件名称，测试版本号，测试人名称，测试事件，测试软件和硬件配置环境，发现软件错误的类型，错误的严重等级，详细步骤，必要的附图，测试注释。处理信息包括处理者姓名，处理时间，处理步骤，错误记录的当前状态。

正确的数据库权限管理是错误跟踪管理系统的重要考虑要素，一般要保证对于添加的错误不能从数据库中删除。软件错误的状态

新信息(New)：测试中新报告的软件缺陷；

打开 (Open)：被确认并分配给相关开发人员处理；

修正(Fixed)：开发人员已完成修正，等待测试人员验证；

拒绝(Declined):拒绝修改缺陷；

延期(Deferred): 不在当前版本修复的错误，下一版修复

关闭(Closed)：错误已被修复；

Bug管理的一般流程

测试人员提交新的Bug入库，错误状态为New。高级测试人员验证错误，如果确认是错误，分配给相应的开发人员，设置状态为Open。如果不是错误，则拒绝，设置为Declined状态。

开发人员查询状态为Open的Bug，如果不是错误，则置状态为Declined；如果是Bug则修复并置状态为Fixed。不能解决的Bug，要留下文字说明及保持Bug为Open状态。对于不能解决和延期解决的Bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。

测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决置Bug的状态为Closed，如没有解决置状态为Reopen。

软件错误流程管理要点

为了保证错误的正确性，需要有丰富测试经验的测试人员验证发现的错误是否是真正的错误，书写的测试步骤是否准确，可以重复。

每次对错误的处理都要保留处理信息，包括处理姓名，时间，处理方法，处理意见，Bug状态。

拒绝或延期错误不能由程序员单方面决定，应该由项目经理，测试经理和设计经理共同决定。

错误修复后必须由报告错误的测试人员验证后，确认已经修复，才能关闭错误。

加强测试人员与程序员的交流，对于某些不能重复的错误，可以请测试人员补充详细的测试步骤和方法，以及必要的测试用例。

---