这个思路不错，确实发广告的基本都是批量广告，普通账号日常也就 1-2 个可能被识别为广告。

估计是。但这样计算个人觉得不合理。如果有 100 个，那最后一个批次的 10 个，tps 就是 10/10=1 了，这样 100 个的平均 tps 会比 10 低不少。

但实际上，服务的处理能力并没有下降过，一直都是每秒处理 10 个事务，只是因为有等待，导致响应时间增加了（在题目的理想模型下）。tps 应该只和本身性能有关，这样才符合当 tps 达到本身服务能力上限后，再增加负载 tps 会持平，而响应时间增加的现象。

集思广益，有想法都可以提出哈~

常规手段（敏感词等）都有自己的一些缺陷，而且我们缺少专职内容审核人员，所以全内容审核也比较难做到。所以需要一些非常规但成本又不会很高的手段。目前我们自己想到的主要是强制绑定微信账号，但也想看看有没有更好的想法。

这是一种方法，但也容易发现和绕过。之前见过有的广告贴末尾加一段红楼梦里随便找的 100-200 字的片段，估计就是绕过这种限制用的。

实名制个人觉得确实是一个可操作的点。当然不是说直接让大家给身份证，而是用微信之类做绑定，由微信帮我们创造给这些非正常用户的注册门槛。

问题 3 这个算法很神奇。第一次见到这么拆开求平均的 tps 算法。
平均响应时间公式也不大对，应该是 总请求响应时间/总请求数（10*2+10*1）/ 20 ，虽然结果一样，但意义不一样。

之前试过，有点太直接了，对方察觉到后稍微改下就绕过了，而且也影响了正常大家发帖（比如问个大会门票开发票的，可能就命中敏感词了）。

管理员已经在看到的第一时间删除，尽量减少影响了。
但发广告的基本都是凌晨发，而且手上都有不少账号屯着，不好解。

大家有什么好建议也可以发表下，一起想想办法

其实我的出发点是不能保证团队每个人的水平，只能靠流程来补充完善。

以前我也是这么想，人的水平参差不齐，通过流程规范，保障最低水平达到及格线。

但实践发现，人才是最关键的。流程要靠人落实，人不靠谱，再多流程也没意义（因为除非你持续监督，否则流程都是没有落实到位的，很可能只是装个样子应付领导）。所以最低水平不应该是流程保障，而是要人或者系统去保障。

对于防止人为失误，个人觉得与其加流程，还不如多做故障分享学习，让团队每个人都意识到这个点，自觉做好防范？

个人觉得，可以转换角度想想，那个 “普通却得到评优” 的项目，有什么地方确实优于自己，自己可以学习的？其他被评上优的项目，哪些方面做得比自己好？

也许这么交流一下，你会知道老板们或者说团队看中什么，也更明确自己下一步的优化方向。领导关注的一般是整体团队的提效，如果两个工具，一个是整个团队用的，提升 30%，另一个是只有团队里 20% 的在用，对这些人提升 50%。那这个时候，大概率会偏向于整个团队的，因为这个是整个团队评优，选这个团队的认可度更高，也就是俗话说的 “众望所归” 。但这不代表另一个工具就不好，只是对于 “评优” 这个场景没那么有优势。

非常认同 18 楼说的，评优啥的不是重点，没评上不代表不认可。用的那十几个人用得很爽，这才是对你最大的认可，而你自己过程中收获到的技能提升，才是最大的财富。

PS：建议可以和你直系领导多聊聊，你直系领导会更清楚评优等方面的考察点，如果他有意培养你，也会指导你下一步怎么去继续提升，最后拿到评优的。

所有和尝试相关的都变成测试工程师的事情

想问下和尝试相关的事情，具体是什么事情？既然都叫做尝试了，为啥会变成测试？
这个部分没太看懂，所以先不发表见解，避免走偏。

个人想到的：和正确性更高的进行对比优化。

比如选 100 道题，提前录入标准答案，然后每次调整这方面的功能后，都用程序对比搜出来的答案里是否有这个标准答案，权重是否比较高
或者楼上说的，和竞品对比（假设竞品正确率比你高）

