了解性能测试-Part 2

了解性能测试-Part 251Testing软件测试网,F/y�h wQ6i
I6K-p
c7r'OU3{0

• 测试过程中测试员的职责
• 确定性能和商业目标
• 如何把性能测试加入到开发过程

Part 251Testing软件测试网 rqyf2@&Z
R1r9c

• 系统架构和基础结构
• 选择要运行的测试类型

Part 351Testing软件测试网,yo e"` T!qgY

• 了解负载(业务概况)
• 测量的量化和界定

Part 4

• 了解工具
• 执行测试和报告结果

 在本系列的第二部分，我将关注处理架构和基础设施的问题，选择合适的测试类型。本文的目标并不会涉及到所有的架构和基础设施，也不会涉及到所有的测试类型。但是会提供一般性的指导以帮助测试人员完成一份比较合理的性能测试报告。51Testing软件测试网F V5]p!~Fh8h]y$VD?
 系统架构和基础设施51Testing软件测试网4`-`1U"d|
tRd.W
51Testing软件测试网b5])o S8kc*R;RO
 架构和基础设施可能是致使软件性能测试失败最常见的原因。为了正确的测试一个系统或者应用程序，有几个关键的因素必须得到确保，至少也要提供相关有用的信息。
1pb)Vd2b"X0
nDf+?jq3a0  我们将首先涉及有关物理架构的相关问题。这里有两个主要元素：1）应用程序和系统2）软件运行所处的平台和网络
&VV(ps5dK/FFG4~B"u0
'v6H8N@{e(Z.T0  如果部署的测试系统和生产环境(或目标环境)完全不同，那么测试就不能提供准确的性能数据。当我们涉及到系统的物理层，有几个关键的元素必须要阐述。51Testing软件测试网Z6V}Zwi#w

a ^m3N%R3i0}:e0 系统的物理痕迹是很关键的。如果生产系统工作在一个多服务器集群，而测试环境是一个单服务器(没有服务器集群)，由于可测量性因素(scalability factor)，测试可能是没有价值的。可测量性因素是测试环境设备与生产环境设备的比例。一些人认为10：1的比例是可以接受的，但是我发现一旦比例超过5：1，就无法确保架构和基础设施的真实性。51Testing软件测试网3R(\B^-_%s)OBb
图1展示一个3:1比例模型

Figure 1

Zq,C4wt.^Z051Testing软件测试网1viI.EP;N$m)L9[
 这可能是一个合理的数字，但是它们并不是一定契合生产环境的保证。在上图中我们漏掉了一个关键因素，在服务器集群中,你需要构建负载平衡。测试环境配置中没有这个因素。生产环境中的负载均衡是个瓶颈，因为所有事务都必须通过它来到达各自服务器。

除了物理层的可测量性问题外，我们也不得不检查每个平台的内部特性，以包含在测试中。

 51Testing软件测试网-i6Y5V?@#[0n(b

Figure 2

] _%K9LH0p0

51Testing软件测试网 t&|7FJU}*y

  上述模型在测试实验室是3：1，然而，在如下领域是有可疑的。它们之所以被怀疑是因为以下元素。第一部分描述一个系统和产品。第二个部分描述测试系统。他们在规模上是大大不同的。

• 生产环境的DB服务器是10 CPU，20GB内存
• 相当于1CPU对应2GB内存
• 测试环境的DB服务器是2CPU分享10GB内存
• 每个CPU有5GB内存
• 生产环境的APP服务器是20CPU分享10GB内存
• 相当于1CPU对应0.5GB内存
• 测试环境的APP服务器有2CPU分享10GB内存
• 每个CPU有5GB内存
• 生产环境的Web服务器是5CPU分享10GB内存
• 相当于1CPU对应2GB内存
• 测试环境的Web服务器是2CPU分享10GB内存
• 每个CPU有5GB内存

^9\&E_5x*u kSK0 架构的内部差异可能使测试环境产生或隐藏的问题而在生产系统中不会出现。如果你因为出现在测试环境下的问题而对系统或架构进行调整的话，你可能已经犯下了致命的错误并带到了生产系统中。

 确认架构和设施模型尤其是具有风险的。一些关系数据库的功能在不同的比例模型下的表现是有很大不同的。有很多方面需要调查:

