IBM Cognos 最佳实践: 设计针对 IBM Cognos BI 的成功的性能和可伸缩性测试

设计针对 IBM Cognos BI 的成功的性能和可伸缩性测试的高级指导。

Mark Pilon, 性能测试架构师, IBM

Mark Pilon 是一位主要关注于 IBM Cognos BI 和 IBM Cognos TM1 的性能测试架构师。在过去 10 年中,他主持了许多大型项目,撰写和研究了几篇公开发表的论文,帮助许多 IBM 大客户解决了各种可扩展性、性能、稳定性和测试驱动问题。



2012 年 4 月 16 日 (最初于 2009 年 7 月 20 日)

免费下载:IBM® Cognos® Express V9.5 或者 Cognos® 8 Business Intelligence Developer Edition V8.4 试用版
下载更多的 IBM 软件试用版,并加入 IBM 软件下载与技术交流群组,参与在线交流。

简介

目的

本文的目的是帮助指导性能评估人员如何针对 IBM Cognos Business Intelligence (BI) 设计一个成功的性能、可伸缩性和稳定性测试。它从很高的角度阐释了性能、可伸缩性和稳定性的一些关键原则。

适用性

本指南针对的是 IBM Cognos BI,但其中的概念也可适用于很多 “多用户”、“多服务器” 软件应用程序。它的出发点是为了给那些评估是否可以将 IBM Cognos BI 作为满足其 BI 需求的供应商的潜在客户提供方便。

例外和免责

本文只是一篇指导性文章,将介绍可能会影响实际测试范围的一些因素,比如时间限制、覆盖面 “扩展”、硬件问题等。

还有一点需要指出的是,本文中的示例并非实指 IBM Cognos BI 产品历史或当前的可伸缩性,纯粹用于演示之目的。

假设

本文假设硬件的稳定性不存在问题。


验证软件性能

对于使用了业务智能的很多组织,软件性能可被认作是验证 IBM Cognos BI 产品是否满足特定的性能条件,比如 “在一个小时内执行 1000 个排定的报告” 或是 “在同时有 100 个用户的情况下,保持平均事务时间 5 秒以下”,或是更为简单的 “与遗留 BI 软件一样快”。

最突出的条件通常取决于一个人在一个组织内担任的职能:

  • 业务分析人员通常会关注完成某些任务所花时间。
  • 服务器管理员通常会关注软件需要多少服务器资源。

单用户性能测试

从业务分析人员的角度,这种测试通常最为简单,需要执行的外部工具的数量也最少。此测试的要点是测量软件对最终用户操作的响应性。

执行这种测试的业务分析人员应该拥有以下工具:

  • 一个测试计划,概括出要测量的用户手势 (user gesture)、预期结果或成功标准。
  • 一种以秒为单位的准确测量用户操作的方法(参见附录 A)。
  • 一个准确记录和发布测试结果的地方。

服务器管理员通常会使用任一单用户测试来收集应用程序在相对安静情况下消耗的服务器资源的基线。服务器管理员应该在进行业务分析人员测试期间监视服务器上使用的服务器资源。最受人们关注的服务器资源有三项:内存、中央处理器 (CPU) 以及网络使用。参见附录 B,获得用来监视服务器资源的有用工具的简单列表。

多用户性能测试

多用户测试需要进行大量的计划,并提供完成这一工作的恰当工具。执行此类测试的性能团队应该提供以下可用工具:

  • 一个测试计划,概括出要测量的用户手势以及预期结果或成功标准。
  • 一种以秒为单位的准确测量用户手势的方法。该测试需要使用用户负载生成工具(参见附录 A)。
  • 一个准确记录和发布测试结果的过程。
  • 帮助诊断复杂问题的主题专家 (Subject Matter Experts, SME)。比如,进行 SQL 查询调优的数据库管理员或应用服务器调优方面的专家。

服务器管理员应该为其性能团队提供必要的访问权限,或是在业务分析人员进行多用户测试期间,监视服务器上使用的服务器资源。最受关注的服务器资源仍是以下三项:内存、CPU 和网络使用。对于多用户测试,服务器管理员应该与性能测试人员直接合作,确保执行测试期间运行的监视服务器资源的命令是正确的。资源监视应该与多用户测试同步启动或停止,否则将多用户测试与资源使用情况联系在一起时会十分困难。参见附录 B 获得用来监视服务器资源的有用工具的简单列表。

