嵌入式測試主要涉及哪些內(nèi)容
嵌入式測試主要包含功能測試和性能測試。即是否滿足功能/非功能需求的測試。
細(xì)分的話有模塊測試和系統(tǒng)測試，涉及測試設(shè)計，腳本編寫，軟硬件仿真等內(nèi)容，其中還有黑盒測試和白盒測試，涉及內(nèi)容一點不比開發(fā)少。
一般來說，軟件測試有7個基本階段，即單元或模塊測試、集成測試、外部功能測試、回歸測試、系統(tǒng)測試、驗收測試、安裝測試。嵌入式軟件測試在4個階段上進(jìn)行，即模塊測試、集成測試、系統(tǒng)測試、硬件/軟件集成測試。前3個階段適用于任何軟件的測試，硬件/軟件集成測試階段是嵌入式軟件所特有的，目的是驗證嵌入式軟件與其所控制的硬件設(shè)備能否正確地交互。
什么是 嵌入式軟件測試求答案
一、嵌入式軟件的測試方法 一般來說，軟件測試有7個基本階段，即單元或模塊測試、集成測試、外部功能測試、回歸測試、系統(tǒng)測試、驗收測試、安裝測試。嵌入式軟件測試在4個階段上進(jìn)行，即模塊測試、集成測試、系統(tǒng)測試、硬件/軟件集成測試。前3個階段適用于任何軟件的測試，硬件/軟件集成測試階段是嵌入式軟件所特有的，目的是驗證嵌入式軟件與其所控制的硬件設(shè)備能否正確地交互。 1、白盒測試與黑盒測試 一般來說，軟件測試有兩種基本的方式，即白盒測試方法與黑盒測試方法，嵌入式軟件測試也不例外。 白盒測試或基本代碼的測試檢查程序的內(nèi)部設(shè)計。根據(jù)源代碼的組織結(jié)構(gòu)查找軟件缺陷，一股要求測試人員對軟件的結(jié)構(gòu)和作用有詳細(xì)的了解，白盒測試與代碼覆蓋率密切相關(guān)，可以在白盒測試的同時計算出測試的代碼的覆蓋率，保證測試的充分性。把100％的代碼都測試到幾乎是不可能的， 所以要選擇最重要的代碼進(jìn)行白盒測試。由于嚴(yán)格的安全性和可靠性的要求，嵌入式軟件測試同非嵌入式軟件測試相比，通常要求有更高的代碼覆蓋率。對于嵌入式軟件，白盒測試一般不必在目標(biāo)硬件上進(jìn)行，更為實際的方式是在開發(fā)環(huán)境中通過硬件仿真進(jìn)行，所以選取的測試工具應(yīng)該支持在宿主環(huán)境中的測試。 黑盒測試在某些情況下也稱為功能測試。這類測試方法根據(jù)軟件的用途和外部特征查找軟件缺陷，不需要了解程序的內(nèi)部結(jié)構(gòu)。黑盒測試最大的優(yōu)勢在于不依賴代碼，而是從實際使用的角度進(jìn)行測試，通過黑盒測試可以發(fā)現(xiàn)白盒測試發(fā)現(xiàn)不了的問題。因為黑盒測試與需求緊密相關(guān)，需求規(guī)格說明的質(zhì)量會直接影響測試的結(jié)果，黑盒測試只能限制在需求的范圍內(nèi)進(jìn)行。在進(jìn)行嵌入式軟件黑盒測試時，要把系統(tǒng)的預(yù)期用途作為重要依據(jù)，根據(jù)需求中對負(fù)載、定時、性能的要求，判斷軟件是否滿足這些需求規(guī)范。為了保證正確地測試，還須要檢驗軟硬件之間的接口。嵌入式軟件黑盒測試的一個重要方面是極限測試。在使用環(huán)境中，通常要求嵌入式軟件的失效過程要平穩(wěn)，所以，黑盒測試不儀要檢查軟件工作過程，也要檢查軟件換效過程。 2、目標(biāo)環(huán)境測試和宿主環(huán)境測試 在嵌入式軟件測試中，常常要在基于目標(biāo)的測試和基于宿主的測試之間作出折衷。基于目標(biāo)的測試消耗較多的經(jīng)費和時間，而基于宿主的測試代價較小，但畢竟是在模擬環(huán)境中進(jìn)行的。目前的趨勢是把更多的測試轉(zhuǎn)移到宿主環(huán)境中進(jìn)行，但是，目標(biāo)環(huán)境的復(fù)雜性和獨特性不可能完全模擬。 在兩個環(huán)境中可以出現(xiàn)不同的軟件缺陷，重要的是目標(biāo)環(huán)境和宿主環(huán)境的測試內(nèi)容有所選擇。在宿主環(huán)境中，可以進(jìn)行邏輯或界面的測試、以及與硬件無關(guān)的測試。在模擬或宿主環(huán)境中的測試消耗時間通常相對較少，用調(diào)試工具可以更快地完成調(diào)試和測試任務(wù)。而與定時問題有關(guān)的白盒測試、中斷測試、硬件接口測試只能在目標(biāo)環(huán)境中進(jìn)行。在軟件測試周期中，基于目標(biāo)的測試是在較晚的“硬件/軟件集成測試”階段開始的，如果不更早地在模擬環(huán)境中進(jìn)行白盒測試，而是等到“硬件/軟件集成測試”階段進(jìn)行全部的白盒測試，將耗費更多的財力和人力。二、嵌入式軟件的測試工具 用于輔助嵌入式軟件測試的工具很多，下面對幾類比較有用的有關(guān)嵌入式軟件的測試工具加以介紹和分析。 1、內(nèi)存分析工具 在嵌入式系統(tǒng)中，內(nèi)存約束通常是有限的。內(nèi)存分析工具用來處理在動態(tài)內(nèi)存分配中存在的缺陷。當(dāng)動態(tài)內(nèi)存被錯誤地分配后，通常難以再現(xiàn)，可能導(dǎo)致的失效難以追蹤，使用內(nèi)存分析工具可以避免這類缺陷進(jìn)入功能測試階段。目前有兩類內(nèi)存分析工具——軟件和硬件的?；谲浖膬?nèi)存分析工具可能會對代碼的性能造成很大影響，從而嚴(yán)重影響實時操作；基于硬件的內(nèi)存分析工具價格昂貴，而且只能在工具所限定的運行環(huán)境中使用。 2、性能分析工具 在嵌入式系統(tǒng)中，程序的性能通常是非常重要的。經(jīng)常會有這樣的要求，在特定時間內(nèi)處理一個中斷，或生成具有特定定時要求的一幀。開發(fā)人面臨的問題是決定應(yīng)該對哪一部分代碼進(jìn)行優(yōu)化來改進(jìn)性能，常常會花大量的時間去優(yōu)化那些對性能沒有任何影響的代碼。性能分析工具會提供有關(guān)的數(shù)據(jù)，說明執(zhí)行時間是如何消耗的，是什么時候消耗的，以及每個例程所用的時間。根據(jù)這些數(shù)據(jù)，確定哪些例程消耗部分執(zhí)行時間，從而可以決定如何優(yōu)化軟件，獲得更好的時間性能。對于大多數(shù)應(yīng)用來說，大部分執(zhí)行時間用在相對少量的代碼上，費時的代碼估計占所有軟件總量的5%-20%。性能分析工具不僅能指出哪些例程花費時間，而且與調(diào)試工具聯(lián)合使用可以引導(dǎo)開發(fā)人員查看需要優(yōu)化的特定函數(shù)，性能分析工具還可以引導(dǎo)開發(fā)人員發(fā)現(xiàn)在系統(tǒng)調(diào)用中存在的錯誤以及程序結(jié)構(gòu)上的缺陷。 3、GUI測試工具 很多嵌入式應(yīng)用帶有某種形式的圖形用戶界面進(jìn)行交互，有些系統(tǒng)性能測試足根掘用戶輸入響應(yīng)時間進(jìn)行的。GUI測試工具可以作為腳本工具有開發(fā)環(huán)境中運行測試用例，其功能包括對操作的記錄和回放、抓取屏幕顯示供以后分析和比較、設(shè)置和管理測試過程。很多嵌入式設(shè)備沒有GUI，但常常可以對嵌入式設(shè)備進(jìn)行插裝來運行GUI測試腳本，雖然這種方式可能要求對被測代碼進(jìn)行更改，但是節(jié)省了功能測試和回歸測試的時間。 4、覆蓋分析工具 在進(jìn)行白盒測試時，可以使用代碼覆蓋分析工具追蹤哪些代碼被執(zhí)行過。分析過程可以通過插裝來完成，插裝可以是在測試環(huán)境中嵌入硬件，也可以是在可執(zhí)行代碼中加入軟件，也可以是二者相結(jié)合。測試人員對結(jié)果數(shù)據(jù)加以總結(jié)，確定哪些代碼被執(zhí)行過，哪些代碼被巡漏了。覆蓋分析工具一般會提供有關(guān)功能覆蓋、分支覆蓋、條件覆蓋的信息。對于嵌入式軟件來說，代碼覆蓋分析工具可能侵入代碼的執(zhí)行，影響實時代碼的運行過程?；谟布拇a覆蓋分析工具的侵入程度要小一些，但是價格一般比較昂貴，而且限制被測代碼的數(shù)量。
三、嵌入式軟件測試策略 在嵌入式領(lǐng)域目標(biāo)系統(tǒng)的應(yīng)用系統(tǒng)日趨復(fù)雜，而由于競爭要求產(chǎn)品快速上市，開發(fā)技術(shù)日新月異，同時硬件發(fā)展的日益穩(wěn)定，而軟件故障卻日益突出，軟件的重要性逐漸引起人們的重視，越來越多的人認(rèn)識到嵌入式系統(tǒng)的測試勢在必行。提到嵌入式軟件測試，首先要簡單介紹一些軟件工程的一些觀點，現(xiàn)在，被普遍接受的軟件的定義是：軟件(software)是計算機系統(tǒng)中與硬件(hardware)相互依存的另一部分，它包括程序(program)、相關(guān)數(shù)據(jù)(data)及其說明文檔(document)。其中程序是按照事先設(shè)計的功能和性能要求執(zhí)行的指令序列；數(shù)據(jù)是是程序能正常操縱信息的數(shù)據(jù)結(jié)構(gòu)；文檔是與程序開發(fā)維護(hù)和使用有關(guān)的各種圖文資料。 對于一般商用軟件的測試，嵌入式軟件測試有其自身的特點和測試?yán)щy。 由于嵌入式系統(tǒng)的自身特點，如實時性(Real-timing)，內(nèi)存不豐富，I/O通道少，開發(fā)工具昂貴，并且與硬件緊密相關(guān)CPU種類繁多，等等。嵌入式軟件的開發(fā)和測試也就與一般商用軟件的開發(fā)和測試策略有了很大的不同，可以說嵌入式軟件是最難測試的一種軟件。 嵌入式軟件測試使用有效的測試策略是唯一的出路，它可以使開發(fā)的效率最大化，避免目標(biāo)系統(tǒng)的瓶頸，使用在線仿真器節(jié)省昂貴的目標(biāo)資源。自從出現(xiàn)高級語言，開發(fā)環(huán)境與最終運行環(huán)境通常都是存在差異的，嵌入式系統(tǒng)更是如此。開發(fā)環(huán)境被認(rèn)為是主機平臺，軟件運行環(huán)境為目標(biāo)平臺。相應(yīng)的測試為host-target測試或cross-testing。 討論嵌入式軟件測試首先就會遇到一個問題：為什么不把所有測試都放在目標(biāo)上進(jìn)行呢？因為若所有測試都放在目標(biāo)平臺上有很多不利的因素： 1）測試軟件，可能會造成與開發(fā)者爭奪時間的瓶頸，避免它只有提供更多的目標(biāo)環(huán)境。
2）目標(biāo)環(huán)境可能還不可行。
3）比起主機平臺環(huán)境，目標(biāo)環(huán)境通常是不精密的和不方便的。
4）提供給開發(fā)者的目標(biāo)環(huán)境和聯(lián)合開發(fā)環(huán)境通常是很昂貴的。
7）使用主機與目標(biāo)環(huán)境之間有什么限制（如軟件安全標(biāo)準(zhǔn)）? 任何人或組織進(jìn)行嵌入式軟件的測試都應(yīng)深入考慮以上問題，結(jié)合自身實際情況，選定合理測試策略和方案。 對于嵌入式軟件測試或叫交叉測試（cross-test），在測試的各個階段有著通用的策略： 1．單元測試 所有單元級測試都可以在主機環(huán)境上進(jìn)行，除非少數(shù)情況，特別具體指定了單元測試直接在目標(biāo)環(huán)境進(jìn)行。最大化在主機環(huán)境進(jìn)行軟件測試的比例，通過盡可能小的目標(biāo)單元訪問所有目標(biāo)指定的界面。 在主機平臺上運行測試速度比在目標(biāo)平臺上快的多，當(dāng)在主機平臺完成測試，可以在目標(biāo)環(huán)境上重復(fù)作一簡單的確認(rèn)測試，確認(rèn)測試結(jié)果在主機和目標(biāo)機上沒有被他們的不同影響。在目標(biāo)環(huán)境上進(jìn)行確認(rèn)測試將確定一些未知的，未預(yù)料到的，未說明的主機與目標(biāo)機的不同。例如，目標(biāo)編譯器可能有bug，但在主機編譯器上沒有。 2．集成測試 軟件集成也可在主機環(huán)境上完成，在主機平臺上模擬目標(biāo)環(huán)境運行，當(dāng)然在目標(biāo)環(huán)境上重復(fù)測試也是必須的，在此級別上的確認(rèn)測試將確定一些環(huán)境上的問題，比如內(nèi)存定位和分配上的一些錯誤。
在主機環(huán)境上的集成測試的使用，依賴于目標(biāo)系統(tǒng)的具體功能有多少。有些嵌入式系統(tǒng)與目標(biāo)環(huán)境耦合的非常緊密，若在主機環(huán)境做集成是不切實際的。一個大型軟件的開發(fā)可以分幾個級別的集成。低級別的軟件集成在主機平臺上完成有很大優(yōu)勢，越往后的集成越依賴于目標(biāo)環(huán)境。 3．系統(tǒng)測試和確認(rèn)測試 所有的系統(tǒng)測試和確認(rèn)測試必須在目標(biāo)環(huán)境下執(zhí)行。當(dāng)然在主機上開發(fā)和執(zhí)行系統(tǒng)測試，然后移植到目標(biāo)環(huán)境重復(fù)執(zhí)行是很方便的。對目標(biāo)系統(tǒng)的依賴性會妨礙將主機環(huán)境上的系統(tǒng)測試移植到目標(biāo)系統(tǒng)上，況且只有少數(shù)開發(fā)者會卷入系統(tǒng)測試，所以有時放棄在主機環(huán)境上執(zhí)行系統(tǒng)測試可能更方便。 確認(rèn)測試最終的實施舞臺必須在目標(biāo)環(huán)境中，系統(tǒng)的確認(rèn)必須在真實系統(tǒng)之下測試，而不能在主機環(huán)境下模擬。這關(guān)系到嵌入式軟件的最終使用。 包括恢復(fù)測試、安全測試、強度測試、性能測試，已超出了軟件測試的范疇，本文暫不討論。 使用有效的cross-test測試策略可極大的提高嵌入式軟件開發(fā)測試的水平和效率，當(dāng)然正確的測試工具使用也是必不可少的： 總結(jié)一下，應(yīng)用以上測試工具進(jìn)行.Cross-test時的策略： A)使用測試工具的插裝功能（主機環(huán)境）執(zhí)行靜態(tài)測試分析，并且為動態(tài)覆蓋測試準(zhǔn)備好一插裝好的軟件代碼。
B)使用源碼在主機環(huán)境執(zhí)行功能測試，修正軟件的錯誤和測試腳本中的錯誤。
C)使用插裝后的軟件代碼執(zhí)行覆蓋率測試，添加測試用例或修正軟件的錯誤，保證達(dá)到所要求的覆蓋率目標(biāo)。
D)在目標(biāo)環(huán)境下重復(fù)（B），確認(rèn)軟件在目標(biāo)環(huán)境中執(zhí)行測試的正確性。
E)若測試需要達(dá)到極端的完整性，最好在目標(biāo)系統(tǒng)上重復(fù)（C），確定軟件的覆蓋率沒有改變。 通常在主機環(huán)境執(zhí)行多數(shù)的測試，只是在最終確定測試結(jié)果和最后的系統(tǒng)測試才移植到目標(biāo)環(huán)境，這樣可以避免發(fā)生訪問目標(biāo)系統(tǒng)資源上的瓶頸，也可以減少在昂貴資源如在線仿真器上的費用。另外，若目標(biāo)系統(tǒng)的硬件由于某種原因而不能使用時，最后的確認(rèn)測試可以推遲直到目標(biāo)硬件可用，這為嵌入式軟件的開發(fā)測試提供了彈性。設(shè)計軟件的可移植性是成功進(jìn)行cross-test的先決條件，它通?？梢蕴岣哕浖馁|(zhì)量，并且度軟件的維護(hù)大有益處。以上所提到的測試工具，都可以通過各自的方式提供測試在主機與目標(biāo)之間的移植，從而使嵌入式軟件的測試得以方便的執(zhí)行。 使用有效的cross-test測試策略可極大的提高嵌入式軟件開發(fā)測試的水平和效率，提高嵌入式軟件的質(zhì)量。附錄：
1). HOST-TARGET的連接方法簡介：圖1-- 直接連接圖2 -- 通過仿真器連接圖3 -- 使用介質(zhì)進(jìn)行間接連接圖4 -- 使用PROM等傳遞被測軟件圖5 -- 測試的交互界面圖6 -- 無交互界面的連接四、結(jié)論 嵌入式系統(tǒng)在人類生活中發(fā)揮著重要的作用，包括飛行控制器這樣的控制系統(tǒng)，以及洗衣機這樣的家用電器。日前，嵌入式系統(tǒng)中軟件的比重越來越大，也越來越復(fù)雜，保證嵌入式軟件的可靠性正面臨嚴(yán)峻的挑戰(zhàn)。 大多數(shù)軟件測試方法都可以直接或間接地用于嵌入式軟件的測試，但是由于操作系統(tǒng)的實時和嵌入式特性，嵌入式軟件測試也面臨一些特殊的問題。雖然日前已經(jīng)有一些針對嵌入式軟件的測試和調(diào)試工具，但是在有些方面仍存在不足，包括許多任務(wù)操作系統(tǒng)的并發(fā)、非侵入式的測試和凋試、嵌入式系統(tǒng)的軟件抽象等。對于嵌入式軟件測試技術(shù)的研究人選測試工具有待開發(fā)，仍須要做很多進(jìn)一步的工作。
嵌入式軟件測試技巧有哪些？
嵌入式軟件開發(fā)過程中，一般來說，花在測試和花在編碼的時間比為3:1(實際上可能更多)。這個比例隨著你的編程和測試水平的提高而不斷下降，但不論怎樣，軟件測試對一般人來講很重要。很多年前，一位開發(fā)人員為了在對嵌入式有更深層次的理解，向Oracle詢問了這樣的一個問題:我怎么才能知道并懂得我的系統(tǒng)到底在干些什么呢? Oracle面對這個問題有些吃驚，因為在當(dāng)時沒有人這么問過，而同時代的嵌入式開發(fā)人員問的最多的大都圍繞“我怎么才能使程序跑的更快”、“什么編譯器最好”等膚淺的問題。所以，面對這個不同尋常卻異乎成熟的問題，Oracle感到欣喜并認(rèn)真回復(fù)了他:你的問題很有深度很成熟，因為只有不斷地去深入理解才有可能不斷地提高水平。并且Oracle為了鼓勵這位執(zhí)著的程序員，把１０條關(guān)于嵌入式軟件開發(fā)測試的秘訣告訴了他:
1.懂得使用工具
2.盡早發(fā)現(xiàn)內(nèi)存問題
3.深入理解代碼優(yōu)化
4.不要讓自己大海撈針
5.重現(xiàn)并隔離問題
6.以退為進(jìn)
7.確定測試的完整性
8.提高代碼質(zhì)量意味著節(jié)省時間
9.發(fā)現(xiàn)它，分析它，解決它
10.利用初學(xué)者的思維
這十條秘訣在業(yè)界廣為流傳，使很多人受益。本文圍繞這十條秘訣展開論述。
１.懂得使用工具
通常嵌入式系統(tǒng)對可靠性的要求比較高。嵌入式系統(tǒng)安全性的失效可能會導(dǎo)致災(zāi)難性的后果，即使是非安全性系統(tǒng)，由于大批量生產(chǎn)也會導(dǎo)致嚴(yán)重的經(jīng)濟(jì)損失。這就要求對嵌入式系統(tǒng)，包括嵌入式軟件進(jìn)行嚴(yán)格的測試、確認(rèn)和驗證。隨著越來越多的領(lǐng)域使用軟件和微處理器控制各種嵌入式設(shè)備，對門益復(fù)雜的嵌入式軟件進(jìn)行快速有效的測試愈加顯得重要。
就象修車需要工具一樣，好的程序員應(yīng)該能夠熟練運用各種軟件工具。不同的工具，有不同的使用范圍，有不同的功能。使用這些工具，你可以看到你的系統(tǒng)在干些什么，它又占用什么資源，它到底和哪些外界的東西打交道。讓你郁悶好幾天的問題可能通過某個工具就能輕松搞定，可惜你就是不知道。那么為什么那么多的人總是在折騰個半死之后才想到要用測試工具呢？原因很多，主要有兩個。一個是害怕，另一個是惰性。害怕是因為加入測試用具或測試模塊到代碼需要技巧同時有可能引入新的錯誤，所以他們總喜歡寄希望于通過不斷地修改重編譯代碼來消除bug,結(jié)果卻無濟(jì)于事。懶惰是因為他們習(xí)慣了使用printf之類的簡單測試手段。下面來介紹一些嵌入式常用的測試工具。
.源碼級調(diào)試器[Source-level Debugger]
這種調(diào)試器一般提供單步或多步調(diào)試、斷點設(shè)置、內(nèi)存檢測、變量查看等功能，是嵌入式調(diào)試最根本有效的調(diào)試方法。比如VxWorks TornadoII提供的gdb就屬于這一種。
.簡單實用的打印顯示工具[printf]
printf或其它類似的打印顯示工具估計是最靈活最簡單的調(diào)試工具。打印代碼執(zhí)行過程中的各種變量可以讓你知道代碼執(zhí)行的情況。但是，printf對正常的代碼執(zhí)行干擾比較大(一般printf占用CPU比較長的時間)，需要慎重使用，最好設(shè)置打印開關(guān)來控制打印。
.ICE或JTAG調(diào)試器[In-circuit Emulator]
ICE是用來仿真CPU核心的設(shè)備，它可以在不干擾運算器的正常運行情況下，實時的檢測CPU的內(nèi)部工作情況。像桌面調(diào)試軟件所提供的：復(fù)雜的條件斷點、先進(jìn)的實時跟蹤、性能分析和端口分析這些功能，它也都能提供。ICE一般都有一個比較特殊的CPU，稱為外合(bond-out)CPU。這是一種被打開了封裝的CPU，并且通過特殊的連接，可以訪問到CPU的內(nèi)部信號，而這些信號，在CPU被封裝時，是沒法“看到”的。當(dāng)和工作站上強大的調(diào)試軟件聯(lián)合使用時，ICE就能提供你所能找到的最全面的調(diào)試功能。但I(xiàn)CE同樣有一些缺點：昂貴；不能全速工作；同樣，并不是所有的CPU都可以作為外合CPU的，從另一個角度說，這些外合CPU也不大可能及時的被新出的CPU所更換。JTAG(Joint Test Action Group)雖然它最初開發(fā)出來是為了監(jiān)測IC和電路連接，但是這種串行接口擴(kuò)展了用途，包括對調(diào)試的支持。AD公司為Blackfin設(shè)計的Visual Dsp++就支持高速的 JTAG調(diào)試。
嵌入式軟件測試的軟件動態(tài)測試工具
Tessy是一個專門針對嵌入式軟件的C/C++代碼進(jìn)行單元、集成測試的工具，它可以自動化地執(zhí)行測試、評估測試結(jié)果并生成測試報告。Tessy的目標(biāo)就是：通過自動化整個測試周期，在所有測試階段完美支持針對C語言的單元測試，當(dāng)然，Tessy也同樣關(guān)注測試組織和測試管理。
在以V模型為例的開發(fā)模式中，Tessy主要處理右半部分驗證和確認(rèn)中單元/模塊測試，集成/組件測試以及系統(tǒng)測試的內(nèi)容。在V模型的開發(fā)模式中，單元測試是第一個測試活動。它阻止了每一類錯誤，比如算法錯誤，在V模式的右邊向上蔓延，這樣可以盡可能早得發(fā)現(xiàn)Bug，防止直到后面的測試過程或者直到最終用戶那里才被發(fā)現(xiàn)，單元測試有經(jīng)濟(jì)效益，越早發(fā)現(xiàn)bug越好 。
另外，Tessy也可以滿足各類標(biāo)準(zhǔn)（ISO26262、IEC 61508、 EN 50128/50129、 DO-178B、汽車SPiCE或FDA的軟件驗證通用原則）對測試的需求，比如ISO26262中各個測試等級中對模塊測試的要求可以使用Tessy來滿足，當(dāng)然Tessy本身也通過了TUeV的認(rèn)證，被證明是安全可靠的，可以在安全相關(guān)性的軟件研發(fā)過程中被使用。 自動生成測試環(huán)境：
Tessy可以自動生成測試環(huán)境驅(qū)動，選擇自動或者手動打樁以及自動生成測試用例模板，幫助客戶提高測試用例設(shè)計效率。
多種測試用例確定方式：
除了從Excel中導(dǎo)入測試用例，手動地設(shè)計測試用例外，Tessy里集成了CTE軟件，根據(jù)分類樹的方法通過Tessy自動化地關(guān)聯(lián)測試用例。
支持動態(tài)測試的各階段：
Tessy可以支持從單元測試到系統(tǒng)測試的動態(tài)測試過程各個階段，通過單元測試檢查最小單位為函數(shù)的功能，通過集成測試來測試各個子功能組合起來的模塊能否達(dá)到預(yù)期要求的父功能以及相互間的接口，通過系統(tǒng)測試實現(xiàn)與目標(biāo)板集成的測試環(huán)境來測試系統(tǒng)功能；另外Tessy可以自動發(fā)現(xiàn)被測對象的改變，分析被測對象的接口，重用測試用例和測試數(shù)據(jù)，從而為重復(fù)的回歸測試節(jié)約大量的工作和時間，在接口不變的情況下Tessy可以完全自動化地執(zhí)行不需要用戶介入的回歸測試；
全自動地測試執(zhí)行及評估；
Tessy檢查源文件并且通過分析程序代碼來確定函數(shù)以及他們的接口，這些信息將被保存在特定的數(shù)據(jù)庫中供隨時檢索，接口信息和測試數(shù)據(jù)的分離實現(xiàn)了結(jié)構(gòu)和數(shù)據(jù)之間的明確劃分，一方面，接口的測試使首先顯示變化成為可能，另一方面，如果發(fā)生變化，通常也只有要測試的函數(shù)接口的幾個元素要發(fā)生變化，在Tessy中接口發(fā)生變化時的處理相當(dāng)簡單；
測試報告生成：
管理測試數(shù)據(jù)并將測試結(jié)果文檔，Tessy提供輸入?yún)?shù)/執(zhí)行測試和評估結(jié)果和報告文檔，Tessy可以生成各種類型的測試報告，包括詳細(xì)報告、概況報告以及覆蓋度報告等。
顯示測試覆蓋度：
Tessy提供C1覆蓋，即分支覆蓋branch coverage或者判定覆蓋decision coverage ；條件覆蓋，即多條件覆蓋MCC（Multiple Condition Coverage）和修正條件判定覆蓋MC/DC（Modified Condition/Decision Coverage），Tessy是通過測試應(yīng)用程序來獲取測試覆蓋信息的；
支持各種測試環(huán)境：
Tessy可以支持超過130種微控制器、交叉編譯器和調(diào)試器的組合； 這確保了Tessy能夠處理交叉編譯器生成的非標(biāo)準(zhǔn)C（ANSI-C）微控制器特定的代碼； 一旦Tessy和不同的調(diào)試器完成集成，就可以自動執(zhí)行測試了。
支持ASAP2：在Tessy中設(shè)計測試用例之前選擇與ASAP2標(biāo)準(zhǔn)的集成功能，確定需要導(dǎo)入的ASAP2文件，使用ASAP2轉(zhuǎn)換規(guī)則自動地將測試用例中設(shè)計的測試數(shù)據(jù)物理值轉(zhuǎn)換為在目標(biāo)板中執(zhí)行測試對象的整數(shù)值，從而簡化測試用例設(shè)計的理解和實現(xiàn)，并且可以在Tessy中顯示其他ASAP2信息，例如單位，最大/最小值等。
Tessy用戶列表及典型案例：Tessy被廣泛應(yīng)用于汽車、國防、鐵路、醫(yī)療和工業(yè)應(yīng)用領(lǐng)域當(dāng)中，眾多著名的汽車整車廠、零部件供應(yīng)商都在使用Tessy。 汽車行業(yè)：Behr-Hella, Bertrandt, Beru, BMW, Bose, Brose, Temic, Daimler, Delphi, Delphi Grundig, Getrag, Helbako, Hella, John Deere, Kiekert, Kostal, Lear, Magna, Marquardt, Pierburg, Preh, SAB Wabco, Siemens VDO, Takata, Tata Elxsi, Tesla, , TRW, Wabco, Valeo, ZF, … 安全關(guān)鍵性領(lǐng)域：Bosch Rexroth, Demag Cranes, Endress&Hauser, Festo, Hanning&Kahl, Liebherr, SEW, Siemens A&D, Testo, Wago, … 醫(yī)療行業(yè)：Allergan, Biotronik, Dr?ger, getemed, Leica , Otto Bock, Sensimed, Stago, St. Jude Medical, Ypsomed, … 白色家電、國防等領(lǐng)域
