结合实际情况,选择自己适合的方案。比如楼主面临的问题,我猜测会不会是现有的系统太复杂或者历史的原因,未必能提取出来系统的接口文档,所以没办法完全用 postman 或者其他工具,用纯 api 的方式去打通?
那么在这种情况下,你用更直观的 UI 自动化去完成前置的登录步骤,也是可行的方案。比如有些系统的登录是需要依赖 SDK 的,而 SDK 里面的登录未必能完全用纯 api 的方式去 call 成功。
原因确定了吗? 是编码的问题还是其他?
建议还是把原因,解决方案说明清楚,对自己后续回顾或者别人参考都有帮助;至于代码,有时候只需要把最关键的那行贴出来就可以了。
比如我猜是设置成 utf-8 那段起效果了。那么如果不设置的话,默认的编码是什么?更改了这个默认配置,对其他有没有影响?能不能解决其他常见的文件或路径的异常情况,比如目录名称有中文或者目录里面有空格?
感谢 testerhome ,在这个测试之家的几年里,学习到很多,也成长了很多。happy birthday!
没有测试过 c 端产品,不过个人觉得 server 端差别不大,主要区别在 b 和 c :
好像之前看过了这篇。
总结得很到位,把我们之前游戏支付的逻辑都介绍得很清晰了
使用什么时区是根据业务决定的啊,比如现在需要统计巴西的用户每天的数据,就要以巴西的时区作为零点进行统计,这里就会涉及到夏令时的问题。
https://testerhome.com/topics/27557
之前有类似的帖子
找了之前记录的两个印象深刻的 bug,提交参与一下
我司对背调就非常严格。重要的是:
其实当你发现了问题,不是应该第一时间提给开发,让他们去排查吗? 你如果有兴趣,再看有什么方式可以抓包,验证你的想法?
测试的第一职责是发现问题,汇报问题,确认和解决问题是开发应该做的,切记不要颠倒次序了。
有个疑问,这种解决方案,能适配到夏令时结束的场景吗? 比如说夏令时结束了,时钟要往回拨一个小时,能保证到时这个问题不会再出现?
我们之前也有遇到过类似的坑。我们当时是用的一个 Timezone 的 jar 包,直接通过城市格式来获取当地的时间。但是后来出现一个 bug ,就是在某一天开始获取的时区不对。后来排查发现,是那个国家的夏令时开始时间提前了,但是那个 jar 包里面还是旧的。通过升级 jar 包版本,解决了这个问题。
所以后来的工作之一,就是要确保这个 jar 包有更新的时候要及时更新部署,以获取最新的时区数据。
request 有对应的 cookie 包可以直接更新 cookie 里的值
其实 selenium 是这些基本操作不是很难,找几个常用的练习一下,遇到问题的时候再找解决方案,这样印象更深;
反而建议你花时间学习一下常用的一些框架或者模式,把用例架构熟悉起来,而不是一个方法里面把所有代码都撸进去了
学好英文还有一个好处就是选择工作的时候多一个外企的选项。
同意按具体的浏览器版本来选择对应的 driver,不过我觉得可以这么优化:
还是槽神一针见血
你看看两种运行模式,上面的是 pytest 下面的是 unittest. 所以你需要先了解这两种框架分别是什么样的,有什么特点和运行方式。
都决定不维护了还去重构,这是怎么被允许上线的呢?
你在用 pytest 写 case,为什么用 unittest 来运行呢?
试下直接运行 JS 代码 set value?
往往说得越全面的东西,越难真正落地坐到。写代码是这样,code review 也一样;
如果都是规则,是不是配到代码扫描工具里,让工具去实现更保障呢?
UI 的很多啊,可能是大家的 UI 自动化都比较稳定了,现在主力在做 api 自动化
平台是干嘛用的呢? 无非就是把已有的各种测试框架和脚本集成到一个比较美观的界面上面,让大家点点鼠标就能触发测试,看到报告,做一些牛逼的图表,甚至可以直接在上面写用例。
如果没有实际的平台需求,其实现成的 Jenkins 等工具就很方便,该有的都有了;实在想要放到平台上面的话,简单的做法也就是做一个触发,直接通过命令去运行你的 unittest。
就是 end to end, 端到端测试吗?
如果你只是为了其中的一个环节的改动,而且改动很小,对数据结构不产生变化,那么只需要对你的上下游做个对比测试就可以了,比如修改前后的报文对比;如果是改动比较大,对数据结构有影响,可能就需要做完整的端到端回归测试。