无法重现。

我这边这个黑色提示只要鼠标移走就会自动消失的，给个具体的步骤和操作系统版本、浏览器版本信息？

原理上就走不通了。

android.jar 内置的全是接口，里面都是空实现，真实实现只有在 android 操作系统下才会被调用到。而且有可能这个 android.jar 替换为真实实现是依赖 android 系统运行应用使用的 jvm 虚拟机的，所以在 android 下跑 python 也不一定能走得通的。

不知道你想测试什么，为啥要调用系统自带的 api ？如果是想拉起 activity 之类的在应用内的操作，建议直接在 app 项目里写单测？

公司封装的 chrome 浏览器（界面大概如下： 打开浏览器时，显示登陆界面，登陆后进去公司的系统）

selenium 调起浏览器，是用调试模式调起的。你得了解下你们公司封装浏览器的时候，是不是把调试模式开关也一并干掉了（这个也不奇怪，毕竟是个安全隐患）

记录一个问题：当在回复里被 @ 的时候，不会自动发消息到【个人】这个组了

应该是的，我也刚留意到。。。估计是存在 redis 之类的缓存里，升级后数据没迁移过来。

首页底部就有：

我试了下，可以正常看到首页，也可以进入帖子。
具体是怎么不支持，给个截图什么的？

@Lihuazhang 仅楼主可见这个你这边看看，看是不是我们的和 rubychina 的刚好相反了？

怎么样的测试环境算一个好的测试环境

越接近线上的越好，仿真度越高

会如何规划搭建一个稳健可复用的测试环境？

没明白题意，公司产品和项目涉及很多端，但基本上需要环境的主要是服务端。那就搭呗。如果需求并行多，那就搭多套测试环境。如果对质量要求高，上线前需要用线上真实数据测试下，那就搭个使用线上数据的预发环境。

查了下，你的用户名是 Ouroboros-Reincarnation
你是本身就用 github 注册的，还是普通方式注册后绑定 github 账号？

设计如此，目前只显示 logo ，不显示名字。鼠标停留才显示名字

首页标题太短大概知道是什么原因了，回复数量那个 css 的固定宽度太大了挤压了左侧。今晚改一下。

我这里看图片好像没问题，你试试请缓存或者换个网络试试？

这几个知识域都是目前很常用的，期待老前辈后续的经验分享~

chromedriver 实例化后，发现会拉起本地 Chrome 浏览器

这段话很奇怪，你测试的是手机里的浏览器打开 web 页面，还是你的 app 内置 webview 里的 web 页面？如果是后者，我理解只需要实例化 appium driver，用 driver 内部切换 context 的方法来切换到 webview 就好（appium 有内置 chromedriver ），不需要实例化 chromedriver 。

最好还是直接贴一下你的脚本代码吧。

想把代码都附上的话，建议直接 github 建个项目放上去，然后文章里分享项目地址和关键代码就好？

这代码篇幅太长了，没啥读到尾的欲望。。。

不知道你这里的最大最优定义是什么？先定个准确定义？
比如响应速度 95% 在 3s 内，且没有引发 fail，系统可在此压力下持续运行 15 分钟且保持稳定的性能表现时，对应的用户数/线程数？

如果单看 TPS 和响应速度指标，个人理解是：

持续增加线程数（压力），TPS 先是变大（程序在长期待命线程基础上增加临时帮忙的线程，所以会加大），然后稳定（达到了 jvm 线程数配置最大值/系统能抗住的最大值，不给加了/没法加了）。
响应时间先是稳定（因为每个线程压力没怎么变，只是线程总数增加获得性能提升），然后变大（线程数加不了了，但活还在增加。来不及立即处理的只能有些排队等待下，所以响应时间长了）。

TPS 稳定且响应时间还没上升到不可接受程度（这个要看具体业务需要）时，可以承受的最大线程数应该就是这个系统的接口在这个配置下最大能承受的并发量了。至于反推用户数，要结合业务场景推算，毕竟 100 个用户在线可能分别在干完全不同的事情，只有极少数场景（比如秒杀）是都在干同一个事情，调用同一个接口。

PS：响应时间不要去看折线图，看不出啥的，因为响应时间是会在一个比较大的范围内波动的，几秒内有可能有的响应速度 3s（可能进了队列等待），也可能 1s（刚好没进入队列直接开始处理），折线图看起来就是一堆线混在一起。要看总体统计数据，95% 响应时间多少，50% 响应时间多少。

PPS：楼主从头到尾都没提及业务场景，所以我也只能顺着下去了纯技术了。实际还得根据业务场景来，比如是否会有固定串行事务、实际上高压力时各接口调用量占比如何等，对应调整压测策略和要观察的数据。

初创团队领导应该更善于做减法，而不是加法吧。不会取舍容易浪费资源。

前后发都有道理，发版前发相当于是发版决策的参考依据，发版后发是整个项目包括线上质量的总结。

估计你们开发想要发版前发，期望是达到发版决策参考依据的目的，那就发版前发呗。

请不要直接甩链接，用户体验很差。至少把正文贴过来。

可以看看 airtest ，appium 好像也有类似的插件。

改到旧逻辑的话，那通过代码 diff、和开发沟通等方式圈定影响范围，再针对性地去回归？一般改到旧逻辑，且改动较大，那就可以当做新功能完整测试了，这个时候原有的埋点也不一定能满足产品需要，需要产品更新下埋点需求。如果改动少，可以针对性回归。

这类问题用刚才我说的招也能快速发现最严重的问题，但很难保障无遗漏。核心点还是要知道开发改了啥，这样才能事半功倍。当然有资源直接把 UI 自动化和埋点检测结合，进行自动化验证，是最好的。不过听你说快速迭代和经常改到旧逻辑，估计你自动化维护成本也不会低。

楼主的回答主要还是没体现技术含量。一般问这个问题其实是想通过这个例子了解你的技术水平，以及是否能说得清 bug 背后的原理、原因及解决方案。

如果沿着楼主这个例子，作为面试官期望听到：
1、为何会出现这个问题，是 mysql 某个版本的 bug 还是官方有明确说过会出现这个问题？官方给出的正确用法是什么？
2、开发的具体修复方式是怎样的，改了什么代码或者配置？这个改进方案会不会只是掩盖问题，而非解决问题？（比如 Integer 改为 Long ，延迟问题的发生）
3、后续怎么把这个变成规范或者流程，尽可能保障以后其他人、其他项目不会再踩同样的坑？

建议要了解下背后的原因，一般风险应该在新埋点，老埋点不应该有影响。

还有一个招，让产品在测试环境就建好后续线上要用的几个主要漏斗报表，产品验收时让产品也看看数据有没有明显问题（比如漏报或错报引起转化断层）。

文中只提到了 无法正常访问、ping 不通，然后就开始推断是 DNS 问题，有点片面了吧。建议你把具体报错附上来？

要让 ping 失败方法很多的，网页打开也一样，不一定就是 DNS 的问题。端口不通、证书不通过等都有可能，都是 “不正常”