第七章 軟件測試自動化

1、第七章 軟件測試自動化,[本章要點] 1.自動化測試應(yīng)考慮的各種因素； 2. 自動化測試和手工測試中涉及的問題以及二者的優(yōu)缺點； 3.應(yīng)用自動化測試工具的目的； 4.自動化測試工具的分類和選擇方法； 5.自動化測試過程實例及自動化測試經(jīng)驗。,[本章目標] 1.了解自動化測試應(yīng)考慮的各種因素以及如何衡量自動化測試成本。 2.掌握自動化測試和手工測試的優(yōu)缺點。 3.了解測試工具的分類、使用目的及其選擇，了解幾種常用

2、的測試工具。 4.了解自動化測試的過程。,7.1進行自動化測試的適當時機 通常，軟件測試的工作量很大（據(jù)統(tǒng)計，測試會占用到40%的開發(fā)時間；一些可靠性要求非常高的軟件，測試時間甚至占到開發(fā)時間的60%）。而測試中的許多操作是重復(fù)性的、非智力性的和非創(chuàng)造性的，并要求做準確細致的工作，計算機就最適合于代替人工去完成這樣的任務(wù)。 軟件自動化測試是相對手工測試而存在的，主要是通過所開發(fā)的軟件測試工具、腳本等來實現(xiàn)，具有良

3、好的可操作性、可重復(fù)性和高效率等特點。在進行自動化測試前，首先要建立一個對軟件測試自動化的認識觀。軟件測試工具能提高測試效率、覆蓋率和可靠性等，自動化測試雖然具有很多優(yōu)點，但它只是測試工作的一部分，是對手工測試的一種補充。自動化測試絕不能代替手工測試，它們各有各自的特點，其測試對象和測試范圍都不一樣：,7.1.1概述 當針對產(chǎn)品的一些特征來設(shè)計一系列測試時，對每一個測試都需要決定是否對其進行自動化測試。 在

4、決定是否要進行自動化測試之前，通常需要考慮如下幾個主要問題： 1．同手工測試相比，只運行一次的自動化測試要多付出多少代價？ 2．自動化測試的生命周期是有限的。那么，這類測試是否遲早要終止？什么事件將會導(dǎo)致測試中止？ 3．在整個生命周期內(nèi)，這次測試能捕獲到新bug的可能性會有多大？這些難以預(yù)計的收益能夠使自動化測試的成本得到補償嗎？,7.1.2自動化測試的成本 創(chuàng)建一次自動化的測試所花費的時間要比一次

5、手工測試所花費的時間多得多。測試成本因產(chǎn)品的架構(gòu)以及自動化測試的方式不同而異。介紹如下幾種(費用由高至低)： 通過圖形用戶界面來測試產(chǎn)品； 使用GUI捕捉/回放工具來跟蹤測試與產(chǎn)品之間的交互，同時建立腳本； 測試的是一個編譯器；測試成本還要考慮測試時間、Bug的多少等問題。,7.1.3自動化測試的生命周期 測試的生命周期如下圖7-1所示：,,,在決定是否進行自動化測試之前，必須首先估計一下，產(chǎn)品的代碼

6、變動在什么范圍內(nèi)，測試仍能存活。如果要求代碼不能有太多變動，要做的測試最好是非常善于捕獲bug的測試. 介于需要被測試的代碼和測試之間的代碼稱作中介代碼（intervening code）。 一、中介代碼的變動對測試周期的影響 中介代碼是使測試中止的一個主要原因。 例如，用戶界面以前要求輸入電話號碼，現(xiàn)在變?yōu)樘峁┮粋€可視的電話鍵盤，使用鼠標點擊數(shù)字來模擬使用真實的電話。雖然通過兩種界面向被測試的

7、代碼傳遞的都是相同的數(shù)據(jù)，但是因為沒有了提供輸入電話號碼的地方，自動化測試可能就會中止。,為了使測試免受中介代碼變化的影響，應(yīng)該從以下幾個方面考慮： 1、評估一下中介代碼的改變會不會影響測試。如果絕不會影響到測試，使用自動測試就能節(jié)省大量的時間。 2、如果中介代碼的變化會影響到測試，就必須考慮一下使用測試庫函數(shù)能夠使測試不受影響的可能性會有多大。 3、假如沒有測試函數(shù)庫——如果是在捕捉/回放的模式下使用GUI測試自動化

