测试也可以深入代码呀，如果是专业的性能测试人员或团队，这个算是基本要求了。如果只是兼职的，倒不会要求这么高，但有这块能力别人会更认可你。

我理解面试官其实是想看你寻根究底到什么程度吧，虽然说有经验的开发会更专业，但测试也掌握这方面的一些技巧，才能更有话语权，也避免被有些不大了解性能的开发带偏。而且性能除了可能是代码问题，也很可能是配置问题，各种框架中间件操作系统，如果都直接用默认配置，也会很容易产生性能瓶颈。

目前使用了一个笨办法，就是批量断言完之后，打标签，如果是 false，就自己 raise 一个异常让 HTMLTestRunner 监听

这个就是正统方法呀，为啥会是个笨方法呢？捕获异常不用依赖任何其他模块，监听 logging.error 还得加上日志模块的依赖，从框架设计角度，捕获异常通用性明显更强也更简单。而且从使用者角度，谁能想到只是打个 error 日志记录下，还能引起用例记录为 fail 呢？

你先描述下你的场景吧，感觉是你对这个使用场景中的用例 fail 判定还有可以改进的地方。

如果是流水线的插件的话，那原有流水线的编译和这个增加覆盖率的编译，可能会引起重复。

建议是直接扩展现有流水线上的编译插件或函数，直接增加是否内置覆盖率统计的开关。至于开关打开后具体插入什么参数，那就根据具体语言和编译器来进行对应设定了。不过一般不同语言整个流水线各个步骤都会有差异，一般 devops 平台都会直接用项目类型来直接区分语言的吧。

对测试框架来说，对一个用例的执行判定是这样的逻辑（具体 fail 和 skip 的异常类可能名字不完全一样，但基本原理都是捕获指定类型的异常）：
1、没有任何异常抛出——success
2、抛出 AssertError 类型的异常——fail
3、抛出其他类型的异常——error
4、抛出 SkipException 类型的异常——skip

没执行到断言就结束且没有产生异常==没有断言==没有异常==success

PS：你贴的那段错误代码，所有异常都被捕获了，捕获完也只是打个日志，没有继续向外抛出。测试框架是用例的外面一层，你不给他异常，他只能认为没有异常。

建议买本书或者上极客时间这类网站找个性能测试课程，系统地学吧。

PS：建议先从不直接伸手开始，直接抛问题而不提自己做过什么尝试和思考，不是学习应有的态度。

个人意见：
要掌握的中间件：主要是被测系统会用到的，其它暂时用不到的了解下即可。从行业通用角度，消息队列类（RabbitMQ、Kafka）、缓存类（redis）、定时任务类（xxl-job）、注册中心类（zookeeper、eureka）应该会比较常见。

1、知道是干嘛的
2、知道大概原理以及优缺点
3、掌握相关的操作工具技巧（如 redis 的 RDM ）
4、知道一下几种典型的用法（面试可能会问到）

点击动作，如果失败的话，应该会抛出异常的。你上面这个场景，无法操作的表现是可以正常调用点击事件，且没有出现任何异常？

最简单的办法，可以加上无法操作时（应该有对应的异常类），也进入异常弹窗处理流程，检测有没有弹窗，有就关掉？

可以看下 Pytest 的并行是否满足？

不过多设备的话，不同设备用不同 driver ，这个还是得小改造下用例里获取 driver 的方法的。用 appium 并行 搜索了下，找到几篇应该有借鉴意义的文章：
http://testerhome.com/topics/1944
http://testerhome.com/topics/12331

你也可以自己搜索下，这块社区以前有不少同学分享过。

感觉这个思路怪怪的，你这里的并发是多用例并行执行还是啥？

如果是多用例并行执行，那每个用例自己管理自己的 driver 就好，用不着搞个 devices_start_sync 来做。框架只需要起几个固定线程，线程一空闲就去全局的待执行用例列表拉用例执行就好。

如果是镜像执行（用例里每一个操作每个 driver 都操作一遍），那应该在 driver 外层封装一个类，用例用这个类，类里面的方法都会自动遍历内部持有的所有 driver 每个执行一遍。

不过这种比较少见，而且也很难处理中间单个设备出现的异常引起的问题。所以更多见到的情况是保障每个设备都有执行过全量用例就行。实现上是多用例并行执行的基础上，把待执行用例列表从一个公共列表，变为每个线程都有一个独立的列表就好了。

