为什么测试工程师要了解bug问题发生的原因

大家好啊，我是大田。如题，产生 BUG 测试人员需要自己去分析原因吗？大田说说自己的想法：如果说到分析，最终肯定是开发查代码去分析，但是测试人员可以根据问题先做一个初步的定位。总体思路是：由测试人员初步定位，再协助开发复现，由开发分析代码，解决。1、如果是测试人员发现的 BUG，可以利用 F12 抓包、Linux看日志 log、查库对比等手段先分析报错情况，这几步基本能发现大部分问题。测试人员把具体报错原因给到开发，也能提升开发的工作效率；2、如果是客户发现的 BUG，先由测试人员复现，复现出来后，按照上述

测试完成后还有bug，测试人员肯定是有责任的，第一时间要赶紧处理而不是着急甩锅。但是这口锅全部扣测试身上，明显也是不能接受的，关键在于测试人员需要找出足够的证据来保护自己。 或许很多人会说测试不可能发现所有的bug，但是这句话在公司老板听来不过借口而已。软件质量由研发团队共同保证，测试人员是研发团队的一份子，而且还是专门负责质量的，你说bug跟你没有关系，怎么也说不过去。 所以出现bug后，不要直接甩锅，这样让人感觉在逃避问题。第一要紧事情是处理bug，尽量减少对用户的影响；只要用户影响不大，即便有责任

一、 软件测试的原则 1. 所有的测试都应追溯到用户需求 1.1 缺陷的源头 根据相关调查，软件缺陷出现最多的地方是软件需求规格说明书（即软件需求定义）， 而不是程序代码。 1.2 如何应用此原则 测试第一个任务是需求分析 测试需求分析要做好 时刻都要提醒自己考虑用户需求 制造缺陷的罪魁祸首不是程序员 做好需求评审 审查所做的内容是否符合用户的需求 2. 尽早启动测试工作 2.1 缺陷雪崩 2.2 测试的成本 2.3 如何应用此原则 测试应该早进行。 测试应该是与软件开发或维护工作并行进行的一

故事的主人公是被誉为计算机程序之母的格蕾丝·赫伯（Grace Hopper）。时光回到1947年，当时她正在为下图这个庞然大物编制程序。 这是世界上第一部万用计算机的进化版——马克2号（Mark II）。瞧瞧这庞大的机器，可想而知，格蕾丝不止要做脑力活儿，还得做体力活儿。 有一天，她正在调试程序（就跟我们在电脑上运行代码，看终端有没有报错一样），结果老是出现故障。 层层排查后，她拆开了继电器，结果发现有只飞蛾被夹扁在触点中间，从而“卡”住了机器的运行。揪出来之后，格蕾丝幽默地把这只幺蛾子的尸体贴在

身为测试工程师，总有一道绕不过去的坎就是定位bug，这其实是非常花费时间的。 也许有很多人不以为然，觉得无非就是发现bug后提交bug管理系统，描述操作步骤，预期结果和实际结果哪里不一致，然后继续测试。并不是说这样做的不对，只是说这样做的不够好，看似节约了测试时间，实则对于项目的进度没有起到应有的推动作用。 接着我就来具体分析一下吧： 如果是一个多

作为测试工程师最重要的工作产出，Bug Report（或者故障单、问题单）是测试工程师工作成果的直接体现，也是最能呈现测试工程师价值和能力的输出物。但项目干系人甚至测试工程师本身对Bug Report的重要性往往认识不足，Bug 单的内容及其提交方式、处理流程对项目推进、运作效率甚至团队士气都有重要影响。

软件测试工程师的职责是发现BUG，此外，如何体现个人价值？那么我们试想，只提出问题而不去解决，问题就永远得不到闭环。所以，一个资深的测试人员的基本功应该是这样的：深挖业务和功能需求，找出BUG，定位BUG，提出解决方案。这里我们就来说说，当我们找到了BUG，应该把BUG提交给谁去解决，这属于BUG定位的问题。 试想: 根据需求，用户头像应是圆形，但结果是方形，是谁的BUG？ 保存用户信息时，无法保存成功，也没有错误提示，最可能是谁的BUG？ 显然，工作过程中，我们不可能把这些BUG提交给同一个人去解决。我们