8、工具——不要指望測試會不受影響。,二、被測試代碼的改變對測試周期的影響 需要判斷一下被測試的代碼的穩(wěn)定性。 首先，需要重點考慮代碼的行為。 其次，考慮功能的增加會不會影響測試。 7.1.4自動化測試的價值 進行自動化測試要解決的問題就是：自動化測試的價值必須要超過所有因此而放棄的手工測試的價值。 考慮問題如下： 1.測試代碼的結(jié)構(gòu)要清晰。 2.測試通常是用來測試功能

9、代碼。支撐代碼對于測試者來說通常是不可見的。,3.但功能代碼的改變通常會改變代碼的行為。因此，極有可能會使測試中止，而不是報告bug。 4.測試的價值主要在于支撐代碼改變以后仍能捕獲bug的能力。 5.如果我們一點也不了解支撐代碼，無法知道測試是否能捕獲bug?如何估計測試是否有助于我們捕獲bug? 6.可以認為與被測試的代碼進行交互的其他代碼大多數(shù)是支撐代碼，支撐代碼的變化也會產(chǎn)生自動測試所能捕獲的bug。,一

10、、分析被測試代碼的結(jié)構(gòu)對測試的影響。 例子：被測試的是一段處理從銀行賬戶里提款的代碼。 （例子詳見教材） 把被測試的代碼分成兩部分： ①功能代碼（feature code），它直接實現(xiàn)被測試代碼所完成的功能。測試會專門對其進行調(diào)用。功能代碼（support code）可以完成用戶所進行的操作（通過使用用戶界面的關(guān)聯(lián)代碼）。 ②支撐代碼(support code)，它起到支持功能代碼 （support code）的作用

11、。測試代碼會對其進行調(diào)用，但并沒有針對這些代碼的特殊測試。,圖7-2 功能代碼和支撐代碼示意圖,在這里，支撐代碼位于水平線以下。功能代碼位于水平線以上，共有五種不同的功能，我們只針對其中的兩個功能進行測試。,二、被測試代碼的變化所帶來的影響。 主要考慮這樣一些問題： 1．就給定的結(jié)構(gòu)而言，代碼的變化將會產(chǎn)生什么樣的影響？ 2．什么樣的變化具有測試價值？ 假設(shè)一些功能代碼發(fā)生了變化，如圖7-3中灰色圖形所示：

12、 這種變化極有可能會導(dǎo)致調(diào)用功能代碼的測試中止。因此，如果希望使用自動化測試的方法在發(fā)生變化的功能代碼（feature code）中找到bug，就必須終止原有測試。如果測試的成本很高，這樣做是很不經(jīng)濟的。,為了使原有的測試行為仍然能夠保留，通常采用的做法是更改支撐代碼（support code）以便能夠支持其他功能代碼的變動。請看圖7-4：,圖7-3,圖7-4,三、支撐代碼的變化對測試的影響 主要從以下兩方面來考

13、慮這個問題： 代碼的變化有多少？這些變化會引入多少bug? 7.1.5例子 假設(shè)我正在測試一個產(chǎn)品，測試已經(jīng)完成一半。產(chǎn)品已經(jīng)實現(xiàn)了主要的功能，但是還需要增加一些輔助功能?，F(xiàn)在我要對這些主要的功能進行測試。 測試過程中，在同如下人員進行交流的過程中提出的問題如下：,程序員：這些輔助的功能是否有可能需要改變產(chǎn)品的支撐代碼？程序員有可能精心設(shè)計了支撐代碼，并且考慮堅持使用可視化的用戶界面來完善各種功

14、能。如果是這樣的話，那么自動化測試的價值就不大。 但是因為要急于完成測試，程序員也可能知道程序的支撐代碼的結(jié)構(gòu)不會一成不變的。由于大部分工作將會重復(fù)進行，所以可能會特別需要進行自動化測試?；蛘叱绦騿T也不知道支撐代碼是否要改變。 項目經(jīng)理：在新版本中，新增的功能是一個十分重要的部分嗎？如果是這樣的話，由于市場競爭激烈，圖形用戶界面有可能改變嗎？以前，用戶界面改動有多大？,為什么會希望今后的改動越少越好？這些變化是為了增加功

