『壹』 請問嵌入式軟體測試工具有哪些
VectorCAST™是主要用於C/C++/Ada程序的自動化測試軟體，能夠運行在Windows和Linux等多種開發環境。其主要功能包含自動化的單元測試、集成測試、覆蓋率分析、回歸測試、代碼靜態分析和測試需求跟蹤，其最大特點或相比於其它相關同類工具最大的優勢，就在於最大程度的自動化和更適用於嵌入式環境。
『貳』 嵌入式軟體測試的嵌入式靜態測試工具
Goanna是一個針對C/C++安全可靠性進行深度靜態分析的工具，為安全性的嵌入式軟體提供全球領先的靜態C/C++代碼分析解決方案。作為確保符合例如DO-178B、ISO26262等安全標準的重要組成部分，Goanna結合了最新的程序驗證研究，並可以與IDE和構建伺服器無縫結成，從而為用戶提供一個簡單而強大的桌面解決方案來提高創建代碼的信心。Goanna產品已被全球汽車、軍工、醫療、關鍵任務的嵌入式系統等行業廣泛應用進行軟體驗證。
Goanna的特性：
在錯誤進入產品前及早發現：Goanna的深度靜態分析只需要源代碼就可以自動化地找到C/C++程序中的錯誤，不需要編譯、模擬或者執行代碼。通過在開發生命周期最早期的階段發現錯誤，用戶可以實現以下目標：提高代碼質量；降低成本；節約開發時間；使產品更快進入市場。
Goanna可以與大部分IDE和配置環境集成，將強大的深度靜態分析部署在用戶指尖，只需要點擊就可以執行，而不需要冗長的安裝成本或者中斷用戶已有的工作流程；
獨一的追蹤模擬器：Goanna可以直接在用戶的IDE中「重現」復雜缺陷的跟蹤，讓用戶可以更快地精確定位缺陷的根本原因；
靈活的增量分析：Goanna生成被分析函數的數字指紋，確保只會分析上次執行之後被修改的部分代碼，從而防止函數在未被改變的情況下產生重分析的潛在費用，實現快速測試周期而不需要等待可能數小時的重新分析；
行業標准：Goanna可以提供符合一些行業安全規范的驗證，例如: MISRA C:2004；MISRA C++:2008；CERT；CWE，從而幫助客戶通過一些標準的認證，例如ISO26262，DO-178B等；
可自定義的檢查：可以非常容易地根據用戶的標准和需求來自定義檢查；
獲獎的技術：Goanna採用先進的獲得Turing獎的模型檢查技術，提供所有執行路徑提供高效的完全路徑覆蓋，甚至非常復雜的函數可以；
路徑敏感的完整代碼分析：Goanna獨特的專利技術提供的完整的程序間分析可以發現調用鏈中深度的缺陷，甚至可以跨越多個函數和文件，例如空指針不能獲得通過並在其它函數中取消其引用；
抽象數據跟蹤：Goanna可以自動跟蹤變數的潛在范圍，實現程序中所有點上的取值、大小和地址的計算，從而非常容易地查找出在動態測試和人工檢查很容易錯過的缺陷，例如發現可能的緩沖區溢出或者不可行路徑等；
超過250個有很高價值的檢查：空指針錯誤；數組越界；字元串溢出；內存泄露；內存損壞；雙重釋放；安全性缺陷；壞的結構；未初始化變數；死代碼；算術錯誤；可移植性缺陷；除零；不安全的庫；加上無限可能的用戶自定義的檢查；等等
可視的圖形化報告：缺陷可以通過一個易於使用的Web介面被即時地繪製成圖形化的報告，提供缺陷歷史和問題領域。高亮的圖表使開發人員能夠在錯誤出現的時候立即識別出故障點並盡快地解決。
集成的儀表盤和度量：通過和基於Sonar的儀表盤的集成，Goanna還可以提供附加的靜態分析、圈復雜度分析、代碼覆蓋率分析以及重復度量指標等信息。
『叄』 嵌入式開發中PC端使用什麼調試和測試軟體
嵌入式系統的功能千差萬別，測試的要求也千差萬別，故絕對通用的軟體是沒有的，相對通用的黑盒測試工具，大致分為兩種類型：純軟體的測試平台、軟硬一體化的測試平台。
1）純軟體的測試平台，通常比較平易近人，簡單易用，應用成本低。
例如，格西烽火通信測試軟體，是一款基於串口和網口的調試和測試軟體，主要解決電子研發過程中調試和測試軟體定製化過多的問題，能夠快捷地定製任意通信規約，使得通信軟體能夠應付快速多變的通信測試環境。
『肆』 求C語言嵌入式軟體測試工具
首先是各種儀器儀表的使用，如萬用表，示波器，邏輯分析儀，其次嵌入式軟體測試一般是配合硬體做的，因此需要對硬體有一定的了解，沒有什麼測試工具，因此一般的測試主要是測量數據，基本學不到技術，而且很多時候是研發人員自己完成後進行測試，沒有問題了就讓你做長時間運行測試穩定性，做開發也很簡單的，建議做研發吧
『伍』 嵌入式軟體測試技巧有哪些
嵌入式軟體開發過程中，一般來說，花在測試和花在編碼的時間比為3:1(實際上可能更多)。這個比例隨著你的編程和測試水平的提高而不斷下降，但不論怎樣，軟體測試對一般人來講很重要。很多年前，一位開發人員為了在對嵌入式有更深層次的理解，向Oracle詢問了這樣的一個問題:我怎麼才能知道並懂得我的系統到底在幹些什麼呢?Oracle面對這個問題有些吃驚，因為在當時沒有人這么問過，而同時代的嵌入式開發人員問的最多的大都圍繞「我怎麼才能使程序跑的更快」、「什麼編譯器最好」等膚淺的問題。所以，面對這個不同尋常卻異乎成熟的問題，Oracle感到欣喜並認真回復了他:你的問題很有深度很成熟，因為只有不斷地去深入理解才有可能不斷地提高水平。並且Oracle為了鼓勵這位執著的程序員，把１０條關於嵌入式軟體開發測試的秘訣告訴了他:
1.懂得使用工具
2.盡早發現內存問題
3.深入理解代碼優化
4.不要讓自己大海撈針
5.重現並隔離問題
6.以退為進
7.確定測試的完整性
8.提高代碼質量意味著節省時間
9.發現它，分析它，解決它
10.利用初學者的思維
這十條秘訣在業界廣為流傳，使很多人受益。本文圍繞這十條秘訣展開論述。
１.懂得使用工具
通常嵌入式系統對可靠性的要求比較高。嵌入式系統安全性的失效可能會導致災難性的後果，即使是非安全性系統，由於大批量生產也會導致嚴重的經濟損失。這就要求對嵌入式系統，包括嵌入式軟體進行嚴格的測試、確認和驗證。隨著越來越多的領域使用軟體和微處理器控制各種嵌入式設備，對門益復雜的嵌入式軟體進行快速有效的測試愈加顯得重要。
就象修車需要工具一樣，好的程序員應該能夠熟練運用各種軟體工具。不同的工具，有不同的使用范圍，有不同的功能。使用這些工具，你可以看到你的系統在幹些什麼，它又佔用什麼資源，它到底和哪些外界的東西打交道。讓你郁悶好幾天的問題可能通過某個工具就能輕松搞定，可惜你就是不知道。那麼為什麼那麼多的人總是在折騰個半死之後才想到要用測試工具呢？原因很多，主要有兩個。一個是害怕，另一個是惰性。害怕是因為加入測試用具或測試模塊到代碼需要技巧同時有可能引入新的錯誤，所以他們總喜歡寄希望於通過不斷地修改重編譯代碼來消除bug,結果卻無濟於事。懶惰是因為他們習慣了使用printf之類的簡單測試手段。下面來介紹一些嵌入式常用的測試工具。
.源碼級調試器[Source-level Debugger]
這種調試器一般提供單步或多步調試、斷點設置、內存檢測、變數查看等功能，是嵌入式調試最根本有效的調試方法。比如VxWorks TornadoII提供的gdb就屬於這一種。
.簡單實用的列印顯示工具[printf]
printf或其它類似的列印顯示工具估計是最靈活最簡單的調試工具。列印代碼執行過程中的各種變數可以讓你知道代碼執行的情況。但是，printf對正常的代碼執行干擾比較大(一般printf佔用CPU比較長的時間)，需要慎重使用，最好設置列印開關來控制列印。
.ICE或JTAG調試器[In-circuit Emulator]
ICE是用來模擬CPU核心的設備，它可以在不幹擾運算器的正常運行情況下，實時的檢測CPU的內部工作情況。像桌面調試軟體所提供的：復雜的條件斷點、先進的實時跟蹤、性能分析和埠分析這些功能，它也都能提供。ICE一般都有一個比較特殊的CPU，稱為外合(bond-out)CPU。這是一種被打開了封裝的CPU，並且通過特殊的連接，可以訪問到CPU的內部信號，而這些信號，在CPU被封裝時，是沒法「看到」的。當和工作站上強大的調試軟體聯合使用時，ICE就能提供你所能找到的最全面的調試功能。但ICE同樣有一些缺點：昂貴；不能全速工作；同樣，並不是所有的CPU都可以作為外合CPU的，從另一個角度說，這些外合CPU也不大可能及時的被新出的CPU所更換。JTAG(Joint Test Action Group)雖然它最初開發出來是為了監測IC和電路連接，但是這種串列介面擴展了用途，包括對調試的支持。AD公司為Blackfin設計的Visual Dsp++就支持高速的 JTAG調試。
『陸』 軟體測試工具有哪些
1、WinRunner
Winrunner 最主要的功能是自動重復執行某一固定的測試過程，它以腳本的形式記錄下手工測試的一系列操作，在環境相同的情況下重放，檢查其在相同的環境中有無異常的現象或與預期結果不符的地方。
2、LoadRunner
LoadRunner® 是一種預測系統行為和性能的工業標准級負載測試工具。通過以模擬上千萬用戶實施並發負載及實時性能監測的方式來確認和查找問題，LoadRunner 能夠對整個企業架構進行測試。
3、QTP
QTP是一個B/S系統的自動化功能測試的利器,軟體程序測試工具。Mercury的自動化功能測試軟體QuickTest Professional ，可以覆蓋絕大多數的軟體開發技術，簡單高效，並具備測試用例可重用的特點。
4、TestDirector
基於WEB的測試管理工具，他能夠讓你系統地控制整個測試過程，並創建整個測試工作流的框架和基礎，使整個測試管理過程變得更為簡單和有組織。
5、SilkTest
SilkTest 是面向Web應用、Java應用和傳統的C/S應用，進行自動化的功能測試和回歸測試的工具。它提供了用於測試的創建和定製的工作流設置、測試計劃和管理、直接的資料庫訪問及校驗等功能，使用戶能夠高效率地進行軟體自動化測試。
6、Selenium
Selenium是為正在蓬勃發展的web應用開發的一套完整的測試系統。Selenium測試直接運行在瀏覽器中，就像真正的用戶在操作一樣。
7、TPT
TPT是針對嵌入式系統的基於模型的測試工具，特別是針對控制系統的軟體功能測試。TPT支持所有的測試過程：包括測試建模、測試執行、測試評估以及測試報告的生成。
『柒』 嵌入式軟體測試的軟體動態測試工具
Tessy是一個專門針對嵌入式軟體的C/C++代碼進行單元、集成測試的工具，它可以自動化地執行測試、評估測試結果並生成測試報告。Tessy的目標就是：通過自動化整個測試周期，在所有測試階段完美支持針對C語言的單元測試，當然，Tessy也同樣關注測試組織和測試管理。
在以V模型為例的開發模式中，Tessy主要處理右半部分驗證和確認中單元/模塊測試，集成/組件測試以及系統測試的內容。在V模型的開發模式中，單元測試是第一個測試活動。它阻止了每一類錯誤，比如演算法錯誤，在V模式的右邊向上蔓延，這樣可以盡可能早得發現Bug，防止直到後面的測試過程或者直到最終用戶那裡才被發現，單元測試有經濟效益，越早發現bug越好 。
另外，Tessy也可以滿足各類標准（ISO26262、IEC 61508、 EN 50128/50129、 DO-178B、汽車SPiCE或FDA的軟體驗證通用原則）對測試的需求，比如ISO26262中各個測試等級中對模塊測試的要求可以使用Tessy來滿足，當然Tessy本身也通過了TUeV的認證，被證明是安全可靠的，可以在安全相關性的軟體研發過程中被使用。 自動生成測試環境：
Tessy可以自動生成測試環境驅動，選擇自動或者手動打樁以及自動生成測試用例模板，幫助客戶提高測試用例設計效率。
多種測試用例確定方式：
除了從Excel中導入測試用例，手動地設計測試用例外，Tessy里集成了CTE軟體，根據分類樹的方法通過Tessy自動化地關聯測試用例。
支持動態測試的各階段：
Tessy可以支持從單元測試到系統測試的動態測試過程各個階段，通過單元測試檢查最小單位為函數的功能，通過集成測試來測試各個子功能組合起來的模塊能否達到預期要求的父功能以及相互間的介面，通過系統測試實現與目標板集成的測試環境來測試系統功能；另外Tessy可以自動發現被測對象的改變，分析被測對象的介面，重用測試用例和測試數據，從而為重復的回歸測試節約大量的工作和時間，在介面不變的情況下Tessy可以完全自動化地執行不需要用戶介入的回歸測試；
全自動地測試執行及評估；
Tessy檢查源文件並且通過分析程序代碼來確定函數以及他們的介面，這些信息將被保存在特定的資料庫中供隨時檢索，介面信息和測試數據的分離實現了結構和數據之間的明確劃分，一方面，介面的測試使首先顯示變化成為可能，另一方面，如果發生變化，通常也只有要測試的函數介面的幾個元素要發生變化，在Tessy中介面發生變化時的處理相當簡單；
測試報告生成：
管理測試數據並將測試結果文檔，Tessy提供輸入參數/執行測試和評估結果和報告文檔，Tessy可以生成各種類型的測試報告，包括詳細報告、概況報告以及覆蓋度報告等。
顯示測試覆蓋度：
Tessy提供C1覆蓋，即分支覆蓋branch coverage或者判定覆蓋decision coverage ；條件覆蓋，即多條件覆蓋MCC（Multiple Condition Coverage）和修正條件判定覆蓋MC/DC（Modified Condition/Decision Coverage），Tessy是通過測試應用程序來獲取測試覆蓋信息的；
支持各種測試環境：
Tessy可以支持超過130種微控制器、交叉編譯器和調試器的組合； 這確保了Tessy能夠處理交叉編譯器生成的非標准C（ANSI-C）微控制器特定的代碼； 一旦Tessy和不同的調試器完成集成，就可以自動執行測試了。
支持ASAP2：在Tessy中設計測試用例之前選擇與ASAP2標準的集成功能，確定需要導入的ASAP2文件，使用ASAP2轉換規則自動地將測試用例中設計的測試數據物理值轉換為在目標板中執行測試對象的整數值，從而簡化測試用例設計的理解和實現，並且可以在Tessy中顯示其他ASAP2信息，例如單位，最大/最小值等。
Tessy用戶列表及典型案例：Tessy被廣泛應用於汽車、國防、鐵路、醫療和工業應用領域當中，眾多著名的汽車整車廠、零部件供應商都在使用Tessy。 汽車行業：Behr-Hella, Bertrandt, Beru, BMW, Bose, Brose, Continental 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, TietoEnator, TRW, Wabco, Valeo, ZF, … 安全關鍵性領域：Bosch Rexroth, Demag Cranes, Endress&Hauser, Festo, Hanning&Kahl, Liebherr, SEW, Siemens A&D, Testo, Wago, … 醫療行業：Allergan, Biotronik, Dräger, getemed, Leica Biosystems, Otto Bock, Sensimed, Stago, St. Jude Medical, Ypsomed, … 白色家電、國防等領域
『捌』 嵌入式測試的測試工具
在嵌入式領域目標系統的應用系統日趨復雜，而由於競爭要求產品快速上市，開發技術日新月異，同時硬體發展的日益穩定，而軟體故障卻日益突出，軟體的重要性逐漸引起人們的重視，越來越多的人認識到嵌入式系統的測試勢在必行。提到嵌入式軟體測試，首先要簡單介紹一些軟體工程的一些觀點，現在，被普遍接受的軟體的定義是：軟體(software)是計算機系統中與硬體(hardware)相互依存的另一部分，它包括程序(program)、相關數據(data)及其說明文檔(document)。其中程序是按照事先設計的功能和性能要求執行的指令序列；數據是是程序能正常操縱信息的數據結構；文檔是與程序開發維護和使用有關的各種圖文資料。
對於一般商用軟體的測試，嵌入式軟體測試有其自身的特點和測試困難。
由於嵌入式系統的自身特點，如實時性(Real-timing)，內存不豐富，I/O通道少，開發工具昂貴，並且與硬體緊密相關CPU種類繁多，等等。嵌入式軟體的開發和測試也就與一般商用軟體的開發和測試策略有了很大的不同，可以說嵌入式軟體是最難測試的一種軟體。
嵌入式軟體測試使用有效的測試策略是唯一的出路，它可以使開發的效率最大化，避免目標系統的瓶頸，使用在線模擬器節省昂貴的目標資源。自從出現高級語言，開發環境與最終運行環境通常都是存在差異的，嵌入式系統更是如此。開發環境被認為是主機平台，軟體運行環境為目標平台。相應的測試為host-target測試或cross-testing。
討論嵌入式軟體測試首先就會遇到一個問題：為什麼不把所有測試都放在目標上進行呢？因為若所有測試都放在目標平台上有很多不利的因素：
1）測試軟體，可能會造成與開發者爭奪時間的瓶頸，避免它只有提供更多的目標環境。
2）目標環境可能還不可行。
3）比起主機平台環境，目標環境通常是不精密的和不方便的。
4）提供給開發者的目標環境和聯合開發環境通常是很昂貴的。
5）開發和測試工作可能會妨礙目標環境已存在持續的應用
從經濟上和開發效率上考慮，軟體開發周期中盡可能大的比例在主機系統環境中進行，其中包括測試。
確定host-target測試環境後，開發測試人員又會遇到以下的問題：
1）多少開發人員會捲入測試工作（單元測試，軟體集成，系統測試）?
2）多少軟體應該測試，測試會花費多長時間？
3）在主機環境和目標環境有哪些軟體工具，價格怎樣，適合怎樣?
4）多少目標環境可以提供給開發者，什麼時候?
5）主機和目標機之間的連接怎樣？
6）被測軟體下載到目標機有多快?
7）使用主機與目標環境之間有什麼限制（如軟體安全標准）?
任何人或組織進行嵌入式軟體的測試都應深入考慮以上問題，結合自身實際情況，選定合理測試策略和方案。
對於嵌入式軟體測試或叫交叉測試（cross-test），在測試的各個階段有著通用的策略： 所有單元級測試都可以在主機環境上進行，除非少數情況，特別具體指定了單元測試直接在目標環境進行。最大化在主機環境進行軟體測試的比例，通過盡可能小的目標單元訪問所有目標指定的界面。
在主機平台上運行測試速度比在目標平台上快的多，當在主機平台完成測試，可以在目標環境上重復作一簡單的確認測試，確認測試結果在主機和目標機上沒有被他們的不同影響。在目標環境上進行確認測試將確定一些未知的，未預料到的，未說明的主機與目標機的不同。例如，目標編譯器可能有bug，但在主機編譯器上沒有。 軟體集成也可在主機環境上完成，在主機平台上模擬目標環境運行，當然在目標環境上重復測試也是必須的，在此級別上的確認測試將確定一些環境上的問題，比如內存定位和分配上的一些錯誤。
在主機環境上的集成測試的使用，依賴於目標系統的具體功能有多少。有些嵌入式系統與目標環境耦合的非常緊密，若在主機環境做集成是不切實際的。一個大型軟體的開發可以分幾個級別的集成。低級別的軟體集成在主機平台上完成有很大優勢，越往後的集成越依賴於目標環境。 所有的系統測試和確認測試必須在目標環境下執行。當然在主機上開發和執行系統測試，然後移植到目標環境重復執行是很方便的。對目標系統的依賴性會妨礙將主機環境上的系統測試移植到目標系統上，況且只有少數開發者會捲入系統測試，所以有時放棄在主機環境上執行系統測試可能更方便。
確認測試最終的實施舞台必須在目標環境中，系統的確認必須在真實系統之下測試，而不能在主機環境下模擬。這關繫到嵌入式軟體的最終使用。
包括恢復測試、安全測試、強度測試、性能測試，已超出了軟體測試的范疇，本文暫不討論。
使用有效的cross-test測試策略可極大的提高嵌入式軟體開發測試的水平和效率，當然正確的測試工具使用也是必不可少的：
總結一下，應用以上測試工具進行.Cross-test時的策略：
A)使用測試工具的插裝功能（主機環境）執行靜態測試分析，並且為動態覆蓋測試准備好一插裝好的軟體代碼。
B)使用源碼在主機環境執行功能測試，修正軟體的錯誤和測試腳本中的錯誤。
C)使用插裝後的軟體代碼執行覆蓋率測試，添加測試用例或修正軟體的錯誤，保證達到所要求的覆蓋率目標。
D)在目標環境下重復（B），確認軟體在目標環境中執行測試的正確性。
E)若測試需要達到極端的完整性，最好在目標系統上重復（C），確定軟體的覆蓋率沒有改變。
通常在主機環境執行多數的測試，只是在最終確定測試結果和最後的系統測試才移植到目標環境，這樣可以避免發生訪問目標系統資源上的瓶頸，也可以減少在昂貴資源如在線模擬器上的費用。另外，若目標系統的硬體由於某種原因而不能使用時，最後的確認測試可以推遲直到目標硬體可用，這為嵌入式軟體的開發測試提供了彈性。設計軟體的可移植性是成功進行cross-test的先決條件，它通常可以提高軟體的質量，並且度軟體的維護大有益處。以上所提到的測試工具，都可以通過各自的方式提供測試在主機與目標之間的移植，從而使嵌入式軟體的測試得以方便的執行。
使用有效的cross-test測試策略可極大的提高嵌入式軟體開發測試的水平和效率，提高嵌入式軟體的質量。
附錄：
1). HOST-TARGET的連接方法簡介：
圖1-- 直接連接
圖2 -- 通過模擬器連接
圖3 -- 使用介質進行間接連接
圖4 -- 使用PROM等傳遞被測軟體
圖5 -- 測試的交互界面
圖6 -- 無交互界面的連接
『玖』 推薦一個嵌入式單元測試工具
winAMS
全面支持嵌入式微機！驗證嵌入式C/C++軟體 實施以模塊為單位的自動化單元測試工具
不需要HookCode 直接使用目標機代碼進行單元測試
聯合靜態解析工具[CasePlayer2]，提供C1,MC/DC用優化測試計劃（test case）製作功能
已取得第三方認證機構TUVSUD對適用於汽車機能安全ISO26262軟體工具的認證
『拾』 LoadRunner或QTP那個能測試嵌入式醫療機械軟體
兩個工具都可以用在醫療器械軟體中的。
1、loadrunner（性能測試工具）：醫療器械在正常的工作中應該不會考慮到負載和壓力，就像X光設備，只有一個人去使用。在這里loadrunner應該可以作為強度測試，系統資源不足的情況下，正常負載下運行設備的性能，他的主要目的是考察穩定運行所需要的最小資源。
2、QTP（自動化工具）：按照開發療程，設備軟體在不同的階段會有不同的測試方法，當我們完成功能測試，一般邏輯復雜的大型軟體都會使用自動化測試，功能測試階段就會開發出自動化腳本，到回歸測試的時候使用，這樣大大的節省了人力物力和時間。