这个是因为阅读量不是存数据库，而是存缓存的。这次迁移数据没有迁移缓存数据。

已修复

嗯嗯，发现了。
已登记 issue: https://github.com/testerhome/homeland/issues/94
周末改一波

1，已重现。感谢反馈

1，可以重现了。点击进入过的帖子，返回后黑底提示框都不会自动消失

无法重现。

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

原理上就走不通了。

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

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

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

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