关于性能测试中“并发”的解释

当我们在谈论“并发”时

动辄要求系统支持成百上千并发的性能需求太多了，也许系统在实际中确实存在这样的需求，但能够较全面理解此需求的情况并不多。

对于并发，我过去接触了几种理解，在接触的第一种理解中，“并发”是由loadrunner中获取，即脚本中所有或部分vuser执行至集合点函数时进行停留，等待触发条件发生以后，同时执行集合点函数后的请求操作的这一个过程，为“并发”（这一个请求操作一般存在多个http请求），可惜这种“并发”是无法直接用于衡量系统性能的。而在接触的第二种理解中，“并发”的理解是相对于服务器某一个时间区间内接收的请求数，也就是每秒的点击率（loadrunner考虑到这点，也就是analysis里面的hits/s），为“并发”，这种“并发”是可以用于对系统性能状况进行量化的，但是这种测试思想只是比较片面的从性能指标的角度去衡量系统性能，不能体现出系统性能带给用户何种性能体验（这也是不少开源性能测试工具的问题）。

前一种“并发”的理解普遍获得了loadrunner初级用户的认可，后一种“并发”的理解普遍获得系统运维、开发人员的认可，在沟通中为了方便区别开来，在两种角色里面，当大家意识到并发的理解存在差异时，大家把前一种被称为“狭义上的并发”，而后一种被称为“广义上的并发”。后来，又从淘宝团队里面了解了一种定义，貌似淘宝QA把“并发”定义为一个完整的事务请求数量过程（loadrunner也考虑到这点，也就是analysis里面的Transactions per Second）。一直以来，还有一种技术范围以外对“并发”的粗略的理解被第三方测试拿来用了，那就是用户在线数中的某个百分比即并发数。

如果一个团队里面对“并发”的理解有这么多种，那么当我们在讨论性能需求的“支持并发数”时，我们究竟在讨论什么呢？

个人认为，有一部分的原因是由于loadrunner是惠普saas（软件即服务的解决方案）的一部分，所以并不是一个纯粹技术人员使用的测试工具，它同时也是一个业务人员可以相对轻易掌握的性能测试工具，因此loadrunner内很多名词解释也不能单纯从技术人员的角度从字面意义上理解。

通常来说，面对同样100笔业务交易量，普遍会认为100vuser对服务器产生的负载会比50vuser要高，但是在性能脚本能够在较快的响应时间中完成时，由于50vuser执行过程中每一个vuser都需要发生两次迭代，导致了性能场景中vuser在脚本action部分停留的时间更长，因此反而能够得到比100vuser的更高的vuser在线数，更高在线数带来的也就是更大的负载，也就是说：

同等业务量的情况下，50 线程所产生的负载完全有可能比100 线程所产生的负载要高。

为了避免发生这种问题，“并发（集合点）”的真正作用就体现出来了，通过集合点函数控制了vuser的行为相对一致，降低了初始化过程和事务前后文请求产生的时间差影响。测试工具中并发存在的真正意义也就在这里，对集合点所理解的“并发”，和现场实际用户里面同时触发的请求关系不是太大。

分析“并发”需求时的一些典型：

a) 某个业务系统里面有10000用户，但是能够访问这个系统的终端数只有1000个、或者所需测试的业务每个月上限是1000笔，那么最高在线用户数就不可能超过1000、业务量也不可能超过1000。所以，有些时候在分析性能需求的时候，去统计一个业务系统的用户数还不如去统计能够访问这个系统的终端数、甚至业务量靠谱。

b) 某个业务系统里面，各个业务模块都不一样，那么就是说完成一笔业务交易，所产生的请求数也是不一样的，例如表单新增，有的需要填写20个字段，有的只需要填写5个字段，各个表单都不一样，那么为了更接近的去模拟用户现场负载，请求数都不一样的各种业务混在一起，并发数又应该是多少呢？

为了解决这些问题，需要首先考虑“并发”的粒度，以真实的业务场景为例：

a) 把粒度控制在用户上来看，假定所有用户访问一次系统平均耗时500秒，一个业务峰值会有800用户在线，则800/500=1.6。理论上，系统的性能需求是每秒要成功处理1.6个用户的请求；

b) 把粒度控制在事务上来看，假定所有用户执行一次完整的、成功的业务操作平均需要500秒，一个业务峰值有2000笔所关注的业务需要去执行，则2000/500=4。理论上，系统的性能需求是每秒要成功处理4笔业务交易；

c) 把粒度控制在请求上来看，假定所有用户执行一次完整的、不管成功或者失败的HTTP请求操作平均需要0.08秒，一个业务峰值有28000个请求需要去完成，则28000/0.08=350000。理论上，系统的性能需求是每秒要成功处理350000个请求。

