性能测试基础知识

性能测试基础知识
性能测试基础知识

性能测试基础知识

一、性能测试概述

1、性能测试定义

所谓性能,有狭义和广义两种含义。狭义的性能指运行速度的快慢。广义的性能涉及很多内容,如可靠性、可用性、功耗、环境适应性、兼容性、安全性、保密性、可扩充性、可移植性、利用率、性能价格比、速度等。

性能测试是通过自动化的测试程序或工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。

2、性能测试目的

真实环境下检测系统性能,评估系统性能以及服务等级的满足情况

预见系统负载压力承受力,在应用实际部署之前,评估系统性能

分析系统瓶颈,优化系统

二、主要性能指标

响应时间、吞吐量、并发、点击率、资源利用率

1、响应时间

响应时间指的是客户端发出请求到得到响应的整个过程所经历的时间。

响应时间=网络传输时间*2+服务器处理时间+客户端显示时间。

2、吞吐量

单位时间内流经被测系统的数据流量,一般单位为b/s,即每秒钟流经的字节数。吞吐量是指单位时间内系统处理的客户请求的数量,直接体现软件系统的性能承载能力。

TPS的概念,每秒事务数。确实TPS会随着负载的增加而逐渐增加,但不会无限制的一直增加。比如,到了300用户后就会出现连接服务失败,那可能说明系统进入了繁忙期,从而产生了失败的事务,从而使得每秒的事务数不再增加,甚至会减少。

TPS就像是一个抛物线,可分为3部分,轻负载区、重负载区、负载失效区。

一开始上升的部分就是轻负载区,最顶端的部分就是TPS的峰值(重负载区),然后随着负载的继续增加,TPS会慢慢下降,从而进入我们所谓的负载失效区。

3、并发用户数

指在某一给定时间内,某个特定点上进行会话操作的用户数。是陆陆续续交替执行的。

随着用户数的增加,HIT PER SECOND开始逐渐减少,说明系统已经开始有失败的VUSER 和事务出现。

4、资源利用率

CPU利用率、内存利用率、磁盘利用率、网络带宽利用率

服务器的CPU在35%内,不存在服务器瓶颈。

想知道服务器有没有拥堵,看看服务器CPU使用率是多少,排队队列是多少

带宽利用率:100MB 约能用6-8%才是实际。

做性能测试时不能让客户机本身成了瓶颈。(客户机cpu使用达到80%就要添加1台测试机)

5、点击率

每秒完成的请求数,点击率是按照客户端向后台发起了多少次请求来计算的。除程序处理速度,还受带宽的限制,每个请求的大小情况。请求越小,每秒完成的请求越多。在排除带宽影响的情况下,做了缓存的系统比没做缓存的系统的点击率要高很多。在网络传输到达一定的程度后,点击率就不会随并发量的增长而增大。

总结如下:并发用户数和QPS两个概念没有直接关系,但是如果要说QPS时,一定需要指明是多少并发用户数下的QPS,否则豪无意义。因为单用户数的40QPS 和20并发用户数下的40QPS是两个不同的概念。前者说明该应用可以在一秒内串行执行40个请求,而后者说明在并发20个请求的情况下,一秒内该应用能处理40 个请求,当QPS相同时,越大的并发用户数,代表了网站并发处理能力越好。对于当前的web服务器,其处理单个用户的请求肯定戳戳有余,这个时候会存在资源浪费的情况。而当并发数设置的过大时,每秒钟都会有很多请求需要处理,会造成进程(线程)频繁切换,真正用于处理请求的时间变少,每秒能够处理的请求数反而变少,同时用户的请求等待时间也会变大,甚至超过用户的心理底线。所以在最小并发数和最大并发数之间,一定有一个最合适的并发数值,在并发数下,QPS能够达到最大。但是,这个并发并非是一个最佳的并发,因为当QPS到达最大时的并发,可能已经造成用户的等待时间变得超过了其最优值,所以对于一个系统,其最佳的并发数,一定需要结合QPS,用户的等待时间来综合确定。

系统吞吐量几个重要参数:QPS(TPS)、并发数、响应时间

QPS(TPS):每秒钟request/事务数量

并发数:系统同时处理的request/事务数

响应时间:一般取平均响应时间

理解了上面三个要素的意义之后,就能推算出它们之间的关系:

QPS(TPS)= 并发数/平均响应时间

一个系统吞吐量通常由QPS(TPS)、并发数两个因素决定,每套系统这两个值都有一个相对极限值,在应用场景访问压力下,只要某一项达到系统最高值,系统的吞吐量就上不去了,如果压力继续增大,系统的吞吐量反而会下降,原因是系统超负荷工作,上下文切换、内存等等其它消耗导致系统性能下降。

三、性能测试的主要类型

一般性能测试

稳定性测试

负载测试

压力测试

并发性能测试

疲劳强度测试

大数据量测试

1、一般性能测试

狭义角度的性能测试,是一种“正常”的测试,主要是测试正常使用时,系统及时性(响应时间、吞吐率)是否满足要求,同时可能为了保留系统的扩展空间进行一些稍稍超出“正常”范围的测试。

2、稳定性测试

通过给系统加载一定的业务压力的情况下,让应用持续运行一段时间,测试系统在这种条件下是否能够稳定运行。

3、负载测试

通过逐步增加系统负载,测试系统性能的变化,并最终确定在满足系统的性能指标情况下,系统所能够承受的最大负载量的测试。

4、压力测试

通常是指持续不断的给被测系统增加压力,直到将被测系统压垮为止,用来测试系统所能承受的最大压力。压力测试是为了发现在什么条件下应用程序的性能会变得不可接受。

5、并发性能测试

并发性能测试的过程,是一个负载测试和压力测试的过程。即逐渐增加并发虚拟用户数负载,直到系统的瓶颈或者不能接收的性能点,通过综合分析交易执行指标、资源监控指标等来确定系统并发性能的过程。并发性能测试是负载压力测试中的重要内容。

6、疲劳强度测试

通常是采用系统稳定运行情况下能够支持的最大并发用户数或者日常运行用户数,持续执行一段时间业务,通过综合分析交易执行指标和资源监控指标来确定系统处理最大工作量强度性能的过程。

疲劳强度测试案例制定的原则是保证系统长期不间断运行的业务量,并且应该尽量去满足该条件。

