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

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

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

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

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

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

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

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 岁）准备换工作的时候，收到很多电话邀约，结果都是同一家公司的不同猎头，其他公司投了简历都没有回应。
幸运的是通过其中一个猎头，只用了一次面试通过，然后在现在的外企工作到现在。