軟件測試培訓文檔

B/S后臺開發(fā)軟件測試測試分類測試用例書寫議程測試中需要注意的問題軟件測試基本概念定義軟件測試就是利用測試工具按照測試方案和流程對產(chǎn)品進行功能和性能測試甚至根據(jù)需要編寫不同的測試工具，設計和維護測試系統(tǒng)對測試方案可能出現(xiàn)的問題進行分析和評估執(zhí)行測試用例后，需要跟蹤故障，以確保開發(fā)的產(chǎn)品適合需求。軟件測試的內容軟件測試主要工作內容是驗證(verification)和確認(validation)驗證(verification)是保證軟件正確地實現(xiàn)了一些特定功能的一系列活動，即保證軟件做了你所期望的事情。(Dotherightthing)

1.確定軟件生存周期中的一個給定階段的產(chǎn)品是否達到前階段確立的需求的過程2.程序正確性的形式證明，即采用形式理論證明程序符合設計規(guī)約規(guī)定的過程3.評市、審查、測試、檢查、審計等各類活動，或對某些項處理、服務或文件等是否和規(guī)定的需求相一致進行判斷和提出報告軟件測試的內容確認(validation)是一系列的活動和過程，目的是想證實在一個給定的外部環(huán)境中軟件的邏輯正確性。即保證軟件以正確的方式來做了這個事件(Doitright)

1.靜態(tài)確認，不在計算機上實際執(zhí)行程序，通過人工或程序分析來證明軟件的正確性；2.動態(tài)確認，通過執(zhí)行程序做分析，測試程序的動態(tài)行為，以證實軟件是否存在問題。軟件測試的對象不僅僅是程序測試，軟件測試應該包括整個軟件開發(fā)期間各個階段所產(chǎn)生的文檔如需求規(guī)格說明、概要設計文檔、詳細設計文檔，當然軟件測試的主要對象還是源程序。

測試分類測試用例書寫議程測試中需要注意的問題

軟件測試基本概念軟件內部結構和具體實現(xiàn)的角度劃分白盒測試黑盒測試灰盒測試白盒測試也稱結構測試或邏輯驅動測試按照程序內部的結構測試程序，通過測試來檢測產(chǎn)品內部動作是否按照設計規(guī)格說明書的規(guī)定正常進行，檢驗程序中的每條通路是否都能按預定要求正確工作白盒測試主要是想對程序模塊進行如下檢查：對程序模塊的所有獨立的執(zhí)行路徑至少測試一遍。對所有的邏輯判定，取“真”與取“假”的兩種情況都能至少測一遍。在循環(huán)的邊界和運行的界限內執(zhí)行循環(huán)體。測試內部數(shù)據(jù)結構的有效性黑盒測試也稱功能測試，它是通過測試來檢測每個功能是否都能正常使用。在測試中，把程序看作一個不能打開的黑盒子，在完全不考慮程序內部結構和內部特性的情況下，在程序接口進行測試，它只檢查程序功能是否按照需求規(guī)格說明書的規(guī)定正常使用，程序是否能適當?shù)亟邮蛰斎霐?shù)據(jù)而產(chǎn)生正確的輸出信息。黑盒測試著眼于程序外部結構，不考慮內部邏輯結構，主要針對軟件界面和軟件功能進行測試。黑盒測試主要是為了發(fā)現(xiàn)以下幾類錯誤：是否有不正確或遺漏的功能？在接口上，輸入是否能正確的接受？能否輸出正確的結果？是否有數(shù)據(jù)結構錯誤或外部信息（例如數(shù)據(jù)文件）訪問錯誤？性能上是否能夠滿足要求？是否有初始化或終止性錯誤？