7、大数据量测试

独立的数据量测试:针对某些系统存储、传输、统计、查询等业务进行大数据量测试

综合数据量测试:与压力测试负载测试相结合的综合测试方案

3. 性能测试的主要类型

测试类型的区别

负载测试与压力测试

稳定性测试与疲劳强度测试

四、性能工具

LoadRunner、Jmeter;

Nmon、Spotlight

五、测试一般过程

明确测试目标

测试计划

测试需求分析

测试方案设计

测试资源准备

测试执行

测试结果分析

性能测试培训——基础知识

性能测试培训(一) ——基础知识 1.软件性能测试的概念 1.1软件性能与性能测试 软件性能:覆盖面广泛,对一个系统而言,包括执行效率、资源占用、稳定性、安全性、兼容性、可扩展性、可靠性等。 性能测试:为保证系统运行后的性能能够满足用户需求,而开展的一系列的测试组织工作。 1.2不同角色对软件性能的认识 用户眼中的软件性能: ?软件对用户操作的响应时间 如用户提交一个查询操作或打开一个web页面的链接等。 ?业务可用度,或者系统的服务水平如何 管理员眼中的软件性能:

开发人员眼中的软件性能: 1.3性能测试的对象 服务器端: ?负载均衡系统; ?服务器(单机、双机热备、集群); ?存储系统、灾备中心; ?数据库、中间件。 网络端: ?核心交换设备、路由设备; ?广域网络、专线网络、局域网络、拨号网络等; 应用系统: 由此可见,性能测试是一个系统性的工作,被测对象包括系统运行时使用的所有软硬件。但在实际操作时,将根据项目的特点,选择特定的被测对象。 1.4性能测试的目标 评价系统当前的性能:

?系统刚上线使用,即处于试运行时,用户需要确定当前系 统是否满足验收要求; ?系统已经运行一段时间,如何保证一直具有良好的性能。分析系统瓶颈、优化系统: ?用户提出业务操作响应时间长,如何定位问题,调整性能; ?系统运行一段时间后,速度变慢,如何寻找瓶颈,进而优 化性能。 预见系统未来性能、容量可扩充性: ?系统用户数增加或业务量增加时,当前系统是否能够满足 需求,如果不能,需要进行哪些调整?提高硬件配置?增 加应用服务器?提高数据库服务器的配置?或者是需要对 代码进行调整? 1.5性能测试的分类 按照测试压力级别: ?负载测试; ?压力测试; 按照测试实施目标: ?应用在客户端的测试; ?应用在网络的测试; ?应用在服务器端的测试; 按照测试实施策略:

详解网站性能测试指标

网站的性能测试指标包括了Web应用服务器、数据库服务器及系统服务器等各种性能测试。每一项测试中都需要根据项目要求完成测试,本文重点讲述了网站性能测试指标,并加以案例分析。 通用指标(指Web应用服务器、数据库服务器必需测试项) Web服务器指标 数据库服务器性能指标 系统的瓶颈定义

稳定系统的资源状态 通俗理解: ·日访问量 ·常用页面最大并发数 ·同时在线人数 ·访问相应时间 案例: 最近公司一个项目,是个门户网站,需要做性能测试,根据项目特点定出了主要测试项和测试方案: 一种是测试几个常用页面能接受的最大并发数(用户名参数化,设置集合点策略) 一种是测试服务器长时间压力下,用户能否正常操作(用户名参数化,迭代运行脚本) 一种则需要测试服务器能否接受10万用户同时在线操作,如果是用IIS做应用服务器的话,单台可承受的最大并发数不可能达到10万级,那就必须要使用集群,

通过多台机器做负载均衡来实现;如果是用websphere之类的应用服务器的话,单 台可承受的最大并发数可以达到10万级,但为性能考虑还是必须要使用集群,通 过多台机器做负载均衡来实现;通常有1个简单的计算方式,1个连接产生1个session,每个session在服务器上有个内存空间大小的设置,在NT上是3M,那么10万并发就需要300G内存,当然实际使用中考虑其他程序也占用内存,所以准备 的内存数量要求比这个还要多一些。还有10万个用户同时在线,跟10万个并发数是完全不同的2个概念。这个楼上已经说了。但如何做这个转换将10万个同时在 线用户转换成多少个并发数呢?这就必须要有大量的历史日志信息来支撑了。系统日志需要有同时在线用户数量的日志信息,还需要有用户操作次数的日志信息,这 2个数据的比例就是你同时在线用户转换到并发数的比例。另外根据经验统计,对 于1个JAVA开发的WEB系统(别的我没统计过,给不出数据),一般1台双CPU、2G内存的服务器上可支持的最大并发数不超过500个(这个状态下大部分 操作都是超时报错而且服务器很容易宕机,其实没什么实际意义),可正常使用(单步非大数据量操作等待时间不超过20秒)的最大并发数不超过300个。假设 你的10万同时在线用户转换的并发数是9000个,那么你最少需要这样的机器18台,建议不少于30台。当然,你要是买个大型服务器,里面装有200个CPU、 256G的内存,千兆光纤带宽,就算是10万个并发用户,那速度,也绝对是嗖嗖的。 另外暴寒1下,光设置全部进入运行状态就需要接近6个小时。具体的可以拿1个 系统来压一下看看,可能会出现以下情况: 1、服务器宕机; 2、客户端宕机; 3、从某个时间开始服务器拒绝请求,客户端上显示的全是错误; 4、勉强测试完成,但网络堵塞或测试结果显示时间非常长。假设客户端和服务器 之间百兆带宽,百兆/10000=10K,那每个用户只能得到10K,这个速度接近1个 64K的MODEM上网的速度;另外以上分析全都没考虑系统的后台,比如数据库、中间件等。 1、服务器方面:上面说的那样的PC SERVER需要50台; 2、网络方面:按每个用户50K,那至少5根百兆带宽独享,估计仅仅网络延迟就 大概是秒一级的; 3、如果有数据库,至少是ORACLE,最好是SYSBASE,SQL SERVER是肯定顶 不住的。数据库服务器至少需要10台4CPU、16G内存的机器; 4、如果有CORBA,那至少再准备10台4CPU、16G内存的机器;再加上负载均衡、防火墙、路由器和各种软件等,总之没个1000万的资金投入,肯定搞不定。

服务器性能测试典型工具介绍

