導航:首頁 > 編程大全 > cantata測試工具

cantata測試工具

發布時間:2023-10-21 21:07:42

Ⅰ 針對c語言的程序,有什麼好的測試工具

部分白盒測試工具介紹

Parasoft白盒測試工具集

Jtest java 代碼分析和動態類、組件測試

Jcontract Java 實時性能監控以及分析優化

C++ Test C,C++ 代碼分析和動態測試

CodeWizard C,C++ 代碼靜態分析

Insure++ C,C++ 實時性能監控以及分析優化

其它公司

.test .Net 代碼分析和動態測試

logiscope c/c++ Verlog公司的靜態、動態分析工具

還有testbed、Cantata c/c++等

Rational工具集中的puricoverage和purify、quantify

Compuware白盒測試工具集

BoundsChecker C++,Delphi API和OLE錯誤檢查、指針和泄露錯誤檢查、內存錯誤檢查

TrueTime C++,Java,Visual Basic 代碼運行效率檢查、組件性能的分析

FailSafe Visual Basic 自動錯誤處理和恢復系統

Jcheck M$ Visual J++ 圖形化的純種和事件分析工具

TrueCoverage C++,Java,Visual Basic 函數調用次數、所佔比率統計以及穩定性跟蹤

SmartCheck Visual Basic 函數調用次數、所佔比率統計以及穩定性跟蹤

CodeReview Visual Basic 自動源代碼分析工具

Xunit白盒測試工具集

Aunit Ada http://www.libre.act-europe.fr

CppUnit C++ http://cppunit.sourceforge.net

ComUnit VB,COM http://comunit.sourceforge.net

Dunit Delphi http://nit.sourceforge.net

DotUnit .Net http://dotunit.sourceforge.net

HttpUnit Web http://c2.com/cgi/wiki?HttpUnit

HtmlUnit Web http://htmlunit.sourceforge.net

Jtest Java http://www.junit.org

jsUnit(Hieatt) javascript 1.4以上 http://www.jsunit.net

PhpUnit Php http://phpunit.sourceforge.net

PerlUnit Perl http://perlunit.sourceforge.net

XmlUnit Xml http://xmlunit.sourceforge.net

DUnit .net

JUnit java

Ⅱ 軟體測試一般都用到哪些工具

常用的軟體測試工具一般是:QTP+LoadRunner+QC

軟體測試中還需的工具如下:

  1. 功能測試工具:QTP(HP),WinRunner(MI),Robort(IBM),QARun(Compuware)

  2. 性能測試工具:LoadRunner(HP),WAS(MS),Robort(IBM)【必須下載相應的插件才支持性能方面的測試】,QALoad(Compuware)

  3. 測試管理工具:TestDirector/Quarlity Center【這兩個工具一個橫版一個豎版,功能完全一樣】,Rational TestManager

  4. 缺陷跟蹤工具:Bugzilla、Mantis

  5. 其他:Rational Purify、Rational PureCoverager

一般測試流程:

  1. 需求分析階段:只要就是對業務的學習,分析需求點。

  2. 測試計劃階段:測試組長就要根據SOW開始編寫《測試計劃》,其中包括人員,軟體硬體資源,測試點,集成順序,進度安排和風險識別等內容。

  3. 測試設計階段:測試方案一般由對需求很熟的高資深的測試工程師設計,測試方案要求根據《SRS》上的每個需求點設計出包括需求點簡介,測試思路和詳細測試方法三部分的方案。《測試方案》編寫完成後也需要進行評審。

  4. 測試方案階段:主要是對測試用例和規程的設計。測試用例是根據《測試方案》來編寫的,通過《測試方案》階段,測試人員對整個系統需求有了詳細的理解。這時開始編寫用例才能保證用例的可執行和對需求的覆蓋。測試用例需要包括測試項,用例級別,預置條件,操作步驟和預期結果。其中操作步驟和預期結果需要編寫詳細和明確。測試用例應該覆蓋測試方案,而測試方案又覆蓋了測試需求點,這樣才能保證客戶需求不遺漏。同樣,測試用例也需要評審。

  5. 測試執行階段:執行測試用例,及時提交有質量的Bug和測試日報,測試報告等相關文檔

Ⅲ 什麼是單元測試