• 驱动器的数量和大小
• 分发表和数据驱动器
• 表中的混合数据
• 索引，关键字，信号量的使用，等等
• 数据库管理系统的使用
• 参照完整性,存储过程
• 连接类型
• SAN，NAS，直接地
• 物理属性
• RAID, Mirrored, etc.
• 被其它应用程序分享

?(|kQ Rc8Zu^A0
)l w.kgq0 当评估基础设施相关的物理层和可测量行问题时，我们也需要考虑某些要素的性质。一些机构中的元素是非线性的。拥有相等数量的资源不一定获得相应的性能。
N&|
z!|,K\2Dd*qR051Testing软件测试网[ Mn%y8u
 查看系统中的CPU使用情况。如果单处理器可以支持100用户，这样的话，是否再加一个处理器就可以支持200用户？不是这样的，这是不会发生的。两个处理器还要消耗部分能力用于处理它们之间的交互。添加第三个处理器可以进一步增加处理用户的数量，但同时降低效率。最后添加另外的处理器可能造成负面影响，进一步减少所支持的用户数量。51Testing软件测试网)zqY ic7SY
一个简单的CPU可扩展性的例子如下：

Figure 351Testing软件测试网T$T*HM3VM(XQ
g

51Testing软件测试网/r|A3w:h_Qo,H
51Testing软件测试网P$zU0xX#W6d;Hk
51Testing软件测试网@)_}2z%Pb#nr
e5A5A
下面介绍架构和基础设施的最后一个元素–网络。 网络是一个类似管道系统的复杂的系统。小管道连接到大管道,大管道连接到更大的管道。信息从小管道流向大管道然后再返回。甚至可能你有一些控制点(阀门？)来管理流向。
:v$kOL'~K!G0How does the network in the test lab compare to the production environment? As with every aspect of the architecture and infrastructure, there are several key issues that need to be addressed, as shown in figure 4.

 测试环境的网络如何与生产环境的进行比较呢？有几个关键的问题需要解决，如下：

G*l*Iu$fHd0

网络类型和配置 &mA9X"ih0 LAN, WAN, Internet,等等. 单独的或者共享的网络? 物理元素数量51Testing软件测试网l'af{6_ | ZI m Bridges, routers, gateways, etc. Non-application elements (firewalls, etc.) 带宽配置 |&w,?0B3Tc6Tt0 Star Bus Ring Hub or switched Etc.

 51Testing软件测试网fl&w9S(Y,Jq4l

Figure 4

O2b4}.b-^VD*s6yX5WMm051Testing软件测试网%P Vl EP
有两个途径评判系统和应用程序的可扩展性：51Testing软件测试网 MhZ%` DrB

• 当前架构缩放比例（规划方面的能力）
• 测试瓶颈是为了防止系统处理过大的工作量
• 测试系统的功能和特性被忽视,但是它会随着系统的增长而变得重要。
• 一旦当前系统达到有效容量，架构要自我调整。
• 为了执行测试，需要额外的架构和设施

5C P)g
?E0 由于各种类型的数据需要相当数量的架构和设施来模拟真实的目标环境（还有支持负载生成工具的环境）,大多数组织不能承受这些费用，这使我们又想到了外推法。51Testing软件测试网j9x3Xt&L
{

'dW8?QF_3D0R7f0 外推法是一种趋势预测的方法。随着被测试系统的负载逐步递增,数据库或网络也呈现相当的递增级数。性能测试团队根据绘制的趋势图表51Testing软件测试网/b-_L7p/{8w:|e
51Testing软件测试网j G'_?)Q-\:i%E
 问题是这种方法准确吗?外推法本质上是一种系统功能的线性推测。正如我们早期关注的可扩展问题，系统和应用程序在很多关键方面的趋势并不是线性的。51Testing软件测试网6oM7G]G

如果你的环境不是很均衡的，预测将会更加不准确。51Testing软件测试网o `:sNHU

/TX$m.\B]9h p B5c0 当这种技术应用到复杂的系统或应用程序时具有很大的潜在隐患。所以最好在可行且存在的架构或者设施中进行测试，而不是靠推测。