灰盒測試是介于白盒測試與黑盒測試之間的，可以這樣理解，灰盒測試關注輸出對于輸入的正確性同時也關注內部表現(xiàn)，但這種關注不象白盒那樣詳細、完整，只是通過一些表征性的現(xiàn)象、事件、標志來判斷內部的運行狀態(tài)，有時候輸出是正確的，但內部其實已經(jīng)錯誤了，這種情況非常多，如果每次都通過白盒測試來操作，效率會很低，因此需要采取這樣的一種灰盒的方法。執(zhí)行程序的角度靜態(tài)測試靜態(tài)方法是指不運行被測程序本身，僅通過分析或檢查源程序的語法、結構、過程、接口等來檢查程序的正確性。靜態(tài)測試結果可用于進一步的查錯，并為測試用例選取提供指導。動態(tài)測試動態(tài)方法是指通過運行被測程序，檢查運行結果與預期結果的差異，并分析運行效率和健壯性等性能這種方法由三部分組成：構造測試實例、執(zhí)行程序、分析程序的輸出結果所謂軟件的動態(tài)測試，就是通過運行軟件來檢驗軟件的動態(tài)行為和運行結果的正確性。目前，動態(tài)測試也是公司的測試工作的主要方式。軟件開發(fā)的過程按階段劃分單元測試單元測試（模塊測試）是開發(fā)者編寫的一小段代碼，用于檢驗被測代碼的一個很小的、很明確的功能是否正確。通常而言，一個單元測試是用于判斷某個特定條件（或者場景）下某個特定函數(shù)的行為。單元測試是由程序員自己來完成，最終受益的也是程序員自己?？梢赃@么說，程序員有責任編寫功能代碼，同時也就有責任為自己的代碼編寫單元測試。執(zhí)行單元測試，就是為了證明這段代碼的行為和我們期望的一致。集成測試集成測試（也叫組裝測試，聯(lián)合測試）是單元測試的邏輯擴展。它的最簡單的形式是：兩個已經(jīng)測試過的單元組合成一個組件，并且測試它們之間的接口。從這一層意義上講，組件是指多個單元的集成聚合。在現(xiàn)實方案中，許多單元組合成組件，而這些組件又聚合成程序的更大部分。方法是測試片段的組合，并最終擴展進程，將您的模塊與其他組的模塊一起測試。最后，將構成進程的所有模塊一起測試。確認測試確認測試的目的是向未來的用戶表明系統(tǒng)能夠像預定要求那樣工作。確認測試又稱有效性測試。在模擬的環(huán)境下，運用黑盒測試的方法，驗證被測軟件是否滿足需求規(guī)格說明書列出的需求。任務是驗證軟件的功能和性能及其他特性是否與用戶的要求一致。對軟件的功能和性能要求在軟件需求規(guī)格說明書中已經(jīng)明確規(guī)定，它包含的信息就是軟件確認測試的基礎。系統(tǒng)測試系統(tǒng)測試的目的是對最終軟件系統(tǒng)進行全面的測試，確保最終軟件系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設計。系統(tǒng)測試是將經(jīng)過測試的子系統(tǒng)裝配成一個完整系統(tǒng)來測試。它是檢驗系統(tǒng)是否確實能提供系統(tǒng)方案說明書中指定功能的有效方法。（常見的聯(lián)調測試）驗收測試驗收測試是部署軟件之前的最后一個測試操作。驗收測試的目的是確保軟件準備就緒，并且可以讓最終用戶將其用于執(zhí)行軟件的既定功能和任務。驗收測試是向未來的用戶表明系統(tǒng)能夠像預定要求那樣工作。經(jīng)集成測試后，已經(jīng)按照設計把所有的模塊組裝成一個完整的軟件系統(tǒng)，接口錯誤也已經(jīng)基本排除了，接著就應該進一步驗證軟件的有效性，這就是驗收測試的任務，即軟件的功能和性能如同用戶所合理期待的那樣。測試分類

測試用例書寫議程測試中需要注意的問題

軟件測試基本概念用例設計等價類劃分邊界值分析法錯誤推測法因果圖方法正交表分析法場景分析方法等價類劃分等價類是指某個輸入域的子集合.在該子集合中,各個輸入數(shù)據(jù)對于揭露程序中的錯誤都是等效的.并合理地假定.測試某等價類的代表值就等于對這一類其它值的測試.因此,可以把全部輸入數(shù)據(jù)合理劃分為若干等價類,在每一個等價類中取一個數(shù)據(jù)作為測試的輸入條件,就可以用少量代表性的測試數(shù)據(jù).取得較好的測試結果.等價類劃分可有兩種不同的情況:有效等價類和無效等價類.邊界值分析法邊界值分析方法是對等價類劃分方法的補充。大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上,而不是發(fā)生在輸入輸出范圍的內部.因此針對各種邊界情況設計測試用例,可以查出更多的錯誤.使用邊界值分析方法設計測試用例,首先應確定邊界情況.通常輸入和輸出等價類的邊界,就是應著重測試的邊界情況.應當選取正好等于,剛剛大于或剛剛小于邊界的值作為測試數(shù)據(jù),而不是選取等價類中的典型值或任意值作為測試數(shù)據(jù).錯誤推測法基于經(jīng)驗和直覺推測程序中所有可能存在的各種錯誤,從而有針對性的設計測試用例的方法.錯誤推測方法的基本思想:列舉出程序中所有可能有的錯誤和容易發(fā)生錯誤的特殊情況,根據(jù)他們選擇測試用例.因果圖方法前面介紹的等價類劃分方法和邊界值分析方法,都是著重考慮輸入條件,但未考慮輸入條件之間的聯(lián)系,相互組合等.考慮輸入條件之間的相互組合,可能會產(chǎn)生一些新的情況.但要檢查輸入條件的組合不是一件容易的事情,即使把所有輸入條件劃分成等價類,他們之間的組合情況也相當多.

