[本文出自天外归云的博客园]
今天在tx内部做了一次关于自动化测试发现bug的分享，把ppt的内容总结下：
1. 自动化模拟程度不够高：自动化过程不能有效替代手工过程，从而导致无法发现通过手工探索可以发现的bug
2. 自动化发现问题见效晚：因为开发也写单测，而且有code review，对于主要单元逻辑出错的概率不大，这导致单测发现问题的阶段后移，有效的单测在代码重构之日就是见效之时，所以增量需求通过单测来发现问题难度较大，但作为重构时的回归用例是合适的，能够弥补手工过程的细微不足之处
1. 一元生态构建：构建自动化能力生态，确保每一个手动行为和肉眼验证都有对应的自动化封装和实现替代：比如音频模块，那么针对minibar是否出现的判断是必备的能力封装，还有对音频播放状态的判断封装，获取到音频bar的能力封装，操作切播的能力封装，底层页音频入口的点击能力封装，音频专辑页的按钮操作能力封装等等，针对场景的自动化测试能力的强弱主要体现在将手工执行用例包含过程的还原度上，比如进入页面是点一个按钮进入的，但是你是通过直接构造一个页面进入的，这是不等价的。省时的未必是好的，自动化测试的有效性一定程度反映在模拟用户行为的程度上
2. 二元代码走查：能够对基本函数的输出结果产生预期，从而在非运行时能够根据需求分析代码逻辑是否符合预期，针对代码的改动处开始进行串联式逻辑走查
3. 三元运行调试：对客户端代码的运行与调试能力，能够通过代码逻辑针对改动进行分析，顺藤摸瓜式找到请求的接口和下发的控制字段，有通过打断点、打log等方式搞清软件运行过程，对问题的原因做出判断的能力
4. 三元归一：拥有了第二和第三点的能力，就可以知道一些控件具备哪些属性，哪些方法，如何获取，如何触发。归根结底是通过对原生函数做出合理的调用和封装，来实现提升自动化生态构建能力的目的（第一点）
原文地址：https://www.cnblogs.com/LanTianYou/p/11793002.html
