测试环境的 mysql 慢查询日志确实很容易误报或者说不准确。另外,mysql 不是已经有 general_log 查询日志了吗,为什么不考虑直接处理日志呢
确实是,开发打的 jar 包挺多外部 jar 包。时间关系还是先用 idea 生成参数放到 txt 来做吧
自动化比较难发现问题是对的,可是楼主做到了 95% 的覆盖率就不一样了,当然这数据水分有多少就不知道了,就算路径、场景覆盖很全,但是断言字段不全也是一个遗漏点。然后一些 bug 是因为各种数据产生的,按照常规的自动化数据也是发现不出 bug。
请问下楼主,有没有人工发现了 bug 但是自动化没检测出来呢,如果没有可能真的没 bug?
这项目排期就存在很大问题啊,83 天开发出 1 个版本? 我觉得最好拆开几个版本每两周交付 1 版,边开发边测试迭代才是正路
直饮水可以直接买矿泉水蒸馏水之类的吧,比水龙头的干净
浏览器代理设置你本机的 ip+8080,再请用浏览器请求测试端
其实转前端开发可以没那么累?
其实用例都有个人风格,如果一堆错误提示我就这么写,导图里写 “错误提示测试”,然后备注里写上所有提示,主要是告诉他们你会测到
细的不会写在用例上(太杂不方便评审和维护),但是测试的时候会对照 PRD 去测这些细的地方