開發人員使用 PureCoverage
開發人員通常負責創建單元測試，有時負責功能測試。這些測試的目的之一是在項目中特定區域中運用所有的。您可以手工檢查源代碼并編寫您認為可以覆蓋整個項目的測試案例，但是這并不是可靠的或者有效的開發測試的方法。您需要一個像 PureCoverage 一樣的代碼覆蓋工具來告訴您：您確實在這個項目的特定區域運行所有的循環和條件。記�。何礈y試的代碼很可能就是有疑問的代碼!
一旦您創建了完全運行目標代碼的單元測試，那不意味著您已經完成了編寫測試。因為一旦下面的代碼變更，您的測試就不可避免地會落后。它們不會運行后來引進的新特征或者不同的代碼路徑。您可以通過利用 PureCoverage 來有規律地分析這個測試覆蓋并在特定子系統的覆蓋水平尋找漏洞。早一點發現比晚點發現要好得多：如果您在一個發布版本周期的晚期遇到了不充分的覆蓋，您將比其他人更晚編寫測試。
當編寫測試時，PureCoverage 還有另一個好處：它將告訴您何時應該停止。如果過度的測試一個功能區域或者子系統是沒有好處的。如果您根據觀察來編寫測試，而不是利用像 PureCoverage 一樣的度量工具，您將在測試創建上過分投資，并且不能得到任何額外的質量回報。PureCoverage 可以告訴您什么時候是最為合適的，幫助您節省時間和資金。
PureCoverage 對開發人員最后一個利益是，它與 Purify 的使用相結合，像一個獵手一樣可以保持這個項目不受內存錯誤使用的影響。記住 Purify 只執行您在測試過程中實際執行的代碼中的內存錯誤的檢驗。如果您的測試沒有運行完所有的代碼，那么您仍然不能在那些區域感受到 Purify 給您帶來的好處。
測試人員使用 PureCoverage
一個測試套件只是與它所包含的測試質量有同樣的性能。那看起來很明顯，但是僅僅是負擔著重復的操作。如果它不能真正運行這個項目，就沒有必要花費時間和資金來運行這個測試套件，即使能夠通過它所有的測試。如果來自這個測試套件的結論不能真實地告訴您這個項目的質量，那么您只是在浪費時間和資源。
一種度量測試質量的方法是，了解它們所運行的這個項目的區域以及（更為重要的是）它們所錯過的區域。只有了解了您的測試所覆蓋的范圍和漏洞，您才能夠判斷出測試結論的價值。沒有工具，測試中的漏洞是很難識別的――一個測試的失敗或者崩潰是很顯然的，然而測試中的漏洞確是隱蔽的。如果您不度量您測試的覆蓋范圍，您會繼續運行您的測試并看到它們都通過測試，但是從來不會知道您的覆蓋水平（因此這個測試運行的價值）正在惡化。
PureCoverage 可以度量您的測試覆蓋范圍，并可以顯示漏洞。它可以產生單線水平的報告；但是對于測試人員來說，在文檔或者子目錄水平通常是最容易捕捉、總結，并趨向覆蓋數據的。這樣可以識別在項目整個運行時間中覆蓋較少范圍的區域，可以顯示測試的什么位置需要按行展開有代碼變更和增添新特征的區域。
測試人員使用 Purify
從測試人員或者測試經理的角度來看， Purify 是他們夢想的工具，因為它可以讓您從您完成的工作中獲得更多的價值。畢竟，您已經擁有運行這個項目的測試，因為它讓您可以從您正在從事的工作中獲得更多的價值。畢竟，您已經擁有了運行這個項目的測試，驗證了它的正確性，報告了它的質量。利用 Purify 運行那些測試，您可以使它們執行雙份的任務。也就是說，當您的測試忙于執行通常所執行的同樣的工作時，您還可以利用 Purify 來監控這個程序的執行來檢測和報告內存的使用錯誤。
正如上面所提到的，許多內存使用錯誤都是潛伏的：程序似乎在正常地運行，即使它所面臨著內存崩潰或者錯誤行為的危險。十分普遍地情況是，測試環境并沒有最終的產品環境復雜，因此即使測試都通過了，程序也能夠包含一個在發布版本后即將引起嚴重破壞的內存崩潰性的錯誤。Purify 可以通過同時檢查內存訪問錯誤來對您的現存正確性測試增加價值。
這里是另一種使 Purify 成為夢想工具的方法：它可以報告出錯誤，以完全或者簡單的方式。有些工具生成出數據后，您需要花很多時間評審或者解釋或者用圖示表示出來，以查看結果。但是 Purify 并不是那樣的。Purify 可以識別您所測試程序中的真實錯誤，并向您指出正確的。Purify 有兩種類型：它們被用黃色的“警告”圖標標出，那些紅色的是“錯誤的”表示�！板e誤”類型很明顯反映了這個程序邏輯中的缺陷： Purify 報告了一個程序的錯誤，那也正是您所想要的。
因為 Purify 對內存使用錯誤的分析是如此的徹底和完全，因此，即便在測試運行中 Purify 沒有報告任何錯誤，它仍然也是很有價值的。當 Purify 不報告任何錯誤時，意味著這個程序(如測試的那樣)并沒有那些錯誤。這是一個好消息，即這是一個關于被測試項目高質量的正面陳述。
理所當然的是，這僅僅運用于 Purify 所發現的內存錯誤的類型，以及您的測試運用這個程序的方法。在這個程序中仍然可能存在內存錯誤，可能隨著不同的代碼路徑發生，或者使用沒有被測試的數據模型。
這就是為什么在測試中識別漏洞時，使用 PureCoverage 與使用 Purify 同樣重要。如果整個測試套件運用這個程序時不能真正完成它的引導，那么一個通過 Purify 的等級也并沒有很大意義。就像一個交通警察， Purify 可以僅僅報告在有人監控時所發生的錯誤行為。PureCoverage 可以讓您識別測試中的漏洞，因此您可以填充這個漏洞并使用 Purify 來診斷問題。
測試人員使用 Quantify
測試不僅僅是與正確性有關的。項目質量的另一個因素是執行。即使這個軟件通常運作地很好并且給了您正確的答案，如果它慢得讓人難于忍耐您也不可能擁有高質量的產品。并不明顯得是，性能可以從一個構架到另一個構架或者從一個發布版本到另一個發布版本發生變更，比如您開始時可以有很好的性能，但是也可能在中途的某個位置遺失了好的性能。
Quantify 讓您能夠度量項目的性能特征。您可以利用這個數據在整個過程中跟蹤結果，辨認出從一個構架到另一個構架或者從發布版本到發布版本的性能。例如，想想您已經擁有一個服務器上測試，并且這個測試將帶有標準數據包和事務序列。您可以利用 Quantify 來度量這個測試的性能，并且您可以在項目進展時對性能進行跟蹤。證實新特征和代碼變更并沒有對整個性能產生嚴重影響是十分重要的。利用 Quantify 的 "圖像偏差 1 " 特性，您可以利用函數調用關系圖和 River of Time 來比較先前和當前的趨勢，并重點突出新熱點和時間陷阱。
如果一個測試套件含對 Quantify 度量特征的了解，它甚至能夠縮小焦點來消除不重要的因素。例如，如果這個服務器要花費很長時間來啟動，那么對于許多服務器應用軟件來說就不重要：重要的啟動之后事務性能的運行速率。一個 Quantify 知曉的測試可以使帶有標準數據和事務的服務器“預熱”（來填充這個緩存），然后使 Quantify 在完成所有事務之后開始數據交換。通過聚集連續事務的時間數據，這個數據可以消除一次的啟動成本，對這個系統的核心性能是否以及怎樣從一個構架到另一個構建或者一個發布版本到另一個發布版本進行變更有一個清晰的概念。
結論
事實是：開發人員和測試人員的想法不同。他們使用工具的方式也不同。他們的共同點是對質量的關注。這兩種角色都能夠從使用 Rational PurifyPlus 的使用過程中獲得利益，因為它既是開發人員也是測試人員的工具――它是一個質量工具。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
