这种存在大量历史数据的项目恰好接触过,处理方法是:
1、一轮测试做空库测试,或者开发库进行测试【校验功能和新增数据的业务连贯性】。
2、二轮测试迁移数据测试,用你们政数局提供一个历史迁移库做测试,并且让开发把迁移脚本给你们【测试历史数据能不能兼容现在的业务】并对所有数据 BUG 的修改脚本留下记录。
3、最后上线阶段,开发迁移最新一版本数据的时候校验所有迁移脚本是否遗漏,二轮数据测试的脚本是否被同步。
简单业务这样做比较快,复杂的金融类业务还是前端更快。对这种系统来说,为了系统稳定, UI 几年都不会迭代一次,成本很低。
你只做了两个对比 禁用 or 不禁用,其实还有一个删除 3.调试取样器。如果还是复现你的问题,那就是你自己脚本有问题 。理论上调试取样器不会对结果有影响
嗯嗯 ,还有硬件配置。感谢
是啊,但是项目现场因为客户或者其他商务原因,总有改动,我们是远程连现场的,而且不是一个部门,沟通麻烦。所以才会想提测上规范他们。
1、通勤时间太长了,很影响生活质量
2、传统行业里面做 IT 缺点很明显,就是楼主提到的那些开发过程很不规范,做起来很恼火;但是也有优势,就是你把这个系统的业务逻辑吃透了,就可以活到退休,不用太担心 35 岁危机
如果要模拟真实场景,更推荐 LR,locust 好像不能在同一个虚拟用户下像浏览器一样同时发多个请求
强 学习了
看公司目前最需要什么专项测试,先掌握一项
个人感觉 “PPT 文化” 不会违反敏捷,挺多时候 PPT 能让人快速了解一个项目或者产品,反而比一堆干文档来的快;只要 ppt 简洁精炼就行。