开发人员使用 PureCoverage
开发人员通常负责创建单元测试，有时负责功能测试。这些测试的目的之一是在项目中特定区域中运用所有的。您可以手工检查源代码并编写您认为可以覆盖整个项目的测试案例，但是这并不是可靠的或者有效的开发测试的方法。您需要一个像 PureCoverage 一样的代码覆盖工具来告诉您：您确实在这个项目的特定区域运行所有的循环和条件。记住：未测试的代码很可能就是有疑问的代码!
一旦您创建了完全运行目标代码的单元测试，那不意味着您已经完成了编写测试。因为一旦下面的代码变更，您的测试就不可避免地会落后。它们不会运行后来引进的新特征或者不同的代码路径。您可以通过利用 PureCoverage 来有规律地分析这个测试覆盖并在特定子系统的覆盖水平寻找漏洞。早一点发现比晚点发现要好得多：如果您在一个发布版本周期的晚期遇到了不充分的覆盖，您将比其他人更晚编写测试。
当编写测试时，PureCoverage 还有另一个好处：它将告诉您何时应该停止。如果过度的测试一个功能区域或者子系统是没有好处的。如果您根据观察来编写测试，而不是利用像 PureCoverage 一样的度量工具，您将在测试创建上过分投资，并且不能得到任何额外的质量回报。PureCoverage 可以告诉您什么时候是最为合适的，帮助您节省时间和资金。
PureCoverage 对开发人员最后一个利益是，它与 Purify 的使用相结合，像一个猎手一样可以保持这个项目不受内存错误使用的影响。记住 Purify 只执行您在测试过程中实际执行的代码中的内存错误的检验。如果您的测试没有运行完所有的代码，那么您仍然不能在那些区域感受到 Purify 给您带来的好处。
测试人员使用 PureCoverage
一个测试套件只是与它所包含的测试质量有同样的性能。那看起来很明显，但是仅仅是负担着重复的操作。如果它不能真正运行这个项目，就没有必要花费时间和资金来运行这个测试套件，即使能够通过它所有的测试。如果来自这个测试套件的结论不能真实地告诉您这个项目的质量，那么您只是在浪费时间和资源。
一种度量测试质量的方法是，了解它们所运行的这个项目的区域以及（更为重要的是）它们所错过的区域。只有了解了您的测试所覆盖的范围和漏洞，您才能够判断出测试结论的价值。没有工具，测试中的漏洞是很难识别的――一个测试的失败或者崩溃是很显然的，然而测试中的漏洞确是隐蔽的。如果您不度量您测试的覆盖范围，您会继续运行您的测试并看到它们都通过测试，但是从来不会知道您的覆盖水平（因此这个测试运行的价值）正在恶化。
PureCoverage 可以度量您的测试覆盖范围，并可以显示漏洞。它可以产生单线水平的报告；但是对于测试人员来说，在文档或者子目录水平通常是最容易捕捉、总结，并趋向覆盖数据的。这样可以识别在项目整个运行时间中覆盖较少范围的区域，可以显示测试的什么位置需要按行展开有代码变更和增添新特征的区域。
测试人员使用 Purify
从测试人员或者测试经理的角度来看， Purify 是他们梦想的工具，因为它可以让您从您完成的工作中获得更多的价值。毕竟，您已经拥有运行这个项目的测试，因为它让您可以从您正在从事的工作中获得更多的价值。毕竟，您已经拥有了运行这个项目的测试，验证了它的正确性，报告了它的质量。利用 Purify 运行那些测试，您可以使它们执行双份的任务。也就是说，当您的测试忙于执行通常所执行的同样的工作时，您还可以利用 Purify 来监控这个程序的执行来检测和报告内存的使用错误。
正如上面所提到的，许多内存使用错误都是潜伏的：程序似乎在正常地运行，即使它所面临着内存崩溃或者错误行为的危险。十分普遍地情况是，测试环境并没有最终的产品环境复杂，因此即使测试都通过了，程序也能够包含一个在发布版本后即将引起严重破坏的内存崩溃性的错误。Purify 可以通过同时检查内存访问错误来对您的现存正确性测试增加价值。
这里是另一种使 Purify 成为梦想工具的方法：它可以报告出错误，以完全或者简单的方式。有些工具生成出数据后，您需要花很多时间评审或者解释或者用图示表示出来，以查看结果。但是 Purify 并不是那样的。Purify 可以识别您所测试程序中的真实错误，并向您指出正确的。Purify 有两种类型：它们被用黄色的“警告”图标标出，那些红色的是“错误的”表示。“错误”类型很明显反映了这个程序逻辑中的缺陷： Purify 报告了一个程序的错误，那也正是您所想要的。
因为 Purify 对内存使用错误的分析是如此的彻底和完全，因此，即便在测试运行中 Purify 没有报告任何错误，它仍然也是很有价值的。当 Purify 不报告任何错误时，意味着这个程序(如测试的那样)并没有那些错误。这是一个好消息，即这是一个关于被测试项目高质量的正面陈述。
理所当然的是，这仅仅运用于 Purify 所发现的内存错误的类型，以及您的测试运用这个程序的方法。在这个程序中仍然可能存在内存错误，可能随着不同的代码路径发生，或者使用没有被测试的数据模型。
这就是为什么在测试中识别漏洞时，使用 PureCoverage 与使用 Purify 同样重要。如果整个测试套件运用这个程序时不能真正完成它的引导，那么一个通过 Purify 的等级也并没有很大意义。就像一个交通警察， Purify 可以仅仅报告在有人监控时所发生的错误行为。PureCoverage 可以让您识别测试中的漏洞，因此您可以填充这个漏洞并使用 Purify 来诊断问题。
测试人员使用 Quantify
测试不仅仅是与正确性有关的。项目质量的另一个因素是执行。即使这个软件通常运作地很好并且给了您正确的答案，如果它慢得让人难于忍耐您也不可能拥有高质量的产品。并不明显得是，性能可以从一个构架到另一个构架或者从一个发布版本到另一个发布版本发生变更，比如您开始时可以有很好的性能，但是也可能在中途的某个位置遗失了好的性能。
Quantify 让您能够度量项目的性能特征。您可以利用这个数据在整个过程中跟踪结果，辨认出从一个构架到另一个构架或者从发布版本到发布版本的性能。例如，想想您已经拥有一个服务器上测试，并且这个测试将带有标准数据包和事务序列。您可以利用 Quantify 来度量这个测试的性能，并且您可以在项目进展时对性能进行跟踪。证实新特征和代码变更并没有对整个性能产生严重影响是十分重要的。利用 Quantify 的 "图像偏差 1 " 特性，您可以利用函数调用关系图和 River of Time 来比较先前和当前的趋势，并重点突出新热点和时间陷阱。
如果一个测试套件含对 Quantify 度量特征的了解，它甚至能够缩小焦点来消除不重要的因素。例如，如果这个服务器要花费很长时间来启动，那么对于许多服务器应用软件来说就不重要：重要的启动之后事务性能的运行速率。一个 Quantify 知晓的测试可以使带有标准数据和事务的服务器“预热”（来填充这个缓存），然后使 Quantify 在完成所有事务之后开始数据交换。通过聚集连续事务的时间数据，这个数据可以消除一次的启动成本，对这个系统的核心性能是否以及怎样从一个构架到另一个构建或者一个发布版本到另一个发布版本进行变更有一个清晰的概念。
结论
事实是：开发人员和测试人员的想法不同。他们使用工具的方式也不同。他们的共同点是对质量的关注。这两种角色都能够从使用 Rational PurifyPlus 的使用过程中获得利益，因为它既是开发人员也是测试人员的工具――它是一个质量工具。
文章来源于领测软件测试网 https://www.ltesting.net/
