LTE基站接收性能测试分析
中国联通研究院王湘宁
摘要
本文逐一分析了PUSCH信道的HARQ技术、PUSCH信道连接状态下的上行同步技术、PUCCH信道的技术特征以及PRACH信道的技术特征，并在此分析的基础上，给出了相应的测试方案和指标要求。
前言
在LTE基站系统中，PUSCH信道、PUCCH信道和PRACH信道是三个十分重要的物理上行信道，其信道性能的指标直接决定了基站接收性能的优劣。本文将以3GPP TS 36.141规范Chapter 8的测试过程为主线，针对涉及三个LTE上行物理信道的主要特征和关键技术进行分析，并说明如何测试这三个信道的性能。无特殊说明，本文以描述FDD-LTE基站特性为主。
1.PUSCH信道关键技术分析与性能测试
上行物理共享信道（ Physical Uplink Shared Channel,PUSCH）用于上行数据的调度传输，是LTE物理层主要的上行数据承载信道，可以承载来自上层的不同的传输内容，包括控制信息、用户业务信息和广播业务信息。其中涉及PUSCH信道的关键技术主要有HARQ技术和上行时间同步技术。
1.1 HARQ技术
为了确保数据的可靠传输，通信系统中一直使用两种差错控制方法：前向纠错（FEC）和自动重复请求（ARQ）技术。FEC技术效率较高，但对信道的适应性比较差，无论信道优劣，它的效率是恒定值，它只适用于没有反向信道的系统中。ARQ技术实现简单，对信道的自适应性强，但其效率是信道误码率的函数。在无线传输信道比较稳定的情况下，由于没有额外的前向纠错比特被加在基础传输数据之上，ARQ的工作效率比较高。当信道条件变差时，由于连续的重传，导致频谱资源的利用有效性变差。
HARQ将两者进行组合，可以实现比FEC高得多的可靠性和ARQ的传输效率。LTE采用HARQ 技术来降低系统的误码率以确保传输质量，有效地克服了无线信道的时变和多径衰落对LTE 信号传输的影响。HARQ不能应用到所有的业务类型。例如，广播业务需要将相同的信息发
送到多个用户，所以通常不会使用HARQ机制。HARQ机制仅支持DL-SCH和UL-SCH。
HARQ系统传输的信息包括三个部分，即有用数据、检错编码和FEC比特。同时，HARQ 系统又分为I 型HARQ和II型HARQ。
I 型HARQ在信道传输质量好的情况下，全部的传输错误将被纠正，接收机可以正确地解码。如果信道质量变差，全部的传输错误不能得到纠正的话，数据包将被丢弃，接收机要求发送端重传。
II型HARQ是比较复杂的解决方案，它每次传输一个由有用数据、检错编码和FEC比特组合而成的集合体，而这个集合体将会随着重传次数的不同而发生变化。也就是说，如果第一次传输的有用数据没有被正确地接收，第二次传输的集合体将包括有用数据、检错编码和FEC比特重新排列，接收端将把首次接收和二次接收的信息进行组合来进行纠错，称之为增量冗余（IR）。如果能被无差错地接收，发送端将准备传输下一个数据块。
在信道质量较好的情况下，I型HARQ额外增加的FEC比特明显地降低了用户的传输速率和信道利用的有效性，将使整个系统效率有一定的降低。II型HARQ使用1/3 turbo 编码，首次传输有用信息和检错编码将占此次传输的绝大部分比例，FEC比特占据的比例相对较小。而在后续的传输中，有用信息和检错编码的比例将逐渐减少，FEC比特占据的比例上升。
具体说来，传输层把从物理层接收到的数据块进行CRC计算,块分割,信道编码后开始进行速率匹配，为了进行速率匹配,首先把编码后的数据流分成三个分量,分别交织后,然后把三个分量首尾连接,形成一个环形的缓存区，然后根据采用的不同RV 版本和比特数目选取本次发送的比特序列。参见图一[5]。
图一速率匹配与交织过程
这里所说的RV是指选择发送比特序列的不同起始位置，来自信道编码后的系统比特（包括有用信息和检错比特）被交织后，放在一个环形的缓存中；校验冗余比特被交织后，也跟随系统比特放在同一个环形的缓存中。
环形缓存中经HARQ被传输的比特取决于RV（冗余版本），RVn目前有四种版本，分别是RV0/RV1/RV2/RV3,其传输的起始位置近似于整个环形缓存的n/4，如果信道质量比较差，在每次HARQ重传时，RV可能使用环形缓存中的全部比特；如果信道质量比较好，在每次HARQ 重传时，RV可能仅使用环形缓存中的部分比特。参见图二。
图二 HARQ冗余版本
LTE系统使用II型HARQ，由于码率在随后的传输中反复降低，II型HARQ在信道质量较好的情况下，其信道能力与ARQ能力相当，排除了不必要的的带宽损失。LTE II型HARQ 使用四种RV格式来反复传递数据直至数据包被正确接收或达到最大重传次数，如果达到最大重传次数还不能被正确接收，HARQ将放弃该数据包并产生误码率。
LTE HARQ采用多个进程的“停止-等待”（stop-and-wait）实现方式，即对于某一个HARQ 进程，在等到ACK/NACK（肯定确认/否定确认）反馈之前，此进程暂时中止，待接收到ACK/NACK 后，再根据是ACK还是NACK决定发送新的数据还是旧的数据的重传。一个上行HARQ的环回处理时间大约为8ms，在一个HARQ进程发出后，剩余的时间不能被浪费，必须发起其他HARQ进程，为此LTE 上行HARQ的并发进程为8个[5]。
对于上行传输，HARQ传输为同步传输，即每个HARQ进程的时域位置被限制在预定好的位置，这样就可以通过一个HARQ进程所在的子帧编号导出该HARQ进程的编号。因此，同步HARQ不需要发送额外的显性信令指示HARQ进程号，每隔8个子帧的时间，UE将重复相同的HARQ进程[5]。
1.2 HARQ技术测试方案
HARQ技术测试要求在静态传播环境（即白噪声）基础之上，叠加不同的信道模型，以模拟真实的环境，来检验LTE系统在实际的复杂信道环境中，正确解调UE发送数据的能力，来验证HARQ技术的能力。
信道模型主要有多径衰落传输和高速运动火车传输两种，其中多径衰落传输模型使用不同环境参数文件（徒步环境、车辆环境和城市环境）和多普勒频移（5Hz、7 Hz、300Hz）的组合；高速运动火车传输模型主要与多普勒频移有关(开放环境最大多普勒频移1340 Hz、隧道环境最大多普勒频移1150 Hz)，与衰落传输无关。
上行参考信号模拟不同带宽和不同调制方式（QPSK、16QAM、64QAM）。HARQ的取值按照表一要求，与实际LTE系统的HARQ的设计要求一致。
表一HARQ的取值
在上述信道模拟环境的不同组合下，按图三进行测试连接，对信号源发出的数据进行吞吐量统计，来检验LTE系统是否可以满足规定的指标要求[1]。
1.3 UE上行同步技术
信号在空间传输是有延迟的，如果UE数据传输期间远离基站，则从基站发出的信号将“越来越迟”的到达UE，与此同时，UE的信号也会“越来越迟”地到达基站，延迟过长会导致基站收到的UE在本时隙上的信号与基站收其它UE信号的时隙相互重叠，引起码间干扰。
因此，在LTE中，不同UE的上行信号到达eNodeB时要时间对齐，以保证UE之间上行信号的正交性，从而有助于消除小区内的干扰，这种上行传输的时间对齐是通过TA（Timing Advance）命令来实现同步的。
相关的同步过程包括两种，一是初始随机接入的传输时间调整，二是连接状态下的上行同步保持。
对于UE在初始随机接入的传输时间调整，UE首先发送上行的PRACH前导序列，eNodeB 通过测量UE的前导序列，在随后的反馈消息中返回给UE 11位的初始T A值（在0到1282之间取值）。TA调整颗粒度为16Ts，即16/(15000?2048)秒。UE根据反馈消息中的初始TA 值，做相应的上行时间调整N TA = T A?16 Ts。T A的时间调整范围为0到0.67ms。
UE在获得初始同步以后，随着时间的推移，由于信道情况的改变或者UE（以及eNodeB）的时钟漂移，UE可能重新变为失步状态。为此eNodeB会周期性的为UE发送TA命令，指导UE进行上行的同步，并且eNodeB为每个UE配置了一个Time Alignment Timer，规定了TA 的有效期，为此eNodeB需要在UE的能力和系统的开销之间进行折中。UE在每次接收到eNodeB的TA命令后，都将此定时器重置为零。在Time Alignment Timer超时以后，如果UE未能收到任何的TA命令，那么UE认为上行已经失步，此时UE不能再进行任何的上行数据传输，而必须通过随机接入的过程来对上行的TA进行重新初始化。
对于处于连接状态下的上行同步保持，UE接入到LTE系统以后，获得初始的上行同步，开始可以发送上行信号。eNodeB 通过对UE上行信号（包括SRS， CQI， HARQ以及PUSCH 中的数据等）的时间进行测量，来决定TA的时间并在适当的时机发送相应的TA命令给UE。与初始接入相应中的TA不同，此时的TA为6个Bit，在0到63之间取值，代表现时的TA 与上一个TA之间的偏移值，即：N TA,new = N TA,old + (T A-31)?16 Ts。
对于收到调整命令后，UE将延时6ms,即对于在子帧N收到的TA命令，UE会在子帧N＋6应用相应的时间偏移[4]。
1.4 UE上行同步技术测试方案
UE上行同步技术测试主要考察移动中的UE与静止的UE各自发送的信号同步到达基站的能力，其中静止UE发送的信号为时间参考基准。如果移动UE发送的信号在一定误差范围内正确地被基站接收，则说明基站给移动的UE发送的TA命令起到了效果，克服了因信号到达不同步而产生的误码现象。
测试方案要求在静态传播环境（即白噪声）基础之上，叠加不同的信道模型，以模拟真实的环境，来检验LTE系统在实际的复杂信道环境中，正确解调移动UE发送数据的能力。
信道模型以多径衰落传输为主，其中多径衰落传输模型使用多普勒频移200Hz下的车辆环境参数文件；上行参考信号模拟不同带宽和不同调制方式（QPSK、16QAM）。HARQ的取值按照表一要求，与实际LTE系统的HARQ的设计要求一致。
在上述信道模拟环境的不同组合下，按图四[6]进行测试连接，对模拟移动UE信号源发出的数据进行吞吐量统计，来检验LTE系统是否可以满足规定的指标要求[1]。
2.PUCCH信道技术特征与性能测试
上行控制信息应当包含已经取得上行同步的UE发送的控制信息和未取得上行同步的UE发送的控制信息。未取得上行同步的UE控制信息将在PRACH（物理随机接入信道）中传输。取得上行同步的控制信息将在PUCCH信道和PUSCH信道中传输。
2.1 上行控制信息类别
LTE系统中上行控制信息主要由CQI和ACK/NACK组成。由于LTE系统中资源调度和链路自适应完全由基站控制，基站将根据上下行信道的频率选择性的信道质量指示（CQI）信息为UE选择合适的资源进行传输。上行信道CQI测量值可以由基站直接获取并使用，下行信道的CQI值需要在UE侧获取，并由UE反馈给基站。CQI的测量可以在整个系统带宽内只测试一个CQI，并反馈给基站，这种CQI称之为宽带CQI。如果针对不同的PRB组来测量CQI并分别反馈，这称之为多频带CQI。CQI用来指示适合该PRB组的传输块尺寸（TBS）和调制方式（MS）等参数。
具体测试CQI的过程是，UE根据某个PRB组信噪比的测量值，找出HARQ第一次传输时，该BLER小于0.1的调制方式，然后反馈相应的CQI。
CQI的测量和反馈可能是周期性或非周期性的，周期性的CQI总是通过PUCCH信道来反馈，非周期性的CQI总是PUSCH信道来反馈。非周期性的CQI是通过事件来触发的，如果基站通过下发信令Uplink Resource Grant向UE发起CQI测量命令，UE把CQI测量结果通过PUSCH信道反馈给基站。如果在发送周期性的CQI子帧中恰好也要发送非周期性的CQI，那么周期性的CQI测量结果就不用通过PUCCH信道发送了，只通过PUSCH信道发送非周期性的CQI信息即可[5]。
ACK/NACK信息用于对下行数据的HARQ反馈。
2.2 上行控制信息在PUCCH信道中传输
PUCCH信道中的ACK/NACK 和CQI的发送将持续一个子帧（ 1ms）,如果不能被正确接收，则可以在多个子帧中重复发送。
根据PUCCH信道承载的内容不同，PUCCH信道被分成多种格式，参见表二[2]。
表二 PUCCH信道的格式
2.3 上行控制信息复用在PUSCH信道中传输
由于LTE物理层采用单载波（DFT-SOFDM）作为多址方式，为了保持上行单载波的特性，LTE物理层不支持PUSCH信道和PUCCH信道的复用，即一个用户不能在一个时刻同时发送PUSCH信道数据和PUCCH信道数据，当用户有上行数据PUSCH在发送时，如果需要同时发送物理层上行控制信息（CQI、ACK），那么这些信息将与数据信息一起复用在PUSCH信道上传输。参见图五[3]。
图五控制信息与UL-SCH在PUSCH信道复用
2.4 上行控制信息传输测试方案
LTE上行控制信息传输测试主要检查PUCCH信道的控制信息和PUSCH信道中的控制
信息能否正确地被基站接收。
测试方案要求在静态传播环境（即白噪声）基础之上，叠加不同的信道模型，以模拟真实的环境，来检验LTE系统在实际的复杂信道环境中，正确解调UE发送的控制信息的能力。
根据2.1和2.2节所述，测试方案应分别针对PUCCH 信道的不同格式和控制信息复用在PUSCH信道中来进行，PUCCH信道格式选取Format 1a和Format 2格式为代表来进行测试。
测试按图六进行测试连接，对模拟UE信号源发出的控制信息进行统计，来检验LTE系统是否可以满足规定的指标要求[1]。
PUCCH Format 1a、PUCCH Format 2和控制信息复用在PUSCH信道中的信号格式如图七所示，要求模拟的信号每子帧(1ms)发送一次，共发送1000次，总计1s统计时间，要求所有控制信息的正确检测概率应大于99%。
3.PRACH信道技术特征与性能测试
LTE随机接入是UE在开始和网络通信之前的接入过程，通过PRACH信道来具体执行。随机接入过程可以分为同步随机接入和非同步随机接入，两者之间的区别主要在于UE是否和系统取得上行时钟同步。由于非同步接入只能采用随机接入的方式，其本质上是一种“竞争接入”的方式。而同步接入则不同，由于上行同步已经取得，可以采用调度的方式传送上行接入信息，因此是“非竞争接入”。LTE上行非同步随机接入过程包括以下四步：
（1）在PRACH信道上发送随机前导序列，用于通知网络进行随机接入尝试。
（2）网络对接入尝试进行响应，在DL-SCH信道上发送随机接入响应。
（3）UE在UL-SCH信道上发送连接请求消息，消息中携带终端标识（C-RNTI）。
(4) 网络侧在DL-SCH信道中发送竞争判决消息，确定UE是否随机接入获得成功。
在整个上行非同步随机接入过程中，对前导序列的正确识别和竞争消息的判决应是整个过程的关键。
3.1 PRACH信道格式分析
PRACH信道包括循环前缀（CP）、Preamble前导序列和保护时隙（GT）三个部分。CP 用于抵抗多径时延，消除载波间干扰（ICI）和符号间干扰（ISI）。GT主要考虑基站的小区半径大小的变化，用来保护UE到达基站信号的时延变化，与LTE基站的覆盖范围密切相关。
PRACH信道的T CP 、T seq、和T GT 三个参数的选取，也充分考虑了小区覆盖半径、Preamble 前导序列检测概率的影响。
在LTE技术规范中，为FDD-LTE和TD-LTE设计了四种通用的Preamble分别是Preamble0，1，2，3。同时，针对TD-LTE，设计了Preamble 4，主要面向较小小区的热点覆盖。参见图八。
格式1和格式3使用了较长的CP，适用于小区半径较大的情况。格式2和格式3中重复的前导序列，适用于路损较大的小区环境。格式0占据一个子帧的长度，格式1和格式2占据两个连续子帧的长度，格式3占据3个连续子帧的长度。从图八可以看出，PRACH信道中的CP和前导序列并没有占满整个子帧的时间，剩余的部分即为保护时间（Guard Period）。具体参数详见表三[2]。
表三Preamble格式参数值
PRACH信道中前导序列是由一个或多个ZC序列的根序列经过循环移位生成的，通过广播信息SIB2中的参数rootSequenceIndex（在0到837之间取值）来广播第一个ZC根序列。对根序列按一定的循环移位长度（Ncs）进行位移，生成相应的PRACH前导序列。在
LTE基站小区中，网络侧配置小区内可以使用的前导序列，每个LTE小区有64个前导序列。由于PRACH上行传输的不同步以及不同的传输延迟，相应的循环移位之间需要有足够的间隔，并非所有的循环移位都能够作为正交序列使用。如果可用的循环移位的前导序列数目不够64个，则按一定的规则选择下一个ZC根序列，通过循环移位生成新的PRACH前导序列[2]。
当执行随机接入尝试时，UE从这64个前导序列选择一个序列进行接入。只要小区内的其他用户不在相同的时间里使用相同的序列，那么就不会发生接入冲突。如果发生冲突，系统将通过后续的竞争判决过程来决定谁是“胜利者”。
3.2 PRACH信道性能测试方案
测试方案要求在静态传播环境（即白噪声）基础之上，叠加不同的信道模型，以模拟真实的环境，来检验LTE系统在实际的复杂信道环境中，正确解调UE发送的前导序列的能力。根据3.1节所述，测试方案应分别针对PRACH信道前导序列的不同格式来进行，连接方案按图六进行测试连接[1]。
不同的信号格式如图八所示，要求模拟的preamble 0格式信号每1ms发送一次，共发送1000次，总计1s统计时间；模拟的preamble 1和preamble 2格式信号每2ms发送一次，共发送1000次，总计2s统计时间；模拟的preamble 3 格式信号每3ms发送一次，共发送1000次，总计3s统计时间。
另外，全部格式的preamble序列移位以50%的Ncs（循环移位长度）为起点,进行连续调整,每一个Preamble移位较前一个Preamble移位增加0.1微秒,连续增加9次,直到增加0.9微秒.然后timing offset恢复到50%的Ncs，随后反复进行。
全部格式的Preamble前导序列正确检测概率应大于99%。
参考文献:
[1]3GPP TS 36.141 V10.1.0 Evolved Universal Terrestrial Radio Access (E-UTRA);
Base Station (BS) conformance testing (Release 10)
[2]3GPP TS 36.211 V10.0.0 Evolved Universal Terrestrial Radio Access (E-UTRA);
Physical channels and modulation (Release 10)
[3]3GPP TS 36.212 V10.0.0 Evolved Universal Terrestrial Radio Access (E-UTRA);
Multiplexing and channel coding (Release 10)
[4]3GPP TS 36.213 V10.0.0 Evolved Universal Terrestrial Radio Access (E-UTRA);
Physical layer procedures (Release 10)
[5]沈嘉等.3GPP长期演进（LTE）技术原理与系统设计
[6] R&S公司. LTE Base Station Performance Tests
作者简历
王湘宁
通信与电子系统硕士，高级工程师。就职于中国联通研究院测评与保障中心。Analysis of LTE Base Station Performance Testing
Wang Xiangning China Unicom Labs,Beijing 100032,China
This paper analysed HARQ technology and UE in connected state uplink synchronous technology of PUSCH channel ,technical features of PUCCH channel and PRACH channel. Based on the analysis, the corresponding test methods and test requirements were given.
Keywords LTE; performance;testing;PUSCH channel; PUcCH channel; PRACH channel;
目录: Linux硬件基础 CPU：就像人的大脑，主要负责相关事情的判断以及实际处理的机制。 CPU：CPU的性能主要体现在其运行程序的速度上。影响运行速度的性能指标包括CPU的工作频率、Cache容量、指令系统和逻辑结构等参数。 查询指令：cat /proc/cpuinfo 内存：大脑中的记忆区块，将皮肤、眼睛等所收集到的信息记录起来的地方，以供CPU 进行判断。 内存：影响内存的性能主要是内存主频、内容容量。 查询指令：cat /proc/meminfo 硬盘：大脑中的记忆区块，将重要的数据记录起来，以便未来再次使用这些数据。 硬盘：容量、转速、平均访问时间、传输速率、缓存。 查询指令：fdisk -l (需要root权限) Linux监控命令 linux性能监控分析命令 vmstat vmstat使用说明 vmstat可以对操作系统的内存信息、进程状态、CPU活动、磁盘等信息进行监控，不足之处是无法对某个进程进行深入分析。 vmstat [-a] [-n] [-S unit] [delay [ count]] -a：显示活跃和非活跃内存 -m：显示slabinfo -n：只在开始时显示一次各字段名称。 -s：显示内存相关统计信息及多种系统活动数量。 delay：刷新时间间隔。如果不指定，只显示一条结果。 count：刷新次数。如果不指定刷新次数，但指定了刷新时间间隔，这时刷新次数为无穷。-d：显示各个磁盘相关统计信息。 Sar sar是非常强大性能分析命令，通过sar命令可以全面的获取系统的CPU、运行队列、磁盘I/O、交换区、内存、cpu中断、网络等性能数据。 sar 命 令行
XXX系统--版本号XXX 性能测试方案 XXX有限公司 XXXX年XX月XX日 修订历史记录
目录 1简介 (1) 1.1目的和软件说明 (1) 1.2内容摘要 (1) 1.3适用对象 (1) 1.4术语和缩略语 (1) 1.5参考文档 (1) 2系统概述 (2) 2.1项目背景 (2) 2.2系统架构 (3) 2.2.1架构概述 (3) 2.2.2运行环境 (3) 2.2.3处理流程 (4) 2.3技术方案设计 (4) 3测试目标 (5) 4测试范围 (6)
4.1测试对象 (6) 4.2需要测试的特性 (6) 4.3不需要测试的特性 (7) 5 4. 测试启动/结束/暂停/再启动准则 (8) 5.1启动准则 (8) 5.2结束准则 (8) 5.3暂停准则 (8) 5.4再启动准则 (9) 6测试人员 (10) 7测试时间 (11) 8测试环境 (12) 8.1系统架构图 (12) 8.2测试环境逻辑架构图 (12) 8.3测试环境物理架构图 (12) 8.4环境配置列表 (12) 8.4.1生产环境 (12)
8.4.2测试环境 (13) 8.4.3环境差异分析 (13) 8.4.4测试客户机 (14) 8.5测试工具 (14) 9测试策略 (15) 10测试场景设计 (16) 10.1总体设计思路 (16) 10.2业务模型 (16) 10.3测试场景设计 (17) 10.3.1......................................... 单交易负载测试 17 10.3.2....................................... 混合交易负载测试 18 10.3.3............................................. 稳定性测试 18 10.3.4...................................... 有/无缓存比对测试 19 10.3.5....................................... 网络带宽模拟测试 19 11测试实施准备.. (21) 11.1................................................. 测试环境准备 21
?每台服务器每秒平均PV量= （（80%*总PV）/（24*60*60*（9/24）））/服务器数量， ?即每台服务器每秒平均PV量=2.14*（总PV）/* （24*60*60） /服务器数量 ?最高峰的pv量是1.29倍的平均pv值 性能测试策略 1.模拟生产线真实的硬件环境。 2.服务器置于同一机房，最大限度避免网络问题。 3.以PV为切入点，通过模型将其转换成性能测试可量化的TPS。 4.性能测试数据分为基础数据和业务数据两部分，索引和SQL都会被测试到。 5.日志等级设置成warn，避免大量打印log对性能测试结果的影响。 6.屏蔽ESI缓存，模拟最坏的情况。 7.先单场景，后混合场景，确保每个性能瓶颈都得到调优。 8.拆分问题，隔离分析，定位性能瓶颈。 9.根据性能测试通过标准，来判断被测性能点通过与否。 10.针对当前无法解决的性能瓶颈，录入QC域进行跟踪，并请专家进行风险评估。 性能测试压力变化模型
a点：性能期望值 b点：高于期望，系统资源处于临界点 c点：高于期望，拐点 d点：超过负载，系统崩溃 性能测试 a点到b点之间的系统性能，以性能预期目标为前提，对系统不断施加压力，验证系统在资源可接受范围内，是否能达到性能预期。 负载测试 b点的系统性能，对系统不断地增加压力或增加一定压力下的持续时间，直到系统的某项或多项性能指标达到极限，例如某种资源已经达到饱和状态等。 压力测试 b点到d点之间，超过安全负载的情况下，对系统不断施加压力，是通过确定一个系统的瓶颈或不能接收用户请求的性能点，来获得系统能提供的最大服务级别的测试。
稳定性测试 a点到b点之间，被测试系统在特定硬件、软件、网络环境条件下，给系统加载一定业务压力，使系统运行一段较长时间，以此检测系统是否稳定，一般稳定性测试时间为n*12小时。 监控指标 性能测试通常需要监控的指标包括： 1.服务器 Linux（包括CPU、Memory、Load、I/O）。 2.数据库：1.Mysql 2.Oracle（缓存命中、索引、单条SQL性能、数据库线程数、数据池连接数）。 3.中间件：1.Jboss 2. Apache（包括线程数、连接数、日志）。 4.网络：吞吐量、吞吐率。 5.应用： jvm内存、日志、Full GC频率。 6.监控工具（LoadRunner）：用户执行情况、场景状态、事务响应时间、TPS等。 7.测试机资源：CPU、Memory、网络、磁盘空间。 监控工具 性能测试通常采用下列工具进行监控： 1.Profiler。一个记录log的类，阿里巴巴集团自主开发，嵌入到应用代码中使用。 2.Jstat。监控java 进程GC情况，判断GC是否正常。 3.JConsole。监控java内存、java CPU使用率、线程执行情况等，需要在JVM参数中进行配置。 4.JMap。监控java程序是否有内存泄漏，需要配合eclipse插件或者MemoryAnalyzer 来使用。 5.JProfiler。全面监控每个节点的CPU使用率、内存使用率、响应时间累计值、线程执行情况等，需要在JVM参数中进行配置。 6.Nmon。全面监控linux系统资源使用情况，包括CPU、内存、I/O等，可独立于应用监控。
性能测试详细测试方案 、八、- 前言 平台XX项目系统已经成功发布，依据项目的规划，未来势必会出现业务系统中信息大量增长的态势。 随着业务系统在生产状态下日趋稳定、成熟，系统的性能问题也逐步成为了我们关注的焦点：每天大数据量的“冲击”，系统能稳定在什么样的性能水平，面临行业公司业务增加时，系统能否经受住“考验”，这些问题需要通过一个完整的性能测试来给出答案。 1第一章XXX系统性能测试概述 1.1 被测系统定义 XXX系统作为本次测试的被测系统（注：以下所有针对被测系统地描述均为针对XXX系统进行的），XXX系统是由平台开发的一款物流应用软件，后台应用了Oraclellg数据库， 该系统包括主要功能有:XXX 等。在该系统中都存在多用户操作，大数据量操作以及日报、周报、年报的统计，在本次测试中，将针对这些多用户操作，大数据量的查询、统计功能进行如预期性能、用户并发、大数据量、疲劳强度和负载等方面的性能测试，检查并评估在模拟环境中，系统对负载的承受能力，在不同的用户连接情况下，系统的吞吐能力和响应能力，以及在预计的数据容量中，系统能够容忍的最大用户数。1.1.1 功能简介 主要功能上面已提到，由于本文档主要专注于性能在这里功能不再作为重点讲述。 1.1.2 性能测试指标 本次测试是针对XXX系统进行的全面性能测试，主要需要获得如下的测试指标。 1、应用系统的负载能力：即系统所能容忍的最大用户数量，也就是在正常的响应时间中，系统能够支持的最多的客户端的数量。
2、应用系统的吞吐量：即在一次事务中网络内完成的数据量的总和，吞吐量指标反映的是服务器承受的压力。事务是用户某一步或几步操作的集合。 3、应用系统的吞吐率：即应用系统在单位时间内完成的数据量，也就是在单位时间内，应用系统针对不同的负载压力，所能完成的数据量。 4、T PS每秒钟系统能够处理事务或交易的数量，它是衡量系统处理能力的重要指标。 5、点击率：每秒钟用户向服务器提交的HTTP青求数。 5、系统的响应能力：即在各种负载压力情况下，系统的响应时间，也就是从客户端请求发起，到服务器端应答返回所需要的时间，包括网络传输时间和服务器处理时间。 6、应用系统的可靠性：即在连续工作时间状态下，系统能够正常运行的时间，即在连续工作时间段内没有出错信息。 1.2系统结构及流程 XXX系统在实际生产中的体系结构跟本次性能测试所采用的体系结构是一样的，交易流 程也完全一致的。不过，由于硬件条件的限制，本次性能测试的硬件平台跟实际生产环境略有不同。 1.2.1系统总体结构 描述本系统的总体结构，包括：硬件组织体系结构、网络组织体系结构、软件组织体系结构和功能模块的组织体系结构。 1.2.2功能模块 本次性能测试中各类操作都是由若干功能模块组成的，每个功能都根据其执行特点分成 了若干操作步骤，每个步骤就是一个功能点（即功能模块），本次性能测试主要涉及的功能 模块以及所属操作如下表
XXXX系统性能测试报告
1 项目背景 为了了解XXXX系统的性能，特此对该网站进行了压力测试2 编写目的 描述该网站在大数据量的环境下，系统的执行效率和稳定性3 参考文档 4 参与测试人员 5 测试说明 5.1 测试对象 XXXX系统
5.2 测试环境结构图 5.3 软硬件环境 XXXXX 6 测试流程 1、搭建模拟用户真实运行环境 2、安装HP-LoadRunner11.00（以下简称LR） 3、使用LR中VuGen录制并调试测试脚本 4、对录制的脚本进行参数化 5、使用LR中Controller创建场景并执行 6、使用LR中Analysis组件分析测试结果 7、整理并分析测试结果，写测试总结报告 7 测试方法 使用HP公司的性能测试软件LoadRunner11.00，对本系统业务进行脚本录制，测试回放，逐步加压和跟踪记录。测试过程中，由LoadRunner的管理平台调用各前台测试，发起 各种组合业务请求，并跟踪记录服务器端的运行情况和返回给客户端的运行结果。录制登陆业务模块，并模拟30、50、80、100 个虚拟用户并发登陆、添加和提交操作，进行多次连续测试，完成测试目标。 测试评估及数据统计 此次测试通过同一台客户机模拟多个并发用户在因特网环境进行，未考虑因特网的稳定 性的问题。此次测试用户操作流程相对简单，只录制了三个事务，即：用户登录、添加和信息提交，从测试的数据来分析，各项性能指标基本在可控的范围之内。但在测试过程中也发 现一些不容忽视的问题，应予以重视。 1 、模拟80 个用户并发操作时，出现1 个未通过的事务，具体原因需结合程序、网络和服务器综合分析，系统的稳定性并非无可挑剔。 2 、用户登陆事务的平均响应时间与其他两个事务相比等待的时间要长，且波动也较大， 在网速变慢、用户数增加的外部条件下，有可能会影响到系统的稳定性。建议优化系统登录页面程序，提高系统的稳定性。
........................................................................................................................................................................................ 性能测试题库答案 一、低难度类： 1、理论类 选择类 1) 通过疲劳强度测试，最容易发现问题的问题是:B A．并发用户数 B．内存泄露 C．系统安全性 D．功能错误 2) 如下那些工具不属于压力测试工具:D A．LoadRunner B．Logiscope（嵌入式测试工具） C．WAS(WebSphere Application Server(WAS)) (中间件服务器) D．Rational Robot(用于的G UI脚本、用于的V U以及V B脚本) 3) 如下哪些测试场景不属于负载压力测试:A A．恢复测试 B．疲劳强度测试 C．大数据量测试 D．并发性能测试 4) LINUX 下，解压缩文件的命令为:B A. tar zxvf 文件名 B. unzip 文件名 C. CAT 文件名 D. VI 文件名 5) 对abcd 文件赋予所有者和组许可的读和执行权限，命令正确的是:B A. chmod 033 abcd B. chmod 550 abcd C. chmod 770 abcd
........................................................................................................................................................................................ D. chmod u+rx abcd 6）在软件性能测试中，下列指标中哪个不是软件性能的指标D A）响应时间C）资源利用率D）并发进程数 B）吞吐量 7）下列关于软件性能测试的说法中，正确的是B A）性能测试的目的不是为了发现软件缺陷 B）压力测试与负载测试的目的都是为了探测软件在满足预定性能需求的情况下所能负担的最大压力 C）性能测试通常要对测试结果进行分析才能获得测试结论 D）在性能下降曲线上，最大建议用户数通常处于性能轻微下降区与性能急剧下降区的交界处 8）下列关于软件可靠性测试的说法中，错误的是A A）发现软件缺陷是软件可靠性测试的主要目的 B）软件可靠性测试通常用于有可靠性要求的软件 C）在一次软件可靠性测试中，执行的测试用例必须完全符合所定义的软件运行剖面 D）可靠性测试通常要对测试结果进行分析才能获得测试结论 问答类 1) 什么是性能测试，其应用领域分别是什么？ 性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试，应用领域有四个：能力验证、能力规划、性能调优、缺陷发 现。 2) 什么是负载测试？ 负载测试：通过被测试系统不断增加压力，直到性能指标超过预期值或者某种资源达到饱和状态； 3) 可靠性测试、可用性测试的定义，有什么区别？ 可靠性测试：通过在有使用代表性的环境中执行软件,以证实软件需求是否正确实现。为进行软件可靠性估计采集准确的数据。估计软件可靠性一般可分为四个步骤,即数据采集、模型选择、模型拟合以及软件可靠性评估。 可用性测试：故名思议是测试设计方案或者产品在一定的环境下的可用性水平。 4) 性能测试包含了哪些测试（至少举出3 种）？ 压力测试、负载测试、并发测试、疲劳强度测试、大数据量测试； 5) 什么时候可以开始执行性能测试？ 在产品相对比较稳定，功能测试完成后； 6) Web服务器指标指标有哪些？ * Avg Rps: 平均每秒钟响应次数＝总请求时间/ 秒数； * Successful Rounds：成功的请求；(成功回合)
性能测试方案
目录 前言 (3) 1第一章系统性能测试概述 (3) 1.1 被测系统定义 (3) 1.1.1 功能简介 (4) 1.1.2 性能测试指标 (4) 1.2 系统结构及流程 (4) 1.2.1 系统总体结构 (4) 1.2.2 功能模块描述 (4) 1.2.3 业务流程 (5) 1.2.4 系统的关键点描述（KP） (5) 1.3 性能测试环境 (5) 2 第二章性能测试 (6) 2.1 压力测试 (6) 2.1.1 压力测试概述 (7) 2.1.2 测试目的 (7) 2.1.3 测试方法及测试用例 (7) 2.1.4 测试指标及期望 (8) 2.1.5 测试数据准备 (9) 2.1.6 运行状况记录 (99) 3第三章测试过程及结果描述 (90) 3.1 测试描述 ................................................................................................. 错误！未定义书签。 3.2 测试场景 ................................................................................................. 错误！未定义书签。 3.3 测试结果 ................................................................................................. 错误！未定义书签。 4 第四章测试报告 (11)
XX系统性能测试方案 (仅供内部使用) 拟制: 日期：yyyy-mm-dd 审核: 日期：yyyy-mm-dd 审核: 日期：yyyy-mm-dd 批准: 日期：yyyy-mm-dd 博为峰教育科技(北京)有限公司 版权所有侵权必究
修订记录
目录 1概述 (6) 1.1被测试系统简介 (6) 1.2性能测试目的 (6) 2性能需求分析 (6) 3系统角色行为分析 (7) 3.1用户行为分析 (7) 3.2运营行为分析 (8) 3.3系统后台行为分析 (8) 4系统结构分析 (8) 4.1系统组成分析 (8) 4.2压力传递分析 (8) 4.3潜在瓶颈分析 (9) 4.4系统资源分析 (9) 4.5系统监测及其评价标准分析 (9) 5性能测试方案的确定 (10) 5.1基本流程的确定 (10) 5.2异常流程分析 (10) 5.3混合流程分析 (10) 5.4测试项的确定 (11) 5.5数据模型分析及数据规划 (11) 5.6妨碍性能测试持续开展的问题及其解决办法 (11) 5.7测试接口分析 (11) 5.8被测系统配置及其组网图 (11) 5.9测试工具的选定 (12) 5.10测试数据的准备 (12) 5.11测试用例设计建议 (12) 6附录 (12)
表目录List of Tables 表1 需求跟踪矩阵表........................................................................................ 错误！未定义书签。
图目录List of Figures 错误！未找到目录项。
1.引言 说明测试方案中所涉及内容的简单介绍，包含：编写目的，项目背景、参考文档，以及预期的读者等。 1.1.编写目的 本文档描述××系统性能测试的范围、方法、资源、进度，该文档的目的主要有： 1.明确测试目的范围。 2.明确测试范围和目标。 3.明确测试环境需求，包括：测试需要的软、硬件环境以及测试人力需求。 4.确定测试方案，测试的方法和步骤。 5.确定测试需要输出的结果和结果表现形式。 6.分析测试的风险，寻找规避办法。 1.2.项目简介 简要描述与测试项目相关的一些背景资料，如被测系统简介，项目上线计划等。 1.3.参考文档 说明文档编写过程参考引用的资料信息。 2.测试目的、范围与目标 2.1.测试目的
根据项目总体计划明确项目测试目的。常见的测试目的如下（依据项目的实际情况修改。 本次性能测试的主要目的在于： ?测试已完成系统的综合性能表现，检验交易或系统的处理能力是否满足 系统运行的性能要求； ?发现交易中存在的性能瓶颈，并对性能瓶颈进行修改； ?模拟发生概率较高的单点故障，对系统得可靠性进行验证； ?验证系统的生产环境运行参数设置是否合理，或确定该参数； ?获得不同备选方案的性能表现，为方案选择提供性能数据支持。 2.2.测试功能范围 说明本项目需要进行测试的待测系统功能范围，列出被测对象的测试重要性及优先级等，提供一份简要列表。对于交易类功能要细化到每一个交易码；对于页面类功能要细化到每一个发起页面。下面表格供参考，非强制使用。 如果测试目的为方案验证，需要文字列出需要验证的方案项。 明确列出说明本次测试需要关注的测试指标的定义及范围，不需要关注的测试指标也应列出。下面的内容供参考。 本次性能测试需要获得的性能指标如下所列：
常用的性能测试方法和测试要点 2008-12-16 13:58:04 / 个人分类：转载好东西 常用的性能测试方法和测试要点 1、明确用户的性能需求（显示的和隐式的），性能测试点，找出瓶颈 1）用户直接需求的和使用过程中（行业经验）可能遇到的性能瓶颈点必须测试和分析到。当然，客户不需要的，也没有必要去花时间和精力。 2）从中获取相应的性能测试参数，峰值和平均值。 3）客户的性能容忍度和系统所能承受的容忍度同样重要。 4）确认系统运行的最低硬件环境要求（虽然硬件便宜的多了，但客户能不能改造自己的环境还得客户说了算） 5）如果可以的话，将系统的容错性做为性能测试的一部分进行测试 2、测试对象和性能负载分布 1）基本的3个对对像：C/S、B/S中的客户端和服务器，其中还有网络进行连接或中间件。 2）服务端可能分为数据端、业务端和服务容器。 3）跟据实际的测试结果合理的进行相应的性能负载分布。 3、负载、容量和压力测试逐一进行（如果需要） 1）更多的情况下，性能测试中出现的问题是最初的设计时应存在的问题。如果可能，建议对相应的性能提前做测试和优化。 2）够用就好，不是所有的系统都要进行性能测试，一切以客户需求和实际需要为准。 4、测试点 1）CPU和内存使用（系统自身的原因）。是否可以正常的使用和释放，是否存在内存溢出。 2）访问的速度（客户需求或是实际的应用要求说了算） 3）网络。网络传输速度，网络传输丢包率。（找些工具，有免费的）
4）服务器。指令、服务应答响应时间，服务器对信息处理的时效性，服务器对峰值的处理（建议进行服务器优化或是进行服务负载均衡，有大量的文档对此进行描述） 5）中间件。中间件在信息传递中的处理性能及信息处理的正确性。 5、测试和监控数据 1）均值下的持续运行（通过分析对整体的性能进行预测和评估） 2）短时间的峰值运行（分析系统的处理能力） 3）最低配置和最佳配置下的性能对比 4）多用户。同时访问，同时提交。 5）对4 中的数据进行记录和监控 6、选择测试工具 现有的测试工具太多了，不在一一列举。 适用就好，推荐开源的工具。 作为一名测试新人加入团队，大多数情况下，项目组成员都是一种热情欢迎的态度，并且主动提供力所能及的支持和帮助，如何快速熟悉项目业务和测试环境，尽快投入到实际工作中去，我谈谈个人的经验和一些看法，供同行参考： 1、寻找新公司的团队元老： 一般来说，一个新人进入新公司，都要指定一个师傅带一段时间，这也就是我们说的测试前辈。很多时候，测试前辈都是经验非常丰富的测试高人，如何您和他相处融洽，关系不错，凭他个人丰富的业务经验，给您指点迷津，也许会比你自己摸索10倍的时间效果还好。很多的测试新手，刚进入新公司时，自高自大，眼高收低，测试前辈都不愿意交，结果到了试用期转正答辩的时候，一问三不知，被迫离开公司，被炒鱿鱼。这样的例子我看到的不下于10例，很可惜丢失了很多工作机会。 2、虚心的学习态度： 刚到一家新公司，保持谦虚的学习态度非常必要。记得我刚毕业那年，公司招聘了一个测试主管，他有4到5年的工作经验，阅历算是不简单，也是我们心目中的牛人吧。但是那个人，除了听总监的话以外，对于我们部门的其它人来说，他简直是自高自大，目中无人，根本不把部门里的其他人放到眼里，觉得部门的人都不如他。他作为一个空降兵，老员工和新员工，对他都很冷漠，碰到什么问题，需要小组成员帮忙的时候，大家都不愿意帮助他，互相推诿，
性能测试详细测试方案 前言 平台XX项目系统已经成功发布，依据项目的规划，未来势必会出现业务系统中信息大量增长的态势。 随着业务系统在生产状态下日趋稳定、成熟，系统的性能问题也逐步成为了我们关注的焦点：每天大数据量的“冲击”，系统能稳定在什么样的性能水平，面临行业公司业务增加时，系统能否经受住“考验”，这些问题需要通过一个完整的性能测试来给出答案。 1第一章XXX系统性能测试概述 1.1被测系统定义 XXX系统作为本次测试的被测系统（注：以下所有针对被测系统地描述均为针对XXX 系统进行的），XXX系统是由平台开发的一款物流应用软件，后台应用了Oracle11g数据库，该系统包括主要功能有:XXX等。在该系统中都存在多用户操作，大数据量操作以及日报、周报、年报的统计，在本次测试中，将针对这些多用户操作，大数据量的查询、统计功能进行如预期性能、用户并发、大数据量、疲劳强度和负载等方面的性能测试，检查并评估在模拟环境中，系统对负载的承受能力，在不同的用户连接情况下，系统的吞吐能力和响应能力，以及在预计的数据容量中，系统能够容忍的最大用户数。 1.1.1功能简介 主要功能上面已提到，由于本文档主要专注于性能在这里功能不再作为重点讲述。
1.1.2性能测试指标 本次测试是针对XXX系统进行的全面性能测试，主要需要获得如下的测试指标。 1、应用系统的负载能力：即系统所能容忍的最大用户数量，也就是在正常的响应时间中，系统能够支持的最多的客户端的数量。 2、应用系统的吞吐量：即在一次事务中网络内完成的数据量的总和，吞吐量指标反映的是服务器承受的压力。事务是用户某一步或几步操作的集合。 3、应用系统的吞吐率：即应用系统在单位时间内完成的数据量，也就是在单位时间内，应用系统针对不同的负载压力，所能完成的数据量。 4、TPS：每秒钟系统能够处理事务或交易的数量，它是衡量系统处理能力的重要指标。 5、点击率：每秒钟用户向服务器提交的HTTP请求数。 5、系统的响应能力：即在各种负载压力情况下，系统的响应时间，也就是从客户端请求发起，到服务器端应答返回所需要的时间，包括网络传输时间和服务器处理时间。 6、应用系统的可靠性：即在连续工作时间状态下，系统能够正常运行的时间，即在连续工作时间段内没有出错信息。 1.2系统结构及流程 XXX系统在实际生产中的体系结构跟本次性能测试所采用的体系结构是一样的，交易流程也完全一致的。不过，由于硬件条件的限制，本次性能测试的硬件平台跟实际生产环境略有不同。
性能测试计划 网站稿件管理发布系统
目录 1.文档介绍 (3) 1.1文档目的 (3) 1.2参考文献 (3) 1.3编写目的 (3) 2.软件概述 (3) 2.1项目介绍 (3) 2.2运行环境 (3) 2.3项目流程 (4) 3.测试资源 (4) 3.1软硬件配置 (4) 3.2测试工具 (6) 3.3人力需求 (6) 3.4测试数据 (6) 4.交付物 (7) 5.测试进度计划 (7) 6.测试启动/结束/暂停/再启动/退出准则 (8) 6.1暂停准则： (8) 6.2暂停/再启动的准则 (8) 6.2.1暂停准则： (8) 6.2.2再启动准则 (8) 6.3测试退出准则 (8) 7.性能测试目标要求 (9) 7.1性能测试指标 (9) 7.2交易响应时间 (9) 7.3交易吞吐量 (9) 7.4并发交易成功率 (10) 7.5资源使用指标 (10) 8.测试策略 (10) 8.1基准测试 (10) 8.2并发测试 (10) 8.3递增测试 (10) 8.4场景测试 (11) 8.5疲劳强度测试 (11) 9.测试用例开发 (11) 10.交易基准测试 (12) 10.1测试方法 (14) 10.2测试场景 (14) 11.交易并发测试 (15) 11.1测试方法 (15) 11.2测试场景 (15) 11.3测试方法 (16) 11.4测试场景 (16) 12.交易递增测试场景.......................................................................... 错误！未定义书签。 12.1测试场景................................................................................................... 错误！未定义书签。 13.混合交易负载场景 (16)
视觉跟踪实验调查 内容提要 在过去20年间的文献中，有各种各样的追踪器被提出，其中成败各半。在现实场景中，对象跟踪是个难题，因此，它仍然是计算机视觉中最活跃的研究领域。好的跟踪器应该在大量涉及照明变化、遮挡、混乱、相机运动、低对比度、高光和至少六个其他方面的视频中执行良好。然而，这些被提出的追踪器的性能，通常是通过不到10个视频或专用数据集来评估的，在本文中，我们的目的是针对包含了上文各个方面的315个视频碎片，用实验方法系统地评估追踪器性能。我们选择了一组19个包括在文献中经常被引用的各种算法的追踪器，用2010年和2011年出现的代码公开的追踪器作补充。 我们证明了可以通过生存曲线、卡普兰Meier统计和Grubbs测试客观地评价追踪器。我们发现,在评估实践中，F-score和对象跟踪精确度得分是一样有效的。这些多种情况下的分析对追踪器的优点与缺点提供了客观的见解。 【关键词】对象跟踪、跟踪评估、跟踪数据集,摄像头监控,视频理解, 计算机视觉,图像处理。 一．介绍 视觉跟踪是个难题，因为需要在一种算法中同时考虑不同且多变的各种情况。举个例子，有的追踪器可能善于处理光照变化，但在处理由于对象的观点变化而导致的对象的外观变化时有困难；有的追踪器可能通过预判移动来估计速度，但在追踪弹性物体时有很大困难；有的追踪器能对外观作出详细的假定，却可能在一个关节式物体上失败。 考虑到各种各样的跟踪情况和跟踪方法，评价视频序列的数量通常是有限的，这一点让人意外。在2011年出现在TPAMI或CVPR上的关于跟踪的文章中，不同的视频数量只有5到10个。视频长度可能长达1到15分钟，但在5到10个视频中，很少有以上条件能得到充分测试的。 考虑到对计算机视觉进行追踪的重要性，用于追踪的视频数量如此之少就显得更让人惊讶。在几乎每个视频分析任务中，跟踪都会发挥作用。跟踪确实已经发展得令人印象深刻，甚至令人惊异、独特的结果，就像对尘土中的摩托车或汽车追逐的跟踪。但是只要这些关于跟踪的文章依旧用有限数量的序列来检测他们方法的正确性，很多情况下就很难得出关于那些方法的鲁棒性的什么结论。我们觉得是时候进行一次针对各种条件的实验调查了。 调查的目的是评估一个视频中的目标跟踪的艺术状态，着重考察跟踪算法的准确性和鲁棒性。由于在这些方法之间没有统一的概念，我们试图从另一头来描述艺术状态：数据。我们设计了一组尽可能多样化的现实数据集，并且记录了所有被选用的追踪器的表现。我们想根据跟踪方法的实验表现来将它们分组。同时，我们也要评估跟踪绩效的表现度和相互依赖性。 我们在ALOV把315个视频碎片聚集起来，每个视频集中在一个情境，以此来
xxx性能测试方案 文档修改历史
目录 1.文档介绍 (3) 1.1.测试目的 (3) 1.2.读者对象 (3) 1.3.参考资料 (3) 1.4.术语与解释 (3) 2.测试环境 (3) 2.1.测试环境 (3) 2.2.测试工具 (4) 3.测试需求 (4) 3.1.测试功能点 (4) 3.2.性能需求 (4) 4.准备工作 (5) 5.测试完成准则 (5) 6.测试风险 (6) 7.测试设计策略 (6) 7.1.关键资源不处于阻塞状态 (6) 7.2.组合测试用例策略 (6) 7.3.测试执行策略 (6) 8.业务模型 (7) 8.1.场景一 (7) 8.2.场景二 (7) 8.3.场景三 (8) 9.测试报告输出 (8)
1.文档介绍 1.1.测试目的 本次性能测试的目的是检测xxx系统的性能情况。即：为了xxx系统上线后能够稳定运行，有必要在上线前对核心业务场景的压力情况有充分了解。因此，希望在模拟生产环境的情况下，模拟上线后的用户并发数，对系统核心业务进行压力测试，收集相应的系统参数，并最终作为上线的依据。 编写本方案的目的是指导本次性能测试有序的进行，相关人员了解本次性能测试。1.2.读者对象 本方案的预期读者是：项目负责人、测试人员和其他相关人员。 1.3.参考资料 1.4.术语与解释 无 2.测试环境 模拟客户使用环境（最好模拟客户实际使用的配置环境）。具体如下： 2.1. 测试环境 网络环境：Lan（100M）
硬件环境： 应用服务器 数量：1台 配置：型号、CPU、内存等 数据库服务器 数量：1台 配置：型号、CPU、内存等 测试客户端 数量：2台 配置：型号、CPU、内存等 软件环境： 操作系统：Windows Server 2008，Windows XP SP3 应用服务软件：WebSphere，Tomcat5.5 数据库：DB2，Oracle 10g 2.2. 测试工具 LoadRunner9.5 3.测试需求 3.1. 测试功能点 本次测试共涉及登录，新闻发布......模块。 3.2. 性能需求 注：1. 如果未提出实际性能需求可简写或省略该项 2. 此项根据产品需要可适当修改 1)并发用户数达到？时，登录系统平均响应时间不超过？秒； 2)并发用户数为？时，操作主要的业务流平均响应时间在用户接受的范围内，系统
光纤位移传感器性能测试 一、实验目的： 1、了解光纤位移传感器的原理结构、性能。 2、了解光纤位移传感器的动态应用。 3、了解光纤位移传感器的测速应用。 二、实验内容： 1、光纤传感器的静态实验； 2、光纤位移传感器的动态应用实验； 3、光纤位移传感器的测速应用实验； （一）光纤传感器的静态实验 实验单元及附件： 主副电源、差动放大器、F/V表、光纤传感器、振动台。 实验原理： 反射式光纤位移传感器的工作原理如下图所示，光纤采用Y型结构，两束多膜光纤一端合并组成光纤探头，另一端分为两束，分别作为光源光纤和接收光纤，光纤只起传输信号的作用，当光发射器发出的红外光，经光源光纤照射至反射面，被反射的光经接收光纤至光电转换器将接受到的光纤转换为电信号。其输出的光强决定于反射体距光纤探头的距离，通过对光强的检测而得到的位移量如下图8-1所示 图8-1 实验步骤： （1）观察光纤位移传感器结构，它由两束光纤混合后，组成Y形光纤，探头固定在Z 型安装架上，外表为螺丝的端面为半圆分布的光纤探头。
（2）了解振动台在实验仪上的位置（实验仪台面上右边的圆盘，在振动台上贴有反射纸作为光的反射面。） （3）如图8-2接线：因光/电转换器内部已安装好，所以可将电信号直接经差动放大器放大。F/V显示表的切换开关置2V档，开启主、副电源。 （4）旋转测微头，使光纤探头与振动台面接触，调节差动放大器增益最大，调节差动放大器零位旋钮使电压表读数尽量为零，旋转测微头使贴有反射纸的被测体慢慢离开探头，观察电压读数由小-大-小的变化。 （5）旋转测微头使F/V电压表指示重新回零；旋转测微头，每隔0.05mm读出电压表的读数，并将其填入下表： △X（mm） 0.05 0.10 0.15 0.20 10.00 指示（V） 图8-2 （二）光纤传感器的动态应用实验 实验单元及附件： 主、副电源、差动放大器、光纤位移传感器、低通滤波器、振动台、低频振荡器、激振线圈、示波器。 实验步骤： （1）了解激振线圈在实验仪上所在位置及激振线圈的符号。 （2）如图8-3接线。 图8-3
国内汽车试验场跟踪研究 我国汽车试验场的起步较晚，试车场的数目更是屈指可数。面对新轮的汽车技术创新挑战与冲击，汽车企业希望找到更好的途径来测试和调整其产品，全国各地正兴起汽车试验场建设的热潮。 一、寒区试车场 （一)黑河寒区试车场 黑河市位于中国黑龙江省北部，面积为6.8万平方公里，人口为175万，是中俄边境线上唯一与俄联邦州政府所在城市相对应的距离最近、规模最大、规格最高、功能最全、开放最早的中国边境城市。 黑河市道路种类齐、分布广，有水泥混凝土路面911公里，沥青路面100公里，渣油路面15.4公里，砂石路面1960公里，改善路面1540公里，无路面130公里。辖区内有大小河流621条，大中型水库14座，还有众多的湖泊以及宽阔的江面可供冰面试车。 黑河已建有上海汽车制动系统有限公司卡伦山冬季试车场、美国天合汽车集团宋集屯冬季试车场、上海泛亚汽车技术中心有限公司冬季试车场、上海大众汽车冬季试车场、韩国万都卧牛湖冬季试车场和红河谷综合试车场等六家试车场。其中：红河谷试车场是我市第一家对各试车企业开放的寒区试车场，建有陆地ABS试车跑道、冰雪跑道系统、17条功能跑道，可为前来试车企业提供服务。 1、上海汽车制动系统有限公司卡伦山冬季试车场 2002年2月28日，中国第一家寒带汽车试验场———上海汽车制动系统有限公司黑河冬季试车场建成使用。 该试车场投资700万元，整个试车场由陆地试车场、冰面试车场和大型试车间三部分组成。黑河冬季试车场的建成，填补了我国寒带试车的空白。 2、上海泛亚汽车技术中心有限公司冬季试车场 泛亚汽车技术中心有限公司成立于1997年6月12日，由通用汽车中国公司与上海汽车工业（集团）总公司各出资50%共同组建而成。泛亚汽车技术中心有限公司是中国第一家中外合资汽车设计开发中心，也是国内最大的研发中心。 3、美国天合汽车集团宋集屯冬季试车场
一、性能测试的目的 1、评估当前系统 2、寻找瓶颈 3、预测未来性能 二、性能测试的前提： 接口稳定/接口确定 三、性能术语与指标详解： 1.并发：（1）一种为所有用户在同一时刻做同一操作，主要是为了验证程序或 数据库对并发处理能力 （2）另一种为多个用户对被测系统发起了多个请求，这些请求可以是同一种操作，也可以是不同操作，类似于混合场景的概念 2. 响应时间：响应时间反应完成某个业务所需的时间 响应时间= 网络传输时间（请求）+服务器处理（一层或多层）时间+网络传输时间（响应时间）+页面前端解析渲染时间 3.每秒通过事务数（TPS）：指每秒通过的事务数，是直接反映系统性能的指标，该值大时，系统性能比较好，当然每个系统都有他的上限，不可能无限大 将他以平均事务响应时间进行对比，可以分析事务数量对以响应时间的影响4.事务：用户一个或一系列的操作，代表一定的功能，在程序上变现为一段代码区块，所有性能测试其实最终都是围绕着事务展开的，事务代表用户的使用方法和结果，不同的操作组合成不同的事务，不同的事务又能组合成不同的场景（LR 必须至少有一个事务，LR监控事务） （事务不能超过接口的上限） 事务 Transactions 5.事务请求时间：从这个事务发起到最终处理完毕的所有时间。 一个事物包括一个或多个事务，每个任务包含一个或多个请求。 6.每秒点击数：每秒点击数代表用户每秒向外部服务器提交的http请求，但这里需要注意是提交一个登陆请求对于后端服务器来说，也许是多个请求，所以点击一次不代表就是一个请求。 7.吞吐量/吞吐率（I/O）（Input/Output）（反应服务器处理能力） 吞吐量：指单位时间内系统处理的请求数量 吞吐率：一般指用户在给定的一秒内从服务器获取的数据量，简而言之就是服务器返回的数据量 8.思考时间：指用户进行操作时每个请求或操作之间的间隔时间，是为了更加真实的模拟用户的操作场景。 9.资源利用率（服务器） CPU：一般分为系统CPU和用户CPU
浅谈软件性能测试中关键指标的监控与分析 一、软件性能测试需要监控哪些关键指标？ 软件性能测试的目的主要有以下三点： ? 评价系统当前性能，判断系统是否满足预期的性能需求。 ? 寻找软件系统可能存在的性能问题，定位性能瓶颈并解决问题。 ? 判定软件系统的性能表现，预见系统负载压力承受力，在应用部署之前，评估系统性能。而对于用户来说，则最关注的是当前系统： ? 是否满足上线性能要求？ ? 系统极限承载如何？ ? 系统稳定性如何？ 因此，针对以上性能测试的目的以及用户的关注点，要达到以上目的并回答用户的关注点，就必须首先执行性能测试并明确需要收集、监控哪些关键指标，通常情况下，性能测试监 控指标主要分为：资源指标和系统指标，如下图所示，资源指标与硬件资源消耗直接相关，而系统指标则与用户场景及需求直接相关。 性能测试监控关键指标说明： ? 资源指标 CPU使用率：指用户进程与系统进程消耗的CPU时间百分比，长时间情况下，一般可接 受上限不超过85%。 内存利用率：内存利用率=（1-空闲内存/总内存大小）*100%，一般至少有10%可用内存，内存使用率可接受上限为85%。 磁盘I/O: 磁盘主要用于存取数据，因此当说到IO操作的时候，就会存在两种相对应的操作，存数据的时候对应的是写IO操作，取数据的时候对应的是是读IO操作，一般使用% Disk Time（磁盘用于读写操作所占用的时间百分比）度量磁盘读写性能。
网络带宽：一般使用计数器Bytes Total/sec来度量，Bytes Total/sec表示为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较。 ? 系统指标： 并发用户数：某一物理时刻同时向系统提交请求的用户数。 在线用户数：某段时间内访问系统的用户数，这些用户并不一定同时向系统提交请求。 平均响应时间：系统处理事务的响应时间的平均值。事务的响应时间是从客户端提交访问请求到客户端接收到服务器响应所消耗的时间。对于系统快速响应类页面，一般响应时间为3秒左右。 事务成功率：性能测试中，定义事务用于度量一个或者多个业务流程的性能指标，如用户登录、保存订单、提交订单操作均可定义为事务，如下图所示： 单位时间内系统可以成功完成多少个定义的事务，在一定程度上反应了系统的处理能力，一般以事务成功率来度量，计算公式如下所示： 超时错误率：主要指事务由于超时或系统内部其它错误导致失败占总事务的比率。 二、如何监控关键指标？ ? 资源指标监控 主要针对各服务器系统平台（Windows、Linux、Unix等）资源使用进行监控。 可以使用系统自带的性能监控工具或者第三方工具进行监控，如Windows系统自带的“系统性能监视器”，如下图所示：