那么接下来可能提出的问题就是 “没错,应该监视内存、CPU 和网络使用情况,但是我究竟要从中寻找什么信息呢”。通常来讲,服务器资源可以接近极限,但不会超过极限,以致于拖累性能。比如:

  • 假设 CPU 接近于 99-100% 的使用率。如果服务器专供正在测试的软件使用、CPU 排队长度并未增长、用户的终端体验也恰在成功条件之内,那么这种使用率可能不存在问题。
    很高的 CPU 使用率,如果未在所有 BI 应用程序层服务器之间进行均衡,那么 BI 分派器提供的负载分配可能会是不均衡的,可以通过调整 BI 处理容量来解决这个问题。
  • 假设物理内存全部消耗完毕并且虚拟内存使用非常高。如果内存耗尽的同时最终用户交易时间受损,这就有可能导致严重问题。如果有额外的内存可供使用,那么将这些内存添加到系统中通常就能够解决此问题。而且,关闭掉服务器上的一些非必要程序也可以释放一些额外的内存资源。
  • 假设网络使用率是 100%。这就是一个问题,因为网络现在已经成为了系统的瓶颈。

最后强调一点,生成负载的计算机也有可能会出现内存、CPU 和网络资源不足的情况。对该计算机保留一个轻量的资源监视器会十分有用,这样做可以确保负载生成器不会成为瓶颈。

多用户灵敏度测试

灵敏度测试关注的是由 BI 系统或社区的某个组成部分完成的工作如何影响 BI 系统或社区的其他组成部分。用于性能测试的工具在这里同样适用,但用途不同。

例如,假设此 BI 社区是全天候工作的,并在工作日期间,在交互用户使用的同一台服务器上定期执行非交互式报告或批量报告。

然后问题出现了... 非交互报告对交互报告用户的性能产生了什么影响,交互报告对非交互报告用户的性能产生了什么影响。二者均有重要的期限而,不能被另一方拖延。灵敏度测试可以解决这个问题。

这里的关键是:要先单独运行每个方面来获得准确的基线。这就意味着:通过使用这个例子,交互用户测试是在真空中运行的。同样地,非交互测试也可以在不受交互报告用户干扰的情况下运行。

之后可运行后续操作,将交互和非交互任务包含其中,从而测量它们的相互影响。可以通过控制交互以及非交互任务的相互影响程度来突出某种趋势。以如下的灵敏度测试为例并测量性能:

  • 完全的非交互基线
  • 完全的交互基线
  • 具有完全交互的完全非交互
  • 具有完全交互的 50% 非交互
  • 具有 50% 交互的完全非交互

由于百分比是可以变化的,这类的灵敏度测量可以从性能的角度给出不同 BI 活动如何相互影响的指示。

根据目标的不同,灵敏度测试可以也非常不同,但是原理是相同的,先分别测试,然后把它们联合起来。


验证软件的可伸缩性

解决方案测试的另一个方面是伸缩性测试。伸缩性测试通常可以解答完成初始性能测试后的人们经常提出的一些问题。比如:

  • 当我向此系统添加更多用户时,将会发生什么?这些会如何影响我目前用户的性能?
  • 如果我向此系统添加更多的服务器来托管软件,会发生什么?我的用户会看到我所做的改进吗?
  • 如果我想使用户社区加倍,并且只是简单地使支持报告服务的硬件加倍,那么用户还能否体验到相同的性能?

以下三个章节将总结测试这些问题的方法,它们将分别概括可伸缩性的三个原理。

可预测的可伸缩性

可预测的可伸缩性可定义为一种能力,它向动态硬件环境添加额外用户,并且可以获得性能上可预测的、成比例的线性变化。比如,如果客户使系统上的用户数量加倍,他们可能会发现,用户的终端体验会降低 50%。相反,如果他们将系统上的用户数量减少一半,则可能让最终用户性能增加 50%。

