測試驅動開發

概述

極限編程是一個輕量級的、靈巧的軟件開發方法，同時它也是一個非常嚴

謹和周密的方法，它從 4 個基本方面對軟件項目進行改善：交流、簡易、反饋

和勇氣。測試驅動開發則是極限編程的最佳實踐之一。它是編程時使用的技術，

要求在編寫任何產品代碼之前，首先編寫用於定義產品代碼行為的測試。采用

測試驅動開發，我們將得到簡單、清晰、高質量的代碼。 MVC 模式是一個復雜的架構模式，它將一個應用的輸入、處理、輸出流程按照 Model、View、Controller 的方式進行分離，使得產品的結構清晰，易於 維護，有利於軟件工程化管理。 Kent Beck 作為極限編程的創始人，提出了測試驅動開發的部分方法，並成功地應用於許多小型的項目中。但是，測試驅動開發在許多系統中應用還存在一定的難度，比如具有圖形用戶界面和多層架構的系統。所以，基於設計模式的測試驅動開發的研究成為國內外軟件工程方向研究者們的課題之一。

反饋是 XP 的四個基本的價值觀之一——在軟件開發中，只有通過充分的測試才能獲得充分的反饋。XP 中提出的測試，在其它軟件開發方法中都可以見到，比如功能測試、單元測試、系統測試和負荷測試等；與眾不同的是，XP 將測試結合到它獨特的螺旋式增量型開發過程中，測試隨着項目的進展而不斷積累。另外，由於強調整個開發小組擁有代碼，測試也是由大家共同維護的。即，任何人在往代碼庫中放程序前，都應該運行一遍所有的測試；任何人如果發現了一個 BUG，都應該立即為這個 BUG 增加一個測試，而不是等待寫那個程序的人來完成；任何人接手其他人的任務，或者修改其他人的代碼和設計，改動完以后如果能通過所有測試，就證明他的工作沒有破壞原系統。這樣，測試才能真正起到幫助獲得反饋的作用；而且，通過不斷地優先編寫和累積，測試應該可以基本覆蓋全部的客戶和開發需求，因此開發人員和客戶可以得到盡可能充足的反饋。

    測試驅動開發(Test- Driven Development), 簡稱TDD, 由Kent Beck 提出的一種軟件開發方式。測試驅動開發以測試作為開發過程的中心, 它要求在編寫任何產品代碼之前, 首先編寫用於定義產品代碼行為的測試, 而編寫的產品代碼又要以使測試通過為目標。測試驅動開發要求測試可以完全自動化的運行, 在對代碼進行重構前后必須運行測試。測試驅動開發主要包括兩方面:測試先行和代碼重構。測試主要針對單元(最小的可測試軟件元素)實施測試。它所測試的內容包括內部結構(如邏輯和數據流)以及單元的功能和可觀測的行為。測試先行一改傳統開發模式的單元測試在編寫代碼之后進行, 而將單元測試的編寫移至編寫正式代碼之前。重構是在不改變代碼外在行為的條件下改進其內部的行為的一種軟件系統改變的過程, 使代碼松耦合度(對外界代碼依賴低)並且內聚度高(內部只完成一項功能) 。測試驅動開發作為極限 編程思想的一種主要實踐, 可以有效地讓程序開發人員開發出更高品質的、經過完整測試的程序。測試驅動開發以測試作為開發過程的開端, 它要求在編寫任何產品代碼之前,首先編寫用於定義產品代碼行為的測試, 而編寫的產品代碼又要以使測試通過為目標。TDD 不是一種開發工具,也不是一種測試方法, 它是一種編碼之前進行單元測試的軟件開發思想。

 

1. 測試驅動開發的研究與實踐

測試驅動開發流程:TDD 開發過程有別於傳統開發流程(Waterfall), 它在進行簡單的概要設計后, 首先進行的是測試用例的編寫,然后執行測試用例進行測試。測試失敗, 則進行編碼驅使測試通過, 這就是所謂的測試驅動。最終, 測試得到通過,再對代碼進行重構,優化代碼結構和性能。而傳統流程則先進行概要設計, 然后在概要設計基礎上進行詳細設計,在詳細設計階段盡可能設想到全部問題和需求的解決方法, 然后才開始編碼實現詳細設計。TDD 開發流程圖如圖所示。

