探索式軟件測試

前言

“用戶購買功能的同時(shí)也在忍受缺陷?！?——史考特·沃茲沃思(Scott Wadsworth) 任何一個(gè)使用過電腦的人都知道軟件故障。從最初的第一個(gè)程序到最新的現(xiàn)代應(yīng)用程序，軟件從來沒有完美過。 將來這一切也多半不會(huì)改變。不只是軟件開發(fā)錯(cuò)綜復(fù)雜和開發(fā)人員容易犯錯(cuò)的天性，還有硬件、操作系統(tǒng)、運(yùn)行時(shí)環(huán)境、驅(qū)動(dòng)程序、平臺(tái)、數(shù)據(jù)庫等不斷變化，這些加在一起使軟件開發(fā)任務(wù)成為全人類最讓人稱奇的專業(yè)技能之一。 不過，僅僅令人稱奇是不夠的，正如本書第1章指出的那樣，這個(gè)世界還要求軟件擁有高質(zhì)量。 顯然，關(guān)心質(zhì)量不只是軟件測試人員的事。我們應(yīng)該用正確的方式構(gòu)建軟件，將可靠性、安全性和高性能等作為系統(tǒng)設(shè)計(jì)的一部分來考慮，而不是到開發(fā)末期才想起它們。然而，說到理解軟件缺陷的本質(zhì)，測試人員總是站在前沿。如果沒有測試人員在測試的最前沿發(fā)揮他們的洞察力、技術(shù)以及應(yīng)變措施，使這樣的可能性變?yōu)楝F(xiàn)實(shí)，軟件質(zhì)量的全面解決方案差不多算是“鏡中花，水中月”。 談?wù)撥浖|(zhì)量的方法有很多，感興趣的聽眾也有很多。本書是為軟件測試人員而寫的，寫的是一種我認(rèn)為比其他任何缺陷都重要的特殊缺陷：即逃過所有各種檢測手段而最終存在于發(fā)布產(chǎn)品中的缺陷。 任何一個(gè)軟件公司發(fā)布的產(chǎn)品都有缺陷。缺陷是怎么引入的？為什么沒有在代碼審核、單元測試、靜態(tài)分析或其他面向開發(fā)人員的活動(dòng)中把它們找出來？為什么自動(dòng)化測試沒有找出它們？那些缺陷有些什么特質(zhì)使其能逃過手工測試？ 什么是找出產(chǎn)品缺陷的最好方法？ 本書針對的正是最后一個(gè)問題。在第2章“手工測試”中，我提出了一個(gè)觀點(diǎn)：因?yàn)橛脩羰窃谑褂密浖^程中找到這些缺陷的，所以我們的測試人員也應(yīng)該通過使用軟件來找到它們。無論使用自動(dòng)化測試和單元測試，還是其他一些手段，都難以接觸到這些缺陷。無論測試人員怎么實(shí)現(xiàn)自動(dòng)化測試，即使全部都自動(dòng)化，這些缺陷還是會(huì)處處作怪，并在產(chǎn)品中屢屢重現(xiàn)從而傷害最終用戶。 問題在于很多現(xiàn)代化手工測試實(shí)踐都缺乏目的性，隨機(jī)性強(qiáng)且重復(fù)性強(qiáng)。有些人可能還會(huì)加上一條：手工測試無聊透頂。本書試圖為手工測試流程提供一些指導(dǎo)、技術(shù)和規(guī)劃。 在第3章“局部探索式測試法”中，針對測試人員在運(yùn)行任何一個(gè)測試用例時(shí)都需要做出很多細(xì)微的戰(zhàn)術(shù)層面決定，我給出了詳盡的指導(dǎo)建議。測試人員必須決定對于某個(gè)特定的輸入字段應(yīng)該使用什么輸入值，或者給應(yīng)用程序使用的文件提供什么數(shù)據(jù)。在測試過程中，必須做出許多這樣的小決定。在缺乏指導(dǎo)的情況下，這些決定常常是未經(jīng)分析且不是最優(yōu)化的。在向一個(gè)文本框內(nèi)輸入一個(gè)數(shù)時(shí)，選擇整數(shù)4難道就勝過整數(shù)400么？應(yīng)該用長度為32字節(jié)的字符串還是長度為256字節(jié)的字符串？選擇一個(gè)而不選另一個(gè)是有一定道理的，這一切都取決于處理該輸入的軟件的具體情況。鑒于測試人員每天都要做出數(shù)百次這樣的小決定，在這里提供有效的指導(dǎo)建議顯得至關(guān)重要。 在第4章“全局探索式測試法”中，針對測試人員在編制測試計(jì)劃和測試用例設(shè)計(jì)時(shí)需要考慮哪些廣泛的戰(zhàn)略性問題，我也給出了一些指導(dǎo)建議。這些技術(shù)都基于“漫游測試”(tour)概念，如同一個(gè)導(dǎo)游帶領(lǐng)旅游團(tuán)隊(duì)參觀大都市中一系列著名景點(diǎn)一樣，這種漫游測試法指出的路線可以指導(dǎo)測試人員如何探索軟件的方方面面。這里的探索并不一定是隨機(jī)的或者漫無目的的。本書所記錄的方法已經(jīng)成為微軟和谷歌的許多測試人員日常工作的一部分。諸如“地標(biāo)測試法”(landmark tour)和“極限測試法”(intellectual’s tour)等詞匯已經(jīng)列入了手工測試人員的標(biāo)準(zhǔn)詞匯表中。測試技術(shù)以前確實(shí)被稱作“漫游”，但是用整個(gè)旅游業(yè)來隱喻軟件測試，并在測試實(shí)際發(fā)布的應(yīng)用程序時(shí)，大規(guī)模使用這些隱喻的名稱，還屬于本書的一個(gè)創(chuàng)舉。 全局探索式測試法對于制定完整的測試策略給出了指導(dǎo)建議。例如，如何創(chuàng)建一組特性覆蓋率(feature coverage)較高的測試用例？如何確定是否要在一個(gè)單獨(dú)的測試用例中使用多個(gè)特性？如何創(chuàng)建一個(gè)完整的測試用例套件(test case suite)，從而使軟件盡可能地滿負(fù)荷工作以便能找到更多重要的缺陷？這些都是設(shè)計(jì)測試用例和保證測試套件質(zhì)量時(shí)必須解決的重大問題。 在第5章“混合探索測試技術(shù)”中，通過把探索式測試和傳統(tǒng)的腳本或基于場景的測試技術(shù)相結(jié)合，進(jìn)一步擴(kuò)展了漫游的概念。我們將討論如何修改各種端到端場景(end-to-end scenario)、測試腳本(test script)或用戶故事(user story)，來創(chuàng)造更多的變化情況，以激發(fā)傳統(tǒng)靜態(tài)測試技術(shù)查找缺陷的潛力。 在第6章“探索式測試的實(shí)際應(yīng)用”中，來自微軟不同產(chǎn)品組的五位客串作者提供了他們使用漫游技術(shù)后得到的經(jīng)驗(yàn)報(bào)告。這些作者和他們的團(tuán)隊(duì)在真實(shí)的開發(fā)環(huán)境中，把漫游方法應(yīng)用在真實(shí)的軟件上。他們記錄了各自是如何使用漫游、修改漫游甚至創(chuàng)建自己的漫游的。這些內(nèi)容來自于使用漫游法測試重要的關(guān)鍵軟件產(chǎn)品的測試人員，屬于真正的第一手資料。 最后，我用兩章內(nèi)容總結(jié)前面各章所討論的內(nèi)容。在第7章“漫游測試的棘手問題”中，描述了我認(rèn)為的測試中最困難的幾個(gè)問題，以及如何將那些具有高度針對性的探索式測試方法融入一個(gè)更廣泛的解決方案中。在第8章“軟件測試的未來”中，我更進(jìn)一步討論在未來幾年中，諸如虛擬化、可視化甚至電視游戲之類的技術(shù)將如何改變測試的面貌。附錄包括我對測試職業(yè)生涯的看法，收集了我以前一些深受讀者喜愛的文章(加入了一些新的注解)，其中一些文章已經(jīng)無法在其他地方看到了。 寫這本書對我來說是一種享受，我希望你閱讀本書也是一種享受。

