前言当产品上线的或者开售时候，如果没有严重的上线事故或售后问题，那自然是皆大欢喜。一旦有严重的问题反馈，产品、开发首先想到的就是测试部门有漏测。问题已经发生了，紧接着的是应该首先搞清问题，然后制定复现策略，抓取有效的Log给开发人员分析。不管是测试漏测，还是开发修改引起而测试回归时没有覆盖到（由于不知道修改点导致没有回归），出现线上或售后严重问题，测试部门、开发部门写回溯报告是在所难免了，需要向上面的老大汇报。虽说产品的最终质量不是由测试决定的，但谁叫测试是产品开发的最后一环把关者呢，这个时候，项目、产品、开发都会把矛头指向测试部门。如果是你刚好负责这个项目的测试，那你运气不好，当季度绩效可能...

Appium UI 自动化中显式等待和隐式等待的异同？在实际项目中是如何应用的？相同点都是智能等待，在一定时间范围内不断查找元素，一旦找到立刻结束查找继续执行代码，没找到才会一直找到超时为止不同点是隐式等待是全局性设置，并且可以随时更改，在更改后对之后的 findxxx 方法生效，对点击、输入、滑动之类的操作不起作用；显式等待仅仅针对单一元素生效，并且不仅仅是针对查找，也可以针对元素的某些属性进行自定义判断；很可能下一个问题就是你在测试过程中常用哪种等待？三种都有，相互结合根据各自不同特点应用不同的场景。大部分元素出现的时间可以用隐式等待统一设置特性元素出现时间较长，可以用显式等待针对他进行超...