免费视频淫片aa毛片_日韩高清在线亚洲专区vr_日韩大片免费观看视频播放_亚洲欧美国产精品完整版

打開APP
userphoto
未登錄

開通VIP,暢享免費(fèi)電子書等14項超值服

開通VIP
單元測試大揭密

單元測試大揭密 

Author: Vince      來源:http://blog.csdn.net/vincetest

  【文章來源:文斯測試技術(shù)研究中心 http://blog.csdn.net/vincetest

在實際的單元測試過程中總會有一些錯誤的認(rèn)識左右著我們,使之成為單元測試最大的障礙,在此將其一一分析如下:【文章來源:文斯測試技術(shù)研究中心 http://blog.csdn.net/vincetest
  • 它太浪費(fèi)時間了,現(xiàn)在要趕進(jìn)度,時間上根本不允許,或者隨便做做應(yīng)付領(lǐng)導(dǎo)。
  • 我是一個很棒的程序員,我寫的代碼肯定是沒有問題的。
  • 做單元測試太煩了,直接集成,到時有問題在集成測試時肯定能發(fā)現(xiàn)的,實在不行在系統(tǒng)測試總該能發(fā)現(xiàn)吧。
  • 它僅僅是證明這些代碼做了什么。
對于以上錯誤認(rèn)識的產(chǎn)生歸根結(jié)底還是由于對單元測試的理解還是不夠,沒有真正認(rèn)識到單元測試的重要性。
單元測試是軟件測試的基礎(chǔ),因此單元測試的效果會直接影響到軟件的后期測試,最終在很大程度上影響到產(chǎn)品的質(zhì)量。從如下幾個方面就可以看出單元測試的重要性在何處。
  • 時 間方面:如果認(rèn)真的做好了單元測試,在系統(tǒng)集成聯(lián)調(diào)時非常順利,因此會節(jié)約很多時間,反之那些由于因為時間原因不做單元測試或隨便做做的則在集成時總會遇 到那些本應(yīng)該在單元測試就能發(fā)現(xiàn)的問題,而這種問題在集成時遇到往往很難讓開發(fā)人員預(yù)料到,最后在苦苦尋覓中才發(fā)現(xiàn)這是個很低級的錯誤而在悔恨自己時已經(jīng) 浪費(fèi)了很多時間,這種時間上的浪費(fèi)一點(diǎn)都不值得,正所謂得不償失。
  •  測 試效果:根據(jù)以往的測試經(jīng)驗來看,單元測試的效果是非常明顯的,首先它是測試階段的基礎(chǔ),做好了單元測試,在做后期的集成測試和系統(tǒng)測試時就很順利。其次 在單元測試過程中能發(fā)現(xiàn)一些很深層次的問題,同時還會發(fā)現(xiàn)一些很容易發(fā)現(xiàn)而在集成測試和系統(tǒng)測試很難發(fā)現(xiàn)的問題。再次單元測試關(guān)注的范圍也特殊,它不僅僅 是證明這些代碼做了什么,最重要的是代碼是如何做的,是否做了它該做的事情而沒有做不該做的事情。【文章來源:文斯測試技術(shù)研究中心 http://blog.csdn.net/vincetest
  • 測 試成本:在單元測試時某些問題就很容易發(fā)現(xiàn),如果在后期的測試中發(fā)現(xiàn)問題所花的成本將成倍數(shù)上升。比如在單元測試時發(fā)現(xiàn)1個問題需要1個小時,則在集成測 試時發(fā)現(xiàn)該問題需要2個小時,在系統(tǒng)測試時發(fā)現(xiàn)則需要3個小時,同理還有定位問題和解決問題的費(fèi)用也是成倍數(shù)上升的,這就是我們要盡可能早的排除盡可能多 的bug來減少后期成本的因素之一。
  •  產(chǎn)品質(zhì)量:單元測試的好與壞直接影響到產(chǎn)品的質(zhì)量,可能就是由于代碼中的某一個小錯誤就導(dǎo)致了整個產(chǎn)品的質(zhì)量降低一個指標(biāo),或者導(dǎo)致更嚴(yán)重的后果,如果我們做好了單元測試這種情況是可以完全避免的。【文章來源:文斯測試技術(shù)研究中心 http://blog.csdn.net/vincetest
    綜上所述,單元測試是構(gòu)筑產(chǎn)品質(zhì)量的基石,我們不要因為節(jié)約單元測試的時間不做單元測試或隨便做而讓我們在后期浪費(fèi)太多的不值得的時間,我們也不愿意因為由于節(jié)約那些時間導(dǎo)致開發(fā)出來的整個產(chǎn)品失敗或重來!
