通常在項(xiàng)目中，測試用例設(shè)計(jì)完成并通過評審后，測試人員會(huì)按照測試用例中描述的程序一步步進(jìn)行測試，得到實(shí)際結(jié)果與預(yù)期結(jié)果的對比。在這個(gè)過程中，為了節(jié)省人力、時(shí)間或硬件資源，提高測試效率，引入了自動(dòng)化測試的

通常在項(xiàng)目中，測試用例設(shè)計(jì)完成并通過評審后，測試人員會(huì)按照測試用例中描述的程序一步步進(jìn)行測試，得到實(shí)際結(jié)果與預(yù)期結(jié)果的對比。在這個(gè)過程中，為了節(jié)省人力、時(shí)間或硬件資源，提高測試效率，引入了自動(dòng)化測試的概念。

最初的自動(dòng)化測試是為了取代重復(fù)的手工測試，主要用于回歸測試和測試同一軟件的新版本。所以在測試之前要考慮如何測試應(yīng)用，比如那些功能，操作步驟，輸入數(shù)據(jù)，預(yù)期輸出數(shù)據(jù)。

目前自動(dòng)化測試的腳本編寫通常是基于已有的手工測試用例，將手工測試用例編寫成相應(yīng)的自動(dòng)化腳本。

并不是所有的項(xiàng)目都需要是自動(dòng)化測試項(xiàng)目，有時(shí)候手工測試可能比自動(dòng)化測試簡單，有時(shí)候由于技術(shù)或環(huán)境因素，有些功能無法自動(dòng)化。

通常適用于軟件測試自動(dòng)化的場合:

與手工測試相比，測試自動(dòng)化的優(yōu)勢是顯而易見的。首先，自動(dòng)化測試可以提高測試效率，使測試人員更加關(guān)注新測試模塊的建立和開發(fā)，從而提高測試覆蓋率。其次，自動(dòng)化測試更便于測試資產(chǎn)的數(shù)字化管理，使得測試資產(chǎn)可以在整個(gè)測試生命周期中重用，這在功能測試和回歸測試中尤其有意義。

通過流程圖我們可以看到，在測試用例編寫之前，自動(dòng)測試流程圖和手動(dòng)測試流程基本相同，不同的是，在測試用例輸出之后，腳本開發(fā)人員開始編寫腳本，腳本編寫完成之后執(zhí)行自動(dòng)測試。

在對一個(gè)項(xiàng)目進(jìn)行自動(dòng)化測試之前，有必要對軟件需求進(jìn)行分析，看它是否適合自動(dòng)化測試。對適合自動(dòng)化測試的項(xiàng)目或模塊進(jìn)行自動(dòng)化測試，對不適合的及時(shí)提出。

可以進(jìn)行自動(dòng)測試，通常需要同時(shí)滿足以下條件:

需求的穩(wěn)定性決定了自動(dòng)化腳本的維護(hù)成本。如果軟件需求變化過于頻繁，測試人員需要根據(jù)變化的需求更新測試用例以及相關(guān)的測試腳本，而腳本的維護(hù)本身就是一個(gè)代碼開發(fā)的過程，需要修改、調(diào)試，必要時(shí)還要修改自動(dòng)化測試的框架。如果成本不低于使用它節(jié)省的測試成本，那么使用自動(dòng)化測試就沒有意義。

項(xiàng)目中有些模塊是相對穩(wěn)定的，而有些模塊的需求是高度可變的。我們可以對相對穩(wěn)定的模塊進(jìn)行自動(dòng)測試，但手工測試仍然是最大的變化。

確定自動(dòng)化測試的需求，設(shè)計(jì)自動(dòng)化測試的框架，編寫和調(diào)試測試腳本，需要很長時(shí)間。這個(gè)過程本身就是一個(gè)測試軟件的開發(fā)過程，需要很長時(shí)間才能完成。如果項(xiàng)目周期很短，沒有足夠的時(shí)間來支持這樣的過程，那么將不需要引入自動(dòng)化測試，手動(dòng)測試是完全勝任的。

根據(jù)項(xiàng)目進(jìn)度，制定自動(dòng)化腳本的交付時(shí)間和范圍。

在啟動(dòng)自動(dòng)測試之前，最好制定測試計(jì)劃，明確測試對象、測試目的、測試項(xiàng)目內(nèi)容、測試方法和測試進(jìn)度要求，確保測試所需的人力、硬件等資源準(zhǔn)備充分。測試計(jì)劃制定后，分配給測試組中的人員，測試組中的人員根據(jù)計(jì)劃完成分配給他們的任務(wù)。