15、能，還是用來代替現(xiàn)有的功能？我們需要切實的估計一下變動的可能性，因為任何變化都可能會提高自動化測試的成本，縮短測試的生命周期。 了解并熟悉測試工具的人員：如何應(yīng)對產(chǎn)品的變化？什么樣的變化會使測試中止？對于新增加功能的測試，遇到這些情況的幾率會有多大？ 一次自動化測試所花費的成本相當于幾次手工測試，并且要特別重視測試價值的大小和生命周期的長短，這樣做可能不對。但這都是為了避免犯下災(zāi)難性的錯誤，如果自動化測試的成本很高而

16、生命周期很短，我們最好使用手工測試。但是這并不意味著不能使用自動化測試，而是要判斷與衡量。,在測試中，要不斷跟蹤bug報告并加以修改，保留所有和測試相關(guān)的文檔。從這些資料當中，我們常常能夠發(fā)現(xiàn)更為重要的信息。如： ?什么樣的因素與產(chǎn)生的bug無關(guān)？ ?哪里存在bug？ ?代碼行為的穩(wěn)定性如何？ 經(jīng)過一段時間，要進行自動化測試還是手工測試的想法就會逐漸成熟，可能會形成一個更大的測試套。,7.1.6另

17、外一些需要考慮的問題 1.手工測試有時候會發(fā)現(xiàn)一些自動化測試所不能發(fā)現(xiàn)的問題。 2.盡管人善于發(fā)現(xiàn)問題，但很容易疲勞。并且不能對結(jié)果做出精確的分析。 3.由于我們不能保證每次手工輸入的數(shù)據(jù)完全相同。因此，重復(fù)的手工測試多少會有些不同，那么就有可能捕獲支撐代碼中的bug。 4.要求對配置測試進行更多的自動化測試。 5.如果在進行第一次測試的時候就捕獲了bug。表明這部分程序代碼將來有可能發(fā)生變化，要進行更多的自

18、動化測試 。,6.如果自動化測試的技術(shù)支持足夠強大，開發(fā)人員很容易就能做回歸測試，自動化測試也要比手工測試快得多，但是并不是所有的公司都具有這樣的自動化測試技術(shù)支持水平。 7.使用手工測試的時候捕獲了bug, 但又不能再現(xiàn)bug時會使人很沮喪。 8.程序更改之后，測試人員應(yīng)該對其進行檢查。 9.因為進行自動化測試的創(chuàng)建要花費一些時間，因此把第一個bug提交給程序員所花費的時間要比手工測試花費的時間長。 10.把測試

19、設(shè)計得簡單有利于進行自動化測試，但不善于捕獲bug。 11.如果產(chǎn)品的行為改變了，自動化測試就有可能會報告一些不真實的bug。,12.如果自動化測試創(chuàng)建的十分好，能夠有序的運行，并且可以改變測試運行的順序。 13.我們可以在產(chǎn)品需要測試之前先設(shè)計測試。 14.也許自動化測試的價值直到下一個新版本發(fā)布之后才能體現(xiàn)出來。 7.2自動化測試和手工測試比較 自動化測試并不能完全取代手工測試，二者各有優(yōu)

20、缺點。 7.2.1自動化測試與手工測試的比較 表7-1顯示了手工測試與自動化測試的比較結(jié)果。,這個測試案例中包括1750個測試用例和700多個錯誤。,表7-1 自動化測試和手工測試比較,7.2.2短測試周期中手工測試面臨的挑戰(zhàn) 迭代式的開發(fā)過程已逐漸取代傳統(tǒng)的瀑布式開發(fā)，成為了目前最流行的軟件開發(fā)過程。在迭代開發(fā)中強調(diào)在較短的時間間隔中產(chǎn)生多個可執(zhí)行、可測試的軟件版本，這就意味著測試人員也必須為每次

