你直接上网找个在线的正则表达式校验工具，自己验证下吧？我还没达到直接看截图就能看出为啥匹配不上的水平。

你打印原始值看看，看原始值有没有问题先。不要一上来就正则。

看了下知乎现在的前端界面，基本是通过类似 app 的方式，下滑到底部请求下一页的内容，直到达到最后一页。

然后看了下你的逻辑，有几个奇怪的地方：

1、offset 按照知乎目前的方式，表示的应该是当前页面第一条记录从实际数据库第几条开始。知乎貌似是固定每页 5 条数据，所以 offset 应该是 1、6、11 这样的。你这里面 offset 是 i+5，i in range(467) ，意思是 offset 的值是 6、7、8...472 ，逻辑不大对吧？

2、只能拿到 181 个回答，有打印看过每个接口请求的返回值，大概循环到第几次的时候，返回值数据开始不正常么？你这里 for 循环没有任何控制速度的措施，都是以最高速度循环获取，有很大可能触发了知乎的接口单 ip 访问的限流策略，直接不返回回答，导致你得到的回答数不增加（你用正则获取，所以也不会抛异常，只是匹配不到任何回答而已）。181 这个统计数据只是个结果，需要有每次接口的具体返回值这些过程数据才能定位问题呀。

我还是没明白，你的前端页面崩溃到底是啥概念。你这里没有用到 selenium 通过浏览器实际打开页面，只不过是通过请求接口，获取了一个 html 格式的返回值内容。
我理解的前端页面崩溃应该是 js 执行耗费资源过多，导致整个前端卡死没反应，但这种是浏览器打开才会有的，你这个接口返回值不应该有？

然后底部触发返回，我理解本质上也是翻页。翻页不只是真正界面看到上一页下一页，拉到底获取新内容也属于翻页的一种。翻页的本质应该是通过分页限制单次返回内容的个数，避免一次性返回过多内容，引起各种性能问题。

抓包看看，是否可以直接获取到服务器接口数据？一般前端翻页都是用服务器接口翻页的，而且直接拿服务器接口数据，解析起来也更便捷。

信息太少，无法判断。这个截图异常也只是个反射触发异常，没啥卵用。

只能说从个人经验上，一般原因可能是你的页面控件太复杂，或者是动态页面控件一致在变，导致无法 dump（UIAutomator 要求控件树要在几秒内保持稳定才会开始 dump ，否则会等待直到控件树不变）。

建议你补充下你具体的 app 截图之类的信息吧。

看你截图，你这个爬虫不是访问服务端接口么，为啥会说前端页面崩溃？没理解这个点。

查了下，好像 win7 的性能监视器挺强大的，CPU、内存都会有，也有很多更细节的数据，至于 GPU 可以用 gpu-z 试试，网卡驱动能拿到的它基本都有了。视频帧率这个就不大清楚了（只知道 3D 游戏有 fraps 可以看帧率，非游戏的不大清楚）。

性能监视器的使用，可以看看这两篇试试？
https://www.cnblogs.com/laoluoits/p/12767945.html
https://www.microsoftpressstore.com/articles/article.aspx?p=2229240&seqNum=2

最后，既然 win10 可以，直接升级到 win10 是不是就可以解决呢？

很详细，赞。

可以也分享下 mysql 的一些常用监控指标不？一般可能更多是从监控指标看异常，然后再逐步排查到这些参数配置。从监控指标开始实用性更强。

没太理解为何需要考虑穷举或者大量组合计算呢？如果题目数量增加到 20 个甚至 100 个，那不就没法测试了？

个人理解从代码实现层面，这里面应该可以拆开两部分，一个是每个小问题的单题得分计算，另一个是多个小问题单题得分的合计。当然具体的逻辑你可以想办法问下开发怎么实现，可以更针对性地拆分。

然后你测试的时候，分别验证这两个点是否正确，然后再抽验几个两个合在一起的，应该就可以了。

windows 自带的性能监视器可以看看？印象中可以具体到进程级别的。

可能我比较懒，我更多习惯在工作中学习，通过工作中多问为什么，接触了解更多内容，进而获得更多机会，继续接触更多内容。也定期做一些总结什么的，了解自己哪方面提升了，哪方面还是有不足。

总结方面，本身周报、月报、季度总结这些，本身公司里面就要写，多加一点自己的真实感受和反思，就是自己的总结了。

描述很抽象，有没有更具体的信息？

