• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            牽著老婆滿街逛

            嚴以律己,寬以待人. 三思而后行.
            GMail/GTalk: yanglinbo#google.com;
            MSN/Email: tx7do#yahoo.com.cn;
            QQ: 3 0 3 3 9 6 9 2 0 .

            單元測試極大地提高C/C++應用質量

            介紹

            如果你沒有執行單元測試,你就會同時失去第一時間改善軟件質量和削減開發時間和成本的機會。這種犧牲當然是令人失望的。在此之前,開發人員一直沒有一種可行的方法來執行單元測試。現在,JAVA開發人員能夠使用ParaSoft的Jtest自動化JAVA單元測試,而C/C++開發人員能夠利用ParaSoft最新的C++Test工具自動化C/C++單元測試。

            本文闡述了執行單元測試的方法、優點和難點,然后描述了C++Test任何能夠給C/C++開發人員帶來巨大的好處。

            什么是單元測試?

            我們對單元測試的定義是測試應用中最小的單元,如C/C++中的一個類。C/C++單元測試的目的是執行每個類中的每一個方法或函數,檢測所有存在的功能性問題、錯誤和構造弱點。發現這些典型的問題通常涉及到三種測試方法:黑盒測試、白盒測試和回歸測試。黑盒測試通過確定類的公共界面是否依照定義執行,檢查類的功能性;執行這種類型的測試不需要有關實現細節的知識。白盒測試通過確定類在遇到非預期輸入時執行是否正確,檢查所有的類的方法和函數(包括保護和私有成員)的健壯性;執行這種類型的測試需要對類的實現細節的完整知識。回歸測試檢查是否類的修改會在原來正確的代碼中引入新的錯誤。

            什么是單元測試的優點?

            單元測試被公認為軟件開發過程中的一個關鍵步驟。單元測試能夠簡化錯誤檢測,在減少開發時間和成本的同時提高軟件質量。

            單元測試促進錯誤檢測的第一個方面是使你更接近錯誤。圖1和圖2說明了這一點。

            圖1:應用測試

            圖1顯示了一個包含許多對象的應用的測試模型。大橢圓表示應用,小橢圓表示對象,箭頭表示用戶輸入,紅星表示潛在的錯誤。

            為了發現錯誤,必須修改輸入,對象間的相互作用將迫使某對象引發潛在的錯誤。這一點無疑是有一定難度的。想象一下你站在一張臺球桌前,所有的球圍成一個三角形放置在桌子中間,要求你一桿擊球將中間的球打入指定的袋中。這是一件多么困難的事情啊!就像要設計一個輸入從而發現應用中的一個錯誤一樣。由于其難度,開發人員只能依賴應用軟件的運行失敗來發現錯誤,但卻仍然沒有測試到許多類。因此只做集成測試是一件非常困難的事情。

            單元級測試提供了一種更有效的發現錯誤的方法。如圖2所示。

            cpptesta.gif (1594 bytes)

            圖2:單元測試

            單獨測試一個類時(與其它對象分離),由于更接近錯誤,找到潛在的錯誤就會變得容易得多。用上述臺球的例子來比喻,就像是臺面上只有壹兩個球時,一桿將一個球擊入指定的袋中。

            單元測試促進錯誤檢測的第二個方面是,將你從在問題中艱難跋涉去修正一個簡單錯誤的困境中解救出來。因為錯誤是相互關聯和作用的,在較高的層次上找到和修正一個錯誤,常常會發現另外的問題。當你在較高層次上測試時,原始的錯誤就象是洋蔥的最內層一樣,另外的錯誤就象緊包著內層的其它層:只有把外層都剝掉才能看到最內層。當你測試每一個類時,錯誤還很少有機會建立在其它錯誤之上,并相互作用引起奇怪的行為。因此在單元級上檢測錯誤會容易的多。

            最重要的結果是,更容易的錯誤檢測能夠在改善應用質量的同時大量削減開發時間和成本。首先,由于能夠更容易地找到錯誤,就會減少發現它們的時間和資源。其次,由于你一寫完一個類,就能發現和改正其中的錯誤,你就不需要在以后花費時間重新了解和摸索。最后,最重要的理由是:由于類的相互作用和關聯性,在單元級修改一個類只會影響到原始的類,而在較高的層次上修改一個類可能會改變多個程序部件的設計和功能性。越遲發現問題,通常就要修改越多的代碼。當修改的代碼量增加時,兩個其它因素也會隨之增加:

            • 修改每一個錯誤所需的時間和費用。
            • 在代碼中引入新的錯誤的機會。

            一次又一次的研究證明,隨著問題被檢測出來的時間的推遲,發現軟件錯誤所需的時間和成本會驚人地增加。請看下面的研究結果:

            • IBM: 根據IBM的一份內部資料指出,確定軟件錯誤的相對成本是:在設計階段,1.5;編碼前,1;編碼中,1.5;測試前,10;測試中,60;交付后,100。[Watts Humphrey]
            • TRW: 確定錯誤的相對時間:需求分析階段,1;設計階段,3-6;編碼階段,10;開發測試階段,15-40;接受性測試階段,30-70;應用運行中,40-1000。[Boehm]
            • IBM: 確定錯誤的相對時間:設計評審,1;代碼檢查,20;測試,82。[Remus]
            • JPL: Bush得出的每個錯誤的平均成本:編碼,US$90-US$120;測試,US$10,000。[Bush]
            • Freedman and Weinberg: 使用設計評審和代碼檢查手段的項目在測試時發現錯誤的數量會減少10倍,測試成本降低50%-8%,包括評審和檢查的成本。[Freedman]

            什么是單元測試的難點?

            基于上述信息,單元測試看上去就象一劑萬能藥。如果是這樣的話,為什么每一個C/C++開發人員不馬上對每一個類進行單元測試?就目前可以使用的技術來說,對C/C++的單元測試是一件困難、煩瑣和耗時的事情,沒有很好的工具來自動化這一過程,使得許多C/C++開發人員望而生畏。

            執行單元測試的第一步是是目標類變得可測。這需要兩個工作:

            • 設計一個運行目標類的測試驅動程序。
            • 設計樁函數,它們為被測類所引用的任何外部資源返回值。

            建立一個測試驅動,需要建立一個新的類,除了測試原始類以外它不能用于任何其它目的。測試驅動應該具有下列特性:

            • 一個指定設置和清除的標準方式。
            • 一個選擇個別測試和所有有效測試的方法。
            • 一個分析輸出的預期(或非預期)結果的機制。
            • 一個標準的錯誤報告形式。

            為了充分而正確地測試類,你需要設計一個能夠完全檢查被測類的測試驅動;若干次修改和重寫這樣一個測試驅動是免不了的。一旦建立了測試驅動,你必須仔細檢查它不能包含任何錯誤。測試驅動中的一個錯誤會破壞這個測試,但是你無法單獨測試一個類,你也不能測試測試驅動本身。

            如果你的類引用任何還沒有準備好或不可訪問的外部資源(如外部文件、數據庫和CORBA對象等),你必須建立相應的樁函數,它們的返回值類似于這些實際的外部資源應該返回的值。當建立這些樁函數時,你需要選擇樁函數的返回值,它們將影響程序的執行路徑...

            • 為了測試類的功能性必須執行任何的路徑,
            • 足夠的路徑能夠提供徹底的測試覆蓋性。

            下一步是設計和建立合適的測試用例。為了徹底地測試類的結構和功能性,你應該設計兩中類型的測試用例:黑盒和白盒。

            黑盒測試用例基于說明和規格文檔。特別地,至少應該為規格文檔的每個入口建立一個測試用例;更好的是這些測試用例能夠測試每個入口的各種邊界條件。還需要為發現的每一個錯誤增加另外的測試用例,以及任何你認為必要的其它測試。

            白盒測試用例通過各種不同的輸入充分地執行類的所有方法以發現缺陷。對于手工測試來說這是非常困難的。為了建立有效的白盒測試用例,你必須研究類的內部結構,然后編寫測試用例盡可能完全地覆蓋類的所有方法,以及覆蓋所有可能引起類崩潰的輸入。要達到較高的測試覆蓋性,需要有效的白盒測試用例它們能夠執行相當多數的路徑。例如,一個典型的1萬行的程序,大約有1億條可能的路徑;手工建立能夠執行所有這些路徑的輸入幾乎是不可行的。

            在建立這些測試用例以后,你將要執行整個測試用例并分析結果,確定在那里出現了錯誤、崩潰和薄弱環節。你還需測量這些測試的覆蓋性,以確定類被測試的程度以及需要追加的測試用例。

            任何時候一個類被修改后,你應該執行回歸測試,保證沒有引入新的錯誤和/或原來的錯誤已經被更正了。回歸測試包括白盒和黑盒測試用例,并且分析結果以確定類的質量是否得到的改善。

            C++Test: 一個自動化的單元測試解決方案

            ParaSoft認識到了C/C++單元測試內在的的價值和難度,開發了C++Test,一個自動的C/C++單元測試工具,增強了ParaSoft的自動錯誤防止和錯誤檢測產品線。C++Test自動執行所有可能的單元測試過程。特別地,它能夠自動:

            • 建立每個被測類的測試驅動程序。
            • 建立任何必要的樁函數,并允許你定制這些樁函數的返回值或加入自己的樁函數。
            • 單鍵執行白盒測試的所有步驟。
            • 生成黑盒測試用例的基礎集合。
            • 運行黑盒測試用例。
            • 生成黑盒測試的輸出結果。
            • 執行回歸測試。
            • 跟蹤測試覆蓋性。

            C++Test能夠測試所有類型的C/C++項目;C++Test甚至能夠支持COM對象,允許你對調用COM對象方法的類和方法執行自動的單元測試。

            C++Test還是高度可定制的;例如,你可以改變測試用例的生成參數,過濾一定的文件、類或方法,在任何層次上(從這個項目到單個方法或測試用例)進行測試。

            另外,C++Test很容易與你目前的開發過程合作。C++Test直接安裝在DevStudio環境中,因此你能夠立即測試任何正在開發中的類。只要在Developer Studio的工具欄上按下Test FileTest Project按鈕,那么C++Test就會自動在C++Test圖形用戶界面中打開你的文件,為每個類建立一個測試驅動程序并自動測試每個類。

            cpptest4.gif (8002 bytes)

            圖3:C++Test圖形用戶界面

            通過自動化單元測試過程,C++Test使得單元測試切實可行,即使對時間非常緊張的項目和開發人員也是如此,并且比手工單元測試具有更好的精確行和正確行。這一切將轉化成更高質量的應用,并且以更短的時間以及更低的開發、支持和維護成本。

            C++Test做什么?

            1. 自動建立測試驅動和樁函數

            C++Test自動建立一個測試驅動程序,其設計目標是極大化類的測試覆蓋性和錯誤檢測。為類建立測試驅動,你只要簡單地打開這個類,然后按Build Test鍵。C++Test將自動建立測試驅動程序。

            另外,如果被測的方法需要調用當時還不存在或無法訪問的函數,C++Test能夠自動生成樁函數;這樣能夠測試與外部資源操作的交互作用和不包含任何隱藏的弱點。C++Test不是實際調用這些函數,而是調用樁函數并返回樁函數提供的值。如果你需要控制使用的返回值,你可以建立一個樁調用表,生命輸入/輸出的關系。

            cpptest5.gif (6939 bytes)

            圖4:建立樁調用表

            你還能加入用戶定義的樁函數。例如,如果你要使用原始的函數,且該函數定義在不同的文件中;或者你想要仿真原始函數的行為,而用一個簡單的函數替代它。

            cpptest6.gif (3209 bytes)

            圖5:鍵入用戶自定義的樁調用

            自動生成C/C++類的測試驅動程序和樁函數的能力是C++Test所獨有的;只有C++Test能夠自動測試C/C++類(一當它能夠編譯時),而不需要用戶的任何干預。使得你能夠盡快地自動檢測代碼錯誤,以最容易、最省錢和最快速的方法找到和修正它們。如果沒有這樣的自動化工具,大量的時間和資源消耗將失去單元測試的潛在好處和現實意義。

            2. 白盒測試

            C++Test提供了一種有效并且高效的方法執行白盒測試。C++Test完全自動執行所有的白盒測試過程,自動生成和執行精心設計的測試用例。自動標記任何運行失敗,并以一種簡單的圖示化結構顯示。然后自動保存這些測試用例,能夠方便地用于以后的回歸測試。

            由于C++Test能夠自動生成樁函數,或允許你加入自己的樁函數,因此它能夠測試引用外部對象的類。換句話說,C++Test能夠運行任何一個或一組類,并自動生成和執行一組測試用例,它們被設計成能夠發現盡可能多的錯誤。

            cpptest7.gif (9816 bytes)

            圖6:執行自動白盒測試

            C++Test允許你定制白盒測試用例的生成,和在什么層次上(項目、文件、類或方法)執行測試。

            3. 黑盒測試

            C++Test通過自動化黑盒測試的大部分操作,減輕了這類測試的負擔。特別是以兩種方法自動化黑盒測試的第一階段--建立測試用例:

            • 幫助你設置每個測試用例的結果

            你可以簡單地輸入測試用例輸入,然后讓C++Test運行測試用例并自動確定實際的輸出結果。如果結果正確,不需要其它動作。如果結果不正確,你可以輸入預期的輸出結果。這樣比手工輸入每個測試用例的結果更快更容易。

            • 自動生成測試用例的核心集合

            C++Test自動設計了一組廣譜的白盒測試用例。當使用這些測試用例在黑盒測試時,你只需簡單地觀察實際的輸出結果,然后對任何不正確的結果輸入預期的值。

            當你需要輸入或修改測試用例時,你可以在C++Test自動生成的測試用例框架種簡單地鍵入相應的值。這將顯著地加快建立測試用例的過程。

            cpptest8.gif (6396 bytes)

            圖7:鍵入一個測試用例

            在自動化建立黑盒測試用例的大多數步驟之外,C++Test完全自動化余下的黑盒測試步驟。按一個鍵,你能夠對項目、文件、類或方法運行一個或一組。C++Test然后自動執行所有的測試用例,報告所有的輸入/輸出關系,并標記任何實際輸出與預期不一致或導致程序崩潰的測試用例。

            4. 回歸測試

            C++Test完全自動化與回歸測試有關的所有步驟。C++Test首次測試某個類時,自動保存其測試和測試參數。當需要執行回歸測試時,你可以打開合適的項目和文件,運行所有原來的白盒和黑盒測試用例;C++Test會自動運行完全相同的測試用例和測試參數,并告之發現的任何問題。這意味著你能夠立即知道修改是否引入了任何錯誤。

            5. 測試覆蓋性分析

            為了幫助你測量當前使用的測試用例集合的有效性,并且給你提供達到盡可能高的覆蓋性的信息,C++Test自動監視測試覆蓋性:

            • 行覆蓋
            • 累計行覆蓋
            • 基本塊覆蓋
            • 分支(判斷)覆蓋
            • 條件覆蓋
            • MC/DC覆蓋(DO-178B標準)

            cpptest3.gif (13064 bytes)

            圖8:瀏覽測試結果

            C++Test實時跟蹤測試覆蓋性,然后建立一個綜合測試覆蓋性報告。覆蓋性窗口圖示化地說明了當前正在被執行的代碼行,已執行過的行和每行的執行次數。因此,它不僅指出了一個代碼行是否被測試過,而且說明了被測試的有多徹底。這些信息對于確定那些代碼需要追加測試是非常有幫助的。

            6. 集成的單步調試

            如果你選擇在方法測試時捆綁調試器,C++Test將自動自動激活Microsoft Visual C++調試器,這樣使得你在用C++Test測試任何方法時仍然能夠方便地進行單步調式。

            7. 防止錯誤

            C++Test能夠自動執行兩種類型的變成標準。其內建的特性允許你自動執行動態的變成標準,如“總是對每個類執行單元測試”和“總是單步調試類”等。另外,假如你使用CodeWizard--ParaSoft的自動化可定制編程標準強化工具,C++Test可以自動運行CodeWizard。

            8. 運行時錯誤檢測

            C++Test還能幫助你執行類一級的運行時錯誤自動檢測。如果你安裝了Insure++,C++Test可以自動運行類和方法通過Insure++,它將檢查下列錯誤:

            • 內存引用錯誤/內存未初始化
            • 內存泄漏
            • 內存分配錯誤
            • 變量定義沖突
            • I/O錯誤
            • 指針錯誤
            • 庫調用錯誤
            • 邏輯錯誤
            • 算法錯誤

            這意味著你能夠在類開發的第一時間檢測運行時錯誤,而且無需自己做任何運行數據。C++Test自動生成大量而精心設計的測試用例,能夠幫助你更徹底、更方便和更快速地檢測運行時錯誤。

            結論

            通過執行單元測試,你能夠有效地防止許多錯誤的出現,盡早檢測出已存在的錯誤,并且比其它測試手段和技術更有效。影響C/C++開發人員執行單元測試的主要障礙是需要消耗大量的時間的資源,目前的一些單元測試工具仍然存在著這樣的問題。C++Test的推出克服了這一障礙。C++Test做到了開發人員總是希望卻不敢相信的事情:自動化C/C++單元測試。

            ....

            posted on 2006-07-05 21:33 楊粼波 閱讀(272) 評論(0)  編輯 收藏 引用 所屬分類: 軟件工程

            午夜精品久久久久久中宇| 国产韩国精品一区二区三区久久| 久久久久香蕉视频| 一本久久精品一区二区| 久久午夜福利无码1000合集| 久久久国产精品网站| 久久成人国产精品一区二区| 欧美一区二区三区久久综合 | 97精品伊人久久久大香线蕉| 国产精品禁18久久久夂久| 秋霞久久国产精品电影院| 久久夜色精品国产噜噜亚洲a| 久久国产精品无码HDAV| 久久性生大片免费观看性| 久久久久无码精品国产| 久久久久久精品成人免费图片| 久久99国产综合精品女同| 亚洲国产成人精品无码久久久久久综合 | 国产∨亚洲V天堂无码久久久| 伊人久久大香线蕉综合5g| 国产L精品国产亚洲区久久| 久久人人爽爽爽人久久久| 久久久久久极精品久久久| 久久99国产综合精品免费| 中文字幕乱码人妻无码久久| 国内精品伊人久久久久网站| 久久中文精品无码中文字幕| 99国产精品久久久久久久成人热| 热RE99久久精品国产66热| 久久久久99精品成人片牛牛影视| 久久国产精品国产自线拍免费| 久久久久亚洲av无码专区| 久久精品夜夜夜夜夜久久| 精品久久久久久无码中文字幕一区| 久久久久久精品无码人妻| 久久这里只有精品视频99| 欧美日韩精品久久久免费观看| 欧美日韩精品久久久免费观看| 久久人人青草97香蕉| 老男人久久青草av高清| 欧美日韩精品久久久久 |