管理上司这个部分，好像没有太体现 “管理” 这个点。看起来基本都是怎么更好地配合上司。

个人觉得，向上管理里面，配合上司是需要的，也是基本的，但应该并不是全部。职场里面大家更多应该是相互协作达成一致目标，获得双赢。一味配合不一定能获得双赢，毕竟上司也有强有弱，如果上司的期望过高甚至不合实际，该提意见我觉得还是需要提的。

我理解向上管理的精髓，应该是怎么想办法影响上司的期望，尽量让上司的期望和你自己的想法计划保持一致，避免自己吃力不讨好？

项目实践才代表你真正掌握这项技能，能用到工作上产生价值。

比如考察是否有实际项目实践的经验和能力，我一般会抽问这些方面的问题：

1、【有效性】用例中断言校验什么？为什么选择校验这个？
2、【有效性】用例执行频率怎样，稳定性如何？不稳定的原因集中在哪，优化思路是？
3、【有效性】通过接口自动化，在项目中得到了什么收益（比如发现了什么问题，降低了多少成本）？现在这种方式如果你有机会改进，会如何改进？

4、【可持续性】单次需求用例编写/维护成本大概怎样？成本高的原因是什么，有什么优化思路？
5、【可持续性】用例中用到的临时测试数据目前是如何准备/销毁的？为什么采用这种方式？

实际项目中，这里面有些问题是没法用理论上的最佳方案的（比如断言校验），怎么因地制宜地选择最合适自己项目的方案，是一个实践中很重要的能力。这个是纯自己练手时练习不了的，也是纯看网络上的文章看不出来的。实际项目往往是在受环境约束的前提下，在成本和收益之间找平衡，done is better than perfect 。

以前没用过，临时查了下，根据个人理解写了下，如果有说的不对的请指正：

查了下 官方文档，临界控制器（Critical Section Controller）本质上是通过加全局锁的方式，让控制器内的子元素（别的控制器/采样器）同一时间只会有一个线程在执行。

从这个原理看，其实就是通过加全局锁控制并发。我理解设计目的应该是用于控制一些在整个场景中存在操作独占资源的时候，通过加锁确保这个独占资源同一个时间只有一个线程在使用（比如写同一个文件，控制无论多少个线程，同一个时间只有一个线程在写这个文件），避免出问题。而且既然用上了锁控制并发，意味着被同一个锁锁上的资源，是无法并发的（拿不到锁的线程都无法执行，只能干等着），最终 tps 会下降，我理解是正常的。

不过搜相关中文文章的时候，我也有点摸不着头脑。网上中文文章介绍的时候，都拿控制多线程下多个 http 请求在控制器作用下，最终一定会按指定顺序执行。我理解要保持最终顺序固定，最简单的做法应该是把线程数设置为 1，那这一个线程就会自动从第一个开始执行，执行完一个再执行完下一个，这样顺序就一定是固定的（因为只有一个线程，一定是串行不存在并行）。搞多线程，然后加锁去保障所有请求不并行执行，实在看不懂是为了啥。

最后，你这里的场景，我理解应该类似于每条记录要先写后读。如果每个线程的记录都是分开而不是独占的，那保障单个线程内顺序执行就可以，没必要保障多个线程一起跑时，还需要顺序执行。

话语权不够这个确实没有什么好招，持续想办法扩大自己影响力，提高话语权吧。加油！

提个建议，分支模型、测试环境这些会切实影响测试这边的东西，测试必须参与并把控好关键点。

比如你这里全部需求共用分支，且团队能力上没法保障这个分支质量保持稳定，就是一个对质量保障很不友好的分支模型。这个测试要主动去推，而且是要提要求。比如我之前说的那个情况，出现了同一个 bug 重开 1-2 次后，我当时就找开发 leader 说这个问题必须作为最高优先级优先解决。测试没有那么多时间精力去不断重复测试一个已经测试过没问题的模块。开发必须保障好这些已经测试通过的模块的稳定，而且开发老是花时间去修同一个模块重复出现的 bug，也很浪费自己的时间精力。

建议找下各个质量相关大会上一些音视频相关的议题分享看看，这些议题基本都是这方面的专家分享的知识，可能对你的指导意义会更大。

比如去年 MTSC 深圳站就有一个快手专场的分享。

我理解一个 shell 脚本就可以解决了？

打印时间用 echo date
筛选日志用 adb logcat | grep "aaa\|bbb\|ccc"

如果确实觉得很别扭，我会提。解不解决是产品决定的，但提不提是我们自己就可以决定的。

好像是本地缓存没有才联网，本地缓存有会直接读本地？

我日常用，很少遇到要等待。

这个，有点众口难调。。。从我个人角度，反而不喜欢新开浏览器，还得手动点关闭，不如直接鼠标按住左键右滑这个手势操作直接返回方便。

如果习惯新开选项卡，可以按住 ctrl 来点击，就会新开选项卡打开了。