內(nèi)容概要

　　談?wù)撥浖|(zhì)量的方法有很多，感興趣的聽眾也有很多。本書是為軟件測試人員而寫的，寫的是一種我認(rèn)為比其他任何缺陷都重要的特殊缺陷：即逃過所有各種檢測手段而最終存在于發(fā)布產(chǎn)品中的缺陷。　　任何一個(gè)軟件公司發(fā)布的產(chǎn)品都有缺陷。缺陷是怎么引入的？為什么沒有在代碼審核、單元測試、靜態(tài)分析或其他面向開發(fā)人員的活動(dòng)中把它們找出來？為什么自動(dòng)化測試沒有找出它們？那些缺陷有些什么特質(zhì)使其能逃過手工測試？　　什么是找出產(chǎn)品缺陷的最好方法？　　本書針對的正是最后一個(gè)問題。在第2章“手工測試”中，我提出了一個(gè)觀點(diǎn)：因?yàn)橛脩羰窃谑褂密浖^程中找到這些缺陷的，所以我們的測試人員也應(yīng)該通過使用軟件來找到它們。無論使用自動(dòng)化測試和單元測試，還是其他一些手段，都難以接觸到這些缺陷。無論測試人員怎么實(shí)現(xiàn)自動(dòng)化測試，即使全部都自動(dòng)化，這些缺陷還是會(huì)處處作怪，并在產(chǎn)品中屢屢重現(xiàn)從而傷害最終用戶?！　栴}在于很多現(xiàn)代化手工測試實(shí)踐都缺乏目的性，隨機(jī)性強(qiáng)且重復(fù)性強(qiáng)。有些人可能還會(huì)加上一條：手工測試無聊透頂。本書試圖為手工測試流程提供一些指導(dǎo)、技術(shù)和規(guī)劃?！　≡诘?章“局部探索式測試法”中，針對測試人員在運(yùn)行任何一個(gè)測試用例時(shí)都需要做出很多細(xì)微的戰(zhàn)術(shù)層面決定，我給出了詳盡的指導(dǎo)建議。測試人員必須決定對于某個(gè)特定的輸入字段應(yīng)該使用什么輸入值，或者給應(yīng)用程序使用的文件提供什么數(shù)據(jù)。在測試過程中，必須做出許多這樣的小決定。在缺乏指導(dǎo)的情況下，這些決定常常是未經(jīng)分析且不是最優(yōu)化的。在向一個(gè)文本框內(nèi)輸入一個(gè)數(shù)時(shí)，選擇整數(shù)4難道就勝過整數(shù)400么？應(yīng)該用長度為32字節(jié)的字符串還是長度為256字節(jié)的字符串？選擇一個(gè)而不選另一個(gè)是有一定道理的，這一切都取決于處理該輸入的軟件的具體情況。鑒于測試人員每天都要做出數(shù)百次這樣的小決定，在這里提供有效的指導(dǎo)建議顯得至關(guān)重要。　　在第4章“全局探索式測試法”中，針對測試人員在編制測試計(jì)劃和測試用例設(shè)計(jì)時(shí)需要考慮哪些廣泛的戰(zhàn)略性問題，我也給出了一些指導(dǎo)建議。這些技術(shù)都基于“漫游測試”（tour）概念，如同一個(gè)導(dǎo)游帶領(lǐng)旅游團(tuán)隊(duì)參觀大都市中一系列著名景點(diǎn)一樣，這種漫游測試法指出的路線可以指導(dǎo)測試人員如何探索軟件的方方面面。這里的探索并不一定是隨機(jī)的或者漫無目的的。本書所記錄的方法已經(jīng)成為微軟和谷歌的許多測試人員日常工作的一部分。諸如“地標(biāo)測試法”（landmark tour）和“極限測試法”（intellectual’s tour）等詞匯已經(jīng)列入了手工測試人員的標(biāo)準(zhǔn)詞匯表中。測試技術(shù)以前確實(shí)被稱作“漫游”，但是用整個(gè)旅游業(yè)來隱喻軟件測試，并在測試實(shí)際發(fā)布的應(yīng)用程序時(shí)，大規(guī)模使用這些隱喻的名稱，還屬于本書的一個(gè)創(chuàng)舉?！　∪痔剿魇綔y試法對于制定完整的測試策略給出了指導(dǎo)建議。例如，如何創(chuàng)建一組特性覆蓋率（feature coverage）較高的測試用例？如何確定是否要在一個(gè)單獨(dú)的測試用例中使用多個(gè)特性？如何創(chuàng)建一個(gè)完整的測試用例套件（test case suite），從而使軟件盡可能地滿負(fù)荷工作以便能找到更多重要的缺陷？這些都是設(shè)計(jì)測試用例和保證測試套件質(zhì)量時(shí)必須解決的重大問題?！　≡诘?章“混合探索測試技術(shù)”中，通過把探索式測試和傳統(tǒng)的腳本或基于場景的測試技術(shù)相結(jié)合，進(jìn)一步擴(kuò)展了漫游的概念。我們將討論如何修改各種端到端場景（end-to-end scenario）、測試腳本（test script）或用戶故事（user story），來創(chuàng)造更多的變化情況，以激發(fā)傳統(tǒng)靜態(tài)測試技術(shù)查找缺陷的潛力?！　≡诘?章“探索式測試的實(shí)際應(yīng)用”中，來自微軟不同產(chǎn)品組的五位客串作者提供了他們使用漫游技術(shù)后得到的經(jīng)驗(yàn)報(bào)告。這些作者和他們的團(tuán)隊(duì)在真實(shí)的開發(fā)環(huán)境中，把漫游方法應(yīng)用在真實(shí)的軟件上。他們記錄了各自是如何使用漫游、修改漫游甚至創(chuàng)建自己的漫游的。這些內(nèi)容來自于使用漫游法測試重要的關(guān)鍵軟件產(chǎn)品的測試人員，屬于真正的第一手資料?！　∽詈?，我用兩章內(nèi)容總結(jié)前面各章所討論的內(nèi)容。在第7章“漫游測試的棘手問題”中，描述了我認(rèn)為的測試中最困難的幾個(gè)問題，以及如何將那些具有高度針對性的探索式測試方法融入一個(gè)更廣泛的解決方案中。在第8章“軟件測試的未來”中，我更進(jìn)一步討論在未來幾年中，諸如虛擬化、可視化甚至電視游戲之類的技術(shù)將如何改變測試的面貌。附錄包括我對測試職業(yè)生涯的看法，收集了我以前一些深受讀者喜愛的文章（加入了一些新的注解），其中一些文章已經(jīng)無法在其他地方看到了?！　戇@本書對我來說是一種享受，我希望你閱讀本書也是一種享受。