服务器性能测试典型工具介绍 https://www.360docs.net/doc/144363492.html,/ 2008-11-17 16:42 IT168 我要评论(2) ?摘要:本文介绍了几个比较典型的服务器评测软件,无论什么评测工具,基本的技术都是利用线程技术模仿和虚拟用户,在这里主要的难点在于测试脚本的编写,每种工具使用的脚本都不一样,但是大多数工具都提供录制功能就算是不会编码的测试人员同样可以测试。 ?标签:服务器评测测试工具 ? Oracle帮您准确洞察各个物流环节众所周知,服务器是整个网络系统和计算平台的核心,许多重要的数据都保存在服务器上,很多网络服务都在服务器上运行,因此服务器性能的好坏决定了整个应用系统的性能。 现在市面上不同品牌、不同种类的服务器有很多种,用户在选购时,怎样从纷繁的型号中选择出所需要的,适合于自己应用的服务器产品,仅仅从配置上判别是不够的,最好能够通过实际测试来筛选。而各种的评测软件有很多种,你应该选择哪个软件测试?下面就介绍一些较典型的测试工具: (一)服务器整机系统性能测试工具 一台服务器系统的性能可以按照处理器、内存、存储、网络几部分来划分,而针对不同的应用,可能会对某些部分的性能要求高一些。 Iometer(https://www.360docs.net/doc/144363492.html,):存储子系统读写性能测试 Iometer是Windows系统下对存储子系统的读写性能进行测试的软件。可以显示磁盘系统的最大IO能力、磁盘系统的最大吞吐量、CPU使用率、错误信息等。用户可以通过设置不同的测试的参数,有存取类型(如sequential ,random)、读写块大小(如64K、256K),队列深度等,来模拟实际应用的读写环境进行测试。

性能测试复习题 (1)

选择2*10 1、以下哪个情况最能够代表出现了性能问题(D ) A:网络延迟达到15ms以上 B:DNS没有完成解析 C:WEB服务器的可用内存降到了1GB以下 D:用户体验超过了预期的系统响应时间 2、关于C语法规则中下面那个说法是正确的( A ): A:在C语言中,允许用一个变量来存放指针 B:分号“;”代表一段程序语句的结束 C:/t后面的内容都是注释 D:C语言是不区分大小写的 3、LoadRunner实现合并图的过程中一般不包括(D ) A:叠加 B:平铺 C:关联 D:替换 4、影响WEB前端页面性能一般不包括下面那个( C ) A. 服务器数据返回延迟 B. 网络传输速率 C. 磁盘空间不够 D. 页面渲染 5、选出下列那个不是系统性能监控的指标(C ) A:CPU利用率 B:磁盘空间大小 C:内存空间使用率 D:网络吞吐量 6、下面哪个LoadRunner的组件生成运行Vuser的负载?( D ) A: VuGen B: Controller C: Analysis D: Load Generator 7、在用LoadRunner进行性能测试过程中Run-Time Setting常用的超时设置不包括( B ) A:HTTP-request connect timeout(sec) B:Call to Copy of Action C:HTTP-request receive timeout(sec) D:Step download timeout 8、C语言数据类型不能遵循下面那个规则(C ): A:char指的是字符型数据 B:int指的是基本整型 C:float指的是双精度实数 D:指针是一种特殊的同时又是具有重要作用的数据类型 9、通过疲劳强度测试,最容易发现问题的问题是( B) A.并发用户数 B.内存泄露 C.系统安全性 D.功能错误 10、如下哪些测试场景不属于负载压力测试: (A ) A.恢复测试 B.疲劳强度测试 C.大数据量测试 D.并发性能测试

软件测试技术经典教程笔记(修).docx

第一章基础知识 1.1、软件 1)、软件=程序+文档 2)、分类 功能:系统+应用 架构:单机+C/S+B/S 用户:产品+项目 规模:小型+中型+大型 1.2、Bug 1)、类型一(广义上,软件生命周期,与用户需求不符的问题): 完全没有实现的功能 基本实现功能,但有功能上或性能上的问题 实现了用户不需要的功能 2)、类型二(测试执行阶段的问题) Defect---------Requirements&Design Error-----------Development Bug------------Testing Failure---------Post production 1.3、测试 1)、概念: 测试是为了检验实际的软件是否符合用户需求,所以不能为了发现错误而发现错误。使用人工或自动手段,来运行或测试某个系统的过程。 2)、测试环境:硬件+软件+网络 要求:真实(项目、产品)+干净+无毒+独立(测试与开发) 1.4、测试用例 测试用例=输入+输出+测试环境 便于团队交流,便于重复测试,便于跟踪统计,比纳与用户自测 开发生命周期 需求分析→概要设计→详细设计→编码→维护 测试生命周期 测试计划→测试设计→测试执行→测试评估 需求分析和测试计划完成后,根据《系统需求规格说明书》和软件原型(DEMO)写测试用例 1.5 其他 1)、测试人员素质要求:细心、耐心、信心、服务意识、团队合作意识、沟通能力 2)、如何成为优秀的测试工程师:1、不断学习充电2、阅读原版书籍3、阅读缺陷管理系 统中的缺陷报告4、阅读高手写的测试用例5、学习产品相关 的业务知识

1.6 软件测试的基本规则 1) Zero Bug 与Good Enough Good Enough原则:不充分测试是不负责任,过分的测试是一种资源浪费。 参考:*遗留bug不超过10个,严重的不超过5个 *测试用例执行率为100%,通过率为95% *单元测试,关键模块语句覆盖率达到100%,分支覆盖率达到85% 2) 不要视图穷举法 3) 开发人员不能既是运动员又是裁判员 4) 软件测试要尽早执行 一般情况下,软件80%的缺陷集中在20%的模块中。 7) 缺陷具有免疫性 缺陷具有免疫性,需要根据新版本修改维护测试用例,另外,有一个值得注意的经验:没修复3-4个bug,可能会产生一个新bug。 第二章测试分类 2.1、是否运行程序 Static Testing------------代码规范、界面、文档 Dynamic Testing--------运行程序 2.2、根据阶段分类 Unit Testing(单元测试)----------10% 最小模块,依据源程序和《详细设计》 白盒测试人员||开发人员 编译代码→静态测试→动态测试 桩模块(Stub)、驱动模块(Driver) Integration Testing(集成测试)----------20% 模块间的接口,依据单元测试的模块和《概要设计》 白盒测试人员||开发人员 一般单元和集成同步进行 System Testing(系统测试)----------40% 整个系统(功能、性能、软硬件环境),依据《需求规格说明书》 黑盒测试工程师 Acceptance Testing(验收测试)----------20% 整个系统(功能、性能、软硬件环境),依据《需求规格说明书》和验收标准