自動(dòng)化用例的設(shè)計(jì)與手工用例的設(shè)計(jì)是一致的，大部分用例沒有單獨(dú)區(qū)分，而是由用例設(shè)計(jì)者統(tǒng)一設(shè)計(jì)。在用例的手工測試執(zhí)行過程中，自動(dòng)化人員編寫測試腳本。在實(shí)際項(xiàng)目中，自動(dòng)化用例的設(shè)計(jì)一般分為兩種情況:

通常這類企業(yè)已經(jīng)有成熟的用例，需要招聘自動(dòng)編碼人員對已有的用例進(jìn)行自動(dòng)化。這類公司的汽車制造商只需要根據(jù)現(xiàn)有的用例實(shí)現(xiàn)自動(dòng)化。

有些公司特別注重測試的質(zhì)量。這時(shí)候往往需要一個(gè)非常熟悉需求的有經(jīng)驗(yàn)的測試人員來負(fù)責(zé)測試用例的編寫，防止漏測的發(fā)生。

在這種情況下，大多數(shù)現(xiàn)有的用例被修改和補(bǔ)充，以促進(jìn)自動(dòng)腳本改編。

這種情況一般是因?yàn)楣救狈y試。每個(gè)人都分配任務(wù)。這個(gè)時(shí)候，自動(dòng)化測試人員需要根據(jù)分配的任務(wù)設(shè)計(jì)用例，也可能負(fù)擔(dān)得起手工測試，以及用例編寫者和用例執(zhí)行者的身份。

腳本應(yīng)按照管理規(guī)范編寫和命名，以便統(tǒng)一管理和維護(hù)。腳本寫好之后，需要反復(fù)執(zhí)行，不斷調(diào)試，直到運(yùn)行正常。調(diào)試過程中也可能發(fā)現(xiàn)產(chǎn)品質(zhì)量問題，此時(shí)就需要提單跟蹤。

腳本的質(zhì)量會(huì)影響整個(gè)自動(dòng)化執(zhí)行的效率和質(zhì)量，甚至后期的維護(hù)成本。每一個(gè)自動(dòng)化腳本誕生后都會(huì)在后續(xù)版本中繼續(xù)運(yùn)行。如果一個(gè)腳本有質(zhì)量問題，就意味著這個(gè)腳本檢測到的測試點(diǎn)會(huì)一直被遺漏。

一個(gè)自動(dòng)化腳本開發(fā)人員應(yīng)該是一個(gè)合格的、有經(jīng)驗(yàn)的測試人員。

方便后續(xù)的腳本搜索。

后來通過腳本的注釋，你很容易知道腳本中寫的是哪個(gè)用例，以及用例的詳細(xì)信息。

第一個(gè)好處是可以一眼看出腳本的創(chuàng)建者是什么時(shí)候創(chuàng)建的，修改者是什么時(shí)候修改的，方便有人定位問題。

第二個(gè)好處是后續(xù)腳本有問題，責(zé)任明確。

腳本中的檢查點(diǎn)太多，會(huì)導(dǎo)致兩個(gè)問題。第一，劇本太長，不利于后期維護(hù)。二是檢測點(diǎn)過多，不利于問題定位。

如果在編寫腳本時(shí)沒有恢復(fù)腳本修改或創(chuàng)建的內(nèi)容，很可能會(huì)對后面運(yùn)行的腳本產(chǎn)生影響。

腳本開發(fā)人員寫好腳本后，不應(yīng)該直接交付腳本參與測試，而應(yīng)該分組。編織組的專家會(huì)審核劇本。確認(rèn)劇本沒有問題后，才能參加測試。(一般有兩種觀點(diǎn)。一種是交叉查看，組內(nèi)的腳本開發(fā)人員互相查看。另一種是由測試經(jīng)理或自動(dòng)化主管統(tǒng)一查看)

自動(dòng)化測試的執(zhí)行不依賴于人員，自動(dòng)化測試可以在任何時(shí)候執(zhí)行。但是執(zhí)行自動(dòng)化腳本并不總是合適的。

一般來說，自動(dòng)測試腳本是在設(shè)備空閑時(shí)運(yùn)行的，因?yàn)椴煌哪_本會(huì)有影響。如果同時(shí)運(yùn)行多個(gè)腳本，或者在運(yùn)行腳本的同時(shí)有其他人在使用設(shè)備，就會(huì)導(dǎo)致定位困難的問題。比如運(yùn)行一個(gè)腳本，需要?jiǎng)h除一些數(shù)據(jù)，但是就在腳本運(yùn)行之前，有人用環(huán)境刪除了要?jiǎng)h除的數(shù)據(jù)，那么腳本就會(huì)出錯(cuò)。如果你不 不看產(chǎn)品的運(yùn)行日志，或者日志記錄不清楚，很可能被當(dāng)作a "bug "。但是這個(gè) "bug "不是真正的bug，沒有辦法定位和修改，最終會(huì)被認(rèn)為是不可重復(fù)的問題。在此期間，開發(fā)人力和測試人力都被浪費(fèi)了。