測試驅動開發模式:在測試驅動開發中,關鍵問題如下:什么時候進行測試,如何選擇要測試的邏輯和如何選擇要測試的數據。測試驅動開發模式指導程序員如何解決上述問題。

＊測試相互獨立。

在測試驅動開發中, 所運行的各種測試之間關系的期望狀態是沒有任何相互影響的。相互獨立的測試意味着所有的測試都是不依賴於順序的, 可以隨便從這些測試中挑出部分測試來運行。程序員必須將自己的問題分解為一些彼此正交的小問題, 這樣就使得為每個測試搭建環境

簡單而快捷。獨立測試鼓勵利用高度內聚、低度耦合的對象組合來解決問題。

＊寫出測試列表。

程序員在開始寫測試之前, 應該寫一個包含所有必須要編寫的測試的清單。那么, 記錄到列表上的就是當前程序員要去實現的測試。首先將需要實現的每種操作的范例都記錄在清單上。對於目前尚不存在的操作, 將其空版本記錄在清單上。

＊測試和斷言優先。

在測試驅動開發中, 程序員構建一個系統應該是從其對最終系統的描述開始的。程序員應該從希望最終代碼能夠通過的測試開始編寫一項功能。相應地,程序員應該從測試完成時能夠通過的斷言開始編寫一個測試。在測試優先的測試里程序員應該盡量使用容易讓人理解的數據, 一般不用一個常量來表達多種意思。

一般從測試列表中選擇具有指導意義並且比較有把握實現的測試來進行編寫。當使用一個新類里的一種新的方法時, 不直接用它來編寫程序, 而是編寫一個小測試來驗證這個API 的工作是否符合人們的願望。當出現某種與當前討論話題並不直接相關的想法時, 那么就在列表中增加一個測試然后重新回到論題上來。當發現一個錯誤的時候, 首先寫一個盡可能小的測試並使其運行, 然后再去修復這個錯誤。

利用JUnit進行測試驅動開發:在Eclipse 建立JUnit 測試, 並進行驅動開發。現在開 發一個"Hello Wor ld" 的例子。按照TDD 的規則, 應該在代碼建立以前先把測試寫好。為了能夠在某處開始, 假設未來的類名是HelloWorld , 並且有一個方法Say(), 這個方法返回String 的值(例如"Hello World !")。根據設定的程序功能, 寫出測試代碼如下:

 

import junit .framework.T estCase ;

public class TestThatWeGetHelloWorldPrompt

extends TestCase {

　public TestThatWeGetHelloWorldPrompt(

　　String name){

　　　super(name);

　　}

　public void testSay(){

　HelloWorld hi=new HelloWorld();

　　assertEquals(" Hello World!" , hi.say());

　}

　public static void main(String[ ] args){

　　junit.textui.TestRunner.run(

　　TestThatWeGetHelloWorldPrompt.class);

　}

}

建立測試案例的步驟如下:

1)建立一個junit.framework.TestCase的實例。

2)定義一些以"test" 開頭的無返回方法(例如test-WasTransactionSuccessful(), testS how(), 等等)。

TestThatWeGetHelloWorldPrompt .java 包含這些:TestCase 的子類和一個叫做testSay()的方法。這個方法調用了assertEquals()函數, 它用來比較預期的值和由say()返回的值。main()方法用來運行測試和顯示輸出。JUnit 的TestRunner 處理測試, 提供基於圖像和文本的輸出表現形式。我們使用基於文本的版本, 因為Eclipse 支持它, 且也適合我們。當開始運行后, 基於文本的版本測試會以文本形式輸出,Eclipse 會把這些輸出自動變成圖像界面的輸出。

現在建立被測試代碼:

public class HelloWorld {

　public String say(){

　　return("Hello World!");

　}

}

 

1. 測試驅動開發在Java語言中的運用

