“让我不要东想西想把测试设计这块拿下,以后往管理岗位转。”
这句话非常有共鸣!在工作这些年,别人对我说过这句话,我也对自己说过这句话,最近有个技术 leader 试图跟我说这句话,被我拒绝了,因为我要转测试开发。我曾经相信了这句话,放弃了技术学习,专搞项目业务测试那一套,等到跳槽时才看到差距。视野内的管理岗很多也都是技术大牛担任的,不搞技术未来发展会越来越窄,这不是说业务不重要,业务是开发和测试共同的基础,只不过测试相对来说技术积累少很多,导致容易迷茫看不到成长,换家公司就没用了。千万不要被别人定性了,也千万不要听所谓过来人,尤其是非测试的项目管理者的言论,有时候他们只需要听话的工具人而已。我也喜欢东想西想,现在除了想还在做,多实践,多写代码,多看看机会,把视线从公司放到整个市场来。
实在不喜欢测试,完全可以转开发,身边就有个妹子,也是被调到做测试,结果实在受不了点点点,转 C++ 了。
从生态来看,Java 无疑是不会后悔的选择。
奥你的问题是,经过参数化后的多个子用例,在分布式执行时,如何按顺序执行?这个貌似没有办法吧,分布式本来就是并行的,并行又要保证先后顺序。
分布式执行用例的设计原则:
用例之间是独立的,用例之间没有依赖关系,用例可以完全独立运行。【独立运行】
用例执行没有顺序,随机顺序都能正常执行。【随机执行】
每个用例都能重复运行,运行结果不会影响其他用例。【不影响其他用例】
.py 文件内部的执行顺序就是从上往下的吧,具体问题能再描述下么?
分布式执行用例的设计原则:
用例之间是独立的,用例之间没有依赖关系,用例可以完全独立运行。【独立运行】
用例执行没有顺序,随机顺序都能正常执行。【随机执行】
每个用例都能重复运行,运行结果不会影响其他用例。【不影响其他用例】
开源估计要等到明年了,哈哈,到时候应该会写个系列文章来从头做个偏学习的版本。
其实现在就是用 Git 管理的,走的 Pull Request,审核后再合并到主干分支,要做成平台是因为每个人的本地环境同步会稍微有点麻烦,开发也有跑用例造数据需求,平台能忽略这些问题,上手就用。还有一个重要原因是公司需要,领导需要,就找了这个折中方案。1 条用例是放在 1 个 test_name.py 文件来写的,就是为了避免多个文件依赖混乱的情况,这一点借鉴了 httprunner 一个 yaml 文件一条用例的做法。如果要改别人的用例,可以先复制用例再修改用例,避免影响别人使用。
好的,我试试,感谢建议,哈哈。
是的,部署没有说,前后端代码是放在 BitBucket 上面的,Drone 是 CI 工具,会轮询 BitBucket 的 Pull Request,自动拉取代码打包成 docker 镜像,通过运维平台配置域名和 Nginx 路由后,部署 image 到 pod,这一套是直接用的公司流程。K8S 这块确实可以优化下。
转成字符串
感谢各位大佬指点。已经和几个负责人沟通了,先解决项目估时问题,把 Story 和 Bug 收敛起来,严格控制发版代码质量,借助 Jira 统计评估是否发版,当收敛到个位数,主流程回归 ok 情况下,出测试报告,澄清测试内容和遗留问题。
再试试这条命令
pip install --default-timeout=6000 -i https://pypi.tuna.tsinghua.edu.cn/simple tep
现在开发想法是测试出报告,线上有问题,报告没写就是测试担责,测试写了就是开发担责。这个做法很慌
是的,初创团队,问题一堆。
每次发版三十个 Bug 没改,十几个 UserStory 没有彻底开发完,你们应该不是这个情况吧
测试报告 测试总结 这是要写 2 份文档
这么夸张 好累
测试数据放 yaml,为什么不直接用 HttpRunner
试试 pip install tep==0.5.3
呢
2021 流行 Java 自动化测试了么
点赞 相同技术栈 正在做 刚好借鉴下
我正在自己写 Vue + Django + DRF
我也没想到被加精了,从读者了解到,文章亮点是给快速搭建自动化项目提供了便利。
tep 只是一款测试工具,不像测试框架逼着你非得这么干,数据代码分离可以通过 fixture 来实现,取决于个人需求和代码习惯。
断言也是一个道理,严谨的话就加上数据库断言呗。
Python 转 Java 方向是什么原因呢
简单易上手,就是 postman 了。
感谢恒温大佬加精!