從用例到測試用例
 
        每個入口點都必須與相應的用例匹配。某些情況下可以忽視這一步，因為類名的自記錄可以實現(xiàn)自動匹配，比如Saxon中的轉(zhuǎn)換類可以實現(xiàn)XSL轉(zhuǎn)換，查詢類可以進行XQuery轉(zhuǎn)換。
        其它情況則要復雜得多。通常用例描述的功能只能以橫切關注點的方式存在，不能用任何單獨的類進行例證。只有幾組類交互時或滿足一定條件時，才能觀察到功能行為。這種情況下，測試的初始化程序會比較長，或者可以用setUp()方法提供需要的測試環(huán)境。
        而調(diào)用代碼的運行程序應該盡可能地設計成一行，以減少與被測試代碼的關聯(lián)，這可以有效避免對邊緣效應與不穩(wěn)定實現(xiàn)細節(jié)的依賴。測試的檢查階段是復雜的，因為這個階段經(jīng)常需要添寫非測試用代碼。測試時可能需要對結(jié)果進行嚴格的分析以確保其符合要求。有時甚至需要將這個過程分為幾步來完成，以取得測試可以識別的結(jié)果。在XSL轉(zhuǎn)換中，這兩種情況都是可能的，結(jié)果儲存在文件中，然后以XML格式讀入內(nèi)存并進行準確性分析。

        Saxon中有個相對簡單的例子。已有XML文件和XPath表達式的情況下，Saxon可以執(zhí)行表達式并返回匹配列表。Saxon中的XpathExample樣本類是用來執(zhí)行這種任務的�；�于以上分析，可以設計如下的測試流程：

    public void testXPathEvaluation() {
      //initialize
      XPathEvaluator xpe = new XPathEvaluator(
        new SAXSource(new InputSource("/path/to/file.xml")));
      XPathExpression findLine =
        xpe.createExpression("/some/xpath[expression]");
      //work
      List matches = findLine.evaluate();
      //check
      assertTrue(matches.count() > 0);
    }

        兩次輸入的都是字符串常量，輸出的則是所匹配的列表，可以用來驗證匹配結(jié)果的正確性。這些工作都由一行代碼完成，這行代碼只是簡單地調(diào)用了被測試的方法。
        另一種可能的情況是XPathEvaluator沒有調(diào)用createExpression()方法。因為表達式不存在，這時可能會顯示錯誤信息。
        將輸入的源文件名和表達式保留在測試用例中不是個好習慣。某些項目（服務器名、用戶名和密碼等）不應該出現(xiàn)在測試文件中，它們應該可以根據(jù)情況自由設置。并且，測試用例的設計應該方便測試驅(qū)動和測試數(shù)據(jù)的分離、測試驅(qū)動對大范圍數(shù)據(jù)的可重用性和測試數(shù)據(jù)對測試驅(qū)動的可重用性。另一方面，不要將一個簡單的測試用例實現(xiàn)設計地過于復雜。一般來說，測試用例已經(jīng)說明了系統(tǒng)的大部分狀態(tài)，并可對其進行參數(shù)描述，所以無需在測試中進行過于詳細的參數(shù)描述。
        許多代碼段可能出現(xiàn)在不止一個測試用例中。有經(jīng)驗的面向?qū)ο箝_發(fā)人員會嘗試對其進行重構并創(chuàng)建通用類和有效方法。有時候這樣做非常有用，比如登錄過程應該設計成所有測試用例可用的方法。 但是，不要過度設計測試，這些Java類僅僅是用來驗證應用程序的功能行為而已。

        測試用例是脆弱的。比如，如果開發(fā)人員更改了testXPathEvaluation測試中輸入文件的位置，或者creatExpression方法簽名有所變動，測試腳本會失效。
        對于應用程序的測試用例實現(xiàn)來說，大量的重復性工作與改動是不可避免的。因此，可跟蹤性對于所有的測試用例都是至關緊要的。出現(xiàn)問題的時候，如果能為開發(fā)人員指出相應的測試用例說明和用例說明將有利于提高修正bug的速度。
        因此，測試用例注釋中應標明原始說明文檔的引用位置。這可以是一個簡單的代碼注釋，也可以對每條測試都注釋相關用例和所測功能，這樣當測試出現(xiàn)問題時開發(fā)人員會收到一條相關信息。因此，在代碼中加入?yún)⒖疾⒕S護可追蹤性是很重要的。

