不如想想，如果你们平时的项目需要测试这几个接口，要多少工作量？如果把你估算的天数，换算成你的薪资成本（工资加公司给你支出的社保什么的），只值 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 的记录，而且只会有一个价格是生效的，那么应该给它加标记，而不是通过是否被删除加时间排序来筛选。就好像价格一直在波动，我可能需要把昨天新加的价格挂上来，也可能把上个月新加的价格挂上来。这种情况下是不是直接去更新这个标记更保险也更直观？

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

这个话题上次在广州的沙龙微信群里有讨论过，众说纷纭。
我们的做法：线上问题都会做复盘，各个角色拉到一起，把事情产生的来龙去脉弄清楚，找到哪些环节出现了问题导致了故障的出现。然后定下来针对性的改进项。
故障就代表着质量问题，那我们测试作为质量保障的重要一环，特别是最后的把关，肯定多少都会有责任。只是看这个责任的大小。
但是责任就是代表锅吗？其实未必。每个问题都会暴露流程的缺少，我们勇于承担责任把这个缺口给补上，其实就是把我们的分量和话语权提升上去了。都在讲左移右移，如果你平时得不到老板的支持，那么这些教训出现的时候你顺势提出来，说不定也能得到更多的支持。
当然，如果纯粹是测试用例少了关键场景导致的漏测，那就没什么好说的，该挨打的时候就乖乖挨打。只要态度端正，勇于认错和积极提出针对性的改进项，老板也不会怪太多。

个人的简单思路：

1. 不管什么改造，业务不能变。所以先保证功能和之前是一致的。回归测试，自动化测试先安排上。
2. 改造的目的，是这个系统改动的需求。所以同样的，要确认和分析需求。比如说有什么样的性能指标？改造后希望比改造前提升多少？性能测试麻烦安排上。
3. 其他可能的风险。改造之后，长时间运行之下会不会有性能的变化？两个系统的数据处理容量是否有不一样和风险？
4. 预警系统是否要随着一起修改？（原来要监控 Redis，现在要监控 mq? 两者之间的预警阈值怎么设置？）
5. 切换方案和演练。如何在不影响线上数据完整性的情况下做两个系统的切换？是否会对客户产生影响？ 如何在生产环境中做验证？ 如果切换过程或之后出现问题，如何回滚？

不知道你的 Jenkins 上执行不通过是什么表现。Jenkins 上关键也是看执行的 slave 上面是什么环境（selenium 版本，webdriver 版本等，基本上出现特殊的问题都和特定的版本有关）和你本地能执行通过的环境有什么区别。甚至说你本机也可以挂载到 Jenkins 上作为一个 slave 来做执行机。 所以你想：如果本地可以，为什么 Jenkins 上不行呢？原因大概率是环境和版本的差异。
建议你先别纠结无头模式，先把 Jenkins 上报错的原因找到和解决。

当你不知道怎么估总时间的时候，可以试下做 breakdown：把你各个测试阶段和模块拆分开来分别评估，然后汇总一个时间。比如测试方案需要多长时间准备？测试用例？数据准备？环境搭建？测试执行（拆分到每个模块分别多少时间）？回归测试？ 缺陷跟踪和验证？

我觉得这个体现的是你们的数据迁移没有拿出来讨论过怎么保证质量（不完全是测试的问题）。
关键是点在于：这是否是一个明确下来，很清晰的需求？还是只是开发想当然就去做的迁移想让也没有考虑过迁移的问题，以及数据完整性？
我觉得完整的方案里面，应该包含数据库的设计是否和原来的数据是融合的，比如表结构是否一致或者旧数据能完整地插入到新表？ 字段的长度是否一致？编码格式是否一致？迁移的过程是怎么操作的，是否有做过方案演练和回滚演练？数据迁移完成后怎么验证数据的准确性？是否有基于迁移的数据做过对应功能的回归测试？
如果前面这些都没人考虑过，也没有提出来过，而是直接在线上迁移然后等客户报问题，那么这整个方案都是灾难性的，测试组有责任但不应该是主要责任。