实际一点的案例看看

在下面的图表中，横轴表示了某业务系统中上午9：00至12：00的一个区间，假定期间只有A、B、C访问了该业务系统。如果用户的访问过程中发送一个请求，则在请求发生的时间中标识一个点，由图可见：

A用户的行为：早上9：00访问了业务系统，并发生了一连串的请求（多个点已经连成一条直线），再然后没有再连续的发生请求（没有再出现黑线），而是有规律的间歇请求，我们暂且猜想用户A这个时候在浏览系统中的业务数据，这确实也符合浏览行为，空白阶段可以理解为在线的浏览，并不会对服务器产生负载；

B用户的行为：早上9：00访问了业务系统，并在临近12：00访问了业务系统，发送了一连串的请求，我们猜想该用户在执行了一些业务操作，浏览所占的比例比较低；

C用户的行为：仅仅在10：30左右访问了业务系统，执行了一连串业务操作以后没有再访问系统。

那么在这里案例里面，我们已知：3用户在线。问题：并发用户最高该是多少？答案其实显而易见，并发只有2个用户，因为用户C执行的业务操作的同时只有A也在执行业务操作，B完全是不在线。

还会有人认为100用户在线就应该上100个vuser/线程么？

问题一：软件测试中性能测试需要关注什么 性能测试需要关注的第3件事，就是被测系统所处的操作系统环境。要破译它，必须要学会凌驾它的命令，不论是windows，unix，还是liunx，皆如此。淘宝用的是liunx，于是我们自然要学会活用liunx命令。在性能测试过程中，我们往往要查询服务器资源使用情况，例如cpu,load,i/o等。此时，top命令、uptime命令、iostat命令就显得尤为重要。在性能测试过程中，我们往往要查询服务器的log信息。此时，cd命令、vi/vim命令、cat命令、grep命令、tail命令就能大显身手。在性能测试过程中，我们往往要查看某个进程使用的虚拟内存和物理内存。此时，cat /proc/pid/status就十分有用。在性能测试过程中，我们往往要查看某个文件占用了大量的空间。此时，find命令派上用场。此处不一一列举。上述这些命令，均可以根据实际情况，配以对应的参数，进行更好的跟踪来采集所需要的数据。liunx命令的灵活应用，配合shell的语法规则，能写出许多非常使用的小脚本。这些东西，对于性能测试，及性能测试结果分析，都有相当重要的意义。

问题二：软件性能测试需要会什么 这个你算问对人了。给你说几点吧，为什么性能测试在软件测试里面算是吃香的，因为他的要求也比较多，需要掌握：网络方面、数据库方面（Oracle、SQLserver、mysql）、操作系统（如Linux方面）、脚本（如shell）、性能测试工具、资源监控工具、瓶颈定位工具，以及分析问题的能力。除此在外要对Java或要有一定了解。尤其是内存机制方面。如果你想成为一名合格的性能测试工程师的话 ，慢慢学吧

问题三：性能测试应该做哪些准备 环境搭建：这个根据实际规划，我在企业内做过的性能测试搭建的环境都是和用户上线使用的实际环境一样的。

数据准备：个人感觉是整个工作里第二耗时的，需要真实模拟用户数据，这个不是单单的创建几个帐号就完事的，每个用户基本都会有不太一样的配置，实际操作的时候部署数据的脚本都写到手软。

脚本编译：选择性能工具编译性能脚本，你需要跑什么业务流程就编译什么样的脚本。

脚本执行：用规划好的用户数执行脚本，这个一般持续很长时间，时间太短不足以暴露服务器等的性能瓶颈，性能测试中最耗时的就是这个步骤。

收集日志：在执行脚本完成后收集到的能客观反应系统性能的日志、报表文件，比如LR的报告、数据库的AWR日志等等。

分析结果：分析收集到的日志、报表，找出性能瓶颈或是得出性能指标结果。这个一般需要对数据库或者底层非常了解的专业人士来分析，一般测试人员只需要提供收集到的报告就差不多了。

生成报告：将上面所有的性能测试活动整理总结，输出测试报告。

问题四：要做好性能测试，该掌握些什么？ 这类问题之前也被问到很多次了，所以这次干脆整理一下，发个主题供同行们参考。如果需要补充，也欢迎大家留言一起讨论。 如果想真的做好性能测试，需要学习的东西还是比较多的。简单列一下吧。 1. 精通性能测试的基本概念，过程，方法论，了解性能工程；

