我在兰亭这三年之AutoDiff自动化测试框架

不知不觉已经写了8个关于我在兰亭这三年的主题，其实在刚开始起草的时候就已经想好了写哪些内容，预告一下总共有10个主题，这是倒数第二个。我在前面也讲过两则关于自动化的主题，其实之前的实践还远远不止这些，今天接着聊那些年我们追过的自动化。

在当时做一个项目时，因为需要保持前后台数据库的一致性，把共用的表结构进行了统一，同时进行了分库操作，代码相应的需要做调整，但是重点验证两点：一是数据源获取正确，二是变更的表结构字段数据获取正确。其实都是数据层的变更，涉及到功能测试的话都是校验功能与原来一致即可。做过电商的同学都知道，对于首页，品类页和单品页这种全TM是各种产品，文字，图片，标签的东东，逻辑甚少，真的考验的就是各种细心。当时一个开发人员想出一招，他自己写了个脚本把原来页面的源代码获取后跟现在新版的进行对比，如果发现有不同的，那就是有问题的。不过他做的这个还有很多方面没有考虑到。

后来在我的工作中，灵感来源于此，想出了一个AutoDiff的自动化测试框架。当然，从萌生想法到实现的确花了不少功夫，而且基本上都是工作以外的时间来做的，也非常感谢跟我配合一起完成的那位同事，没有他我也只能完成一部分。现在大致说一下这个框架的思路：

1.使用Webdriver启动浏览器模拟用户行为，获取页面 HTML
如果不启动浏览器，用HtmlUnit Driver或直接使用HttpUnit获取页面源代码的话，跟真实浏览器对CSS和JS的渲染有差异的，大家可以试试。

2.使用正则表达式匹配需要获取的区块内容
如果把整个页面获取的源代码进行对比的话，实际上是非常脆弱的，失败的几率非常大，所以为了提高用例的复用程度并且降低维护成本把页面区块化，比如分成页头，banner广告展示区，左侧分类导航区，商品区，footer等等。下一步就是考虑如何匹配这些内容了，就很自然想到用正则表达式，接下来就是对每个区块分别进行对比。

3.可能有需要对获取的内容做处理：如忽略图片的宽和高，trim掉注释等等
事情总不会如想象的那么顺利，获取到之后一运行，可能因为各种情况而失败，那就需要详细分析，寻找解决办法。其中导致失败的一些情况如：页面会有随机数的出现，图片加载时宽和高的位置在源码中不一样，有些自适应的内容在加载时的像素值不一样，网速快慢影响到一些代码的位置等等。具体情况具体分析，那就要自己实现代码对他们做处理，如把随机数cut掉，忽略宽和高的位置，忽略不同的像素值等。

4.第一次运行时保存为基准内容，之后每次运行时与基准进行对比，保存结果到数据库
在人工确保首次运行的结果为正确的之后，把它作为基准值，并把区块的内容和计算出的MD5值存入数据库，以后每次运行获取的内容计算出MD5值跟它对比，运行结果存入数据库，同时标记FAIL或SUCCESS。

5.页面读取运行结果，并提供入口人工判断是否正确，并可以保存为基准供下次对比
一般的自动化其实以上四步就已经满足要求了，可以运行，可以出结果，如果失败了，重新运行设置一次基准值就好了。但是，我觉得它依然不够智能，每次设置基准值时需要修改数据库，因为默认是把第一次运行的结果作为基准，所以需要清除掉这个区块的所有结果，然后运行。当时我的解决思路是在页面上展现每次运行结果，并可以预览这个区块的显示样式，页面显示2半，左侧是基准，右侧是运行结果，上下和左右的滚动条可以同时控制左右两侧的显示，方便判断。有时候失败可能只是因为改了某个CSS的class，但是页面显示和功能都是正常的，人肉眼能够判断结果，同时右侧提供一个按钮方便人为地把该次运行结果设置为新的基准值，去更新数据库中基准值的内容，以后每次运行跟本次进行对比，这样，大大减少了维护成本。

其实这里面还有一些细节需要考虑，比如每次运行时需要记录运行的次数，在把所有的用例跑完之后更新数据库的值，这样测试结果按次数进行显示，并且能追踪到以前的测试结果，这里就很好的利用了testNG的一些特性，其中就用到了@BeforeSuite和@AfterSuite，确保在每次运行前后对数据库进行查询及更新。

查看余下内容，请访问我的个人博客：http://oktest.me