因此必須考慮采用一種適合于描述對于多種條件的組合,相應產(chǎn)生多個動作的形式來考慮設計測試用例.

這就需要利用因果圖（邏輯模型）.因果圖方法最終生成的就是判定表.它適合于檢查程序輸入條件的各種組合情況.正交表分析法有時候，可能因為大量的參數(shù)的組合而引起測試用例數(shù)量上的激增，同時，這些測試用例并沒有明顯的優(yōu)先級上的差距，而測試人員又無法完成這么多數(shù)量的測試，就可以通過正交表來進行縮減一些用例，從而達到盡量少的用例覆蓋盡量大的范圍的可能性。場景分析方法指根據(jù)用戶場景來模擬用戶的操作步驟，這個比較類似因果圖，但是可能執(zhí)行的深度和可行性更好。

測試分類測試用例書寫議程

測試中需要注意的問題

軟件測試基本概念測試需要注意的問題為什么要開展軟件測試工作？因為沒有經(jīng)過測試的軟件很難在發(fā)布之前知道該軟件的質量，就好比ISO質量認證一樣，測試同樣也需要質量的保證，這個時候就需要在團隊中開展軟件測試的工作。在測試的過程發(fā)現(xiàn)軟件中存在的問題，及時讓開發(fā)人員得知并修改問題，在即將發(fā)布時，從測試報告中得出軟件的質量情況。測試需要注意的問題測試計劃工作的目的是什么？測試計劃工作的內容都包括什么？其中哪些是最重要的？軟件測試計劃是指導測試過程的綱領性文件，包含了產(chǎn)品概述、測試策略、測試方法、測試區(qū)域、測試配置、測試周期、測試資源、測試交流、風險分析等內容。借助軟件測試計劃，參與測試的項目成員，尤其是測試管理人員，可以明確測試任務和測試方法，保持測試實施過程的順暢溝通，跟蹤和控制測試進度，應對測試過程中的各種變更。測試計劃和測試詳細規(guī)格、測試用例之間是戰(zhàn)略和戰(zhàn)術的關系，測試計劃主要從宏觀上規(guī)劃測試活動的范圍、方法和資源配置，而測試詳細規(guī)格、測試用例是完成測試任務的具體戰(zhàn)術。所以其中最重要的是測試測試策略和測試方法（最好是能先評審）測試需要注意的問題您認為做好測試計劃工作的關鍵是什么？1.明確測試的目標，增強測試計劃的實用性編寫軟件測試計劃得重要目的就是使測試過程能夠發(fā)現(xiàn)更多的軟件缺陷，因此軟件測試計劃的價值取決于它對幫助管理測試項目，并且找出軟件潛在的缺陷。因此，軟件測試計劃中的測試范圍必須高度覆蓋功能需求，測試方法必須切實可行，測試工具并且具有較高的實用性，便于使用，生成的測試結果直觀、準確2．堅持“5W”規(guī)則，明確內容與過程5W”規(guī)則指的是“What（做什么）”、“Why（為什么做）”、“When（何時做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”規(guī)則創(chuàng)建軟件測試計劃，可以幫助測試團隊理解測試的目的（Why），明確測試的范圍和內容（What），確定測試的開始和結束日期（When），指出測試的方法和工具（How），給出測試文檔和軟件的存放位置（Where）。測試需要注意的問題3．采用評審和更新機制，保證測試計劃滿足實際需求測試計劃寫作完成后，如果沒有經(jīng)過評審，直接發(fā)送給測試團隊，測試計劃內容的可能不準確或遺漏測試內容，或者軟件需求變更引起測試范圍的增減，而測試計劃的內容沒有及時更新，誤導測試執(zhí)行人員。4.分別創(chuàng)建測試計劃與測試詳細規(guī)格、測試用例應把詳細的測試技術指標包含到獨立創(chuàng)建的測試詳細規(guī)格文檔，把用于指導測試小組執(zhí)行測試過程的測試用例放到獨立創(chuàng)建的測試用例文檔或測試用例管理數(shù)據(jù)庫中。測試計劃和測試詳細規(guī)格、測試用例之間是戰(zhàn)略和戰(zhàn)術的關系，測試計劃主要從宏觀上規(guī)劃測試活動的范圍、方法和資源配置，而測試詳細規(guī)格、測試用例是完成測試任務的具體戰(zhàn)術。您認為做好測試用例設計工作的關鍵是什么？白盒測試用例設計的關鍵是以較少的用例覆蓋盡可能多的內部程序邏輯結果黑盒法用例設計的關鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可能做到完全測試，以最少的用例在合理的時間內發(fā)現(xiàn)最多的問題請盡可能的詳細描述您以往的性能測試工作的完整過程。性能測試類型包括負載測試，強度測試，容量測試等負載測試：負載測試是一種性能測試指數(shù)據(jù)在超負荷環(huán)境中運行，程序是否能夠承擔。強度測試：強度測試是一種性能測試，他在系統(tǒng)資源特別低的情況下軟件系統(tǒng)運行情況。容量測試：確定系統(tǒng)可處理同時在線的最大用戶數(shù)在網(wǎng)站流量逐漸加大的情況下，開始考慮做性能測試了，首先要寫好性能測試計劃，根據(jù)運營數(shù)據(jù)得出流量最大的頁面（如果是第一次的話，一般是首頁，下載頁，個人帳戶頁流量最大，而且以某種百分比）.軟件自動化測試技術