單元測試(模塊測試)是開發者編寫的一小段代碼,用於檢驗被測代碼的一個很小的、很明確的功能是否正確。通常而言,一個單元測試是用於判斷某個特定條件(或者場景)下某個特定函數的行為。例如,你可能把一個很大的值放入一個有序list 中去,然後確認該值出現在list 的尾部。或者,你可能會從字元串中刪除匹配某種模式的字元,然後確認字元串確實不再包含這些字元了。 單元測試是由程序員自己來完成,最終受益的也是程序員自己。可以這么說,程序員有責任編寫功能代碼,同時也就有責任為自己的代碼編寫單元測試。執行單元測試,就是為了證明這段代碼的行為和我們期望的一致。 工廠在組裝一台電視機之前,會對每個元件都進行測試,這,就是單元測試。 其實我們每天都在做單元測試。你寫了一個函數,除了極簡單的外,總是要執行一下,看看功能是否正常,有時還要想辦法輸出些數據,如彈出信息窗口什麼的,這,也是單元測試,老納把這種單元測試稱為臨時單元測試。只進行了臨時單元測試的軟體,針對代碼的測試很不完整,代碼覆蓋率要超過70%都很困難,未覆蓋的代碼可能遺留大量的細小的錯誤,這些錯誤還會互相影響,當BUG暴露出來的時候難於調試,大幅度提高後期測試和維護成本,也降低了開發商的競爭力。可以說,進行充分的單元測試,是提高軟體質量,降低開發成本的必由之路。 對於程序員來說,如果養成了對自己寫的代碼進行單元測試的習慣,不但可以寫出高質量的代碼,而且還能提高編程水平。 要進行充分的單元測試,應專門編寫測試代碼,並與產品代碼隔離。老納認為,比較簡單的辦法是為產品工程建立對應的測試工程,為每個類建立對應的測試類,為每個函數(很簡單的除外)建立測試函數。首先就幾個概念談談老納的看法。 一般認為,在結構化程序時代,單元測試所說的單元是指函數,在當今的面向對象時代,單元測試所說的單元是指類。以老納的實踐來看,以類作為測試單位,復雜度高,可操作性較差,因此仍然主張以函數作為單元測試的測試單位,但可以用一個測試類來組織某個類的所有測試函數。單元測試不應過分強調面向對象,因為局部代碼依然是結構化的。單元測試的工作量較大,簡單實用高效才是硬道理。 有一種看法是,只測試類的介面(公有函數),不測試其他函數,從面向對象角度來看,確實有其道理,但是,測試的目的是找錯並最終排錯,因此,只要是包含錯誤的可能性較大的函數都要測試,跟函數是否私有沒有關系。對於C++來說,可以用一種簡單的方法區隔需測試的函數:簡單的函數如數據讀寫函數的實現在頭文件中編寫(inline函數),所有在源文件編寫實現的函數都要進行測試(構造函數和析構函數除外)。 為什麼要使用單元測試 我們編寫代碼時,一定會反復調試保證它能夠編譯通過。如果是編譯沒有通過的代碼,沒有任何人會願意交付給自己的老闆。但代碼通過編譯,只是說明了它的語法正確;我們卻無法保證它的語義也一定正確,沒有任何人可以輕易承諾這段代碼的行為一定是正確的。 幸運,單元測試會為我們的承諾做保證。編寫單元測試就是用來驗證這段代碼的行為是否與我們期望的一致。有了單元測試,我們可以自信的交付自己的代碼,而沒有任何的後顧之憂。 什麼時候測試?單元測試越早越好,早到什麼程度?XP開發理論講究TDD,即測試驅動開發,先編寫測試代碼,再進行開發。在實際的工作中,可以不必過分強調先什麼後什麼,重要的是高效和感覺舒適。從老納的經驗來看,先編寫產品函數的框架,然後編寫測試函數,針對產品函數的功能編寫測試用例,然後編寫產品函數的代碼,每寫一個功能點都運行測試,隨時補充測試用例。所謂先編寫產品函數的框架,是指先編寫函數空的實現,有返回值的隨便返回一個值,編譯通過後再編寫測試代碼,這時,函數名、參數表、返回類型都應該確定下來了,所編寫的測試代碼以後需修改的可能性比較小。 由誰測試?單元測試與其他測試不同,單元測試可看作是編碼工作的一部分,應該由程序員完成,也就是說,經過了單元測試的代碼才是已完成的代碼,提交產品代碼時也要同時提交測試代碼。測試部門可以作一定程度的審核。 關於樁代碼,老納認為,單元測試應避免編寫樁代碼。樁代碼就是用來代替某些代碼的代碼,例如,產品函數或測試函數調用了一個未編寫的函數,可以編寫樁函數來代替該被調用的函數,樁代碼也用於實現測試隔離。採用由底向上的方式進行開發,底層的代碼先開發並先測試,可以避免編寫樁代碼,這樣做的好處有:減少了工作量;測試上層函數時,也是對下層函數的間接測試;當下層函數修改時,通過回歸測試可以確認修改是否導致上層函數產生錯誤。 在一種傳統的結構化編程語言中,比如C,要進行測試的單元一般是函數或子過程。在象C++這樣的面向對象的語言中, 要進行測試的基本單元是類。對Ada語言來說,開發人員可以選擇是在獨立的過程和函數,還是在Ada包的級別上進行單元測試。單元測試的原則同樣被擴展到第四代語言(4GL)的開發中,在這里基本單元被典型地劃分為一個菜單或顯示界面。 單元測試不僅僅是作為無錯編碼一種輔助手段在一次性的開發過程中使用,單元測試必須是可重復的,無論是在軟體修改,或是移植到新的運行環境的過程中。因此,所有的測試都必須在整個軟體系統的生命周期中進行維護。 經常與單元測試聯系起來的另外一些開發活動包括代碼走讀(Code review),靜態分析(Static analysis)和動態分析(Dynamic analysis)。靜態分析就是對軟體的源代碼進行研讀,查找錯誤或收集一些度量數據,並不需要對代碼進行編譯和執行。動態分析就是通過觀察軟體運行時的動作,來提供執行跟蹤,時間分析,以及測試覆蓋度方面的信息。 一些流行的誤解 在明確了什麼是單元測試以後,我們可以進行"反調論證"了。在下面的章節里,我們列出了一些反對單元測試的普遍的論點。然後用充分的理由來證明這些論點是不足取的。 它浪費了太多的時間
一旦編碼完成,開發人員總是會迫切希望進行軟體的集成工作,這樣他們就能夠看到實際的系統開始啟動工作了。 這在外表上看來是一項明顯的進步,而象單元測試這樣的活動也許會被看作是通往這個階段點的道路上的障礙, 推遲了對整個系統進行聯調這種真正有意思的工作啟動的時間。 在這種開發步驟中,真實意義上的進步被外表上的進步取代了。系統能夠正常工作的可能性是很小的,更多的情況是充滿了各式各樣的Bug。在實踐中,這樣一種開發步驟常常會導致這樣的結果:軟體甚至無法運行。更進一步的結果是大量的時間將被花費在跟蹤那些包含在獨立單元里的簡單的Bug上面,在個別情況下,這些Bug也許是瑣碎和微不足道的,但是總的來說,他們會導致在軟體集成為一個系統時增加額外的工期, 而且當這個系統投入使用時也無法確保它能夠可靠運行。 在實踐工作中,進行了完整計劃的單元測試和編寫實際的代碼所花費的精力大致上是相同的。一旦完成了這些單元測試工作,很多Bug將被糾正,在確信他們手頭擁有穩定可靠的部件的情況下,開發人員能夠進行更高效的系統集成工作。這才是真實意義上的進步,所以說完整計劃下的單元測試是對時間的更高效的利用。而調試人員的不受控和散漫的工作方式只會花費更多的時間而取得很少的好處。 使用AdaTEST和Cantata這樣的支持工具可以使單元測試更加簡單和有效。但這不是必須的,單元測試即使是在沒有工具支持的情況下也是一項非常有意義的活動。 它僅僅是證明這些代碼做了什麼
這是那些沒有首先為每個單元編寫一個詳細的規格說明而直接跳到編碼階段的開發人員提出的一條普遍的抱怨, 當編碼完成以後並且面臨代碼測試任務的時候,他們就閱讀這些代碼並找出它實際上做了什麼,把他們的測試工作基於已經寫好的代碼的基礎上。當然,他們無法證明任何事情。所有的這些測試工作能夠表明的事情就是編譯器工作正常。是的,他們也許能夠抓住(希望能夠)罕見的編譯器Bug,但是他們能夠做的僅僅是這些。 如果他們首先寫好一個詳細的規格說明,測試能夠以規格說明為基礎。代碼就能夠針對它的規格說明,而不是針對自身進行測試。這樣的測試仍然能夠抓住編譯器的Bug,同時也能找到更多的編碼錯誤,甚至是一些規格說明中的錯誤。好的規格說明可以使測試的質量更高,所以最後的結論是高質量的測試需要高質量的規格說明。 在實踐中會出現這樣的情況: 一個開發人員要面對測試一個單元時只給出單元的代碼而沒有規格說明這樣吃力不討好的任務。你怎樣做才會有更多的收獲,而不僅僅是發現編譯器的Bug?第一步是理解這個單元原本要做什麼, --- 不是它實際上做了什麼。 比較有效的方法是倒推出一個概要的規格說明。這個過程的主要輸入條件是要閱讀那些程序代碼和注釋, 主要針對這個單元, 及調用它和被它調用的相關代碼。畫出流程圖是非常有幫助的,你可以用手工或使用某種工具。 可以組織對這個概要規格說明的走讀(Review),以確保對這個單元的說明沒有基本的錯誤, 有了這種最小程度的代碼深層說明,就可以用它來設計單元測試了。 我是個很棒的程序員, 我是不是可以不進行單元測試?
在每個開發組織中都至少有一個這樣的開發人員,他非常擅長於編程,他們開發的軟體總是在第一時間就可以正常運行,因此不需要進行測試。你是否經常聽到這樣的借口? 在真實世界裡,每個人都會犯錯誤。即使某個開發人員可以抱著這種態度在很少的一些簡單的程序中應付過去。 但真正的軟體系統是非常復雜的。真正的軟體系統不可以寄希望於沒有進行廣泛的測試和Bug修改過程就可以正常工作。 編碼不是一個可以一次性通過的過程。在真實世界中,軟體產品必須進行維護以對操作需求的改變作出反應, 並且要對最初的開發工作遺留下來的Bug進行修改。你希望依靠那些原始作者進行修改嗎? 這些製造出這些未經測試的原始代碼的資深專家們還會繼續在其他地方製造這樣的代碼。在開發人員做出修改後進行可重復的單元測試可以避免產生那些令人不快的負作用。