1. 它是一種驗證行為。
程序中的每一項功能都是測試來驗證它的正確性,為以后的開發(fā)提供支緩。就算是開發(fā)后期,我們也可以輕松的增加功能或更改程序結(jié)構(gòu),而不用擔(dān)心這個過程中會破壞重要的東西。而且它為代碼的重構(gòu)提供了保障,這樣,我們就可以更自由的對程序進(jìn)行改進(jìn)。
2.它是一種設(shè)計行為。
編寫單元測試將使我們從調(diào)用者觀察、思考,特別是先寫測試(test-first),迫使我們把程序設(shè)計成易于調(diào)用和可測試的,即迫使我們解除軟件中的耦合。另外還可以使編碼人員在編碼時產(chǎn)生預(yù)測試,將程序的缺陷降低到最小。【文章來源:文斯測試技術(shù)研究中心 http://blog.csdn.net/vincetest
3.它是一種編寫文檔的行為。
單元測試是一種無價的文檔,它是展示函數(shù)或類如何使用的最佳文檔。這份文檔是可編譯、可運(yùn)行的,并且它保持最新,永遠(yuǎn)與代碼同步。
4.它具有回歸性。
自動化的單元測試避免了代碼出現(xiàn)回歸,編寫完成之后,可以隨時隨地的快速運(yùn)行測試。
 
1. 單元測試:單元測試又稱模塊測試,屬于白盒測試,是最小單位的測試。模塊分為程序模塊和功能模塊。功能模塊指實現(xiàn)了一個完整功能的模塊(單元),一個完整的程序單元具備輸入、加工和輸出三個環(huán)節(jié)。而且每個程序單元都應(yīng)該有正規(guī)的規(guī)格說明,使之對其輸入、加工和輸出的關(guān)系做出名明確的描述。
2.測試驅(qū)動:驅(qū)動被測試模塊正常運(yùn)行起來的實體
3.測試樁:代替被測模塊調(diào)用的子模塊的實體,該實體一般為樁函數(shù)。
4. 測試覆蓋:評測測試過程中已經(jīng)執(zhí)行的代碼的多少。
5.覆蓋率:代碼的覆蓋程度,一種度量方式。針對代碼的測試覆蓋率有許多種度量方式,定義如下:

 

單元測試的對象是軟件設(shè)計的最小單位——模塊或函數(shù),單元測試的依據(jù)是詳細(xì)設(shè)描述。測試者要根據(jù)詳細(xì)設(shè)計說明書和源程序清單,了解模塊的I/O條件和模塊的邏輯結(jié)構(gòu)。主要采用白盒測試的測試用例,輔之以黑盒測試的測試用例,使之對任何合理和不合理的輸入都能鑒別和響應(yīng)。要求對所有的局部和全局的數(shù)據(jù)結(jié)構(gòu)、外部接口和程序代碼的關(guān)鍵部分進(jìn)行桌面檢查和代碼審查。在單元測試中,需要對下面5個方面的內(nèi)容進(jìn)行測試,也是構(gòu)造測試用例的基礎(chǔ)。

1)   模塊接口:測試模塊的數(shù)據(jù)流。如果數(shù)據(jù)不能正確地輸入和輸出,就談不上進(jìn)行其他測試。因此,對于模塊接口需要如下的測試項目:
  • 調(diào)用所測模塊時的輸入?yún)?shù)與模塊的形式參數(shù)在個數(shù)、屬性、順序上是否匹配;
  • 所測模塊調(diào)用子模塊時,它輸入個子模塊的參數(shù)與子模塊的形式參數(shù)在個數(shù)、屬性、順序上是否匹配;
  • 是否修改了只做輸入用的形式參數(shù);
  • 輸出給標(biāo)準(zhǔn)函數(shù)的參數(shù)在個數(shù)、屬性、順序上是否匹配;
  • 全局變量的定義在各模塊中是否一致;
  •  限制是否通過形式參數(shù)來傳送。
