会有问题的。

所以一般发版是先发服务端，服务端全部节点更新完毕，再开始发客户端（只要新客户端不发，那就不用担心新版本特有功能的调用会被分配到老版本服务器）。如果实在需要包含新功能和不包含新功能两个版本并存，那可以配合请求 header 统一加客户端版本号之类的请求标记方式，让流量分配的时候保障新功能的流量一定分配到可以处理新功能的节点。

负载均衡的只负责流量分配，10 个请求过来后能按设定的比例分配给 5 个节点，就算实现负载均衡了。

它并不会去管背后的节点版本是否一致。实际线上节点比较多的话，发布期间就会处于不一致状态（有的还没更新在跑老版本，有的更新完跑新版本）。楼上说的灰度发布等场景，也会处于不一致状态。

一般说分布式部署，主要是强调它并非单节点部署吧。这种场景下，内部进行设计时就需要保障一些关键资源必须通过某种方式给多节点共享（比如一些共享的数据要放数据库、redis，不能只记录在自己内部的共享变量），同时一些并发机制也要特别考虑多节点间的协调（比如分布式锁）。

试了下，os.popen 返回的是连接管道的文件对象，所以只要管道建立开始运行了，就会立即返回，不会等管道里面的命令执行完毕。
如果需要等待命令执行完毕，得给返回值加上 read() ，进行里面的值读取，读取完加上 close() 方法关闭文件对象。

一般建议用法是：

# 通过 with 让文件对象在结束 with 内代码执行时自动关闭
with os.popen("cmd") as p:
    # 把命令执行输出值记录到 return_value 变量中，后续使用
    return_value = p.read()

另外，看你这里应该没有获取返回值的需要，建议直接用 os.system() 可能更方便。

有点奇怪，你的命令执行完正常不是文件已经生成完毕了么？

大猫还是有很多传奇经历的，值得大家来一听

好问题，本地试了一下，确实有这个情况存在，而且命令行输出只会有第二个问题，不会有第一个问题：

pytest t.py::TestClass_10000::test_one --html report.html --reruns 1
=========================================================================================================== test session starts ===========================================================================================================
platform darwin -- Python 3.9.2, pytest-6.2.5, py-1.10.0, pluggy-1.0.0
rootdir: /Users/chenhengjie/Documents/Projects/质效改进组/qa_repos/tmp/python_scripts
plugins: metadata-2.0.1, rerunfailures-10.2, html-3.1.1
collected 1 item                                                                                                                                                                                                                          

t.py R                                                                                                                                                                                                                              [100%]F [100%]

================================================================================================================ FAILURES =================================================================================================================
________________________________________________________________________________________________________ TestClass_10000.test_one _________________________________________________________________________________________________________

self = <python_scripts.t.TestClass_10000 object at 0x101d2d640>

    def test_one(self):
        print ("here is test_one")
>       assert 1 == 2
E       assert 1 == 2

t.py:14: AssertionError
---------------------------------------------------------------------------------------------------------- Captured stdout setup ----------------------------------------------------------------------------------------------------------
setup ---->
---------------------------------------------------------------------------------------------------------- Captured stdout call -----------------------------------------------------------------------------------------------------------
here is test_one
-------------------------------------------------------------------------------------------------------- Captured stdout teardown ---------------------------------------------------------------------------------------------------------
teardown ---->
---------------------------------------------------------------------------------------------------------- Captured stdout setup ----------------------------------------------------------------------------------------------------------
setup ---->
---------------------------------------------------------------------------------------------------------- Captured stdout call -----------------------------------------------------------------------------------------------------------
here is test_one
------------------------------------------------------------- generated html file: file:///Users/chenhengjie/Documents/Projects/质效改进组/qa_repos/tmp/python_scripts/report.html -------------------------------------------------------------
========================================================================================================= short test summary info =========================================================================================================
FAILED t.py::TestClass_10000::test_one - assert 1 == 2
======================================================================================================= 1 failed, 1 rerun in 0.13s =====================================================

从上面输出看，可以基本猜测下两个问题的原因：

1、出现了两次 setup 、teardown ——应该是 html 插件的问题
2、重跑时没有跑 teardown ——应该是重跑插件 runfailtures 的问题

这些问题都是比较细节的问题，推荐你直接看下这些插件的源码逻辑来解析，也有助于你更深入了解 pytest 的机制。时间有限我就没法去细看源码了。

1、左侧状态列表里的 up 显示还在 starting ，你查看下内部启动日志，看是否真的启动成功了？
2、不知道你的 192 开头 ip 会不会有错，如果你是在 docker 环境所在主机打开的浏览器，可以试试直接用 127.0.0.1:8081 打开。

曾经用过 cucumber 和 gauge 这类 BDD 或者 ATDD 驱动框架的路过。表示既要写 spec ，还得写实现代码，且 spec 有诸多限制要求，写起来真不如直接写纯代码 + 注释方便。可能运气一直不大好，没遇到过这类工具的最佳实践方式：产品写 spec，技术写代码实现。

楼主有在实际项目中试过用 BDD 的方式么？可以分享下项目中使用的优缺点，便于读者按需选择是否要采用？

无效具体是怎么无效？麻烦提供更详细的信息吧。

闪退自动收集信息这个，有挺多崩溃平台可以做到。

但你说的在 app 手动可以提交问题的，暂时没怎么见到过。有好的可以推荐下~

额，一般不怎么监控资源，意义不大。

monkey 测试目标是确认有没有崩溃点，所以应用有接入崩溃采集平台，能收集到崩溃信息就可以。

第四点要写数据走向这个挺不错的，你有个好师傅。

开始写总结是持续进步的开始，继续加油~

你是 docker 部署还是什么部署？有没有详细点的操作步骤信息？

分布式部署是把同一个版本的程序部署到多台服务器上运行。比如 Java 放的是 jar 包

这里的程序已经是代码编译后的结果产物了，除非是运行方式比较特殊需要放源码（比如 python 这类没有太多编译必要的），否则一般服务器是不放项目源代码的。

个人思路，仅供参考：

• 正向思路：现有的在客户服务器部署系统现在的流程步骤是怎样的，是否足够详细、明确，从流程本身看是否会有问题。比如部署是人工部署还是自动化部署？自动化部署是一个个软件装，还是直接一个打包好的镜像（含操作系统及各种配套软件）还原到虚拟机上？一般镜像还原相对还原度是最高的，其次是自动化，人工的话是最低的。

• 反向思路：做一下客户遇到的问题的归因分析，看大部分问题集中在什么位置，这些位置在现有的部署和验证中是否容易遗漏，能怎么优化预防它发生。

不过个人也没做过 ToB 的，可能里面会由于受限所以暗坑更多，仅供参考哈。

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

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

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

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

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

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"

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