測試驅動開發與Java結合的實踐應用：很多同學在程序開發過程中對測試不夠重視，主要表現為：第一，沒有針對實際問題設立出足夠全面的測試用例；第二，主管認為某些代碼是正確的，實際上無法為這些代碼設計相應的測試用例。將測試驅動開發與Java課程有機結合起來，能夠有效地客服同學們對測試認識的不足，從而編寫出更高質量的程序。經過實踐，可遵循以下步驟：

首先編寫測試用例:測試用例是對實際需求的現。用戶向程序輸入一個測試用例，則期望程序給出某些輸出。輸入和輸出往往表現為函數關系。在傳統的編程方式中，程序員也會考慮到實際需求問題，但往往由於僅限於思維上的沒有做出清晰歸納的印象。尤其是一些心急的程序員，覺得寫代碼就是解決問題的全部工程。實際上這樣忽略測試用例而編寫出來的程序很容易未能覆蓋實際問題的各方面要求。

編寫僅能通過測試用的代碼：在編寫測試用例階段，首先要遵循的是：讓編譯器告知程序員，合適該增加新的方法，而不是主動對程序做出規划。在實際的Java語言課程教學實踐中發現，有許多同學在針對某測試用例編寫通過代碼時，喜歡即興發揮，寫出一些並非通過本測試用例所需要的代碼。這樣可能會導致幾個方面的問題：第一，這些代碼無合適的測試用例驗證，可能永遠都不會被執行；第二，這些代碼存在錯誤，但由於當前測試用例不是用於檢驗這些代碼的，它們可能會遺漏到后期的軟件開發中，甚至被集成到其它軟件，造成后期難以檢測出來的隱患；第三，這些代碼可以解決問題的某一方面，但放置位置不合適，造成代

碼意義模糊。例如在上面的代碼中，有些同學在完成了當前測試用例后，馬上想到對於以文本文件方式輸入的同類型的數據也可以使用同樣的程序代碼處理，於是在方法中加入有關文本文件的代碼，這樣的做法其實不合適，因為有關文本文件方式輸入的處理應該在求最大公約數之前的方法中實現。

代碼重構:代碼重構對於測試驅動開發來說相當重要。當程序中代碼的代碼越來越多，就有可能需要進行重構，以優化程序性能，並使程序更加"優美"。例如代碼出現重復、某些代碼要表達的意圖過於復雜時，程序員都要考慮進行重構的必要性。代碼重構與代碼編寫是交錯進行的。代碼編寫是進行代碼重構的基礎，而適時地進行代碼重構將能極大地加快代碼編寫的進度。另一方面，代碼重構無可避免地增加了代碼編寫階段的工作量，所以在進行重構的時機和范圍都需要根據實際問題

維護程序員測試集。進行增量式開發:對於測試集的編寫，則應當遵循"不遺漏，不重復"的原則。通過前三個步驟，不斷擴充測試用例至測試集，並立刻針對擴充的測試用例編寫能通過的代碼，直至測試集包括了實際問題的所有方面為止，則認為程序開發的代碼編寫階段已經完成。

 

1. 測試驅動開發在J2EE項目中實踐

J2EE是一種用來開發企業級軟件應用系統的平台。目前針對J2EE項目，多采用多層架構設計，清晰簡單、分工合作，每層使用特定的框架實現相應的設計策略。比如，Strum+Sprig+Hibernate就是一個很受歡迎的開源整合框架：表示層用Struts實現，業務層用Spring實現，持久層則用Hibernate實現。

在這個整合框架下進行開發，對於普通水准的J2EE開發者來說，可能會有太多的時間被浪費在非關鍵任務上，或者是僅僅為了執行單元測試就不得不把所有程序部署到應用服務器上，其生產率是無法令人滿意的。於是，一種全新的軟件開發方法(測試驅動開發)就被提出且日益流行起來。

