要先了解你的测试需求是什么。
按你的描述，这个系统是会定时地去采集其他系统的信息进行分析。那我猜测大概可以往这些方面去考虑：

1. 采集的频率是否可以设置？如果设置成最低的采集频率，是否会对服务产生性能压力？
2. 采集的数据量是否会根据被采集对象的实际设置或者埋点发生数据量的变化？同样的问题，会不会同时需要采集多个被采集对象系统，从而产生不同级别的数据量，带来不同的性能压力？
3. 数据分析处理产生的压力？

但是从你的疑问来看，我觉得你提到的这个系统很可能不是你的测试对象（第三方的服务？），所以还还得你先去确定和了解清楚你的测试对象和测试需求。

要不。。。你们众筹给领导换部新手机

打卡

接口和 UI 是两个层级的测试，现在讲求的都是要分层测试，你放到一起是为啥呢？
而且接口和 UI 应该是分开部署的，你也对应分开，会更灵活

哈哈，两年前的帖子被你翻出来了。
情绪每个人都有，工作中也好生活中也好，自己学会调节吧。当然也别委屈自己了

不如想想，如果你们平时的项目需要测试这几个接口，要多少工作量？如果把你估算的天数，换算成你的薪资成本（工资加公司给你支出的社保什么的），只值 1000 甚至只值 100？

自己项目的信息记得千万不要公开出来

你指的是哪一部分？ 只要环境 OK，Python 什么的都有，操作系统应该没问题的

三年薪资上涨 200%，你确定现在这个环境可以达到吗？

1. selenium 在一台服务器上面可以开多个 session 的，只要你的账号不存在单点登录的限制，理论上你可以设置很多个 session 去同时跑，减少执行时间。
2. 从用例执行测试角度入手，看下哪些步骤耗时比较长，尝试优化，降低单条用例的执行时间。

感觉楼主有点矛盾啊，标题是想用 fixture，但是又不考虑 pytest, 所以是 unittest 里面可以支持 fixture 吗？

其实 unittest 转化成 pytest 还是很快的，不知道楼主是基于什么原因，一点都不考虑 pytest 呢？

我记得楼主前段时间有发一篇三十五岁之后找到一家外企工作的帖子。其实楼主的这个经历，和这篇提到的各种敏捷团队，等等，都和我现在的情况非常相似。
我是三年前入职已经广州的外企，然后去年团队原来的老大离职之后，由我接手团队的管理。上面我的每一点，都是和老板，和开发团队沟通之后的感受。在老板的眼里，是真的不会关心你做得有多累，而是看你是不是真的把你的工作做好。这个自上而下也是成立的：你也不会希望你的自动化工程师整天在忙着手工测试，没有自动化产出吧？
所以还是要学会换位思考，把自己从一个尽责的团队万金油测试，转变成为一个管理者的角度和心态。不要想着面面俱到，把什么细节都做好，不到迫不得已，也别把自己陷进去具体某个难点里面去埋头苦干。发掘团队里面合适的人，把你的想法和任务分给他们去帮你完成。如果没有合适的人，说明的也是你需要培养或者招人，把团队的短板补起来。
管理不易，承受来自各方的压力也不易。与君共勉！

我觉得楼主的问题是作为 leader，对自己团队的规划和现状都不够清晰，不知道是不是也没有和老板沟通清楚？

1. 我都不知道你们测试团队在干嘛？ 开发这么提，说明他是不清楚测试团队的目标和现状的。但是你作为测试团队的 leader，为什么也答不上来呢？如果这个问题下次是老板在和你年终考核的时候问呢？ 团队可以做得不够好，可以有上升空间，但是重要的是要看到进步和未来的目标。这时候 leader 的计划与目标，总结和调整都很重要。

2. 我都在忙线上的事情，没有那么多时间参与自动化测试这些。 其实可以想想，作为测试 leader，这个回答和产出真的 OK 吗？团队可能是真的很辛苦，你作为 leader 也很累；但是如何客观评价一个人，一个团队的工作是否合格，不是看他做得有多辛苦，而是要看他是不是把自己的职责都认识清楚和完成。如果不是在自己该尽的职责上面埋头苦干，获得的可能只是苦劳，而没有功劳。

3. api 测试是开发的，不能算在测试头上；你的 automation tester 只是在学习，没有产出... 这些评价，你作为测试 leader 认可和接受吗？ 好像也没看到你在保护你的团队，据理力争？