2)  局部數(shù)據(jù)結(jié)構(gòu)測試:模塊的局部數(shù)據(jù)結(jié)構(gòu)是最常見的錯誤來源,應(yīng)設(shè)計測試用例以檢查以下各種錯誤:
  •  檢查不正確或不一致的數(shù)據(jù)類型說明;
  • 使用尚未賦值或尚未初始化的變量;
  •  錯誤的初始值或錯誤的默認(rèn)值;
  • 變量名拼寫錯誤或書寫錯誤;
  •  不一致的數(shù)據(jù)類型。【文章來源:文斯測試技術(shù)研究中心 http://blog.csdn.net/vincetest
3)路徑測試:對基本執(zhí)行路徑和循環(huán)進(jìn)行測試會發(fā)現(xiàn)大量的錯誤。根據(jù)白盒測試和黑盒測試用例設(shè)計方法設(shè)計測試用例。設(shè)計測試用例查找由于錯誤的計算、不正確的比較或不正常的控制流而導(dǎo)致的錯誤。
  • 常見的不正確的計算有:
Ø         運(yùn)算的優(yōu)先次序不正確或誤解了運(yùn)算的優(yōu)先次序;
Ø         運(yùn)算的方式錯誤(運(yùn)算的對象彼此在類型上不相容);
Ø         算法錯誤;
Ø         初始化不正確;
Ø         運(yùn)算精度不夠;
Ø         表達(dá)式的符號表示不正確等。
  •  常見的比較和控制流錯誤有:
Ø         不同數(shù)據(jù)類型的比較;
Ø         不正確的邏輯運(yùn)算符或優(yōu)先次序;
Ø         因浮點(diǎn)運(yùn)算精度問題而造成的兩值比較不等;
Ø         關(guān)系表達(dá)式中不正確的變量和比較符;
Ø         “差1錯”,即不正確地多循環(huán)或少循環(huán)一次;
Ø         錯誤的或不可能的循環(huán)終止條件;
Ø         當(dāng)遇到發(fā)散的迭代時不能終止循環(huán);
Ø         不適當(dāng)?shù)匦薷牧搜h(huán)變量等。
4) 錯誤處理測試:比較完善的模塊設(shè)計要求能預(yù)見出錯的條件,并設(shè)置適當(dāng)?shù)某鲥e處理對策,以便在程序出錯時,能對出錯程序重新做安排,保證其邏輯上的正確性。這種出錯處理也是模塊功能的一部分。表明出錯處理模塊有錯誤或缺陷的情況有:
  • 出錯的描述難以理解;
  • 出錯的描述不足以對錯誤定位和確定出錯的原因;
  • 顯示的錯誤與實際的錯誤不符;
  • 對錯誤條件的處理不正確;
  • 在對錯誤進(jìn)行處理之前,錯誤條件已經(jīng)引起系統(tǒng)的干預(yù);
  •  如果出錯情況不予考慮,那么檢查恢復(fù)正常后模塊可否正常工作。
5) 邊界測試:邊界上出現(xiàn)錯誤上常見的。設(shè)計測試用例檢查:
  •  在n次循環(huán)的第0次、1次、n次是否有錯誤;
  • 運(yùn)算或判斷中取最大最小值時是否有錯誤;
  • 數(shù)據(jù)流、控制流中剛好等于、大于、小于確定的比較值時是否出現(xiàn)錯誤。

 

