哈尔滨手机网站建设,企业为什么需要流程管理,中国交通建设集团有限公司招标网,wordpress wpj1、问题bug定位技巧
首先#xff0c;作为开发也好#xff0c;测试也好#xff0c;定位问题有一个总的思路#xff0c;而这个思路是和数据的走向一致的。
大致是这样#xff1a;
用户层面问题 - Web页面/软件界面 - 中间件 - 后端服务 - 代码 - 数据…1、问题bug定位技巧
首先作为开发也好测试也好定位问题有一个总的思路而这个思路是和数据的走向一致的。
大致是这样
用户层面问题 - Web页面/软件界面 - 中间件 - 后端服务 - 代码 - 数据库
以下都以Web页面举例说明。
用户层面问题指的是用户自己的环境问题或者操作问题比如环境不通或者操作不正确。这种问题一般不是bug当然如果要考虑构建更加健壮的软件那么可以根据实际情况来决定要不要处理这类问题。
到第二步用户在Web页面进行正常操作时也可能会发现问题。这类问题一般通过观察以及利用一些常识可以发现比如样式问题一般是css的问题交互问题一般是js的问题文本问题一般是html的问题当然有可能是其他问题例如js生成html
到第三步Web页面操作后比如发出一个请求可能会进入中间件这个层面。我这里说的中间件是广义上的比如LVS、CDN、各种缓存服务器等等。
我们遇到过一个问题发现刚刚上传的图片进行读取展示时就读不到那么可以想到可能是负载均衡时将上传照片和读取照片两个请求分配到了不同的服务器导致的也就是我们常说的会话保持。
当然中间件问题有时候是和开发相关的有时候是公司其他团队负责的比如360公司就是OPS在负责。
当然中间件也不仅仅会出现在这一步实际的项目中可能还会用到更多的基础设施比如消息中间件、数据存取中间件等如果发现了相应的问题也就需要有对应的思路去排查。
接着再往下到第四步服务会转发到我们真正的后端服务层web服务器、应用服务器比如nginx、tomcat会收到请求。如果发现内存溢出那么就可能会定位到是tomcat配置的问题如果请求返回404也可能是nginx配置不当。
当然这个时候可能会遇到一些环境问题比如测试环境没有的问题到线上就有了很可能是环境原因比如jdk版本不同、tomcat版本不同、jar包版本不同等等。
最后一层是数据库。代码没有问题不代表软件没有问题。数据库层面也可能会有各种各样的问题比如字段的约束问题等等。
假如一个文本框的前端校验和接口校验的文本长度最大是50但数据表字段设定的是varchar(30)那么在存数据的时候肯定会报错。
再比如之前发现一个数据库的问题测试环境没有到线上却有了那么也可以看下是不是数据库版本不同导致的。
上面我们说的是问题定位的一个大致思路。每一个环节都有可能出现bug既可能是response的问题也可能是前端回调处理的问题。有的问题可能会直接暴漏在用户面前有些则可能需要我们去分析日志。 当然很多时候我们不需要这样一层一层去定位经验丰富的开发或者测试根据现象可能马上能定位到究竟哪里出了问题。
同时我也准备了一份软件测试视频教程含接口、自动化、性能等需要的可以直接在下方观看或者直接关注VX公众号互联网杂货铺免费领取
软件测试视频教程观看处 字节大佬教你逼自己如何在15天内掌握自动化测试接口自动化/APP自动化/Web自动化/性能测试内含项目实战 2、下面我们就来说说测试人员定位问题的N板斧。
保存现场
碰到问题先别忙定位首先请保存犯罪现场并且确认能复现。然后排除QA的低级问题 。为什么要保存现场
如果以后复现不了就证明不了问题的存在。有哪些QA的低级问题常见的就是hosts不对网络不通以及操作姿势不正确等等。这个其实就是上文提到的用户层面问题这里的用户就是QA人员。经常有QA人员发现问题后就赶紧叫开发过来看开发这时候幽幽地说句“host对吗”一看不对岂不是很尴尬。
还有一类问题就是脏数据我们有时候会遇到服务端报500错误查看日志后报空指针那么很有可能就是数据库中关联表的数据被人为删掉导致的。还有的问题是由于工具的影响导致的例如fiddler。所以发现问题您别慌让子弹飞一会确认不是自己的问题再说。
直观查看页面表现
这个就是上文提到的对Web页面的观察。不再赘述。
看状态码
4xx状态码一般表示是客户端问题当然也有可能是服务器端配置问题比如发生了401那么要看下是否带了正确的身份验证信息 发生了403则要看下是否有权限访问404则要看下对应的URL是否真实存在。
而5xx一般表示服务端问题。比如发生了500错误则表明是服务器内部错误这个时候要配合服务器log进行定位 发生了502则可能是服务器挂了导致的 发生503可能是由于网络过载导致的 发生504则可能是程序执行时间过长导致超时。
看服务器日志
如果发生5xx问题或者检查后端接口执行的sql是否正确我们最常见的排查方法就是去看服务器日志比如tomcat日志开发人员一般会打出关键信息和报错信息从而找到问题所在。测试人员要养成看日志的习惯。
并且如果将来进行开发也要养成打日志的习惯否则发现问题真不知道到哪哭去。
接口的请求和返回以及js执行是否有报错
在第3点中我们说了状态码的问题明确了4xx和5xx的问题所在。那么如果接口返回了200就一定正常吗
假设有这么一种情况要测试一个翻页控件翻到第二页的时候发现内容和第一页完全一样接口请求返回的是200。这个时候你会怎么排查
这个时候就要看前端发送的参数正不正常后端返回的内容正不正常即接口的请求和返回。
我们来看翻页控件的问题。我们看接口的请求F12控制台查看网络请求或者抓包工具一般根据开发的习惯会有pn、ps参数看看传值是否正确。
如果请求参数不正确那么就是前端的问题。 如果正确那么就看response看看返回的内容对不对以此就知道到底是前端问题还是服务端问题。如果发现js执行报错了那就是前端有问题比如跨域问题。
请求URL不正确是前端bug传参不正确是前端bug响应内容不正确则是后端bug。如果是响应内容不正确的后端问题那就要继续深挖是接口吐数据的时候出错了还是数据库中的数据就错了还是缓存中的数据错了如果用到了缓存的话。
经常见到后端开发人员有的负责接口有的负责写入数据库有的负责维护缓存所以如果发现是后端的问题可以更进一步确认下是哪块的问题。
开发提供可测性支持
有时候涉及到多方面合作不太好测试的情况下需要开发提供可测性支持。比如要查看接口给另一个接口发的请求是否正确可以让开发打印出完整的请求log。还有一些逻辑开关、修改页面数据条数等都属于可测性支持的范畴。
配置的问题
很多时候bug不是代码问题而是tomcat配置、nginx配置、jdbc配置等的问题。在这个层面上测试人员最好能够了解下它们的各项配置在发现问题后可能就会想到这方面的问题。
经验法则
太阳底下没有新鲜事有经验的人早就遇到过相同的问题。高手往往能够一眼看穿表面现象内部的问题然后直奔主题迅速报告或者解决留下别人在风中凌乱……
当然我们在发现问题或者定位到问题原因后一定要进行一步就是再次确认问题。所谓确认问题就是弄清楚问题是否每次都发生还是概率事件或者是工具相关的问题比如换个浏览器是否依然出现如果换个浏览器不出现的话很可能就是前端的兼容性问题。
比如翻页控件我们待测的系统有很多页面都有翻页控件那么就要看下是否每个页面都会出现这个问题进而报bug时进行统一说明也更加方便开发人员批量处理防止漏改。
以上是对问题的初步定位。对问题的进一步分析可能是更加体现测试人员素质的比如你发现了一个问题通过白盒测试看他的代码发现某一个分支的判断条件写错了并且把这些告诉了开发那么他一定会给你一个大大的赞然后说上一句小伙子靠谱和你合作很愉快
3、案例
例一点击页面的某个“修改”按钮页面弹窗提示“unforbidden”但需求文档中显示应该提示“没有权限”如何定位
这个问题要看弹窗中的错误信息是谁发出的。如果点击修改按钮前端发出了一个接口请求而该接口的response中有“unforbidden”那么说明前端的提示是后端返回的那么就需要后端去修改。否则就是前端写的提示。
所以有时候不能想当然地认为前端弹窗提示文案一定是前端的问题。具体问题具体分析。
例二修改某个表单中文本框内的文字并提交跳转到结果列表页后发现该文本内容显示不全该如何排查
这个问题的可能性有很多我们可能需要这样排查首先查看下表单提交时前端发送的请求中该文本内容是否正确如果正确就再去数据库中查看记录然后去看后端响应内容是否正确然后去看前端渲染是否正确以此来判断是前后端交互的哪个环节出了问题。
可以发现上面两个案例都没有定论都是得具体问题具体分析。我们只要掌握了分析方法和思路就能够找出来到底是哪里出了问题。
前端页面所看到的所有元素以及所有数据要么是前端返回要么是后端返回有问题了就看是谁生成的返回前端返回的就去找前端后端返回的就去找后端谁的孩子惹麻烦了就去找谁前后端就靠http来通信所以要多F12多观察前后端接口交互。
这只是经验总结并非标准。bug千差万别有时候需要一个一个分析。多修炼内功对业务系统的掌握测试方法以及开发技术。建设自己的bug知识库多思考、多积累、多总结。
4、文章总结
PS这里分享一套软件测试的自学教程合集。对于在测试行业发展的小伙伴们来说应该会很有帮助。除了基础入门的资源博主也收集不少进阶自动化的资源从理论到实战知行合一才能真正的掌握。全套内容已经打包到网盘内容总量接近500个G。如需要软件测试学习资料关注公众号互联网杂货铺后台回复1整理不易给个关注点个赞吧谢谢各位大佬
☑ 240集-零基础到精通全套视频课程 ☑ [课件源码]-完整配套的教程 ☑ 18套-测试实战项目源码 ☑ 37套-测试工具软件包 ☑ 268道-真实面试题 ☑ 200个模板-面试简历模板、测试方案模板、软件测试报告模板、测试分析模版、测试计划模板、性能测试报告、性能测试报告、性能测试脚本用例模板信息完整 这些资料对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴我走过了最艰难的路程希望也能帮助到你凡事要趁早特别是技术行业一定要提升技术功底。
