缺陷：
記錄/回放工具能夠記錄下用戶(hù)和應用程序交互時(shí)的擊鍵和鼠標的移動(dòng)。擊鍵和鼠標的移動(dòng)都被記錄成一個(gè)腳本，然后可以在測試執行期間“回放”。雖然這種方法對特定的情形是有益的，但是記錄/回放功能大約僅僅是其全部功能的1/10。記錄/回放腳本在首次記錄生成之后必須要進(jìn)行修改。對功能性測試的修改主要集中在通過(guò)GUI進(jìn)行驗證的測試，也稱(chēng)為黑箱測試。只是通過(guò)記錄/回放直接創(chuàng )建腳本有一些嚴重的局限和缺點(diǎn)。
1.硬編碼的數值。記錄/回放工具根據用戶(hù)的交互動(dòng)作來(lái)生成腳本，其中也包含了從用戶(hù)界面輸入或者接受的任何數據。讓數值在腳本中“硬編碼”會(huì )給以后的維護工作帶來(lái)問(wèn)題。如果應用程序的用戶(hù)界面或則其他方面發(fā)生了變化，那么硬編碼的數值會(huì )導致腳本非法。例如：在記錄期間生成腳本的時(shí)候，輸入值、窗口坐標、窗口標題和其他值可能也被記入生成的腳本代碼中。如果在應用程序中，這些值中任何一個(gè)發(fā)生了變化，那么測試執行期間這些固定的數值就成了罪魁禍首：測試腳本與應用程序的交互是錯誤的，或者徹底失敗。另一個(gè)可能出問(wèn)題的硬編碼數值是日期戳。如果測試工程師在測試過(guò)程中記錄了當前日期，那么幾天后再次運行這個(gè)腳本會(huì )導致失敗，因為腳本中包含了硬編碼的數值不再和當前的日期匹配。
2.非模塊化的、不易維護的腳本。測試工具產(chǎn)生的記錄/回放腳本通常不是模塊化的，維護起來(lái)非常困難。例如：可能許多測試過(guò)程都引用了一個(gè)WEB應用程序中特殊的URL，如果腳本中使用了硬編碼的URL，那么這個(gè)URL的改變將會(huì )導致大量的腳本作廢。在一個(gè)模塊化的開(kāi)發(fā)方法中，只有一個(gè)函數中引用，或則包裝了這個(gè)URL。隨后各個(gè)是引用它的腳本會(huì )調用這個(gè)函數，這樣URL的任何變化只需要改動(dòng)一處就可以了。
3.缺乏可重用性的標準。測試過(guò)程開(kāi)發(fā)面臨的最重要的課題之一是可重用性。如果測試創(chuàng )建專(zhuān)門(mén)的標準，明確地要求開(kāi)發(fā)可復用的自動(dòng)測試過(guò)程，那么就會(huì )極大地提高測試組的工作效率。如果把用戶(hù)界面部分的測試封裝進(jìn)模塊化的、可重用的腳本文件，供其他腳本調用，那么當用戶(hù)界面經(jīng)常不斷變化的時(shí)候，腳本的維護工作量就會(huì )大大降低。
創(chuàng )建一個(gè)可重用的函數庫時(shí)，最好把諸如數據讀取、寫(xiě)入和確認、導航、邏輯以及錯誤檢查功能分別歸到不同的腳本文件中。自動(dòng)測試開(kāi)發(fā)的指導方針應該大量的借用高效的軟件開(kāi)發(fā)工作所遵循的原則。遵循與測試工具生成腳本的開(kāi)發(fā)語(yǔ)言最接近的開(kāi)發(fā)語(yǔ)言的指導方針，這是一個(gè)很好的時(shí)間。例如：如果工具生成的腳本類(lèi)似于C語(yǔ)言，那么應該遵從C語(yǔ)言的開(kāi)發(fā)標準;如果工具生成的腳本類(lèi)似于BASIC語(yǔ)言，那么應該遵從BASIC語(yǔ)言的開(kāi)發(fā)標準。
在自動(dòng)測試開(kāi)發(fā)中，只使用記錄/回放方法生成的測試腳本是很難維護和重用的，這是明顯的事實(shí)。雖然也有少數的情況，可使用未經(jīng)加工的腳本，但是對于大多數情況，如果不在記錄之后修改腳本，那么在測試執行期間，測試工程師會(huì )由于正在測試的應用程序的變化而反復記錄腳本。使用記錄/回放工具可能帶來(lái)的潛在收益，一定會(huì )被不斷重建測試腳本的無(wú)奈所抵消。這會(huì )使測試人員產(chǎn)生很強的挫折感，并且會(huì )對自動(dòng)測試工具感到不滿(mǎn)。
為了避免未經(jīng)加工的記錄/回放腳本帶來(lái)的問(wèn)題，應該建立可復用的測試腳本的開(kāi)發(fā)方針。未經(jīng)過(guò)加工的記錄/回放腳本并不表示有效的自動(dòng)測試。
解決方法：自制開(kāi)發(fā)一個(gè)測試工具
為了去除自動(dòng)測試工具的局限性和對核心組件進(jìn)行更深入的測試，可以自制開(kāi)發(fā)一個(gè)測試工具。這種定制的測試工具一般用健壯的程序語(yǔ)言編寫(xiě)，例如：獨立的C++ 或則Java程序，定制的測試工具一般比自動(dòng)測試工具生成的腳本運行的速度更快，也更靈活，因為這些腳本受限于測試工具的特定環(huán)境。
我們舉一個(gè)適合用定制測試工具來(lái)測試任務(wù)的例子，假設一個(gè)應用程序的用途使根據用戶(hù)提供的信息進(jìn)行計算，并且把計算的結果生成報告。計算過(guò)程可能是復雜的，并且可能對各種輸入參數的不同組合是敏感的。這可能會(huì )有數百萬(wàn)種潛在變化，這些變化會(huì )產(chǎn)生不同的結果，因此，對計算過(guò)程進(jìn)行全面的測試才能保證計算的正確性。
手工開(kāi)發(fā)和驗證大量的計算性測試用例是非常浪費時(shí)間的。在大多數情況下，通過(guò)界面執行大量的測試用例也是非常緩慢的。此時(shí)一個(gè)更高效的方法是自制開(kāi)發(fā)一個(gè)測試工具，它會(huì )直接針對應用程序的代碼(一般是直接針對用戶(hù)界面層之下的核心組件)執行測試用例。
另一種使用自制測試工具的方法是：對照遺留組件或者系統來(lái)比較新組件。兩個(gè)系統通常使用的數據存儲格式是不同的，用不同的技術(shù)實(shí)現的用戶(hù)界面也是不同的。此時(shí)，為了在兩個(gè)系統上運行相同的測試用例并且生成比較報告，自動(dòng)測試工具需要一種特殊的機制來(lái)復制自動(dòng)測試腳本。在最壞的情況下，單個(gè)測試工具不能同時(shí)兼容兩個(gè)系統，此時(shí)兩套測試腳本必須用兩種不同的自動(dòng)測試工具來(lái)開(kāi)發(fā)。一個(gè)更好的替代方案是自制生成一個(gè)定制的、自動(dòng)測試工具，它把兩個(gè)系統之間的差異封裝進(jìn)獨立的模塊，這樣我們就能夠設計出同時(shí)適用于兩套系統的測試。自制的自動(dòng)測試工具可以把遺留系統產(chǎn)生的測試結果作為基線(xiàn)，并且通過(guò)比較兩套結果和輸出它們之間的差異來(lái)自動(dòng)地驗證新系統產(chǎn)生的結果。
達到上述目的的一種方法是使用自制工具適配器模式。自制測試工具適配器是一個(gè)模塊，它通過(guò)轉換或者改造正在測試地每個(gè)系統使之和自制測試工具兼容，這樣自制測試工具可以通過(guò)適配器在系統種執行預定義地測試用例，并且把結果存儲為相互之見(jiàn)可以自動(dòng)比較地標準格式。對于每個(gè)開(kāi)發(fā)出來(lái)地適配器必須能夠直接和系統進(jìn)行交互和針對系統執行測試用例。用一個(gè)自制測試工具測試兩個(gè)系統需要不同地適配器并獨立調用兩次自制測試工具，每個(gè)系統調用一次。兩次調用的結果應用保留起來(lái)并進(jìn)行比較。圖示描述了針對遺留系統和新系統執行測試用例的定制測試工具。
通過(guò)為每個(gè)系統使用不同的適配器，相同的測試用例可以用于多個(gè)系統。針對遺留系統的適配器來(lái)產(chǎn)生一組基線(xiàn)結果，這個(gè)結果用于和新系統的結果比較。
為了完成他們的任務(wù)，自制的測試工具適配器首先獲得一組測試用例，然后按照順序執行這些用例，從而直接測試每個(gè)系統的邏輯，繞過(guò)了用戶(hù)界面。繞過(guò)用戶(hù)界面使性能得到了優(yōu)化，使得測試用例的吞吐量最大化。它還具有更高的穩定性。如果自制測試工具依賴(lài)于用戶(hù)界面，那么用戶(hù)界面的任何變化(在開(kāi)發(fā)生命周期種，用戶(hù)界面經(jīng)常會(huì )經(jīng)過(guò)多次修改)都可能導致自制測試工具對缺陷的漏識別。檢查這樣的結果會(huì )浪費大量寶貴的時(shí)間。
每個(gè)測試用例的執行結果被存儲在一個(gè)或者多個(gè)結果文件中，存儲的格式使相同的。與正在測試的系統無(wú)關(guān)。保存結果文件是為了與隨后運行的測試產(chǎn)生的結果進(jìn)行比較。比較可以有一個(gè)定制生成的結果工具來(lái)完成，這個(gè)工具按照一定的規則讀取和評估結果文件，并且輸出發(fā)現的所有錯誤或者差異。如果我們把結果格式化，那么也可以通過(guò)標準的“file diff”(比較文件差異)工具對它們進(jìn)行比較。
與所有的測試類(lèi)型一樣，自制測試工具使用的測試用例可能使相當復雜的，特別是當自制測試工具所測試的組件使用于數學(xué)計算或者科學(xué)計算的時(shí)候，利用自制的測試工具就可以覆蓋大部分的測試。
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/