何時進(jìn)行單元測試?單元測試在編碼階段進(jìn)行。在源程序代碼編制完成、經(jīng)過評審和驗證、確認(rèn)沒有語法錯誤之后,就可以開始進(jìn)行單元測試的測試用例設(shè)計。要利用軟件設(shè)計文檔,設(shè)計可以驗證程序功能、找出程序錯誤的多個測試用例。【文章來源:文斯測試技術(shù)研究中心 http://blog.csdn.net/vincetest
對于每一組輸入,應(yīng)該有預(yù)期的正確結(jié)果。在單元測試時,如果模塊不是獨(dú)立的程序,需要輔助測試模塊,有兩種輔助模塊:
  • 驅(qū)動模塊(Driver):所測模塊的主程序。它接收測試數(shù)據(jù),把這些數(shù)據(jù)傳遞給所測試模塊,最后再輸出測試結(jié)果。當(dāng)被測試模塊能完成一定功能時,也可以不要驅(qū)動模塊。
  •  樁模塊(Stub):用來代替所測模塊調(diào)用的子模塊。
      被測試模塊、驅(qū)動模塊和樁模塊共同構(gòu)成了一個測試環(huán)境,如下圖所示:


 
1.測試用例的組成(在單元測試中測試用例基本上由測試腳本組成)
  • 用例運(yùn)行前置條件
  • 被測模塊/單元所需環(huán)境(全局變量賦值或初始化實體)
  • 啟動測試驅(qū)動
  • 設(shè)置樁
  • 調(diào)用被測模塊
  • 設(shè)置預(yù)期輸出條件判斷
  • 恢復(fù)環(huán)境(包括清除樁)
2.測試用例的設(shè)計原則
  • 一個好的測試用例在于能夠發(fā)現(xiàn)至今沒有發(fā)現(xiàn)的錯誤;
  • 測試用例應(yīng)由測試輸入數(shù)據(jù)和與之對應(yīng)的預(yù)期輸出結(jié)果這兩部分組成;
  • 在測試用例設(shè)計時,應(yīng)當(dāng)包含合理的輸入條件和不合理的輸入條件;
  • 為系統(tǒng)運(yùn)行起來而設(shè)計測試用例;
  • 為正向測試而設(shè)計測試用例;
  • 為逆向測試而設(shè)計測試用例;
  • 為滿足特殊需求而設(shè)計測試用例;
  • 為代碼覆蓋而設(shè)計測試用例;
3.用例設(shè)計方法
1)        規(guī)范(規(guī)格)導(dǎo)出發(fā)
2)        等價類劃分法
3)        邊界值分析法
4)        狀態(tài)轉(zhuǎn)移測試法
5)        分支測試法
6)        條件測試法
7)        數(shù)據(jù)定義-使用測試法(又名數(shù)據(jù)流測試法)
8)        內(nèi)部邊界值測試法
9)        錯誤猜測法
4. 特定的用例測試設(shè)計
1)聲明測試:檢查模塊中的所有變量是否被聲明。經(jīng)驗表明,大量重要的錯誤都是由于變量沒有被聲明或沒有被正確的聲明而引起的。
2)路徑測試:要求模塊中所有可能的路徑都被執(zhí)行一遍,屬邏輯覆蓋測試。
基本路徑測試:由于實際中,一個模塊中的路徑可能非常多,由于時間和資源有限,不可能一一測試到。這就需要把測試所有可能路徑的目標(biāo)減少到測試足夠多的路徑,以獲得對模塊的信心。要測試的最小路徑集就是基本測試路徑集。基本測試路徑集要保證:
  • 每個確定語句的每一個方向要測試到;
  • 每條語句最少執(zhí)行一次。
3)循環(huán)測試:重點(diǎn)檢查循環(huán)的條件-判斷部分以及邊界條件。測試循環(huán)是一種特殊的路徑測試,因為循環(huán)比其他語句都復(fù)雜一些。循環(huán)中錯誤的發(fā)生機(jī)會比其他代碼構(gòu)成部分多。因此,對于任何給定的循環(huán)測試應(yīng)該包括測試下面每一條件的測試用例:
  •  循環(huán)不執(zhí)行;
  •  執(zhí)行一次循環(huán);
  • 執(zhí)行兩次循環(huán);
  • 反映執(zhí)行典型的循環(huán)的執(zhí)行次數(shù);
  • 如果有最大循環(huán)次數(shù),最大循環(huán)次數(shù)減1;
  • 最大循環(huán)次數(shù);
  • 大于最大循環(huán)次數(shù)。