测试可预测的可伸缩性的一般步骤为:

  • 在特定硬件上配置软件应用程序。
  • 在给定的时间框内对系统运行一个 “少量” 负载的负载测试,比如为一个较小的服务器提供 20 名用户。然后记录最终用户的响应性和服务器资源信息。
  • 在给定的时间框内对系统运行一个 “中等” 负载的负载测试,比如为一个较小的服务器提供 40 名用户。然后记录最终用户的响应性和服务器资源信息。
  • 在给定的时间框内对系统运行一个 “大量” 负载的负载测试,比如为一个较小的服务器提供 60 名用户。然后记录最终用户的响应性和服务器资源信息。
  • 检查和核对这些数据。最终用户响应性和服务器资源应该以一种可预测的方式进行增长。

这并不是说在将用户添加到静态系统中时,IBM Cognos BI 会以线性方式进行伸缩。有一些调优设置可以提供帮助。但是,如果系统已经遇到特定的静态资源瓶颈,那么向系统添加或减少用户可能会导致遗留用户体验发生可测变化。

可预测的可伸缩性示例

我们进行了以下这样的假设:BI 社区在未来两年内会增长三倍。在如下所示的图表中,平均报告执行时间为 Y 轴,活动的用户社区为 X 轴。对于 20 名活动用户,平均报告执行时间为 5.5 秒。由于额外向社区添加了 20 和 40 名用户;平均报告执行时间分别提高到 9.5 秒和 18 秒,如下图所示。

图 1 的柱状图显示,随着添加到系统中的用户数量的增加,报告执行时间也随之增长
图 1 的柱状图显示,随着添加到系统中的用户数量的增加,报告执行时间也随之增长

虽然当前的服务水平推测仍在可接受的参数之内,但当前的用户社区未必会接受近三倍的降级。对此次测试的资源使用数据的进一步分析显示,服务器仍具有足够的 CPU 和内存可用。这一发现允许我们做出以下假设:随着更多用户的添加,IBM Cognos 报告服务对请求进行了排队,而这会导致报告执行时间的延迟。

如下的图表显示了在向此环境中添加了更多的 IBM Cognos 报告服务之后,平均报告执行时间仍为 Y 轴,活动的用户社区仍为 X 轴。对于 20 个活动用户,平均报告执行时间为 5.5 秒。由于又有 20 和 40 个用户加入到社区中来;平均报告执行时间分别提高到 6.5 秒和 10 秒,如下图所示。

图 2 的柱状图显示,在将用户添加到提供额外的 IBM Cognos 报告服务的系统中时,报告执行时间减少了
图 2 的柱状图显示,在将用户添加到具有额外的 IBM Cognos 报告服务的系统中时,报告执行时间减少了

现在,由于额外的报告服务消耗了更多的内存和 CPU,这致使服务器资源使用率更高;换来的是增长的用户社区对遗留用户的影响减小。

在这两种情况下,这种可预测的可伸缩性测试让用户能够量化向静态系统添加用户对总的最终用户体验带来的影响。

水平的可伸缩性

水平的可伸缩性可定义为向产品环境添加硬件的能力,它保持系统用户数量不变,并希望能够看到性能的提升。比如,如果一个客户在使可用硬件数量加倍的同时又能保持系统用户数量不变,那么应该可以获得 50% 的性能提升。

测试水平可伸缩性的一般步骤:

  • 在一个特定的 “小型” 硬件配置上,比如单一一个服务器,配置软件应用程序。再配置另外两个一摸一样的服务器但让它们保持空闲。
  • 在给定的时间内,在一台服务器的系统上运行负载测试,比如为一台服务器提供 80 名用户。然后记录最终用户的响应性和服务器资源信息。
  • 从多个用户角度(在本例中为 80 名用户)进行测试,在给定的时间内,在两台服务器的系统上运行相同的负载测试。然后记录最终用户的响应性和服务器资源信息。
  • 从多个用户角度(在本例中为 80 名用户)进行测量,在给定的时间内,在三台服务器的系统上运行相同的负载测试。然后记录最终用户的响应性和服务器资源信息。
  • 检查和核对这些数据。最终用户响应性和服务器资源应该以一种可预测的形式降低。

水平可伸缩性举例

我们做出了以下假设:BI 社区开始对 BI 性能不满,因为有一组新用户现在正在使用 BI 应用程序。添加更多硬件有可能帮助解决问题,但是能帮到何种程度呢?