WEB服务器性能测试基本指标

WEB服务器性能测试基本指标 1说明 随着公司业务的发展,公司网站、管理后台、app服务器的访问量在不断增加,但通常在软件设计开发的时候很难模拟出大量用户同时访问系统的实际情况,因此,当Web网站遇到访问高峰时,容易发生服务器响应速度变慢甚至服务中断。为了避免这种情况,需要一种能够真实模拟大量用户访问Web应用系统的性能测试工具进行压力测试,来测试静态HTML页面的响应时间,甚至测试动态网页(包括PHP、JSP 等)的响应时间,为服务器的性能优化和调整提供数据依据。 Web性能测试的部分概况一般来说,一个Web请求的处理包括以下步骤: (1)客户发送请求 (2)web server接受到请求,进行处理; (3)web server 向DB获取数据; (4)web server生成用户的object(页面),返回给用户。给客户发送请求开始到最后一个字节的时间称为响应时间(第三步不包括在每次请求处理中)。

2网络拓扑图 3系统配置

4主要指标 4.1事务(Transaction) 在web性能测试中,一个事务表示一个“从用户发送请求->web server接受到请求,进行处理-> we b server向DB获取数据->生成用户的object(页面),返回给用户”的过程,一般的响应时间都是针对事务而言的。 4.2请求响应时间 请求响应时间指的是从客户端发起的一个请求开始,到客户端接收到从服务器端返回的响应结束,这个过程所耗费的时间,在某些工具中,响应通常会称为“TTLB”,即"time to last byte",意思是从发起一个请求开始,到客户端接收到最后一个字节的响应所耗费的时间,响应时间的单位一般为“秒”或者“毫秒”。一个公式可以表示:响应时间=网络响应时间+应用程序响应时间。标准可参考国外的3/5/10原则: (1)在3秒钟之内,页面给予用户响应并有所显示,可认为是“很不错的”; (2)在3~5秒钟内,页面给予用户响应并有所显示,可认为是“好的”; (3)在5~10秒钟内,页面给予用户响应并有所显示,可认为是“勉强接受的”; (4)超过10秒就让人有点不耐烦了,用户很可能不会继续等待下去; 4.3事务响应时间 事务可能由一系列请求组成,事务的响应时间主要是针对用户而言,属于宏观上的概念,是为了向用户说明业务响应时间而提出的.例如:跨行取款事务的响应时间就是由一系列的请求组成的.事务响应时间是直接衡量系统性能的参数. 4.4并发用户数 并发一般分为2种情况。一种是严格意义上的并发,即所有的用户在同一时刻做同一件事情或者操作,这种操作一般指做同一类型的业务。比如在信用卡审批业务中,一定数目的拥护在同一时刻对已经完成的审批业务进行提交;还有一种特例,即所有用户进行完全一样的操作,例如在信用卡审批业务中,所有的用户可以一起申请业务,或者修改同一条记录。 另外一种并发是广义范围的并发。这种并发与前一种并发的区别是,尽管多个用户对系统发出了请求或者进行了操作,但是这些请求或者操作可以是相同的,也可以是不同的。对整个系统而言,仍然是有很多用户同时对系统进行操作,因此也属于并发的范畴。 可以看出,后一种并发是包含前一种并发的。而且后一种并发更接近用户的实际使用情况,因此对于大多数的系统,只有数量很少的用户进行“严格意义上的并发”。对于WEB性能测试而言,这2种并发情况一般都需要进行测试,通常做法是先进行严格意义上的并发测试。严格意义上的用户并发一般发生在使用比较频繁的模块中,尽管发生的概率不是很大,但是一旦发生性能问题,后果很可能是致命的。严格意义

性能测试基础知识

性能测试基础知识 一、性能测试概述 1、性能测试定义 所谓性能,有狭义和广义两种含义。狭义的性能指运行速度的快慢。广义的性能涉及很多内容,如可靠性、可用性、功耗、环境适应性、兼容性、安全性、保密性、可扩充性、可移植性、利用率、性能价格比、速度等。 性能测试是通过自动化的测试程序或工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。 2、性能测试目的 真实环境下检测系统性能,评估系统性能以及服务等级的满足情况 预见系统负载压力承受力,在应用实际部署之前,评估系统性能 分析系统瓶颈,优化系统 二、主要性能指标 响应时间、吞吐量、并发、点击率、资源利用率 1、响应时间 响应时间指的是客户端发出请求到得到响应的整个过程所经历的时间。 响应时间=网络传输时间*2+服务器处理时间+客户端显示时间。 2、吞吐量 单位时间内流经被测系统的数据流量,一般单位为b/s,即每秒钟流经的字节数。吞吐量是指单位时间内系统处理的客户请求的数量,直接体现软件系统的性能承载能力。 TPS的概念,每秒事务数。确实TPS会随着负载的增加而逐渐增加,但不会无限制的一直增加。比如,到了300用户后就会出现连接服务失败,那可能说明系统进入了繁忙期,从而产生了失败的事务,从而使得每秒的事务数不再增加,甚至会减少。 TPS就像是一个抛物线,可分为3部分,轻负载区、重负载区、负载失效区。 一开始上升的部分就是轻负载区,最顶端的部分就是TPS的峰值(重负载区),然后随着负载的继续增加,TPS会慢慢下降,从而进入我们所谓的负载失效区。 3、并发用户数 指在某一给定时间内,某个特定点上进行会话操作的用户数。是陆陆续续交替执行的。 随着用户数的增加,HIT PER SECOND开始逐渐减少,说明系统已经开始有失败的VUSER 和事务出现。 4、资源利用率 CPU利用率、内存利用率、磁盘利用率、网络带宽利用率

服务器性能测试指标介绍