作者簡介

James A.Whittaker，近日已加入谷歌擔(dān)任測試工程主管，他曾在微軟擔(dān)任Visual Studio Team SysterTl架構(gòu)師，負(fù)責(zé)為微軟測試業(yè)務(wù)主導(dǎo)產(chǎn)品策略，并領(lǐng)導(dǎo)內(nèi)部團(tuán)隊(duì)?wèi)?yīng)用探索式軟件測試。Whittaker博士曾在佛羅里達(dá)理工學(xué)院擔(dān)任計(jì)算機(jī)科學(xué)教授一職。在校期間，他被The Jourhal of Systems and Software授予“首席學(xué)者”稱號，并領(lǐng)導(dǎo)一個(gè)研究團(tuán)隊(duì)創(chuàng)建了許多領(lǐng)先的測試工具和技術(shù)，包括備受稱贊的運(yùn)行時(shí)錯(cuò)誤注入工具Holodeck。Wtlittaker博士還著有《如何攻破軟件》、《如何破壞軟件安全》和《如何破壞網(wǎng)絡(luò)軟件》。他發(fā)表過50+有關(guān)軟件開發(fā)和安全的同級評審論文。他持有安全測試和安全防御技術(shù)方面多項(xiàng)發(fā)明的專利。譯者簡介：方敏，現(xiàn)任微軟業(yè)洲工程院UIS項(xiàng)目首席測試部門主管，擁有20年軟件測試管理和開發(fā)的豐富經(jīng)驗(yàn)，曾參加過微軟多項(xiàng)重大產(chǎn)品和技術(shù)的研制，包括UIS，Windows Server／Client／Security，SQL Server，Exchange Server，MSN，COM+Services，Windows Medi和微軟內(nèi)部IT工具等。方敏曾在清華大學(xué)獲得電子工程學(xué)士和碩士學(xué)位，在美國新墨西哥技術(shù)學(xué)院獲得計(jì)算機(jī)碩士學(xué)位。張勝，現(xiàn)任微軟總部高級軟件開發(fā)測試主管，擁有10余年軟件開發(fā)測試和團(tuán)隊(duì)管理經(jīng)驗(yàn)，參與Visual Studio，SQL Server和Office Live的開發(fā)測試與發(fā)布，現(xiàn)主管Office Communications Server本地化軟件開發(fā)測試工作。張勝擁有復(fù)旦大學(xué)計(jì)算機(jī)系碩七和學(xué)上學(xué)位。