軟件自動化測試原理

代碼分析

GUI對象識別

DOM對象識別

捕獲和回放

腳本技術自動比較技術自動化測試的實現(xiàn)方法，對于靜態(tài)測試和動態(tài)測試有很大的不同：動態(tài)測試的自動化實現(xiàn)主要通過特定的程序來模擬軟件的操作過程或操作行為，然后對軟件所做出的反應或輸出結果進行檢查或驗證。靜態(tài)測試的自動化實現(xiàn)是按照代碼規(guī)范和軟件開發(fā)的最佳實踐建立各種代碼規(guī)則，然后依據(jù)這些規(guī)則對代碼進行自動掃描，發(fā)現(xiàn)和規(guī)則不匹配的各種問題。軟件測試自動化實現(xiàn)的原理和方法主要有：直接對代碼進行靜態(tài)和動態(tài)分析、測試過程的捕獲和回放、測試腳本技術、自動比較技術、虛擬用戶技術和測試管理技術等。軟件自動化測試的原理代碼分析類似于高級編譯系統(tǒng)，一般是針對不同的高級語言去構造分析工具，在工具中定義類、對象、函數(shù)、變量和常量等各個方面的規(guī)則。在分析時，通過對代碼進行掃描和解析，找出不符合編碼規(guī)范的地方，從而給出錯誤信息和警告信息。還可以根據(jù)某種質量模型評價代碼的質量，生成系統(tǒng)的調用關系圖，評估代碼的復雜度等。代碼分析Findbugs是一個靜態(tài)分析工具，它檢查類或JAR文件，將字節(jié)碼與一組缺陷模式（Java代碼規(guī)范）進行對比以發(fā)現(xiàn)各種可能存在的問題。通過靜態(tài)分析工具可以在不運行程序的情況下對軟件進行測試，更早地發(fā)現(xiàn)軟件中的缺陷。安裝Findbugs（Findbugs可以獨立運行，也可以作為Eclipse的插件）設置Java環(huán)境：安裝JDK；配置環(huán)境變量安裝Eclipse：下載Eclipse軟件包并解壓在Eclipse中安裝Findbugs插件URL：/eclipse用Findbugs做Java代碼的分析安裝成功后，在Eclipse的“窗口”-->“首選項”中，展開“Java”后發(fā)現(xiàn)Findbugs項，從中可以發(fā)現(xiàn)Findbugs定義了很多種檢查器(Detector)，而且分為不同的模式(pattern)和類型(category)：糾錯(correctness)、不合理的(dodgy)、不好的實踐(badpractice)、安全性(security)、性能(performance)和多線程糾錯(multithreadedcorrectness)等問題。使用Findbugs：創(chuàng)建或打開一個Java項目選擇該項目并單擊右鍵，從菜單中執(zhí)行“Findbugs”運行后的警告信息會顯示在右下區(qū)域的Problems視圖中雙擊某條警告信息會自動定位到編輯器中對應的源代碼行用Findbugs做Java代碼的分析（續(xù)）用Findbugs做Java代碼的分析（續(xù)）上述例子中沒有執(zhí)行代碼，而是通過對代碼的逐行掃描來分析代碼，找出問題。這種靜態(tài)測試是通過事先所建立的代碼規(guī)則、由軟件工具來自動執(zhí)行。代碼靜態(tài)分析的關鍵是建立各種規(guī)則，而這種規(guī)則的建立依賴于相應編程語言的語法。利用這些規(guī)則可以找出Java源程序的許多問題，如：沒有用到的變量、多余的變量創(chuàng)建操作、空的catch塊等。為了提高代碼分析的效率，會把Java源代碼解析成抽象語法樹(AbstractSyntaxTree,AST)，由Java符號流（對象）構成樹型層次結構（語義層）。對一個規(guī)則的檢驗，就是對相應的AST的一次遍歷。代碼分析的實現(xiàn)舉例說明：下面是為一個簡單的計算語句而設立的規(guī)則。計算：Times=n*a+1規(guī)則：Times(plus(Var(“a”),Var(“n”)),Int(“1”))它的操作過程可以抽象為如右圖所示的抽象語法樹：