Ⅳ 怎樣測試一個程序的速度

其實很多是有測試工具可以幫你完成的,看你要測試什麼了,不同的程序有對應的軟體,給你列舉些:
廠商 工具名稱
Mercury Winrunner
Mercury Quicktest pro
Mercury XRunner
Compuware QARun
Compuware WebCheck
Compuware TestPartner
Parasoft WebKing
IBM Rational Robot
IBM Rational Visual Test
IBM Rational Functional Tester
Segue SilkTest
Segue SilkTest International
Empirix e-Tester
Radview WebFT
AutomatedQA TestComplete
Seapine QA Wizard
RedStone Software EggPlant
Microsoft Visual Studio Test Edition
Minq PureTest
Autotester Autotester
Original Software Testbench400
VEReCOMM TestExpert
Qronus TestRunner
Telelogic TTCN suite
Centerline QC/Replay
AutoTester Web
Software Research eValid
OCLC WebART
開源 MaxQ
開源 WebInject
開源 Marathon
性能測試/監控工具

廠商 工具名稱
Mercury LoadRunner
Mercury SiteScope
Mercury Topaz
Compuware QaLoad
Quest PerformaSure/benchmark
Segue Silkperformer
Segue Silkperformer Lite
Segue SilkCentralTM Performance Manager
Empirix e-Load
IBM Rational Robot
IBM Rational Performance Tester
RadView WebLoad
Microsoft Web applicaton stress tool
Microsoft Application center test
Minq PureLoad
Metron Athene APR
facilita ForeCast
Cyrano Impact/Impact for CBT
Lawrence Berkeley Laboratory sniffer
開源 Jmeter
開源 openSTA
開源 Siege
開源 StressMark
開源 DBMonster
白盒測試/代碼分析工具

