框架做到后期，大量的测试脚本已经编写完毕。大家可能会发现，量少和量多是完全不一样的概念。正如量多的时候你需要考虑运行性能一样，大量的测试脚本，必须考虑其组织方式。
在上次重构中，已经和大家交流过，系统中为测试脚本预留了一个“测试包”的概念。而最近又正好在设计最后日志的分析功能，所以很自然地联系起来考虑。（测试包是一个非常简单的概念，就是允许多个测试步骤或测试包，作为另一个测试包的子节点存在。）
日志是脚本在运行过程中记录下来的信息。对于测试来讲，这些脚本中的错误信息是他们非常需要的。但是如何在庞大的运行日志中方便地统计出他们需要的报告呢？
这里面必须先回答一个问题：这个报告给谁看？
给测试看？不，还有项目经理，开发经理，测试经理等等项目负责人。除了负责人，还有我们的开发人员也可能看。事实上，最好的情况是，测试错误能自动发送到相关模块的编码负责人手里，只不过由于这点往往需要和开发管理系统相连接，因此暂时不考虑。
回答了这个问题，我们知道统计的报告设计必须考虑到两方面的需求。对于管理者，他最需要了解的是这个系统运行的大概情况，有多少错误发生？这些错误严重吗？这些错误都是怎么分布的？如果你是管理者，你可能还能提出更多的要求，总之，你最关心当前这个版本能发版吗？
这是看上去简单，但又是很复杂的事情。简单是因为只是一些简单的数据而已，复杂的是这些数据的形成。我们知道，数据最关键的在于意义。如果不能为我们的统计数据找到合适的形成方式，那么所谓的报告也只能显得苍白无力。
这里面最最关键的在于回答管理者所谓的“严重”的标准。经过和测试人员反复的探讨，他们最关心的是“模块”的概念，这是和业务非常相近的。我们的系统如何来理解模块的概念呢？特别是，那些模块是重要的，那些模块是不重要的。
正如大家所想到的，解决这个问题的过程中，我们考虑到脚本中已经频繁使用到的“测试包”。虽然一开始并没有对测试包定义明确的意义，但是我们非常惊奇地发现，测试在编写脚本的时候，正是按照模块的概念在组织测试脚本。这对我们自然是一个非常好的消息。下面就是如何利用这个特点。测试人员心中想的是模块，因此组织的时候自然也容易按照模块的概念进行。不过包的数量还是很多的，因此我们做了一些假设（这些假设可能会作为配置选项出现），第一层和第二层的包是非常重要的，也是系统应该最优先关注的。
这样系统的分析报告便有了大概的模型：
-
运行日志总览：总数、错误数
-
日志错误分布：一级模块、二级模块
这个分析是根据一些假设来做的，有人问，万一用户不是这样使用“测试包”的呢？这个问题非常简单，我们的测试方案的组织和测试结果的分析报告，是一个相辅相成的矛盾体。正是因为测试包已经这样组织了，所以这样分析非常好。反过来，因为我们会这样统计结果，所以也会促使测试人员在编写脚本的时候，注意到测试包的应用。所幸的是，测试包可以非常方便地被插入和组织。
不要忘了我们另一个目的。测试人员要根据运行日志详细查看。一来分析脚本执行情况，而来确定并定位到具体错误所在。这种情况下，出一个静态报告，远不如一个动态分析软件更有用。因此这方面我们选择提供一个日志分析模块，可以过滤出所有错误项，还可以做一些其他的分析。
前面曾经提到的自动分析模块的错误，并发送到开发人员手里。这个现在并没有实现，思考时曾经考虑提供一个模块和开发人员的对应表，这样可以自动发送邮件了。不过具体实现的时候可能会遇到其他问题。
在日志分析基本完成后，自动化测试系统已经进入一个小结的时间，现在也要开始考虑它的下一步走向了。谢谢一直关心这个系统的人们！
发表于 @ 2007年09月23日 23:30:00|评论(loading...)|编辑