遵照水平可伸缩性的建议,可以针对此场景执行一次测试。简化的结果显示在如下所示的柱状图中,其中 Y 轴表示平均报告执行时间,X 轴表示应用服务器数量。单应用服务器的平均报告执行时间为 30.3 秒。随着另外一个和两个应用服务器添加到此环境中来;平均报告执行时间分别减少到 17.1 和 9.5 秒。由于柱状图显示了线性改进;硬件的添加看似能提供所需的容量,从而将最终用户体验提升到一个用户更能接受的级别。

图 3 的柱状图显示,随着更多应用服务器的加入,报告执行时间呈线性减少
图 3 的柱状图显示,随着更多应用服务器的加入,报告执行时间呈线性减少

测试结果显示,如果向用户社区保持恒定的系统添加硬件,可使 IBM Cognos BI 应用程序级可用的硬件资源有所增加,并能增加用户体验和获得性能方面的一个可预测的增长。

因此,水平可伸缩性测试让用户能够量化向静态用户社区添加硬件对总的最终用户体验带来的影响。

垂直可伸缩性

可将其定义为向产品环境中添加硬件、向环境中添加适当数量的用户并获得相同级别的性能的一种能力。比如,如果一个客户让硬件数量加倍,那么他们就可能需要使用户数量加倍,然后才能维持相同的性能。

测试垂直可伸缩性的一般步骤如下:

  • 在使用特定的 “小型” 硬件配置(比如一台服务器)的情况下配置软件应用程序。再配置另外两台一摸一样的服务器,但让这两台服务器保持空闲。
  • 在给定的时间内,在一台服务器系统上运行负载测试,比如为一台服务器提供 40 名用户。然后记录最终用户的响应性和服务器资源信息。
  • 运行另一个负载测试,但成比例地提高用户负载和服务器,比如为两台同样的服务器提供 80 名用户。然后记录最终用户的响应性和服务器资源信息。
  • 运行最后一个负载测试,并再次成比例地提高用户负载和服务器,比如为两台同样的服务器提供 120 名用户。然后记录最终用户的响应性和服务器资源信息。
  • 检查并核对数据。最终用户响应性和服务器资源应保持相对平稳。

垂直可伸缩性举例

我们做出以下假设:BI 社区在不久的将来会增长三倍。当前的社区有一个服务水平协议 (Service Level Agreement, SLA),最终用户性能提升的倍数不能降低,而这就带来了问题,因为可预测的可伸缩性测试的结果显示,性能应该呈线性增长。

让硬件数量增长三倍来匹配用户社区的三倍增长可以缓和这个问题。遵循上述的垂直可伸缩性测试的建议,可以执行一个测试来模拟这种场景。

下面的柱状图中的 Y 轴为平均报告执行时间。三个柱体(从左到右)分别表示:在 40 个用户使用一台应用服务器时,报告执行时间为 30.3 秒;在 80 个用户使用两台应用服务器时,报告执行时间为 32.1 秒;在 120 个用户使用三台应用服务器时,报告执行时间为 30.7 秒。这些简化的结果显示了执行时间相互接近的性能特征,并且硬件的增加似乎能够提供将最终用户体验维持在更容易接受的级别的必要能力。

图 4 的柱状图显示,随着用户和应用服务器的增加,报告执行时间是保持一致的
图 4 的柱状图显示,随着用户和应用服务器的增加,报告执行时间是保持一致的

验证软件的稳定性

对产品性能和可伸缩性同样重要的还有软件的稳定性原则。软件稳定性是指:在很长一段时间内在没有宕机、没有对用户社区的干扰或管理员的干涉的情况下,软件对给定工作负载的支持能力。

稳定性测试通常可以回答人们在完成性能和可伸缩性测试后提出的一些问题。比如在 BI 系统负载过轻的情况下:

  • BI 系统是否能维持最终用户的响应性和吞吐量?
  • BI 系统是否显示了任何显著的内存增长(比如内存泄漏或内存碎片)?
  • BI 系统是否能随时间推移有效均衡负载?
  • 任何 BI 过程是否意外终止?
  • 用户社区是否开始体验到意外行为,比如错误?