JUnit工具介紹：作為流行成熟的回歸測試框架，JUIlit提供了基於API的自動測試方法，您可以在測試代碼中調用這個框架來檢查條件是否滿足，並報告錯誤的數量和類型。這種方案非常靈活，大多數情況下它大大減少了測試代碼的維護時間，並且使應用中的復雜功能測試成為可能，還可交替使用白盒測試或黑盒測試。。本文所討論的測試工具有JMock、SpringContextTestCase、StrutsTestCase、Canoo WebTest，也都是JUnit在具體領域的擴展。

項目組織結構：本項目采用的分層架構使Web應用達到了松散耦合還能靈活改變，並可以承載各種級別的業務處理，每層之間開放通信接口。各層都采用了測試先行編程的開發方法。

 

 

src/dao(數據訪問對象)目錄存放持久層和域模型的實現;src/service目錄存放業務層的實現;src/web目錄存放表示層的實現。每層的測試用例則相應地存放在test目錄下。

Member類有四個屬性，部分代碼如下：

持久層測試:

該層測試使用了Spring對JUnit的擴展測試框架，AbstractTransactionalDataSourceSpringContextTests類的繼承類MemberDaoTest可以不必依賴服務器而直接運行，從而對集成測試(類似單元測試)提供了良好的支持可以隨意更新表中的數據而不必擔心造成影響，因Spring的測試類支持事務管理，會自動圓滾在測試中所做的任何修改。按照TDD的驟接下來才是編寫程序代碼 ，創建MemberDao接口和相應的實現類MemberDao

-Hibernate，然后在Spring配置文件中綁定。現在可以直接在Junit中進行測試。若測試通過，轉到業務層開發。

業務層測試: 我們使用的測試工具是JMock，它可以靈活地定義對象間交互時的約束關系，減少測試的脆弱性。

使用JMock，需要繼承MockObjeetTestCase類，先建立測試運行的上下文，然后設定Mock對象使用到方法、參數、返回值等行為，最后執行測試。按照測試先行方法，現在應該聲明MemberManager接口並實現MemberManagerImpl類。

表示層測試：Struts框架基於MVC(模型一視圖一控制)設計模式，將數據訪問、頁面顯示、流程邏輯三部分分離開來。這使得Web應用的容器內功能測試和單元測試變得困難。StrutsTestCase正是為測試Struts Web應用而創建的Mock測試框架，它無需啟動Servlet容器就可以方便地測試.接下來，是創建MemberAction類、MemberForm類、memberForm頁和memberList頁的時候；然后開始該層測試。

 

1. 在設計模式中的應用

在傳統的軟件工程中，軟件開發過程講究的是前期詳盡的需求和系統詳細設計，以便開發出軟件系統盡量與實際一致，但是這樣做有一個缺點，容易造成 " 設計過度"。所謂設計過度，就是在尚未完全理解客戶需求的基礎上，就根據自己的理解做詳細設計，並力求把系統設計得完美靈活。 然而一旦客戶不需要那些功能或是改變需求的話， 就會造成開發過程中極大的浪費。

測試驅動開發 （ test-driven development，TDD）是一種新型的程序開發方式，而不是一種測試方法，它是由 Kent Beck、Devid Astels 等人提出的，與傳統的程序設計方法不同的軟件開發方式，其基本思想是首先編寫測試代碼， 由測試來決定要編寫哪些程序代碼。TDD 的缺點是在前期過少的考慮整個系統架構，過多的強調了先測試后編碼的原則，導致后面增加了重構的難度。

設計模式^[4]是在軟件設計過程中解決某一類問題的方法。設計模式的基本思想是：根據系統的需求，在經過前人總結得出的方法中選出一種最適合當前系統使用的方法。 使用設計模式的好處是， 它是在無數前人經驗的基礎上總結得出的一些最本質的設計方法， 使用設計模式可以縮短系統結構設計的時間，能夠保證系統的健壯性、擴展性和可維護性。 因此，設計模式是一種指導，在它的指導下，不僅有助於完成任務，而且有助於得到解決問題的最佳辦法，從而做出一個優良的設計方案以達到事半功倍的效果。

為了彌補TDD前期開發對系統結構設計不足的缺點，將TDD與設計模式結合進行軟件設計則是一種新型開發方法。