書籍目錄

第1章 軟件質(zhì)量 1 軟件的魔力 1 軟件失效 4 小結(jié) 9 練習(xí)題 9 第2章 手工測試 11 軟件缺陷的根源 11 缺陷預(yù)防和檢測 12 缺陷預(yù)防 12 缺陷檢測 13 手工測試 15 手工測試中使用腳本 16 探索式測試 16 小結(jié) 21 練習(xí)題 21 第3章 局部探索式測試法 23 想不想測試軟件？ 23 測試就是有所變，有所不變 25 用戶輸入 26 狀態(tài) 36 軟件狀態(tài)的基本知識(shí) 36 如何測試軟件狀態(tài) 37 代碼路徑 39 用戶數(shù)據(jù) 39 運(yùn)行環(huán)境 41 小結(jié) 41 練習(xí)題 42 第4章 全局探索式測試法 45 探索軟件 45 旅游者比喻 47 漫游測試 49 商業(yè)區(qū)測試類型 51 歷史區(qū)測試類型 58 娛樂區(qū)測試類型 60 旅游區(qū)測試類型 63 旅館區(qū)測試類型 66 破舊區(qū)測試類型 68 漫游測試法實(shí)戰(zhàn) 70 小結(jié) 72 練習(xí)題 72 第5章 混合探索式測試技術(shù) 73 場景和探索 73 使用基于場景的探索式測試 75 通過場景操作引入變化 76 插入步驟 76 刪除步驟 77 替換步驟 77 重復(fù)步驟 78 替換數(shù)據(jù) 78 替換環(huán)境 78 通過漫游測試引入變化 80 賣點(diǎn)測試法 80 地標(biāo)測試法 81 極限測試法 81 深巷測試法 81 強(qiáng)迫癥測試法 81 通宵測試法 81 破壞測試法 82 收藏家測試法 82 超模測試法 82 配角測試法 82 取消測試法 83 混票測試法 83 小結(jié) 83 練習(xí)題 83 第6章 實(shí)踐中的探索式測試 85 漫游測試 85 Dynamics AX客戶端的漫游 86 有用的探索漫游 87 收藏家測試法和收集缺陷 89 漫游測試提示 92 利用漫游查找隱錯(cuò) 94 測試用例管理解決方案的測試 94 取消測試法 95 破壞測試法 96 快遞測試法 97 測一送一測試法 98 在Windows Mobile設(shè)備中的 漫游實(shí)踐 98 我的測試方法和哲學(xué) 99 漫游測試法找到的有趣缺陷 101 破壞測試法實(shí)例 102 超模測試法實(shí)例 103 Windows媒體播放器的漫游測試 實(shí)踐 105 Windows 媒體播放器 105 遍歷測試法 106 超模測試法 108 極限測試法 109 與WMP相關(guān)的25個(gè)“假如” 類型的問題 109 極限測試法：邊界之旅 110 停車場測試法及其在 Visual Studio Team System測試版的應(yīng)用 112 Sprint中的測試 112 停車場測試法 114 漫游測試中的測試規(guī)劃與管理 115 定義地貌 115 旅行計(jì)劃 116 讓漫游測試運(yùn)轉(zhuǎn)起來 118 漫游結(jié)果的分析 118 判斷：里程碑和發(fā)布 119 在實(shí)踐中 119 小結(jié) 120 練習(xí)題 120 第7章 漫游與測試中的棘手問題 121 軟件測試的五個(gè)棘手問題 121 漫無目的 122 重復(fù)性 124 暫時(shí)性 126 單調(diào)性 127 健忘 128 小結(jié) 130 練習(xí)題 130 第8章 軟件測試的未來 131 歡迎來到未來世界 131 測試人員的專有提示顯示 132 測試百科 134 測試用例的重用 135 測試原子和測試分子 136 虛擬化的測試資產(chǎn) 137 可視化 138 未來的測試 141 發(fā)布之后的測試 142 小結(jié) 143 練習(xí)題 144 附錄1 經(jīng)營成功的測試職業(yè)生涯 145 你是如何開始做測試工作的？ 145 回到未來 146 上山 147 巔峰 149 下山 150 附錄2 JW的專業(yè)博客摘錄 151 教我一些東西吧 151 軟件誡律 151 測試錯(cuò)誤代碼 157 真正的職業(yè)測試人員，請上前一步 160 我找到的一些常見的共同特性 (無特別順序) 161 建議總結(jié) 162 三擊不中出局，是新的打擊手上場的 時(shí)候了 163 正式方法 164 工具 164 流程改進(jìn) 165 第四種提案 166 軟件測試是藝術(shù)、技巧或?qū)W科？ 166 恢復(fù)對軟件行業(yè)的尊重 169 事與愿違的過去 170 尋找更好的方法 171 分析安全漏洞和質(zhì)量問題的 流程 171 附錄3 JW微軟博客修訂版 175 加入博客圈 175 2008年7月 176 開篇 176 PEST(泡吧與軟件測試) 177 測試人員評估 179 預(yù)防與治療(一) 181 用戶與John 182 手工測試人員的贊歌 182 預(yù)防與治療(二) 185 歐洲，你好！ 186 測試賦 187 預(yù)防與測試(三) 189 回到測試 190 2008年8月 192 預(yù)防與治療(四) 192 如果微軟擅長測試，為什么軟件 依然糟糕呢？ 194 預(yù)防與治療(五) 197 自由式探索式測試 198 基于場景的探索式測試 198 基于策略的探索式測試 198 基于反饋的探索式測試 199 軟件測試的未來(一) 199 軟件測試的未來(二) 201 2008年9月 203 測試認(rèn)證 203 軟件測試的未來(三) 205 軟件測試的未來(四) 207 軟件測試的未來(五) 208 2008年10月 210 軟件測試的未來(六) 210 軟件測試的未來(七) 212 軟件測試的未來(八) 214 談到谷歌 216 再議手工測試與自動(dòng)化測試 216 2008年11月 218 不再需要測試人員？ 218 讓測試人員繼續(xù)測試 219 2008年12月 220 谷歌與微軟的開發(fā)∶測試 比例之爭 220 2009年1月 221 Zune的問題 221 解釋探索式測試 223 (未來的)測試用例重用 224 測試用例重用(續(xù)) 226 休假歸來 227 鼴鼠和受感染的花生 228

