这里的前端和后端也叫前台和后台。前台基本是能在页面上可看得见的错误,而后台是看不到的,如UI界面样式相关的错误不用判断肯定是前台的,用户数据问题基本是后台的。
前台一般的工作是获取、加载、计算、渲染数据,后台主要是通过接口直接请求数据或者回写数据,有时候需要通过判断接口的类型和逻辑才能更好的分析是前台还是后台问题。
最简单偷懒的方法是遇到问题就跑去问开发同事,“哥,这是啥问题?”,这当然不符合测试人的风格,也不利于提高自己。
最常用的方法就是通过抓包工具(Fiddler、Charles)或PC端浏览器自带的F12来判断,如下是遇到问题判断到底是前台还是后台的常规思路:
1、看前台是否请求了相应的接口,如果没有按照要求发送请求接口得到的结果肯定不对,此类为参数错误是前台的问题,否则下一步。
2、根据开发或产品提供的接口文档对比,查看请求中的请求头和请求参数忘记带数据或传入的数据不正确,则是前台问题,如果正确仍需下一步。
3、前台按照需求要求的接口进行请求了。查看接口响应的状态码,如果响应的状态码是4开头的一般是前台问题,5开头的一般是后台的问题,如果状态码是200则说明请求成功,没有报错则继续下一步。
4、前台按照需求要求的接口进行请求了,接口返回正常,但是返回的值与页面显示不一致或页面没有显示。如果是接口返回与预期返回不符合则是后端问题,如果是前台显示把值写死了或显示的格式与后台返回的数据不一致则是后台的问题。
5、另外有遇到必须调用接口A拿到权限后才能访问接口B的,前台直接调用B接口且调试成功则该问题既是前台问题也是后台问题。
6、另外的特殊情况:前台需要收到后台的通知才会出发接口请求,这种情况抓包工具抓到通知就需要查看日志看后台是否发送了相应的通知,前台是否接收到了通知来判断是前台还是后台的问题。
如果经验经验丰富了,其次还有很多种方法,通过查看开发代码,日志,通过PC浏览器的控制台、mock等,当然这些要求比较高,可以后续积累。
当然最好的方案就是提前做好接口测试保证后端没问题在做UI测试。
不能重现的bug?
最大的原因就是:测试人员对被测物的了解还不够深入。
那些被称作过“难以重现”的bug最后都可以分为如下几类:
环境的变更造成了bug难以重现,这里的环境包括了:基础软硬件环境(操作系统、网络、存储、中间件、容器等等),被测物自身发生了某些变更。环境的变更一般是由于多人共用环境造成的,也有少量情况下是系统内部或者时间触发的变更(这类bug非常难重现)。
没有找到真正引发bug的操作。这些操作往往是一些不怎么显而易见的操作,测试人员在不经意间完成,而又忽略了这一操作,以致难于重现bug。
没有找到真正会引发bug的操作序列。很多bug的重现需要满足多个条件。在满足多个条件的状态下,你做了对应的操作,bug才会被触发。
bug必须使用特殊的数据才会出现,测试人员没有意识到她使用的数据的特殊性。一种比较难搞的情况是:同一组输入,在不同情况下(不是不同的业务情况)输入会被转化成不同的数据。
测试人员由于错误操作,出现了误报(这很常见)。比如,记得自己执行了step3,其实没有,或者没有正确执行step却觉得正确执行了。
有的时候你差的就是那么一点儿点儿耐心。
团队协作:很多情况下,重现bug不是一个人能搞定的。我们需要测试环境ready,测试数据ready,各种监控、分析工具ready,各种不同的视角开拓思路、加深对被测试物的认识。这是team work!!!独行侠有时候很管用,但是终究有极限。这就是为什么CSI是一票人在做而不是一两个人在做。
一点儿运气:说实在的,有的时候重现bug就是靠运气,你不得不承认这一点。
Let it go:全试过了,连运气都没有。你只能放手,回到最上面我说的那两条了:找开发来帮忙,或者给开发报issue。btw,即使不能重现bug,也应该给开发人员提供更多信息:如log、dump文件、监控记录、屏幕截图等。做一个负责人的测试人员,把烦恼真实的留给下家,这很重要…
下面是我整理的2023年最全的软件测试工程师学习知识架构体系图 |
不从泥泞不堪的小道上迈步,就踏不上铺满鲜花的大路。纸上得来终觉浅,绝知此事要躬行。生活的激流已经涌现到万丈峭壁,只要再前进一步,就会变成壮丽的瀑布。
依靠天地不如依靠自己。俗话说,自助者,天助也。有人能够帮助自己,那是自己的幸运。如果没有人帮助,那是命运的公正。
人生的秘诀,就是寻找一种最适合自己的速度,莫因疾进而不堪重荷,莫要因迟缓而去空耗生命。