TDD的基本步驟如下：

步驟 1 先寫一段單元測試代碼；
步驟 2 執行這個測試代碼，不能通過編譯；
步驟 3 寫所能想到的最簡單的程序代碼，讓單元測試代碼可以通過編譯；
步驟 4 再次執行這個單元測試，應該會得到驗證失敗的結果 （ 如果通過的話，說明單元測試沒有擊中要害，需要修改測試代碼）；
步驟 5 寫主程序，讓單元測試可以順利通過驗證；
步驟 6 回到步驟 1，開始寫新的單元測試。

 

軟件工程中無數項目的成功經驗證明， 設計模式是非常重要和必要的。 對於初步接觸

TDD 的編程人員來說，結合設計模式進行的測試驅動開發最合理的方式應該是：① 花一定的時間做好前期的分析，在研究模式上投入時間；② 在最初以最簡單的形式實現模式，以后再增加其復雜性；③ 如果使用了一種模式，而在以后發現無法滿足需要時，通過轉換的方式將其修改。 使用了結合設計模式進行的 TDD，將會極大的減少修改構架的復雜度，使得修改朝着有序的方向進行。

結合設計模式的TDD的開發流程基本如下：

可以看到，設計模式主要是用於業務邏輯層中。 業務邏輯層的作用就是處理系統中的各個業務邏輯，並將所得結果通過接口提供給外部的展現層調用。在開發過程中，遇到需要系統構架調整的時候，只要保持對應用程序的展示層的接口方法不變，無論下面層次中的程序做如何大的改動，前台都不需要做相應的變動，實現了展示層同業務邏輯層相分離的原則。這就是在 TDD 中也要使用設計模式的好處。

 

 

 

1. 基於MVC的測試驅動開發

基於 MVC 架構的測試驅動開發過程:由於具有使 View、Controller 與 Model 分離開來的特性，MVC 很適用於 GUI 軟件的開發。目前許多 GUI 軟件的結構都是基於或者是部分地基於MVC 的。比如，Microsoft Foundation Class(MFC)-----它把 View 和 Controller 集成在視圖內，文檔負責數據的表示以及存取(Model) ,視圖負責顯示文檔內容(View)以及處理用戶界面上的操作( Controller)；Struts-----它采用EJB 作為模型，JSP 和 Custom Tag Library 配合作為View，Servlet作為控制器。

根據對 MVC 架構各層的特點的分析，三層中 Controller 反映了應用程序的功能和流程，並且清楚 Model 和 View 的功能，所以測試驅動開發應該從Controller 出發，首先將開發的重點放在實現程序的功能上，更早地實現需求。由於在 Controller 的開發過程中需要不斷地對 Model 和 View 進行重構，為了減少重構的代價，可以將 Model 中未實現的對象用 Mock Object 來代替。當在實現一個用戶故事的 Controller 后，或者實現多個 Controller 后，從 Controller 層可以提取出 View 與 Controller 之間數據傳遞的信息，根據這些信息可以進行View 層的設計和開發，View 的實現主要考慮以怎樣的視圖來顯示這些信息，以及設計怎樣的事件來觸發Controller中相應的方法。另一方面，當Controller 中可以至少提取出一個完整的 Model 對象時，調用 Model 層代碼生成工具生成Model 的程序代碼和測試代碼。

