可以用 mdc 存一个唯一 key,日志框架打日志的时候从 mdc 取这个 key 打出来,查的时候直接拿这个 key 查。顺序还是乱的这没法,除非你要打的都集中到一条里
最近也在测这些,基本都是测自己的业务,测 sdk 的各种回调
你的目标是衡量质量还是提升质量?提升质量要看具体的问题的,测试也不可能教研发少产生 bug,我们不是保姆
服务是 java 的话脚本也用 java 写会好点?正常这种工具类都有个公共的依赖,之前都是直接引用他们的依赖,自己写费时费力还得对签名算法
这些小游戏简直是逆天,铺天盖地的广告,晃下手机就进去了,质量还低的令人发指,看不懂这些怎么火的
那就不用慌,提前计划下未来那几件事
如果钱包没压力不如出去玩个爽,去年四月爽玩一个月。但是找工作也是真的心累
能根据需求生成测试用例?
我这因为测试结果没有入库,所以直接就是 AtomicLong
大佬这套流程能否开贴讲讲大概的实现,需要什么基建用到什么工具
话里有话啊 hhh
之前有过试运行大概两个月,效果不好。
一个是成本太高了,其结果都是人工在检查,一个版本仅一个服务大量的变更一个个看过去头都大,更不要说其他服务了,然后变更没覆盖到的都是一些兜底异常的逻辑,不走单元测试基本测不到,最后结果就是聊胜于无
第二个是对检查的人要有基本的代码能力要求,看不懂的人光看没覆盖到的只会去找研发问为什么哪里漏掉了,久而久之兴趣就下去了就没人搞了
9 号
大道至简
这个没必要搞个平台吧,既然在跑接口用例,拿接口跑几个订单和财务数据,直接读库校验就行,至于规则我理解是直接写死,又快又好使不是
23 年 4 月的时候面试也是这样
关于调用链分析有做下游服务的影响分析么,就是一个 rpc 或者 http 接口有被多少的服务调用
所以最终还是维护 mysql 表,这个就跑不了,用文件形式维护 sql 是可以的,但是为啥要去传 cos,直接放 git 里不行么,也好维护
读库用 json 存数据就行吧。不过是啥场景要把文件存 cos 去再从 cos 读,看描述是配置文件和库表有关联,直接读库不行么
看是什么业务吧,比如 saas 那种租户隔离的,这个还是有必要做,不管是后台的还是客户端一旦有异常数据在权限里,是有可能引起前端的报错,还有就是数据也可能被越权窃取。
如果是内部自己人用的系统,有问题也不会产生损失,不做也行
maven 的 surefire 插件可以配置 junit4 监听器,试试看?
对,这样你 setup 里面就没必要去初始化 genericService 了,你一次跑用例也不会全部接口都跑吧?
beforeClass 是多少测试类就跑多少次,所以会多次加载。把 beforeClass 换成 beforeSuite,保证初始化一次执行只跑一次就行。或者 genericService 换成懒加载单例,不在初始化里面生成实例而是用例里面去取实例。
感谢建议,做了什么和产出主要是放在简历,这里毕竟论坛,不详细写了=。=
毕竟测试干了四年多,舍不得 hhh