还有一种方法，看用户的行为反馈。对于明显不正确的答案用户是不感兴趣的，压根不会点击查看。可以看下对于搜索结果，用户大多点击的是前几名的，还是会去点击几十名开外的。

没明白你说的准确率，具体是指什么准确率？

jvm-sandbox-repeater 对这个场景的解决方案是：把录制时查数据库的结果也一并录下来，回放的时候直接返回录制的结果而不是去查库。

这样每次用的都是录制那个瞬间查到的数据，什么前后依赖的都不用管了。

还有后续么？比如代码结构说明什么的，可以补充下？

别想太多，也许只是单纯想了解下而已。
我面试的话很少会这么问，因为我自己都不知道得到回答后对我决定面试结果有啥用。不管是突击还是本来就掌握，只要能力达到了就行。而且大部分情况下问几个问题就大概知道有没有做准备了。

如果说是面试者大部分问题都答不出来的情况下反问这个问题，只能说这个面试官不太专业。

不知道为啥楼主会有这感觉？大公司社招也不少的吧。

期待调整后的新文章。你这个场景应该对不少人还是有不错的参考性的。

看完感觉有点蒙，还是铺垫略少。大篇幅都在介绍平台本身功能，而且是按功能点介绍，不是典型使用场景。读起来略干。

作为这个工具系统我觉得没啥问题（是否叫 cicd 这个持保留意见，这只是个一键部署而已，离 cicd 还有一段距离），甚至能感受到这个打通系统后直接一键部署应该挺受欢迎的。

只是作为介绍文章，前面铺垫篇幅太少，读者不会把自己代入到这个场景，所以会产生各种 “这个人在干嘛，为啥要这么干，他这么干关我啥事” ，而不是 “这个问题我也有耶，这个方法真不错我也学学”。

恩，这个确实是 bug，可以复现。

比较神奇的是，如果再刷新下，这个问题就消失了。应该和点击跳转这个动作有关，点击跳转貌似是局部刷新，可能有些地方数据更新不大对，导致这个事件触发失败了。

我先记着，后面抽空研究下，是个挺有意思的 bug

特意查了下后台，这个不是 bug ，是 2 个不同的用户，只是刚好头像和昵称都一样：

对应你现在账号，在杭州城市里的位置是这个：

以前用的是 rest assured + testng

首先，json 只是个便利参数，检测到有 json 参数值会多做一步 dump 变成字符串以及加上 content-Type 而已，本质上还是会变为 data 往后走的。files 也是类似的做法。所有属于 body 的不同参数输入，最终都会转换成 data 传入 http body 里面。

可以看下源码里的 requests.models.PreparedRequest.prepare_body

然后，1 楼的也是一个不错的方法，每个参数都单独给一列，哪一列有内容就直接给到对应内容，没有就传 None 。类似：

代码实现起来很简单，直接遍历每一列有没有值，然后赋值就行。

最后，一定要按需实现，一个能满足 80% 需求的框架就是好框架，不用刻意追求满足 100%。excel 格式本身对于 files 类型就不友好（只能写路径不能直接写内容），multipart 就更不用说了（这种格式本身就很另类，body 里可以写多种格式的数据）。专注支持好 data、json、params 几种就很足够了（一般系统绝大部分接口的 body 是纯字符串）。而且你这个场景下，json 和 data 没啥差（都是字符串，所以 dump 出来都是一样的，只是会多加一个 content-type 的 header 而已），没啥好纠结的。剩下少量的 files 和 multipart 的接口，那就直接调用 request api 手写代码好了。

有尝试过改变环境么，例如申请权限，给开发和自己上司安利看日志的好处。

如果改变不了，建议还是考虑换吧。改变不了别人就改变自己。

感觉这个复盘是不是少了一个很重要的点，就是在发版流程甚至系统里监控 sqlite数据库进行了升级 这个改动点，如果有进行强提醒，让负责发版的同学引起警觉？

另外，升级这个场景，在大部分情况下，其实和新版本在老版本基础上覆盖安装差异不大，那是不是可以改为做老版本覆盖安装测试，甚至把这个流程做成自动化？

通过增加流程来控制问题，个人认为是下策。时间长了流程会越来越复杂，成本越来越高。而且流程的执行强依赖人，不同人执行质量也会有差异，这些都是会导致流程失效的潜在因素，也是风险。