廠商 工具名稱
Parasoft Jtest
Parasoft C++test
Parasoft SOA test
Parasoft .test
Parasoft Codewizard
Parasoft Insure++
Parasoft DataRecon
Compuware Numega devpartner studio
Compuware DevPartnerJavaEdition
Compuware BoundsChecker
Compuware SmartCheck
Compuware DBPartner
Empirix Bean-test
AutomatedQA AQtime
AutomatedQA QESatJava
Unitware Visual Unit
Gimpel Software PC-lint
Macabe Macabe
Borland Optimizeit Suite
Quest Software JProbe Suite
Quest Software Application assurance suite
Quest Software Sql optimizer
ej-technologies JProfiler
cyrano workbench
TeleLogic Logiscope
TeleLogic rulecheck
Macabe Macabe
Segue SilkPerformer Component Test Edition
IBM rational Purifyplus
IBM rational Rational Test Realtime
開源 junit
開源 cactus
開源 Hansel
開源 TestNG
開源 StrutsTestCase
開源 JFCUnit
開源 Httpunit
開源 Dunit
開源 cppunit
開源 Nunit
開源 Xunit
開源 JTR
Linux平台工具 MallocDebug
Linux平台工具 Valgrind
Linux平台工具 Kcachegrind
Linux平台工具 dmalloc
Linux平台工具 ElectricFence
Linux平台工具 LeakTracer
Linux平台工具 memprof
Linux平台工具 ccmalloc
Linux平台工具 mprof
Linux平台工具 yamd
Linux平台工具 njamd
Linux平台工具 mpatrol
嵌入式系統測試工具