了解典型的用户社区

设计一个好的稳定性测试的一个关键是:要了解用户社区的特征,以及 “典型的一天” 是如何度过的。下表将典型的用户社区细分成了 Report Consumers、Lightweight Reporting、Heavyweight Reporting 和 Data Analysts。

Report Consumers 组查看所保存的报告输出,这部分占整体社区的 25%。这个组通常会以定期或批量的模式使用连夜执行的报告。

Lightweight Reporting 组以交互方式对业务需求进行报告,这部分占整体社区的 40%。这个组要求对整个工作日内可能更改的数据进行实时报告。

Heavyweight Reporting 组对更高级别的需求进行报告,这部分占整个用户社区的 30%。这个组通常会使用大量的数据,因为它们需要有关整体业务的信息。

用户社区的最后 5% 由执行特别的业务数据分析的 Data Analysts 小组组成。这个组通常由高级用户组成,他们使用 Analysis Studio 或 Business Insight Advanced 这样的工具对数据进行具体的深入研究,发现社区数据的特定趋势。

这种划分如下表所示。

表 1. 一个典型 BI 社区的组成部分
描述百分比
Report Consumers查看保存的报告输出25%
Lightweight Reporting以交互方式对业务需求进行报告40%
Heavyweight Reporting以交互方式对更高级别的业务需求进行报告30%
Data Analysts特别的业务数据分析5%

了解这些信息之后,就可以基于上面的四个组对具有代表性的测试进行规划,做定期的/批量报告,提供有关 BI 系统在负载下的稳定性的有用信息。

基于用户社区设计稳定性测试

为了定义能够与之前定义的 BI 社区内的角色相对应的典型测试用例,需要创建测试用例来实现以下操作:

  • Report Consumers 将查看所保存的报告输出。
  • Lightweight Reporting 用户将以交互方式在 Cognos Viewer 或 Business Insight 内执行轻量级报告。
  • Heavyweight Reporting 用户将以交互方式在 Cognos Viewer 或 Business Insight 内执行重量级报告。
  • Data Analysts 将使用像 Analysis Studio、Query Studio 和 Business Insight Advanced 这样的 BI 工具与数据进行交互。

然后这些将按定义好的百分比组合成为一个测试场景。再加上有代表性的数量的以非交互方式执行的定期报告,这就形成了稳定性测试的主干。

稳定性测试的运行时间的长度取决于很多因素。如果时间足够,可以将测试的时间安排为运行数天或数周。如果时间不够,那么就需要密切地分析测试工件内的趋势,以期发现持续运行测试会导致 BI 用户社区出问题的地方。但底线是,稳定性测试执行得越长,发现潜在问题的机会就越大。

可能影响发现这些问题的其他因素包括用户负载和负载均衡。如果系统没有负载均衡,或者如果在各服务器上没有足够多的用户负载来充分执行测试,那么就更难以发现潜在问题。如果服务器被迫接近其能力的极限,则更有可能发现潜在的问题。

监视稳定性测试

在某些方面,监视稳定性测试可能会比较容易一些,而在另外一些方面,监视稳定性测试可能很困难。好的消息是测试运行的时间很长,因此更容易寻找如下问题:

  • 内存泄漏或碎片
  • 负载均衡问题
  • 网络带宽瓶颈
  • 最终用户性能的可能恶化
  • 随时间推移,由于到达或超过某些特定硬件或软件极限而发生的最终用户错误

为了收集这些信息,性能分析必须具有针对以下内容的历史视图的运行时访问权限:

  • 最终用户事务性能数据
  • 有关系统吞吐量(字节)和网络使用的数据
  • 最终用户体验到的错误
  • 系统资源使用,包括 BI 过程以及支持 BI 的软件过程,比如 Web 服务器和数据库
  • 软件日志

有了这些信息后,您的性能团队就可以展示观测结果,并基于测试期间发现的问题或看到的趋势(如果没有发现这些,极有可能导致用户社区出问题,比如负载不均衡或过多的内存增长)对 BI 社区进行预测。


通用的测试技巧

以下是一些通用而又简单的测试技巧,对设计和执行多用户测试周期的团队很有帮助。

一次只更改一个变量