對于增量和減量不是1的FOR語句,要特別注意,因為程序員習(xí)慣于增量1。
4) 循環(huán)嵌套:循環(huán)嵌套使邏輯的次數(shù)呈幾何級數(shù)增長,設(shè)計測試嵌套循環(huán)的測試用例應(yīng)該包括的測試條件有:
  • 把外循環(huán)設(shè)置為最小值,并運(yùn)行內(nèi)循環(huán)所有可能的情況;
  • 把內(nèi)循環(huán)設(shè)置為最小值,并運(yùn)行外循環(huán)所有可能的情況;
  • 把所有的循環(huán)變量都設(shè)置為最小值運(yùn)行;
  • 把所有的循環(huán)變量都設(shè)置為最大值運(yùn)行;
  •  把外循環(huán)設(shè)置為最大值,并運(yùn)行內(nèi)循環(huán)所有可能的情況;
  • 把內(nèi)循環(huán)設(shè)置為最大值,并運(yùn)行外循環(huán)所有可能的情況;
5) 邊界值測試:指程序內(nèi)部邊界測試。檢查確定代碼在任何邊界情況下都不會出差錯。重點(diǎn)檢查小于、等于和大于邊界條件的情況。邊界值測試是指專門設(shè)計用來測試當(dāng)條件語句中引用的值處在邊界或邊界附近時系統(tǒng)反映的測試。被測試語句的最好的例子就是“IF-THEN…ELSE-ENDIF”部分。這樣語句的例子如:【文章來源:文斯測試技術(shù)研究中心 http://blog.csdn.net/vincetest
IF a <= 123 THEN
b = 1
ELSE IF a >= 123 THEN
b = 2
ELSE b = 3
END IF
           上面例子中的邊界值測試用例應(yīng)該至少包括a的以下值:122,123,124。當(dāng)a=123時,b=1還是2。(找出邏輯判斷的矛盾)
6)接口測試:檢查模塊的數(shù)據(jù)流(輸入、輸出)是否正確。檢查輸入的參數(shù)和聲明的自變量的個數(shù),數(shù)據(jù)類型和輸入順序是否一致。檢查全局變量是否被正確的定義和使用等。
7)確認(rèn)測試:是否接受有效輸入數(shù)據(jù)(操作),拒絕無效數(shù)據(jù)(操作)。
8)事務(wù)測試:輸入->輸出,錯誤處理。
一般來說,做單元測試均采用的是商用的測試工具或自行開發(fā)的測試工具,用例的編寫都是在測試工具上完成,測試用例都是一些測試腳本,都以文件的方式來保存,故其用例的執(zhí)行過程主要是由測試工具根據(jù)所編寫的具體的測試用例腳本來完成,這樣對于用例的管理和執(zhí)行也非常靈活。
在特定場合,比如某種壓力測試或極限測試,對于測試執(zhí)行過程時間很長時(幾個小時以上),一般都預(yù)先編寫好用例(確保用例無誤),使用空閑機(jī)或非工作時間執(zhí)行測試用例,這樣操作起來較節(jié)約時間。
在用例的執(zhí)行過程中務(wù)必注意如下事項:
  •  程序的執(zhí)行過程―――便于構(gòu)造發(fā)散用例
  • 不要放過任何細(xì)節(jié)―――這種細(xì)節(jié)可能就是問題

 

在測試的過程中為了提高測試效率和效果,不斷的減少冗余勞動,也為后期的回歸測試和測試管理帶來很大的方便,不至于感到測試很混亂無序。因此我們要對測試用例和測試執(zhí)行進(jìn)行不斷的優(yōu)化,以測試策略為指導(dǎo)方針進(jìn)行測試。【文章來源:文斯測試技術(shù)研究中心 http://blog.csdn.net/vincetest

1、測試用例的優(yōu)化

    測試用例的優(yōu)化主要是指用例的合并、修改和刪除,減少冗余的無價值的測試,其優(yōu)化依據(jù)來源于測試后的測試數(shù)據(jù)分析和評估,其中測試覆蓋也是用例優(yōu)化的主要參考。

