这么问，一下子想不全，想到哪写到哪吧：

1、代码型的脚本编写方式，很多人一起写用例，写法各不统一，重复逻辑满天飞。解决嘛，代码明确分层 + 做一些写法培训 + 新人写代码必须经过审核才能 merge
2、环境不稳定，执行时刚好有人重启服务那就直接失败。解决方案：类似线上，核心服务做平滑上线，后面的节点启动完毕才把流量切换到新节点。
3、数据库断言写起来费时费力，维护也麻烦。解决方案：先根据数据库实际内容自动生成断言，然后执行第二次，给一些会自动变化的参数（如时间）加标记忽略校验。

无法用数据来体现价值

可以对比下用了 UI 自动化后，测试执行效率/频率的提升？我理解你这个是 UI 自动化都会有的问题，所以普通 UI 自动化的数据也可以用。

不客气，加油！

先修正一下你的术语用法，用的不大对。这样会造成沟通上有很大的误差。

知乎 api 接口返回值的格式是 json ，不是 Html 。里面没有 html 标签，所以不应该被称为 “html 返回的格式”
html 内容实际是前端的 javascript 脚本，基于这个 json 再去生成出来的。你的爬虫没有这个前端 javascript 的部分，所以是看不了生成后的 html 的，自然不可能基于这个 html 来做匹配或者解析。

然后，你截图里的图片 url 很多，这个截图只是一个很局部的内容，只是 json 数据众多字段里其中一个字段的数据而已。你用一些在线 json 解析器解析一下，看下整体的 json 的结构？绝大部分情况下，这个 json 数据的结构一定是固定的，不会少字段，所以不应该会没有回答 id 这个字段。如前面所说，请不要用正则来找内容，用 path 型的匹配方式或者直接代码逻辑解析数据吧

举个例子，返回值是这样的：

{"data": [
    {"id": 123, "url": "http://zhihu.com/answer/123"},
    {"id": 123, "url": "http://zhihu.com/answer/444"}
]}

你要打印这个 json 里的所有 url 数据，应该是把它转为 python 的 dictionary 类型数据，然后再按类似下面的方式解析：

for item in response_json["data"]:
    print(item["url"])

这样才是按结构去解析数据。这种解析方法，只要结构不变，不管 url 变成什么值，你都一定能拿到，而且不会拿错。

建议后续可以你先对比下接口数据和当时的浏览器界面对应关系，确认有 2-3 个都和对应关系匹配上，这个字段确实满足需要。先根据经验提出假设没问题，假设的验证也要做好。你这次的问题就在于验证做得不够严谨，发现有匹配就认为是对了，没有确认匹配的数量是否对的上界面实际看到的回答数。

也分享下我当时是怎么一步一步分析到这个正则不大对的，你后面可以参考下：
1、跑起程序后，先 print 一个返回值。看到里面有匹配正则的，但位置怪怪的，和常见的分页不大一样（一般分页每一页的内容个数是固定的，但这个和正则匹配的值每一页数量都在变，比较奇怪）
2、重点看正则匹配数量为 0 的，发现返回值格式其实没啥大的差异，只是返回值没有能匹配正则的值。再用在线 diff 工具看一下有匹配和没匹配的返回值，会比较明显看出是因为 link_card_info 字段缺失了所以没有任何匹配。说明这个字段是个可选字段，应该不是一个回答有一个值这样的固定字段。
3、到这里已经比较确定获取的字段不大对了，但还是很疑惑 link_card_info 到底是干嘛的，为啥有的有有的没有，所以打开浏览器上知乎，通过 network 查看翻页请求的返回值，刚好第一页就有 link_card_info ，拿里面 2-3 个值在开发者工具的 elements 里搜（这里是计算后的结果，和看到的内容是完全实时同步的，所以只要界面有显示这里都能被搜到），就看到原来这个字段的值对应的是上面截图里的 引用外部回答 了。这样整个逻辑就很清晰了。

我一直觉得，面试是双方的，面试官真的倔且不愿意承认自己的错误，那就 88。很多时候面试不仅看技能，也看性格和沟通方式是否合得来。如果真的合不来，不需要勉强。

而且从你这个例子里看，面试官是先激动的一方，面试者已经尽量降低冲突了，所以我觉得面试者没啥要改进的。即使面试里委屈求全通过了，说不定以后工作上的合作又出现类似的问题，到时候更坑。

本地调试了下你的完整代码，看到了完整的知乎接口返回值，终于知道足够的细节了。。。

先说明下，为啥你会拿不到，原因是你这个正则匹配的内容就不对。

你这个正则匹配的值，实际上只会在返回值 json 里面一个 "link_card_info" 字段里的 key 会匹配得上，而这个字段对应的展示内容，实际是回答里的引用其他回答样式，类似下图（我直接在 chrome 浏览器搜索能匹配你正则的 url ，就找到这个 html 元素了）：

你得到的 184 ，代表的是所有回答里一共有 184 个引用其他回答的内容。和这个问题一共有多少个回答，是两个完全不同的概念。。。

要想拿到所有 400 多个回答的独立地址，个人感觉应该拿 data 里面的这个地址，具体你可以试验一下：

提几个建议：

1、爬虫少用正则，多用 path 型的匹配或者直接代码解析数据。json 可以用 jsonpath ，html 可以用 xpath 。直接正则看起来省力，实际规则太宽松，非常容易匹配错误，而且导致你偷懒不去研究清楚返回值和界面内容的对应映射关系，出现方向完全错误的问题。

2、代码里变量命名永远、永远、永远不要用 aaa、bbb 这些无意义字符。要看懂你这段逻辑太费劲，看到一个变量还得去看变量怎么来的才知道这个变量是啥，阅读效率大幅度下降。

3、提问的时候，要 尽可能把问题描述得足够清楚 。有具体数据的直接给具体数据，不要文字概括性描述。 talk is cheap , show me your code 。如果自己不知道要提供多少信息，就直接把你的代码贴出来。只要有代码，就有办法本地跑，跑起来才能最自由地得到所有信息。

adb devices 输出啥？这个工具底层用的就是 adb 和手机连接的，adb 连上应该等价于工具连上。

你这个逻辑不大对呀，request 的 get 方法，如果响应超时导致没有返回，应该会抛异常的，而不是导致你的正则表达式匹配不到答案。知乎的服务器不至于那么差，offset 大点返回值就出问题。

你把你这部分爬虫的代码直接用 markdown 的代码块贴出来吧，看截图好累。具体 markdown 怎么写代码块，可以看看右下角的排版说明。

也建议你代码里加一个逻辑，凡是回答数为 0 的，都打印原始返回值，你自己看看到底是返回值格式变了导致你获取不了，还是格式没变单纯你正则没写好所以没匹配。

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

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

看了下知乎现在的前端界面，基本是通过类似 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）有啥差异吗？一般都是有差异才会出现问题的。

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

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

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