看问题的不同角度而已，可能面试官着重考察的是你落地的能力

那没办法了，对于我们这种传统行业，产品已经存在了十几年，而且很可能在未来的十年里都会一直存在。即使已经迭代过好多批人，这些业务知识和用例也会一直存在，只是随着产品的更新不停地在微调和迭代。

08 年毕业入坑到现在。毕业那年正好遇上雷曼暴雷，金融危机，当时整个班的同学就业情况都很差，迷茫了大半年才在当年的 10 月底误打误撞进了某家小公司，进了测试这一行。
今年身边的情况都很差，去年年底到今年年初，团队在广州和西安都缩减了不少人员，而且可怕的是有很多同事已经过了大半年都还没找到新的工作。

一大早被直击心灵。

我记得你之前是不是有发过一个类似的帖子，我好像还回复了。
这个 ID 会变的话你就别写死，用 contains(@resource-id, 'page') 来定位

看了下官方文档，就正常的 pytest 启动命令就可以了。可能难点是怎么准备环境，官方推荐是用 Docker

https://testerhome.com/articles/34758
之前做的总结

1. 基础的东西大家都做得差不多了，没什么新的可以分享
2. 社区的发帖评论的审核机制，一定程度上会打击发帖的积极性（老人不太习惯）

这个界面是 流利说 吗？我前两年也用过一段时间，挺好的。不过最锻炼人的，还是大胆说，特别是在工作中

这种情况，要么是这位同事短时间内得到很大的提升，要么就是给你们产品埋下很多坑。
我们最近也在做折叠屏的适配，本来开发想直接让我们测试去测一轮，发现问题开发再改，被我拒绝了：折叠屏不是一种全新的东西，开发应该先从 Android 的系统上面入手做调研，为了适配折叠屏，Android 官方文档会要求做什么，以及有什么特性需要去注意和测试。这些都需要 Android 开发的 lead 去 review 过之后，一起和测试过一遍，再交给测试去做对应的测试和适配计划。
你们这种直接交给一个开发去做，然后还出现了那么多 bug，这完全是没重视起来其中的影响和风险啊，建议尽快和领导汇报；而且抛开适配的特殊性，任何项目如果缺陷数量异常的高，而且还没有收敛的趋势，是一定要尽快上报的，说明存在非常高的质量风险。

第一种 diff image 的方案我们也在使用，主要是针对那些相对来说比较固定，以及包含各种图标或者图片，不容易判断元素是否存在错位情况或者颜色错误的页面，比如登录页，设置页等。
第二种场景，在某些元素因为某些特别奇怪的原因导致各种奇怪问题，比如 webview 页面元素突然无法识别，某些元素明明能定位到，但是点击却没有反应等问题，我们也尝试过这种这种方式去做。PS：这种用图片来定位元素的方式其实早在 qtp 时代就已经支持了。

iOS 17 都马上要更新了

匿名用户你好（错以为我已经屏蔽的匿名区又出来了）

请重点说说 2

Xdist 好像可以设置不同的 group，你查一下

用例的质量和作者的表达能力关系很大，碰到很多历史的用例，得花很长时间才知道到底是想测什么点和场景；而且本身对测试用例的产出就缺少一个质量把控的过程，很少有人会认真地去 review，也不会有什么 bug 被人发现出来。

Python 或者 pytest ➕appium 完全没问题呀，网上也好多资料

弱弱问一句：标题的 selenium 和内容的性能测试有啥关系？

吐槽归吐槽，尝试给你一些建议：

1.自动化测试只能有后端人员来写脚本，因为公司的测试人员没有这个技能。
-- 这是一个很奇怪的理由，后端人员也没有 APP 自动化测试的技能啊，为什么就只能由后端人员来写呢？ 没有对口技能的人员，要么从外面招一些进来，要么从内部挖掘可以转型的资源（或许你老板就是考虑到后端人员有对应的开发背景，上手自动化测试更快）。但即使是这样，也不能定义成后端人员在写自动化测试，而是后端人员转型或者学多一个技能兼职自动化测试。这样想是不是就没那么奇怪了？