2、測試執(zhí)行的優(yōu)化

        測試執(zhí)行的優(yōu)化主要是指測試步驟的優(yōu)化,減少測試人員的手工操作,因為太多的手工操作會導(dǎo)致測試人員很厭倦,直接影響測試效果,優(yōu)化依據(jù)來源于測試總結(jié)。
3、測試策略
    在測試過程中由于時間或資源的原因可能會使測試處于緊張的局面,在此情況下我們要采取一定的策略來解決此局面。策略來源于測試數(shù)據(jù)的分析,主要的方法是:為各模塊制定測試優(yōu)先級,其優(yōu)先級的劃分依據(jù)如下:
  • 哪些是重點(diǎn)模塊?
  •  哪些程序是最復(fù)雜、最容易出錯的?
  •  哪些程序是相對獨(dú)立,應(yīng)當(dāng)提前測試的?
  •  哪些程序最容易擴(kuò)散錯誤?
  • 哪些程序是開發(fā)者最沒有信心的?
  •  80-20原則:80%的缺陷聚集在20%的模塊中,經(jīng)常出錯的模塊改錯后還會經(jīng)常出錯,這種應(yīng)該列入測試重點(diǎn)。【文章來源:文斯測試技術(shù)研究中心 http://blog.csdn.net/vincetest

 

   單元測試完成以后,需要對單元測試的執(zhí)行效果進(jìn)行評估,主要從以下幾方面進(jìn)行:
1)測試完備性評估,主要檢查測試過程中是否已經(jīng)執(zhí)行了所有的測試用例,對新增的測試用例是否已及時更新測試方案等。
2)代碼覆蓋率評估,主要是根據(jù)代碼覆蓋率工具提供的語句覆蓋情況報告,檢查是否達(dá)到方案中的要求,公司要求語句覆蓋達(dá)到100%。但很多情況下,第一輪測試用例執(zhí)行完后是很難達(dá)到的,這時在評估過程中要對覆蓋率進(jìn)行分析,主要從以下方面來考慮:
  • 不可能的路徑或條件
  • 不可達(dá)的或冗余的代碼
  • 不充分的測試用例
3) 從覆蓋的角度看,測試應(yīng)該覆蓋:
  •  功能覆蓋
  •  輸入域覆蓋
  • 輸出域覆蓋
  • 函數(shù)交互覆蓋
  • 代碼執(zhí)行覆蓋
   大多數(shù)有效的測試用例都來自于分析,而不是僅僅為了達(dá)到測試覆蓋率目標(biāo)而草率設(shè)計測試用例。千萬不要誤解測試覆蓋,測試覆蓋并不是我們最求的目的,它只是評價測試的一種方式,為測試提供指導(dǎo)和依據(jù)。
1.測試過程中各種人員的作用
  • 系統(tǒng)分析設(shè)計人員
     進(jìn)行需求跟蹤,確保系統(tǒng)需求的實現(xiàn)和更新。進(jìn)行軟件單元可測性分析,確定單元測試的對象、范圍和方法。【文章來源:文斯測試技術(shù)研究中心 http://blog.csdn.net/vincetest
  • 軟件開發(fā)人員
     負(fù)責(zé)編碼和單元測試過程,完成單元測試計劃、方案和報告。
  • 軟件測試人員
     參與單元測試計劃、方案和報告的評審,對單元測試的計劃、設(shè)計和執(zhí)行質(zhì)量進(jìn)行監(jiān)控。根據(jù)實際情況,可選擇參與由開發(fā)人員負(fù)責(zé)的代碼檢視、單元測試等活動。
  •  配置管理人員
    對代碼及單元測試文檔進(jìn)行配置管理。
  • 質(zhì)量保證(QA)人員
     參與編碼與單元測試評審,對編碼和單元測試過程進(jìn)行審計。
2.  單元測試輸入
  • 《軟件需求規(guī)格說明書》
  • 《軟件詳細(xì)設(shè)計說明書》
  • 《軟件編碼與單元測試工作任務(wù)書》
  • 《軟件集成測試計劃》
  • 《軟件集成測試方案》
  • 用戶文檔
