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

比如你这里全部需求共用分支，且团队能力上没法保障这个分支质量保持稳定，就是一个对质量保障很不友好的分支模型。这个测试要主动去推，而且是要提要求。比如我之前说的那个情况，出现了同一个 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 的内容有没有匹配的？

fastbot 官方好像有交流群的，你到项目主页看看？

另外，如果是想在社区寻求帮助，除了一个报错信息，建议附上更详细的操作信息以及 fastbot 版本号等信息，像报 bug 一样完整阐述你的问题吧。

光一个报错信息，除了肚子里货非常多的搜索引擎，作为个人实在很难解答。

没太明白你想表达什么，如果是想协助解决问题，可以把你具体的操作步骤、报错信息等附上来？

这个可能会有比较多难点。

1、在控件内容（比如原来定位的 id）变了的情况下，怎么判断新的元素是用于替换旧元素的？这个我没想到什么比较固定的准则，实际项目里基本也是需要结合需求判断，有些不确定的需要找开发二次确认的。

2、如果不只是改控件，而是连布局、交互都改了呢？这种情况下可能不存在原来的控件改成了什么新控件这种一对一关系，需要改动的其实不只是定位元素，甚至用例逻辑都得改。这时候可能需要的是会自动生成用例，而不仅仅是维护用例的工具了，现阶段除了智能遍历类外，暂时没见到这方面有比较成熟通用的工具。

所以，如果界面元素持续变动很大的话，建议取消做 UI 自动化，或者考虑用录制之类的更便捷的方式生成用例。

偶现性问题的复现，我理解最有效的方式是：多试。

然后试了之后，不要只记录步骤（因为相同的步骤不一定能复现），还需要记录现场的所有相关信息，包括相关日志、内存 dump 信息等。

两个都需要。