一、前言 相信不少，应该说绝大数的测试同学都遇到过这样的场景，上线出现了BUG，被质问： 为什么没测出来！ 测试怎么测得？到底会不会测？ 这对测试来说则是灵魂拷问级别不好回答的问题了。 那么我们遇到类似这样的提问该如何回答、解决呢？ （PS：觉得分享的不错可以点赞收藏评论一下，这是对我最大的支持！） 二、如何回答和解决 其实当遇到线上出现问题的时候，不管这个问题是谁的锅, 先以解决问题为主, 先复现问题, 再配合开发调试定位问题进行修复, 然后测试完成进行紧急的修复上线才是最应该做的事情！ 这个时候也不要

有人看到别人在侵淫面试技巧，什么《程序员面试宝典》，或者《面试测试工程师须知》等等，就会嗤之以鼻。他会觉得这不是“投机取巧”吗，最重要的还是踏实提高自己的能力。 非常同意这种看法，但是转过头来回顾现实，现在无论是学校的升学考试，还是企业的应聘面试，大多是类似的应试路线。从小学到大学，再到企业，培养了一批批擅长考前突击作战，应试能力颇高的“人才”。 抛开这种方式对于错，仔细观察一...

测试工程师不只是负责发现问题，除了发现问题这种基本功外，定位问题，提出解决方案，提出预防方案也是要掌握的技能。这里先说定位问题的要求，定位问题要向深入，前提当然是对功能、产品的流程、开发方案、开发人员非常熟悉了，以我们部门为例，定位bug至少要到下面这种程度。 首先确定是界面显示问题还是功能问题 如果是界面问题，如贴图错误，文字错误，样式错误，则需要截图。 如果是功能问题，控制台的问题至少定位到...

一个优秀的软件测试师不仅仅能够发现软件中的bug，还能分析出bug产生的原因。本文总结了一些软件测试入门必须要了解和学习的BUG基础知识，主要包括BUG定义、测试BUG的等级划分、Bug流程以及Bug解决优先级等内容。下面一起来梳理一遍这些基础知识吧！ BUG基础知识 1、BUG定义 软件的Bug也叫缺陷：狭义概念是指软件程序的漏洞或缺陷，广义概念除此之外还包括测试工程师或用户所发现和提出的软件可改进的细节、或与需求文档存在差异的功能实现等。 2、测试BUG等级划分 （1）Critical致命 通常表现为：

软件测试工程师如何去判断缺陷（Bug）如何规范的记录（功能测试面试必问!）开发不修改Bug的两个原因！

大家面试测试工程师一般问什么问题？

测试流程主要有三个阶段：需求了解分析，测试准备和测试执行１需求了解分析阶段产品同学主持需求评审会议，我们会把不明白不理解的需求在会议上说出来，包含需求的合理性还有需求的可测性等，产品这边解答，目的是让我们测试这边和开发对需求的理解达到一致２测试准备阶段会议结束之后我们开始准备测试工作，我们测试这边会写一个测试计划，分配每个人负责的模块，然后我们就根据自己负责的模块用xmind（思维导图）进行测试需求分析，分析测试点，以及编写测试用例。之后我们会在自己的组内评审，评审修改之后在项目组评审。

软件测试面试技巧

另外，当我们编写的代码导致之前编写的关联测试无法通过流水线时，去查找失败的原因以及修正这些错误也是隐形时间。反过来说，如果你对 bug采取的是零容忍的态度，甚至不惜把此写入 KPI 中，它也未必会带来正面效应，因为自此开始，没有人会愿意重构，没有人会愿意引入新的技术方案，道理非常简单：改动越多风险越大——这是某年发生在我所属团队的一次亲身经历。我们换来的只是打扫的速度，对制造垃圾的人产生不了任何影响，效果甚至会适得其反：考虑到总有人为他们收拾残局，我们的善后工作做得越好，他们越是会肆无忌惮。

在软件测试领域，能够快速准确地定位Bug根源的测试工程师，其价值是普通执行者的3-5倍。一个Bug从发现到修复，定位环节往往消耗60%以上的时间。本文将系统化介绍Bug定位的方法论体系，帮助你从现象看到本质。

背景：一家主要是做一款APP的公司，公司技术部门有三个组：爬虫组、服务端组和APP客户端组。

转载自：https://blog.csdn.net/zhusongziye/article/details/78106449 身为测试工程师，总有一道绕不过去的坎就是定位bug，这其实是非常花费时间的。 也许有很多人不以为然，觉得无非就是发现bug后提交bug管理系统，描述操作步骤，预期结果和实际结果哪里不一致，然后...