自动化测试平台的开发总结（一） log系统

东西比较多，整理比较慢，就先从log系统开始的。

自动化测试的log关系着自动化能否提高效率。
自动化执行成本为0，但是执行时间!=不等于结果检查，定位问题的时间。你的自动化测试系统的log系统设计好不好直接影响你结果检查的效率。 机器一晚上可以成千万条case,但是人不能不能一天检查完那些执行的结果呢。并且现在很多公司都要求持续集成，要做到daily build.机器跑没问题，结果人查的过来吗，弄不好就会出现人机赛跑。结果检查的速度跟不上，自动化的意义就会大打折扣了。

什么样的好log系统算是好呢,个人总结以下三点:

1. 尽可能能够通过log直接快速定位问题。要想做到这一点，就要把让系统所有log,都能与case关联起来，你能很容易从一坨log中拿到某个case执行这段时间所产生log。甚至是某条step执行所对应的log.
2. 测试产生的结果要很容易与后端分析工具与系统集成。例如执行结果可以直接填进项目数据库，并且能够直接发邮件与相关的人。测试log能够导入excel等工具进行分析定位问题。
3. 对于log的输出的颗粒度能够控制。例如有些log在调试时候出现，而在执行的不要，或者功能稳定的时候，log输出颗粒度大一些，减少log的输出量，可以节省磁盘空间（可不要小看这一点，你大规模执行的时候，log量也是很惊人的，一般能跑出上G的log也是很正常的，可不要因为磁盘空间满而导致测试结果无效。而功能不稳定的时候log产生的颗粒度小一些，记录更加详细信息有利于定位问题。

设计原则:
 log分层
     1. 至少Case,step,substep，才能提供相应灵活度，并且三级基本上可以应对绝大部分需求,
     2.呈现方式 以html方式来呈现最好。

  log要分类并且各类结果又要case为基础进行关联:
     1. Case 执行交互的log 与状态进度结果用来生成上面格式。同时生成执行成功与否数据用来填写数据库。
     2. error 与debug log. 分开有利于快速定位问题
     3. 被测设备本身后台log.
 执行结果历史比对,当然要做好这个要对error code做很好的定义。
     1. 与上一次执行结果相比，成功还是失败。
     2. 与基准结果相比。例如与1.0 release版本相比，没有新失败的，并且失败数量的变化。
     3. 如果失败，是新的原因引起的，还是与过去某一个版本的失败是同一个原因。