21、迭代產(chǎn)生的軟件系統(tǒng)進行測試。 隨著軟件開發(fā)過程的進展，測試工作越來越繁重，如果使用手工測試的方法，將很難保證測試工作的進度和質(zhì)量。,7.2.3手工測試的問題 手工測試的方法是根本不可能符合軟件快速開發(fā)的要求的。大公司用自動化測試因為它適合自動化測試的特點和有較高的投資回報率。 1、針對產(chǎn)品型項目的測試 2、針對增量式開發(fā)、持續(xù)集成項目的測試 3、針對能夠自動編譯、自動發(fā)布的系統(tǒng)

22、的測試 4、回歸測試 5、需要多次重復(fù)、機械性動作的測試 6、需要頻繁運行的測試 7、將煩瑣的任務(wù)轉(zhuǎn)化為自動化測試,7.2.4自動化測試的問題 自動化測試并不能完全取代手工測試。例如：在下面幾種情況下就不適合使用自動化測試。 定制型項目（一次性的） 項目周期很短的項目 涉及業(yè)務(wù)規(guī)則復(fù)雜的對象 關(guān)于美觀、聲音、易用性的測試 很少運行的測試，如：一個月只運行一次的測試。

23、 測試的軟件不穩(wěn)定 涉及物理交互的測試,7.2.5自動化測試的優(yōu)點 1、對程序的新版本運行己有的測試，即回歸測試。2、可以運行更多更頻繁的測試。 3、可以進行一些手工測試難以完成或不可能完成的測試。 4、充分地利用資源。 5、測試具有一致性和可重復(fù)性。 6、測試具有復(fù)用性。 7、縮短軟件發(fā)布的時間。8、增強軟件的可靠性。,7.2.6自動化測試的缺點 1、自動化測試不能取代手工測試， 測試主要還是要靠

24、人工的。 2、新缺陷越多，自動化測試失敗的幾率就越大。 3、工具本身不具有想象力 4、技術(shù)問題、組織問題、腳本維護 5、測試工具與其他軟件的互操作性,7.3自動化測試工具的選擇和使用 7.3.1 應(yīng)用自動化測試工具的目的 一般而言，在測試過程中應(yīng)用自動化測試工具主要為了以下幾個目的： 1、 提高測試質(zhì)量； 2、 減少測試過程中重復(fù)的手工勞動，提高測試效率； 3、 實現(xiàn)測試自動

25、化，充分利用測試資源。 7.3.2自動化測試工具的概要介紹 根據(jù)軟件生命周期中的定義，可以把自動化測試工具分為白盒測試工具、黑盒測試工具和測試管理工具三大類。這些工具和軟件開發(fā)過程中相關(guān)活動的關(guān)系如圖7-6所示：,,圖7-6 測試工具與開發(fā)過程關(guān)系圖,一、白盒測試工具 白盒測試工具一般是針對代碼進行測試的工具，測試中發(fā)現(xiàn)的缺陷可以定位到代碼級，根據(jù)測試原理的不同，又可以分為靜態(tài)測試工具和動態(tài)測試工具。

26、 1、 靜態(tài)測試工具 所謂靜態(tài)測試就是不運行測試而直接對代碼進行分析的測試。 靜態(tài)測試工具的代表是PR公司的PRQA軟件。,2、 動態(tài)測試工具 動態(tài)測試主要采用“插樁”的方式，即向代碼生成的可執(zhí)行文件中插入一些監(jiān)測代碼，運行框架程序，統(tǒng)計程序運行時的數(shù)據(jù)，可以針對所有類的成員函數(shù)進行測試，也可以只針對類的公共接口函數(shù)進行測試。代表有Jtest，C++test等。 二、黑盒測試工具

27、 黑盒測試工具包括功能測試工具和性能測試工具。 主要代表是WinRunner。,三、測試管理工具 測試管理工具用于對測試進行管理。一般而言，測試管理工具主要對軟件缺陷、測試計劃、測試用例、測試實施進行管理。,7.3.3自動化測試工具的選擇 在考慮選用工具的時候，建議從以下幾個方面來權(quán)衡和選擇： 　1、 功能 　 除了基本的功能之外，以下的功能需求也可以作為選擇自動化測試工具

