當(dāng)前大部分的測試工具是軟件的功能性測試功能(也被稱為記錄/回放工具)，如Rational的Robot和Mercury 的Winrunner等。記錄/回放工具的缺陷使我們在測試中不能過分依賴它。

　　缺陷：

　　記錄/回放工具能夠記錄下用戶和應(yīng)用程序交互時的擊鍵和鼠標(biāo)的移動。擊鍵和鼠標(biāo)的移動都被記錄成一個腳本，然后可以在測試執(zhí)行期間“回放”。雖然這種方法對特定的情形是有益的，但是記錄/回放功能大約僅僅是其全部功能的1/10。記錄/回放腳本在首次記錄生成之后必須要進(jìn)行修改。對功能性測試的修改主要集中在通過GUI進(jìn)行驗證的測試，也稱為黑箱測試。只是通過記錄/回放直接創(chuàng)建腳本有一些嚴(yán)重的局限和缺點(diǎn)。

　　1.硬編碼的數(shù)值。記錄/回放工具根據(jù)用戶的交互動作來生成腳本，其中也包含了從用戶界面輸入或者接受的任何數(shù)據(jù)。讓數(shù)值在腳本中“硬編碼”會給以后的維護(hù)工作帶來問題。如果應(yīng)用程序的用戶界面或則其他方面發(fā)生了變化，那么硬編碼的數(shù)值會導(dǎo)致腳本非法。例如：在記錄期間生成腳本的時候，輸入值、窗口坐標(biāo)、窗口標(biāo)題和其他值可能也被記入生成的腳本代碼中。如果在應(yīng)用程序中，這些值中任何一個發(fā)生了變化，那么測試執(zhí)行期間這些固定的數(shù)值就成了罪魁禍?zhǔn)祝簻y試腳本與應(yīng)用程序的交互是錯誤的，或者徹底失敗。另一個可能出問題的硬編碼數(shù)值是日期戳。如果測試工程師在測試過程中記錄了當(dāng)前日期，那么幾天后再次運(yùn)行這個腳本會導(dǎo)致失敗，因為腳本中包含了硬編碼的數(shù)值不再和當(dāng)前的日期匹配。

　　2.非模塊化的、不易維護(hù)的腳本。測試工具產(chǎn)生的記錄/回放腳本通常不是模塊化的，維護(hù)起來非常困難。例如：可能許多測試過程都引用了一個WEB應(yīng)用程序中特殊的URL，如果腳本中使用了硬編碼的URL，那么這個URL的改變將會導(dǎo)致大量的腳本作廢。在一個模塊化的開發(fā)方法中，只有一個函數(shù)中引用，或則包裝了這個URL。隨后各個是引用它的腳本會調(diào)用這個函數(shù)，這樣URL的任何變化只需要改動一處就可以了。

　　3.缺乏可重用性的標(biāo)準(zhǔn)。測試過程開發(fā)面臨的最重要的課題之一是可重用性。如果測試創(chuàng)建專門的標(biāo)準(zhǔn)，明確地要求開發(fā)可復(fù)用的自動測試過程，那么就會極大地提高測試組的工作效率。如果把用戶界面部分的測試封裝進(jìn)模塊化的、可重用的腳本文件，供其他腳本調(diào)用，那么當(dāng)用戶界面經(jīng)常不斷變化的時候，腳本的維護(hù)工作量就會大大降低。

　　創(chuàng)建一個可重用的函數(shù)庫時，最好把諸如數(shù)據(jù)讀取、寫入和確認(rèn)、導(dǎo)航、邏輯以及錯誤檢查功能分別歸到不同的腳本文件中。自動測試開發(fā)的指導(dǎo)方針應(yīng)該大量的借用高效的軟件開發(fā)工作所遵循的原則。遵循與測試工具生成腳本的開發(fā)語言最接近的開發(fā)語言的指導(dǎo)方針，這是一個很好的時間。例如：如果工具生成的腳本類似于C語言，那么應(yīng)該遵從C語言的開發(fā)標(biāo)準(zhǔn);如果工具生成的腳本類似于BASIC語言，那么應(yīng)該遵從BASIC語言的開發(fā)標(biāo)準(zhǔn)。

　　在自動測試開發(fā)中，只使用記錄/回放方法生成的測試腳本是很難維護(hù)和重用的，這是明顯的事實(shí)。雖然也有少數(shù)的情況，可使用未經(jīng)加工的腳本，但是對于大多數(shù)情況，如果不在記錄之后修改腳本，那么在測試執(zhí)行期間，測試工程師會由于正在測試的應(yīng)用程序的變化而反復(fù)記錄腳本。使用記錄/回放工具可能帶來的潛在收益，一定會被不斷重建測試腳本的無奈所抵消。這會使測試人員產(chǎn)生很強(qiáng)的挫折感，并且會對自動測試工具感到不滿。

　　為了避免未經(jīng)加工的記錄/回放腳本帶來的問題，應(yīng)該建立可復(fù)用的測試腳本的開發(fā)方針。未經(jīng)過加工的記錄/回放腳本并不表示有效的自動測試。

　　解決方法：自制開發(fā)一個測試工具