代碼分析的實現(xiàn)（續(xù)）還可以自定義一些代碼規(guī)則來供靜態(tài)分析工具使用。例如，代碼復雜度和代碼重復率是代碼質量關心的主要問題之一。對于代碼復雜度可能是含有過多的條件語句（if,while或for語句等）造成的，可通過圈復雜度的度量來檢查。當圈復雜度為10或超過10時，一般就表明該方法過于復雜。所以，可設立如下的代碼規(guī)則：<modulename=“CyclomaticComplexity”><propertyname=“max”value=“10”/></module>代碼分析的實現(xiàn)（續(xù)）功能測試工具需要和用戶界面打交道，就要能操作、控制用戶界面上的各種對象，所以大部分功能測試工具是基于GUI對象識別技術來實現(xiàn)自動化測試的。安裝功能測試工具AutoITv3工具下載URL：英文版：/site/autoit/downloads/中文版：AutoIT安裝成功后，從“開始”-->“所有程序”-->“AutoITv3”菜單中，選擇執(zhí)行“AutoIT窗口信息工具(AutoITWindowInfo)”，就可以進行Windows對象識別的操作。GUI對象識別啟動“AutoIT窗口信息工具”后，鼠標在Windows不同窗口或對象上移動，AutoIT窗口信息工具會顯示鼠標所指向的對象信息。也可以移動查詢工具來指定某個窗口、菜單、快捷鍵、按鈕、輸入框、文字信息等各種對象，從而獲得如右圖所示的信息。在操作中，會發(fā)現(xiàn)它可以識別工具欄，但不能識別工具欄的某個具體對象（如主頁、打印機等圖標），而對瀏覽器內的對象更是無能為力。用AutoIT識別GUI對象基于GUI對象識別和控制的自動化測試工具，一般在腳本語言中采用WindowsAPI（ApplicationProgrammingInterface,應用程序編程接口）函數(shù)調用的方法來實現(xiàn)。WindowsAPI涵蓋了系統(tǒng)的管理、診斷、圖形和多媒體、網(wǎng)絡、安全性等各個方面，但在自動化測試工具中或對象識別中，主要使用WindowsUserInterface（用戶界面）一類的API。這類函數(shù)封裝了操作應用軟件所需的接口函數(shù)，包括鍵盤和鼠標操作的捕獲，以及窗口、按鈕、選擇項等的識別和操作。自動化測試工具可以基于這些API函數(shù)，來完成對象的識別和操作。如何實現(xiàn)Windows對象識別有些測試工具（如Selenium）直接訪問Web瀏覽器，利用腳本語言操縱瀏覽器和Web頁面，這時就需要對DOM（DocumentObjectModel,文檔對象模型）對象進行識別，從而模擬用戶控制瀏覽器中頁面元素的操作。也只有獲取DOM對象的屬性，才可以驗證頁面實際的表現(xiàn)，即確定實際結果和期望結果是否一致。DOM定義了HTML的標準對象集合，是HTML文檔的編程接口，與瀏覽器、平臺、語言無關。DOM也就是定義了標準的訪問和操縱HTML對象的方式，使得其他程序或軟件可以訪問頁面的標準組件。DOM以層次結構組織節(jié)點、內容等相關信息，從而將一個Web頁面轉換為一個基于樹或基于對象的多層次集合。DOM對象識別安裝IEWebDeveloper工具下載URL：/dominspector使用IEWebDeveloper可以在IE瀏覽器內查看頁面，獲取完整的DOM信息。打開IE瀏覽器，點擊“查看”-->“瀏覽器欄”-->“IEWebDeveloper”，啟動后就可以看到當前頁面的結構，并查看頁面的各個元素，如下圖所示。用IEWebDeveloper識別DOM對象安裝Firebug（工具下載URL：）最好的DOM識別工具是Firebug，它可以JavaScript文件方式支持在IE、Opera和Safari等瀏覽器中運行，但推薦作為Firefox的一個插件使用。Firebug功能強大，集HTML查看和編輯、JavaScript控制臺、CSS/script/DOM查看器、網(wǎng)絡狀況監(jiān)視器、測試于一體，可從各個不同的角度剖析Web頁面內部的細節(jié)層面。打開Firefox工具下的Firebug后，在瀏覽器載入任何頁面時，F(xiàn)irebug都可以生成DOM樹，點擊HTML標簽，鼠標只要停在某個對象上，瀏覽器頁面上相應的對象就會被明顯標識出來。點擊某個對象屬性的參數(shù)，F(xiàn)irebug還可以編輯HTML。如果點擊DOM標簽，可以更詳細的了解頁面的DOM結構及其元素。用Firebug識別DOM對象用Firebug識別DOM對象（續(xù)）代碼分析是一種白盒測試的自動化方法，捕獲和回放則是一種黑盒測試的自動化方法。捕獲是將用戶每一步操作都記錄下來。這種記錄的方式有兩種：程序用戶界面的像素坐標或程序顯示對象（窗口、按鈕、滾動條等）的位置，以及相對應的操作、狀態(tài)變化或是屬性變化。所有的記錄轉換為一種腳本語言所描述的過程，以模擬用戶的操作?；胤艜r，將腳本語言所描述的過程轉換為屏幕上的操作，然后將被測系統(tǒng)的輸出記錄下來同預先給定的標準結果比較。這可以大大減輕黑盒測試的工作量，在迭代開發(fā)的過程中，能夠很好地進行回歸測試。捕獲和回放關于自動化測試中的“錄制-回放”技術目前的自動化負載測試解決方案幾乎都是采用“錄制-回放”的技術。所謂的“錄制-回放”技術，就是先由手工完成一遍需要測試的流程，同時由計算機記錄下這個流程期間客戶端和服務器端之間的通信信息，這些信息通常是一些協(xié)議和數(shù)據(jù)，并形成特定的腳本程序(Script)。然后在系統(tǒng)的統(tǒng)一管理下同時生成多個虛擬用戶，并運行該腳本，監(jiān)控硬件和軟件平臺的性能，提供分析報告或相關資料。這樣，通過幾臺機器就可以模擬出成百上千的用戶對應用系統(tǒng)進行負載能力的測試。捕獲和回放（續(xù)）腳本是一組測試工具執(zhí)行的指令集合，也是計算機程序的一種形式。腳本可以通過錄制測試的操作產(chǎn)生，然后再做修改，這樣可以減少腳本編程的工作量；也可以直接用腳本語言編寫腳本。自動化測試腳本和程序代碼比較接近，包括指令和數(shù)據(jù)，還包括其他內容，如：同步，何時進行下一個輸入；比較信息，是測試驗證點所需要的，包括比較什么、如何比較及和誰比較；捕獲何種屏幕數(shù)據(jù)及存儲在何處；從何處讀取測試數(shù)據(jù)；控制信息等。腳本技術測試腳本可以分為以下幾類：線性腳本：是錄制手工執(zhí)行的測試用例得到的腳本。結構化腳本：類似于結構化程序設計，具有各種邏輯結構。共享腳本：是指某個腳本可被多個測試用例使用。數(shù)據(jù)驅動腳本：將測試輸入存儲在獨立的數(shù)據(jù)文件中。關鍵字驅動腳本：是數(shù)據(jù)驅動腳本的邏輯擴展。線性腳本是最簡單的腳本，如同流水賬那樣描述測試過程，一般由自動錄制得來；而結構化腳本是對線性腳本的加工，類似于結構化設計的程序，是腳本優(yōu)化的必然途徑之一。而數(shù)據(jù)驅動腳本和關鍵字驅動腳本可以進一步提高腳本編寫的效率，極大地降低腳本維護的工作量。目前大多數(shù)測試工具都支持數(shù)據(jù)驅動腳本和關鍵字驅動腳本。測試腳本的分類線性腳本是直接基于手工操作而錄制的腳本，這種腳本包含用戶所做的所有鍵盤和鼠標操作。如果僅使用線性腳本技術，所有錄制的測試用例可以通過腳本完整的回放。優(yōu)點：不需要深入的工作或計劃；可以加快開始自動化；對實際執(zhí)行操作可以審計跟蹤；測試用戶可以不必是編程人員；提供良好的（軟件或工具）演示。缺點：過程煩瑣，一切依賴于每次捕獲的內容；測試輸入和比較是“捆綁”在腳本中的；無共享或重用腳本；容易受軟件變化的影響；修改代價大，維護成本高；容易受意外事件的影響，引起整個測試失敗。適用情況：演示或培訓；執(zhí)行量較少、且環(huán)境變化小的測試；數(shù)據(jù)轉換。線性腳本線性腳本示例線性腳本結構不清晰，有很多重復腳本，很難維護，所以線性腳本不能真正應用于實際項目的自動化測試中，必須轉換為結構化的腳本，或者直接開發(fā)出結構化的腳本。結構化腳本類似于結構化的程序，含有控制腳本執(zhí)行的指令。這些指令或為控制結構，或為調用結構?？刂平Y構中包括“順序”、“循環(huán)”和“分支”，和結構化程序設計中的概念相同。調用結構是在一個腳本中調用另外的腳本，當子腳本執(zhí)行完成后再繼續(xù)運行父腳本。優(yōu)點：健壯性好，具有很好的可重用性、靈活性，腳本易于維護，可通過循環(huán)和調用減少工作量。缺點：腳本較復雜，而且測試用例（測試數(shù)據(jù)）“捆綁”在腳本中。結構化腳本結構化腳本示例共享腳本是指腳本可以被多個測試用例使用，一個腳本可以被其他的腳本所調用。使用共享腳本可以節(jié)省腳本的生成時間和減少重復工作量，當重復任務發(fā)生變化時，只需修改一個腳本或幾個共享的腳本。共享腳本可以是在不同主機、不同系統(tǒng)之間的共享腳本，也可以是在同一主機、同一系統(tǒng)之間的共享腳本。優(yōu)點：以較少的開銷實現(xiàn)類似的測試；維護開銷低于線性腳本；能刪除明顯的重復。缺點：需要跟蹤更多的腳本，給配置管理帶來一定的困難；對于每個測試，仍然需要特定的測試腳本，維護費用比較高；共享腳本通常是針對被測軟件的某部分，存在部分腳本不能直接運行。共享腳本數(shù)據(jù)驅動腳本將測試腳本（執(zhí)行步驟）和數(shù)據(jù)進行分離，將測試輸入數(shù)據(jù)存儲在獨立的數(shù)據(jù)文件中，而不是直接存儲在腳本中。在腳本中引入變量，執(zhí)行時通過變量來讀取數(shù)據(jù)文件中的數(shù)據(jù)，腳本本身描述測試的具體執(zhí)行過程。使用數(shù)據(jù)驅動腳本，同一個腳本可以針對不同的輸入數(shù)據(jù)來進行測試，提高了腳本的使用效率和可維護性。優(yōu)點：可以快速增加類似的測試；測試者增加新測試不必掌握工具腳本語言的技術；對第二個及以后類似的測試無額外的維護開銷。缺點：初始建立的開銷較大；需要專業(yè)（編程）支持；必須易于管理。數(shù)據(jù)驅動腳本數(shù)據(jù)驅動腳本示例關鍵字驅動腳本實際上是比較復雜的數(shù)據(jù)驅動技術的邏輯擴展。它將測試數(shù)據(jù)文件變成測試用例的描述，用一系列關鍵字指定要執(zhí)行的任務。關鍵字驅動腳本實際上封裝了各種基本的操作，每個操作由相應的函數(shù)實現(xiàn)，而在開發(fā)腳本時，不需要關心這些基礎函數(shù)，直接使用已定義好的關鍵字，腳本編寫的效率會大大提高，腳本也更易于維護。而且，關鍵字驅動腳本構成簡單，腳本開發(fā)按關鍵字來處理，可以看作是業(yè)務邏輯的文字描述，每一個測試人員都能開發(fā)腳本。關鍵字驅動腳本的數(shù)量不隨測試用例的數(shù)量變化，而僅隨軟件規(guī)模而增加。這種腳本還可以實現(xiàn)跨平臺的測試用例共享，只需更改支持腳本即可。關鍵字驅動腳本關鍵字驅動腳本示例沒有驗證點的自動化測試就不能被稱為測試，驗證某個測試用例的結果，實質上就是將實際結果（輸出）與期望結果進行比較。自動化測試時，預期輸出是事先定義的，要么插入腳本中或記錄在數(shù)據(jù)庫、數(shù)據(jù)文件中，然后在測試過程中運行腳本，將捕獲的結果和預期的輸出進行比較，從而確定測試用例是否通過。通過自動比較技術，驗證實際獲得的測試結果和事先定義的期望結果是否一致。如果不一致，將記錄所執(zhí)行的具體日志（log），報告錯誤。

