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：把你各个测试阶段和模块拆分开来分别评估，然后汇总一个时间。比如测试方案需要多长时间准备？测试用例？数据准备？环境搭建？测试执行（拆分到每个模块分别多少时间）？回归测试？ 缺陷跟踪和验证？

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

这是一个匿名，不是真的 何建雄。
原因是你回复匿名帖子的时候，默认就是以匿名回复（可能是你回复的时候没留意）。然后匿名的回复，就会随机给一个名字，何建雄就是其中一个。

1. 先确定怎么能从命令行执行？ 如果是 Python 文件，Python xxx.py 这种方式可以运行吗？
2. 只有上面的命令已经找到了，就可以配置到 Jenkins 里面运行。需要留意的是 Python 的版本和文件地址是否正确。

这个我之前遇到过，空格有可能是编码格式不一样。空格在 ASCII 里面的有 160 和 32 两个值，所以看起来都是空格，但是实际的 ASCII 值不一样。
我的做法是，把里面的空格都转码一下（如果是 160 就替换成 32，然后再来比对：

if ord(string_list[i])== 160:
   ord(string_list[i] = chr(32)

昨天也遇到了，Chrome 会报这个错， 换 edge 是可以的

因为我有点怀疑你是不是参考了我之前一个帖子里面的代码例子：

https://testerhome.com/topics/19035

第一个用例
访问百度首页并搜索 testerhome：

describe('My first test case for cypress',function(){
    it('visit baidu home page and search for testerhome:',function(){
        cy.visit('h
ttp://www.baidu.com') //访问url
        cy.title().should('contain','百度一下，你就知道')   //验证页面 title 是否正确
        cy.get('#kw')      //根据 css 定位搜索输入框
        .type('testerhome')        //输入关键字
        .should('have.value','testerhome')  //验证关键字自动是否展示正确
        cy.get('#su').click()   //根据 css 定位搜索按钮并点击
        cy.url().should('include','wd=testerhome')     //验证目标url 是否正确包含关键字
        cy.title().should('contain','testerhome_百度搜索')  //验证页面 title 是否正确
        cy.get('[id="1"]')   
        .should('contain','TesterHome')   // 验证第一个结果中是否包含TesterHome
        cy.screenshot()
    })
})

常见的测试准入检查项（开发提测的检查项）

1. 需求完成度。需求项是否已实现？ 是否完成了自测？
2. 部署完成度。是否已经部署到测试环境？ 数据、配置是否已经检查完没问题？
3. 提测质量： 是否有单测覆盖？是否通过了冒烟测试？

正如 恒捷所说，这个算不上底层了。
这种场景就好像改 bug 一样，如果开发连 root cause 都没有找出来，然后改了一下代码发现能跑通了，你也不放心说把你的 bug 直接关掉吧？

赛普拉斯

这里的代码是忘了改吗？

触发推送，只需要 call 对应平台（google-Android 自带的推送服务, apple -iOS 自带的推送服务,还有其他推送平台）的 api 就可以了。需要指定对应设备的 token，这块需要在 APP 端打开设置，并且从平台端初始化或者更新之后收集起来放到触发的脚本里面使用。

至于 APP 端的自动化，因为这个推送有一定的滞后性（特别在国内测试 Google 的推送，很难可以收到），而且一定要真机才能收到推送，感觉做自动化不好处理，成功率也不好保证。 个人建议可以通过脚本触发后，手工验证各个设备的接受推送和推送消息的跳转。

比楼主大一岁。19 年（当时 34 岁）准备换工作的时候，收到很多电话邀约，结果都是同一家公司的不同猎头，其他公司投了简历都没有回应。
幸运的是通过其中一个猎头，只用了一次面试通过，然后在现在的外企工作到现在。

1. 如果是可以直接在浏览器运行的，可以直接用 selenium，结合 Chrome option 设置需要覆盖的浏览器分辨率比例作为模拟。
2. 如果需要在 APP 里面运行，可以参考 appium，结合 native 与 hybird 的切换。

结合实际情况，选择自己适合的方案。比如楼主面临的问题，我猜测会不会是现有的系统太复杂或者历史的原因，未必能提取出来系统的接口文档，所以没办法完全用 postman 或者其他工具，用纯 api 的方式去打通？
那么在这种情况下，你用更直观的 UI 自动化去完成前置的登录步骤，也是可行的方案。比如有些系统的登录是需要依赖 SDK 的，而 SDK 里面的登录未必能完全用纯 api 的方式去 call 成功。

原因确定了吗？ 是编码的问题还是其他？
建议还是把原因，解决方案说明清楚，对自己后续回顾或者别人参考都有帮助；至于代码，有时候只需要把最关键的那行贴出来就可以了。
比如我猜是设置成 utf-8 那段起效果了。那么如果不设置的话，默认的编码是什么？更改了这个默认配置，对其他有没有影响？能不能解决其他常见的文件或路径的异常情况，比如目录名称有中文或者目录里面有空格？

感谢 testerhome ，在这个测试之家的几年里，学习到很多，也成长了很多。happy birthday！

没有测试过 c 端产品，不过个人觉得 server 端差别不大，主要区别在 b 和 c :

1. 载体不一样，对应的测试对象也不一样。b 端是需要依赖于浏览器实现，c 端本身就是一个软件，对操作系统的依赖比较大。所以两者对应的自动化测试技术和兼容性测试组合对象都不一样。
2. 实现技术不一样。b 端一般是通过 http ，c 端一般是通过 rpc ？
   
3. 升级测试：b 端是针对浏览器升级的测试，c 端自身还需要考虑不同情况下的升级？
4. 缓存？ 浏览器的缓存 vs 应用程序的缓存？
5. 性能相关： 内存管理？加载速度？两者技术方案不同导致的后台不一样的性能管理和支持？
6. 自动化测试： selenium 等浏览器端测试框架 vs 桌面端自动化测试工具？

好像之前看过了这篇。
总结得很到位，把我们之前游戏支付的逻辑都介绍得很清晰了

使用什么时区是根据业务决定的啊，比如现在需要统计巴西的用户每天的数据，就要以巴西的时区作为零点进行统计，这里就会涉及到夏令时的问题。