章節(jié)摘錄

插圖：已經(jīng)有很多文章闡述了漫無目的的生活會(huì)帶來哪些壞處，但盲目的測試和現(xiàn)代測試實(shí)踐中的無目標(biāo)性，導(dǎo)致了這樣一個(gè)問題。軟件測試不是簡單地拿起來就做的事情。它要求有計(jì)劃、有準(zhǔn)備、有策略和有多變的戰(zhàn)術(shù)，這是成功進(jìn)行軟件測試的前提。但是，太多的軟件企業(yè)因偏愛“想干就干”而忽略適當(dāng)?shù)臏?zhǔn)備。測試工作非常重要，所以決不能如此隨便地對待它。我在佛羅里達(dá)理工學(xué)院擔(dān)任教授的時(shí)候，我教過軟件測試課程。有一個(gè)學(xué)期，注冊這門課的學(xué)生多得超乎我的想象。我決定做一個(gè)試驗(yàn)，想把少數(shù)隨意選擇這門功課的學(xué)生嚇走。在開學(xué)的第一天，我在計(jì)算機(jī)房上課，我指導(dǎo)學(xué)生們確定要測試的應(yīng)用程序，兩人為一個(gè)測試小組。我沒有給學(xué)生們完成這個(gè)測試任務(wù)提供進(jìn)一步的指導(dǎo)。作為鼓勵(lì)，我答應(yīng)他們，如果我對他們采用的技術(shù)留下深刻的印象，他們就會(huì)被留在我的班上。如果他們不能滿足要求，我就認(rèn)為他們自動(dòng)放棄（我不是有意要趕他們走，但是這種要求達(dá)到了我想要的效果）。我在實(shí)驗(yàn)室里走來走去，無形中對學(xué)生們產(chǎn)生了壓力，有時(shí)我會(huì)與一組學(xué)生攀談，要求他們解釋如何找到軟件錯(cuò)誤。每當(dāng)我提出這樣的問題，就會(huì)得到類似的答案，如“不太清楚，我們只希望它會(huì)出錯(cuò)?！弊詈?，一些聰明的學(xué)生意識(shí)到這種回答并不奏效，他們在隨后的回答中漸漸地開始包含一些策略。事實(shí)上，我清楚地記得有兩個(gè)學(xué)生說“我們將要對所有的文本輸入框輸入較長的字符串，希望能夠找到一些不檢查字符串長度的地方。”①我當(dāng)即接受他們成為我的第一組學(xué)生，并鼓勵(lì)他們繼續(xù)做下去。太好了！雖然這不是最好的或者最重要的策略，但它至少是一種策略，有助于減少測試的無目標(biāo)性。軟件測試人員運(yùn)行測試程序時(shí)，經(jīng)常缺乏策略或沒有指定明確的目標(biāo)。在他們進(jìn)行手工測試時(shí)，他們漫無目的地測試應(yīng)用程序。在他們實(shí)現(xiàn)測試自動(dòng)化時(shí)，僅僅由于他們熟悉怎樣編寫測試自動(dòng)化，就去這么做了，而不考慮這樣的自動(dòng)化是否能發(fā)現(xiàn)有價(jià)值的缺陷，是否經(jīng)得起時(shí)間的考驗(yàn)，是否值得付出維護(hù)費(fèi)用。