51Testing软件测试网)ZkVur Q'G1UVo

 外推法可以应用到很有限的情况下。如果性能只是关注单一组件或者系统方面。

而且该部分具有线性特性，只有这样该方法才能应用。51Testing软件测试网2{Q;p
hnK"sR

• 举例来说，评估数据库一系列事务消耗空间数量是一个线性行为。数据的分散可能或可能不使用线性算法。如果只关注磁盘的使用情况，那么每个事务消耗的存储空间是有具体数量的。

正如我们所见，架构和设施需要的性能测试是非常难以确定和管理的。甚至还有很多问题这里都没有涉及到，如果在测试实验室中测试系统失败了，在生产环境中也可能失败。
-jkV!{/d0
%G9B%^4AHI^]0选择测试类型51Testing软件测试网)C(]3|$LVqx"An
51Testing软件测试网.l[8Y s ^-O7RQU8Y
  当在确定哪种性能测试类型之前，我们必须首先知道我们需要解决什么问题。一旦你知道测试的总体目标和对问题有充分的来哦接，你就可以选择一个测试或者一系列的测试去审查那些问题。

通常地，我盟把性能测试分为3种普遍的类型：

• 基于负载源或类型的测试
• 基于我们想测量什么（测量目的）的测试
• 测试系统压力或发现瓶颈

上述列出的这些分类都有多种子分类和变种。我不会尝试去涉及每个可能的变种，但是会关注每个类型的子分类。那些测试可以回答我们在本系列之前部分讨论的大多数问题。下面让我们来看看具体内容。
3h$LlF0V1@ U5OR051Testing软件测试网D,x6B5R
sP _
大部分性能测试是由一种或多种测试类型（一个或多个分类）组成的。

51Testing软件测试网ld.|;rS {_!D

基于负载源或类型的测试

• 基于使用的测试：根据业务概况，在测试环境下以同样的方式实际运行系统。
• 用户场景：一系列真实的活动，取决于用户如何实际操作系统。功能测试人员使用标准测试用例设计技术设计常规测试。就如边界值法，一个功能对应一个测试用例。这常常用在各个事务之间有复杂的交互的场景。
• 基准测试：使用标准的工作量，而不是用户指定的，当很难确定系统实际上如何被使用时，大多数的商业基准通过TPC.org公布。
• 负载变化和活力测试：在模拟的真实环境中，观察负载在一段时间内的变化，以及相应的各种性能指标的变化。模拟系统需要在早期部署好。
• 可扩展性测试：通过增加每个用户的工作量，并发用户数量，数据库的大小，连接到网络设备的数量等等，考察系统增长能力(能否适应这些增长)
• 正如我们之间提到的，有两种可扩展类型。在当前架构和基础设施达到满负荷下扩展；自行的扩展架构和基础设备。
• 特定组件测试：考察性能和系统组件的健壮性。在被测组件准备好就可以进行测试，不必等其它组件。
• 校准测试： 检查系统是否符合委托的标准。

基于测量目的的测试51Testing软件测试网)oXOJ)gKO

• 响应时间测试：测量系统完成一个或一组任务的时间
• 响应时间通常关注使用者和客户的感受。
• 一些响应时间测试可能是由组件和SLA驱动的，比如测试第三方接口(比如电子商务程序的信用卡处理过程)
• 吞吐量测试：测量一个单元的吞吐量，比如系统中一个点会通过多少流量，在指定的时间內或者指定的压力下完成多少任务。
• 可用性测试：记录系统或组件运行时间的百分比
• 一个通用的行业参考，被称为5个九– 99.999%。这是一个可用性和可靠性都相当高的水准。
• 资源利用测试：监视系统资源使用的情况，如内存，CPU，线程等等。
• 出错率测试：有些地方也称为“健壮性”。测量当系统处于正常或过重负载情况下的功能出错率。还有当负载增加或者改变时可能引起错误的增加。
• 系统和应用程序是否可以处理错误的增加？如果用户不能使用功能，再快的响应和再大的吞吐量也是没用的。

测试系统压力或者发现瓶颈51Testing软件测试网#n4Dx!CG$P

