其实当你发现了问题,不是应该第一时间提给开发,让他们去排查吗? 你如果有兴趣,再看有什么方式可以抓包,验证你的想法?
测试的第一职责是发现问题,汇报问题,确认和解决问题是开发应该做的,切记不要颠倒次序了。
有个疑问,这种解决方案,能适配到夏令时结束的场景吗? 比如说夏令时结束了,时钟要往回拨一个小时,能保证到时这个问题不会再出现?
我们之前也有遇到过类似的坑。我们当时是用的一个 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, 端到端测试吗?
如果你只是为了其中的一个环节的改动,而且改动很小,对数据结构不产生变化,那么只需要对你的上下游做个对比测试就可以了,比如修改前后的报文对比;如果是改动比较大,对数据结构有影响,可能就需要做完整的端到端回归测试。
我会关心:
楼主用的是 robot framework 啊,你们和他说什么 pytest 呢。
楼主参考一楼的做法,设置保留多少天的记录就可以了。
你看我 GitHub requirements 文件里的版本吧,不过那都是 18 年的代码了,不知道后面的版本有没有变化
回复测试
这位仁兄说 1000+ case 执行时间要小于一小时,看来是没接受过后台很多复杂依赖的系统。以我司为例,做个登录可能都要半分钟,还隔三差五地挂某些服务。这种情况下我们能三个小时跑完,已经是非常好的结果了
如果用例之间不存在用户账号的限制(不会相互踢),那么可以考虑继续加线程。其实你说有八台机器,不知道是设置每台机器只跑一个线程,还是已经设置了多个线程?
我之前是在一个 selenium node 里面设置 10 个实例,执行的线程设置为 6,执行的情况还可以。
https://testerhome.com/topics/32469
推荐这篇<网易有道 UI 自动化探索与落地方案>,对大家的自动化整体方案落地和提升很有参考价值。
有没可能是你的 Excel 找不到或者没数据了呢?
怎么会呢,裁正式工的成本怎么都比裁外包要高吧