压测礼包折扣挺吸引，但没找着对应的专栏文章呀，是还没发布？

不知道你这个安全测试的目的是啥，可以先说明下？这样才好划定范围给建议。安全的范畴很大的。

大部分专业的 web 端安全测试，大多是在做渗透测试，这块要求的技能比较多，一般得专业安全测试工程师才能做得来。测试工程师一般能做的，也就只是针对最常见的漏洞进行挖掘和测试，以及用一些第三方的安全扫描工具扫描下。比如 https://www.cnblogs.com/fundebug/p/details-about-6-web-security.html 里面提到的各种常见漏洞。

以前安全还有个 OWASP 组织，定期采集高危安全漏洞，并出一些报告和安全标准的，好像最近几年没怎么见到新消息。官网倒是有些可以参考的资料 http://www.owasp.org.cn/OWASP-CHINA/owasp-project/

你这个不像是 UI 自动化测试的需求，更像是爬虫。遍历所有数据，并根据条件做不同的操作。

既然目的是遍历数据做操作，建议可以考虑换用爬虫的方式，从接口来抓取数据？效率更高、更稳定。

基本都是从抄别人框架开始的做起的。看得多、用得多了，慢慢就熟练起来了。

没太明白，你具体是要做什么？

你图里看起来有文字型控件，基于这类控件的 text 属性来定位是否可以满足？

没有例子，看不懂这个题目描述。。。

看了下，好像主要是识别文字的，和大厂们分享的可以识别控件并生成控件树的还是有点不大一样。

具体报啥错？

截屏和查找界面元素是完全没关系的，截屏是获取帧数据，查找界面元素获取的是控件树，两个完全是两码事。而且根据一个 uiautomatorviewer 的报错就说 “禁止截屏” ，这个结论是不是下得有点不够严谨？

这问法很常见，就是最常见的行为面试法问的问题。现场记不起来就提前准备好示例，背好吧。

你们用的什么 OCR 框架做控件定位，可以分享下么？

类似 airtest 这种图像识别的，分辨率变了或者有些图标变了很容易直接 gg 。而那种直接根据一个图生成一个控件树的，可以自由定位的，只在各家大厂 ppt 看过，实际可用框架暂时没见过，不确定具体的效果。

PS：OCR（Optical Character Recognition）我理解是特指文字字符识别的，控件等图像特征识别叫这个好像不大准确？

原因和解决方案，可以发上来分享下？

握个手，点个赞。确实年龄大了有家庭，不再有那么多时间 “晚上求发展” 了。但也不需要直接躺平，只是要选性价比更高的学习方式而已。比如工作里面多做总结沉淀、多向身边人交流学习、上班路上听听书、偶尔参加下沙龙大会充充电，也是一种 “求发展”

你的期望是跳过这些已删除的回答吗？还是什么？

如果是跳过，那现在程序的行为和你的期望不一致，属于不正常。那你改下代码，在采集逻辑里根据答案是否被删除状态，剔除掉删除状态的回答就好了。哪个字段代表删除，你需要自己找下、验证下。

另外，你的日志加一些描述信息吧，像截图里面那样的纯数字，完全看不懂对应意义，你就算用红框框住还是看不懂的，所以没法基于你这个信息给建议。

举个例子：

459 [xxx,xxx]

改为

回答抓取完毕，共计抓取到 459 个回答。对应id为：[xxx,xxx]

不用羡慕，你可以对比看看能自动生成的 case 和你自己设计的差异。

新接口的自动生成 case（特指有效的用例，那些单纯各个参数为空、为数字、为字母之类的用例，个人觉得意义不大），目前还没见到能达到接近人设计的水平的用例。

倒是建议可以搞流量录制回放，这个比较多公司在做，且也有开源的平台了，之前问过，roi 还是比较高的。

提个小建议，对于如何开发一个小工具可以单独放另一篇文章？前半部分的经历已经可以独立成文了。

现在 “如何开发一个小工具” 这部分讲得有点简单，有点像 我要做 xx，只需要写 xx+xx 就可以了 ，只讲了 what ，没有讲 why ，对于真正的新手会很难记住。更建议是先讲一下这个开发框架的整体架构分层，然后说要实现的功能是什么，在这个架构分层下对应怎么拆，最后才是拆完后每个分层的具体实现。

个人觉得，对于开发过程来说，代码只是最后的运行产物，中间的逻辑设计才是精华呀。

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

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 的，都打印原始返回值，你自己看看到底是返回值格式变了导致你获取不了，还是格式没变单纯你正则没写好所以没匹配。