有对比过 selenium 点击下一页，和你手动点击下一页，发出的请求内容（包括 header）有啥差异吗？一般都是有差异才会出现问题的。

中间突然插了一个微信支付二维码是啥情况。。。引导捐赠可以，但也不要那么突然，有点一头雾水。

原来大猫这么早就来广州啦

感觉还是没看出，到底何时适合进行自动化测试？与其说那么多概念，不如来个实际的例子，会更清晰易懂？

但是远程启动所有压力机完成后，样本数却少于并发数

样本数具体是多少，少了多少？你这里信息不完整。

另外，同步计时器原理上是通过阻塞进程来一次性发出压力的，只能阻塞单个 jvm 里面的线程。你这里用了多个压力机，jmeter 自带的 master/slave 通讯机制，是无法保障跨压力机情况下的同步计时器线程累计数的。

比如你脚本里同步计时器设置了 200，那实际上是每个 slave 自己分别去累积 200 个并发一起发，而不是全部 slave 一起累积 200*9 个并发一起发。具体可以参考下

https://zhuanlan.zhihu.com/p/72945182
https://stackoverflow.com/questions/54228259/how-to-synchronize-request-send-time-across-different-nodes-in-jmeter

你这个是啥？缓存命中率？

我只是猜测而已哈，具体你得看接口逻辑才知道为啥前期性能比较差，不一定就是缓存的问题。

不知道你背后系统实现是什么，如果用的是 mybatis + pagehelp ，那实际 size、pages、total、current 都是 pagehelp 自动加的分页用字段。

这类建议直接手工测试一下即可，除非分页逻辑有调整，否则个人觉得没太大必要去校验分页参数。以前分页各种 bug 是因为都是手写分页逻辑导致的，现在都用框架配置，用不对问题会非常明显，所以个人觉得没太大必要自动化去校验。

records 倒是关键，这个和分页逻辑没有关系。比如搜索的话，看搜索结果是否符合要求来判断搜索逻辑的 sql 是否有写错。这部分一般都得手写 mybatis mapper xml 的配置，会比较容易写错写漏。如果有权限看代码，直接看代码会更直接便捷。

你这个问题得问平台开发人员吧，每个平台的设计和实现都不一样，我们不知道你这个内部平台的实现，所以你问 “大家有遇到吗” ，我只能说没遇到过，毕竟我没办法用这个平台。

然后平台不能 os.system ，可能和平台本身设计有关，毕竟 os.system 是权限非常高且危险的（rm -rf /* 这类危险的命令都可以跑），限制不给使用也算情理之中。

个人习惯按风险挑。简单的说就是如果这个用例对应功能真出问题了，问题会多大。把会出大问题的都过一遍。

不过也看实际情况，如果对质量要求高，全过也没啥问题。

瞎猜，像是前期都没命中缓存，所以性能消耗非常大也慢；后期都命中缓存，就稳定多了。

不知道你具体的脚本和报错，没法给更多推论了。

不合适，这样就有很大的分叉了，我没有足够精力维护这样一个新的分叉。

而且我这个 pr 其实没包含前端的部分，以及和现有 agiletc 实时同步的兼容测试，在我内部二次开发过的平台是一个成品，但在 agiletc 上还是个半成品，需要前端配合以及做好兼容方面的测试。

查询后把内容变为实体类对象，这个就是 mybatis 做的事情了。你可以试试引入 Mybatis ？实体类自动生成这些 我前面说的这个工具都有。

另外，不知道你这里的查询条件有多少，我们以前接口测试查数据，可能更倾向于直接写 sql ，通过 where 条件限定内容，比较灵活。如果查出来的结果有比较多需要校验的，那就通过外部表格等方式来记录，甚至进一步通过自动写入表格来自动生成断言。

可以把你公司或团队里面，这种问题的具体情况分享下不，以及你们尝试过的方案？你的描述里从来没提到 “我们” 或者 “我”，全是第三人称甚至没有人称 ，总感觉你不是在说自己的问题，而是说别人的问题，或者 yy 出来的问题。

然后你的回复相比感谢和理解并变成后续行动这种认可（比如：感谢分享，确实我们复盘没有找到你提到的根因，后续我们再内部讨论一下，继续深挖为何需求这么混乱），更像是内容点评。我们回复的目的是想帮助你解决你的问题，而不是给你做这些点评的，这些点评我主观感受上，会感觉很怪。