后記

人非圣賢，孰能無過。一語道破人類容易犯錯(cuò)的天性，也為人們提供了堂而皇之逃避責(zé)任的借口。但隨著科學(xué)技術(shù)的發(fā)展，軟件在金融、醫(yī)學(xué)、航天、汽車等行業(yè)全方位的滲透，導(dǎo)致我們越來越難借助于這樣的托詞，原諒自己的失誤，因?yàn)橐粋€(gè)微不足道的疏忽或者失誤，放過軟件中存在的漏洞、缺陷和隱錯(cuò)，就會(huì)導(dǎo)致無可挽回的損失甚至災(zāi)難性的后果。上世紀(jì)末在美國，因?yàn)閮商总浖捎玫亩攘繂挝徊灰恢拢ㄒ粋€(gè)公制單位N／s，一個(gè)英制單位b／s，后者是前者的4倍），導(dǎo)致美國國家航空航天局（NASA）幾億美元的損失，使火星氣候軌道飛行器在最后的關(guān)鍵時(shí)刻墜入火星，而不是順利進(jìn)入軌道按照既定設(shè)計(jì)繞火星運(yùn)行。此類事例在計(jì)算機(jī)一統(tǒng)天下的今天并不罕見，同時(shí)也為我們敲響了警鐘，軟件測試到了不得不高度重視的程度。反觀軟件測試行業(yè)，可用的測試方法與10年前卻沒有多大差別。要想提高軟件質(zhì)量，測試先行，測試創(chuàng)新，已經(jīng)到了刻不容緩的地步。探索式測試（Explory tory Testing，也稱探索性測試）是一種軟件測試方法，最先是CemKaner在1983年提出的。這是一種強(qiáng)調(diào)個(gè)人自由與責(zé)任的測試方法，讓獨(dú)立測試人員可以借由不斷的學(xué)習(xí)來改善測試的規(guī)劃與測試的執(zhí)行，而在測試的過程中也會(huì)同時(shí)改善測試案例達(dá)到相輔相成的效果。在Nortel和微軟的很多項(xiàng)目中，都采用了這一新穎、有趣和富有創(chuàng)意的測試方法。

