简单总结，就是不要在最末尾真的开始搞绩效的时候才来关注绩效，日常各种早会、周会等都要保持好沟通，让员工自己知道自己绩效是好还是不好。

特别是里面提到的 “在主管心里，无论怎样都是有排名的” ，深有感触。刚开始只是带小组感觉不那么明显，当带一个 15 人以上甚至更大团队时，这个会很明显。同时基于这个排名其实也可以定期自己模拟一下给团队的同学做绩效评定，这样更清晰知道自己想培养的人现在有没有培养到位（比如能不能找得到真的比较不错的项目或事迹佐证他拿到好绩效），落后的人是否有及时沟通和给予机会，有没有人自己关注太少没啥印象需要关注下的。

看下整个磁盘的空间？运行过程中需要使用的不仅仅是 docker root 的空间。

也可以参考下这个：https://stackoverflow.com/questions/44634346/failed-to-write-all-bytes-for-bisect-so

就是一眼就能看出来的垃圾信息，比如可以帮开发票这些。

这个其实已经超出测试环节的范畴了。

毕竟准确识别违规内容，这玩意相比普通的测试，更接近于机器学习里面的分类问题了，而且进一步说，因为有商业利益在（SEO 权重高，就会被利用作为推广手段），对方很可能使用到安全攻防相关手段（比如直接木马注入，跳过所有的程序写逻辑防护），这已经不是单单测试可以搞定的了。测试用例防范的是普通用户的不规范操作或者程序可能出现的异常，但很难防范别有用心用户的精心操作。比如 Log4j 这个漏洞，估计 99% 用 log4j 的人都想不到这个使用姿势。

PS：最近学习了一个冷知识 零宽字符 ，有兴趣可以去看看，很可能公司自家的敏感词屏蔽没防护到这个。

对，堵住所有漏洞。

违规内容这个是红线，不能再碰了

是的，避免再出现违规内容。

我们一般是性能测试的时候需要对比竞品的性能数据，这样才知道自己在竞品中的水平情况。单纯一个绝对值看不出是好是坏。

不知道你说的是不是这个？不是的话可以说下是要测竞品的啥呢？

我用 macbook ，直接拷贝你正文里面的代码到 pycharm 文件里，直接运行，没有你这个编码的错误，只是有另外的语法错误，说明不是你可以看得到的字符问题，应该是你文件的字符问题。

coding 的声明你从哪里抄的？* 号前后应该是英文中划线，不是下划线。
可以看看这个：https://blog.csdn.net/zhongbeida_xue/article/details/81736671

另外，从报错上看，已经识别到 utf-8 编码了，但里面有的字符无法正常 decode 。建议你拿个 16 进制编辑器，看看到底这个在第 4 个字符的 0x92 是啥，把它删掉吧。

具体在 pycharm 里怎么跑的 pytest ，截图说清晰点？

https://cn.bing.com/search?q=UnicodeDecodeError%3A+%27utf-8%27+codec+can%27t+decode+byte+0x87&form=QBLH&sp=-1&pq=&sc=0-0&qs=n&sk=&cvid=1F5BB1D1958C420894799ECA8647F618

末尾的错误，搜索引擎一查就有很多说明了。猜测你的 0x87 是文件头信息，估计是你新建文件的编辑器自己加的，属于不可见字符，得用可以显示不可见字符的编辑器（如支持看 16 进制编码的）才能看到。

因为没有具体的问题，只能泛泛而谈一下。个人觉得总体的大方向是先在可掌控范围内（简单点说就是纯测试团队就能做的），控制住影响比较大的问题的出现（测试防护网）获得成效、得到认可；然后再逐步推动做根因解决/预防性工作，巩固成效同时，提高整体团队质量意识。

1、先了解现在主要有哪些问题，哪些严重影响业务，急需解决。列个优先级，并和上级、兄弟团队 leader 达成共识。
2、针对优先级达到最高级别的几个问题，先测试团队内部建立对应的防护网，确保不再把问题漏到线上（比如建立上线 checklist 保证这个检查点检查到位，这阶段追求质量先牺牲部分效率）。
3、根据防护网捕捉到问题的情况，复盘了解根因，从根本上解决/预防问题的再次出现。这部分的先聚焦解决已有问题，会涉及推动非测试团队配合，但只做最必要的，避免负荷调大兄弟团队不接受。
4、几个问题根因解决见效后，就可以把上述套路扩散到优先级稍微低一些的问题里了。同时也可以抽离里面的共性，逐步开始建设有梯度的质量体系，比如左移（需求质量把控、代码质量把控、代码逻辑 review 等）、自动化测试、右移（线上核心业务指标的监控及预警、核心接口巡检等）

