明确了具体的性能要求后,可以开始进行javascript:tagshow(event, '%B2%E2%CA%D4');" href="javascript:;" target=_self>测试,确定应用程序是否满足这些要求。性能测试假定应用程序稳定、可靠地运行。因此,在测试中消除尽可能多的变数很重要。例如,代码中的错误可以导致出现性能问题,甚至掩盖性能问题。要精确地比较不同性能测试的结果,应用程序必须正确地工作。如果调整过程修改了组件的实现,则重新测试应用程序的功能尤其重要。应用程序必须通过功能性测试后才可以测试性能。除了应用程序更改外,硬件、网络通信量、软件配置、系统服务等诸多方面也会发生意外的更改。控制应用程序更改很重要。 测量性能 要正确地调整性能,必须准确完整地记录每次测试的结果并进行维护。记录应包括:
这些记录不仅指示应用程序是否达到性能目标,而且有助于识别未来性能问题的潜在原因。 性能调整是与性能管理相关的主要活动。当性能降到最基本的水平时,性能调整由查找和消除瓶颈组成,瓶颈是在服务器中的某个硬件或软件接近其容量限制时发生和显示出来的情况。 在开始性能调整循环之前,必须做一些准备工作,为正在进行的性能调整活动建立框架。您应该:
建立了性能调整的边界和期望值后,可以开始调整循环,这是一系列重复的受控性能试验。 调整循环重复以下所示的四个调整循环阶段,直到获得在开始调整过程前建立的性能目标。 调整循环 收集收集阶段是任何调整操作的起点。在此阶段,只是使用为系统特定部分选择的性能计数器集合来收集数据。这些计数器可用于网络、服务器或后端数据库。 不论调整的是系统的哪一部分,都需要根据基准测量来比较性能改变。需要建立系统空闲以及系统执行特定任务时的系统行为模式。因此,可以使用第一遍数据收集来建立系统行为值的基准集。基准建立在系统的行为令人满意时应该看到的典型计数器值。 注意 基准性能是一个主观的标准:必须设置适合于工作环境且能最好地反映系统工作负荷和服务需求的基准。 分析收集了调整选定系统部分所需的性能数据后,需要对这些数据进行分析以确定瓶颈。记住,性能数字仅具有指示性,它并不一定就可以确定实际的瓶颈在哪里,因为一个性能问题可能由多个原因所致。某个系统组件的问题是由另一系统组件的问题导致的,这种情况也很普遍。内存不足是这种情况的最好示例,它表现为磁盘和处理器使用的增加。 以下几点来自“Microsoft Windows 2000 资源工具包”,提供了解释计数器值和消除可能导致设置不适当的调整目标值的错误数据或误导数据的指南。
配置收集了数据并完成结果分析后,可以确定系统的哪部分最适合进行配置更改,然后实现此更改。 实现更改的最重要规则是:一次仅实现一个配置更改。看起来与单个组件相关的问题可能是由涉及多个组件的瓶颈导致的。因此,分别处理每个问题很重要。如果同时进行多个更改,将不可能准确地评定每次更改的影响。 测试实现了配置更改后,必须完成适当级别的测试,确定更改对调整的系统所产生的影响。在这一点上,这是确定更改是否有如下影响的问题:
如果幸运,性能提高到预期的水平,这时便可以退出。如果不是这样,则必须重新逐步进行调整循环。 提示 可以从监视日志文件(可导出到 Microsoft Excel)和事件日志中获取测试所产生的监视结果。 测试时务必要:
在每遍测试中,运行一系列完全相同的性能测试;否则,无法分辨不同的结果是由于测试中的改动还是应用程序更改造成的。使尽可能多的性能测试操作自动进行有助于消除因操作者造成的差异。 其他表面上是良性的因素影响性能测试的结果,如应用程序在测试开始前运行的时间。正如冷的汽车引擎与热引擎的性能不同,长时间运行的应用程序由于内存碎片这样的因素,其性能可能与刚启动的应用程序不同。 定义性能测试性能测试期间,测量和记录性能目标中指定的度量标准值。达到全部性能度量标准(如思考时间、事务混合等)很重要。在这些约束下,测试应尽可能实际。例如,对应用程序进行测试,确定它在许多客户端同时访问它时的性能。多线程测试应用程序可以用可复制的方式模拟多个客户端,每个线程表示一个客户端。如果应用程序访问数据库,则数据库应包含实际数目的记录,并且测试应使用数据项的随机(但有效)值。如果测试数据库太小,数据库服务器的缓存效果将产生不符合实际情况的测试结果。如果输入或访问数据的方式不符合实际情况,则结果也可能不符合实际情况。例如,在主键上按字母顺序创建新数据是不太可能的。 通常,测试装置必须接受用户指定的输入参数,如事务混合、思考时间、客户端数目等。然而,测试装置本身可以规定创建实际的随机数据的规则。 创建了驱动应用程序的测试装置后,应该将所有运行测试的不变条件记入文档。最起码,这些条件应包括运行测试装置所需的输入参数。另外,应将如何设置运行测试的数据库记入文档。说明中应指定数据库不应包含前一遍测试所做的更改。说明中还应指定用于测试的计算机配置。在不同于应用程序所在的另一台计算机上运行测试装置,因为这样设置更接近生产环境。 确定基准性能确定了性能目标并制定了性能测试后,运行一次测试以建立基准。验证环境与生产环境越相似,应用程序部署后的性能令人满意的可能性就越大。因此,一开始有一个符合实际情况的验证环境很重要。 幸运的话,基准性能将符合性能目标,并且应用程序不需要任何调整。但更可能的情况是,基准性能不令人满意。然而,记录初始测试环境和基准结果可以为调整工作提供坚实的基础。 压力测试压力测试是性能测试的一种专门形式,它与其他工程领域的破坏性测试相似。压力测试的目的是使应用程序产生故障,通过增加处理负载使其超过性能的降低,直到由于资源饱和或发生错误而使应用程序开始出问题。压力测试有助于揭示细微的错误,这些错误本来要到部署应用程序时才会被发现。由于此类错误通常是因设计缺陷所致,压力测试应该早在开发阶段便在应用程序的每个区域上开始进行。在其源头修复这些细微的错误,而不是忽视这些错误,直到它们可能在应用程序中的其他位置表现出症状时才修复它们。 解决性能问题通常可将性能问题归结于不止一个因素。因此,查找性能恶化的解决方案与进行科学实验极为相似。科学实验传统上遵循一个分六步进行的过程,包括观察、初步假设、预测、测试、控制和结论。结论由该过程积累的最佳证据集合所支持的假设组成。可以遵循同样的过程来解决性能问题。 当观察到 ASP 应用程序的性能比期望的低时,您假定 ASPProcessorThreadMax 元数据库属性设置得太低。当“ASP 排队请求”性能计数器上下移动,并且处理器的运行效率低于 50% 时,可能会发生这种情况。您预测增加 ASPProcessorThreadMax 元数据库属性的数值可以提高性能。 活动线程设置现在已经变成控件。一次仅进行一个设置更改,直到观察到满意的性能改变。如果在几次调整 ASPProcessorThreadMax 元数据库属性之后获得了更令人满意的性能,则结论是某个属性设置与所有当前变量(所需内存的总量、正在运行的应用程序数、已升级的软件等)组合,可提供最佳服务器性能。变量中的任何更改就会形成进一步的实验。 |
文章来源于领测软件测试网 https://www.ltesting.net/