PS：这两种模式的并行执行用例，都比较常见，印象中 pytest 有自带这方面的功能。如果要省力，可以考虑看看 pytest 自带的功能是否满足

我经历过的情况是，有时候 leader 其实没太认真想过这个问题，基本都是实际在项目中用了，才知道自己想要什么，然后再调整具体展示的指标数据。

所以一开始一般都是给统计起来最简单的数据（用例总数、总通过率什么的），后面再根据需求增加统计指标。

先根据业务看 pageB 是否可以随时直接跳转，有些界面依赖上一级界面或操作的数据，不一定能这么操作。

如果确认可以直接跳转，web 的话可以直接用 url 跳转，app 可以用 deeplink 或者手动启动指定 activity（android）等方式。

针对这个场景而言，这个设计有一些问题：

1、需求 1 看起来还比较正常。虽然返回 pageB 有点怪怪的，但实际上如果确实简便一些倒问题不大。
2、需求 2 本身有问题，怎么确保不在 B 页面就一定在 A 页面 ？如果用户实例化 B 页面只是为了判定当前是否在 B 页面，而非跳转到 B 页面呢？这个绑定太死了。

如果针对单纯技术而言，这个应该就是引起循环依赖了。解决也很简单，
1、抽离相互依赖的部分到一个第三方类里（ a->b，b->a 变为 a->c，b->c ）
2、干掉其中一个方向的依赖（比如 PageA 就别返回 PageB 了）
3、引入依赖的时机从全局改为局部（比如 pageA 里面只有 goPageB 方法里才特别加上 import pageB ）
第三种可能比较适合，不过治标不治本。

核心还是设计问题，为了一个特定场景的简便，把每个类的边界搞得很模糊，想把这些类变成 “万能类” 是很危险的。跨类的操作尽量还是放到用例层级，而非 page 级别吧，虽然写起来代码稍微多一点，但逻辑清晰很多。组合才是最灵活的。

我指的不是技术层面怎么采集数据，而是业务层面怎么样的数据才能起到比较有效的度量效果。

这块一般需要和 leader 或者需要用到这些数据的各个业务团队的同学沟通吧？

不知道。。。

从 MDN 看，应该是从 63 版本后支持的： https://developer.mozilla.org/en-US/docs/Web/API/Navigator/webdriver

也查了下 https://github.com/chromium/chromium 上的 issue ，没搜到相关的问题。建议你如果确认有问题，可以给官方提个 issue，让官方答复你？

不错，已收藏。后面有空读下这些书

比较关注，各个平台的测试结果数据那么多，楼主是怎么沟通确定具体需要展示什么数据，用什么形式展示的？

可以分享下这块不？

我们有内部体验，发个邮件给各干系人可以直接下载体验，体验有问题可以找对接人反馈。不过一般实际上会体验的人不多。
也会直接约一个小时会议室，各个 leader 拿着已经装好包的测试机结合产品对本版本功能的介绍，集中进行体验 + 现场反馈。这种一般会比较有效果，也能收到不少有效反馈。

但我们没叫体验测试，不知道和你说的是不是一样。

你说的调试是指编写过程中的调试（类似写代码的断点调试），还是后面多次运行偶尔出现的出错后问题排查定位？

如果是前者，看是否可以支持一个一个 action 手动执行 + 随时手动插入 action 功能。之前看到站内开源的 opendx 这块做的挺不错，但它是针对 app 的，你可以看下看是否有可以借鉴的点？

不过从习惯写代码的角度，再怎么好的 web 平台，调试起来还是没有 ide 的断点调试那么强大。

对的。

一般叫做 configuration 的东西，用途都是全局配置，基本都是一个线程组里创建一次就够了。

防火墙？

招聘请发到招聘区，已帮你移到招聘专区了。

另外，麻烦补充下薪酬范围

一个 jdbc connection configuration 应该是对应创建一个数据库连接的
一个 jdbc request 才是对应使用这个数据库连接进行一次查询

如果查询的是同一个数据库，那创建一次连接就可以了

官方文档：https://jmeter.apache.org/usermanual/build-db-test-plan.html

你看下是不是你用法错了，每次查询都创建了新的数据库连接，导致连接数过多？

建议框架层面，增加在出错后自动截图和记录 page source 的功能，这类问题一般看截图和 page source 才能搞清楚发生了什么，光一个堆栈看不出啥。