服务器性能测试指标介绍 当前业界常见的服务器性能指标有: TPC-C TPC-E TPC-H SPECjbb2005 SPECjEnterprise2010 SPECint2006 及SPECint_rate_2006 SPECfp2006 及SPECfp_rate_2006 SAP SD 2-Tier LINPACK RPE2 一、TPC (Transaction Processing Performance Council) 即联机交易处理性能协会, 成立于1988年的非盈利组织,各主要软硬件供应商均参与,成立目标: 为业界提供可信的数据库及交易处理基准测试结果,当前发布主要基准测试为: TPC-C : 数据库在线查询(OLTP)交易性能 TPC-E : 数据库在线查询(OLTP)交易性能 TPC-H : 商业智能/ 数据仓库/ 在线分析(OLAP)交易性能 1.TPC-C测试内容:数据库事务处理测试, 模拟一个批发商的订单管理系统。实际衡量服务器及数据库软件处理在线查询交易处理(OLTP)的性能表现. 正规TPC-C 测试结果发

布必须提供tpmC值, 即每分钟完成多少笔TPC-C 数据库交易(TPC-C Transaction Per Minute), 同时要提供性价比$/tpmC。如果把TPC-C 测试结果写成为tpm, TPM, TPMC, TPCC 均不属正规。 2.TPC-E测试内容:数据库事务处理测试,模拟一个证券交易系统。与TPC-C一样,实际衡量服务器及数据库软件处理在线查询交易处理(OLTP)的性能表现。正规TPC-E测试结果必须提供tpsE值,即每秒钟完成多少笔TPC-E数据库交易(transaction per second),同时提供$/tpsE。测试结果写成其他形式均不属正规。 对比:TPC-E测试较TPC-C测试,在测试模型搭建上增加了应用服务器层,同时增加了数据库结构的复杂性,测试成本相对降低。截止目前,TPC-E的测试结果仅公布有50种左右,且测试环境均为PC服务器和windows操作系统,并无power服务器的测试结果。除此之外,TPC官方组织并未声明TPC-E取代TPC-C,所以,说TPC-E取代TPC-C并没有根据。 附TPC-C与TPC-E数据库结构对比 3.TPC-H测试内容:对大型数据仓库进行决策支持(decision support)的基准测试。TPC-H包含一组复杂的业务查询及修改操作,属于商业智能/数据仓库/在线分析(OLAP)

软件测试技术基础课后习题答案[1]

第1章软件测试概述 1.简述软件测试的意义。 解:随着计算机技术的迅速发展和广泛深入的应用,软件质量问题已成为开发和使用软件人员关注的焦点。而由于软件本身的特性,软件中的错误是不开避免的。不断改进的开发技术和工具只能减少错误的发生,但是却不可能完全避免错误。因此为了保证软件质量,必须对软件进行测试。软件测试是软件开发中必不可少的环节,是最有效的排除和防治软件缺陷的手段,是保证软件质量、提高软件可靠性的最重要手段。 2.什么是软件缺陷?它的表现形式有哪些? 解:从产品内部看,软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题;从外部看,软件缺陷是系统所需实现的某种功能的失效或违背。 它的表现形式主要有以下几种:(1)软件未达到产品说明书中已经标明的功能;(2)软件出现了产品说明书中指明不会出现的错误;(3)软件未达到产品说明书中虽未指出但应当达到的目标;(4)软件功能超出了产品说明书中指出的范围;(5)软件测试人员认为软件难以理解、不易使用,或者最终用户认为该软件使用效果不良。 3.简单分析软件缺陷产生的原因,其中那个阶段引入的缺陷最多,修复成本又最低? 解:软件缺陷产生的主要原因有:需求规格说明错误;设计错误;程序代码有误;其他。其中在需求分析阶段引入的缺陷最多,修复的成本又最低。 4.当用户登录某网站购物完毕并退出后,忽然想查查购物时付账的总金额,于是按了浏览器左上角的“退回”按钮, 就又回到了退出前的网页,你认为该购物软件有缺陷吗?如果有,属于哪一类? 解:有缺陷。其所属类别与软件产品说明书的要求有关。 5.什么是软件测试?简述其目的与原则。 解:软件测试是为了尽快尽早地发现在软件产品中所存在的各种软件缺陷而展开的贯穿整个软件开发生命周期,对软件产品(包括阶段性产品)进行验证和确认的活动过程。 测试目的:(1)证明:获取系统在可接受风险范围内可用的信心;尝试在非正常情况和条件下的功能和特性;保证一个工作产品是完整的并且可用或可被集成。(2)检测:发现缺陷、错误和系统不足;定义系统的能力和局限性;提供组件、工作产品和系统的质量信息。(3)预防:澄清系统的规格和性能;提供预防或减少可能制造错误的信息;在过程中尽早检测错误;确认问题和风险,并且提前确认解决这些问题和风险的途径。 测试过程中应注意和遵循的原则:(1)测试不是为了证明程序的正确性,而是为了证明程序不能工作。(2)测试应当有重点。(3)事先定义好产品的质量标准。(4)软件项目一启动,软件测试也就开始,而不是等到程序写完才开始进行测试。(5)穷举测试是不可能的。(6)第三方进行测试会更客观,更有效。(7)软件测试计划是做好软件测试工作的前提。(8)测试用例是设计出来的,不是写出来的。(9)对发现错误较多的程序段,应进行更深入的测试。(10)重视文档,妥善保存一切测试过程文档。 6.件测试阶段是如何划分的? 解:软件测试的阶段划分为:规格说明书审查;系统和程序设计审查;单元测试;集成测试;确认测试;系统测试;验

基于LoadRunner的性能测试培训课程