廠商 工具名稱
Metrowerks codetest
IPL Cantata/cantana++
Reflex Technology IceMaster
Reflex Technology System test
DDC-I scorecast
testquest Testquest
ATTOL UniText
Vector software vectorcast
qronus testrunner
telelogic Logiscope
RT-Builder
測試管理工具

廠商 工具名稱
Mercury TestDirector(QualityCenter)
Compuware QADirector
worksoft certify
aimware Proct manager
segue SilkCentral Test Manager
telelogic Doors
empirix e-manager
IBM Rational testmanager
RadView TestView Manager
T-Plan Professional
testlink

缺陷管理工具

廠商 工具名稱
Mercury TestDirector(QualityCenter)
IBM Rational ClearQuest
Compuware TrackRecord
Seapine TestTrack pro
McCabe TrueTrack
Techexcel Devtrack
IBM Lotus Notes
Segue SilkCentral Issue Manager
Merant PVCS Tracker
Remedy AR System
LealSoft URTrack
缺陷管理系統BMS
Clarion
Hansky Butterfly
開源 Bugzilla
開源 Mantis
開源 JIRA
開源 BugFree
配置管理工具

廠商 工具名稱
IBM Rational ClearCase
Merant PVCS Version Manager
Diamond VCS
Computer Associates AllFusion Harvest Change Manager/CCC Harvest
Borland StarTeam
MKS Source Integrity Enterprise and Integrity Manager
Serena ChangeMan Professional
Perforce Perforce
McCabe TRUEchange
Telelogic SYNERGY CM
Microsoft VSS
JBCM
Hansky Firefly
開源 CVS
開源 subversion
開源 SCCS
開源 RCS

閱讀全文

與cantata測試工具相關的資料

熱點內容
win10最新預覽版續航 瀏覽:705
web伺服器更新代碼 瀏覽:603
u盤裝msdnwin10 瀏覽:135
電子表格列印有內容但是打開文件沒內容 瀏覽:788
大數據分析如何做好 瀏覽:819
拉美數據中心在哪裡 瀏覽:797
office2007診斷工具 瀏覽:83
紅眼去除工具 瀏覽:405
手機語言編程用什麼鍵盤 瀏覽:599
java環境已配置好了找不到文件 瀏覽:565
w10系統修改文件格式 瀏覽:179
桌面怎麼把兩個文件夾壓縮成一個 瀏覽:293
u盤為什麼存文件這么慢 瀏覽:807
手機的下拉菜單代碼 瀏覽:384
寧波ug編程培訓中心哪裡好 瀏覽:565
描述性別是屬於什麼數據 瀏覽:752
聽力障礙人群用哪些app 瀏覽:932
中國郵政ems微信號 瀏覽:699
win10刪除更新補丁 瀏覽:870
哪裡有賣二手電筒腦的app 瀏覽:139

友情鏈接