自動(dòng)化執(zhí)行者和腳本編寫者可能不是同一個(gè)人。在實(shí)際項(xiàng)目中，很可能是一個(gè)人運(yùn)行產(chǎn)品的所有自動(dòng)化腳本。如果腳本運(yùn)行失敗，操作員需要大致分析腳本失敗的原因:如果是產(chǎn)品問題，需要通過提貨單追蹤；如果是腳本問題，可以找相應(yīng)的腳本開發(fā)者修改；如果是環(huán)境問題，那就修復(fù)環(huán)境。

自動(dòng)化測試結(jié)果應(yīng)該及時(shí)分析。如果沒有專人來執(zhí)行自動(dòng)化測試，建議測試人員每天抽出一些時(shí)間來分析自動(dòng)化測試結(jié)果，以便盡早發(fā)現(xiàn)缺陷。如果有人負(fù)責(zé)自動(dòng)化測試，就可以有人來做。

理想情況下，自動(dòng)化測試用例運(yùn)行失敗后，自動(dòng)化測試平臺會(huì)自動(dòng)粗略判斷缺陷是什么，然后對缺陷進(jìn)行初步分類(腳本問題？環(huán)境問題？產(chǎn)品問題？)。如果是產(chǎn)品問題，會(huì)自動(dòng)報(bào)告缺陷。測試人員仍然需要確認(rèn)這些自動(dòng)報(bào)告的缺陷是否是真實(shí)的系統(tǒng)缺陷。如果是產(chǎn)品缺陷，提交給開發(fā)商維修；如果不是系統(tǒng)缺陷，檢查自動(dòng)化測試腳本或者測試環(huán)境；如果是環(huán)境問題，需要在環(huán)境上確認(rèn)；如果是腳本問題，腳本開發(fā)者修改腳本。

測試中記錄的bug應(yīng)該記錄在缺陷管理工具中，這樣它們就可以被定期跟蹤和處理。開發(fā)者修復(fù)問題后，需要進(jìn)行回歸測試，即重復(fù)問題對應(yīng)的細(xì)的地方，通過就關(guān)閉，否則繼續(xù)修改。與手工測試回歸相比，自動(dòng)測試回歸要方便得多，它只需要運(yùn)行失敗的用例以及與開發(fā)修改點(diǎn)相關(guān)的用例。

如果問題的修改方案與客戶達(dá)成一致，但偏離了原來的需求，那么在回歸測試之前您還需要根據(jù)需要修改和調(diào)試腳本。

自動(dòng)化腳本完成后，測試組長需要對所有的測試結(jié)果進(jìn)行分析，分析結(jié)果一般是基于數(shù)據(jù)的。比如已經(jīng)執(zhí)行了多少自動(dòng)化用例，覆蓋了哪些功能模塊，用例通過的百分比，有多少腳本失敗是產(chǎn)品問題，是否所有的產(chǎn)品問題都有提貨單跟蹤。

通過對劇本的分析，可以了解項(xiàng)目的運(yùn)作情況，可以及時(shí)調(diào)整和計(jì)劃。

許多自動(dòng)化腳本可以 不要寫了，運(yùn)行幾年，他們永遠(yuǎn)不會(huì)改變。

一般來說，產(chǎn)品的需求可能會(huì)發(fā)生變化，用例、腳本也會(huì)隨著需求的變化而變化。這樣，自動(dòng)腳本編寫者就有必要添加腳本，或者及時(shí)剔除或修改不合適的腳本。

不僅需求會(huì)改變，腳本也會(huì)改變。運(yùn)行腳本時(shí)可能會(huì)發(fā)現(xiàn)腳本的穩(wěn)定性和可靠性不好，導(dǎo)致有些腳本有時(shí)運(yùn)行成功，有時(shí)運(yùn)行不成功。這也需要腳本開發(fā)人員對腳本進(jìn)行強(qiáng)化。

交通服務(wù)自動(dòng)化應(yīng)用案例——自動(dòng)化公路是交通自動(dòng)化的先導(dǎo)和基礎(chǔ)，也是現(xiàn)代工業(yè)國家的生命線。在許多國家，交通堵塞造成的時(shí)間延誤、燃料浪費(fèi)和不必要的廢氣排放給社會(huì)造成了巨大的損失。有些人可能認(rèn)為解決問題的方法無非是多建幾條路。