使用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.anti-gravitydesign.com