全國(guó)統(tǒng)一學(xué)習(xí)專線 8:30-21:00
返學(xué)費(fèi)網(wǎng) > 培訓(xùn)機(jī)構(gòu) > 南京信盈達(dá)
自動(dòng)化測(cè)試基本流程
1、制定測(cè)試計(jì)劃
在展開自動(dòng)化測(cè)試之前，最好做個(gè)測(cè)試計(jì)劃，明確測(cè)試對(duì)象、測(cè)試目的、測(cè)試的項(xiàng)目?jī)?nèi)容、測(cè)試的方法、測(cè)試的進(jìn)度要求，并確保測(cè)試所需的人力、硬件、數(shù)據(jù)等資源都準(zhǔn)備充分。制定好測(cè)試計(jì)劃后，下發(fā)給用例設(shè)計(jì)者。
2、分析測(cè)試需求
用例設(shè)計(jì)者根據(jù)測(cè)試計(jì)劃和需求說明書，分析測(cè)試需求，設(shè)計(jì)測(cè)試需求樹，以便用例設(shè)計(jì)時(shí)能夠覆蓋所有的需求點(diǎn)。一般來(lái)講，基于Web功能測(cè)試需要覆蓋一下幾個(gè)方面：
1）頁(yè)面鏈接測(cè)試，確保各個(gè)鏈接正常；
2）頁(yè)面控件測(cè)試，確保各個(gè)控件可靠；
3）頁(yè)面功能測(cè)試，確保各項(xiàng)操作正常；
4）數(shù)據(jù)處理測(cè)試，確保數(shù)據(jù)顯示準(zhǔn)確、處理精確可靠；
5）模塊業(yè)務(wù)邏輯測(cè)試，確保各個(gè)業(yè)務(wù)流程暢通。
3、設(shè)計(jì)測(cè)試用例
通過分析測(cè)試需求，設(shè)計(jì)出能夠覆蓋所有需求點(diǎn)的測(cè)試用例，形成專門的測(cè)試用例文檔。由于不是所有的測(cè)試用例都能用自動(dòng)化來(lái)執(zhí)行，所以需要將能夠執(zhí)行自動(dòng)化測(cè)試的用例匯總成自動(dòng)化測(cè)試用例。必要時(shí)，要將登陸系統(tǒng)的用戶、密碼、產(chǎn)品、客戶等參數(shù)信息獨(dú)立出來(lái)形成測(cè)試數(shù)據(jù)，便于腳本開發(fā)。
4、搭建測(cè)試環(huán)境
自動(dòng)化測(cè)試人員在用例設(shè)計(jì)工作開展的同時(shí)即可著手搭建測(cè)試環(huán)境。因?yàn)樽詣?dòng)化測(cè)試的腳本編寫需要錄制頁(yè)面控件，添加對(duì)象。測(cè)試環(huán)境的搭建，包括被測(cè)系統(tǒng)的部署、測(cè)試硬件的調(diào)用、測(cè)試工具的安裝和設(shè)置、網(wǎng)絡(luò)環(huán)境的布置等。
5、編寫測(cè)試腳本
根據(jù)自動(dòng)化測(cè)試用例和問題的難易程度，采取適當(dāng)?shù)哪_本開發(fā)方法編寫測(cè)試較薄。一般先通過錄制的方式獲取測(cè)試所需要的頁(yè)面控件，然后再用結(jié)構(gòu)化語(yǔ)句控制腳本的執(zhí)行，插入檢查點(diǎn)和異常判定反饋語(yǔ)句，將公共普遍的功能獨(dú)立成共享腳本，必要時(shí)對(duì)數(shù)據(jù)驚醒參數(shù)化。當(dāng)然還可以用其他高級(jí)功能編輯腳本。腳本編寫好了之后，需要反復(fù)執(zhí)行，不斷調(diào)試，知道運(yùn)行正常為止。腳本的編寫和命名要符合管理規(guī)范，以便統(tǒng)一管理和維護(hù)。
6、分析測(cè)試結(jié)果、記錄測(cè)試問題
應(yīng)該及時(shí)分析自動(dòng)化測(cè)試結(jié)果，建議測(cè)試人員每天抽出一定時(shí)間，對(duì)自動(dòng)化測(cè)試結(jié)果進(jìn)行分析，以便盡早地發(fā)現(xiàn)缺陷。如果采用開源自動(dòng)化測(cè)試工具，建議對(duì)其進(jìn)行二次開發(fā)，以便與測(cè)試部門選定的缺陷管理工具緊密結(jié)合。理想情況下，自動(dòng)化測(cè)試案例運(yùn)行失敗后，自動(dòng)化測(cè)試平臺(tái)就會(huì)自動(dòng)上報(bào)一個(gè)缺陷。測(cè)試人員只需每天抽出一地你該時(shí)間，確認(rèn)這些自動(dòng)上報(bào)的缺陷，是否是真實(shí)的系統(tǒng)缺陷。如果是系統(tǒng)缺陷就提交開發(fā)人員修復(fù)，如果不是系統(tǒng)缺陷，就檢查自動(dòng)化測(cè)試腳本或者測(cè)試環(huán)境。
7、跟蹤測(cè)試BUG
測(cè)試記錄的BUG要記錄到缺陷管理工具中去，以便定期跟蹤處理。開發(fā)人員修復(fù)后，需要對(duì)此問題執(zhí)行回歸測(cè)試，就是重復(fù)執(zhí)行一次該問題對(duì)應(yīng)的較薄，執(zhí)行通過則關(guān)閉，否則繼續(xù)修改。如果問題的修改方案與客戶達(dá)成一致，但與原來(lái)的需求有所偏離，那么在回歸測(cè)試前，還需要對(duì)腳本進(jìn)行必要的修改和調(diào)試。
8、自動(dòng)化腳本的維護(hù)
如果系統(tǒng)發(fā)生變更時(shí)，對(duì)自動(dòng)化測(cè)試腳本和相關(guān)文檔包括《自動(dòng)化測(cè)試用例》、《自動(dòng)化腳本設(shè)計(jì)說明書》進(jìn)行維護(hù)，以適應(yīng)變更后的系統(tǒng)。
自動(dòng)化測(cè)試的問題我們已經(jīng)探討了很多次了，所以今天我們就給大家簡(jiǎn)單分享了在自動(dòng)化測(cè)試過程中常用的一些測(cè)試工具和方法，下面java課程就一起來(lái)了解一下吧。希望通過對(duì)本文的閱讀，能夠提高大家對(duì)自動(dòng)化測(cè)試的認(rèn)識(shí)和理解。
1.帶的Selenium
Selenium無(wú)疑是受歡迎的Web自動(dòng)化測(cè)試工具。其開源的特性是被廣泛使用的原因之一。您可以使用不同的語(yǔ)言在Selenium中實(shí)施各種框架，從而為自動(dòng)化測(cè)試提供更多的功能。
Selenium能夠支持多種操作系統(tǒng)(Windows、Mac、Linux)和多種瀏覽器(Chrome、火狐、IE和Headless類型瀏覽器)。我們可以運(yùn)用多種語(yǔ)言(如Java、Groovy、Python、C#、PHP、Ruby和Perl)來(lái)開發(fā)出不同的測(cè)試腳本。
Selenium內(nèi)置了許多工具和框架，您可以啟用它們來(lái)進(jìn)行持續(xù)測(cè)試。是Selenium用來(lái)進(jìn)行持續(xù)測(cè)試的一種常用的框架。通過Robot，您可以運(yùn)行各種自動(dòng)化測(cè)試，包括由所提供的、基于UI元素和API的測(cè)試。
Selenium既可以使用關(guān)鍵字驅(qū)動(dòng)的方法進(jìn)行驗(yàn)收測(cè)試，也可以進(jìn)行驗(yàn)收測(cè)試驅(qū)動(dòng)式的開發(fā)(-，ATDD)。通過使用Python和Java所實(shí)現(xiàn)的附加測(cè)試庫(kù)，其測(cè)試功能得到了進(jìn)一步擴(kuò)展。而不僅可以用于Web應(yīng)用的測(cè)試，也可被用來(lái)測(cè)試Android和iOS的應(yīng)用。
但是，Selenium本身并不能滿足所有的持續(xù)測(cè)試需求。它需要與大量的工具相集成，以滿足在軟件開發(fā)生命周期(SDLC)中的不同目的。此外，Selenium還需要使用者具有高級(jí)的編程技能，并愿意花費(fèi)專門的時(shí)間與精力，來(lái)構(gòu)建自動(dòng)化框架，以滿足其特定的測(cè)試需求。
2.Testsigma
Testsigma是一個(gè)統(tǒng)一的、以AI驅(qū)動(dòng)測(cè)試的自動(dòng)化平臺(tái)。它采用Shift-Left方法，將持續(xù)測(cè)試集成到了端到端的持續(xù)交付生態(tài)系統(tǒng)之中。Testsigma通過減少自動(dòng)化測(cè)試技術(shù)中的復(fù)雜性，為功能和自動(dòng)化團(tuán)隊(duì)帶來(lái)了更多的靈活性。
功能測(cè)試人員可以輕松地使用自然語(yǔ)言，編寫出簡(jiǎn)化的代碼，來(lái)進(jìn)行自動(dòng)化測(cè)試。Testsigma通過可重用的步驟組合、與集中對(duì)象存儲(chǔ)庫(kù)()大限度地提高了測(cè)試代碼的重用性。同時(shí)它通過使用AI，來(lái)大幅降低了與測(cè)試有關(guān)的維護(hù)開銷。
Testsigma能夠與各種開源的或三方工具相集成。它支持上千種不同“設(shè)備+瀏覽器+操作系統(tǒng)”組合的云端測(cè)試環(huán)境，以不斷滿足各種的動(dòng)態(tài)測(cè)試需求。
Testsigma能為企業(yè)級(jí)的自動(dòng)化測(cè)試、和持續(xù)測(cè)試提供所有必需的功能，其中包括：數(shù)據(jù)驅(qū)動(dòng)測(cè)試、跨瀏覽器測(cè)試、可重用性測(cè)試套件、測(cè)試計(jì)劃與數(shù)據(jù)管理、電子郵件與Slack通知、并行測(cè)試執(zhí)行、集中對(duì)象/元素存儲(chǔ)庫(kù)、綜合報(bào)告、與CI工具的集成、以及自動(dòng)化Bug報(bào)告等。
作為一款基于云端的自動(dòng)化測(cè)試工具，Testsigma為Web、移動(dòng)Web、Android、iOS應(yīng)用、以及RESTful服務(wù)提供了各種類型的應(yīng)用支持。
3.
RFT是另一種能夠進(jìn)行功能、API、性能和回歸測(cè)試的工具。使用記錄和回放來(lái)創(chuàng)建自動(dòng)化的功能測(cè)試，并將預(yù)期結(jié)果與執(zhí)行時(shí)系統(tǒng)所產(chǎn)生的實(shí)際結(jié)果相比較。
IBM支持廣泛的應(yīng)用程序，并能夠與等工具相集成。另外，還支持在API級(jí)別、用戶界面級(jí)別、以及整個(gè)系統(tǒng)級(jí)別進(jìn)行回歸測(cè)試，以實(shí)現(xiàn)在DevOps或持續(xù)交付生命周期內(nèi)的各種測(cè)試目標(biāo)。
一般是指軟件測(cè)試的自動(dòng)化，軟件測(cè)試就是在預(yù)設(shè)條件下運(yùn)行系統(tǒng)或應(yīng)用程序，評(píng)估運(yùn)行結(jié)果，預(yù)先條件應(yīng)包括正常條件和異常條件。自動(dòng)化測(cè)試是把以人為驅(qū)動(dòng)的測(cè)試行為轉(zhuǎn)化為機(jī)器執(zhí)行的一種過程。
基本信息
中文名稱
自動(dòng)化測(cè)試
外文名稱
Test
定 義
人為驅(qū)動(dòng)測(cè)試為轉(zhuǎn)為機(jī)器執(zhí)行過程
應(yīng) 用
軟件測(cè)試的自動(dòng)化
工 具
QTP
自動(dòng)化測(cè)試是把以人為驅(qū)動(dòng)的測(cè)試行為轉(zhuǎn)化為機(jī)器執(zhí)行的一種過程。通常，在設(shè)計(jì)了測(cè)試用例并通過評(píng)審之后，由測(cè)試人員根據(jù)測(cè)試用例中描述的規(guī)程一步步執(zhí)行測(cè)試，得到實(shí)際結(jié)果與期望結(jié)果的比較。在此過程中，為了節(jié)省人力、時(shí)間或硬件資源，提高測(cè)試效率，便引入了自動(dòng)化測(cè)試的概念。
折疊編輯本段工具介紹
折疊QTP
全名HP QuickTest software ，2012年12月6日發(fā)布11.5版本，并更名為Unified Testing
QTP是quicktest 的簡(jiǎn)稱，是一種自動(dòng)測(cè)試工具。使用QTP的目的是想用它來(lái)執(zhí)行重復(fù)的手動(dòng)測(cè)試，主要是用于回歸測(cè)試和測(cè)試同一軟件的新版本。因此你在測(cè)試前要考慮好如何對(duì)應(yīng)用程序進(jìn)行測(cè)試，例如要測(cè)試那些功能、操作步驟、輸入數(shù)據(jù)和期望的輸出數(shù)據(jù)等
QuickTest針對(duì)的是GUI應(yīng)用程序，包括傳統(tǒng)的Windows應(yīng)用程序，以越來(lái)越流行的Web應(yīng)用。它可以覆蓋絕大多數(shù)的軟件開發(fā)技術(shù)，簡(jiǎn)單高效，并具備測(cè)試用例可重用的特點(diǎn)。其中包括:創(chuàng)建測(cè)試、插入檢查點(diǎn)、檢驗(yàn)數(shù)據(jù)、增強(qiáng)測(cè)試、運(yùn)行測(cè)試、分析結(jié)果和維護(hù)測(cè)試等方面。
折疊WinRunner
Mercury 公司的WinRunner是一種企業(yè)級(jí)的功能測(cè)試工具，用于檢測(cè)應(yīng)用程序是否能夠達(dá)到預(yù)期的功能及正常運(yùn)行。通過自動(dòng)錄制、檢測(cè)和回放用戶的應(yīng)用操作，WinRunner能夠有效地幫助測(cè)試人員對(duì)復(fù)雜的企業(yè)級(jí)應(yīng)用的不同發(fā)布版進(jìn)行測(cè)試，提高測(cè)試人員的工作效率和質(zhì)量，確?？缙脚_(tái)的、復(fù)雜的企業(yè)級(jí)應(yīng)用無(wú)故障發(fā)布及長(zhǎng)期穩(wěn)定運(yùn)行。
企業(yè)級(jí)應(yīng)用可能包括Web應(yīng)用系統(tǒng)，ERP系統(tǒng)，CRM系統(tǒng)等等。這些系統(tǒng)在發(fā)布之前，升級(jí)之后都要經(jīng)過測(cè)試，確保所有功能都能正常運(yùn)行，沒有任何錯(cuò)誤。如何有效地測(cè)試不斷升級(jí)更新且不同環(huán)境的應(yīng)用系統(tǒng)，是每個(gè)公司都會(huì)面臨的問題。
折疊
是業(yè)界最頂尖的功能測(cè)試工具，它甚至可以在測(cè)試人員學(xué)習(xí)高級(jí)腳本技術(shù)之前幫助其進(jìn)行成功的測(cè)試。它集成在測(cè)試人員的桌面IBM Rational Test Manager上，在這里測(cè)試人員可以計(jì)劃、組織、執(zhí)行、管理和報(bào)告所有測(cè)試活動(dòng)，包括手動(dòng)測(cè)試報(bào)告。這種測(cè)試和管理的雙重功能是自動(dòng)化測(cè)試的理想開始。
折疊
AdventNet QEngine是一個(gè)應(yīng)用廣泛且獨(dú)立于平臺(tái)的自動(dòng)化軟件測(cè)試工具，可用于Web功能測(cè)試、web性能測(cè)試、Java應(yīng)用功能測(cè)試、Java API測(cè)試、SOAP測(cè)試、回歸測(cè)試和Java應(yīng)用性能測(cè)試。支持對(duì)于使用HTML、JSP、ASP、.NET、PHP、/VBScript、XML、SOAP、WSDL、e-commerce、傳統(tǒng)客戶端/服務(wù)器等開發(fā)的應(yīng)用程序進(jìn)行測(cè)試。此工具以Java開發(fā)，因此便于移植和提供多平臺(tái)支持。
折疊SilkTest
是業(yè)界領(lǐng)先的、用于對(duì)企業(yè)級(jí)應(yīng)用進(jìn)行功能測(cè)試的產(chǎn)品，可用于測(cè)試Web、Java或是傳統(tǒng)的C/S結(jié)構(gòu)。SilkTest提供了許多功能，使用戶能夠高效率地進(jìn)行軟件自動(dòng)化測(cè)試。這些功能包括:測(cè)試的計(jì)劃和管理;直接的數(shù)據(jù)庫(kù)訪問及校驗(yàn);靈活、強(qiáng)大的4Test腳本語(yǔ)言，內(nèi)置的恢復(fù)系統(tǒng)(Recovery System);以及具有使用同一套腳本進(jìn)行跨平臺(tái)、跨瀏覽器和技術(shù)進(jìn)行測(cè)試的能力。
折疊QARun
QARun的測(cè)試實(shí)現(xiàn)方式是通過鼠標(biāo)移動(dòng)、鍵盤點(diǎn)擊操作被測(cè)應(yīng)用，即而得到相應(yīng)的測(cè)試腳本，對(duì)該腳本可以進(jìn)行編輯和調(diào)試。在記錄的過程中可針對(duì)被測(cè)應(yīng)用中所包含的功能點(diǎn)進(jìn)行基線值的建立，換句話說就是在插入檢查點(diǎn)的同時(shí)建立期望值。在這里檢查點(diǎn)是目標(biāo)系統(tǒng)的一個(gè)特殊方面在一特定點(diǎn)的期望狀態(tài)。通常，檢查點(diǎn)在QARun提示目標(biāo)系統(tǒng)執(zhí)行一系列事件之后被執(zhí)行。檢查點(diǎn)用于確定實(shí)際結(jié)果與期望結(jié)果是否相同
折疊
是一個(gè)自動(dòng)化的功能測(cè)試工具，它專為測(cè)試基于微軟、Java和Web技術(shù)的復(fù)雜應(yīng)用而設(shè)計(jì)。它使測(cè)試人員和開發(fā)人員都可以使用可視的腳本編制和自動(dòng)向?qū)?lái)生成可重復(fù)的測(cè)試，用戶可以調(diào)用VBA的所有功能，并進(jìn)行任何水平層次和細(xì)節(jié)的測(cè)試。的腳本開發(fā)采用通用的、分層的方式來(lái)進(jìn)行。沒有編程知識(shí)的測(cè)試人員也可以通過的可視化導(dǎo)航器來(lái)快速創(chuàng)建測(cè)試并執(zhí)行。通過可視的導(dǎo)航器錄制并回放測(cè)試，每一個(gè)測(cè)試都將被展示為樹狀結(jié)構(gòu)，以清楚地顯現(xiàn)測(cè)試通過應(yīng)用的路徑。
折疊Holodeck
-強(qiáng)大的故障植入軟件測(cè)試工具
Holodeck is an advanced fault-injection tool that gives you the power to attack an while it monitors and logs your does - every function call, registry entry, piece of data read or written.
折疊
TAU第二代包含三個(gè)最新的、最強(qiáng)大的技術(shù)用來(lái)加速大規(guī)模軟件開發(fā)和測(cè)試:統(tǒng)一建模語(yǔ)言(UML)及它的許多最新修訂版本中的特性，UML2.0;功能強(qiáng)大的測(cè)試語(yǔ)言TTCN-3和新的構(gòu)造系統(tǒng)的方法:Model Driven (模型驅(qū)動(dòng)構(gòu)架)。這三個(gè)新的業(yè)界標(biāo)準(zhǔn)結(jié)合成TAU的已經(jīng)過認(rèn)可的軟件開發(fā)平臺(tái)，形成了一個(gè)系統(tǒng)，一個(gè)一流的穩(wěn)定可靠的工具解決方案。TAU第二代是系統(tǒng)與軟件開發(fā)解決方案的一個(gè)突破，它把業(yè)界從使用了太長(zhǎng)時(shí)間的手工、易出錯(cuò)、以代碼為中心的方法中釋放出來(lái)，自然而然地邁向下一步，一個(gè)更加可視化、自動(dòng)化及可靠的開發(fā)方法。Telelogic TAU/Tester是基于通用測(cè)試語(yǔ)言TTCN-3,用于自動(dòng)化的系統(tǒng)和集成測(cè)試的強(qiáng)大工具。TAU/Tester以現(xiàn)代化的開發(fā)工具為基礎(chǔ)，提供高層測(cè)試功能，支持整個(gè)測(cè)試生命周期，加速自動(dòng)化測(cè)試。TAU/Tester可使用戶特別關(guān)注于測(cè)試的開發(fā)，因?yàn)門TCN-3語(yǔ)言是獨(dú)立于開發(fā)語(yǔ)言或測(cè)試設(shè)備的，且是抽象和可移植的。
折疊
是黑盒測(cè)試工具，可以用來(lái)完成功能測(cè)試、回歸測(cè)試，可以提高測(cè)試效率，降低測(cè)試人工成本。
產(chǎn)品可以對(duì)以下類型對(duì)象進(jìn)行GUI功能性測(cè)試:
1 Windows類型對(duì)象，一般為用C++/Delphi/VB/VFP/PB/.NetForm等技術(shù)開發(fā)的桌面程序。
2 IE網(wǎng)頁(yè)對(duì)象，一般性的網(wǎng)站，比如大的門戶類網(wǎng)站。
3 Java對(duì)象，一般為用AWT/Swing/SWT等技術(shù)開發(fā)的桌面程序。
4 Flex對(duì)象，網(wǎng)頁(yè)的內(nèi)容是用Flex開發(fā)的。
5 對(duì)象，網(wǎng)頁(yè)的內(nèi)容是用開發(fā)的。
6 WPF對(duì)象，一般為用WPF技術(shù)開發(fā)的桌面程序。
7 QT對(duì)象，一般為用QT技術(shù)開發(fā)的桌面程序。
折疊
Phoenix Framework是一款基于 Selenium，Webdriver，autoIt研發(fā)的一款集資源管理和測(cè)試于一體的Web自動(dòng)化測(cè)試工具。最新版本是1.1.8，該工具支持無(wú)腳本執(zhí)行模式，無(wú)人值守執(zhí)行模式，自由定制模式。不僅執(zhí)行模式可以定制，功能模塊也支持定制。使用該工具的界面創(chuàng)建用例，組裝腳本，啟動(dòng)執(zhí)行。使用該工具其他開放的接口，可手動(dòng)創(chuàng)建腳本，組裝并執(zhí)行。它支持兩種部署模式，第一種是Server-Client方式，Server與Client均為EXE程序，通信協(xié)議是Socket;另一種是WEB版部署，方便與現(xiàn)有系統(tǒng)集成，支持Linux，將Server與Client放到Tomcat或Weblogic服務(wù)器下部署，通信協(xié)議為Http，通過WEB頁(yè)面控制并監(jiān)控Client端的執(zhí)行。
折疊編輯本段前提條件
實(shí)施自動(dòng)化測(cè)試之前需要對(duì)軟件開發(fā)過程進(jìn)行分析，以觀察其是否適合使用自動(dòng)化測(cè)試。通常需要同時(shí)滿足以下條件:
1) 需求變動(dòng)不頻繁
測(cè)試腳本的穩(wěn)定性決定了自動(dòng)化測(cè)試的維護(hù)成本。如果軟件需求變動(dòng)過于頻繁，測(cè)試人員需要根據(jù)變動(dòng)的需求來(lái)更新測(cè)試用例以及相關(guān)的測(cè)試腳本，而腳本的維護(hù)本身就是一個(gè)代碼開發(fā)的過程，需要修改、調(diào)試，必要的時(shí)候還要修改自動(dòng)化測(cè)試的框架，如果所花費(fèi)的成本不低于利用其節(jié)省的測(cè)試成本，那么自動(dòng)化測(cè)試便是失敗的。
項(xiàng)目中的某些模塊相對(duì)穩(wěn)定，而某些模塊需求變動(dòng)性很大。我們便可對(duì)相對(duì)穩(wěn)定的模塊進(jìn)行自動(dòng)化測(cè)試，而變動(dòng)較大的仍是用手工測(cè)試。
2) 項(xiàng)目周期足夠長(zhǎng)
自動(dòng)化測(cè)試需求的確定、自動(dòng)化測(cè)試框架的設(shè)計(jì)、測(cè)試腳本的編寫與調(diào)試均需要相當(dāng)長(zhǎng)的時(shí)間來(lái)完成，這樣的過程本身就是一個(gè)測(cè)試軟件的開發(fā)過程，需要較長(zhǎng)的時(shí)間來(lái)完成。如果項(xiàng)目的周期比較短，沒有足夠的時(shí)間去支持這樣一個(gè)過程，那么自動(dòng)化測(cè)試便成為笑談。
3) 自動(dòng)化測(cè)試腳本可重復(fù)使用
如果費(fèi)盡心思開發(fā)了一套近乎完美的自動(dòng)化測(cè)試腳本，但是腳本的重復(fù)使用率很低，致使其間所耗費(fèi)的成本大于所創(chuàng)造的經(jīng)濟(jì)價(jià)值，自動(dòng)化測(cè)試便成為了測(cè)試人員的練手之作，而并非是真正可產(chǎn)生效益的測(cè)試手段了。
另外，在手工測(cè)試無(wú)法完成，需要投入大量時(shí)間與人力時(shí)也需要考慮引入自動(dòng)化測(cè)試。比如性能測(cè)試、配置測(cè)試、大數(shù)據(jù)量輸入測(cè)試等。
折疊編輯本段適用場(chǎng)合
通常適合于軟件測(cè)試自動(dòng)化的場(chǎng)合:
(1)回歸測(cè)試，重復(fù)單一的數(shù)據(jù)錄入或是擊鍵等測(cè)試操作造成了不必要的時(shí)間浪費(fèi)和人力浪費(fèi);
(2)此外測(cè)試人員對(duì)程序的理解和對(duì)設(shè)計(jì)文檔的驗(yàn)證通常也要借助于測(cè)試自動(dòng)化工具;
(3)采用自動(dòng)化測(cè)試工具有利于測(cè)試報(bào)告文檔的生成和版本的連貫性;
(4)自動(dòng)化工具能夠確定測(cè)試用例的覆蓋路徑，確定測(cè)試用例集對(duì)程序邏輯流程和控制流程的覆蓋。
隨著測(cè)試流程的不斷規(guī)范以及軟件測(cè)試技術(shù)的進(jìn)一步細(xì)化，軟件測(cè)試自動(dòng)化已經(jīng)日益成為一支不可忽視的力量。能否借助于這支外在力量以及如何借助于這支力量來(lái)規(guī)范企業(yè)測(cè)試流程、提高特定測(cè)試活動(dòng)的效率，正是本期所要討論的話題。
軟件測(cè)試自動(dòng)化的研究領(lǐng)域主要集中在軟件測(cè)試流程的自動(dòng)化管理以及動(dòng)態(tài)測(cè)試的自動(dòng)化(如單元測(cè)試、功能測(cè)試以及性能方面)。在這兩個(gè)領(lǐng)域，與手工測(cè)試相比，測(cè)試自動(dòng)化的優(yōu)勢(shì)是明顯的。首先自動(dòng)化測(cè)試可以提高測(cè)試效率，使測(cè)試人員更加專注于新的測(cè)試模塊的建立和開發(fā)，從而提高測(cè)試覆蓋率;其次，自動(dòng)化測(cè)試更便于測(cè)試資產(chǎn)的數(shù)字化管理，使得測(cè)試資產(chǎn)在整個(gè)測(cè)試生命周期內(nèi)可以得到復(fù)用，這個(gè)特點(diǎn)在功能測(cè)試和回歸測(cè)試中尤其具有意義;此外，測(cè)試流程自動(dòng)化管理可以使機(jī)構(gòu)的測(cè)試活動(dòng)開展更加過程化，這很符合CMMI過程改進(jìn)的思想。根據(jù)的調(diào)查，在2001年前后的3年中，全球范圍內(nèi)由于采用了測(cè)試自動(dòng)化手段所實(shí)現(xiàn)的投資回報(bào)率高達(dá)1500%。
折疊編輯本段選型原則
然而存在優(yōu)勢(shì)是否就一定意味著選擇自動(dòng)化測(cè)試方案都能為企業(yè)帶來(lái)效益回報(bào)呢?也不盡然，任何一種產(chǎn)品化的測(cè)試自動(dòng)化工具，都可能存在與某具體項(xiàng)目不甚貼切的地方。再加上，在企業(yè)內(nèi)部通常存在許多不同種類的應(yīng)用平臺(tái)，應(yīng)用開發(fā)技術(shù)也不盡相同，甚至在一個(gè)應(yīng)用中可能就跨越了多種平臺(tái);或同一應(yīng)用的不同版本之間存在技術(shù)差異。所以選擇軟件測(cè)試自動(dòng)化方案必須深刻理解這一選擇可能帶來(lái)的變動(dòng)、來(lái)自諸多方面的風(fēng)險(xiǎn)和成本開銷。
以下筆者給出企業(yè)用戶進(jìn)行軟件測(cè)試自動(dòng)化方案選型的參考性原則，這些原則是從筆者實(shí)際工作中凝練而成的，它包括以下六個(gè)方面的建議:
●選擇盡可能少的自動(dòng)化產(chǎn)品覆蓋盡可能多的平臺(tái)，以降低產(chǎn)品投資和團(tuán)隊(duì)的學(xué)習(xí)成本;
●測(cè)試流程管理自動(dòng)化通常應(yīng)該優(yōu)先考慮，以滿足為企業(yè)測(cè)試團(tuán)隊(duì)提供流程管理支持的需求;
●在投資有限的情況下，性能測(cè)試自動(dòng)化產(chǎn)品將優(yōu)先于功能測(cè)試自動(dòng)化被考慮;
●在考慮產(chǎn)品性價(jià)比的同時(shí)，應(yīng)充分關(guān)注產(chǎn)品的支持服務(wù)和售后服務(wù)的完善性;
●盡量選擇趨于主流的產(chǎn)品，以便通過行業(yè)間交流甚至網(wǎng)絡(luò)等方式獲得更為廣泛的經(jīng)驗(yàn)和支持;
●應(yīng)對(duì)測(cè)試自動(dòng)化方案的可擴(kuò)展性提出要求，以滿足企業(yè)不斷發(fā)展的技術(shù)和業(yè)務(wù)需求。
折疊編輯本段過程
自動(dòng)化測(cè)試與軟件開發(fā)過程從本質(zhì)上來(lái)講是一樣的，無(wú)非是利用自動(dòng)化測(cè)試工具(相當(dāng)于軟件開發(fā)工具)，經(jīng)過對(duì)測(cè)試需求的分析(軟件過程中的需求分析)，設(shè)計(jì)出自動(dòng)化測(cè)試用例(軟件過程中的需求規(guī)格)，從而搭建自動(dòng)化測(cè)試的框架(軟件過程中的概要設(shè)計(jì))，設(shè)計(jì)與編寫自動(dòng)化腳本(詳細(xì)設(shè)計(jì)與編碼)，測(cè)試腳本的正確性，從而完成該套測(cè)試腳本(即主要功能為測(cè)試的應(yīng)用軟件)。
1) 自動(dòng)化測(cè)試需求分析。
當(dāng)測(cè)試項(xiàng)目滿足了自動(dòng)化的前提條件，并確定在該項(xiàng)目中需要使用自動(dòng)化測(cè)試時(shí)，我們便開始進(jìn)行自動(dòng)化測(cè)試需求分析。此過程需要確定自動(dòng)化測(cè)試的范圍以及相應(yīng)的測(cè)試用例、測(cè)試數(shù)據(jù)，并形成詳細(xì)的文檔，以便于自動(dòng)化測(cè)試框架的建立。
2)自動(dòng)化測(cè)試框架的搭建。
所謂自動(dòng)化測(cè)試框架便是像軟件架構(gòu)一般，定義了在使用該套腳本時(shí)需要調(diào)用哪些文件、結(jié)構(gòu)，調(diào)用的過程，以及文件結(jié)構(gòu)如何劃分。
而根據(jù)自動(dòng)化測(cè)試用例，我們很容易能夠定位出自動(dòng)化測(cè)試框架的典型要素:
a. 公用的對(duì)象。
不同的測(cè)試用例會(huì)有一些相同的對(duì)象被重復(fù)使用，比如窗口、按鈕、頁(yè)面等。這些公用的對(duì)象可被抽取出來(lái)，在編寫腳本時(shí)隨時(shí)調(diào)用。當(dāng)這些對(duì)象的屬性因?yàn)樾枨蟮淖兏淖儠r(shí)，只需要修改該對(duì)象屬性即可，而無(wú)需修改所有相關(guān)的測(cè)試腳本。
b. 公用的環(huán)境。
各測(cè)試用例也會(huì)用到相同的測(cè)試環(huán)境，將該測(cè)試環(huán)境獨(dú)立封裝，在各個(gè)測(cè)試用例中靈活調(diào)用，也能增強(qiáng)腳本的可維護(hù)性。
c. 公用的方法。
當(dāng)測(cè)試工具沒有需要的方法時(shí)，而該方法又會(huì)被經(jīng)常使用，我們便需要自己編寫該方法，以方便腳本的調(diào)用。
d. 測(cè)試數(shù)據(jù)。
也許一個(gè)測(cè)試用例需要執(zhí)行很多個(gè)測(cè)試數(shù)據(jù)，我們便可將測(cè)試數(shù)據(jù)放在一個(gè)獨(dú)立的文件中，由測(cè)試腳本執(zhí)行到該用例時(shí)讀取數(shù)據(jù)文件，從而達(dá)到數(shù)據(jù)覆蓋的目的。
在該框架中需要將這些典型要素考慮進(jìn)去，在測(cè)試用例中抽取出公用的元素放入已定義的文件，設(shè)定好調(diào)用的過程。
折疊編輯本段腳本編寫
該編寫過程便是具體的測(cè)試用例的腳本轉(zhuǎn)化。初學(xué)的自動(dòng)化測(cè)試人員均會(huì)使用錄制腳本到修改腳本的過程。但專業(yè)化的建議是以錄制為參考,以編寫腳本為主要行為，以避免錄制腳本帶來(lái)的冗余、公用元素的不可調(diào)用、腳本的調(diào)試復(fù)雜等問題。
折疊編輯本段測(cè)試運(yùn)行
事實(shí)上，當(dāng)每一個(gè)測(cè)試用例所形成的腳本通過測(cè)試后，并不意味著執(zhí)行多個(gè)甚至所有的測(cè)試用例就不會(huì)出錯(cuò)。輸入數(shù)據(jù)以及測(cè)試環(huán)境的改變，都會(huì)導(dǎo)致測(cè)試結(jié)果受到影響甚至失敗。而如果只是一個(gè)個(gè)執(zhí)行測(cè)試用例，也僅能被稱作是半自動(dòng)化測(cè)試，這會(huì)極大的影響自動(dòng)化測(cè)試的效率，甚至不能滿足夜間自動(dòng)執(zhí)行的特殊要求。
因此，腳本的測(cè)試與試運(yùn)行極為重要，它需要詳查多個(gè)腳本不能依計(jì)劃執(zhí)行的原因，并保證其得到修復(fù)。同時(shí)他也需要經(jīng)過多輪的腳本試運(yùn)行，以保證測(cè)試結(jié)果得一致性與精確性。
自動(dòng)化測(cè)試引入的原因是就把軟件測(cè)試人員從枯燥乏味的機(jī)械性手工測(cè)試勞動(dòng)中解放出來(lái)，以自動(dòng)化測(cè)試工具取而代之，使測(cè)試人員的精力真正花在提高軟件產(chǎn)品質(zhì)量本身。
折疊編輯本段注意事項(xiàng)
首先，一個(gè)企業(yè)實(shí)施測(cè)試自動(dòng)化，絕對(duì)不是拍腦袋說干就能干好的，它不僅涉及測(cè)試工作本身流程上、組織結(jié)構(gòu)上的調(diào)整與改進(jìn)，甚至也包括需求、設(shè)計(jì)、開發(fā)、維護(hù)及配置管理等其他方面的配合。如果對(duì)這些必要的因素沒有考慮周全的話，必然在實(shí)施過程中處處碰壁，既定的實(shí)施方案也無(wú)法開展。其次，盡管自動(dòng)化測(cè)試可以降低人工測(cè)試的工作量，但并不能完全取代手工測(cè)試。100%的自動(dòng)化測(cè)試只是一個(gè)理想目標(biāo)，根據(jù)筆者的經(jīng)驗(yàn)，即便一些如SAP、OracleERP等測(cè)試庫(kù)規(guī)劃十分完善的套件，其測(cè)試自動(dòng)化率也不會(huì)超過70%。所以一味追求測(cè)試自動(dòng)化只會(huì)給企業(yè)帶來(lái)運(yùn)作成本的急劇上升。再次，實(shí)施測(cè)試自動(dòng)化需要企業(yè)有相對(duì)規(guī)模的投入，對(duì)企業(yè)運(yùn)作來(lái)說，投入回報(bào)率將是決定是否實(shí)施軟件測(cè)試自動(dòng)化的最終指揮棒，筆者建議企業(yè)在決定實(shí)施軟件測(cè)試自動(dòng)化之前，必須要做量化的投資回報(bào)分析。此外，實(shí)施軟件測(cè)試自動(dòng)化并不意味著必須采購(gòu)強(qiáng)大的自動(dòng)化軟件測(cè)試工具或自動(dòng)化管理平臺(tái)，畢竟軟件質(zhì)量的保證不是依靠產(chǎn)品或技術(shù)，更多的因素在于高素質(zhì)的人員和合理有效的流程。
折疊編輯本段實(shí)戰(zhàn)模擬
折疊背景介紹
A公司是一家大型保險(xiǎn)公司，擁有近20個(gè)城市的分公司，并在其中5個(gè)城市建立了IT支持中心。平均每年的上線應(yīng)用數(shù)量在20個(gè)左右(新業(yè)務(wù)系統(tǒng)和原有業(yè)務(wù)系統(tǒng)的主要版本發(fā)布)。A公司的專職測(cè)試團(tuán)隊(duì)人數(shù)不足30人而且測(cè)試團(tuán)隊(duì)的測(cè)試人員技能參差不齊測(cè)試只是作為項(xiàng)目上線前的一道工序而已。在測(cè)試團(tuán)隊(duì)內(nèi)部也幾乎沒有自動(dòng)化的手段，主要依靠手工測(cè)試。由于已上線應(yīng)用系統(tǒng)的問題，開發(fā)團(tuán)隊(duì)必須分出一部分資源去維護(hù)和修復(fù)上線應(yīng)用，而同時(shí)測(cè)試團(tuán)隊(duì)的測(cè)試成果和效率卻無(wú)法和這些應(yīng)用質(zhì)量掛鉤，也更無(wú)從談起對(duì)軟件質(zhì)量的控制。所以，A公司決定在軟件質(zhì)量和測(cè)試方面進(jìn)行投入，他們考慮以下幾方面:
●引進(jìn)軟件測(cè)試流程管理的自動(dòng)化，提高軟件測(cè)試過程的管理水平，使軟件測(cè)試和軟件開發(fā)一樣可被評(píng)估、被衡量。
●實(shí)現(xiàn)性能測(cè)試自動(dòng)化，所有應(yīng)用上線之前必須有應(yīng)用性能風(fēng)險(xiǎn)評(píng)估報(bào)告和相關(guān)部門的確認(rèn)
●逐步實(shí)現(xiàn)功能測(cè)試的自動(dòng)化，在目前人員配置的情況下，把部分手工測(cè)試變成自動(dòng)化測(cè)試，提高測(cè)試可信度，降低人為錯(cuò)誤。
●通過軟件測(cè)試自動(dòng)化，管理軟件測(cè)試中的案例、缺陷、報(bào)告等資產(chǎn)，進(jìn)一步提升軟件測(cè)試的效率并建立測(cè)試基礎(chǔ)庫(kù)。
●在規(guī)劃中，將來(lái)的2~3年內(nèi)使所有的應(yīng)用系統(tǒng)上線都必須有數(shù)字化的測(cè)試數(shù)據(jù)作為依據(jù)。
折疊系統(tǒng)的情況
由于保險(xiǎn)公司的業(yè)務(wù)種類繁多，同時(shí)在經(jīng)過了幾十年的經(jīng)營(yíng)后，公司內(nèi)的應(yīng)用系統(tǒng)從早期的終端方式到現(xiàn)代的J2EE和.NET等應(yīng)有盡有，魚龍混雜。IT部門已經(jīng)建立的3年規(guī)劃，即在未來(lái)的3年時(shí)間內(nèi)將所有終端和C/S方式的應(yīng)用轉(zhuǎn)換成B/S架構(gòu)，但當(dāng)前仍然需要對(duì)這些舊應(yīng)用系統(tǒng)進(jìn)行維護(hù)，以保證業(yè)務(wù)的順利進(jìn)行。對(duì)于開發(fā)部門來(lái)說，新應(yīng)用開發(fā)基本上已經(jīng)以B/S架構(gòu)為主，主要是基于J2EE架構(gòu)的WebHTTP應(yīng)用和部分Window.NETForm的應(yīng)用。
折疊公司現(xiàn)狀
企業(yè)機(jī)構(gòu)在做測(cè)試自動(dòng)化選型時(shí)一定要考慮清楚企業(yè)內(nèi)部哪些部分可以實(shí)施自動(dòng)化、哪些部分暫不實(shí)施自動(dòng)化、哪些部分僅在某幾個(gè)項(xiàng)目做自動(dòng)化試點(diǎn)。切忌匆忙上馬或盲目否定，缺乏實(shí)事求是的理性思考。
測(cè)試部門僅負(fù)責(zé)系統(tǒng)測(cè)試和對(duì)用戶驗(yàn)證測(cè)試進(jìn)行管理，對(duì)于之前的單元測(cè)試和集成測(cè)試主要由開發(fā)團(tuán)隊(duì)中劃分出的一部分臨時(shí)測(cè)試人員完成。由于缺乏監(jiān)測(cè)手段，測(cè)試部門也無(wú)法收集和確定集成測(cè)試和單元測(cè)試的完成情況，在整個(gè)軟件測(cè)試過程中，業(yè)務(wù)需求是由開發(fā)部門通過進(jìn)行管理，但測(cè)試需求尚沒有提出要求，測(cè)試案例主要通過在公司公用的文件服務(wù)器中的目錄管理方式管理，對(duì)測(cè)試中缺陷流程等管理主要依靠郵件的流轉(zhuǎn)進(jìn)行處理90%以上的測(cè)試是通過Excel和Word等測(cè)試案例文檔來(lái)完成，測(cè)試人員對(duì)軟件測(cè)試自動(dòng)化的認(rèn)識(shí)僅停留在"記錄+回放"的認(rèn)識(shí)上。
折疊方案
方案A:A公司可以采用美科利(Mercury)公司產(chǎn)品為主的軟件測(cè)試自動(dòng)化方案。
●依照原先的郵件流轉(zhuǎn)過程配置缺陷管理流程，為每個(gè)保險(xiǎn)業(yè)務(wù)的開發(fā)小組和測(cè)試團(tuán)隊(duì)分配相應(yīng)的用戶許可證，取消原有郵件方式。
●部署，以便完成應(yīng)用程序相關(guān)功能測(cè)試。
●部署-Runner。從測(cè)試團(tuán)隊(duì)中分化出專職的性能測(cè)試自動(dòng)化工程師和小組，和業(yè)務(wù)部門協(xié)調(diào)，建立A公司應(yīng)用系統(tǒng)上線性能指標(biāo)，通過給出測(cè)試指標(biāo)。
●建議A公司成立專門的質(zhì)量控制部門，對(duì)中的數(shù)據(jù)定期進(jìn)行分析，建立相關(guān)質(zhì)量模型，以便于企業(yè)量化管理和過程改進(jìn)。
方案B:A公司也可以采用產(chǎn)品為主的軟件測(cè)試自動(dòng)化方案。
●采用來(lái)進(jìn)行整個(gè)測(cè)試流程的管理，為相關(guān)開發(fā)和測(cè)試小組成員分配相應(yīng)權(quán)限，改變以前通過郵件以及Word、Excel文檔管理測(cè)試的工作方式。
●部署，用它來(lái)完成功能相關(guān)的測(cè)試工作以及新版本發(fā)布時(shí)的冒煙測(cè)試。此外，也能較好地完成性能相關(guān)測(cè)試。統(tǒng)一的操作方式降低了工具的學(xué)習(xí)周期和培訓(xùn)帶來(lái)的大筆開銷。
●部署，使測(cè)試工作前移到開發(fā)階段。由于能較好地支持白盒測(cè)試，編程人員在編碼階段引入的錯(cuò)誤能盡早被檢測(cè)到，這大幅降低了后期測(cè)試的開銷。
●建議A公司成立專門的質(zhì)量控制部門，對(duì)中的數(shù)據(jù)定期進(jìn)行分析，建立相關(guān)質(zhì)量模型，以便于企業(yè)量化管理和過程改進(jìn)。
方案C:A公司也可以采用開源軟件為主的軟件測(cè)試自動(dòng)化方案。
●采用Bugzilla來(lái)進(jìn)行Bug跟蹤管理，采用進(jìn)行測(cè)試用例管理，采用CVS進(jìn)行測(cè)試資源的配置管理。
●采用MaxQ和WebInject對(duì)B/S結(jié)構(gòu)的應(yīng)用系統(tǒng)進(jìn)行功能測(cè)試。
●采用DBMonster、Open-STA、LoadSim進(jìn)行性能相關(guān)測(cè)試。
●可采用Xunit架構(gòu)的開源工具對(duì)不同語(yǔ)言的程序單元進(jìn)行單元測(cè)試。
●建議A公司成立專門的開源軟件維護(hù)小組，以解決可能會(huì)碰到的工具維護(hù)工作。
●建議A公司成立專門的質(zhì)量控制部門，對(duì)Bugzilla、、CVS中的數(shù)據(jù)定期進(jìn)行分析，建立相關(guān)質(zhì)量模型，以便于企業(yè)量化管理和過程改進(jìn)。
折疊方案評(píng)價(jià)
由于不同客戶在組織架構(gòu)、員工素質(zhì)以及流程管理水平等方面的不同，我們很難用一個(gè)實(shí)例、一兩句話來(lái)說明不同解決方案的適用性。在上面的例子中，筆者給出了3種可行的方案，具體選擇哪一個(gè)，需要仔細(xì)權(quán)衡。這里筆者給出一般性的意見，對(duì)于不想受制于某個(gè)測(cè)試自動(dòng)化廠家的企業(yè)，開源絕對(duì)是一個(gè)理想的選擇。此外，它不需要支付成本，工具的源代碼可以隨意修改，因而具有較好的靈活性。但開源工具的弊端也是明顯的:缺乏使用培訓(xùn)和技術(shù)支持，工具的用戶界面一般也較為粗糙。而對(duì)于那些比較看重培訓(xùn)和售后支持的企業(yè)，筆者建議選擇或Mercury或其他廠家的產(chǎn)品。這樣雖然需要支付一部分費(fèi)用，但省去了工具維護(hù)所需要的大量工作。至于具體選擇哪個(gè)廠家的產(chǎn)品為好，筆者尚無(wú)結(jié)論性意見。相信讀者朋友都有一些見仁見智的看法，不妨來(lái)信交流。
只要一個(gè)電話
我們免費(fèi)為您回電