28、的參考： 1) 報表功能； 2) 自動化測試工具的集成能力； 3) 操作系統(tǒng)和開發(fā)工具的兼容性；,2、價格 3、對自動化測試工具進行評估。 4、引入自動化測試工具的目的是使測試自動化。,7.3.4自動化測試工具在測試過程中的應(yīng)用 很多引入測試軟件的公司并沒有能夠讓測試軟件發(fā)揮應(yīng)有的作用，其原因主要有三個方面： 1、沒有考慮公司的實際情況，盲目引入自動化測試工具 2、沒有形成一

29、個良好的使用自動化測試工具的環(huán)境 3、沒有進行有效的自動化測試工具的培訓,7.4性能測試實例 本節(jié)列舉了一個使用LoadRunner進行的性能測試實例。 7.4.1 LoadRunner 簡介 LoadRunner® 是一種預(yù)測系統(tǒng)行為和性能的負載測試工具。通過模擬成千上萬名用戶和實施實時性能監(jiān)測來確認和查找問題，LoadRunner能夠?qū)φ麄€企業(yè)架構(gòu)進行測試。通過使用LoadRunner，企業(yè)

30、能最大限度地縮短測試時間，優(yōu)化性能和加速應(yīng)用系統(tǒng)的發(fā)布周期。其主要功能如下：1、輕松創(chuàng)建虛擬用戶 2、創(chuàng)建真實的負載3、定位性能問題 4、分析結(jié)果精確定位問題所在,7.4.2案例分析 該案例仍然是針對電廠兩票管理系統(tǒng)的性能測試，電廠工作人員可以使用該管理系統(tǒng)開出工作票和操作票。假設(shè)開設(shè)100個賬號和密碼可供100個工作人員同時開出工作票或操作票。要求，每臺機器只能由一個用戶使用，每個用戶只能使用各自不同的

31、賬號登錄該管理系統(tǒng)，開票結(jié)束后，要求把工作票或操作票內(nèi)容存檔，若在規(guī)定的時間內(nèi)沒有存檔，則系統(tǒng)強制存檔。,但是，一般測試部門不可能有100臺機器同時進行測試的。所以，使用Loadrunner模擬IP地址，修改腳本來協(xié)助測試。但是，為了保證測試結(jié)果，建議使用所有可用的機器進行復(fù)測，因為有時候測試工具是不可以完全信賴的。 現(xiàn)場測試環(huán)境： 硬件：100臺PC機，一個Web服務(wù)器 操作系統(tǒng)：Windows 2000 Ser

32、ver 測試工具：Loadrunner 8.0 瀏覽器：IE5.0和IE6.0 測試人員：質(zhì)控小組4人，執(zhí)行現(xiàn)場測試 項目小組22人，提供現(xiàn)場環(huán)境 技術(shù)小組各1人，提供技術(shù)支持,測試要求： 100個用戶擁有獨立IP地址，不同的用戶及密碼登錄，開票操作完成后各自同時把工作票或操作票內(nèi)容存檔。測試內(nèi)容： 100個用戶以不同的用戶名和密碼登錄該管理系統(tǒng)

33、。開票完成后，把工作票或操作票內(nèi)容存檔。測試系統(tǒng)是否能正常開票以及正確存檔。 測試方案： 1、 完全50臺實際的PC機進行現(xiàn)場測試。 （1） 準備工作，并做計劃。第一輪測試執(zhí)行三遍，設(shè)定50個用戶開出的工作票或操作票內(nèi)容同時提交，第一遍全部使用IE5.0，第二遍25臺使用IE5.0，25臺使用IE6.0，第三遍全部使用IE6.0,（2） At 9：00 ，50個用戶同時登錄系統(tǒng)（3） At 9：05 ，50個用戶同時提交

34、（4） 分別記錄第一輪測試（三遍）的結(jié)果（5） 第二輪測試準備工作，設(shè)定30個用戶開出的工作票或操作票內(nèi)容同時提交，另外20個用戶延時5分鐘提交，全部使用IE5.0（6） At 9：15 ，50個用戶同時登錄系統(tǒng)（7） At 9：20 ，30個用戶同時提交（8） At 9：25 ，剩余20個用戶同時提交（9） 記錄第二輪測試結(jié)果（10） 第三輪測試準備工作，設(shè)定30個用戶開出的工作票或操作票內(nèi)容同時提交，另外20個用戶延時5

