在維護階段

　　有一點認識越來越為大多數人所認可：應用系統的維護費用與初始的開發費用基本相等，而在維護過程中，在對應用結構、邏輯、運行的理解上花費的時間，要用去50%的時間。

　　由于系統維護人員很可能不是開發人員本人，再加上人員的流動、團隊內部的交流的不足，都需要對應用系統的理解。

　　理解應用系統

　　將應用系統的設計，以文件形式(部件文件間的關系)和調用圖的形式(函數和過程間的關系)可視化。

　　函數的邏輯結構以控制流圖的形式顯示，在控制流圖上選定一個節點，即可得到相對應的代碼。

　　應用系統可以在不同的抽象層上進行分析，不同層次間的導航關聯，促進對整體的理解。

　　對應用按其資源的使用進行檢測，由此促進對函數之間(參數傳遞)的信息流、數據間的關系，以及其它資源的理解。

　　安全地修改軟件

　　維護軟件意味著修改軟件，修改后的程序確認需要大量的工作。因為，看起來很小的修改，都可能會滾雪球似的導致數十處甚至上百處的修改。這種后繼的修改需求，越早發現越好，最好是在編譯前就發現并做出修改，最壞的情況是在調試和非回歸測試期間發現。

　　二、黑盒測試的實施方案

　　傳統系統的編程語言和邏輯全是過程式的。這種邏輯順序只有當數據中的值引起不同的循環或控制順序改變時才會發生變化。

　　客戶機/服務器和圖形用戶界面系統不是過程式的。它們是事件驅動的。這意味著計算機針對發生的事件執行相應的程序。這里的事件是指用戶采取的行為，象鍵盤活動，鼠標移動，鼠標擊鍵動作和按鍵的動作，都是事件的例子。因為事件發生的順序不能預先知道，事件驅動系統相對來說更難測試。開發人員不可能知道用戶下一次要選中哪個按鈕或菜單項。實際上，應用程序必須在任何時候對所有發生和可能發生的事件作好正確處理的準備。

　　另外，隨著RAD(快速應用開發方式)的引入，導致應用的實現速度很快，但這種方式也有它的不足。一個重要的缺點是項目規劃經常漏掉重要的測試階段。測試象在傳統開發項目中一樣，經常被忽視，并且給予很不現實的少量時間和資源。對于這一點，測試RAD方式下提交的應用并保證軟件質量是測試團隊的首要工作。

　　黑盒測試在實施時又分為客戶端的測試和服務器端的性能測試�？蛻舳说臏y試主要關注應用的業務邏輯，用戶界面，功能測試等;服務器端的測試主要關注服務器的性能，衡量系統的響應時間、事務處理速度和其他時間敏感的需求。在應用系統最終被交付之前保證這兩方面的測試沒有缺陷。

　　由于測試并不是進行一次就可以完成的個過程，而是需要根據產品版本的變化生成不同的測試過程，如果這一過程僅通過手工方式完成是很難達到的。需要通過工具的幫助，從而簡化測試的復雜程度，降低在測試成本上的開銷，縮短投放市場的時間。還有一個突出的特點就是應用程序的回歸測試，這是手工方式完成不了的過程，只有通過工具才能實施。而回歸測試在測試階段是很重要的過程，通過回歸測試可以發現很多隱含的缺陷和錯誤。

　　在服務器端的測試主要以模擬合法用戶活動給系統的負載，負載測試的統計結果被用來預測用戶將體驗到的性能和響應時間。這都需要在客戶機/服務器系統發行之前都要進行的。