今天给大家带来{黑客24小时在线接单网站}，和软件测试常见问题的相关知识,如果可以可以选择收藏本站。
软件测试人员测试过程中如何分析定位常见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+项目源码】
全套软件测试自动化测试大厂面经
软件测试面试常见问题及答案是什么
一般软件测试的面试分为三轮：笔试，HR面试，技术面试。
前两轮，根据不同企业，或有或无，但最后一个技术面试是企业了解你“行不行”的关键环节，每个企业都会有的。
在平时的学习、工作中一定要善于总结，如果回答不好，面试官会认为你技术能力有限或者不勤于思考，是很容易被pass掉的。
简单为大家总结了些面试过程中经常会被问到的问题：
hr会问的几个问题
1.你觉得自己的优缺点是什么
2.你上一家公司的薪资是多少，调了几次薪
3.为什么从上一家公司离职呢
4.离职证明和背调可以吗？
5，你还有什么问题要问吗？
（这些问题都带坑！回答不好会死在这儿的，不知道怎么回答，可以百度下或者联系在线客服）
技术方面的问题
【功能方面】
1.你是怎样理解软件测试的
2.让你介绍你做的项目的业务流程
3.软件测试的流程
4..你认为什么是bug，说一下你印象深刻的bug，结合项目说一下你们公司有哪些类型的bug和bug评判严重程度的标准
5.如何保证软件测试的质量
6.如何保证你写的测试用例覆盖所有的场景
7.如果用户在正式环境发现一个bug，你在测试环境没有发现，怎么办
8.项目测试到什么程度就可以上线了
【场景方面】
1.让你写登录，支付，充值，购物车，文件上传，三角形，笔，水杯等的测试点（80%的公司会让你分析测试点！！！）
【计算机网络基础知识】
1.http协议的内容是什么?
2.请求头的内容有哪些
3.常见的状态码有些
4.http和https的区别有哪些
5.tcp和udp的区别
6.请描述下tcp的三次握手四次挥手的过程
7.网关的作用
8.osi七层模型每一层的作用
9.session是什么，cookie是什么，有什么使用场景
10.session和cookie的区别
【接口测试】
1.你认为的接口是什么
2.接口测试工具工作的原理是什么呢？
3.接口中包含哪些内容
4.接口用例如何写
5.你是如何做接口测试的，使用的什么工具？
6.接口自动化了解过吗
7.get和post的区别
【自动化测试】
1.可能会问到selenium
2.selenium元素定位的方式，显示等待，隐式等待，强制等待的区别等
3.接口自动化脚本的编写原理和过程
这块可以不用担心，只要会一些简单的就可以了，因为对于初中级测试来说，自动化是一个加分项，一般如果自动化掌握的很熟练的同学薪资是在12-25k之间的
【其他测试问题】
1.简述转包过程，你用的抓包工具是什么
2.如何分析一个bug是前端还是后端bug
3.url后面跟数据的话如何拼接上去
4.抓包的原理是什么
5.你们公司使用的bug管理工具是什么
6.弱网测试是如何实现的
7.web测试和app测试的区别是什么
8.给你一个软件你会如何进行测试
9.兼容性测试你是如何做的（从app 和 web两方面回答）
10.冒泡排序之类的一些代码题
11.如果在正是环境发现bug测试环境没发现怎么办
12.如果有一个bug，怎么判断这个bug是前端代码导致的还是后端代码导致的
这些问题回答的正确与否直接决定了你能否留下，甚至能拿多少薪资的问题，多回答对一个问题，就有可能多为自己争取到500-1000块的工资呢。如果不知道怎么回答，可以私信细聊哦！
软件测试BUG的种类和种类定义
复制的 希望对你有用。、 软件缺陷1、概念：软件缺陷简单说就是存在于软件（文档、数据、程序）之中的那些不希望，或不可接受的偏差，而导致软件产生的质量问题。按照一般的定义，只要符合下面5个规则中的一个，就叫做软件缺陷。 软件未达到软件规格说明书中规定的功能； 软件超出软件规格说明书中指明的范围； 软件未达到软件规格说明书中指出的应达到的目标； 软件运行出现错误； 软件测试人员认为软件难于理解，不易使用，运行速度慢，或者最终用户认为软件使用效果不好。 2、软件缺陷的种类（1）功能不正常（2）软件在使用上不方便（3）软件的结构未做良好规划（4）功能不充分（5）与软件操作者的互动不良（6）使用性能不佳（7）未做好错误处理（8）边界错误（9）计算错误（10）使用一段时间所产生的错误（11）控制流程的错误（12）在大数据量压力之下所产生的错误（13）在不同硬件环境下产生的错误（14）版本控制不良所产生的错误（15）软件文档的错误3、正确面对软件缺陷在软件测试过程中，软件测试人员必须确保测试过程发现的软件缺陷得以关闭； 测试是为了证明程序有错，而不是证明程序没错。不管测试计划多么完善和执行测试多么努力，也不能保证所有软件缺陷发现了就能修复。有些软件缺陷可能会完全被忽略，还有一些可能推迟到软件后续版本中修复。有些软件缺陷不被修复的原因如下。（1）没有足够的时间（2）不算真正的软件缺陷（3）修复的风险太大（4）不值得修复（5）测试误登记 4、缺陷的分类按严重程度划分：严重、较严重、一般、建议 严重：系统崩溃、数据丢失、数据毁坏 较严重：操作性错误、错误结果、遗漏功能 一般：小问题、错别字、UI布局、罕见故障 建议：不影响使用的瑕疵或更好的实现按优先级划分：最高、次高、中等、最低 最高优先级：立即修复，停止进一步测试 次高优先级：在产品发布之前必须修复 中等优先级：如果时间允许应该修复 最低优先级：可能会修复，但是也能发布缺陷的分类按测试种类划分： 逻辑功能类性能类界面类 易用性类 兼容性类
软件测试BUG的判断依据有那些？
1、查看报错日志，通过日志分析，需要有一定的经验，并且有一定的代码基础，才能更好地定位问题。
2、查看数据库的数据，了解所测功能的数据表结构，测试过程中，查看数据库的数据，确认数据的正确性。
3、查看缓存（如Memcache、apc、redis等缓存）是否正确。
扩展资料：
快速发现bug方法
1、尽快熟悉公司的产品业务，根据产品的业务属性来熟悉产品的业务流程，这样才能迅速找出软件中存在的一些重要的缺陷，这样发现的软件的价值才是有价值的，否则即使能找到一些软件缺陷，那也是纯软件的缺陷，价值不大。
2、不用让程序开发员＂用户不会这样操作＂的观点说服自己，遇到这样的情况，要坚持自己的正确的观点，把这种现象作为一个Bug。
软件测试中容易犯的测试错误
虽然说我们在工作中一再要求大家要认真细心，但是对于许多的新手来说，依然会在不知不觉中犯错误。下面云南电脑培训就通过软件测试岗位做为分析案例，了解一下，一个软床测试新人都容易犯的测试错误都有哪些。
1.没有测试
我们很容易毫无原因地掉入这个陷阱。从现在开始，制定计划添加测试到你现在正在处理的代码中，并添加测试到将来的项目中。
2.没有从项目一开始就启动测试
我们很难再回过头去添加测试，并且可能需要改变架构才能添加测试，这样做终将需要你花更长的时间才能产出可信任的代码。从一开始就在项目的生命周期添加测试可以节省时间和精力。
3.编写失败的测试
TDD方法的普及将红—绿—重构的理念带到软件测试世界。这个理念常常被误认为应该“通过编写一个失败的测试开始”。其实并非如此。在写代码之前创建测试的目的是定义系统的正确行为应该是什么。在许多情况下，它是一个失败的测试(红色表示)，但它可能会通过一个非决定性的或未实现的测试来表示。
4.担心未实现测试
软件开发中的一个大问题就是，代码和任何关于系统实际上应该做什么的文档之间的沟壑。通过拥有一个名称中明确定义你终想要实现的预期行为的测试，你将从测试中得到一定的价值，即使将怎么写测试目前还不得知。
5.没有很好地命名测试
命名软件这件事出了名的很难做好，这同样适用于测试。关于如何命名测试有几种流行的约定。无论你使用哪一种都没有关系，只要你能够一贯使用，并准确描述正在测试什么。
6.让测试做太多事情
又长又复杂的名字通常说明了你想同时测试多件事情。单个测试应该只测试一件事情。如果失败了也应该在代码中注明是什么地方出了错。你没有必要为了知道代码中出了什么问题而查看是哪部分测试失败。这并不意味着你不应该在测试中有多个断言，但这些断言应该紧密相关。例如，一个查看订单处理系统输出，并确认输出中是否有一个单一项目以及它是否包含具体项目的测试，是ok的。但一个验证相同系统的输出的测试，既创建一个特定项目，又记录到数据库中，还发送确认电子邮件，就不行了。
7.没有实际测试代码
经常可以看到测试新手创建过于复杂的模型以及不能实际测试代码的设置程序。他们可能会验证模拟代码是否正确，或者模拟代码是否和真正代码做相同的事情，或没有任何断言而只是执行代码。这样的“测试”都是白费力气，特别是如果它们的存在只是为了提高代码覆盖率水平的话。
8.担心代码覆盖率
代码覆盖率的理念很崇高，但往往实际价值有限。知道运行测试的时候有多少代码被执行应该是有用的，但因为它不考虑正在执行代码的测试的质量，因此就变得没有意义。代码覆盖率在它数值非常高或非常低的时候，是挺博人眼球的。如果非常高，就表明，比起带来的价值，过多的代码可能正在被测试。非常低的代码覆盖率表明有可能代码的测试不够。因为这样模棱两可的意思，有的人就不知道单一片段的代码是否应该进行测试。我用一个简单的问题来明确这一点：代码是否包含重大的复杂性?如果包含，那么你需要一些测试。如果没有的话，你就不需要。测试属性访问器不过是浪费时间。如果它们失败的话，那么比起你正在写的代码，你的代码体系出现了一些更根本的问题。如果你不用看一段代码，就立即知道一切，那么它就不重大。这不仅适用于代码，也适用于你写代码。如果我们在任意点重访代码，那么它就需要测试。如果在现有代码中发现过bug，那就说明这一块的代码对其复杂性没有进行充分的测试。
9.着眼于一种类型的测试
一旦你开始测试，很容易只纠结于一种风格的测试。这是一个错误。只用一种类型的测试，你就不能充分测试系统的所有部分。你需要单元测试来确认代码的各个组件是否能够正确工作。你需要集成测试来确认不同组件是否能够协同工作。你需要自动化UI测试来验证软件是否可以如预期使用。后，你需要为任何不容易自动化的部分和探索性尝试进行手动测试。
软件测试碰到的问题举个例子
1、这个bug我这边重现不了
解决办法
Bug应该简明扼要，重点突出。如果描述存在歧义，一定要总结并尽快改进。有时会遇到概率性的bug，要告诉开发概率是多少，尽可能多的提供重现的条件。
在复现问题时，希望能大致判断几个问题点，然后和测试人员沟通下，需要如何捕获信息，捕获那类信息？是不是提供debug版本进行复现，或者根据预判的点增加打印信息版本进行复现？
2、这个不是代码问题，需求这么定义的
解决办法
需求也是人定的，如果觉得有异议，可以找需求人员询问清楚，为什么这样定义，把自己的想法告诉他们，看他们怎么决定。如果被需求说服了当然是最好的，如果自己还是不同意需求的看法，需求又不同意我的提议，那只能听他的，毕竟权力在他那里。但是我们可以保留交流的记录，证明曾经在这里发生过歧义。
3、这块是别人负责的，我负责的部分没有问题
解决办法
如果bug是由开发的项目经理来分发到程序员，那就是项目经理来面对这样的问题，而不是测试。当然，项目经理当然有项目经理的处理办法。可是，测试遇到这样的问题怎么办呢，把负责相关内容的开发都邀请到一个讨论组里，让他们自己讨论，这样更清楚，不必在测试这里中转。如果他们都觉得代码没问题，而我也有强有力的截图和真相，那就只有上交给上级领导，让他们来决定怎么解决。
4、有问题吗？（也就是开发不认为这是个问题）
解决办法
测试人员一定比开发要敏感，对bug的容忍度也要低一些。特别是一些不符合用户习惯的bug，开发总觉得无大碍。比如，一个列表默认的宽度太小了，导致初次打开，有一些内容被隐藏在后面，但是这个宽度可以手动调节。开发觉得问题很小，不影响功能，而且也有解决办法，所以不认为是bug。这个时候，就要发挥测试的本事了，嘴甜一点，说说好话，态度柔和一些。因为既然是小问题，解决起来一定不难，耐心地催开发的改过来就好。催一次不行催两次，记住态度一定要好。
5、用户不会像你这样操作的！
解决办法
用户怎么操作，谁都预料不到。我们不可能覆盖所有可能性，但是大多数用户会出现的操作，我们当然要测试。慢慢地把开发从代码的世界里带出来，带到用户的世界里，让他换个角度思考问题，毕竟软件开发不是为了实现功能，是要满足用户需求的。如果最后还是没能说服他，第一向上级反映，第二做好沟通的记录，将来备份在测试报告里。
以上就是软件测试中遇到的常见问题及沟通方法，如果觉得麻烦可以考虑用一些APP自动化测试工具
软件测试常见bug的介绍到这里结束，感谢您的关注，软件测试常见问题、软件测试常见bug的信息别忘了在本站进行查找喔。