35、分鐘提交，全部使用IE6.0,（11） At 9：15 ，50個用戶同時登錄系統(tǒng) （12） At 9：20 ，30個用戶同時提交 （13） At 9：25 ，剩余20個用戶同時提交 （14） 記錄第三輪測試結(jié)果 （15） 第四輪測試準備工作，設(shè)定30個用戶開出的工作票或操作票內(nèi)容同時提交，另外20個用戶延時5分鐘提交，正常提交用戶使用IE5.0，延時提交用戶使用IE6.0 （16） At 9：15 ，50個用戶同時登

36、錄系統(tǒng) （17） At 9：20 ，30個用戶同時提交 （18） At 9：25 ，剩余20個用戶同時提交 （19） 記錄第四輪測試結(jié)果 （20） 第五輪測試準備工作，設(shè)定30個用戶開出的工作票或操作票內(nèi)容同時提交，另外20個用戶延時5分鐘提交，正常提交用戶使用IE6.0，延時提交用戶使用IE5.0 （21） At 9：15 ，50個用戶同時登錄系統(tǒng) （22） At 9：20 ，30個用戶同時提交,（23） At

37、 9：25 ，剩余20個用戶同時提交 （24） 記錄第五輪測試結(jié)果 （25） 第六輪測試準備工作，設(shè)定30個用戶開出的工作票或操作票內(nèi)容同時提交，另外20個用戶延時5分鐘提交，正常提交用戶其中20個使用IE5.0，10個使用IE6.0，延時提交用戶使用IE5.0 （26） At 9：15 ，50個用戶同時登錄系統(tǒng) （27） At 9：20 ，30個用戶同時提交 （28） At 9：25 ，剩余20個用戶同時提交

38、（29） 記錄第六輪測試結(jié)果 （30） 第七輪測試準備工作，設(shè)定25個用戶開出的工作票或操作票內(nèi)容同時提交，另外25個用戶分兩次分別延時5、15分鐘提交 （31） At 9：35 ，50個用戶同時登錄系統(tǒng),（32） At 9：40 ，25個用戶同時提交 （33） At 9：45 ，剩余的其中15個用戶同時提交 （34） At 9：55 ，其他10個用戶同時提交 （35） 記錄第七輪測試結(jié)果，參見第二輪測試－第六

39、輪測試過程分別對IE5.0和IE6.0的情況進行測試 （36） 第八輪測試準備工作，設(shè)定其中25個用戶開出的工作票或操作票內(nèi)容不提交，由系統(tǒng)強行提交 （37） At 10：10 ，50個用戶同時登錄系統(tǒng) （38） At 10：15 ，25個用戶同時提交 （39） 其余用戶的內(nèi)容由系統(tǒng)強行提交 （40） 記錄第八輪測試結(jié)果，參見第二輪測試－第六輪測試過程分別對IE5.0和IE6.0的情況進行測試 （41） 第

40、九輪測試準備工作，設(shè)定其中25個用戶開出的工作票或操作票內(nèi)容同時提交，15個用戶延時5分鐘提交，其余用戶由系統(tǒng)強行提交,（42） At 10：25 ，50個用戶同時登錄系統(tǒng) （43） At 10：30 ，25個用戶同時提交 （44） At 10：35 ，剩余的其中15個用戶同時提交 （45） 剩余10個用戶系統(tǒng)強制提交 （46） 記錄第九輪測試結(jié)果，參見第二輪測試－第六輪測試過程分別對IE5.0和IE6.0的情況進行測試

41、 2、模擬50個用戶進行測試。其中，18臺是PC機，另外32臺機器的IP地址是Loadrunner模擬出來的。 （1） 在18臺實際的PC機中抽取其中一臺虛擬32個IP地址，包括自身的IP地址，這臺機器上共33個IP地址，這33個IP地址只能全部使用IE5.0或者全部使用IE6.0 （2） 其余17臺實際的PC機分別由17個人操作，另外一臺機器由一位質(zhì)控小組人員操作,（3） 對于異常情況，延時提交和強制提交全部由實際的機