設計運行時事件表
 
        要了解測試覆蓋的范圍，必須先了解所測試代碼如何運行，以及各種靜態(tài)類如何形成描述程序狀態(tài)的動態(tài)對象圖表。
        有許多模擬這種行為的方法，包括Granovetter圖和物件互動圖。其基本思想是用圖形化的方式研究代碼以了解測試中涉及到的運行時部分。這些技術都可用運行時事件表（Runtime Event Diagrams）來描述，因為這些圖表顯示了程序運行時發(fā)生的事件，而非理論上類可以控制的事件。這些圖表非常重要的原因包括：
        首先，這些圖表便于從高層上理解代碼，并提供有用的說明文檔。這個文檔與代碼的內(nèi)聯(lián)文檔不同。這些圖表顯示代碼的運行時表現(xiàn)，是產(chǎn)生代碼功能的地方，也易于對系統(tǒng)的了解；大多數(shù)設計模式和架構在用對象和參考表示時要比用類和域表示容易得多。
        另外，這些圖表將測試執(zhí)行的代碼分類列表，并確定測試是否會受到將來對任意代碼改動的影響。如果開發(fā)人員確定測試A是建立在B、C和D的基礎上，她可以確定如果對B、C或D做出改動需要對A進行重新測試（確保向后兼容）。
        以盡可能少的步驟模擬系統(tǒng)是個好方法�？偟膩碚f，實際調(diào)用與此無關，重要的是系統(tǒng)如何作為整體運作以獲得預期目標�？梢杂煤喕�的模擬系統(tǒng)實現(xiàn)這個目的，該系統(tǒng)只關心對象間的基本交互，并用自然語言描述交互中發(fā)生的事件。
        做出運行時事件表后，可以將其整合到類文檔中。需要注意的是，為表添加一些限制可使其對類的修改更有彈性。首先，一般不能使用方法名，因為它們會隨時間發(fā)生變化。取而代之的是更易理解的自然語言描述。其次，這些圖表主要是關于系統(tǒng)中各部分的交互。這是高層架構上的設計方案，一般不會再做改動。后，圖表是建立在類型而非特定類的基礎上。只要基本類型不變，為維持交互協(xié)議的正常運行，這些圖表不需要更新。
        一旦圖表創(chuàng)建成功，可以在許多方面獲得應用。比如，一個圖表可以用來獲取系統(tǒng)如何運作，以及如何運用其交互部件實現(xiàn)功能的概覽。在某種程度上這是一種簡化了的UML語言，它只描述關系到整體功能的系統(tǒng)部件：實例及其類型、其它引用的實例，以及組件可以實現(xiàn)的功能。
        這些圖表也可以用來分析系統(tǒng)的復雜性以及如何進行簡化。要確定簡化系統(tǒng)的方法，可以查找系統(tǒng)中使用過一到兩次的對象，并為其尋找其它可能更合適的位置。也可以查找重復的任務，將其封裝到方法或類中。
        然而，重要的是圖表在測試中的應用。通過對系統(tǒng)狀態(tài)的總結(jié)，圖表可以幫助解決系統(tǒng)中出現(xiàn)的問題。出現(xiàn)問題時，圖表中的信息便可用作參考。因為只需要將系統(tǒng)目前狀態(tài)與預期狀態(tài)作比較即可，這樣確定問題產(chǎn)生的原因也變得比較簡單了。對小組件的改動不應該影響整體架構，因此可以通過對照運行時事件表以保證系統(tǒng)仍然正常運行。并且，當有重要組件發(fā)生變動時，可以用運行時事件表對照系統(tǒng)當前狀態(tài)以獲取系統(tǒng)修正方案。由于將系統(tǒng)作為整體和對預期功能的描述，運行時事件表也可以看作是一種結(jié)構化的單元測試。如果系統(tǒng)有變動，可以更容易地做出修正以維持系統(tǒng)的正常功能。
        如果經(jīng)常因細節(jié)問題影響對全局的把握，應該使用圖表。其高層本質(zhì)可以用來分析軟件的設計模式，像反模式一樣。還有許多其它用途，并且當運行時事件表、測試用例說明和用例說明沒有描述所需的細節(jié)時，它還提供了直接進行代碼分析的路線圖。

利用功能測試進行回歸測試
 
        后，為回報你在功能測試上做出的努力，配置一個與自動生成的程序相應的自動化測試程序。這個程序不只從功能上測試代碼，還可以同時進行常規(guī)的回歸測試�，F(xiàn)在大多開發(fā)項目都建立在龐大的代碼庫基礎上，如果不能對代碼庫進行充分測試，開發(fā)團隊將無從決定對程序的修正是否會破壞現(xiàn)有的功能，結(jié)果是很難對這種代碼進行擴展或優(yōu)化。與此相反，如果開發(fā)人員可以在全面的功能測試基礎上進行回歸測試，優(yōu)化或擴展代碼時不必擔心可能會引發(fā)不可預料的問題。畢竟，沒有比做完回歸測試后發(fā)現(xiàn)一切正常更令人心情愉快的事了。