3. 扎实的计算机专业基础知识，包括计算机组成原理、操作系统、数据库原理、计算机网络原理；

4. 熟悉至少1个常用的数据库产品，例如SQL Server或者 Oracle，能进行一般的数据库管理操作，熟悉SQL脚本的使用，熟悉常用的数据调优工具和常用的counter；

5. 熟悉至少一个操作系统的原理，Windows或者Linux都可以，熟悉操作系统的体系架构、操作系统的重要基础概念，以及内存管理、存储/文件系统、驱动/硬件的管理、网络协议的实现及构成、性能的监控方法和原理，熟悉常用的counter；

6. 熟悉至少一个web server 产品，例如apache，了解一般的配置和常用的counter；

7. 熟悉至少一个应用服务器产品，例如tomcat，了解一般的配置，熟悉常用的服务器性能监控方法和原理，熟悉常用的counter；

8. 至少熟悉TCP/IP协议，熟悉HTTP协议，至少见过并了解三层、四层交换或者路由器的使用和配置。了解常用的与网络性能相关的counter；

9. 了解一般的大型企业应用的部署架构和应用架构；

10. 了解知名大型web应用、高并发量、高流量、实时响应要求高的超大规模网站的架构和优化历程；

11. 熟悉统计学的基础知识、常用分析方法以及实验设计方法，了解数学建模相关的知识；

12. 熟悉专属行业的业务知识和用户场景，例如电信行业的OSS系统所涉及的业务知识和用户场景，证券交易系统所涉及的业务知识和用户场景；

13. 大量的实际性能测试及优化经验；

14. 积极的参与到各类圈子、社团的讨论和交流、分享中。 暂时先想到了这么多，有兴趣的朋友可以一起讨论一下，相信每个人都有自己不同的经历和感想，可以跟其他人分享一下，提供参考。

另外，我之前也整理发布过不少性能测试方面的资料，从入门级的文章到 升级的必读都有一些，有兴趣可以参考。

问题五：性能测试的内容 性能测试 在软件的质量保证中起着重要的作用，它包括的测试内容丰富多样。中国软件评测中心将性能测试概括为三个方面：应用在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。通常情况下，三方面有效、合理的结合，可以达到对系统性能全面的分析和瓶颈的预测。 应用在客户端性能测试的目的是考察客户端应用的性能，测试的入口是客户端。它主要包括并发性能测试、疲劳强度测试、大数据量测试和速度测试等，其中并发性能测试是重点。并发性能测试是重点并发性能测试的过程是一个负载测试和压力测试的过程，即逐渐增加负载，直到系统的瓶颈或者不能接收的性能点，通过综合分析交易执行指标和资源监控指标来确定系统并发性能的过程。负载测试（Load Testing）是确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统组成部分的相应输出项，例如通过量、响应时间、CPU负载、内存使用等来决定系统的性能。负载测试是一个分析软件应用程序和支撑架构、模拟真实环境的使用，从而来确定能够接收的性能过程。压力测试（Stress Testing）是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。并发性能测试的目的主要体现在三个方面：以真实的业务为依据，选择有代表性的、关键的业务操作设计测试案例，以评价系统的当前性能；当扩展应用程序的功能或者新的应用程序将要被部署时，负载测试会帮助确定系统是否还能够处理期望的用户负载，以预测系统的未来性能；通过模拟成百上千个用户，重复执行和运行测试，可以确认性能瓶颈并优化和调整应用，目的在于寻找到瓶颈问题。当一家企业自己组织力量或委托软件公司代为开发一套应用系统的时候，尤其是以后在生产环境中实际使用起来，用户往往会产生疑问，这套系统能不能承受大量的并发用户同时访问? 这类问题最常见于采用联机事务处理(OLTP)方式数据库应用、Web浏览和视频点播等系统。这种问题的解决要借助于科学的软件测试手段和先进的测试工具。举例说明：电信计费软件众所周知，每月20日左右是市话交费的高峰期，全市几千个收费网点同时启动。收费过程一般分为两步，首先要根据用户提出的电话号码来查询出其当月产生费用，然后收取现金并将此用户修改为已交费状态。一个用户看起来简单的两个步骤，但当成百上千的终端，同时执行这样的操作时，情况就大不一样了，如此众多的交易同时发生，对应用程序本身、操作系统、中心数据库服务器、中间件服务器、网络设备的承受力都是一个严峻的考验。决策者不可能在发生问题后才考虑系统的承受力，预见软件的并发承受力，这是在软件测试阶段就应该解决的问题。大多数公司企业需要支持成百上千名用户，各类应用环境以及由不同供应商提供的元件组装起来的复杂产品，难以预知的用户负载和愈来愈复杂的应用程序，使公司担忧会发生投放性能差、用户遭受反应慢、系统失灵等问题。其结果就是导致公司收益的损失。如何模拟实际情况呢? 找若干台电脑和同样数目的操作人员在同一时刻进行操作，然后拿秒表记录下反应时间？ 这样的手工作坊式的测试方法不切实际，且无法捕捉程序内部变化情况，这样就需要压力测试工具的辅助。测试的基本策略是自动负载测试，通过在一台或几台PC机上模拟成百或上千的虚拟用户同时执行业务的情景，对应用程序进行测试，同时记录下每一事务处理的时间、中间件服务器峰值数据、数据库状态等。通过可重复的、真实的测试能够彻底地度量应用的可扩展性和性能，确定问题所在以及优化系统性能。预先知道了系统的承受力，就为最终用户规划整个运行环境的配置提供了有力的依据。并发性能测试前的准备工作测试环境：配置......>>

