常用策略是限流排队机制。还有就是土豪办法,服务器多开一点,压测的时候,就保证 2 倍历史峰值的并发去部署硬件。
点赞
测开是为质量保障各个环节赋能
成都的有没有
前面的帖子有分享,可以翻一下看看
我想请教一下 流量回放怎么解决那些每次运行都有变化的字段,最经典的 比如时间戳 比如随机数 比如依赖的上游数据
比较朴实无华的回答是,针对产品文档的每一句描述都确定有一组对应的用例。主动考虑文档没有覆盖但是是常识的功能点设计对应的用例。这两个能坚决执行,那么基本能保证覆盖率到 95%。用例评审的时候再查漏补缺剩下的 5%。
事实上 实践中会发现自动化一般并不会节约成本,反而会因为脚本的频繁维护而增加成本.
你大大方方跟你主管商量 你想用空闲时间搞搞自动化
造数据归造数据的职责 不要用用例去造数据
我司项目组基本都是传统的 excel + svn
我司某个项目上线日期定好之后,几乎每个版本都延期
挺好的,支持一波
说虚的,本篇文章的标题就强调了,不是成果展示文章,而是分享困难
比如我拍卖行的上架商品的用例,前置数据需要依赖另外两个接口获取,获取之后的数据还不能直接用,还需要用一些逻辑处理下。
如果我想在用例里面写个判断逻辑或者循环逻辑,应该怎么办呢
既然开源了,直接看代码呗
请问有后续吗
压测业务逻辑用纯 json 配置去实现还是有些局限性,我们仍然是用代码去写的压测业务逻辑。其他的模拟机器人部分都大同小异。
公司会不会认为你有泄露面试题的风险?
设置奖励是个不错的办法,毕竟要求所有人都有自驱力是很困难的一件事。
期待人类通过生物或机械得到进化
线上 BUG 漏测数,是一个很重要的指标,直接衡量版本测试质量
没有 POCOSDK 的话,用图像识别试着做一做怎么样
SDK 部分 github 链接失效了