42、器來模擬 （4） 其余過程參見1 3、模擬50個用戶進行測試。其中，10臺是PC機，另外40臺機器的IP地址是用Loadrunner模擬出來的。 （1） 在10臺實際的PC機中抽取其中一臺虛擬40個IP地址，包括自身的IP地址，該機器上共41個IP地址，這41個IP地址只能全部使用IE5.0或者全部使用IE6.0 （2） 其余9臺實際的PC機分別由9個人操作，另外一臺機器由一位質(zhì)控小組人員操作 （3） 對于異常情況，延

43、時提交和強制提交全部由實際的機器來模擬 （4） 其余過程參見1 4、模擬75個用戶進行測試。其中，35臺是PC機，另外40臺機器的IP地址是用Loadrunner模擬出來的。,（1） 在35臺實際的PC機中抽取其中三臺分別虛擬13、13、14個IP地址，這40個IP地址只能全部使用IE5.0或者全部使用IE6.0 （2） 其余32臺實際的PC機分別由32個人操作，另外三臺機器由兩位質(zhì)控小組人員操作 （3） 對于異常情況，延

44、時提交和強制提交全部由實際的機器來模擬 （4） 其余過程參見1 5、模擬100臺用戶進行測試。其中，40臺是PC機，另外60臺機器的IP地址是用分別用四臺實際的PC機模擬出來的。記錄測試結(jié)果。 （1） 在40臺實際的PC機中抽取其中四臺分別虛擬15個IP地址，這64個IP地址只能全部使用IE5.0或者全部使用IE6.0 （2） 其余36臺實際的PC機分別由36個人操作，另外四臺機器由四位質(zhì)控小組人員操作,（3） 對于異常情

45、況，延時提交和強制提交全部由實際的機器來模擬 （4） 其余過程參見1 6、 對5中所述情況重復(fù)測試兩次。 7、 為了保證結(jié)果的正確性，完全100臺實際的PC機進行現(xiàn)場測試。過程參見1測試過程(參見教材275頁),LoadRunner內(nèi)含集成的實時監(jiān)測器，在負載測試過程的任何時候，都可以觀察到應(yīng)用系統(tǒng)的運行性能。 當測試運行結(jié)束后，LoadRunner 收集匯總所有的測試數(shù)據(jù)，提供高級分析和匯報數(shù)據(jù)，

46、這樣便能迅速查找到性能問題并追溯原由。,本章小結(jié) 1．由于進行自動化測試，我們要放棄一些手工測試，所以在衡量自動化測試的成本時要考慮到我們因此放棄多少手工測試，少捕獲了多少bug。 2．應(yīng)該針對特殊的目的來設(shè)計測試，然后針對一個或多個功能的重要方面進行測試。 3．要正確估量自動化測試腳本開發(fā)和維護工作量，將關(guān)鍵而有許多次執(zhí)行的測試用例自動化。 4．一般來說，手工測試可以取代任何類型、功能的自動測

47、試，但在多用戶并發(fā)等情況下，手工測試是很難實現(xiàn)的，這時自動測試就發(fā)揮作用了。另外，使用自動測試工具可以減少很多重復(fù)的手工勞動，精確復(fù)制缺陷，提高測試覆蓋率，從而提高產(chǎn)品質(zhì)量。,5．應(yīng)該根據(jù)企業(yè)的特點來選擇測試工具。首先，對商業(yè)化的測試工具進行評估；然后，在公司的實際項目中試用，通過這種方法來檢驗工具在特定的環(huán)境下是否具有供應(yīng)商所宣傳的特性，同時考察代理商的技術(shù)支持水準，這對將來工具的大規(guī)模應(yīng)用非常重要。 6．雖然測試工具的應(yīng)用

48、可以提高測試的質(zhì)量、測試的效率，但要成功實施自動化測試，測試工作就必須遵從系統(tǒng)的、結(jié)構(gòu)化的和循序漸進的觀念來進行。,習 題 1、自動化軟件測試應(yīng)該考慮哪些因素？ 2、簡述自動化測試和手工測試的優(yōu)缺點。 3、自動化測試工具大致可以分為幾類，并舉例說明幾種與之相應(yīng)的測試工具？ 4、簡述應(yīng)用自動化測試工具的目的？ 5、選擇測試工具時主要應(yīng)該從哪幾個方面進行考慮？ 6、使用LoadRunner對本校網(wǎng)站進行壓力測試，