eg1.接口性能
测试需求
测试以下接口的性能
应用服务器：192.168.10.111 linux
接口名称：login
访问路径：/login
通讯协议：http
请求数据格式：json
请求报文体个构成：
username：“字符串”
password：“字符串”
sign：“字符串”
响应数据格式：json
响应报文体构成：
RespondCode：int
RespondMsg：“文本”
OK，首先这是一个接口的性能测试，没有具体的业务需求，只有接口的一些定义，那么这种情况下一般是在测试环境看看接口的业务处理能力，并且这里只有应用服务器的地址，没有后台数据库等其他相关服务器的地址，故表面上好像只能监控应用服务器的资源。我们下面来进行逐步的分析，制定一个测试方案和测试案例。
测试目的：没有明确的目的要求，就是随机测试一下现有环境下的接口处理性能
业务需求：登录接口，没有说大概的用户需求以及服务器响应时间时延等，从测试目的来看是可以一直加压知道服务器不能处理，分析进行适当的优化，即可。
系统结构：没有说明系统的具体部署结构，那么我们有两种方式来确定系统结构，谁下达的任务可以让谁向上追溯询问被测系统的部署结构，是否与中间件？中间件用的什么？部署位置？是否有数据库？数据库是什么？部署位置？是否有外部接口调用？（不要以为一个简单的接口后面运行没有外部接口，这也是有可能的）最好是有一个部署结构图？
需要监控所有的部署节点；拿到部署结构比如说有tomcat，有数据库mysql等等部署位置也都拿到了。开始按照自己理解的系统关系画系统数据流向图，并和相关人员确认。得到最终的系统结构关系图。
一般性能指标确认：响应时间（2（较好）-5（一般）-8（较差，不理想）原则），CPU/IO-Wait/MEN占用（均值70%/10%/70%）等等是否可以达成一致认识。最终要达成一个一致认可的值。
系统环境确认:应用服务器硬件设备（CPU/MEN/DISK），数据库硬件设备（CPU/MEN/DISK），操作系统的配置（最大打开文件句柄数，TCP连接数），应用服务器tomcat参数配置（内存/连接数等），数据库配置（内存/连接数/存储模式等）
分析可能瓶颈：硬件设备的内存是多少？DISK的IO限制是多少？（后面的tomcat以及数据库的参数配置是否已经优化过？数据库是否支持异步存储？数据存储是否支持批量读写？等等，新手测试对这些不了解可以暂时不用管它，后面发现是这方面的问题再优化也可以）这一步也可以在后续的测试优化中再考虑。
测试方案：
(1)测试内容/目的/系统结构 设备软硬件环境等已经可以列出来了；
(2)测试工具选择---选择一个自己比较熟悉，有较简单的工具；（比如像这种已知输入输出的接口，选择JMETER做性能测试比较容易点。）
(3)测试监控---选择一个自己比较熟悉，能够快速使用起来的工具（比如NMON，JMETER Server-Agent插件）
(4)测试案例设计：
一般业性能测试案例：
操作步骤：
（1）在数据库构造和预置3000万用户数据；
（2）测试之前5分钟，在应用服务器和数据库服务器开启系统资源监控；
（3）使用测试工具模拟用户发送登录请求，施压用户1000万，其中正确登录用户（用户密码匹配）占比90%，错误登录用户（用户密码不匹配）占比10%，（结合接口返回的错误信息和错误码考虑各种返回的情况，合理安排比例）；
（4）持续对服务器进行施压测试30分钟以上
（5）停止施压，5分钟后停止监控服务器的监控，后去监控数据
预期结果：
(1)测试过程中服务器资源占用CPU（均值小于70%），内存（均值小于80%，或者使用期间没有内存泄漏和错误产生），IO-Wait（均值小于10%）（资源占用可根据需要进行调整，或者没有预期，只是测试一个结果，如果测试结果较好就继续加压，测试结果不好就考虑进行优化）
(2)业务成功率目标100%（成功90%，失败10%，各种返回比例满足事先的预期设计比例值）
(3)其他业务需求
OK,还需要一些测试安排计划和测试风险的评估，补充到测试方案里面。一个基本的测试方案基本就可以算是完成了。
测试脚本开发：
这个跟你选择的工具而定，本文就不在此详说，后面会继续分享到部分用常用工具进行测试脚本的开发。
本篇就简单介绍一下简单接口的性能测试，下一篇再找一个复杂一点的需求来做一下测试方案制定的实例分析。