基于LoadRunner的性能测试培训课程 适用于:性能工程师,操作人员,QA工程师 需要对应用进行负载测试的LoadRunner 新用户 概述: LoadRunner是自动化负载测试工具,允许用户在应用实施前、实施中或实施后对其进行负载测试。 本课程的设计目标是帮助用户打下良好的负载测试知识基础。 LoadRunner的组件——LR Controller和LR Virtual User Generator用于计划和创建高效的负载测试。您将会使用LRController来创建和运行负载测试场景。LR Analysis组件用于对负载测试结果进行分析,您将会学习到如何分析LR Analysis 图表,满足负载测试目标。所有的课题都会有实验课程,帮助您掌握使用LoadRunner进行对系统进行负载测试的所需知识。 VuGen 是用来记录和运行用户在被测应用上面的操作的脚本工具。在脚本生成器的讲解和演练中,着重在Web和winsock、Database、Tuxedo、Java等环境中如何计划、创建和增强虚拟用户(Vuser)的脚本。 课程目标: 在课程结束后,您将能够: ?负载测试的价值 ?计划高效的负载测试 ?了解当前软件企业中的性能测试实践 ?建立负载测试目标 ?运行负载测试场景 ?执行场景时创建不同级别的负载 ?分析和解释负载测试结果 ? 使用VuGen录制脚本 ?了解http、winsock、Database、Tuxedo等协议的脚本处理方式 ? 度量特定业务流程事务时间 ? 增加内容检查 ? 使用参数化的脚本处理用户输入数据 ? 如何通过增加VuGen函数定制脚本 ? 关联脚本处理服务器动态返回的数据 ?其他的一些高级技巧 ? LoadRunner调用Diagnostics进行测试 预备知识: 具有微软Windows 2000 或NT操作系统的使用经验 具有较深入的Web 应用或C/S 应用环境方面的知识 具有一定的C语言编程知识更佳

浅谈耳机生产工艺和性能测试(耳机基础知识五)

浅谈耳机生产工艺和性能测试(耳机基础知识五) 耳机基础知识五 上节聊了耳机的核心部件音圈和振膜对音质的影响。喜欢听音乐的朋友你们知道耳 机是怎样生产出来的吗?耳机生产过程有哪个重要的项目需要管控呢?为了保证高品质音 质性能测试有哪个项目呢?我都经历过德系、日系、欧美等国际顶尖品牌耳机生产线管理,基本上按以下品质基准和测试基准来生产的。当然不同的耳机生产工艺或测试是不同的, 不同客户测试标准和品质水准也是不一样的,不同类型的耳机工艺上会有增加或删减,但 是性能测试基本的还是不变的。今天简单聊聊的这话题,让大家对耳机工艺和测试有一个 了解,当然国际品牌为了保证耳机品质,测试设备比较齐全,国一些小加工厂或山寨厂只 有一台音频扫频仪,其它测试设备都免了,大家俗称的做出来的耳机只要有声音就行了。 由于大、中耳机工艺比较复杂,今天举例一款简单带MIC入耳式耳机(如sennheiser mm30i),但以下工艺可能有少许偏差。 一、耳机生产(组装)工艺流程: 1.半成品加工:(1)电线半成品加工(电线插头生产、MIC控制盒组装加工)(2)SPK前壳加工(贴调纸、点胶水)(3)后壳加工(穿SR/贴调音纸/加工装饰片等)----(篇幅有限加 工部分详细流程略) 2.耳机组装工艺流程:1.检查电线+投入流水线 >> 2. 电线穿耳机后壳+打结(R、L)>> 3.焊接喇叭(R、L)>> 4.检查焊点品质(R、L)>> 4.耳机前壳+后壳组装(点胶水或超声波)>> 5.装耳套 >> 6.耳机/MIC测频响曲线 >> 7.耳机听音测试 >> 8.MIC听音测试 >> 9.控制盒按键功能测试 >> 10.检查耳机外观 >> 11.包装 (注:不同的耳机组装和包装工艺略有些不同) 二、耳机生产所需性能测试所用仪器及测试项目: 电声测试仪很多种:比较知名如:丹麦B&K(全球最牛电声测试仪,也是公认的标准,一般 用于无响室,价格昂贵不利于用于生产线上测试)、德国DAAS、美国soundcheck/美国LMSSA、意大利CLIO、、国品牌较多,如吉高(原浙大电声)、佳宏等等。 扫频仪:、国品牌较多,如吉高、中策等。 极性机:、国品牌比较多,如吉高、中策等。

最全软件测试基础教程(2011版)

软件测试基础教程 测试的基本概念 测试是软件生存周期中十分重要的一个过程,是产品发布、提交给最终用户前的稳定化阶段。 1、测试的分类: 从测试方法的角度可以分为手工测试和自动化测试。 手工测试:不使用任何测试工具,根据事先设计好的测试用例来运行系统,测试各功能模块。 自动化测试:利用测试工具,通过编写测试脚本和输入测试数据,自动运行测试程序。目前最常用的自动化测试工具是基于GUI的自动化测试工具,基本原理都是录制、回放技术。 从整体的角度可以分为单元测试、集成测试、系统测试、确认测试。 单元测试:是针对软件设计的最小单位—程序模块,进行正确性检验的测试工作。一般包括逻辑检查、结构检查、接口检查、出错处理、代码注释、输入校验、边界值检查。 单元测试的依据是系统的详细设计;一般由项目组开发人员自己完成。 集成测试:在单元测试的基础上,将所有模块按照设计要求组装进行测试。一般包括逻辑关系检查、数据关系检查、业务关系检查、模块间接口检查、外部接口检查。 系统测试:系统测试是在所有单元、集成测试后,对系统的功能及性能的总体测试。 确认测试:模拟用户运行的业务环境,运用黑盒测试方法,验证软件系统是否满足用户需求或软件需求说明书中指明的软件特性(功能、非功能)上的。 从测试原理上分为:白盒测试、黑盒测试和灰盒测试。 白盒测试:是通过程序的源代码进行测试而不使用用户界面。这种类型的测试需要从代码句法发现内部代码在算法,溢出,路径,条件等等中的缺点或者错误,进而加以修正。 黑盒测试:是通过使用整个软件或某种软件功能来严格地测试, 而并没有通过检查程序的源代码或者很清楚地了解该软件的源代码程序具体是怎样设计的。测试人员通过输入他们的数据然后看输出的结果从而了解软件怎样工作。在测试时,把程序看作一个不能打开的黑盆子, 在完全不考虑程序内部结构和内部

服务器性能测试相关的常用工具概要

