《测试开发方法论》之 预判

说起预判，大家可能并不陌生，在电子游戏中，高手通常预判非常好，比如，预判敌人的走位，提前把技能释放到地方等待敌人恰好撞到。

那么在测试开发领域中，预判具体指的是什么呢？

这里其实就是指，对某些比较复杂的开发等技术任务，在立项或者解决的前期，对整个项目链条的周期，方案，风险，成功率，效果等等进行精准的预测。

为什么常见于测开领域呢？相比较普通的纯业务开发程序员的工作来说，测试开发的任务 往往充满着很多不确定性，甚至比摸石头过河还要有风险。很多经验不足的同学，往往会事倍功半，太多的意外发生，太多弯路走了，浪费了太多成本，效果大打折扣，最终判定为项目失败。

那么，此时如果能有较好的预判思维，在各种方法路线 实施前就预测出 所有，这才是一个成熟的老手会做的事。

小章是公司的selenium自动化工程师，也就是web自动化。这天，他们组接到了一个新内部平台的自动化需求，因为是内部平台，所以安全性要求较高，打开页面后，会需要手动安装一个证书才可以继续。

说是安装证书，其实也就是浏览器会弹出一个win弹窗，只需要手动点下确定就可以了。但是这可难倒了同组的其他小测开。

可是小章小章，从不慌张。他先是打开记事本，耐心的记录下这个疑难杂症 的表现：

然后他开始针对这个问题，列出了俩种解决大方向：

1. 设置浏览器，让浏览器自己记住选择，永远不需要再弹出弹窗

2.自动化代码，用脚本每次自动点击一下确定按钮

然后他迅速开始分析第一种方向：

从浏览器自身下手，但是他之前没接触过证书相关的设置，百度都可能不知道怎么搜索，而且要设置的不只谷歌浏览器，还有火狐等，平台也多，又是mac又是windows的。

而且如果中间换台电脑，或者部署到服务器的自动化电脑中，那么可能还会失效，还要折腾一番。

按他自身的经验来看，一下午应该搞不定，成功率不高，优先级最后吧。

接着他又赶忙去想第二种方向：

在脚本代码中下手，这种情况跨平台可能稍微好一些，看起来方便，但是难度也不低，优先级可以优先。

当小章 确定了 从 代码下手后。

他又开始细分。都有哪些思路或者说方案，并对方案进行简单分析

1.利用selenium的库函数：alert.accept()

对于自动化工程师来说，这个方法大概率不好使，因为这不是一个简单的alert弹窗，而是一个复杂的证书选择器，如果机器安装的证书多，还涉及到先选择再确定。所以此路不通。

2.利用autoit3等win自动化：这种软件被selenium工程师熟知是因为其可以处理超脱于浏览器之外的各种软件等，安利说这种是基本一定可以成功的，但是小章目前的情况是电脑没安装autoit3，且电脑是mac，所以无法使用，即便换成windows,也要先到处找安全的下载地址，然后大概率还要研究破解，再录制脚本，打包成.exe，再去python代码中调用这个.exe，这个过程即便顺利，那时候天估计都黑了。而且程序运行速度被.exe牵制。所以不优先。

3.利用selenium的鼠标/键盘操作哦，强制点击确定按钮 或 回车按键。这个方法看起来很简单 很可靠，所以小章立即开始进行深层分析：

但是这个方法有个前提，就是selenium脚本在运行，也就是浏览器已加载完毕。但是小章实际测试发现，在证书弹出的时候，浏览器并没有加载完毕，而是在一直缓冲中，这就导致selenium的代码全都被挂起了，别说模拟回车/点击确定了。就连个print此时都无法执行。

---------------------

遇到这个问题后，小章便继续对这个阻塞情况进行分析 ，想出了其他方法：

1.利用超时技术，强制运行js 停止当前页面加载，然后就可以让点击证书的脚本运行了。

这种方法使用，的确可以停止网页缓冲，程序也成功的点击了回车，关闭了证书弹窗，但是结果是，浏览器一大半的内容都没加载。相当于为了帮受伤的人身上的子弹取出来，就把人开膛破肚，然后粗鲁的拿出子弹，但是人已经没了。。。

2.利用多线程技术，新建一个子线程，去点击回车，解决阻塞问题：

当主线程走到打开网页时，启动子线程，子线程负责在等待2秒种后，模拟点击键盘回车，弹窗消失，主线程继续走。子线程回收。就这么简单。

小章最终判断该方法 的 实现简单，成本极低，成功率超高，且效果良好。立即开始实施。

最终从接手到实现 不到 半小时。最终成功。

上面的小章 ，没有像其他人一样，盲目想到一个方法就开始实施，而是先构思了大方向，然后权衡利弊，再对大方向下 进行小方法的设计。然后对小方法进行逐个预判，排出了优先级。

然后从优先级最高的着手，一次便搞定了这个难题，成本时间都耗费最小。