媒體關(guān)注與評論

“好書！Whittaker講述的概念有創(chuàng)意、巧妙、令人印象深刻。他真正懂得如何鼓勵(lì)工程師們以不同的角度考慮軟件測試。” 　　——谷歌公司測試工程總監(jiān)Patrick Copeland “James把美妙的手工測試方法學(xué)提升到了極致。漫游不僅概念正確，而且實(shí)際應(yīng)用得很好，我們已經(jīng)在所有測試人員的內(nèi)部培訓(xùn)課程中分享了漫游的概念。如果你想把手工測試過程帶到21世紀(jì)，請閱讀這本書吧?！?　　——微軟公司卓越測試總監(jiān)Alan Page “1990年，我開始與James在IBM一起共事。他早在當(dāng)時(shí)就鼓勵(lì)測試人員和開發(fā)人員大膽創(chuàng)新。通過這本書，他把對軟件質(zhì)量的熱情提升到了全新的高度。請閱讀這本書吧，見證你自己成為一個(gè)更好的測試工程師。James是這方面的權(quán)威，這個(gè)星球上的軟件測試工程師和開發(fā)工程師，無論他們是真正關(guān)心軟件質(zhì)量，或者只是想在自己的日常工作中增加更多的樂趣，都應(yīng)該閱讀這本書?！?　　——Cisco Systems公司高級工程主管Kaushal K. Agrawal “James Whittaker 是測試領(lǐng)域中一位真正有遠(yuǎn)見的人士。Utest和我們的QA專業(yè)全球社區(qū)經(jīng)常向James咨詢以獲得他的靈感、他對測試未來趨勢的解讀和他的各種測試?yán)砟睢，F(xiàn)在，他終于為大家寫出了這本書，我們這個(gè)行業(yè)會(huì)由于這本書而變得更有智慧?！?　　——uTest公司CEO和合伙人Doron Reuveni “只有像James Whittaker這樣的人才會(huì)把旅游和軟件測試以小說的形式結(jié)合起來，也只有James才能把它做到這么天衣無縫。漫游方法不僅提供了令人難忘的有效思考模式，還把適當(dāng)?shù)慕Y(jié)構(gòu)和組織與廣泛的探索和創(chuàng)造結(jié)合在一起。bug們，小心啦！” 　　——谷歌公司Alberto Savoia “James是軟件測試主題最出色的演講者之一，讀他的書就像聆聽他的演講。如果你希望增加測試知識(shí)并成為一個(gè)更優(yōu)秀的測試人員，這本書就是為你而寫的?！?　　——TCL集團(tuán)公司主席和合伙人Stewart Noakes “我從事探索性測試已經(jīng)有段時(shí)間了，James的漫游測試法給我所使用的各種方法起了名字，定義了測試重點(diǎn)，更重要的是給了我實(shí)際的指導(dǎo)。這本書將會(huì)使探索式測試的教學(xué)和應(yīng)用變得更方便?！?　　——iMeta Technologies公司高級測試顧問Rob Lambert “我為這項(xiàng)工作感到非常激動(dòng)，它概念新潮卻又合情合理。連我這樣的普通讀者都能輕松地理解和使用，而不用首先去學(xué)習(xí)一些華而不實(shí)的過時(shí)理論。在閱讀本書時(shí)，我也從不需要借助字典。測試領(lǐng)域長久以來就一直期盼著這樣的創(chuàng)新之作，我由衷地認(rèn)為本書在這方面走在行業(yè)最前沿。” 　　——Netjets公司QA部門經(jīng)理Linda Wilkinson