尽量维护测试的科学性。在一个大型的软件环境中,一次只更改一个变量看起来十分耗时,但从长远考虑,这样做会节省时间。没有事情比一次更改了五个东西、已经看到性能的显著提升、但随后又不得不回溯所有这些更改来查找具体起因更糟糕的事情了。请确保为每个改变都明确建立了文档并记录了更改的原因。

做了更改后,建议回访至少两个数据点。理想情况下,这些数据点将是特定测试用例的高用户和低用户测试,这是因为某些更改可能会协助繁忙系统上的用户,却会阻碍不怎么繁忙系统上的用户,反之亦然。在建议进行更改,尤其是对产品环境进行更改之前,最好注意这一点。

执行测试之前最好重置尽量多的东西

由于测试结果相互比较,确保了每个测试均在同一点启动。例如,建议在整个软件系统重启、软件日志备份完毕以及服务器资源监视重启后再运行各性能或稳定性测试。

否则,因某些数据库连接已经建立、数据已经缓存、过程已经使用了更多的内存(因它们尚未清除来自之前会话的所有存储信息),之前的测试会能影响当前的测试。IBM Cognos BI 产品能够轻松地从命令行启动和停止,所以只要测试者拥有正确的权限,在每个测试前重置 IBM Cognos 产品相对而言不是那么重要。

使用与当前测试相同的时间表来执行基线测试

有时出现的情况可能是:测试人员使用了 6 个月前的结果作为当前测试的基线。硬件和配置相同,有什么问题呢?可能的问题是在该时间内服务器可能已经被修复、磁盘可能已经分区严重、运行新软件的服务器使用的 CPU 周期和内存在 6 个月前根本不存在。所有这些均能影响可伸缩性和性能数字。

要最大程度地降低此风险,在当前测试之前,总是需要重新运行基线,让基线和当前测试能够平等地受服务器上所有因素的影响。

尽量多地自动化

自动化可以解决两个问题:

  1. 测试可相对无看守运行,所以可将下班时间用于测试。工作时间则用在结果分析而不是运行测试上。
  2. 自动化将能确保每个测试或后续重新测试能以完全相同的方式运行。

通常而言,所有用于性能测试的软件工具均带一整套命令行工具,所以只需进行批量编程即可。

独占运行测试的硬件

如果得到一个意外结果,而后发现是因为有人在运行测试期间使用了同一台服务器,并自以为不会影响进行中的测试而执行了一些查询,那么没有比这更糟的情况了。在很多环境下,性能和可伸缩性测试人员需要与用户接受测试人员 (user acceptance tester) 共享硬件。与其他的组共同制定一个日程安排,以便让性能测试不会影响用户接受测试,反之亦然。

不要等到测试结束才分析结果

计划每天对测试结果进行分析。性能测试人员都希望早些发现问题以方便解决这些问题。在测试周期开始时解决问题要比在结束时解决它们更容易。这让测试人员能够为那些对测试过程感兴趣的管理层提供初步结果。有了这些结果以后,建议发送定期的状态更新,以便该测试所涉及的各方均能及时知道测试的当前状态。


为性能和可伸缩性测试创建一个测试计划

没有计划的测试将是麻烦的开始。这是一个常识但却十分有用。确保在测试之前所有的股东均阅读并签署了测试计划的意向书。

确保测试计划内包含了以下部分。

  • 目的:测试的目的。可以是一个非常简短的陈述,比如 “此次性能和可伸缩性测试用于测量 IBM Cognos BI 8.4 和 IBM Cognos BI 10.1 的当前产品运行版本之间的特定报告执行时间。还会测量特定最终用户体验用例以及这些用例期间的服务器资源消耗。”
  • 目标:为测试定义性能成功的标准。测试之前知道成功的标准极其有帮助。
  • 测试用例描述:性能测试的特定测试用例的完整描述。逐步写出每个测试的步骤。比如,为业务分析测试用例写出每次单击,用户或性能测试工具将如何执行。如果报告运行于 IBM Cognos BI 内,则需要描述所运行的报告类型、返回的行数等。这些都是与测试的成功标准有关的。
  • 测试执行矩阵:遵循上述步骤 2-3 中给出的测试描述并创建特定的测试用例,并在该用例中明确定义测试用例描述、用户数量以及用于该测试用例的硬件资源。这些都与测试的成功标准有关。
  • 可交付成果:测试所导致的交付成果及其到期日期的明确描述。
  • 日程安排:生成一个符合测试时间表的日程安排。在这个日程中包括脚本开发、自动化开发、软件配置等。测试周期的每一周至少要省出一天的时间,用该时间来创建文档并对测试结果进行最终分析。确保各方均同意这个日程安排。在其中放上一个提示,如果出现了对日程安排有消极影响的问题,应该尽快召集一次会议来讨论补救方法,比如延长测试周期或删除某些测试用例。