測試驅動開發中 MVC架構各部分的關系:MVC 架構的形式化分析，可知 MVC 三層模塊之間是相互依賴的關系，而三層中 Controller 層反映了程序的控制邏輯，它的實現依賴於 Model向數據庫獲取數據，又依賴於 View 將更新的數據顯示在界面上。所以在測試驅動開發 Controller 過程中可以設計出 Model 和 View 的接口。View 只是用開發環境提供的各種控件將數據簡單的顯示在界面上。Model 主要是對數據進行處理，數據處理的過程有其規律性，在絕大部分系統中，這些對象的方法主要是對數據庫的操作，包括增加、刪除、查詢、修改等。三者的對應關系如下圖。測試代碼傳入測試數據對被測代碼的 public方法進行測試，隨着 Controller 功能的實現，在 Controller 的程序代碼部分可以知道，Model 和 View 對象的接口信息逐漸被設計和編寫出來。對於 View 來說，它只負責顯示圖形用戶界面，不涉及任何的功能代碼，所以 View 層不適合作測試驅動開發，而是將 View 的測試集中在用戶界面風格上，比如用戶界面的一致性、界面的布局、用戶界面之間的切換是否順暢、顏色的使用是否適當、以及界面的設計是否考慮不同用戶的需求等等。在 Web 界面測試方面，配合使用ASPUnit 和 HttpUnit 等自動化測試工具可以提高測試效率。Model 的測試集中在每個對象的方法是否返回正確的結果，Model 的方法確定了，對方法的測試用例也可以確定下來，而測試數據可以從 Controller 測試代碼中用於測試的數據中獲得。為了提供程序的編寫效率，可以先從 Controller 的測試代碼和程序代碼提取出生成 Model 代碼所需的信息，再利用代碼生成工具，生成 Model 的測試代碼和程序代碼。

 

 

Model信息的提取

對測試驅動開發 Controller的基本約定

對 Controller 的開發基本按照測試驅動開發的步驟來進行，將開發的重點放在實現程序的功能上。但是，為了能更好的實現從 Controller 層抽取出 Model和 View 層信息，並保證 Controller 層的可測試性，在開發 Controller 層時，還應該做到以下幾點：

1. 保持 View 的簡單性，將事件代碼交給 Controller 處理。因為測試 View是困難和繁瑣的, 所以View應該是盡可能的簡單。View中各控件的event handle事件只是傳遞的作用，具體的功能較由 Controller 的方法處理。

2. MVC 三層的通信都要經過 Controller 層。這種限制保證了 Model 和 View 的分離，同時也保證了 Controller 層的測試用例可以完全覆蓋整個程序的功能。

3．為了便於用程序實現在 Controller 中提取自動生成 Model 的信息，Controller 代碼中的某些方法和屬性的命名應遵循一定的規則，具體如下：

1） Model 方法的命名：方法類型+Model 類名，如 InsertUser。

2） Model 幾個常用方法的類型為：Insert 表示"插入"，Search 表示"查詢"，Get 表示"單個查詢"，Update 表示"更新"，Delete 表示"刪除"。

3）Controller 測試程序中的一個測試類對應一個 Controller 類，一個測試方法對應一個 Controller 方法的一個測試用例。

 

1. 嵌入式系統測試驅動開發的策略

雙目標開發策略:對多數嵌入式項目來講，並行進行硬件和軟件開發是個現實。如果只能在目標硬件上運行，有可能會有多個浪費時間的因素。但並不是所有的開發團隊都會遇到浪費時間的問題，傳統意義上，這也是嵌入式開發者會轉而使用評估板來緩解目標硬件的一個原因。評估板是在開發時使用的一種電路板，它有同目標系統相同的處理器配置，理想情況下還有同樣的輸入輸出接口。評估板能保護不會延遲項目，但是這還不夠，評估板仍然有構建時間長的問題。雙目標開發則是解決上述瓶頸問題的一個策略。雙目標是指代碼被設計成至少應能在兩個平台上運行：代碼最終是要在一個嵌入式目標硬件上運行，但它首先在開發系統中寫出和測試的，而雙目標解決了以下幾個問題：它可以在硬件就緒之前就測試代碼，並使它在整個軟件開發周期里避免硬件帶來的瓶頸，還可避免隨硬件和軟件同時調試帶來的互相指責。雙目標還會影響設計、對軟件與硬件之間邊界的關注會產生更模塊化的設計。在開發系統中，測試代碼會在把代碼應用於目標硬件之前來幫助開發人員建立信心，但在雙目標方案當中存在其固有的風險。所以這些可能導致在一個環境里運行沒有錯誤的代碼卻在另一個環境里卻測試失敗。在嵌入式中的TDD循環可以較好地應對這些問題。

