想起图片验证，我就会想到我曾经的第一个自动化测试程序，那会被图片验证纠结了很久，最后也没有想通该怎么处理，直到最近，我终于想通了，可是却离开那个程序了。
人生憾事其一，回头时发现自己曾做过的事那么浅薄，却沾沾自喜。
------------------------------------------------------------------------
图片验证，这个不光指的是被测程序上的那些图片的验证，更可以引申为一些比较难以用常规方法来验证的功能的验证。
先不去纠结到底怎么实现图片验证，来简单聊聊图片验证的一些实现。
目前所有的图片共可以分为两大类，矢量图和位图。如果你要比较的是矢量图，那么，亲，可以找些资料一起来研究么，这块我不是很懂。目前的测试中，需要比较的图片90%以上都是位图，就算有些地方是矢量图，也是当成位图来比较的，所以目前我们先解决位图的问题。
位图比较的基本原理是按位比较，因为位图的本质是一个矩阵（黑白图）或三个矩阵（RGB图），所以我们可以通过按位比较来判断两张图是否完全一样，这个也是最简单的了。当然，现在已经有了很多成熟的图形比较算法或工具，我们可以去网上找找。
然后来说说利用图片来验证一些比较难以用常规方法来验证的功能。这个的核心思想是：一个软件，在相同的数据源、相同的显示环境、相同的操作下所显示的内容是完全一致的。
先来举个例子。比如说画图板的绘图功能，如果要对这个进行自动化测试，那我们应该怎么做呢？无从下手么？因为我们不敢保证我们所绘制的图片是真的符合预期的，因为很难判断出来，并且很多前辈高人也说过，如果涉及图片比较多的最好放弃自动化。
那么就真的没救了吗？
再假设，画图板中的矩形选择区、线性选择区的对象是被自定义的，即不能被当前任一款测试工具所识别的，那我们还能实现自动化吗？
其实，也有一条路是可以走通的。绘图功能的本质就是把特定线条或者区域中的像素点修改为对应的颜色，也就是说，如果两次的操作的图片、图片大小、绘图的轨迹完全一样的话，那得到的图片也应该是一样的。至于随机事件和各种组合的结果验证，亲，让他们一边玩去，测试脚本很忙。
到这里，我们可以大致总结下：
1. 对于一些常规方法验证不了的问题，我们可以采用这种方法进行验证。不过操作最好小于3步，以减少误差；
2. 截图比较的区域要尽可能避免无关因素的干扰，如系统时间等；
3. 如果有动态数据，则需要对截图范围内的图片相似度做一些规定，两个时刻的相似度低于80%，要么重新制定截图区域策略，要么寻求其他更有效的方法。