編輯推薦

如何發(fā)現(xiàn)和修復(fù)被常規(guī)軟件測試忽略的關(guān)鍵軟件缺陷？在《探索式軟件測試》中，享譽(yù)業(yè)界的軟件測試專家Ja rrlesWhittaker揭示了當(dāng)下最嚴(yán)重、隱藏最深的軟件錯(cuò)誤的真正誘因，并介紹了如何利用功能強(qiáng)大的探索式測試技術(shù)來找到并糾正這些錯(cuò)誤。先后就職于谷歌、微軟和其他頂尖軟件公司的james Whittaker，在軟件測試的前沿陣地?fù)碛薪?0年的豐富經(jīng)驗(yàn)，他為傳統(tǒng)的手工測試引入了可重復(fù)、規(guī)范、可傳授和特別高效的新過程。Whittaker定義了針對單個(gè)測試人員的簡單技術(shù)和針對大規(guī)模測試團(tuán)隊(duì)的復(fù)雜技術(shù)。他還引入了一個(gè)混合策略，將探索式概念引入傳統(tǒng)腳本測試。在《探索式軟件測試》中，可以體會(huì)到如何在恰當(dāng)?shù)臅r(shí)機(jī)使用這些方法，如何成功地充分應(yīng)用這些方法。簡潔、詼諧和可行，《探索式軟件測試》引入的這些技術(shù)已經(jīng)經(jīng)過上市軟件的測試人員廣泛應(yīng)用，人們在實(shí)際測試過程中深受這些方法的啟發(fā)，成功實(shí)現(xiàn)了預(yù)期目標(biāo)?！短剿魇杰浖y試》是為測試人員、QA專家、開發(fā)人員、程序經(jīng)理和架構(gòu)師所寫的?！短剿魇杰浖y試》涉及以下重要問題：為什么自動(dòng)化測試無法消除所有缺陷，如何才能讓這些缺陷無處遁形？哪些技術(shù)可幫助我不斷發(fā)現(xiàn)和消除致命錯(cuò)誤？如何更高效地進(jìn)行手工測試，增加些許輕松和愉悅的感覺？對于每個(gè)項(xiàng)目，如何確定最高效的高級測試策略？在我無法進(jìn)行全部測試時(shí)，哪些輸入是必須測試的？哪些測試用例能提供最理想的特性覆蓋率？在結(jié)合使用探索測試和傳統(tǒng)腳本或場景測試時(shí)，如何才能獲得理想效果？如何體現(xiàn)來自開發(fā)過程的反饋意見，代碼更改嗎？

圖書封面

圖書標(biāo)簽Tags

無

評論、評分、閱讀與下載

---

    探索式軟件測試 PDF格式下載

---