嵌入式的TDD循環:嵌入式的TDD循環是對TDD微循環的擴展，它可以克服目標硬件所帶來的瓶頸。當構建和測試的循環只有幾秒鍾的情況下TDD效果最好，更長的構建和測試時間會導致采用更大的步伐。對這種快速反饋的需求迫使TDD的微循環脫離目標硬件，而運行在本地的開發系統中。TDD微循環是嵌人式TDD循環的第一個平台，如圖所示。

 

 

 

平台2～4被設計用於緩解用開發平台來運行單元測試所帶來的風險。平台5確保完整集成后的系統能夠提供可工作的特性。

平台1：TDD微循環。在這個平台運行得最頻繁，通常幾分鍾一次。大部分代碼會在這個平台中寫出，並且只在開發系統本地編譯。測試是在開發系統里完成的，這樣它能給出快速反饋，而不會被硬件的可靠性或可用性的約束拖累。在這個平台中，需要寫於平台無關的代碼。要尋找把軟件和硬件斷開的機會，硬件和軟件的邊界要很清楚，並記錄在測試用例中。

平台2：編譯器兼容性檢查。要定期的為目標系統作編譯，采用為產品而使用的交叉編譯器。這個平台是對編譯器不兼容的一個早期警告。它會警告移植問題，如頭文件不可用，語言支持不兼容，以及語言特性缺失等，不必在每次代碼改變時都運行平台2。在每次采用了新的語言特性時做一下目標系統的交叉編譯。

平台3：在評估板上運行單元測試。有一個風險是，編譯后的代碼在本地開發系統和目標處理器上運行起來是不同的。為緩和這種風險，可以在評估板上運行單元測試。使用評估板可以看到代碼在開發系統和目標處理器上行為的差異。擁有在評估板上運行的能力，即使在目標硬件就緒之后可能仍然比較方便。如果有一可疑的目標硬件行為，可以快速地通過在評估板上運行單元測試，以把目標硬件的問題包含進來或排出。

平台4：在目標硬件上運行單元測試。平台4的目的和平台3相同，只是平台4會使用真實的內存。而且可以運行只能在目標硬件上運行的測試。這些測試可以識別出或者學習到目標硬件的行為。這個平台一個新增的功能是目標硬件上有限的內存。在這種情況下，可以把測試組織成不同的測試套件，使每個套件都能裝進內存中。

平台5：在目標硬件上運行驗收測試。最后，需要在目標硬件上運行自動化的和手工的驗收測試來保證產品特性。這里要確保任何不能完全被自動化測試的、依賴於硬件的代碼都會被手工測試。

 

 

[1] Badreddin O, Forward A, Lethbridge T C. A test-driven approach for developing software languages[C]// International Conference on Model-Driven Engineering and Software Development. IEEE, 2014:225-234.

[2] 蘇慶.SU Qing 測試驅動開發在Java語言課程實踐中的應用[期刊論文]-廣東工業大學學報（社會科學版） 2008(z1)

[3] 程燁.高建華.CHENG Ye.GAO Jian-hua與設計模式相結合的測試驅動開發方法[期刊論文]-計算機工程與設計 2006(16)

[4]Pipka J U. Test-Driven Web Application Development in Java[C]// Revised Papers from the International Conference NetObjectDays on Objects, Components, Architectures, Services, and Applications for a Networked World. Springer-Verlag, 2002:378-393.

[5] Kent Beck. Test-Driven Development—By Example[J]. Pearson Schweiz Ag, 2003.

[6] 黎利 基於MVC的測試驅動開發研究[學位論文]碩士 2007

[7] 陳立群.CHEN Li-qun 測試驅動開發在J2EE項目中的全程實踐[期刊論文]-計算機工程與科學2008(4)

[8] 張揚.黃厚寬.ZHANG Yang.HUANG Hou-kuan 測試驅動開發及開發實踐[期刊論文]-計算機技術與發展 2006(5)

[9] 齊山松.姬進.QI Shansong.JI Jin測試驅動的嵌入式開發與實踐[期刊論文]-電子科技 2013(8)