国际化和本地化这方面的测试，我理解一般不怎么需要特意用 selenium 做自动化吧？毕竟大部分情况下，国际化和本地化大部分情况下并不会动到背后的处理逻辑，更多调整的会集中在展示方面的内容。

渲染是否正确这些，毕竟不是 selenium 自动化的强项。可以辅助用于快速遍历客户端界面，但判断是否正确可能人直接看，或者借助机器学习算法做一些自动判定的独立程序，可能效果更佳。

额，这个问题有点伸手了。。。我搜索引擎找了下，前几个结果应该都能满足你，你看下有没有合适的吧。

https://cn.bing.com/search?q=DB2%2F400+python&form=QBLH&sp=-1&pq=db2%2F400+py&sc=0-10&qs=n&sk=&cvid=287DC452D34541E9A19067917472D04A

如果你已经尝试了里面某些方法，遇到困难卡住的话，建议直接说明你的尝试和卡住的位置。

列一下你们已有的解决方案有哪些，以及这些解决方案后面会用于什么？

我理解只要能体现是属于开发方面的原因，他们需要优化，就行了。说实话，都属于比较低级的人为操作错误。

感觉你们聊的不是一个维度。。。

bug 指代的是结果。程序运行输出结果不符合预期称为 bug
而你前面列的 1-4 和开发说的 “外部原因” 都是在说原因，是指出现这个结果背后的原因。

bug 可以是外部原因造成的，两者不冲突。你想说的冲突，是不是测试认为这些属于开发人为操作失误导致，开发需要改进；而开发说是外部原因，即认为开发不需要改进？

底层貌似是基于 mobileperf ，目前貌似是只支持安卓。但楼主问的就是 android ，应该也够用。

我们内部有做了一个类似的取代 perfdog 的性能采集工具，支持 android + ios ，并打包成了独立的客户端应用可以开箱即用，但暂时没法开放。ios 的性能数据采集，可以考虑基于 tidevice 之类的逆向 instruments 协议获取性能数据的工具来做。

官方仓库里好像有打 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 的，可能里面会由于受限所以暗坑更多，仅供参考哈。