好了，废话不多说，下面几张图请按顺序观看，是作者用OWASP ZAP对某一个网站进行登录的SQL注入测试，网址和登录密码，作者已经打码了，如有侵权或引起其他不适，请联系作者。
——————————————第一步——————————————
——————————————第二步——————————————
——————————————第三步——————————————
——————————————第四步——————————————
——————————————第五步——————————————
InfluxDB性能测试报告
被测环境：
腾讯云
| CPU | 内存 | 带宽 | 版本号 |
| 4核 | 16G | 1Gbit/s | Ubuntu 4.8.4-2ubuntu1~14.04.3 |
地址：
被测程序：
Docker下安装的influxDB 端口8086
压测环境：
腾讯云
| CPU | 内存 | 带宽 | 版本号 |
| 2核 | 8G | 1Gbit/s | Ubuntu 4.8.4-2ubuntu1~14.04.3 |
地址：
测试程序：
从github上找的influxdata公司提供的两款测试工具
influx-stress 用于写入测试
influxdb-comparisons用于查询测试
测试场景：
| 写入测试 | |
| 工具名称 | influx-stress |
| 工具github地址 | https://github.com/influxdata/influx-stress |
| 测试原理 | 该工具是通过go语言的fasthttp库编写的。 1. 会在服务器上创建一个数据库stress 2. 然后创建一个MEASUREMENT（类似关系数据库的表）名为ctr 该表有time,n.some三个字段 3. 不断的向stress数据库的ctr表插入数据，每次插入的数据都包含三个字段。每一条数据称为一个points。 插入数据的方法是通过influxDB的HTTP API 发送请求（POST /write?db=stress） |
| 测试命令 | influx-stress insert -r 60s –strict –pps 200000 –host http://10.XX.XX.XX:8086 |
| 测试程序运行结果 | ||
| Points Per Second（发起请求） | Write Throughput(points/s) （数据库实际处理结果） |
CPU平均利用率 |
| 200000 | 199713 | 33% |
| 300000 | 299280 | 45% |
| 400000 | 392873 | 62% |
| 500000 | 491135 | 80% |
| 600000 | 593542 | 90% |
| 650000 | 606036 | 93% |
| 700000 | 613791 | 95% |
测试结论：最大的吞吐量为每秒写入60万条数据。这之后，每秒发送的points再多，吞吐量也不会增加，同时CPU利用率已达90%。
| 查询测试 | |
| 工具名称 | influxdb-comparisons |
| 工具github地址 | https://github.com/influxdata/influxdb-comparisons |
| 测试原理 | 该工具是通过go语言的fasthttp库编写的。 1. 会在服务器上创建一个数据库benchmark_db 2. 然后创建9个MEASUREMENT ：cpu,disk,diskio,kernel,mem,net,nginx,postgresl 每个measurement 有2160行数据。 3. 通过http GET请求”GET /query?db=benchmark_db“查询cpu这张表。 查询语句为：SELECT max(usage_user) from cpu where (hostname = ‘host_0’) and time >= ‘2016-01-01T01:16:32Z’ and time < ‘2016-01-01T02:16:32Z’ group by time(1m) 可以取出61条数据。 |
| 测试命令 | ./bulk_query_gen -query-type “1-host-1-hr” | ./query_benchmarker_influxdb -urls http://10.XX.XX.XX:8086 -limit 1000 |
| 测试程序运行结果 | ||||
| 查询命令执行次数 （-limit） |
命令最短执行时间 | 每条命令平均执行时间 | 命令最大执行时间 | 总耗时 |
| 100 | 1.20ms | 1.69ms | 4.36ms | 0.2sec |
| 200 | 1.20ms | 1.71ms | 7.40ms | 0.3sec |
| 300 | 1.25ms | 1.73ms | 7.54ms | 0.5sec |
| 400 | 1.21ms | 1.71ms | 7.54ms | 0.7sec |
| 500 | 1.20ms | 1.70ms | 7.54ms | 0.8sec |
| 600 | 1.17ms | 1.67ms | 7.54ms | 1.0sec |
| 700 | 1.14ms | 1.66ms | 8.33ms | 1.2sec |
| 800 | 1.14ms | 1.65ms | 8.33ms | 1.3sec |
| 900 | 1.14ms | 1.63ms | 8.33ms | 1.5sec |
| 1000 | 1.14ms | 1.64ms | 8.33ms | 1.6sec |
测试结论：因为该工具最大只能测到读取1000条数据，所以没有继续加大压力测试。查询操作的消耗时间因为受到被查询表的数据量和查询语句的复杂性影响，所以在influxDate官方给出的被查表和查询语句下，算出来是平均每秒执行600次查询。
很多时候，我们只注意在了自动化的实现上，而忘记了对自动化测试的需求分析上，从而导致后期做出来的目录结构不合适，改动困难，debug难度高，自动化测试的首要特性就是重复执行，不能重复执行，且易暴露问题的自动化，不如手工测试。
我认为的自动化测试框架必有以下特征：
1.方便指定待测集合（用例、套件）运行
2.方便失败之后的debug过程
3.方便编写（建议用强类型语言）
4.与手工测试能互相呼应，能够很容易明白这条用例要做什么。就好比我们说英语一样，我不想要收到了英语的信息之后，通过翻译软件，告知我的大脑它的中文意思，然后我的大脑再在我的记忆之中找出对应的英语单词，最后由我的口发出。我希望是，我接受到了英语信息，我的大脑不需要把英文翻译成中文，而是直接明白英文的意思，并且用英文发出，整个过程不涉及翻译，所以建议不要搞花式的EXCEL关键字驱动或者其他形式的XX驱动，有这么一句话，show me the code
手工测试用例->自动化测试用例需求分析
我们在最初开发自动化测试框架的时候，一定要记住结合目前已有的手工用例，并且分析，最后定出我们自动化测试框架的结构，不然后期会吃大亏，就像产品人员根据已有竞品，分析出我们的开发需求一样，我们得分析我们的手工用例，定义我们的自动化测试框架需求。
这是一条常见的购物测试手工用例：
1.登录网站首页
2.输入用户名，密码
3.购买一款价值500元的产品
4.检查实际支付金额是否正确
期望结果：
实际支付金额正确。
用例看起来很简单。好像操作步骤也不复杂，应该是一条很容易自动化的测试用例。实际不然，我们在做自动化测试的时候，需要进行详细的分析。按照我们自动化的测试逻辑，分为@测试前（数据准备），@测试过程（执行测试步骤）@测试后（用例失败或成功的数据清理）。这条用例按照自动化的逻辑就变成：
@测试前
1.通过数据库插入语句生成一个用户，“用户名”“密码”固定，传入测试数据
2.通过数据库修改语句修改某产品的价格为500，返回“产品名”，传入测试数据
3.通过数据库修改语句修改已知的用户的账户余额大于500
@测试步骤
1.打开网站首页。在网站首页点击登录按钮
2.在登录弹出层输入“用户名”“密码”，按下确定按钮
3.在搜索框输入测试数据中的“产品名”点击搜索按钮
4.在搜索结果列表页点击第一个搜索结果的标题栏
5.在产品详情页点击加入购物车按钮，点击页面右上角的购物车按钮
6.在购物车页面点击立即结算按钮
7.在支付页面选择账户余额支付，完成支付
8.等待页面挑战提示支付成功字样
9.点击页面右上角会员中心按钮
10.在会员中心检查该订单的实际支付金额。获得订单号，传入测试数据
断言：实际支付金额==500
@测试后
1.根据用户名删除该用户
2.判断是否存在订单号，存在则删除订单表中的该订单数据
3.修改购买的该产品的价格为原价
所以，根据上面的用例，我们可以分析出，我们的测试框架有
–测试用例
–测试页面库
–测试动作库
–测试结果校验库
–组合测试步骤库
–其他工具库（包含数据库操作，API操作等）
流程是：
在通过某些工具准备好数据之后，每一个测试用例包含多个测试步骤。每一个测试步骤会在一个测试页面上进行多次动作。操作多个页面元素。操作完成后会经过一到多个测试结果检查。完成测试结果之后，告诉测试基类这次测试的结果是正确还是错误，记录在日志之中。最后在完成所有测试集合之后，最后统一通过邮件发送出来。
在明确业务流程后，完成自动化测试就是具体的落实工作。如果后续有时间，我会发出我推荐的自动化测试代码框架。
我的建议是用testng+ selenide+ ExtentReports+jenkins+maven+jdbc+httpclient这些工具做自动化应该是比较好的，对于mybatis ,dom4j ,poi这些我感觉是用不到的，我曾经加入过excle,xml等一些貌似很合情合理的功能，但是后续在用例失败debug的时候简直让我爆炸，自动化测试，一切从简，能用代码解决的，就不要用其他工具。
jenkins+maven+tomcat做持续集成是web网站不可缺少的了，大部分网站都详细的写了如何配置。这里记一下遇到的问题
1.jenkins 签出svn代码，这个还是比较简单的，网上配置步骤也多，配置成这样，在主页点击立即构建，就会把代码从SVN上加入工作空间了。
2.加入触发器，我设置的是只要SVN有更新就立即构建代码，也可以按照项目需求进行变更，如一天一次。
3.jenkins里使用maven打包，并且跳过测试，通过这种方法会在工作空间的target目录下生成一个*.war包（这个war包就是打包好的程序，可以手动复制该文件到tomcat的webapp目录）关于maven的使用，另有其他网站介绍，主要就是修改pom.xml文件和使用goals命令，是项目管理的一大利器
4.jenkins自动部署tomcat.这里比较麻烦 ,需要先安装jenkins插件,Deploy war/ear to a container。然后在配置里填写如下，war文件用**/*.war就好了。tomcat服务器的管理员账户密码以及tomcat的登录地址加上端口号。如果本地调试，地址就是localhost了。
但是，这样部署之后，tomcat实际上并不能部署成功，会报错，
错误1.如下：
这个时候，需要修改C:Program Filesapache-tomcat-7.0.70conf 目录下的context.xml文件
添加
这个错误解决之后，还有可能出现另外一个错误
错误2，如下：
这很奇怪，需要用到ant的jar包，好吧jenkins部署tomcat环境要用到ant，那就往pom.xml里添加ant的相关配置
org.apache.ant
ant
1.10.1
这样添加之后，再运行项目的立即构建功能，会发现，jenkins能够自动把tomcat目录下的老的无用工程文件删除，重新注入新的工程文件，其实和 maven 的tomcat7:redeploy功能是完全相同的，只是jenkins下使用maven tomcat7:redeploy总报错，所以无奈只能用jenkins插件里的deploy方法
错误1.如下：
Caused by: java.lang.NoSuchMethodException: org.apache.catalina.deploy.WebXml addFilterat org.apache.tomcat.util.IntrospectionUtils.callMethod1(IntrospectionUtils.java:849)at org.apache.tomcat.util.digester.SetNextRule.end(SetNextRule.java:201)at org.apache.tomcat.util.digester.Digester.endElement(Digester.java:1060)这个时候，需要修改C:Program Filesapache-tomcat-7.0.70conf 目录下的context.xml文件
添加
这个错误解决之后，还有可能出现另外一个错误
错误2，如下：
SEVERE: Resource '/WEB-INF/lib/ant-1.7.0.jar' is missing这很奇怪，需要用到ant的jar包，好吧jenkins部署tomcat环境要用到ant，那就往pom.xml里添加ant的相关配置
org.apache.ant
ant
1.10.1
这样添加之后，再运行项目的立即构建功能，会发现，jenkins能够自动把tomcat目录下的老的无用工程文件删除，重新注入新的工程文件，其实和 maven 的tomcat7:redeploy功能是完全相同的，只是jenkins下使用maven tomcat7:redeploy总报错，所以无奈只能用jenkins插件里的deploy方法