问题六：软件性能测试的目的 为了验证系统是否达到用户提出的性能指标，同时发现系统中存在的性能瓶颈，起到优化系统的目的。

问题七：软件测试一般都用到哪些工具 测试工具分为很多种，主要如下：

测试管理工具：MQC，TestManager，QACenter，其中缺陷跟踪还可以使用：变更管理工具

功能测试自动化：QTP，RFP，QARun，Silk

性能测试工具：Loadrunner，Robot，QAload，WAS，Silk Performance

单元、白盒测试工具：Junit,Jmeter，devpartner，骸probe，Purify Plus

安全测试： Appscan，Fortify

问题八：手机软件的测试主要有哪些方面去测试，性能测试用什么去测试好？ 罗列几个比较有代表性的方向：

功能测试

性能测试

稳定性测试

安全测试

兼容性测试

网络环境测试

位置定位测试等

如何做性能测试：

明确测试目标，了解性能测试需求

编写性能测试计划

分析性能测试需求

编写性能测试方案、设计测试场景

相关资源准备(人力资源、硬件资源、软件资源)

测试程序开发，脚本维护、测试数据准备、测试监控准备

执行性能测试并收集测试结果

分析结果

系统调优及再测试

现今的安卓开发环境，碎片化现象十分严重。安卓机型铺天盖地，很多中小型研发团队缺少测试环境，也没有资金和精力购全机型，这时就引入了一个云真机测试的概念。WeTest平台的云真机测试 wetest.qq/...zhidao 平台提供上千台真实的安卓主流机型，随时随地进行测试，提供截图、实时日志和各种性能数据。

如果以上回答能帮助到你那就最好不过了~

问题九：测试主板性能的软件有哪些 WinBench 99可以用来测试各个部件的性能的。你可以用3DMARK测试一下电脑各个部件的性能，一般上3DMARK所有项目都通过的话，就说明主板和其他部分没有什么冲突的问题了。

问题十：app的性能测试到底是测什么意思 app的性能测试要关注

包体大小、CPU 占用率、图片处理器每秒刷新的帧数、内存使用、电量、流量等等

Apache服务器自带了ab压力测试工具，可以用来测试网站性能，使用简单方便。

工具/原料

Apache

方法/步骤

打开Apache服务器的安装路径，在bin目录中有一个ab.exe的可执行程序，就是我们要介绍的压力测试工具。

在Windows系统的命令行下，进入ab.exe程序所在目录，执行ab.exe程序。注意直接双击无法正确运行。

执行ab命令成功后，可以看到如图提示。该帮助很清楚详细的介绍了ab的用法以及各个参数的含义。

ab 的用法是：ab [options] [http://]hostname[:port]/path

例如：ab -n 5000 -c 200 http://localhost/index.php

上例表示总共访问http://localhost/index.php这个脚本5000次，200并发同时执行。

ab常用参数的介绍：

-n ：总共的请求执行数，缺省是1；

-c： 并发数，缺省是1；

-t：测试所进行的总时间，秒为单位，缺省50000s

-p：post时的数据文件

-w: 以html表的格式输出结果

执行测试用例：ab -n 1000 -c 100 -w http://localhost/index.php >>c:\1.html

上面的测试用例表示100并发的情况下，共测试访问index.php脚本1000次，并将测试结果保存到c:\1.html文件中。

测试报告如图，可知在该100并发访问的情况下，共测试访问1000次，失败了852次。可知该脚本在此环境无法满足100并发访问的要求。

修改参数继续测试。测试并发50和30两种情况，由测试报告得知，在并发访问降到30时，错误的访问数降为39。

步骤阅读

---