　　為了去除自動測試工具的局限性和對核心組件進(jìn)行更深入的測試，可以自制開發(fā)一個測試工具。這種定制的測試工具一般用健壯的程序語言編寫，例如：獨(dú)立的C++或則Java程序，定制的測試工具一般比自動測試工具生成的腳本運(yùn)行的速度更快，也更靈活，因為這些腳本受限于測試工具的特定環(huán)境。

　　我們舉一個適合用定制測試工具來測試任務(wù)的例子，假設(shè)一個應(yīng)用程序的用途使根據(jù)用戶提供的信息進(jìn)行計算，并且把計算的結(jié)果生成報告。計算過程可能是復(fù)雜的，并且可能對各種輸入?yún)��?shù)的不同組合是敏感的。這可能會有數(shù)百萬種潛在變化，這些變化會產(chǎn)生不同的結(jié)果，因此，對計算過程進(jìn)行全面的測試才能保證計算的正確性。

　　手工開發(fā)和驗證大量的計算性測試用例是非常浪費(fèi)時間的。在大多數(shù)情況下，通過界面執(zhí)行大量的測試用例也是非常緩慢的。此時一個更高效的方法是自制開發(fā)一個測試工具，它會直接針對應(yīng)用程序的代碼(一般是直接針對用戶界面層之下的核心組件)執(zhí)行測試用例。

　　另一種使用自制測試工具的方法是：對照遺留組件或者系統(tǒng)來比較新組件。兩個系統(tǒng)通常使用的數(shù)據(jù)存儲格式是不同的，用不同的技術(shù)實(shí)現(xiàn)的用戶界面也是不同的。此時，為了在兩個系統(tǒng)上運(yùn)行相同的測試用例并且生成比較報告，自動測試工具需要一種特殊的機(jī)制來復(fù)制自動測試腳本。在最壞的情況下，單個測試工具不能同時兼容兩個系統(tǒng)，此時兩套測試腳本必須用兩種不同的自動測試工具來開發(fā)。一個更好的替代方案是自制生成一個定制的、自動測試工具，它把兩個系統(tǒng)之間的差異封裝進(jìn)獨(dú)立的模塊，這樣我們就能夠設(shè)計出同時適用于兩套系統(tǒng)的測試。自制的自動測試工具可以把遺留系統(tǒng)產(chǎn)生的測試結(jié)果作為基線，并且通過比較兩套結(jié)果和輸出它們之間的差異來自動地驗證新系統(tǒng)產(chǎn)生的結(jié)果。

　　達(dá)到上述目的的一種方法是使用自制工具適配器模式。自制測試工具適配器是一個模塊，它通過轉(zhuǎn)換或者改造正在測試地每個系統(tǒng)使之和自制測試工具兼容，這樣自制測試工具可以通過適配器在系統(tǒng)種執(zhí)行預(yù)定義地測試用例，并且把結(jié)果存儲為相互之見可以自動比較地標(biāo)準(zhǔn)格式。對于每個開發(fā)出來地適配器必須能夠直接和系統(tǒng)進(jìn)行交互和針對系統(tǒng)執(zhí)行測試用例。用一個自制測試工具測試兩個系統(tǒng)需要不同地適配器并獨(dú)立調(diào)用兩次自制測試工具，每個系統(tǒng)調(diào)用一次。兩次調(diào)用的結(jié)果應(yīng)用保留起來并進(jìn)行比較。圖示描述了針對遺留系統(tǒng)和新系統(tǒng)執(zhí)行測試用例的定制測試工具。

　　通過為每個系統(tǒng)使用不同的適配器，相同的測試用例可以用于多個系統(tǒng)。針對遺留系統(tǒng)的適配器來產(chǎn)生一組基線結(jié)果，這個結(jié)果用于和新系統(tǒng)的結(jié)果比較。

　　為了完成他們的任務(wù)，自制的測試工具適配器首先獲得一組測試用例，然后按照順序執(zhí)行這些用例，從而直接測試每個系統(tǒng)的邏輯，繞過了用戶界面。繞過用戶界面使性能得到了優(yōu)化，使得測試用例的吞吐量最大化。它還具有更高的穩(wěn)定性。如果自制測試工具依賴于用戶界面，那么用戶界面的任何變化(在開發(fā)生命周期種，用戶界面經(jīng)常會經(jīng)過多次修改)都可能導(dǎo)致自制測試工具對缺陷的漏識別。檢查這樣的結(jié)果會浪費(fèi)大量寶貴的時間。

　　每個測試用例的執(zhí)行結(jié)果被存儲在一個或者多個結(jié)果文件中，存儲的格式使相同的。與正在測試的系統(tǒng)無關(guān)。保存結(jié)果文件是為了與隨后運(yùn)行的測試產(chǎn)生的結(jié)果進(jìn)行比較。比較可以有一個定制生成的結(jié)果工具來完成，這個工具按照一定的規(guī)則讀取和評估結(jié)果文件，并且輸出發(fā)現(xiàn)的所有錯誤或者差異。如果我們把結(jié)果格式化，那么也可以通過標(biāo)準(zhǔn)的“file diff”(比較文件差異)工具對它們進(jìn)行比較。

　　與所有的測試類型一樣，自制測試工具使用的測試用例可能使相當(dāng)復(fù)雜的，特別是當(dāng)自制測試工具所測試的組件使用于數(shù)學(xué)計算或者科學(xué)計算的時候，利用自制的測試工具就可以覆蓋大部分的測試。