这个思路不错,确实发广告的基本都是批量广告,普通账号日常也就 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 。类似:
url | method | data | json | files | params |
---|---|---|---|---|---|
/a | get | page=1 | |||
/b | post | {"a":1} |
代码实现起来很简单,直接遍历每一列有没有值,然后赋值就行。
最后,一定要按需实现,一个能满足 80% 需求的框架就是好框架,不用刻意追求满足 100%。excel 格式本身对于 files 类型就不友好(只能写路径不能直接写内容),multipart 就更不用说了(这种格式本身就很另类,body 里可以写多种格式的数据)。专注支持好 data、json、params 几种就很足够了(一般系统绝大部分接口的 body 是纯字符串)。而且你这个场景下,json 和 data 没啥差(都是字符串,所以 dump 出来都是一样的,只是会多加一个 content-type 的 header 而已),没啥好纠结的。剩下少量的 files 和 multipart 的接口,那就直接调用 request api 手写代码好了。
有尝试过改变环境么,例如申请权限,给开发和自己上司安利看日志的好处。
如果改变不了,建议还是考虑换吧。改变不了别人就改变自己。
感觉这个复盘是不是少了一个很重要的点,就是在发版流程甚至系统里监控 sqlite数据库进行了升级
这个改动点,如果有进行强提醒,让负责发版的同学引起警觉?
另外,升级这个场景,在大部分情况下,其实和新版本在老版本基础上覆盖安装差异不大,那是不是可以改为做老版本覆盖安装测试,甚至把这个流程做成自动化?
通过增加流程来控制问题,个人认为是下策。时间长了流程会越来越复杂,成本越来越高。而且流程的执行强依赖人,不同人执行质量也会有差异,这些都是会导致流程失效的潜在因素,也是风险。