性能测试流程5步走：BS架构和CS架构性能指标大对比

性能测试的目的，简单说其实就是为了获取待测系统的响应时间、吞吐量、稳定性、容量等信息。而发现一些具体的性能相关的缺陷（如内存溢出、并发处理等问题），我认为只是一种附加结果。从更高的层次来说，性能测试最想发现的，是瓶颈。如何能得到所需要的信息，就需要从多方面进行测试。

拿到一个性能测试任务的时候，我们首先需要明确我们的测试目标和输出结果是什么；没有计划的开始注定是失败的。做性能测试需要一个规范的流程，划分清各个阶段需要做哪些工作，这样我们在接到一个任务时就不会手忙脚乱。

性能测试流程大致分为一下几个阶段：

测试准备

脚本开发与调试

测试执行

测试结果评估

测试后跟踪

测试准备包括：

测试目标：

从需求文档或者用户获取：并发用户数，事务吞吐需求，响应时间需求，系统占用资源需求，可扩展性需求等；

应用软件：

从开发人员获取：系统整体架构（BS/CS），采用开发语言，通信协议，动态session，验证码等；

系统部署平台：

从运维人员获取：物理部署（局域网/虚拟机），硬件架构（CPU/MEM/IO），操作系统，数据库（版本/启动参数/存储布局），中间件（参数配置），部署模式等；

系统负载模型：

通过调研获取：从业务层面选取关键用例吞吐率以及用户行为习惯，确定测试流程及流程业务比例；从系统负载方面了解高峰/平常场景吞吐率；

制定测试计划和测试方案

测试脚本是做好性能测试的基础，监控结果是性能测试的关键；扎实的代码基础和熟练掌握监控结果的收集和分析是性能测试的保障；系统上线后，对实际负载与性能情况和测试过程中做比较总结经验也是学习提高的好方法。

在实际中作中我们经常会对两种类型软件进行测试：bs和cs，这两方面的性能指标一般需要哪些内容呢？
Bs结构程序一般会关注的通用指标如下（简）：
Web服务器指标指标：
* Avg Rps: 平均每秒钟响应次数＝总请求时间 / 秒数；
* Avg time to last byte per terstion （mstes）:平均每秒业务角本的迭代次数 ,有人会把这两者混淆；
* Successful Rounds：成功的请求；
* Failed Rounds ：失败的请求；
* Successful Hits ：成功的点击次数；
* Failed Hits ：失败的点击次数；
* Hits Per Second ：每秒点击次数；
* Successful Hits Per Second ：每秒成功的点击次数；
* Failed Hits Per Second ：每秒失败的点击次数；
* Attempted Connections ：尝试链接数；
CS结构程序，由于一般软件后台通常为数据库，所以我们更注重数据库的测试指标：
* User 0 Connections ：用户连接数，也就是数据库的连接数量；
* Number of deadlocks：数据库死锁；
* Butter Cache hit ：数据库Cache的命中情况
当然，在实际中我们还会察看多用户测试情况下的内存，CPU，系统资源调用情况。这些指标其实是引申出来性能测试中的一种：竞争测试。什么是竞争测试，软件竞争使用各种资源（数据纪录，内存等），看他与其他相关系统对资源的争夺能力。
我们知道软件架构在实际测试中制约着测试策略和工具的选择。如何选择性能测试策略是我们在实际工作中需要了解的。

一般软件可以按照系统架构分成几种类型：
c/s
client/Server 客户端/服务器架构
基于客户端/服务器的三层架构
基于客户端/服务器的分布式架构
b/s
基于浏览器/Web服务器的三层架构
基于中间件应用服务器的三层架构l
基于Web服务器和中间件的多层架构l

总结：

总的来说，我认为，性能测试的难度主要不在技术手段上，互联网时代技术都是共享的，要善于去搜索利用他人的成果。即使自己搞不定，团队内一定还有专业的开发工程师、数据库管理员、系统管理员可以帮你搞定。真正的难点在于，你要想出来如何去测是有效的、有保障的，这才是测试工程师最重要的能力。

还是那个观点，思想才是根本。