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

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

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

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

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

也许这么交流一下，你会知道老板们或者说团队看中什么，也更明确自己下一步的优化方向。领导关注的一般是整体团队的提效，如果两个工具，一个是整个团队用的，提升 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数据库进行了升级 这个改动点，如果有进行强提醒，让负责发版的同学引起警觉？

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

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

个人经验，比较有效的办法还是把大项目按功能点拆细，这样一部分功能点早点提测，测试早点介入，整个项目周期可以相对缩短。

内网和外网是完全隔离的么？有即可以连内网也可以连外网的机器么？如果有，那利用那台机器就好了。

PS：你都纯内网到这程度了，就算通知到人，人也得到公司能连到纯内网的电脑才能去修复错误吧。这种通知有必要么？

日志监听：
python logging 模块提供的 handler 说明：https://docs.python.org/zh-tw/3/howto/logging.html#useful-handlers

测试结果监听：
unittest 可以基于 TestRunner 里面的 TestResult 来做，可以参考 https://github.com/SeldomQA/HTMLTestRunner/blob/master/HTMLTestRunner.py 里面 class _TestResult(TestResult): 这个部分的实现

看你做这个活动的目的。

如果只是分享交流，更关注分享者的收益（自我总结、锻炼演讲交流能力、提高在组织内部的影响力等）。可以找有比较不错经验或者最近表现出色的同学来做个分享，只要分享内容对团队有帮助即可，最好是实战经验的分享。这块可以 1-2 周来一次。

如果是培训或者技能提升，更关注参与者的收益。那建议有专门一个人或者一个小组去设计课程（比如 UI 自动化入门、性能测试基础等），然后 1.5 小时内，三分之一授课，三分之一现场小组练习，最后三分之一各组分享自己的练习成果和心得。这类课程的设计成本比较高，但一般在技能收获方面效果会比较好，参与者成本不高，可以一个月一次周期性持续开展获得更高收益。

至于做题考核类嘛，可能做比赛比较适合。我们之前组织过 code review 比赛，客观题比代码规范、代码片段中找 bug 的能力，现场 20 分钟完成；主观题给一段项目代码去模拟真实 CR ，提出意见以及优化建议，并实施优化，一周时间完成；比赛现场每组 5 分钟左右分享给出的意见建议和优化后代码，最后专家评委评分选出一二三等奖，发出奖品。不过比赛的成本更高，参与者和组织者都高，一般间隔时间最好是半年到一年。

技术上都可以，实际怎么做方便就看你想要达到什么样的效果了。

可以直接在日志框架和测试框架加新的自定义 handler ，每条日志以及每个用例执行结果都记录到数据库，网页做定时刷新，定时去拉数据库数据。

如果不想搞太多额外的开发，其实直接日志打印到控制台，jenkins 用 console output 看也基本是实时的。唯一缺点是没有最终报告格式那么好看，和 idea 控制台差不多效果。

另外，也建议考虑清楚这个需求的使用场景。大部分自动化测试的执行期间，是无人值守的，基本上都是跑完了一段时间，才有有空人看下报告，甚至跑失败告警了才有人去看报告。不一定有太多跑的过程中时不时去看一眼进展的场景。如果想知道进度百分比，jenkins 根据历史执行时间预估出来的进度条也可以作为一个不错的参考。

那可以换一种方式，在你的手机上安装测试应用？

能用沙箱或者测试账号最好，但如果真的非得用真实账号（如线上验证），基本就是要公司征集甚至考虑贡献自己账号了。

问题一，我也看不出来有啥错。不过我这个是 1 年前的 demo 了，不确定会不会是官方改了内容

问题二，我这周抽空再试试官方新的 repeater console 模块吧。老模块印象中没有这个接口，所以也没遇到过你的报错。

如果要涉及真正金钱交易，那就得真实账户了。

现在都实名制，如果你能说服领导贡献账号出来也可以，但大部分情况下应该还是用自己的比较便捷，至少有需要收验证码不用等别人。至于安全嘛，只要你及时注销没啥不安全的，反而可能会触发支付工具的安全策略（登录设备老是换），让你每次都得输手机验证码确认本人，某个角度说反而更安全了。