找到 BUG，并排除

RF 现在是不是比较少人用啦，请问一下是用在什么场景呢

了解到可能是因为出现线程阻塞，jmeter 所申请的内存不足导致的，尝试通过调整 jmeter.bat 中的内存参数

是 jmeter 申请内存不足，还是测试机内存不足了，后者是不是可以考虑分布式执行之类

这样穷尽的测试大概需要多少时间呢

先赞后看，前段时间忽然让做安全测试，可以学习一波

又是在评论中学习的一天～

大佬的日常 “烦恼” 吗

楼主说了前提是：确认是否有数据展示，应该需要增加简单的断言判断，不通过才截图吧

我昨天准备年终总结，结合年初计划，咦，我年初计划是这样的？？

我们团队，大部分都是前端优化，因为很长一段时间里后端工作量都大于前端，后端需要处理其他紧急的任务

最重要的还是需要和对应领导/主管沟通确认，结合实际业务的情况，确定这些问题或者规范是否需要遵循，还是说前端操作不报错就成

学习了，是不是中间还有三个参数被忽略了啊

我遇到的生产问题，基本就是邮件沟通较多，抄送的人也多，要说 原因，解决方案，避免措施啥的
不过可能正常流程按照一个 BUG 单来跟踪解决会更合理一些，也方便归档一些

学习了，虽然大多测试过程中 sql 用的都比较简单

事实上，a 组测试完毕的东西给 b 组测，确实可以发现很多之前忽略的问题，给我的感觉有点类似交叉测试

整体就业环境都不大好，当然也包含了测试

学习了，后续可以试试～

如果我和你一起共事，我肯定会向你学习，

会不会因为业务测试主导的公司，测试团队领导或者再大一层的领导没有这种意识，让人有种吃力不讨好的感觉（坐了也没法落地，测试事情有一大堆）

个人觉得能搭建测试平台，可以做白盒测试，自己做 ci 流程，12k 确实低了，还在一线城市…

不过可以去尝试面试一下，简单涉及和说明白可能是两码事，哪怕大环境不好，提前面试也清楚的知道自己的短板，厚积薄发～楼主加油！

是不是还的结合实际用的自动化框架来说呢，比如说基于 excel 的，或者数据库，这样自然就规定了哪些是必填的，那些是选填的，自然风格也就统一了🤔

打卡第六天 ~

可能也可以，就如上面所说的，有些测试精通业务，了解客户使用，更靠近产品侧，精通测试方法论，做测试分析，给与一定的测试指导，特别是对于一些有一定业务门槛的行业，应该还是很吃香的， 不过我好像不认识这样的人，只是觉得可行

打卡~

感谢回复，感觉说的挺全面的，先关注后期需要实践的时候再系统的看看~

就我所在的工作场景下，判断指标，确定压测场景，数据铺底，参数化这些肯定是需要做的，不过可能都比较粗糙，比如，

1. 数据铺底直接用压测脚本先跑几个小时，数据就达标了，最多的也就是十万 百万级
2. 参数化可能就是需要关联的用户，中间参数 (常见就是交易编号，审批编号啥的)
3. 业务场景基本就是基于客户历史的业务分布来确定了

对于瓶颈定位原因分析啥的，还停留在比较初级的阶段，只能找到现象，比如说 CPU 太高了，内存占用太高，垃圾回收太频繁，或者系统报错了，基本还是找开发解决，感觉路还很长..

这个是笔者最无法接受，但是被使用最广的理由。“写好接口测试后，加下并发数，就能测试性能了”，很多人如是说。如果性能脚本是这么容易搞定的，那我们分析业务模型、数据模型又是为了什么？撑的？

真诚请教，分析业务模型、数据模型指的是确定指标的过程吗？毕竟我也是很多人中的一个

PS : 今年我们也写过一段时间的 jmeter，主要是团队中的代码水平较差，而 jmeter + ant 比较容易上手，感觉遇到问题还是蛮多的，比如说 不能直观反映结果（用的是公司的 CI 平台），效果就是每次集成发邮件给你，还需要点进去才可以看到正确与否。再比如说 不能执行多个（文章里面也说到了），还有模板不好看，自己也不会改