服务器性能测试相关的常用工具 (一服务器整机系统性能测试工具 一台服务器系统的性能可以按照处理器、内存、存储、网络几部分来划分,而针对不同的应用,可能会对某些部分的性能要求高一些。 Iometer(https://www.360docs.net/doc/144363492.html,:存储子系统读写性能测试 Iometer是Windows系统下对存储子系统的读写性能进行测试的软件。可以显示磁盘系统的最大IO能力、磁盘系统的最大吞吐量、CPU使用率、错误信息等。用户可以通过设置不同的测试的参数,有存取类型(如sequential,random、读写块大小(如64K、256K,队列深度等,来模拟实际应用的读写环境进行测试。Iometer操作简单,可以录制测试脚本,可以准确有效的反映存储系统的读写性能,为各大服务器和存储厂商所广泛采用。 SisoftSandra(https://www.360docs.net/doc/144363492.html,:WINDOWS下基准评测 SiSoft发行的Sandra系列测试软件是Windows系统下的基准评测软件。此软件有超过三十种以上的测试项目,能够查看系统所有配件的信息,而且能够对部分配件(如CPU、内存、硬盘等进行打分(benchmark,并且可以与其它型号硬件的得分进行对比。另外,该软件还有系统稳定性综合测试、性能调整向导等附加功能。SisoftSandra软件在最近发布的Intelbensley平台上测试的内存带宽性能并不理想,不知道采用该软件测试的FBD内存性能是否还有参考价值,或许软件应该针对FBD 内存带宽的测试项目做一个升级。 Iozone(https://www.360docs.net/doc/144363492.html,:linux下I/O性能测试 现在有很多的服务器系统都是采用linux操作系统,在linux平台下测试I/O性能可以采用iozone。iozone是一个文件系统的benchmark工具,可以测试不同的操作系统中文件系统的读写性能。可以测试Read,write,re-read,re-write, read backwards, read strided, fread, fwrite,random read,pread,mmap, aio_read,aio_write等等不同的模式

软件测试技术基础教程(第2版)-习题答案

软件测试技术基础教程(第2版)-习题答案

第一章软件测试理论 一、选择题 1、C 2、A 3、D 4、B 5、D 6、 D 7、B 8、B 二、简答题 1. 参考答案: 软件测试是伴随着软件的产生而产生的。在软件行业发展初期,没有系统意义上的软件测试,更多的是一种类似调试的测试,测试用例的设计和选取也都是根据测试人员的经验随机进行的,大多数测试的目的是为了证明系统可以正常运行。 到了20世纪70年代以后,很多测试理论和测试方法应运而生,逐渐形成了一套完整的体系。在产业界,从20世纪70年代后期到20世纪80年代中期,很多软件企业成立了QA或者SQA部门。后来QA的职能转变为流程监控(包括监控测试流程),而测试(Testing)则从QA中分离出来成为独立的组织职能。 到了20世纪80年代初期,一些软件测试的基础理论和实用技术开始形成,软件测试作为软件

质量保证(SQA)的主要职能,包含软件质量评价的内容。软件测试已有了行业标准(IEEE/ANSI )。 在我国,软件测试目前还没有形成一个真正的产业,尚处于起步阶段。 但是,在国内,现在在软件测试行业中各种软件测试的方法、技术和标准都还在探索阶段。 总之,国内软件测试行业与一些发达国家相比还存在一定的差距。 2. 参考答案: 软件缺陷造成的修复费用随着时间的推移呈指数级地增长,如下图所示。 3. 参考答案: 软件测试的复杂性体现在:

?不可能对程序实现完全测试。 ?杀虫剂现象,即为了克服被测试软件的免疫力,软件测试员必须不断编写新的测试程 序,对程序的各个部分进行不断测试,以避 免被测试软件对单一的测试程序具有免疫 力而使软件缺陷不被发现。 ?软件测试的代价不容易掌握,因为随着测试量的增加,测试成本将呈几何数级上升,而 软件缺陷数量降低到某一数值之后将没有 明显的变化,寻求最优测试点,掌握好测试 工作量是至关重要的。 ?在实际操作过程中,测试人员要进行正确的判断,合理的取舍,根据风险分析来决定哪 些故障需要修复,哪些故障可以不修复,即 并不是所有的软件缺陷都需要被修复。 4. 参考答案: 软件测试是软件生命期中费用消耗最大的环节。测试费用除了测试的直接消耗外,还包括其他的相关费用。影响测试费用的主要因素有:(1)软件的功能,软件产品需要达到的标

服务器能力测算

服务器能力测算 一、术语和定义 1.1、信息系统 由计算机、通信设备、处理设备、控制设备及其相关的配套设施构成,按照一定的应用目的和规则,对信息进行采集、加工、存储、传输、检索等处理的人机系统。 1.2、软硬件平台 指信息系统运行的环境,主要包括硬件(服务器、存储)和软件(操作系统、数据库和中间件)部分。 1.3、非安全区 即Internet,此区域允许外网用户随意访问。 1.4、安全区 内网,此区域通常不对外提供服务。 1.5、DMZ 区 又称非军事区,介于非安全区与安全区之间,此区域按需对外网用户提供部分服务。

1.6、FC SAN 指采用光纤通道的存储区域网络,是一种将存储设备、连接设备和服务器集成在一个高速网络中的技术,SAN作为存储网络,与LAN网络隔离,主要承担数据存储任务。 1.7、FC Switch 指光纤通道交换机,是一种高速的网络传输中继设备,以光纤作为传输介质, 是组成FC SAN光纤存储网络的光纤交换机。 1.8、磁盘阵列 由多个容量较小、速度较慢的磁盘组合成一个磁盘组,以提升整体性能和存储空间。 1.9、虚拟机 指使用系统虚拟化技术,运行在一个隔离环境中、具有完整硬件功能的逻辑计算机系统。 1.10、负载均衡 分为硬件和软件负载均衡,软件负载均衡指通过将负载均衡软件安装在一台或多台服务器相应的操作系统上来实现负载均衡,硬件负载均衡是直接将负载均衡设备部署在服务器和外部网络之间,专门完成负载均衡任务。 1.11、关键应用系统

指对业务开展起核心的支撑作用的,对可靠性(Reliability)、可用性(Availability)和可服务性(Serviceability)等具有非常高要求的应用系统,如资产管理系统、营销管理系统、财务管理系统、人力资源系统、协同办公系统和综合管理系统。 1.12s非关键应用系统 指除关键应用系统外的应用系统。 1.13、TPC-C 测试 指模拟一个批发商的订单管理系统进行数据库事务处理测试,主要衡量服务器及数据库软件处理在线查询交易处理(OLTP)的性能表现,正规TPC-C测试结果发布必须提供tpmC值,即每分钟完成多少笔TPC-C (TPC-C Transaction Per Minute)数据库交易。 1.14、业务交易 在TPC-C估算法中,业务交易指的是用户的业务请求,用户每次查询、修改和删除操作均各算一次业务交易。 二、软硬件平台架构 1、网络从安全角度上分,一般分为DMZ区和安全区(内网),根据应用的用途、架构、功能,选择适合的网络环境。

服务器测试报告.docx

服务器测试报告 概述 此次测试针对新的服务器进行性能测试,主要有5个方面的测试:服务器基本性能测 试, InfoDB 性能测试, BinaryDB性能测试, Apache 性能测试, LINUX 下 MYSQL性能测试,此文档仅针对机器硬件基本性能和BinaryDB 的性能测试进行描述 测试结果概述: 基本硬件性能概要:( 此部分数据使用互联网下载的相应测试工具测得) CPU 浮点运算方面:服务器约是232 服务器性能的238 % CPU 多核心间带宽:服务器约是232 服务器性能的10 倍 高速缓存和内存间的带宽:服务器约是232 服务器性能的 300% 内存带宽方面:服务器约是232服务器性能的 87 % 内存随机访问性能:服务器的内存带宽约是232 服务器性能的86% 内部网络性能:服务器和232 服务器几乎没有差别(同处一个交换机,性能不可能有 差距) 硬盘读取性能:服务器约是232服务器性能的 6倍。 硬盘写入性能: 打开写入缓存前:服务器约是232服务器性能的10%。 (16KB数据包 ) 打开写入缓存后:服务器约是232服务器性能的290%。 (16KB数据包 ) BinaryDB性能概要: 写入效率方面(写入数据包为16KB) 文件模式服务器约是232服务器性能的23 % 磁盘模式服务器约是232服务器性能的61 % 打开磁盘缓存后文件模式提高了 1 倍的速度,但效率也仅达到232 的 50% 磁盘模式并没有因为打开磁盘缓存而加快速度,仅达到了232 的 67% 读取效率方面,服务器的速度稍好,但是和硬盘读取效率的比值还是有很大差距。 文件模式服务器约是232服务器性能的125 % 磁盘模式服务器约是232服务器性能的124 % 性能测试报告BinaryDb详细性能测试报告请看这里服务器. 目录 第一部分:服务器基本性能数据 (3) 一.服务器基本硬件资料: (3) 二. CPU 测试 (4) 三.内存测试 (4)

软件测试技术基础教程

软件测试技术基础教程 软件测试技术基础教程。近来,软件测试行业发展迅速,企业越来越重视测试了。越来越多的人加入了测试大军中,很多人也想通过自学来学习软件测试技术加入这个行业,更多的人开始关注软件测试案例教程,那么软件测试案例教程哪里好呢?软件测试案例教程内容有什么?软件测试案例教程学什么?下面我为大家简要介绍一下软件测试案例教程——黑盒测试和白盒测试 黑盒测试:已知产品的功能设计规格,可以进行测试证明每个实现了的功能是否符合要求。 白盒测试:已知产品的内部工作过程,可以通过测试证明每种内部操作是否符合设计规格要求,所有内部成分是否以经过检查。 软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子,测试人员完全不考虑程序内部的逻辑结构和内部特性,只依据程序的需求规格说明书,检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误: 1、是否有不正确或遗漏的功能? 2、在接口上,输入是否能正确的接受?能否输出正确的结果? 3、是否有数据结构错误或外部信息(例如数据文件)访问错误?

4、性能上是否能够满足要求? 5、是否有初始化或终止性错误? 软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子,它允许测试人员利用程序内部的逻辑结构及有关信息,设计或选择测试用例,对程序所有逻辑路径进行测试。通过在不同点检查程序状态,确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查: 1、对程序模块的所有独立的执行路径至少测试一遍。 2、对所有的逻辑判定,取“真”与取“假”的两种情况都能至少测一遍。 3、在循环的边界和运行的界限内执行循环体。 4、测试内部数据结构的有效性,等等。

web项目测试实战性能测试结果分析免费

5.4.2测试结果分析 LoadRunner性能测试结果分析是个复杂的过程,通常可以从结果摘要、并发数、平均事务响应时间、每秒点击数、业务成功率、系统资源、网页细分图、Web服务器资源、数据库服务器资源等几个方面分析,如图5- 1所示。性能测试结果分析的一个重要的原则是以性能测试的需求指标为导向。我们回顾一下本次性能测试的目的,正如所列的指标,本次测试的要求是验证在30分钟内完成2000次用户登录系统,然后进行考勤业务,最后退出,在业务操作过程中页面的响应时间不超过3秒,并且服务器的CPU使用率、内存使用率分别不超过75%、70%,那么按照所示的流程,我们开始分析,看看本次测试是否达到了预期的性能指标,其中又有哪些性能隐患,该如何解决。 图5- 1性能测试结果分析流程图 结果摘要 LoadRunner进行场景测试结果收集后,首先显示的该结果的一个摘要信息,如图5- 2所示。概要中列出了场景执行情况、“Statistics Summary(统计信息摘要)”、“Transaction Summary(事务摘要)”以及“HTTP Responses Summary(HTTP响应摘要)”等。以简要的信息列出本次测试结果。 图5- 2性能测试结果摘要图

场景执行情况 该部分给出了本次测试场景的名称、结果存放路径及场景的持续时间,如图5- 3所示。从该图我们知道,本次测试从15:58:40开始,到16:29:42结束,共历时31分2秒。与我们场景执行计划中设计的时间基本吻合。 图5- 3场景执行情况描述图 Statistics Summary(统计信息摘要) 该部分给出了场景执行结束后并发数、总吞吐量、平均每秒吞吐量、总请求数、平均每秒请求数的统计值,如图5- 4所示。从该图我们得知,本次测试运行的最大并发数为7,总吞吐量为842,037,409字节,平均每秒的吞吐量为451,979字节,总的请求数为211,974,平均每秒的请求为113.781,对于吞吐量,单位时间内吞吐量越大,说明服务器的处理能越好,而请求数仅表示客户端向服务器发出的请求数,与吞吐量一般是成正比关系。 图5- 4统计信息摘要图 Transaction Summary(事务摘要) 该部分给出了场景执行结束后相关Action的平均响应时间、通过率等情况,如图5- 5所示。从该图我们得到每个Action的平均响应时间与业务成功率。 图5- 5事务摘要图

相关文档
最新文档