使用Rational PurifyPlus 进行运行时分析

运行时分析是一种基于观察系统运行时行为的实践。它与"静态分析"不同，静态分析是指通过观察源代码或高级架构分析系统行为；或是分析系统失败时的"崩溃分析。"

　　调试是一种经典的运行时分析的例子：设置断点，一步步地运行系统，并且观察评估值和变量，通过这些方法了解系统运行时所发生的情况。当您调试的过程中，您不会对所有可能发生的事情感兴趣，仅仅对真正发生的感兴趣。这正是将运行时分析从静态分析中分离出来的原因。

　　调试过程是高度互动且有效的，但它受限于所能展示的内容。当您将关注的焦点集中于一行或一个变量时，它很难识别出模式并综合高级行为。

　　测试是另一种运行时分析：您通过数据或事件检验是否获得来自系统的正确行为。这种类型的测试是软件质量的基础。

　　传统的测试仅仅为您展现出这么多。一个通过了所有测试（获得正确结果）的系统仍然具有严重的质量问题。

　　这些就是为什么类似于 IBM Rational PurifyPlus 的运行时分析工具诞生的原因。

什么是 PurifyPlus？

　　PurifyPlus 是一种运行时分析工具，它用以在系统运行时监测系统并且报告系统行为的重要内容：

它会使用多少内存？
是否会造成内存泄露？
是否包括内存访问错误？
需要多长时间启动；瓶颈在哪里？
什么是线程运行/睡眠行为？
实际运行的源代码有多少？
这些关键分析特征都与核心"正确性" 问题无关："是否能够运行？"和"是否产生正确结果？" 测试能够显示您的系统是否正常工作，利用类似于 PurifyPlus 的运行时分析工具能够发现所有类型的错误。

PurifyPlus 的主要组件有：

内存使用追踪及内存错误检测
量化的性能分析、代码流和线程可视化
源代码覆盖分析的 PureCoverage
系统开发周期中的运行时分析

　　交互的开发周期和工程质量方案中重要的自动化构建、测试过程中都会包含运行时分析。

开发与执行过程中的运行时分析

　　在交互开发过程中，Purify 能够在新代码加入工程前报告内存错误。开发人员能够使用 PureCoverage 识别所需新测试的区域。Quantify 能够在开发早期展现未期望的代码路径和瓶颈。

自动化测试过程中的运行时分析

　　当运行自动化构建测试时，PurifyPlus 能够使您监测质量并且收集信息以确保工程处于正轨。当您的测试运行于 Purify 且没有错误报告时，您就可以知道系统并不含有内存访问错误和内存泄露。 当所运行的 Quantify 显示性能满足目标时，您可以知道系统没有遇到瓶颈。当 PureCoverage 报告高级别的代码覆盖时，您可以知道并没有引入新的代码块，因此不必增加自动测试。

　　您可以增加利用自动化测试工具（IBM Rational Functional Tester）所获得的运行时分析数据的质量。自动化的测试能够在一次叠代中得到更多的测试信息，并且能够评估所引入的新产品质量效果。如果软件质量介于两类连续的组件叠代间，那么运行时分析数据很容易找出其中的特点或代码的改变。

用以理解系统的运行时分析

　　有时，运行时分析并不包括正确性或质量。例如，运行时分析可以帮助理解系统。尤其是，Quantify 能够展示出调用图，揭示系统的各个部分如何协调工作，或揭示了非期望的性能下降或交互。

基本的 PurifyPlus 能力

　　如上所述，IBM Rational PurifyPlus 具有三个主要组件：内存分析的 Purify，性能分析的 Quantify，和代码覆盖分析的 PureCoverage。

　　对于 C/C++ 程序，Purify 自动化的检测并报告内存泄露和内存访问错误，例如，在内存释放后使用内存，重复释放相同区域的内存，或是初始化前从内存读。所有这些都是潜伏于程序中的软件质量问题，即使通过了所有测试。这类错误可以导致严重的生产错误。

　　对于 Java 和 Microsoft .Net 程序（"已管理的程序"），Purify 追踪内存的使用和内存引用，因此，您能够发现哪里是内存瓶颈，应在哪里释放内存，比对前后图形以检测程序中未预料的内存使用 （"泄露"）。

　　Quantify 追踪程序性能和调用行为，因此您能够发现执行流并识别出瓶颈。 Quantify 强调了使用 River of Time（tm）特征的花费最久的代码路径。除此之外，Quantify 为您可视化的实现了线程执行行为。

　　PureCoverage 追踪代码覆盖，因此您可以发现测试与运行时分析工具不能发现的鸿沟。由于 Purify 和 Quantify 仅仅看到了实际运行的代码，PureCoverage 提供的代码覆盖矩阵重点了解正在检测和更新的质量。

使用 PurifyPlus 的运行时分析的例子

　　调试的主要目标就是找出缺陷的根本原因并理解程序行为。

　　运行时分析提供了额外的补充传统调试不足的能力：

应用执行的可视化。
重要运行时参数的度量，包括内存使用、性能和代码覆盖。
用户模式下的错误检测。
运行时行为的文档。
我们将在下面检查这些能力。

应用执行的可视化

为理解这一能力，我们将看到以下四个例子。

可视化例子1：代码覆盖

　　使用诸如 Rational® PureCoverage® 的运行时工具（包含于 Rational PurifyPlus 中）提供了各种视图展现代码覆盖信息，其中之一就是 Annotated Source。这一特别的视图显示了所检查的应用的源文件；划线的颜色指出了执行测试事例之后的状态：hit、 missed、 dead 或部分 hit。

可视化例子　2：线程

运行时分析工具诸如 Rational Quantify （包含于 Rational PurifyPlus中）提供了线程可视化，它能够利用标记调试时每个线程的状态检测多线程问题。如图2所示，它允许您在调试时检测可视化线程的状态。

可视化例子 3：调用图

　　运行时分析工具还能够检测和显示性能瓶颈。这种方法与传统方式相比最大的优势就在于，您可以获得完美的执行路径概况，和关于调用数准确信息。如图 3A 和 3B 所示，Rational Quantify 中的 Call Graph 强调了最大时间消耗执行的路径的调用链；那就是性能弱点。连接方法的粗线表示了调用链所花费时间和剩余应用时间（如果使用 Purify，那就是内存）的比率。

可视化例子 4：内存使用

处理内存泄露的第一步就是要检测。一种直观的方式就是可视化全部内存使用并且在测试（PUT）下进行内存快照。这可以在运行中的应用中发现潜在的内存泄露。（在 Rational Purify for Java 和 .NET 管理应用中已经实现）例如，如果对于在服务器端运行的组建内存快照显示，全部内存性能在客户端增加，之后很可能是组件泄露。


关键运行时参数的测量

可见的错误检测仅仅是运行时分析的第一步。我们还需要准确理解运行时所发生的事情。因此，运行时分析应基于针对应用执行的准确的参数测量：

运行时性能
内存使用
代码覆盖
我们将再次通过事例理解这一运行时分析的能力。

原文转自：http://www.ltesting.net