自动化测试框架:日志的分析

3974人阅读 评论(4) 收藏 举报

框架做到后期,大量的测试脚本已经编写完毕。大家可能会发现,量少和量多是完全不一样的概念。正如量多的时候你需要考虑运行性能一样,大量的测试脚本,必须考虑其组织方式。

在上次重构中,已经和大家交流过,系统中为测试脚本预留了一个“测试包”的概念。而最近又正好在设计最后日志的分析功能,所以很自然地联系起来考虑。(测试包是一个非常简单的概念,就是允许多个测试步骤或测试包,作为另一个测试包的子节点存在。)

日志是脚本在运行过程中记录下来的信息。对于测试来讲,这些脚本中的错误信息是他们非常需要的。但是如何在庞大的运行日志中方便地统计出他们需要的报告呢?

这里面必须先回答一个问题:这个报告给谁看?

给测试看?不,还有项目经理,开发经理,测试经理等等项目负责人。除了负责人,还有我们的开发人员也可能看。事实上,最好的情况是,测试错误能自动发送到相关模块的编码负责人手里,只不过由于这点往往需要和开发管理系统相连接,因此暂时不考虑。

回答了这个问题,我们知道统计的报告设计必须考虑到两方面的需求。对于管理者,他最需要了解的是这个系统运行的大概情况,有多少错误发生?这些错误严重吗?这些错误都是怎么分布的?如果你是管理者,你可能还能提出更多的要求,总之,你最关心当前这个版本能发版吗?

这是看上去简单,但又是很复杂的事情。简单是因为只是一些简单的数据而已,复杂的是这些数据的形成。我们知道,数据最关键的在于意义。如果不能为我们的统计数据找到合适的形成方式,那么所谓的报告也只能显得苍白无力。

这里面最最关键的在于回答管理者所谓的“严重”的标准。经过和测试人员反复的探讨,他们最关心的是“模块”的概念,这是和业务非常相近的。我们的系统如何来理解模块的概念呢?特别是,那些模块是重要的,那些模块是不重要的。

正如大家所想到的,解决这个问题的过程中,我们考虑到脚本中已经频繁使用到的“测试包”。虽然一开始并没有对测试包定义明确的意义,但是我们非常惊奇地发现,测试在编写脚本的时候,正是按照模块的概念在组织测试脚本。这对我们自然是一个非常好的消息。下面就是如何利用这个特点。测试人员心中想的是模块,因此组织的时候自然也容易按照模块的概念进行。不过包的数量还是很多的,因此我们做了一些假设(这些假设可能会作为配置选项出现),第一层和第二层的包是非常重要的,也是系统应该最优先关注的。

这样系统的分析报告便有了大概的模型:

  1. 运行日志总览:总数、错误数
  2. 日志错误分布:一级模块、二级模块

这个分析是根据一些假设来做的,有人问,万一用户不是这样使用“测试包”的呢?这个问题非常简单,我们的测试方案的组织和测试结果的分析报告,是一个相辅相成的矛盾体。正是因为测试包已经这样组织了,所以这样分析非常好。反过来,因为我们会这样统计结果,所以也会促使测试人员在编写脚本的时候,注意到测试包的应用。所幸的是,测试包可以非常方便地被插入和组织。

不要忘了我们另一个目的。测试人员要根据运行日志详细查看。一来分析脚本执行情况,而来确定并定位到具体错误所在。这种情况下,出一个静态报告,远不如一个动态分析软件更有用。因此这方面我们选择提供一个日志分析模块,可以过滤出所有错误项,还可以做一些其他的分析。

前面曾经提到的自动分析模块的错误,并发送到开发人员手里。这个现在并没有实现,思考时曾经考虑提供一个模块和开发人员的对应表,这样可以自动发送邮件了。不过具体实现的时候可能会遇到其他问题。

在日志分析基本完成后,自动化测试系统已经进入一个小结的时间,现在也要开始考虑它的下一步走向了。谢谢一直关心这个系统的人们! 

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:1723101次
    • 积分:19475
    • 等级:
    • 排名:第429名
    • 原创:277篇
    • 转载:25篇
    • 译文:0篇
    • 评论:2765条
    博客专栏
    最新评论