官方仓库里好像有打 docker 镜像相关的命令在了：

https://github.com/metersphere/metersphere/blob/dev/Jenkinsfile

具体是卡在哪里了，可以给点错误日志或者详细的操作步骤？

可以看下这个：http://testerhome.com/opensource_projects/solox-apm-tool

哈哈，客气拉。这些其实都是很常见的问题，基本都有经历过，相互交流。

其他的功能测试本身也没什么好的办法优化效率，排除没有发现的摸鱼情况之外，也就只有堆人和加班两条路了

这个不知道你是否有深入去分析过？说实话，要缩短测试周期，从你作为测试团队 leader 的位置来说，最有效的手段还是想办法缩短测试自己花费的耗时，因为只有这个范围内的事情你是有比较强掌控能力的。方式包括我前面提到的优先投入到高优先级需求、分析现在测试排期是否合理有没有优化空间、用到的一些测试方法是否是最高效的等。功能测试提高效率的方法很多，写造数脚本缩短造数时间、根据实际质量要求情况舍弃部分操作成本很高的异常场景用例等，你说的这种不涉及逻辑的调整直接免测也是一种。

其次是控制你的准入，比如前面提到的提测质量，这个关守好，也可以减少很多非常影响测试进度的阻塞类问题。不过这个涉及和开发的协作，相对不如上面说的把控性强。

另外，这些非测试内部引起的阻塞测试进度的问题，实际占据测试周期中多少时间，可以大概统计下。在 15% 内应该都算正常，超出的话看下最慢的是哪类问题，让下面的同学再出现的话多久没解决直接上升给你去推动。

其实是一个 “尽快开始测试” 和 “优先结束测试” 的抉择。但不管是优先结束，还是优先进入，都不会缩短项目整体的周期，只是让测试开始到测试结束看起来变短了。

额，这个倒不是优先进入还是优先结束的问题，而是办事方法的问题。测试资源大部分情况下是稀缺的（相比开发资源），有限的时间内只能做有限的事情，那最好是做优先级高的。领导关注的、对业务影响比较大的，也主要是优先级高的事情，优先级不高的，一般引不起关注（领导的时间精力也很有限），就算产品找过来，说明是由于资源优先给了高优先级需求，一般也说得过去。况且这里面也有一些其实就算出问题也风险不大的，评估改动范围后直接让开发自测 + 产品验收也并不是不可以，这样总工作量也有所减少。

同时产品内部也有竞争，同时进行的关键需求也不在少数

不知道你们现在开发测试比大概多少，但如果测试人员数量真的连关键需求都 cover 不住，那就想办法找领导加人吧。

楼主说的这种情况，其实还是很常见的。

不过楼主的思维有点陷入了 “为测试慢找阻塞进度的原因” 这样的方向了，这个其实很危险。因为这个方向找下去，会发现找到越来越多其他人的问题（因为别人才会 “卡” 住你，你自己怎么可能卡住你自己呢？），而这些问题其实都是很难解决的，它的处理超出楼主自己管理范围。同时，在领导参加的周会上直接说其他团队没做好影响到测试效率，不知道楼主有没有提前把这些复盘内容提前和兄弟团队的 leader 沟通？如果没有，那相当于背刺兄弟团队，这个很危险。。。

我说下如果是我，可能会怎么做，仅供参考：

1、先了解下从领导的角度，为何会觉得测试慢，领导觉得应该是多久，为什么，然后说明下实际情况和领导想的理想情况差异是什么，针对这个差距自己目前在进行的优化计划是什么，让领导对这个问题有清晰且全面的了解。这时候如果领导能理解认同，就没必要花时间精力搞报告了，因为首要目标是扭转领导的这个印象，避免领导觉得测试单方面拖后腿。

2、如果领导不认可，或者要求需要报告证明，那就出报告。但在给领导前，会私底下先和兄弟团队聊，让兄弟团队了解自己难处，也了解兄弟团队的难处，两边一起合计怎么一起优化这个事情（甚至借汇报机会找领导帮忙解决，比如需求太多人手不足的问题，核心是要让兄弟团队感受到是同一战线的），再写进报告里。这样周会上汇报，兄弟团队也可以立即接上这个问题已经在优化中。

另外，楼主上面说的都是其他团队的问题，不知道有没有总结测试自身的问题？建议先集中精力优化自己掌控范围内的问题，产生成效。比如 “目前只能一个人负责一个需求的测试工作” ，这里其实本身就有问题。需求是有轻重缓急之分的，不能一人一个。关键需求（直白点说就是领导都很关注的需求）就优先集中资源优先完成，非关键需求可以按正常排资源测试，或者风险不大的，让开发演示场景测试结果后直接上线（类似免测）。

会有问题的。

所以一般发版是先发服务端，服务端全部节点更新完毕，再开始发客户端（只要新客户端不发，那就不用担心新版本特有功能的调用会被分配到老版本服务器）。如果实在需要包含新功能和不包含新功能两个版本并存，那可以配合请求 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，那这一个线程就会自动从第一个开始执行，执行完一个再执行完下一个，这样顺序就一定是固定的（因为只有一个线程，一定是串行不存在并行）。搞多线程，然后加锁去保障所有请求不并行执行，实在看不懂是为了啥。

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

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