bug1之linux日志定位
- bug描述：创建一条数据提交后再去修改，修改后点击确认按钮弹出“XX参数配置不可为空”，且前端页面上没有相关字段让我去填写这个参数
- bug原因：F12抓包看请求和响应正常；日志定位tail -f ｜grep 关键字，发现有参数值为空，导致传参出错，所以把bug单指派给后端开发；
- bug解决：与后端沟通后发现，在开发环境修改数据后可正常提交；在测试环境会报错；经开发人员对比两边代码后发现，测试环境里的参数在一个对象里，值取不到；所以传参会显示为null，导致修改提交时信息报错；bug定位确认后跟进验证关闭bug；
- 启示：查日志定位bug，有助于和开发沟通，一定程度上提升bug的修复效率；
bug2之必填参数校验
- bug描述：新增入库单号是通过前端以当前时间段自动生成的，且是必填项，通过页面创建入库单时是没有问题的；但是API测试时，可以绕过前端页面必填的限制，当将入库单号设置成非必填项时，发现也能正常创建入库单，但是页面展示的入库单号为空。影响后面的查询入库单和出库等流程；
- bug原因：后端没有对这个入库单号字段做出必填项校验；
- bug解决：后端对入库单号做判空判断；
web测试抓包案例
前端字段取值案例
- 在Web端点击F12使用Google自带的抓包工具，准备抓包；
- 界面点击，再次向后端发起请求——这里示例是点击“查询”
- 第一步：分析接口前端有没有调对
在headers里拿获取到的url里的接口跟开发的接口文档(或接口管理平台swagger)比对，看前端是否调对接口；
- 第二步：检查前端开发取值是否正确——这个是开发经常出bug的地方
- 看接口文档中，后端开发对字段的定义——哪个是应缴、哪个是实缴
- 如应缴金额和实缴金额值一样，需要在linux查看接口调的sql，核对数据从哪个数据库表取值，手动改数据库字段；
- 从接口知道要去 estate-trade 服务查看日志；
- 首先要知道自己要去哪个服务的日志获取查询sql，服务的日志放的位置要问开发，同时自己也要有服务器的访问权限
- 敲下Enter开始动态查看日志后，web界面再点击“查询”，重新发起查询请求
- 数据库运行查询sql。顺带检查sql返回的数据是否符合业务需求+数据是从哪个数据库表查，取值是否正确的
- 从sql知道源数据从哪个表来，同时也校验后端开发接口取值正确；
- 如应缴金额和实缴金额一样，可以在数据库改对应字段的数值。但一定要记得校验完成后改回来
- 总结：检查前端取值要溯源
后端字段返回没有数据案例
案例描述
- 业务层面原因：原本的需求是A接口只统计A渠道的单笔缴费业务，B接口统计b渠道的批量缴费业务。后来实际实现中，B渠道也出现了单笔缴费业务，查询交易详情时，接口返回的业务单号为空。导致前端没法取到值，所以前端没有正常展示；
- 排查过程
- 打开web网页点击业务流程F12抓包-Network-点击对应查询链接
- 接口有返回，但前端没显示；
- 截图给前端；
- 前端答复：接口返回businesslist字段为空，导致前端渲染失败；
印象深刻的bug
考察求职者的问题定位能力、测试分析能力、测试知识面以及沟通能力
- 举例：系统A创建一个任务的时候需要上传一个文件，文件中包含了客户id，然后这些客户需要推给系统C；在推送的过程中导致客户丢失；
- 详细介绍问题产生的原因：由于客户文件推送的过程涉及两个定时任务，第一个是将文件推送到中间平台B，另一个定时任务是系统C获取这个名单文件；第一个定时任务执行后，第二个定时任务还没有到执行时间，第一个任务再次执行的时候把第一次上传的文件覆盖了；覆盖的原因是因为客户文件命名是根据年月日命名，所以会被覆盖掉。导致第二个定时任务拿不到被覆盖的文件数据
- 向开发了解，解决该bug的方法：举例：将文件的命名方式改为年月日时分秒命名
- 对问题的反思和复盘：举例：由于测试的时候，定时任务是手动触发，没有关注中间平台的数据。只关注了系统C是否能拿到数据；2、缺少对关联定时任务的场景分析；