互联网业务测试团队如何快速构建轻量级的自动化(2)

　　每个子系统的目录组织如下：

　　这里有个小的tricky的地方，为了部署的时候更灵活，希望脚本里面互相引用的文件是相对的路径，但是JMeter支持不太好，默认的根目录是bin，所以简单的做法是把整个自动化用例的目录copy到JMeter的bin下面。

　　2. 因为我们有多个系统，对应多个测试小组，大家各有专注，而我们电商的业务又是一个长链条。function层就是我们复用的基础，里面再包含对CGI层接口的调用。这里有点JMeter的技术细节，2.10开始建议用TestFragment来组织，而TestFragment是不能直接执行的，只是些积木，到了TestCase层面再用ThreadGroup现场组，才可以执行。

　　下面是一个完整的TestCase，include了本系统和其他系统的一些function座位步骤。用例细节其实还有很多需要打磨的地方，比如命名规范，执行起来不容易。

　　3. 自动化的报告，每次执行完了之后自动的发邮件报告出来。

　　为了更好的定位问题，需要把每个接口执行的细节也暴露出来，点击详情可以看到调用的情况，包括request和response的数据。

　　除了好处，也有一些不方便的地方：

　　1. JMeter在include其他的jmx脚本后，不能直接在界面显示加载的内容，所以看不到被include的脚本里面的步骤，调试的时候不方便。不过好在JMeter可以一套binary启多个，并着看。

　　2. 最后的结果报告里面，不能控制展示的粒度，是直接摊开成CGI层面的步骤，显得比较杂。

　　目前我们执行的情况

　　1. 目前覆盖了200多个CGI接口，以及100多个功能点，初步有4个系统挂接到了自动部署后的执行。用例还在进一步的扩展中，框架不需要改动。JMeter本身的稳定性还是不错的。

　　2. 整个过程，不算制作用例的时间，我们实际投入的测试开发的人力合起来不到一个人月。

　　3. 大部分业务测试同学都参与到了用例的制作，提升了对业务逻辑的理解，并且对部分同学来说，也补了HTTP协议等基础知识的课，实际动手比听听培训效果要好。

　　从实际的效果和投入来说还是比较满意的。

　　除了技术层面，自动化执行起来有几个核心的要点：

　　1. 一定要强挂钩到测试和发布的环节。

　　这一点看起来没那么重要，但是如果不希望自动化成为花瓶，就必须要这样做。像互联网产品这样快的节奏跑起来，任何花哨的环节会逐渐被洗掉，因为人员的配比和版本的数量，不是必做的东西慢慢就坚持不下来。所以自动化如果要能发挥效果，目前来看最合适的点是在每次自动部署后快速的刷一遍，在手工测试开始之前。而且如果要人工去点，这事儿时间长了也不靠谱，一定要把这个过程也自动化，版本在测试环境部署好了之后，自动化自动跑完，这就是强的挂钩。

　　2. 报告也是要自动的，并且邮件抄送给相关的开发，测试和团队的负责人。我们现在的做法是跑完了脚本解析后自动的发邮件报告。

　　3. 非100%成功的都要跟进。

　　宁愿少而精，这个也类似broken window理论，如果能容忍一个用例失败，就会有2个，3个，也会让自动化慢慢失去意义。目前的做法是只要有失败，对应系统的负责同学要邮件reply all跟进原因。

原文转自：http://blog.csdn.net/superqa/article/details/20644285