没看懂，你这两个版本是两个分支的意思？

近段时间发现测试环境内频发一些基础功能无法使用的问题（新增/运行等类型功能），而这些模块在近期是没有新增需求改动的。
经与开发了解，发现是因多人多需求改动相同代码文件导致

1、没有新增需求改动，为啥会有多人多需求改动相同代码？这个逻辑没看懂，建议再问清楚

2、多人多需求改动相同代码文件，从版本管理角度最容易出现的问题就是代码冲突，以及某些情况下自动合并后的逻辑会错误。这个确实有可能导致质量很不稳定（以前别的项目也有遇到过，客户端并行需求，分支管理没弄好，两个需求共用一个分支，经常相互影响）。解决方法也很简单，既然需求是相互独立的，短期内可以拆分为两个分支，分别独立去测试，上线前再合并并回归一遍；长期来说大概率是架构有问题，存在某个超级类，啥逻辑都往里面怼，所以大部分需求都要改到这个类，需要想办法把这个类拆散，解决多需求会改到同一个文件这个问题。

man 用的很少，自带文档实在太长太啰嗦了。

相比 man，我更喜欢 tldr ，或者直接百度。

会哭的孩子有奶吃。如果你觉得自己现在能力值得更高的薪资，且绩效也确实不错（这个很关键，绩效一般的话，说明你能力从公司评价角度，还没有超出预期，一般情况下不大可能争取到涨薪，涨薪肯定优先给到高绩效的员工），该提就提吧。

图都挂了，楼主修复下？

你这种应该是工资倒挂了，其实还挺常见的，内部涨薪不如跳槽涨得快。我第一家公司也有类似情况，涨得比行情慢很多，最后还是跳槽才涨上去的，直接涨了快一倍。

现在既然已经提离职了，而且听起来你领导也不是特别想挽留你，你就不要思前想后了，破釜沉舟，全力去找工作吧。只要坚持，金子总会发光的。

除了常规招聘网站，建议也可以留意下社区招聘板块的信息，里面也有不少好机会，而且发帖的一般是内部主管，相对来说机会大点（至少不会在招聘网站简历可能直接被筛掉）。

加油！

时间有点久，不大记得了。解决了就好~

楼主有点冲动了，今年互联网行业这个大环境，找工作很难。

并且听楼主描述，像是为了涨薪而离职找工作，但自己能力却又并没有超出自己目前薪资的表现，所以很难找。提几个建议：

1、继续找，但短暂放弃涨薪这个要求，想办法进一个能让自己涨能力的公司或者团队。
2、考虑跨城市，不同城市薪酬水平有差异，相同的能力换个城市可能薪资就上去了（当然生活成本也上去了，需要自己综合衡量）

至于是否留在现在公司，建议还是以能力是否有可能提升作为一个核心衡量标准去考虑，从长远来说，薪酬还是和能力挂钩的。

没太明白，这里的数据有效性指的是测试出来的性能结果有效性（背后涉及设计出来的性能测试模型是否和实际场景一致、测试环境模拟度是否足够等），还是啥的有效性？你说的这个数据库断言，我理解是功能的正确性（即服务端返回成功的话，数据库确定是写入成功的，不会是假的成功），不像是有效性。

如果做数据库断言，理论上是会增大数据库的读压力的，但会影响多大这个不好评估，得看实际情况，比如这个查询复不复杂，是否命中索引、查询频率有多高等。

那不清楚了，没怎么做过微信小程序的自动化，不大了解。

受教了

我们这边服务端服务 app 为主，大部分场景需要请求多接口的话，没有依赖关系的都是直接并行访问，不大会串行。所以很少特意关注这里提到的用户请求的并发模型。

看了下，文章想说的应该是 LR 和 KylinPET 两者的录制能力差异吧，LR 录制后默认是串行，而 KylinPET 则是和浏览器的发送情况基本保持一致。确实从这个角度来说，LR 的录制能力不够 “拟真”

不过有个疑问，一般什么场景下的性能测试，会要求并发模型和单个用户浏览器访问的时候保持一致呢？而且用这个评估最大在线用户数，也有点说不过去？

“最大在线用户数” 这个概念本身就比较模糊，如果按 token 保持有效就算在线的话，那 token 最大存储个数本身就等价于最大在线用户数了。如果要加上服务处理性能，那得看这些用户在干嘛，用到哪部分接口，这个还得细分典型场景（大多数人用的场景）、特殊场景（预估压力会特别大但又真实存在的场景，比如大 V 直播啥的）啥的，很难一个 “最大在线用户数” 直接概括。

从报错信息看，像是 customfield_10301 这个字段无法识别。

确认过这个字段确实是这个 key 么？会不会写错了？

有没有试过去掉这个字段？

点个赞，细节都是魔鬼，能关注平台的体验细节，说明你是个很用心的人。

从截图看，有多个 webview 。建议可以看看其他 webview 的内容有没有匹配的？