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. 所以你需要先了解这两种框架分别是什么样的，有什么特点和运行方式。

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

你在用 pytest 写 case，为什么用 unittest 来运行呢？

试下直接运行 JS 代码 set value？

往往说得越全面的东西，越难真正落地坐到。写代码是这样，code review 也一样；
如果都是规则，是不是配到代码扫描工具里，让工具去实现更保障呢？

UI 的很多啊，可能是大家的 UI 自动化都比较稳定了，现在主力在做 api 自动化

平台是干嘛用的呢？ 无非就是把已有的各种测试框架和脚本集成到一个比较美观的界面上面，让大家点点鼠标就能触发测试，看到报告，做一些牛逼的图表，甚至可以直接在上面写用例。
如果没有实际的平台需求，其实现成的 Jenkins 等工具就很方便，该有的都有了；实在想要放到平台上面的话，简单的做法也就是做一个触发，直接通过命令去运行你的 unittest。

就是 end to end, 端到端测试吗？

如果你只是为了其中的一个环节的改动，而且改动很小，对数据结构不产生变化，那么只需要对你的上下游做个对比测试就可以了，比如修改前后的报文对比；如果是改动比较大，对数据结构有影响，可能就需要做完整的端到端回归测试。