单车出行，通勤时间十分钟。

• 早：8:30 ~ 12:00
• 午：13:30 ~ 17:30
• 无加班，早中晚在家吃

L034 不用担心来人的影响，太小概率事件了，而且即使来人也无伤大雅，L035 倒车空间确实有点不足，只要化了车位紧急门就不重要。
还有，L034 是个图中唯一的一个独立空间，相信我，这个很重要！！！

没看太懂这个图，但如果车库入口是箭头处的话，无脑入 L034/L035
如果是其他入口，离这俩比较远的话，就选左侧靠柱子的完了

1.固定相机 + 身份证，确保每次都能拍到身份证
2.直接跨过拍摄过程，传入身份证图片
3.开发变更，关闭验证

想清楚为什么存在评审环节，你也就没有疑虑了

当年给 zf 甲方演示项目，项目垃圾到操作列表我都心惊胆战的程度，发现有个需求页面未做。
后续内部电话沟通解决方案时开发说：我给你 P 个图，你去演示下不就完了（很认真的说，绝不是开玩笑）
然后我就直接电话里开喷了

好一个待定！

那些上辈子创业失败跳楼转生做测试的，出来说话！！！

嘎嘎快，你好

趁年轻，换个 Country 吧，不要在存量市场里浪费时间了

首先开通一批账号权限，然后发给我，下周一你们就可以直接上线了

如果你能来份 HTTPS 的抓包教程，我就给你一键三连！

这就是大上海！

不用那么麻烦，我们先干他一万个并发，合不合理的开发自己分去就完了

不是沉浸在旧时代，是感慨现状。
现在大环境下 10% 左右的提升相比跳槽面临的风险来说性价比极低，不如维持现状了

但是这个比例的提升对大部分人来说也没有吸引力啊，除非现在的工作出了问题。
真难顶啊

针对上传类接口，通常会采用异步处理的方式来提高用户体验，即前端请求后后端立即返回响应，但上传操作还在后台进行中。
我的意思是：
1.两者响应时间过大，可能是前端你只关注到响应返回，而非文件上传完成。
2.Jmeter 则是监控的全流程，即请求上传到文件上传完成后的完整流程

我的第一想法是两者监听不一致，页面响应是正确的，上传类做了异步处理，提前响应；接口调用是监听的文件完成上传过程，也是正确的

很棒的一次测试，有几个问题请教下：
1.Influxdb 存储数据的意义是什么呢？是为了压测平台内的数据查询吗？
前面说性能瓶颈是在测试平台的数据存储上，当工具的性能对测试流程带来了负面影响，是否可以考虑舍弃？就比如 Jmeter 到 Influxdb 的 summaryOnly 选择
2.百亿级数据到百万级的压缩只是为了优化测试平台本身瓶颈对测试的影响吗？数据量的变化不会影响到数据本身吗？

别想这么多，多学习多了解就行

穷

看你的工资够不够就行

然后一杯茶的功夫，我们就可以智能退休了

3 个月完事了，升了也差不了多点