2.没有设计合理的测试用例，只能通过用户行为驱动去覆盖 app 的功能。
-- 这是需要整个团队考量的，自动化测试怎么和回归测试相结合。通常的做法是从回归用例里面提取和整合出来需要的自动化测试用例去实施。
而你后面提到的用户行为驱动，是怀疑自动化测试能不能覆盖后端所有逻辑？如果是这样，应该是要分层测试结合起来去做的，单元测试，接口测试加 UI 自动化测试。

3.在上线新功能的时候，测试人员已经把所有的功能都测试完了，自动化测试方面都还没有进行或者进展很慢，跟不上发版计划。
-- 自动化测试一般我们理解有两种模式：
-第一种：以回归测试为目的。你的每个新功能不是上线之后就不需要再测试的，每次发版，功能变更，甚至只是服务器做个操作系统升级，都需要进行回归测试。所以这种需要频繁执行的测试用自动化测试去覆盖是理论上可以最大程度节省人力的。

• 第二种：与开发同步的自动化测试。需求文档确定下来之后，开发根据设计去写代码，其实测试也可以同步去写自动化测试用例（只是没办法马上联调）。当开发交付之后，只需要把对应的 locator 补充上去就可以执行（甚至如果这个 locator 已经在设计阶段定义好了，则可以无缝开始测试）。 至于你说跟不上开发发版计划，这是和你们的人力投入有关的。要达到什么目的，才能去看需要补充投入多少人力；如果人力是没办法补充的 那整个事情也就无从说起了。

4.在实际使用过程中，很容易出现一些异常情况，例如：单个测试用例运行毫无问题，一旦串行多个测试用例或多或少的会出现一些异常现象。 该怎么来规避？
-- 这些都是自动化测试框架需要考虑的因素，而且业界已经有很多最佳实践的分享。还是得多投入点时间去看怎么优化。

如果只是根据自身的问题来讨论事情是否有必要，就等同于给自己找一个不去做这件事的理由。

同样的，我们也可以给单元测试，接口测试，甚至测试这个事情找到同样多的理由。但是 “测试是否有必要？” 这个问题相信你也有显而易见的答案吧？

所以还不如多花点时间去想怎么解决你的问题吧，或者如果你自己想不通为什么一个后端开发要来做自动化测试，要不和你领导聊一下，让他另请高明，你专心做开发？

我以前是白嫖阿里云测，每天免费两次大概三十多台设备，不过现在不知道还能不能免费了。

你的个人发展方向是什么呢？ 如果是测试，我觉得还是得把自动化测试框架，接口测试，和测试的基础先巩固好。现在这个行情下面，对很多团队来说最重要的还是找到能干测试活的人，测试平台什么的坦白说优先级没那么高了

嗯嗯，加油！

testin 不是云测平台吗，那么我理解它的优势应该是背后的云真机？
我们现在使用的国外云真机平台（device farm）是支持主流测试框架直接集成调用的（比如 selenium，appium，cypress，playwright 等），因为它所提供的服务就只是设备而已，不会也不应该强制客户要根据它的模式去写，或者重新编写一套用例。不然我以后不想继续用你了，要换个云真机平台或者自己搭建内部的平台，这套用例怎么办？又重写一次？

其实很多看似的没必要，背后都是为了兼容和处理不同场景。毕竟 appium 是一个同时兼容 Android 和 iOS 两个平台，底层还要集成不同的驱动类型。如果你这一套能实现到 appium 类似的体量，效果和程度，最后的效率提升会有多少呢？

从大部分的用户使用来看，这种方式起码保证了我只要专注于怎么使用和 selenium 一脉相承的语法去维护我的用例，甚至于同一套用例，只需要区分不同平台的 locator 就可以做到公用，牺牲一点执行时间是可以接受的。而且执行时间长，其实可以通过并发执行等方式去提升，一定程度上是可以接受的。