自動比較技術自動比較可以是最簡單的數(shù)字比較，也可能是比較復雜的圖像比較。例如，自動比較有兩類模式——驗證（Verify）和斷言（Assert）。它們所具有的功能（命令）是非常相近的，只是對驗證結果的處理不同。當Assert失敗時，則退出當前測試；而當Verify失敗時，測試會繼續(xù)運行。

Web功能測試工具Selenium中Verify驗證失敗的界面

Web功能測試工具Selenium中自動比較的命令自動比較還可以對比分析屏幕或屏幕區(qū)域圖像、比較窗口或窗口上控件的數(shù)據(jù)或屬性、比較網(wǎng)頁、比較文件等。自動比較技術的實現(xiàn)圖片或自繪窗口特效的驗證是自動化測試中的難點。雖然有些自動化測試工具提供了驗證圖片的功能，但穩(wěn)定性都不是很好。一般圖片驗證的原理是首先截取并保存正確的圖片，然后將腳本運行時截取的圖片與保存的圖片進行比較。由于這種比較是在像素級上進行的。極微小的差異都會被認為是不同的，這可能導致同樣的腳本在不同物理機器（顯卡、OS等不同）上運行時，常常會因為顯示上的微小差異而導致檢查結果失敗，但用戶是可以接受的。有的測試工具可以設定閾值，允許存在微小的差異，高于閾值的被認為是“差異明顯存在”，認定驗證失??；低于或等于閾值的差異將被忽視，認定驗證通過。這樣，測試結果會比較穩(wěn)定、可靠。如果閾值可以根據(jù)實際情況或用戶的特定要求進行自動調整，則可以稱為“智能比較”。自動比較技術的實現(xiàn)（續(xù)）從自動比較的方式和技術看，自動比較可分為以下四類：靜態(tài)比較和動態(tài)比較——動態(tài)比較是在測試過程中進行比較；靜態(tài)比較是通過另外一個單獨的工具進行結果比較。簡單比較和復雜比較——簡單比較要求實際結果和期望結果完全匹配；復雜比較是一種智能比較，允許實際結果和期望結果有一定的差異。敏感性測試比較和健壯性測試比較——敏感性測試比較要求比較盡可能多的信息；健壯性測試比較只比較最少量、最需要的信息。比較過濾器——對實際輸出結果和期望輸出結果進行預先處理，執(zhí)行過濾任務之后再進行比較。自動比較技術的分類Junit介紹2/7/202367開源的Java測試框架主要特征：測試代碼與產(chǎn)品代碼分開提供了編寫測試類的框架通過與Ant結合，易于集成到程序的構建過程中，實施增量開發(fā)源代碼公開，易于二次開發(fā)可擴展性強下載地址/JUnit2/7/2023681997年ErichGamma和KentBeck為Java語言創(chuàng)建了一個簡單有效的單元測試框架ErichGamma《設計模式》作者之一KentBeck提出軟件開發(fā)方法“極限編程”《重構:改善既有代碼的設計》的作者Eclipse2/7/202369開源軟件基于Java的可擴展開發(fā)平臺僅提供框架，通過插件的方式構筑開發(fā)環(huán)境前身是IBM公司開發(fā)的VisualAgeforJava，2001年11月貢獻給開源社區(qū)，現(xiàn)在由非營利軟件供應商聯(lián)盟Eclipse基金會管理下載地址：Eclipse的版本變遷2/7/2023702003年，Eclipse3.0選擇OSGi服務平臺規(guī)范為運行時架構2007年6月，穩(wěn)定版3.3發(fā)布2008年6月發(fā)布代號為Ganymede的3.4版2009年7月發(fā)布代號為GALILEO的3.5版2010年6月發(fā)布代號為Helios的3.6版2011年6月發(fā)布代號為Indigo的3.7版2011年8月6日Eclipse基金會為支持JAVA7發(fā)布Eclipse3.8M12/7/2023南通大學計算機科學與技術學院71在Eclipse中使用JUnit2/7/202372建立一個被JUnit測試的類建立對應的JUnitTest類針對自動生成的代碼進行修改執(zhí)行測試用例建立一個被JUnit測試的類2/7/202373建立對應的JUnitTest類2/7/202374JUnit4新的特征針對自動生成的代碼進行修改2/7/202375測試用例執(zhí)行通過2/7/202376GreenBarKeepthebargreentokeepthecodeclean測試用例執(zhí)行失敗2/7/202377Assert方法（測試用例預期輸出）2/7/202378assertArrayEquals判斷兩個數(shù)組是否相等assertEquals判斷兩個對象是否相等assertFalse和assertTrue判斷布爾變量是否為False或TrueassertNotNull和assertNull判斷一個對象是否為空assertNotSame判斷兩個引用是否指向同一個對象Fail讓測試用例失敗Exception測試2/7/202379對@Test傳入expected參數(shù)值，即可測試異常暫時忽略這個測試用例測試用例集的構造2/7/202380使用方法創(chuàng)建一個空類作為測試用例集入口用@RunWith、@SuiteClasses注釋修飾這個空類；將Suite.class作為參數(shù)傳入@RunWith注釋，以提示JUnit將此類指定為運行器；將需要測試的類組成數(shù)組作為@SuiteClasses的參數(shù)。2/7/202381參數(shù)化測試2/7/202382為參數(shù)化測試類用@RunWith注釋指定特殊的運行器：Parameterized.class；在測試類中聲明幾個變量，分別用于存儲期望值和測試用的數(shù)據(jù)，并創(chuàng)建一個使用著幾個參數(shù)的構造函數(shù)；創(chuàng)建一個靜態(tài)（static）測試數(shù)據(jù)供給（feed）方法，其返回類型為Collection，并用@Parameter注釋以修飾；編寫測試方法（用@Test注釋）。

2/7/202383Ant2/7/202384基于Java的build工具類似于Unix中的make工具配置文件基于XML主要優(yōu)點跨平臺操作簡單易于集成到各種開發(fā)環(huán)境內典型的項目層次結構2/7/202385src目錄：存放文件。bin目錄：存放編譯后的文件。lib目錄：存放第三方JAR包。dist目錄：存放打包，發(fā)布以后的代碼。2/7/202386Antbuild.xml實例2/7/202387運行結果2/7/202388<project>標簽2/7/202389每個構建