自动化是持续集成生态中必不可少的一环，起到了一个推动力的作用。因此对于自动化用例报表体现错误时候，就会有一个十分麻烦的工作“查错”或者“问题定位”。如果您是业务专家同时又是十分熟悉自动化平台，那么凭借经验和技术能力也很快能定位出问题。但是对于开发和测试人员只看到“您提交的代码，导致什么错误”、“您输入的测试数据，产生了什么错误”。他们肯定会一脸蒙逼，那些错误鬼知道是哪里的，心里肯定不爽提出了对于自动化的质疑“什么玩意儿？自动化的错误吧”。不好意思，这样的抱怨我觉得没毛病，因为只有自动化用例开发者可能了解那些报错返回信息。那么对于被测业务系统报错还是自动化本身错误，这个问题该怎么去解决呢？
解决方案
对于上述问题解决方法，我想出了一个基于数据分析的方案。这个系统架构图如下：
第一 由于被测业务系统日志和自动化平台日志都是可以收集到的，那么我们分别对两个日志做区分。这里技术框架用到了消息流式处理，简单说一下：zk这里是管理kafka和redis集群的，保证依附这可以健康运行。kafka用来存取和实时传输业务日志和自动化日志，redis用来存取从kafka获取（消费）日志时候的偏移量。再介入正题，加入topic1用来存取业务系统日志，topic2用来存取自动化平台日志，那么两个数据源可以保证实时输入到我们搭建的流式系统中。【简单说一下选择流式处理理由：持续集成要求实时性高，用例量比较大，如果采用传统处理方式效率太低且开发代价很大。】
第二 接下来就是最关键的部分，数据分析与处理模块设计。首先是对于原始数据（原始日志）做预处理，方法是一个基于python的re模块，将正则表达式作为一个灵活可变的配置文件，然后通过基于re开发解析公共能力模块支撑。每次运行加载正则表达式文件，然后得到模板化结构数据，此时的数据都是我们想要的内容与格式。接下来我们根据业务系统日志特点和自动化日志特点，设计一个自己的模型，可能就是一堆简单if else的的堆砌，那也没关系！只要能达到目的，后续可以在做优化，但是前提这部分要解耦做成一个单独的模块。此时在不同的分支就会形成不同的结果，此时就可以区分出不同的错误，不用在面对他们的“甩锅”！这里将结果存入到mysql中。
第三 接下来就是展示我们分析出来的结果，采用的是django，写几个简单的页面就可以了。
上边扔出了砖头，您是否已经有了自己的答案呢？那请在评论区留下，相互学习。热枕期待您的宝贵想法与经验~
写在最后
最后写一点优化点吧，也就是体现标题“智能”二字，目前这是架构设计不是那么的智能。后期引入NLP，打算在【第二】步骤中加入基于nltk的自然语言处理技术。目的是达到对我们筛选出来的重点日志通过这个评估系统智能识别出是消极的还是积极的，根据实际情况设置评估区间，当然需要大量的训练才可以得到这个区间。
再一次期待您的分享与交流~