3.單元測試的輸出
  • 《單元測試計劃》
  • 《單元測試方案》
  • 《需求跟蹤說明書》或需求跟蹤記錄
  •  代碼靜態(tài)檢查記錄
  • 《正規(guī)檢視報告》
  •  問題記錄
  •  問題跟蹤和解決記錄
  • 軟件代碼開發(fā)版本
  • 《單元測試報告》
  • 《軟件編碼與單元測試任務(wù)總結(jié)報告》

 

1.  單元測試實施步驟
1)        制定測試計劃和測試方案(包括測試工具的選擇)
2)        根據(jù)計劃和方案及相關(guān)輸入文檔編寫測試用例
3)        搭建測試環(huán)境
4)        執(zhí)行測試
5)        記錄和跟蹤問題
6)        編寫測試報告和總結(jié)報告
2.  單元測試實施遵循的原則
  •  精心制定測試計劃
  •  嚴(yán)格評審測試計劃
  •  嚴(yán)格執(zhí)行測試計劃
  • 系統(tǒng)分析測試結(jié)果并提交報告


 
常用的C語言單元測試工具介紹如下:
1.         VcTester
1)        簡介
VcTester是與VC(注:Visual C++及VisualStudio開發(fā)套件是微軟發(fā)布的產(chǎn)品)配套使用的新一代單元測試工具,分共享版與商用版兩大系列,其主要功能包括:腳本化測試驅(qū)動(包括修改變量與調(diào)用函數(shù))、腳本樁、支持持續(xù)集成測試、測試覆蓋率統(tǒng)計(僅商用版本)、生成測試報告(僅商用版本)、測試消息編輯器(僅商用版本)等。
2)        功能特性
  • 腳本化測試驅(qū)動
  • 腳本樁
  •  在線測試
  •  即時調(diào)測
  • 測試工程管理
3)        價格
共享版免費(fèi)
4)        相關(guān)網(wǎng)站
2.         C++Test
1)        簡介
C++Test是一個功能強(qiáng)大的自動化C/C++單元級測試工具,可以自動測試任何C/C++函數(shù)、類,自動生成測試用例、測試驅(qū)動函數(shù)或樁函數(shù),在自動化的環(huán)境下極其容易快速的將單元級的測試覆蓋率達(dá)到100%。
2)        功能特性【文章來源:文斯測試技術(shù)研究中心 http://blog.csdn.net/vincetest
  •   即時測試類/函數(shù)
  • 支持極端編程模式下的代碼測試
  • 自動建立類/函數(shù)的測試驅(qū)動程序和樁調(diào)用
  • 自動建立和執(zhí)行類/函數(shù)的測試用例
  • 提供快速加入和執(zhí)行說明和功能性測試的框架
  •  執(zhí)行自動回歸測試
  •  執(zhí)行部件測試(COM)
3)        價格
不詳【文章來源:文斯測試技術(shù)研究中心 http://blog.csdn.net/vincetest
4)        相關(guān)網(wǎng)站

歡迎轉(zhuǎn)載此文,轉(zhuǎn)載時請注明文章來源:文斯測試技術(shù)研究中心 http://blog.csdn.net/vincetest

本站僅提供存儲服務(wù),所有內(nèi)容均由用戶發(fā)布,如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容,請點(diǎn)擊舉報。
打開APP,閱讀全文并永久保存 查看更多類似文章
猜你喜歡
類似文章
單元測試測什么?
軟件測試基礎(chǔ)
單元測試的任務(wù)
詳細(xì)講解單元測試的內(nèi)容
單元測試詳解
黑盒測試和白盒測試的區(qū)別
更多類似文章 >>
生活服務(wù)
分享 收藏 導(dǎo)長圖 關(guān)注 下載文章
綁定賬號成功
后續(xù)可登錄賬號暢享VIP特權(quán)!
如果VIP功能使用有故障,
可點(diǎn)擊這里聯(lián)系客服!

聯(lián)系客服