会做自主优化是好事，长期可以持续保障代码的质量，毕竟赶需求很容易导致代码写得比较临时（比如各个配置项没抽离，各种 if 嵌套等），也叫做欠技术债。听楼主的描述，问题不是出在自主优化，而是出在临时插入不好安排，以及改动点模糊不好评估测试范围。

其实这个核心还是缺少流程规范导致信息不够透明，沟通不通畅。这类优化开发会觉得小 case 想简单处理，简单过头就变成无计划无规律了。如果说频率很低那还好，频率高还是有个流程规范统一一下，否则容易开发觉得测试效率低，测试觉得开发计划乱，双方都不满意。

建议你们的需求里增加一种类型，叫做技术优化类需求，提出者就是开发方。让开发这类调整都作为这类需求进行提出（注意不是提测时提出，而是在开始进行时就提出，和普通需求一样进入开发阶段前就明确提出并同步测试），并且提测时描述清楚改动点（直接附带 MR 更好，代码是最好的文档），这样整体测试的排期和资源安排就可以合理纳入，测试也可以有足够的时间根据改动点进行评估，如果改动风险低的甚至可以直接开发演示自测结果后，直接给予测试通过，减少测试投入时间。

大佬这个名字受不起，我的水平离真大佬还远着呢。。。

8 楼正解。你这个批量添加用户的场景应该是一个线程循环 200 次，而不是 200 个线程并行执行。

线程组的设定，直接截个图吧，200-0-1 没看懂具体每个数值的含义。

另外，你的截图只看到了 if 控制器，没见到哪个是仅一次控制器，也标识清楚吧。

可惜人没在上海，上海的同学不要错过啦。

没看懂讨论啥？讨论有啥框架能做，还是怎么设计框架让它能做到？

从做需求里也可以找点价值，比如需求做得更快了，有些流程比之前规范了之类的。

5 年的时候倒没什么困惑，当时还在持续上升期，在专注应对带团队、建设平台的挑战，没太多精力分散到 “下一个方向往哪走” 这个问题上。

@Before 的识别是 junit 执行器自己识别的。

要不你手动重新实现一个执行器，自动根据注解判定
要不你通过调用 junit 执行器提供的方法来执行指定用例，而非直接调用类里面的方法

对于第二种方法，百度关键字 函数调用 junit 也可以找到，参考结果：https://blog.csdn.net/haorenmin2008/article/details/44491331

httpclient 偏底层，实际项目用一般都要自行封装各种调用方法，否则用起来要写不少代码，太繁琐了。

RestAssured 相对顶层一些，底层其实也是通过调用 httpclient 之类的 http 库实现功能的，但函数封装比较好，调用起来没那么繁琐，并且集成了一些断言、AOP 之类的能力，在接口测试领域的常见实践都可以无需二次封装，开箱即用。

不好意思，由于人力有限，暂时还没做成员自行退出社团的功能。

不过目前社团的管理员有移除成员权限，可以先找找你们社团的管理员沟通下？

插一句，都详细到这程度了，与其用无法保障百分百准确且需要高成本建模的 NLP，不如直接用 BDD 呗？比如 calabash 这类 bdd 框架写出来的用例，本身就比较接近自然语言，且确保了可直接运行。

学习的过程中的确有很多速成的技巧，用以提升学习效率，熟练技能的使用。但这些是以各种弯路为参照物的，如果大家都是花了 1 万小时才能熟练掌握的技能，那就没必要去找低于 5000 小时的速成技巧。

这个点很认同。能速成成功的，大多都不是零基础。

我估计这哥们本身进度计划，就是花 1 天时间找这个问题的解决方案吧，要不着急的话不会愿意折腾这么久。真正优雅的方案不可能速成得来，都需要根据实际场景和相关技术原理，系统思考得来，这个急不来。