因為軟體測試的工作量很大（40% 到60% 的總開發時間），而又有很大部分適於自動化，因此，測試的改進會對整個開發工作的質量、成本和週期帶來非常顯著的效果。
首先，談談在測試自動化的情況下，帶有圖形介面的產品的測試用例的設計問題。因為圖形介面的輸出顯示不是很容易做到測試結果自動化比較，所以一般的做法是把圖形介面輸出的部分單獨建立測試用例，以手工執行。而所有非圖形輸出則可進行自動測試。
下面舉出一些測試自動化的例子：
1.測試個案（test case ，或稱為測試用例）的生成
用程式語言或更方便的劇本語言（script language 例如perl等）寫出短小的程式來產生大量的測試輸入（包括輸入資料與操作指令）。或同時也按一定的邏輯規律產生標準輸出。輸入與輸出的檔案名字按規定進行配對，以便控制自動化測試及結果核對的程式易於操作。
這裡提到測試個案的命名問題，如果在專案的文件設計中作統一規劃的話，軟體產品的需求與功能的命名就應該成為後繼開發過程的中間產品的命名分類依據。這樣，就會為文件管理和配置管理帶來很大的方便，使整個產品的開發過程變得更有條理，更符合邏輯。任何新手半途加入到開發工作中也會更容易進入狀態。
2.測試的執行寫控制
單元測試或整合測試可能多用單機執行。但對於系統測試或回歸測試，就極有可能需要多台機在網路上同時執行。記住乙個這樣的原則，在開發過程中的任何時候，如果你需要等候測試的執行結果的話，那就是乙個縮短開發時間的機會。
對於單個的測試執行，挖潛的機會在測試的設定及開始執行和結果的對比及顯示。有時候，需要反覆修改程式，重新彙編和重新測試。這樣，每乙個迴圈的各種手工鍵入的設定與指令所花費的時間，加起來就非常可觀。如果能利用make或類似的軟體工具來幫助，就能節省大量的時間。
對於系統測試或回歸測試這類涉及大量測試個案執行的情況，挖潛的的機會除了利用軟體工具來實現自動化之外，就是怎樣充分利用一切硬體資源。往往，就算是在白天的工作時間內，每台計算機的負荷都沒有被充分利用。能夠把大量測試個案分配到各台機器上去同時執行，就能節省大量的時間。另外，把大量的系統測試及回歸測試安排到夜間及週末執行，更能提高效率。
如果不購買商品化的工具的話，應當遵從正規的軟體開發要求來開發出好的軟體測試自動化工具。在實踐中，許多企業自行開發的自動化工具都是利用一些現成的軟體工具再加上自己寫的程式而組成的。這些自己開發的工具完全是為本企業量身定做的，因此可用性非常強。同時，也能根據需要隨時進行改進，而不必受制於人。當然，這就要求有一定的人力的投入。
在設計軟體自動測試工具的時候，路徑（path）控制是乙個非常重要的功能。理想的使用情況是：這個工具可以在任何乙個路徑位置上執行，可以到任何路徑位置去取得測試用例，同時也可以把測試的結果輸出放到任何的路徑位置上去。這樣的設計，可以使不同的測試執行能夠使用同一組測試用例而不至於互相干擾，也可以靈活使用硬碟的空間，並且使備份儲存工作易於控制。
同時，軟體自動測試工具必須能夠有辦法方便地選擇測試用例庫中的全部或部分來執行，也必須能夠自由地選擇被測試的產品或中間產品採作為測試物件。
3.測試結果與標準輸出的對比
在設計測試用例的時候，必須考慮到怎樣才能夠易於對此測試結果和標準輸出。輸出資料量的多少及資料格式對比較的速度有直接影響。而另一方面，也必須考慮到輸出資料與測試用例的測試目標的邏輯對應性及易讀性，這將會大大有利於分析測試所發現的不吻合，也有利於測試用例的維護。
許多時候，要寫一些特殊的軟體來執行測試結果與標準輸出的對比工作，因為可能有部分的輸出內容是不能直接對比的（比如，對執行的日期時間的記錄，對執行的路徑的記錄，以及測試物件的版本資料等），就要用程式進行處理。
4.不吻合的測試結果的分析、分類、記錄和通報
上一點所談到的，用於對測試結果與標準輸出進行對比的特殊軟體，往往也同時擔任對不吻合的測試結果進行分析、分類、記錄和通報的任務。
「分析」是找出不吻合的地方並指出錯誤的可能起因。「分類」包括各種統計上的分項，例如，對應的源程式的位置，錯誤的嚴重級別（提示、警告、非失效性錯誤、失效性錯誤；或別的分類方法），新發現的還是已有記錄的錯誤，等等。「記錄」，是按分類存檔。「通報」，是主動地對測試的執行者及測試用例的「負責人」通報出錯的資訊。
這裡提到測試用例的「負責人」的概念。是用以指定乙個測試用例執行時發現的缺陷，由哪乙個開發人員負責分析（有時是另外的開發人員引進的缺陷而導致的錯誤）及修復。在設立測試用例庫時，各用例均應有指定的負責人。
最直接的通報方法是由自動測試軟體發出電子郵件給測試執行者及測試用例負責人。郵件內容的詳細程度可根據需要靈活決定。
5.總測試狀況的統計，報表的產生
這些都是自動測試工具所應有的功能。目的是提高過程管理的質量，同時節省用於產生統計資料的時間。
產生出來的統計報表，最好是存放到乙個約定的路徑位置，以便任何有關人員都知道怎樣查閱。同時，可按需要用電子郵件向適當的物件（如專案經理，測試經理和質量保證經理）寄出統計報表。
6.自動測試與開發中產品每日構建（build ）的配合
自動測試應該是整個開發過程中的乙個有機部分。自動測試要依靠配置管理來提供良好的執行的環境，同時它必須要與開發中的軟體的構建緊密配合。
在開發中的產品達到一定程度的時候，就應該開始進行每日構建和測試。這種做法能使軟體的開發狀態得到頻繁的更新，以及及早發現設計和整合的缺陷。
為了充分利用時間與裝置資源，下班之後進行自動的軟體構建，緊接著進行自動測試（這裡多數指的是系統測試或回歸測試），是乙個非常行之有效的方法。如果安排得好，到第二天上班時，測試結果就已經在各人的電子郵箱裡面面了，等待著新的一天的開發工作。
軟體測試自動化的一些具體做法
因為軟體測試的工作量很大 40 到60 的總開發時間 而又有很大部分適於自動化，因此，測試的改進會對整個開發工作的質量 成本和週期帶來非常顯著的效果。首先，談談在測試自動化的情況下，帶有圖形介面的產品的測試用例的設計問題。因為圖形介面的輸出顯示不是很容易做到測試結果自動化比較，所以一般的做法是把圖形...
關於自動化測試的一些思考。
我們都知道自動化測試是一種不錯的回歸測試的解決方案，我們一直想在自己負責的被測試產品 模組中引入自動化測試，但是，是不是應該大張旗鼓的在產品測試過程中引入自動化？要知道回歸測試是有其專用目的的，主要是為了驗證原來好用的功能現在仍繼續好用，發現原來好用但現在不好用的功能。要知道自動化測試指令碼的完全建...
關於自動化測試的一些認知
為什麼要用自動化？因為每次的產品更新或者是上線前後，都需要大量的時間需要進行回歸測試，但是回歸測試如果人工完成的話就費時費力，而且容易造成遺漏。如果能夠用自動化回歸，再配置一些管理工具來自動觸發，不僅能夠省時省力，而且能夠做到無人值守。自動化測試不能做什麼？a.樣式問題 顏色 字型 字型大小 b.新...