赞你，希望这些东西能给大家以方向性的帮助

你与思寒定义的测试开发不太一样
思寒定义的测试开发，没有你定义的要求高，按你这个要求，思寒的课程体系培养出来的大部分应该都不达标

暂时先这样了

这次版式被动到，发现 APP 中很多模块的很多页面，都被影响到了

由于我司的 APP 是个全家桶（集成了太多的模块与功能），各种三级 四级页面如果全部手工回归一遍耗时较长，所以才想到看能否用自动化覆盖

看起来截不出来，所以用截图对比的方式不行

如下图 1，实际是这样

但是 airtest 截图截出的为图 2

我先摸索摸索，之前还没有了解过这个方法，如果能解决同一个脚本适配不同分辨率手机的问题，就太好了

非常感谢！

:截图的话，不同分辨率可能又会出现识别不出的问题，有好的解决方法吗

谢谢

也是一种思路，后续会思考思考如何执行

多谢

兼容性的问题确实也考虑过用 testin

在此抛出 显示 这个问题，是因为最近一直在思考，UI 自动化的覆盖问题，产品迭代过程中确实发现，有些改动会影响到 APP 界面元素的显示，比如某次改动导致头像偶现性显示错误

按理说功能方面，我们可以通过自动化跑整个流程，基本可以覆盖到，但是显示的问题，分很多种（显示错误，显示不全，显示不匹配等），如果通过截图对比也是一种思路，但是这样 APP 界面的展示的东西很多，工作量太大了，再加上 airtest 对分辨率的不同的识别还不是很完美，所以陷入了困境，到底要不要做 显示 相关的自动化（如果有些明显的显示问题都没有抓出出来，领导也觉得这个自动化覆盖率还嫌低，与预期差距较大）

特此与大家讨论讨论，大家的自动化覆盖率问题

是这样，之前 UI 自动化多是用来回归功能，比如你们 APP 具有交易功能，那么基本都是走一遍交易的流程，看整个交易流程能完成，断言成功，就代表这个测试 pass 了

我的疑问是，如果交易页面，由于显示适配问题，你的头像被水滴摄像头挡住了，没显出出来完整，这样不会影响你完成交易功能，然而确实有显示 bug，

所以想请教大家，ui 自动化过程中，有没有针对显示就行覆盖测试的，不只是功能。
ps：也曾思考过对元素的显示进行断言，但是这样的话，APP 界面的展示的东西太多了，这样断言的东西太多，代码成本太高了，而且显示错误也分很多种，感觉没有头绪了

通常情况下 开发都会又 log 日志啊，跑完从日志看看有没有崩溃不可以吗

借问高手

1. poco 有自带断言方法，如果不用 poco 的断言 (exist, equl)，而是用 unittest 或者 pytest 的断言，对报告会不会有影响，比如判断不出执行的失败与否

前一段时间看了看 boss
22k 以上的，几乎两页翻完了
高薪的需求，感觉不像很多人说的那么多

先 mark,后面仔细学习