做
测试，自动化是一个绕不开的主题，而且也是非常值得去做的事情，无论是对测试质量和效率的提升，还是对人的能力的锻炼，都是非常的有帮助。就目前个人观察到的情况，一些负责基础性组件测试的团队，比如底层平台、SDK等，或者是负责功能通用性高的产品，比如防火墙、邮件系统等，都可以做到比较高的自动化率，而且
自动化测试开发的过程通常也没有那么纠结。相比而言，强应用层业务相关的
测试团队，通常在自动化方面的开展要困难很多。我这里说的是比较全面的功能的自动化，不是指写几个简单的脚步覆盖几个功能，大的思路是接口层面，不涉及UI的，而且可以制作大规模的用例。
主要有几个问题：
1. 首要的问题是版本的节奏，
互联网的产品版本的节奏非常快，一个20多人的测试团队一周发布上百个功能特性是一件很普通的事情。团队成员有非常多的精力消耗在这些功能版本上，需要快速的理解业务，构建测试环境，bug验证回归，以及发布上线等等，留给业务测试同学构建自动化用例的时间非常少。
2. 功能非常的庞杂，而且有负责的业务流程，难以标准化。
3. 说到自动化，大家会想到自动化框架，需要有一个比较好的自动化框架。自己开发或者维护过框架的同学可能都深有体会，这绝不是一件容易的事情，其
工作量和持续的时间往往会超出我们的预期。我们是否有足够的测试开发人力能做自己的框架，以及业务能否承受这样的等待时间？
互联网行业的变化很快，线上功能变化按天算，业务调整和组织架构调整按月看，做一个大的框架如果在部门层面还有可能，到了业务测试团队来说比较奢侈。很多方案是环境和需求逼出来的，细想下来，有两条路，一是看部门的框架，二是有没有轻量级的方案，可以快速的应用。
这里结合我们自己的一些实践来看看，也是一点浅显的经验。
部门有一些平台，但是有一些局限，主要是针对HTTP协议，另外对数据的准备支持不太好，也不支持DB的数据检查等功能，另外就是不太方面去定制和扩展，相比而言更适合外网的监控，评估下来准备想想别的办法。
很多时候，过去的成功经验往往会让我们想复用，所以一开始的时候准备参照在以前公司做过的keyword driven的框架，把功能点封装成一个个的步骤，然后通过配置文件来构造用例，实现自由的组合和数据驱动。这条路验证过，而且看起来对现在的业务来说也没有什么问题，能走通，但是就目前团队的情况来看，开发一个这样的框架的代价无法承受。
考虑了很久，于是有了现在更轻量点的做法，写出来给那些测试开发资源比较少的业务测试为主的团队参考。
如果想要快速，但是又功能丰富，最好的办法就是抱一条粗腿，这里我们选的是JMeter。从2.2版本到最近的2.11，一直在关注和使用，发现JMeter的进步很快，版本活跃程度也很高，另外，它早就超出了一个HTTP性能测试工具的范畴，自动化测试其实是它另一个很大的主打，官方文档也提到。
选中JMeter简单来说有几点：
1. 接口大部分HTTP协议，而JMeter对HTTP支持非常全面，毕竟是做这个出身的。如果有些接口不是呢？我们的做法是用写adapter转换，这里不详述，所以写用例这边还是按HTTP协议走。
2. 对数据提取和断言非常多的支持。还可以支持直连DB，可能需要补充额外的驱动jar包，但是没有技术障碍。
3. 可以图形界面，极大的方便了用例制作和调试。以前的经验，我们做了命令行的功能点，后面为了大规模制作用例，还开发过
web console，现在完全没有必要，这一部分也省掉了。
4. 可以命令行执行，这就意味着可以方面的被粘合到我们的脚本里面。
5. 输入和输出都是文本，jmx和存成的csv都是文本，极大的方便了脚本的处理和结果的parse。
还有更多细节的点不多说了，有了这些基本可行性就很高了。想要独自开发上面这些功能得很大的代价，这也是轻量级能做到的主要原因。
有了上面这些基本的骨架有了，但是要想想怎么整合成可复用和扩展的用例。
基本的思路如下：
1. 用例的分层，为了更好的复用和管理。CGI是最小的粒度，对应一个HTTP请求，完成一个很细节的操作。Function是一个对外有逻辑意义的历史，比如下订单，审核订单。TestCase是一个成品，TestSuite是一个用例的集合。
每个子系统的目录组织如下：
这里有个小的tricky的地方，为了部署的时候更灵活，希望脚本里面互相引用的文件是相对的路径，但是JMeter支持不太好，默认的根目录是bin，所以简单的做法是把整个自动化用例的目录copy到JMeter的bin下面。 2. 因为我们有多个系统，对应多个测试小组，大家各有专注，而我们电商的业务又是一个长链条。function层就是我们复用的基础，里面再包含对CGI层接口的调用。这里有点JMeter的技术细节，2.10开始建议用TestFragment来组织，而TestFragment是不能直接执行的，只是些积木，到了TestCase层面再用ThreadGroup现场组，才可以执行。
下面是一个完整的TestCase，include了本系统和其他系统的一些function座位步骤。用例细节其实还有很多需要打磨的地方，比如命名规范，执行起来不容易。
3. 自动化的报告，每次执行完了之后自动的发邮件报告出来。