最后,在完成测试后,需要查看此测试计划,了解哪里地方还能进一步完善。记录下所有问题,并将解决方案融入到后续测试中。

根据测试的确切特征,可以加入更多的部分,但上述的这些部分是一个很好的基础。


交付结果

虽然立即着手立即开始测试更让人兴奋,但是最好在测试计划阶段花些时间来确定测试的可交付成果。有时候,回过头来收集丢失的信息并不是一个很好的选择。

以下就是需要针对可交付成果进行考虑的一些因素:

  • 如何将数据发布给各种受众?例如,管理层可能希望看到正式的 PowerPoint 类型的展示,而业务分析人员和服务器管理员则希望看到 Excel 格式的原始数据或 IBM Cognos BI 报告。
  • 每个受众需要什么信息?例如,管理层可能希望看到性能特征总结,业务分析人员希望看到每个任务花费的时间,而服务器管理员则想要看到各种测试能消耗多少服务器资源。 提前与公司的各股东进行讨论,以确保不会错过重要的东西。
  • 了解如何在同一个报告或图表中建立最终用户体验与服务器资源之间的关系。从这些功能强大的图表获得的数据中可以发现最终用户体验如何与服务器上的资源消耗相关联。例如,某个测试可能会显示最终用户时间上的极大性能恶化。不过,在将这个图表与显示内存消耗的图表相关联时,您就会发现服务器已经没有足够的内存来运行这么多用户了。

附录 A:测试最终用户事务并为性能和可伸缩性测试生成负载的有用软件

下面的软件(并非完整列表)是控制负载以及测试性能和可伸缩性的某些方面的强大工具。它们只是建议采用的工具,并不强制您使用其中一个工具而不使用其他工具。 请根据您组织的测试套件深入研究并评估这些工具。

IBM Rational Performance Tester(单用户和多用户)

Rational Performance Tester (RPT) 是 IBM 提供的一种性能测试工具(http://www-01.ibm.com/software/awdtools/tester/performance/)。

LoadRunner(单用户和多用户)

LoadRunner 是 Hewlett Packard 提供的一种性能测试工具。

Fiddler(单用户)

Fiddler 是一个免费的、基于浏览器的单用户性能工具,您可以从 http://www.fiddler2.com/fiddler2/ 在线获得它。它适用于 Internet Explorer、FireFox 和 Opera 等。


附录 B:为性能和可伸缩性测试测量服务器资源的有用软件

在性能和可伸缩性测试期间,以下软件可用来测量服务器资源使用情况。它们只是建议采用的工具,并不强制您使用其中一个工具而不使用其他工具。

Microsoft 的 SysInternals 工具(Windows)

http://technet.microsoft.com/en-us/sysinternals/default.aspx

有众多的有用工具,比如 psList,可以将与过程和服务器相关的信息输出到一个文件。然后可以解析文件以获得相关的信息。

Microsoft 的 Performance Monitor (Windows)

这是 Windows 的默认性能监视工具,是操作系统自带的。

NMon(AIX 和 Linux)

http://www.ibm.com/developerworks/wikis/display/WikiPtype/nmon

此系统性能监视工具可通过下载获得并在线安装。

‘top’ 和 ‘ps’(Linux 和 UNIX)

这些工具是操作系统自带的。您可以查看两个命令的手册页,获得为运行在这些操作系统上的产品收集必要的服务器和过程信息所需的正确参数。

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Information Management
ArticleID=810290
ArticleTitle=IBM Cognos 最佳实践: 设计针对 IBM Cognos BI 的成功的性能和可伸缩性测试
publish-date=04162012