軟件測試自動(dòng)化的糾結 軟件測試
人們在談到軟件測試自動(dòng)化時(shí)，首先會(huì )想到測試工具，包括功能測試工具、性能測試工具等。而測試工具能執行各種不同的、具體的測試，就依賴(lài)于測試腳本。測試人員通過(guò)開(kāi)發(fā)測試腳本(test script)，來(lái)實(shí)現測試用例所要進(jìn)行的具體操作和驗證。一旦選定測試工具，則測試腳本的開(kāi)發(fā)就成為測試人員的日常工作之一，也是測試自動(dòng)化的最主要的工作。也就是說(shuō)，測試腳本的開(kāi)發(fā)和維護直接關(guān)系到軟件測試自動(dòng)化的成敗，至少對自動(dòng)化測試的投入產(chǎn)出存在巨大的影響。
測試腳本從最初的錄制腳本發(fā)展到結構化腳本、數據驅動(dòng) (data-driven)腳本，再發(fā)展到關(guān)鍵字驅動(dòng)(keyword-driven)腳本。從歷史發(fā)展過(guò)程來(lái)看，數據驅動(dòng)腳本和關(guān)鍵字驅動(dòng)腳本對提高自動(dòng)化測試腳本開(kāi)發(fā)效率有顯著(zhù)的幫助，而且也有利于腳本的維護。下面這個(gè)表，可以充分說(shuō)明不同類(lèi)型的測試腳本對自動(dòng)化收益的影響是很大的。
自動(dòng)化測試腳本類(lèi)型成本收益凈收益
錄制和回放 8.3112.7
數據驅動(dòng)腳本 8.4189.6
關(guān)鍵字驅動(dòng)腳本(自動(dòng)化測試框架) 9.8155.2
關(guān)鍵字驅動(dòng)/數據驅動(dòng)混合結構 11.6197.4
下面是一個(gè)簡(jiǎn)單的關(guān)鍵字驅動(dòng)腳本示例：
命令對象值
open/change_address_form.html
typeaddress_fieldBetelgeuse state prison
clickAndWait//input[@name='Submit']
verifyTextPresentAddress change successful<
從中看出，這樣的業(yè)務(wù)邏輯很清楚，操作起來(lái)簡(jiǎn)單。而且，伴隨著(zhù)關(guān)鍵字驅動(dòng)腳本的誕生，也相繼出現了各種自動(dòng)化測試框架，形成良好的腳本開(kāi)發(fā)環(huán)境或平臺，使得自動(dòng)化測試腳本的開(kāi)發(fā)更具開(kāi)放性、可視性和層次性，測試人員開(kāi)發(fā)和維護腳本都變得更輕松、容易，從而在整體上進(jìn)一步提高自動(dòng)化測試的效率和應用范圍。
當然，任何事情都不會(huì )十全十美，會(huì )存在另外一個(gè)問(wèn)題。一旦自動(dòng)化測試框架及其工具完成之后，測試人員的腳本開(kāi)發(fā)工作簡(jiǎn)單，缺乏技術(shù)含量，可能缺少編程的鍛煉機會(huì )，從而在自動(dòng)化測試的實(shí)施過(guò)程中帶來(lái)一個(gè)新的糾結問(wèn)題——是使用關(guān)鍵字驅動(dòng)腳本開(kāi)發(fā)模式還是使用原生態(tài)的腳本語(yǔ)言(如Python、VBScript，甚至C++/C#、Java等)開(kāi)發(fā)模式?這里主要指Frontend功能測試的自動(dòng)化，涉及UI。如果是backend 或API 的自動(dòng)化測試，相對容易。
如果采用關(guān)鍵字驅動(dòng)腳本的開(kāi)發(fā)模式，個(gè)人能力得不到提高。而且感覺(jué)，一旦離開(kāi)公司原有的腳本開(kāi)發(fā)經(jīng)驗幾乎沒(méi)有價(jià)值。而如果采用原生態(tài)的腳本語(yǔ)言，個(gè)人編程能力得到實(shí)實(shí)在在的鍛煉，這些能力是業(yè)界普遍需要的，所以個(gè)人的價(jià)值得到提高。從這個(gè)職業(yè)發(fā)展角度看，測試人員更樂(lè )于采用原生態(tài)的腳本語(yǔ)言，而不愿采用關(guān)鍵字驅動(dòng)腳本，特別是對那些看作個(gè)人發(fā)展的員工，會(huì )有一個(gè)權衡的考慮。
站在公司角度看，應更多考慮自動(dòng)化測試的投入產(chǎn)出，毫無(wú)疑問(wèn)選擇關(guān)鍵字驅動(dòng)腳本，保證自動(dòng)化測試效率。如果選用原生態(tài)的腳本語(yǔ)言，那么自動(dòng)化測試的開(kāi)發(fā)工作量會(huì )增加，要求測試人員和開(kāi)發(fā)人員達到1：1的配備，將來(lái)自動(dòng)化測試的腳本維護也會(huì )是一個(gè)很大的問(wèn)題。如果選擇像C++/C#這樣高級語(yǔ)言來(lái)寫(xiě)自動(dòng)化測試腳本，腳本變得復雜，會(huì )帶來(lái)腳本本身測試/驗證的問(wèn)題，形成了一個(gè)無(wú)窮的“遞歸循環(huán)”。
從管理角度看，可以采取行政命令，統一行動(dòng)，全面采用優(yōu)秀的自動(dòng)化測試框架和關(guān)鍵字驅動(dòng)腳本，確保有高產(chǎn)出投入比(ROI)。同時(shí)，過(guò)于強制實(shí)施某套方案，可能會(huì )不利于員工的工作積極性或主動(dòng)性，也會(huì )對生產(chǎn)力產(chǎn)生負面影響。
站在公司角度，也要關(guān)懷員工，幫助員工的職業(yè)發(fā)展，如何創(chuàng )建更多的機會(huì )給員工來(lái)提高自己的能力。所以，全面推行關(guān)鍵字腳本的軟件開(kāi)發(fā)呢，還是允許部分團隊采取那種相對原始的腳本開(kāi)發(fā)模式呢? 這是一對矛盾，需要平衡和疏導。有些獨立的項目、周期短的項目、局部的項目可以放開(kāi)，由團隊自己來(lái)決定，而對最核心的全局產(chǎn)品開(kāi)發(fā)、周期長(cháng)的項目統一到同一個(gè)支持關(guān)鍵字驅動(dòng)腳本的自動(dòng)化框架上來(lái)。
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
