IBM® Rational® PurifyPlus™ 能够帮助开发人员和测试人员达到他们项目质量的共同目标。有些人把 PurifyPlus 看作一个测试工具,有些人则将它看作是一个开发工具。开发人员和测试人员都可以从 PurifyPlus 获得利益,因为他们都是在软件项目中为高水平的质量而奋斗。
在这篇文章中,我展现了一个 PurifyPlus 的概述、它如何操作,以及为什么它对开发人员和测试人员有如此大的价值,通过许多重要的产品活动不仅仅提高了产品质量,还增加了个人和小组的效率和有效性。
低质量的成本
为了您项目的成功,尽早找到并修复故障是非常必要的。如果能够尽早找到并修复缺陷,这些缺陷的成本将少得多,要么通过开发人员要么通过早期得测试得方法来操作。故障如果通过了测试并到达了客户,成本将比找到并修复要高得多,而且对您得声誉和最终的业务也有相当大的影响。
在开发和测试阶段使用 PurifyPlus,您可以尽早将质量引入项目,并且可以避免不完全测试的高成本,处理性能问题,以及/或者稍后找到并修复内存使用错误。
PurifyPlus 组件
Rational PurifyPlus 产品有三个组件:内存错误验证的 Purify,性能数据采集的 Quantify,以及代码覆盖分析的 PureCoverage。我将依次讨论每个成分的工作方式。
Purify 组件
在 C/C++ 程序中去除分解内存使用。当它发现事件比被分配时使用更多的内存,或者在它初始化之前或者释放之后使用内存,就会发布一个错误报告。Purify 还可以报告内存泄漏――比如,当一个程序在丢失内存跟踪之前不能释放一个或者更多的内存板块时。尤其是在 Java™ 和 Microsoft .NET 程序中,Purify 能够帮助您识别使用内存并且没有将它释放的程序区域,这是另一种类型的内存泄漏。
对于 C 和 C++ 程序 (而不是 Java 或者 .NET), Purify 通过在这个程序执行中的每一个内存访问周围插入额外的指令来工作。这叫做仪表化。当您运行这个仪表化程序时,它将正常运作,进行与平时一样的操作。但是,Purify 在里面,可以检查问题。如果这个程序从还没有被初始化的内存中读取,或者读取或者改写已经被释放或者仍然存在于分配区域之外的内存,您将看到一个 Purify 错误报告。
有些类型的内存访问错误 (比如使用一个 NULL 指示器) 将会导致一个程序完全崩溃。这是一个很容易就可以辨认出的一个错误――您可以用一个正规调试器来找到它。Purify 可以让您看到更多潜伏的内存错误类型,它们可能出现在程序开起来似乎运转正常的情况下。这个特殊的功能在程序中可以产生正确的答案,您的测试可以通过,但是仍然可能存在内存错误。
例如,一个逻辑性的瑕疵可能在只有99条被分配时已经产生100条的错误。这种错误可能不会导致您的程序崩溃或者您的测试失败,但是仍然存在内存崩溃的危险。某天当潜在的内存错误由于一个不正确的操作超出了内存的范围,那么将导致系统崩溃,这将导致客户的不满意。在项目的早期,Purify 就能够很容易的发现这种类型的错误。
对于 Java 和 .NET 程序,当您的项目仍然在使用本应该已经释放的内存时, Purify 能够帮助您识别出来。这种类型的内存泄漏将会导致您的程序越来越大,运行越来越慢,最终耗尽内存。
Quantify 组件
Quantify 是 PurifyPlus 中进行分析的组件。它适用于 C/C++, Java,以及 .NET 程序。Quantify 度量并分析在程序中所花费的时间,从而识别“热点”和无效的代码。独特的 "River of Time" 显示可以直接让您找到您的程序中最浪费时间的区域。
PureCoverage 组件
PureCoverage 进行代码覆盖的分析。就像 Quantify,您可以利用它应用在您的 C/C++, Java, 以及 .NET 程序中。利用 PureCoverage,您可以确保测试您的整个程序。毕竟,您没有进行测试的代码的质量是未知的。因为您的测试并不报告它的错误或者健康状态。没有测试到的错误将会“逃离”进入释放,找到并修复它们的成本将十分昂贵。在发布版本之前识别测试漏洞,填充并找到这些错误,成本会低得多。
此外,很重要得一点是, Purify 只在运行测试的过程中对部分的程序进行错误的检验。如果您在测试覆盖范围中有漏洞,那么您在 Purify 错误检验中仍然会有漏洞。这是使用 PureCoverage 另一个很好的理由。
开发人员和测试人如何使用 PurifyPlus
开发人员和测试人员使用工具的方法是不同的。一个开发人员更想要交互的,图解的并带有“挖掘”性能的结果,然后 PurifyPlus 将它交付。而测试人员更喜欢用报告中的日志文档和总结报告,利用它们捕捉结果。PurifyPlus 也可以产生这样的结果。在这个部分中我将分别描述开发人员和测试人员利用 PurifyPlus 组件优化质量的方法,还将讨论您将从中获得的好处。
开发人员使用 Purify
开发人员可以用两种方法来使用 Purify。首先,当您遇到一个程序错误或者看起来是与不适当使用内存相关的缺陷时,您可以把它当作一个程序调整工具来使用。当内存被毁坏、不适当地使用,或者泄漏时,Purify 能够帮您识别所有不正当行为。这样看来, Purify 像一个医生:当您生病需要诊断治疗时可以求助于它。
但是开发人员还有另外一种使用 Purify 的方法:像作家利用拼写检查器一样,找到并去除您没有意识到的错误。有规律地使用 Purify,您可以在程序崩溃或者其它明显疑问的行为发生之前,找到内存的错误使用并修复它。(如果您在检验之前找到并修复了这个错误,它还会有影响吗?)
有些程序设计部门使用 Purify 的方法是,将它作为源代码中的自动步骤来控制过程。在开发人员的检入代码被允许进行测试之前,必须用 Purify 来进行测试。如果存在 Purify 错误报告,这个变更是不能继续进入到这个构架的。这样可以使构架保持健康,并不至于开发人员陷入困境中。毕竟,您并不希望成为引入一个变更而导致所有测试崩溃的人。这样看来,Purify 就像维他命或者锻炼:您可以每天使用来保持您代码的健康,这样一来这些问题就可以掌控之中。
开发人员使用 Quantify
测试人员或者测试工具可以从较高的层面上告诉您系统性能并不充分,但是找到并修复这个潜在问题的任务将落到开发人员身上。这就是 Quantify 组件参与进来的位置。Quantify 重点突出了您代码中的 "热点",比如运算法则需要改良的位置,如果链接列表应该是一个哈希表,或者什么地方应该使用缓存,以避免不必要的重新计算。
Quantify 可以用来比较您程序的两种趋向,这样您可以清楚地看到您做出代码变更时所表现的不同性能。这样您可以利用真实的代码而不是猜测来对您的性能进行最优化操作。对于 C 和 C++ 程序,Quantify 利用不变的定时数字,这样性能数据就不会受到外界因素的影响,比在测试机上加载。这意味着您可以更可靠地比较这两种趋势,度量与只使用度量“运行时间”工具相比较时地良好性能差别。
除了性能分析之外,另一种使用 Quantify 的方法是获取对程序逻辑和操作更好的理解。Quantify 的 "River of Time" 展现了一个图示,显示了程序的功能是如何调用对方的。您可以利用它来跟踪程序逻辑,并可以查看子系统之间的相互关系。有时最有价值的见解来自诸如"我并不希望这个子系统来调用那个子系统。" 之类的惊喜。Quantify 的调用图示向您显示了将会发生什么――如果它确实您所期望的不匹配,那么您就学习更多的相关知识。