到自动化测试框架的第二部分我介绍下一个Java写的自动化测试框架。这个框架的核心比较小，所应用的位置也比较有局限性。这个框架测试的不是功能，而是性能。用一句话来描叙，这个框架是用Java调用被测试产品的Java API的性能，本身也是Java编写的。
　　之所以不用LoadRunner或者别的工具是因为测试团队的大部分人都是开发团队成员，对商用测试工具的价格敬而远之，本身也不都是搞测试出身的。商量了很久，还是决定自己写测试API的框架。
　　以下是这个框架的结构图：

　　图中黄色的部分是产品相关的API，是不属于测试框架的部分，而白色的部分是整个框架的组成部分。
　　先撇开被测产品的API不谈，整个工具暂且称作QTool。主要组成部分是Common，DB，Report以及User Exit4个大部分，另外还有关于版本以及Launcher部分。
　　其中Launcher是启动QTool的部分，Common是定义TestCase以及Test Scenario以及定义Log以及Util和VU以及CommandClient的部分，是整个框架的核心部分。DB是调用DB相关的Result的部分。Report部分详细定义了Test Report的格式以及终画图的部分。而UserExit部分则是定义了直接调用被测产品API的接口函数。
　　再来看看被测产品的API，主要包括2部分：
　　1 基本的CRUD部分；
　　2 基本的BPM的3个API。
　　先来看看我们如何定义性能测试：
　　不是说简单的应用LoadRunner把被测产品压CPU到多少是性能测试了。这里这种简单粗暴的方式至少有2个错误：
　　1 拿我这里简化的API来说：至少有Create、Update、Retrieve和Delete，以及3个BPM的API。你的简单的压CPU是否把所有的API都包含进去了，我的建议是可以
重复但是不能遗漏。
　　2 姑且算你的这种压制算是无差别攻击吧。但是你好保证每一次Loop都是射中目标的，这样打个比方吧。你每次Create需要真的导入一个文档才算真的压到被测产品了，不然你随便录一个，都没有真正存进去文档，被测系统只是再不断报错或者只是在错误恢复。这样不算有效。
　　所以真的性能测试，必须你保证你的每一发子弹都命中目标，然后覆盖所有被测的API。然后再加大VU以及Loop，这样才算是完整的压力测试。
　　为了简单起见，我们假设如下的API的速度相同的：
　　假设我们定义这样1个Case：
　　用户登录产品-Create-Update-Update-DocRoute_Start-DocRoute_Continue-DocRoute_Finish-Delete-用户退出产品
　　可以预见1个VU跑完一个Loop是没有问题的，但是如果2个VU跑的话，必须做好隔离机制，因为可能第二个用户还在用第一个用户跑到Delete已经删除的文档。