个人建议你先找个时间把整个团队的计划，目标，和现状，难点什么的理清楚。长期目标是什么，短期目标先解决什么问题；落地的难点，找你的核心队友帮你解决；对外的难点，找你的老板帮你沟通。我觉得这是一个来自身边很好的提醒，好好想想自己怎么去做好这个 leader 的角色。

我也是基于这个官方教程去改造的，把保存的文件从 JSON 改成 pickle 就可以了

这不就是 selenium 常见的处理问题之一吗？ 而且为什么要写死坐标，不用考虑不同浏览器和分辨率的兼容性吗？

我们的做法是做个通用处理，如果元素看不到就尝试滑动，直到元素可见或者滑动到了底部为止。

感觉还是以前一样，直接显示 匿名 直观一点，已经不是第一个人理解错了

“你写出来的用例要让没接触过这个系统的新人小白都能够去执行！”

说实话这个观点和标准在现在已经不那么适用了。特别是对复杂的系统，你敢放心把用例交给小白去执行？没有一段时间的培训和熟悉，你敢信他能正确理解你用例设计的测试目的和测试步骤？

写用例是需要时间成本的，用例步骤，期望结果写的越详细，所需要的时间成本越高，维护的成本也越高。反而如果我们是以 “对系统有一定熟悉程度，并且接受过足够的业务培训和用例交接的测试工程师” 作为你的用例编写的标准，对成熟的团队反而是更有效的方式。

正好前段时间用 pickle 和 FileLock 做了这个改造，步骤大概如下（代码暂时没办法贴上来）：

1. 封装一个登录方法，并把登录结果保存到 pickle 文件中，同时通过 filelock 来做锁定保护。
2. 在登录的 fixture 中，先尝试去读取 pickle 中的登录结果。 如果文件已锁定且读取成功，就返回登录结果。这时候说明其他 session 已经登录成功； 如果文件已锁定但登录结果为空，则说明其他 session 正在登录但是还没完成。这时候会返回 none，并在上层做一个 30 秒的 for 循环进行轮询等待。 如果文件不存在，则说明还没有 session 尝试登录。这时候就调用步骤 1 的封装方法进行登录并写入登录结果。

指平台给商家打款吧，我理解

我理解之所以走人工审核，就是因为没有犯错空间了

思路就是封装一个登录的方法，然后把登录结果通过一个 pickle 的库，存到一个文件里面。
通过 fixture 去尝试读取这个文件，如果能拿到就返回已登录的结果；如果这个文件不存在，就说明还没有登录，就去登录一次，并且保存登录结果。

1. 改配置，只需要让他触发条件就可以了 2.真正涉及到数据量大的情况，考虑是否需要做性能测试

1. 为什么报错的原因楼上说了。我理解把 test_dict = {} 改成 self.test_dict = {} 才是同一个变量的方向。
2. 测试用例的独立性是很重要的，不同用例直接应该减少依赖。以你的登录例子为例，相信绝大部分的用例都是需要登录的，所以你需要考虑一下 setup 方法，或者 pytest 的 fixture，把登录提取出来共享给对应的用例，达到登录一次，所有用例都能共享使用的效果。

其实这种是属于硬件问题吧？ 而且大概率和施工场地的地面情况有关系？

如果套用我们软件系统问题排查的方式，应该先看看正式环境上有没有 log，然后根据 log 去分析原因，再到测试环境去重现问题，验证分析结果是否正确；之后就是修复问题，测试环境验证和回归测试，部署上线然后验证问题已修复。

但是在这个场景下，一般是没办法造一个一摸一样的测试环境出来模拟的（不可能建一条一样的路出来吧？）。所以最好的方式，还得去同一条路上找问题，比如浇一遍水，走一走看那些砖会有问题；或者从工程的角度，看是否使用的材料，施工方式，排水设施是否有改进的措施，等等。

首先问个问题：为什么同一个 ID 在不同表有不同的删除状态的情况？这是特殊需求要求，还是设计缺陷或者运维错误导致的数据错误？

如果这是个很明确的需求（从数据层面看，是最新加的数据被删除了，所以最新应该取上一个版本的数据），那么可以理解是漏测，但可能很难被发现。从设计角度也很奇怪，如果一张表里有很多同一个商品 ID 的记录，而且只会有一个价格是生效的，那么应该给它加标记，而不是通过是否被删除加时间排序来筛选。就好像价格一直在波动，我可能需要把昨天新加的价格挂上来，也可能把上个月新加的价格挂上来。这种情况下是不是直接去更新这个标记更保险也更直观？

而如果是后者，我觉得把责任往测试身上推就很勉强了。