• 斜坡式测试：对于这个概念有几个解释。
• 测量启动进程所需的时间。
• 比方说,一个未工作的网络设备在需要它工作而被启动时，它必须在50毫秒内开始工作。
• 术语斜坡式测试也可以被解释：在系统开始运转期间， 逐渐地增加测试负载而不是突然增加到最大负载以避免系统崩溃。
• 在极端情况下，可能出现在系统上的活动突然激增。这方面的一个例子是如果用户尝试登录崩溃后重新回复的系统，突然增加的活动可能再次导致系统崩溃。
• 持续和耐力测试：有人把这个当作可靠性测试的一部分。在测试环境下持续运行被测系统一段时间(几天或者几周),这样可以用来发现那些需要运行长时间才会出现的bug，比如内存泄漏。这对于那些不间断的系统特别重要，比如电子商务系统或自动柜员机。
• 热点测试：关注系统中指定的，有限的一部分以确定该部分是否是个薄弱点。
• 在一个应用程序的通常部分也能可能进行该类型测试。比如，待电子商务网站出售特殊时刻的礼品。可以预见在节假日会出现蜂拥而至的交易。然而目标系统应对这种情况是非常困难的。在母亲节，整个网站都处于活跃状态，但是在情人节，大多数活动都集中在单个产品区域（长茎红玫瑰和巧克力）。我们就可以在这些点设立“热点”进行测试。
• 钉子测试：在非常短的时间内使系统处于高负荷的工作状况下，用于确定系统如何处理突然增加的高负载需求。此测试用以验证系统能够应对快速的重大变化以及改变资源的使用。比如，使用负载均衡。
• 这种测试类型的有效性取决于被测系统的类型
• 主机，局域网/广域网和局域网类型的程序对连接到系统中的设备数量只有相当有限的潜力。
• Web和 基于局域网应用程序拥有几乎无穷尽访问的可能。某些安全攻击，拒绝服务攻击和分布式拒绝服务攻击是极端的由黑客引起负荷的例子。
• 断点或故障测试：增加负载直到系统出现故障或达到测试环境负荷极限。它也许不可能生成足够的负载以使系统发生崩溃，取决于负载生成的用户（授权的数量是个关键因素）
• 这个测试对于验证系统工程师是否已经对系统进行了安全设置有帮助,比如应用程序阀值。这些内在的控制可以防止应用程序或系统发生崩溃。
• 死锁测试：运行高容量测试（可能来自不同应用程序源）来发现系统中是否存在资源竞争，比如多请求试图同时访问同一数据库，并造成由于区域冲突而被系统锁定用户请求，比如数据库记录锁定。
• 运行退化模式测试：在不是所有资源在工作的情况下，确定系统是否仍能提供预期的服务水准。（一个降级模式测试的例子是在服务器集群中故意断电一台服务器，并试图继续正常操作。）

使用哪种类型的测试取决于早期确定的性能目标和潜在问题存在于应用程序，系统或者架构中的位置。测试的压力类型通常与测量类型结合。我们使用业务跟踪（在本系列第三部分介绍）来创建我们需要的应用程序或系统的活动类型，进而评估出那些我们感兴趣的区域。51Testing软件测试网V[/Ht4d

如果我们对以用户的角度看端对端的响应时间感兴趣，我们应该运行基于使用的测试并结合测量类型。（测量CPU，内存使用，线程等等）。当我们不知道问题将发生的位置时，我们需要结合几种测试类型。如果我们发现响应时间的异常，我们需要采取措施帮助性能测试团队的技术人员定位和解决问题。51Testing软件测试网@M"UWV
tI

.H#IpU-e(o7N/S0 我们已经了解性能测试过程，性能目标，以及已经涉及了架构和基础设施问题，我们需要关注测试的内容。在本系列的下一部分，我将介绍确定负载（操作跟踪） 和 测试中的测量。

原文地址:http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=COL&ObjectId=14891&tth=DYN&tt=siteemail&iDyn=251Testing软件测试网#m#wG2j)U6u

  本文章由本人翻译供大家学习之用，版权归原作者所有。原作者如有任何异议，请通知本人删除,且未经书面授权许可，任何网站或个人不得转载。另由于本人翻译水平有限，很多不当之处请见谅。51Testing软件测试网-^ N ?.A \_G9^a