对楼主说的这个现象，特别是现象 2，我只能想到研发是不同分辨率、不同设备用了不同的布局代码，但这个我觉得可能想很小（但凡对兼容多设备的布局有一些了解，都不会用这种维护成本这么高的方案），所以可以先去找研发沟通了解下，他们是怎么去做不同设备、不同分辨率下的布局兼容的？

另外，也希望楼主可以提供更多的信息，比如界面截图及布局信息之类的，这里信息脱敏太厉害，有点没看懂。

需求不够全面吧，只有价格区间一个要求，电商网站按价格筛选就可以了，没必要问，所以应该背后还有隐藏需求。

楼主可以说下你电脑的主要用途（越具体越好，比如 android 开发，比单纯 写代码 要具体），和比较看重的一些指标（如续航、性能等）？

很清晰的问题分析和技术方案选型说明你。好奇问下，最终选择了哪个方案？

听楼主的说明，本质问题是 “改动点的影响开发也不是能评估到” ，即代码质量失控。本质问题不解决，你能做的只是把兜底做得更完善（比如用更多的回归用例兜底，最多加点自动化减少下人力成本），没办法真正减少工作量，而且也只会越做越累。

这类问题背后有可能是因为开发新接手不熟悉，也可能是本身架构设计不好太多共用，牵一发动全身。个人想到的几个解决方向，大方向还是测试要提高代码能力，倒逼和补充开发这个地方的短板：

1、联合开发做好 bad case 收集学习。正文里提到的这些曾经遗漏到线上的问题，都进行复盘，明确直接原因（代码改动点）和根本原因（为何会产生预期外影响但开发 + 测试都评估不到），以及制定落实优化措施（代码本身耦合度高的，提技术优化任务，进行重构优化；新人不清楚的，代码里补充好注释和写好项目代码介绍文档），持续提高这些容易出问题地方的代码质量。
2、经常出问题的部分项目，要求开干前做技术方案设计，测试参与到方案评审中。通过这个来倒逼开发做好设计方案，和评估好此方案的影响范围，思考好再开始写代码，降低风险。这个要去争取开发 leader 的支持，一般他参与评审，开发才会更认真进行设计，而且他把关质量才有保障。
3、提高自己的代码能力，去 review 开发代码，做到每一行改动都明确是在干嘛，和本次需求是否有直接关系，是否有连带影响其它位置。

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

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

大部分专业的 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 里搜（这里是计算后的结果，和看到的内容是完全实时同步的，所以只要界面有显示这里都能被搜到），就看到原来这个字段的值对应的是上面截图里的 引用外部回答 了。这样整个逻辑就很清晰了。