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

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 桌面端自动化测试工具？

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

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

https://testerhome.com/topics/27557
之前有类似的帖子

找了之前记录的两个印象深刻的 bug，提交参与一下

我司对背调就非常严格。重要的是：

1. 简历里面不要有任何不实的内容，包括公司，工作时间，职位。这些信息一般在面试过程中添加水分其实对你面试帮助有限，但是背调的时候有任何一项对不上就是很严重的诚信问题，会被一票否决。特别是职位这块，除非你能有明确的头衔证明，否则尽量用合同或者 offer 上面的职位名称。
2. 背调会调查的是你五年内的工作经历，所以确保这些经历是准确无误的。
3. 如果背调过程中发现有什么问题（比如我当时就发现其中一家公司的开始时间和上一家公司的结束时间对不上），要及时提供有力的证明，比如对应的合同，离职证明等。

其实当你发现了问题，不是应该第一时间提给开发，让他们去排查吗？ 你如果有兴趣，再看有什么方式可以抓包，验证你的想法？
测试的第一职责是发现问题，汇报问题，确认和解决问题是开发应该做的，切记不要颠倒次序了。

有个疑问，这种解决方案，能适配到夏令时结束的场景吗？ 比如说夏令时结束了，时钟要往回拨一个小时，能保证到时这个问题不会再出现？

我们之前也有遇到过类似的坑。我们当时是用的一个 Timezone 的 jar 包，直接通过城市格式来获取当地的时间。但是后来出现一个 bug ，就是在某一天开始获取的时区不对。后来排查发现，是那个国家的夏令时开始时间提前了，但是那个 jar 包里面还是旧的。通过升级 jar 包版本，解决了这个问题。
所以后来的工作之一，就是要确保这个 jar 包有更新的时候要及时更新部署，以获取最新的时区数据。

request 有对应的 cookie 包可以直接更新 cookie 里的值

其实 selenium 是这些基本操作不是很难，找几个常用的练习一下，遇到问题的时候再找解决方案，这样印象更深；
反而建议你花时间学习一下常用的一些框架或者模式，把用例架构熟悉起来，而不是一个方法里面把所有代码都撸进去了

学好英文还有一个好处就是选择工作的时候多一个外企的选项。

同意按具体的浏览器版本来选择对应的 driver，不过我觉得可以这么优化：

1. 起个定时任务去查询有没有新的版本，有的话下载下来。
2. 所有的 driver 按版本号来解压存储，比如 driver100，driver101。
3. 启动测试的时候，根据当前 Chrome 的版本来选择对应的 driver。
4. 如果对存储空间敏感，可以考虑保留最近几个版本的 driver.

还是槽神一针见血

你看看两种运行模式，上面的是 pytest 下面的是 unittest. 所以你需要先了解这两种框架分别是什么样的，有什么特点和运行方式。

都决定不维护了还去重构，这是怎么被允许上线的呢？