測試用例是脆弱的。比如，如果開發人員更改了testXPathEvaluation測試中輸入文件的位置，或者creatExpression方法簽名有所變動，測試腳本就會失效。
對于應用程序的測試用例實現來說，大量的重復性工作與改動是不可避免的。因此，可跟蹤性對于所有的測試用例都是至關緊要的。出現問題的時候，如果能為開發人員指出相應的測試用例說明和用例說明將有利于提高修正bug的速度。
因此，測試用例注釋中應標明原始說明文檔的引用位置。這可以是一個簡單的代碼注釋，也可以對每條測試都注釋相關用例和所測功能，這樣當測試出現問題時開發人員就會收到一條相關信息。因此，在代碼中加入參考并維護可追蹤性是很重要的。
設計運行時事件表
要了解測試覆蓋的范圍，必須先了解所測試代碼如何運行，以及各種靜態類如何形成描述程序狀態的動態對象圖表。
有許多模擬這種行為的方法，包括Granovetter圖和物件互動圖。其基本思想是用圖形化的方式研究代碼以了解測試中涉及到的運行時部分。這些技術都可用運行時事件表(Runtime Event Diagrams)來描述，因為這些圖表顯示了程序運行時發生的事件，而非理論上類可以控制的事件。這些圖表非常重要的原因包括：
首先，這些圖表便于從高層上理解代碼，并提供有用的說明文檔。這個文檔與代碼的內聯文檔不同。這些圖表顯示代碼的運行時表現，是產生代碼功能的地方，也易于對系統的了解;大多數設計模式和架構在用對象和參考表示時要比用類和域表示容易得多。
另外，這些圖表將測試執行的代碼分類列表，并確定測試是否會受到將來對任意代碼改動的影響。如果開發人員確定測試A是建立在B、C和D的基礎上，她就可以確定如果對B、C或D做出改動就需要對A進行重新測試(確保向后兼容)。
以盡可能少的步驟模擬系統是個好方法�？偟膩碚f，實際調用與此無關，重要的是系統如何作為整體運作以獲得預期目標�？梢杂煤喕哪M系統實現這個目的，該系統只關心對象間的基本交互，并用自然語言描述交互中發生的事件。
做出運行時事件表后，就可以將其整合到類文檔中。需要注意的是，為表添加一些限制可使其對類的修改更有彈性。首先，一般不能使用方法名，因為它們會隨時間發生變化。取而代之的是更易理解的自然語言描述。其次，這些圖表主要是關于系統中各部分的交互。這是高層架構上的設計方案，一般不會再做改動。最后，圖表是建立在類型而非特定類的基礎上。只要基本類型不變，為維持交互協議的正常運行，這些圖表就不需要更新。
一旦圖表創建成功，可以在許多方面獲得應用。比如，一個圖表可以用來獲取系統如何運作，以及如何運用其交互部件實現功能的概覽。在某種程度上這是一種簡化了的UML語言，它只描述關系到整體功能的系統部件：實例及其類型、其它引用的實例，以及組件可以實現的功能。
這些圖表也可以用來分析系統的復雜性以及如何進行簡化。要確定簡化系統的方法，可以查找系統中使用過一到兩次的對象，并為其尋找其它可能更合適的位置。也可以查找重復的任務，將其封裝到方法或類中。
然而，最重要的是圖表在測試中的應用。通過對系統狀態的總結，圖表可以幫助解決系統中出現的問題。出現問題時，圖表中的信息便可用作參考。因為只需要將系統目前狀態與預期狀態作比較即可，這樣確定問題產生的原因也就變得比較簡單了。對小組件的改動不應該影響整體架構，因此可以通過對照運行時事件表以保證系統仍然正常運行。并且，當有重要組件發生變動時，可以用運行時事件表對照系統當前狀態以獲取系統修正方案。由于將系統作為整體和對預期功能的描述，運行時事件表也可以看作是一種結構化的單元測試。如果系統有變動，可以更容易地做出修正以維持系統的正常功能。
如果經常因細節問題影響對全局的把握，就應該使用圖表。其高層本質可以用來分析軟件的設計模式，就像反模式一樣。還有許多其它用途，并且當運行時事件表、測試用例說明和用例說明沒有描述所需的細節時，它還提供了直接進行代碼分析的路線圖。
最后，為回報你在功能測試上做出的努力，配置一個與自動生成的程序相應的自動化測試程序。這個程序不只從功能上測試代碼，還可以同時進行常規的回歸測試�，F在大多開發項目都建立在龐大的代碼庫基礎上，如果不能對代碼庫進行充分測試，開發團隊將無從決定對程序的修正是否會破壞現有的功能，結果就是很難對這種代碼進行擴展或優化。與此相反，如果開發人員可以在全面的功能測試基礎上進行回歸測試，優化或擴展代碼時就不必擔心可能會引發不可預料的問題。畢竟，沒有比做完回歸測試后發現一切正常更令人心情愉快的事了。
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
