| | | 自動化測試開發全程實戰 | 該商品所屬分類:工業技術 -> 自動化技術 | 【市場價】 | 841-1219元 | 【優惠價】 | 526-762元 | 【介質】 | book | 【ISBN】 | 9787302490241 | 【折扣說明】 | 一次購物滿999元台幣免運費+贈品 一次購物滿2000元台幣95折+免運費+贈品 一次購物滿3000元台幣92折+免運費+贈品 一次購物滿4000元台幣88折+免運費+贈品
| 【本期贈品】 | ①優質無紡布環保袋,做工棒!②品牌簽字筆 ③品牌手帕紙巾
| |
版本 | 正版全新電子版PDF檔 | 您已选择: | 正版全新 | 溫馨提示:如果有多種選項,請先選擇再點擊加入購物車。*. 電子圖書價格是0.69折,例如了得網價格是100元,電子書pdf的價格則是69元。 *. 購買電子書不支持貨到付款,購買時選擇atm或者超商、PayPal付款。付款後1-24小時內通過郵件傳輸給您。 *. 如果收到的電子書不滿意,可以聯絡我們退款。謝謝。 | | | | 內容介紹 | |
-
出版社:清華大學
-
ISBN:9787302490241
-
作者:編者:蝸牛學院|總主編:鄧強
-
頁數:508
-
出版日期:2018-04-01
-
印刷日期:2018-04-01
-
包裝:平裝
-
開本:16開
-
版次:1
-
印次:1
-
字數:787千字
-
-
本書將對整個自動化測試技術進行全面而深入的細致講解,包括單元測試自動化,接口測試自動化,性能測試自動化的底層原理及代碼實現。以及結合當前流行的自動化測試框架如Selenium, Appium, JMeter等進行講解和實驗,幫助讀者深入理解原理的同時,也能快速利用這些開發框架和工具實現高效的測試開發工作,幫助讀者在企業中樹立起**的能力和專業素養。
-
本書作為“蝸牛學院”自動化測試開發的核心教材,全面而深入地講解了自動化測試開發的四大核心技術:接口測試、GUI測試、性能測試和測試框架設計。本書全程以項目和實驗為主線,將所有測試開發的核心技術以及底層實現原理進行了詳細的剖析,並結合Java代碼完整地實現了這些原理。由於本書以Java作為核心編程語言,所以也有專門的項目講解測試開發過程中常用的Java核心編程知識。同時,筆者也將從業多年來關於軟件測試的項目和實驗進行了總結,這也是本書的特色和價值所在。考慮到目前讀者對測試工具的學習需求,本書也對目前比較流行的幾款測試工具進行了講解。
本書面向的主要讀者群為軟件測試工程師、測試主管、測試架構師和對自動化測試開發有濃厚興趣的愛好者。本書也可以作為整個研發團隊提升測試技術和質量意識的參考書。希望通過本書的學習,能為讀者建立起一套完整的、有競爭力的自動化測試技術體繫化思維。
-
無
-
項目1自動化測試體繫及環境準備1 1.1預備知識2 1.1.1軟件工程與“沒有銀彈”2 1.1.2理解自動化測試6 1.1.3自動化測試實施過程9 1.1.4軟件測試專業術語14 1.2核心實驗18 1.2.1Eclipse開發環境的配置與使用18 1.2.2安裝XAMPP並配置數據庫及應用繫統24 項目2WoniuATM模擬繫統32 2.1預備知識33 2.1.1Java程序設計基礎——變量與類型33 2.1.2Java程序設計基礎——控制結構37 2.1.3Java程序設計基礎——數組44 2.2核心實驗: 實現WoniuATM的注冊與登錄50 2.3預備知識56 2.3.1Java面向對像——類與實例56 2.3.2Java面向對像——靜態與非靜態61 2.3.3Java面向對像——構造方法63 2.3.4Java面向對像——失血模型66 2.3.5Java面向對像——繼承與多態69 2.4核心實驗: 重構WoniuATM並完善其功能77 2.5預備知識86 2.5.1Java異常處理機制86 2.5.2Java數據持久化——文本文件91 2.5.3Java數據持久化——Excel文件95 2.5.4Java數據持久化——JDBC數據庫99 2.6核心實驗102 2.6.1利用文本文件重構WoniuATM102 2.6.2利用數據庫重構WoniuATM108 2.6.3利用正則表達式檢驗用戶輸入113項目3代碼級接口測試自動化118 3.1預備知識: 深入理解接口測試及白盒測試119 3.2核心實驗122 3.2.1實現被測程序ArrayCompare代碼122 3.2.2基於Java實現TDD測試驅動開發127 3.2.3基於Java實現代碼級接口測試132 3.2.4基於Java實現代碼級集成測試135 3.2.5基於JUnit實現代碼級接口測試137 3.2.6基於TestNG實現代碼級接口測試149 3.2.7基於EclEmma實現代碼覆蓋率統計157 3.2.8將被測程序導出為Jar包並完成測試161 項目4協議級接口測試自動化164 4.1預備知識165 4.1.1協議級接口測試的價值165 4.1.2網絡通信過程與TCP/IP協議167 4.2核心實驗173 4.2.1利用Wireshark完成協議監控與分析173 4.2.2利用Java實現TCP通信過程175 4.2.3利用Java對飛秋客戶端實施可靠性測試177 4.3預備知識: Web繫統通信協議HTTP179 4.4核心實驗189 4.4.1利用協議分析工具監控Agileone通信過程189 4.4.2利用Java發送GET請求獲取頁面源文件193 4.4.3利用Java發送POST請求實現登錄測試196 4.4.4使用Java對Agileone進行暴力破解200 4.4.5利用Java對需求提案模塊進行測試202 4.4.6利用HttpClient實現需求提案的測試212 4.4.7利用Java對Phpwind論壇進行“灌水”216 4.4.8利用Java完成對Phpwind論壇的隨機回帖223 4.4.9利用Java處理JSON格式的數據內容226 4.4.10利用Java實現文件的上傳下載232 4.4.11利用Java實現HTTPS協議通信240 4.4.12利用Java完成對Web Service協議接口測試247 4.5工具應用254 4.5.1利用SoupUI實現協議級接口測試254 4.5.2利用TesseractOCR實現驗證碼識別260 項目5界面級黑盒測試自動化265 5.1預備知識: 基於界面的自動化測試核心技術266 5.2核心實驗271 5.2.1對像識別原理——Java實現Monkey測試271 5.2.2對像識別原理——Java操作Windows窗體對像276 5.2.3對像識別原理——Java操作Java窗體對像283 5.2.4對像識別原理——JavaScript操作Web窗體對像294 5.2.5Selenium IDE——測試Agileone的公告管理297 5.2.6Selenium WebDriver——配置與使用306 5.2.7Selenium WebDriver——代碼結構優化310 5.2.8Selenium WebDriver——代碼深度優化316 5.2.9Selenium WebDriver——對像識別機制327 5.2.10Selenium WebDriver——鼠標與鍵盤操作338 5.2.11Selenium WebDriver——對話框與窗口341 5.2.12Selenium WebDriver——其他重要對像344 5.2.13Selenium WebDriver——兼容性測試347 5.3工具應用: 使用Appium測試Android應用程序348 項目6協議級性能測試自動化356 6.1預備知識357 6.1.1性能測試核心原理與技術體繫357 6.1.2性能測試工程體繫與場景設計361 6.1.3性能測試指標體繫與結果分析370 6.2核心實驗375 6.2.1基於Java的多線程技術應用375 6.2.2利用Java的Executor框架運行多線程387 6.2.3利用Java開發Phpwind性能測試腳本392 6.2.4利用Java+JSoup實現頁面資源的下載407 6.2.5利用Java設計拱形場景及思考時間412 6.2.6監控並分析Windows和Linux關鍵性能指標417 6.2.7基於Web前端的性能測試分析430 6.3工具應用437 6.3.1使用JMeter實現Agileone的接口測試437 6.3.2使用JMeter實現Phpwind的性能測試444 項目7CBT自動化測試框架設計451 7.1預備知識: 理解自動化測試框架設計與CBT452 7.2核心實驗454 7.2.1利用CBT的ATM模型實現基礎框架454 7.2.2利用DDT模型重構CBT框架463 7.2.3在CBT中定制測試報告組件467 7.2.4對CBT測試報告組件進行測試479 7.2.5在CBT中定制公共組件模塊485 7.2.6利用CBT完成與禪道管理繫統集成495 7.2.7讓CBT完成產品的持續集成500 參考文獻509
-
3
項目3代碼級接口測試自動化項目簡介
被測程序(ArrayCompare)實現如下功能。 輸入一個以逗號(或其他字符)分隔的字符串,程序將解析該字符串並得到一個數組。以同樣的方式輸入第二個字符串,並解析成數組。 對輸入的字符分隔的每一個值進行判斷,必須為數值類型,否則程序將不做任何處理。 如果輸入合法,將按如下順序進行判斷。 (1) 如果數組長度為零,將直接輸出信息“結果: 數組長度為零.”。 (2) 如果兩個數組長度不相等,將直接輸出信息“結果: 數組長度不一致.”。 (3) 如果兩個數組不經過任何排序,自然相等,輸出信息為“結果: 數組相同.”。 (4) 如果兩個數組經過排序後比較,是相等的,輸出信息為“結果: 數組排序後相同.”。 (5) 如果兩個數組經過排序後比較,不相等,輸出信息為“結果: 數組不同.”。 程序不需要設計專門的GUI界面,直接使用命令行即可。 ☆代碼路徑: \\\\bookworkspace\\\\CodeTest
項目展示
實驗結果如圖31所示。 圖31數組判斷
項目目標
(1) 理解路徑覆蓋和條件覆蓋對測**例設計的指導價值。(2) 熟練運用基於代碼級的接口測試自動化技術。 (3) 對代碼級自動化測試框架JUnit和TestNG有深入理解。 (4) 理解代碼覆蓋率對代碼級自動測試的價值。 (5) 深入理解並熟練運用代碼級自動化測試技術,突破自動化測試技術難題。 3.1預備知識: 深入理解接口測試及白盒測試〖*2〗實驗簡介隨著移動互聯網的觸角深入人們生活的每個角落,伴隨而來的便是企業不斷對其軟件繫統接口定義和研發,以便於進行數據傳輸和交換。由此導致目前企業急需大量專業接口測試工程師,因為接口測試天然具備自動化測試的可行性。所以本項目專門介紹接口測試的各種存在形式。 實驗目的
(1) 理解接口測試的含義與作用。 (2) 理解白盒測試與灰盒測試。 (3) 理解代碼級接口測試與協議級接口測試。 實驗流程〖*2〗1. 關於接口測試接口測試是一個比較寬泛的概念,近幾年在**受到很多企業和測試從業者的追捧。事實上,無論通過何種方式運行一段程序,人們都必須依賴於調用該程序的接口纔能實現。 比如,假設現在用戶通過登錄界面輸入用戶名和密碼,單擊“登錄”按鈕,*終該操作會被組裝為一個HTTP請求進而發送給後臺服務器端,後臺服務器則會直接調用實現登錄的接口,通過該接口運行登錄的實際代碼,如圖32所示。 圖32通過接口運行登錄的實際代碼
在這個過程中,單擊“登錄”按鈕動作發生在前端界面,如果通過該方法觀察其*終運行狀態,就稱之為界面級的黑盒測試。人們也可以利用各種協議發送工具甚至用代碼發送協議數據包給後臺服務器進而觀察其運行狀態,此時,就稱之為協議級的接口測試。當然,人們也可以從代碼層面直接調用該登錄接口,這樣就稱之為代碼級的接口測試。*後,人們還可以直接深入代碼實現層,對代碼的實現邏輯進行詳細測試,這樣就稱之為白盒測試或單元測試。 那麼問題來了,這整個過程**的區別僅在於人們調用該登錄代碼的方式不一樣,*終真正工作的都是同一段代碼。所以,任何一種調用的方式,都是在驅動程序運行而已。從本質上來說,人們所做的事情沒有任何區別,那麼為什麼還要基於界面測試登錄的功能呢?這裡**可以基於其接口進行測試達到同樣的目的,而且這樣的做法都是可以自動化的,也是可以重用的。這也是為什麼接口測試越來越受到重視的原因。 當然,也正是因為接口測試的“接口”,是一個不太容易下定義的概念,所以讀者千萬不能盲目地認為協議級的測試就是接口測試,或者代碼級的測試就是接口測試。 2. 關於白盒測試
本書在前面將自動化測試進行了歸類: 代碼級、協議級和界面級。本書所講的白盒測試,統指代碼級的測試。白盒測試是相對於黑盒測試而言的一種測試方法而已,是指人們可以基於繫統的代碼層邏輯實現**有針對性的測試,其參考文檔主要是繫統的詳細設計文檔,甚至可以**到算法層實現,也可以向上提升到代碼接口層。 白盒測試的核心就是利用程序測試程序(如某個函數或方法),所以白盒測試默認情況下自帶自動化測試屬性。從接口測試的定義來看,白盒測試自然也是通過調用其函數或方法的接口纔能完成測試的執行。所以,本書後續所介紹的白盒測試,均是指基於代碼級接口實現的測試,既關注接口規範,也關注代碼的邏輯實現。 白盒測試既然天然屬於自動化測試,那麼可以將白盒測試、灰盒測試和黑盒測試有效地結合起來,各自完成不同的測試。比如利用白盒測試完成對基本功能點的測試或部分性能測試;利用灰盒測試如協議級測試完成可靠性、安全性、性能等測試工作;利用黑盒測試完成用戶體驗、兼容性方面的測試。通常情況下,這樣的組合會讓人們的測試工作變得*加有效率。建議讀者不妨在工作當中嘗試這樣的組合。 3. 代碼級接口測試實施價值
代碼級測試在預防軟件產品的Bug方面是**有效的。如果將其發揮好,從組織和技術層面做好協調和規範,其價值不容小覷。簡單將其特點歸納為如下幾點。 (1) 容易上手。隻要對代碼有一定了解,都可以輕易完成針對代碼的專項測試。即使是一個沒有受過正統程序設計培訓的人,也可以比較容易地按照標準流程和模板完成測試腳本的開發和測試數據的準備。 (2) 容易實施。由於代碼級測試工作直接使用測試代碼調用被測代碼(通過其開放出來的接口進行調用),所以實施過程**容易。隻需要通過簡單的判斷就可以確定該項測試是通過還是失敗。 (3) 容易維護。通常情況下,在軟件研發的過程中,一旦代碼的接口確定,變動相對較少,所以維護該測試腳本的工作量相對較低,測試腳本也會比較穩定。 (4) 容易見效。一旦將代碼級測試工作實施起來,可以立即看到測試腳本所產生的效果。 (5) 容易定位。由於測試腳本直接調用被測代碼,所以一旦測試腳本無法運行通過,很容易定位該問題,同樣,修復該問題的成本也會*小。 (6) 增強質量意識。事實上,很多企業的代碼級測試工作會由測試團隊和程序員團隊共同負責,這將**有助於程序員團隊在編寫代碼時增強其代碼的質量意識,為全員質量意識打下堅實的基礎。 4. 代碼級接口測試實施難題
既然代碼級測試這麼有價值,為什麼現在很多企業還是做不好呢?當然,這當中是有技術的原因,但*重要的是人為的原因。筆者就這些年的經驗,總結一下為什麼很難將代碼級測試實施的原因。 (1) 程序員不習慣。程序員習慣了直接上手寫代碼,並沒有養成寫代碼之前或之後還要再寫測試代碼的習慣。 (2) 測試人員編碼能力差。很多測試工程師在編碼方面的能力的確不敢恭維,而且**存在著這樣一種現像就是寫不好代碼的人纔去做軟件測試。 (3) 程序接口不規範。代碼級測試能夠實施好,需要一個規範的設計文檔和接口說明,甚至清晰的算法實現。但是在很多研發團隊中,能把客戶的需求分析清晰、形成文檔已經不易,根本沒有時間設計接口規範。所以程序編寫的過程就是一個打補丁的過程,導致代碼級測試工作很難實施。 (4) 利用調試代替測試。程序員團隊都會將自己的代碼進行調試,為了能盡早發現程序中可能存在的Bug。這本身並沒有錯,錯的是誤認為這就是測試。事實上,調試是單次的、隨機的行為,不具備可重用性,比如程序員每一次調試輸入的數據可能都是隨機的,而且這個數據很有可能沒有很好地覆蓋代碼邏輯。而代碼級測試則是嚴謹的、可重復運行的。無論程序怎麼修改,隻要能順利通過代碼級測試,都是可以接受的,除非測試程序有Bug。 (5) 項目時間緊迫。這應該是每個團隊都會遇到的問題。由於時間緊迫,團隊沒有時間完整地測試;由於時間緊迫,團隊沒有時間寫測試腳本。但是這樣真的可以提高效率嗎?無數失敗或延期的項目經驗告訴人們,如果不具備規範和嚴謹的流程,以及全員質量意識,即使項目趕出來了,客戶也不一定認可。 (6) 隻關心用戶看得到的東西。有的團隊隻做黑盒測試,以為將用戶的操作過程模擬好就行,這樣用戶就不會發現問題了。但是,實際上,往往用戶什麼問題都可以發現,所以千萬不能抱有僥幸心理。 (7) 測試程序復雜度高。有時候程序員為了能調用一個被測代碼,需要準備大量的測試環境和測試數據,這是代碼級測試經常遇到的問題。事實上,這個問題需要辯證地來看待,針對測試環境**復雜的情況,無論白盒、黑盒,可能測試起來都會比較復雜。通常筆者會建議代碼級測試*多關注在代碼的算法層或邏輯實現層(即層次*低的代碼)。而協議級或界面級的測試,*多關注於控制層代碼。 事實上,筆者並不是在說代碼級測試多麼**,多麼有價值,但是一定不能無視它的存在。如果研發團隊能把代碼級測試的工作多做一些,繫統測試的工作就可以少做一些,而且根據缺陷放大模型,把問題扼殺在搖籃中,*能看到其價值。 思考練習
(1) 請理解單元測試與白盒測試、代碼級接口測試與灰盒測試在作用上的區別。 (2) 自學白盒測試中的路徑覆蓋、條件覆蓋等測**例設計方法。 3.2核心實驗〖*4/5〗3.2.1實現被測程序ArrayCompare代碼〖*2〗實驗簡介本實驗主要為讀者梳理本測試項目的目標程序ArrayCompare的功能結構以及具體的代碼實現。 實驗目的
(1) 掌握概要設計與接口設計的基本方法。 (2) 能夠熟練快速地定位和梳理代碼邏輯。 (3) 對代碼功能進行解讀,進而達到測試的目的。 實驗流程〖*2〗1. 代碼結構圖ArrayCompare代碼結構如圖33所示。 圖33ArrayCompare代碼結構圖
2. 代碼實現原則
本書將基於如下思路進行程序的整體架構和接口設計。 (1) 合理使用面向對像特性,保證可測試性和模塊的獨立性。 (2) 高重用,低耦合。 (3) 結構合理,方法之間的調用深度不超過5層。 (4) 命名規範合理,見名知意。 (5) 不使用多態性,不過度使用面向對像設計原則。 (6) 不使用太多內置API,盡量自主實現所有功能。
| | | | | |