探索式軟件測試

所属分类:軟件工程及軟件方法學  
出版时间:2010 年4月   出版时间:清華大學出版社   作者:James A. Whittaker   页数:230   译者:方敏;張勝,鐘頌東;郭艷春  

前言

“用户购买功能的同时也在忍受缺陷。” ——史考特·沃兹沃思(Scott Wadsworth) 任何一个使用过电脑的人都知道软件故障。从最初的第一个程序到最新的现代应用程序,软件从来没有完美过。 将来这一切也多半不会改变。不只是软件开发错综复杂和开发人员容易犯错的天性,还有硬件、操作系统、运行时环境、驱动程序、平台、数据库等不断变化,这些加在一起使软件开发任务成为全人类最让人称奇的专业技能之一。 不过,仅仅令人称奇是不够的,正如本书第1章指出的那样,这个世界还要求软件拥有高质量。 显然,关心质量不只是软件测试人员的事。我们应该用正确的方式构建软件,将可靠性、安全性和高性能等作为系统设计的一部分来考虑,而不是到开发末期才想起它们。然而,说到理解软件缺陷的本质,测试人员总是站在前沿。如果没有测试人员在测试的最前沿发挥他们的洞察力、技术以及应变措施,使这样的可能性变为现实,软件质量的全面解决方案差不多算是“镜中花,水中月”。 谈论软件质量的方法有很多,感兴趣的听众也有很多。本书是为软件测试人员而写的,写的是一种我认为比其他任何缺陷都重要的特殊缺陷:即逃过所有各种检测手段而最终存在于发布产品中的缺陷。 任何一个软件公司发布的产品都有缺陷。缺陷是怎么引入的?为什么没有在代码审核、单元测试、静态分析或其他面向开发人员的活动中把它们找出来?为什么自动化测试没有找出它们?那些缺陷有些什么特质使其能逃过手工测试? 什么是找出产品缺陷的最好方法? 本书针对的正是最后一个问题。在第2章“手工测试”中,我提出了一个观点:因为用户是在使用软件过程中找到这些缺陷的,所以我们的测试人员也应该通过使用软件来找到它们。无论使用自动化测试和单元测试,还是其他一些手段,都难以接触到这些缺陷。无论测试人员怎么实现自动化测试,即使全部都自动化,这些缺陷还是会处处作怪,并在产品中屡屡重现从而伤害最终用户。 问题在于很多现代化手工测试实践都缺乏目的性,随机性强且重复性强。有些人可能还会加上一条:手工测试无聊透顶。本书试图为手工测试流程提供一些指导、技术和规划。 在第3章“局部探索式测试法”中,针对测试人员在运行任何一个测试用例时都需要做出很多细微的战术层面决定,我给出了详尽的指导建议。测试人员必须决定对于某个特定的输入字段应该使用什么输入值,或者给应用程序使用的文件提供什么数据。在测试过程中,必须做出许多这样的小决定。在缺乏指导的情况下,这些决定常常是未经分析且不是最优化的。在向一个文本框内输入一个数时,选择整数4难道就胜过整数400么?应该用长度为32字节的字符串还是长度为256字节的字符串?选择一个而不选另一个是有一定道理的,这一切都取决于处理该输入的软件的具体情况。鉴于测试人员每天都要做出数百次这样的小决定,在这里提供有效的指导建议显得至关重要。 在第4章“全局探索式测试法”中,针对测试人员在编制测试计划和测试用例设计时需要考虑哪些广泛的战略性问题,我也给出了一些指导建议。这些技术都基于“漫游测试”(tour)概念,如同一个导游带领旅游团队参观大都市中一系列著名景点一样,这种漫游测试法指出的路线可以指导测试人员如何探索软件的方方面面。这里的探索并不一定是随机的或者漫无目的的。本书所记录的方法已经成为微软和谷歌的许多测试人员日常工作的一部分。诸如“地标测试法”(landmark tour)和“极限测试法”(intellectual’s tour)等词汇已经列入了手工测试人员的标准词汇表中。测试技术以前确实被称作“漫游”,但是用整个旅游业来隐喻软件测试,并在测试实际发布的应用程序时,大规模使用这些隐喻的名称,还属于本书的一个创举。 全局探索式测试法对于制定完整的测试策略给出了指导建议。例如,如何创建一组特性覆盖率(feature coverage)较高的测试用例?如何确定是否要在一个单独的测试用例中使用多个特性?如何创建一个完整的测试用例套件(test case suite),从而使软件尽可能地满负荷工作以便能找到更多重要的缺陷?这些都是设计测试用例和保证测试套件质量时必须解决的重大问题。 在第5章“混合探索测试技术”中,通过把探索式测试和传统的脚本或基于场景的测试技术相结合,进一步扩展了漫游的概念。我们将讨论如何修改各种端到端场景(end-to-end scenario)、测试脚本(test script)或用户故事(user story),来创造更多的变化情况,以激发传统静态测试技术查找缺陷的潜力。 在第6章“探索式测试的实际应用”中,来自微软不同产品组的五位客串作者提供了他们使用漫游技术后得到的经验报告。这些作者和他们的团队在真实的开发环境中,把漫游方法应用在真实的软件上。他们记录了各自是如何使用漫游、修改漫游甚至创建自己的漫游的。这些内容来自于使用漫游法测试重要的关键软件产品的测试人员,属于真正的第一手资料。 最后,我用两章内容总结前面各章所讨论的内容。在第7章“漫游测试的棘手问题”中,描述了我认为的测试中最困难的几个问题,以及如何将那些具有高度针对性的探索式测试方法融入一个更广泛的解决方案中。在第8章“软件测试的未来”中,我更进一步讨论在未来几年中,诸如虚拟化、可视化甚至电视游戏之类的技术将如何改变测试的面貌。附录包括我对测试职业生涯的看法,收集了我以前一些深受读者喜爱的文章(加入了一些新的注解),其中一些文章已经无法在其他地方看到了。 写这本书对我来说是一种享受,我希望你阅读本书也是一种享受。

内容概要

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

作者简介

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

书籍目录

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

章节摘录

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

后记

人非聖賢,孰能無過。一語道破人類容易犯錯的天性,也為人們提供了堂而皇之逃避責任的借口。但隨著科學技術的發展,軟件在金融、醫學、航天、汽車等行業全方位的滲透,導致我們越來越難借助于這樣的托詞,原諒自己的失誤,因為一個微不足道的疏忽或者失誤,放過軟件中存在的漏洞、缺陷和隱錯,就會導致無可挽回的損失甚至災難性的後果。上世紀末在美國,因為兩套軟件采用的度量單位不一致(一個公制單位Ns,一個英制單位bs,後者是前者的4倍),導致美國國家航空航天局(NASA)幾億美元的損失,使火星氣候軌道飛行器在最後的關鍵時刻墜入火星,而不是順利進入軌道按照既定設計繞火星運行。此類事例在計算機一統天下的今天並不罕見,同時也為我們敲響了警鐘,軟件測試到了不得不高度重視的程度。反觀軟件測試行業,可用的測試方法與10年前卻沒有多大差別。要想提高軟件質量,測試先行,測試創新,已經到了刻不容緩的地步。探索式測試(Explory tory Testing,也稱探索性測試)是一種軟件測試方法,最先是CemKaner在1983年提出的。這是一種強調個人自由與責任的測試方法,讓獨立測試人員可以借由不斷的學習來改善測試的規劃與測試的執行,而在測試的過程中也會同時改善測試案例達到相輔相成的效果。在Nortel和微軟的很多項目中,都采用了這一新穎、有趣和富有創意的測試方法。

媒体关注与评论

“好书!Whittaker讲述的概念有创意、巧妙、令人印象深刻。他真正懂得如何鼓励工程师们以不同的角度考虑软件测试。”   ——谷歌公司测试工程总监Patrick Copeland “James把美妙的手工测试方法学提升到了极致。漫游不仅概念正确,而且实际应用得很好,我们已经在所有测试人员的内部培训课程中分享了漫游的概念。如果你想把手工测试过程带到21世纪,请阅读这本书吧。”   ——微软公司卓越测试总监Alan Page “1990年,我开始与James在IBM一起共事。他早在当时就鼓励测试人员和开发人员大胆创新。通过这本书,他把对软件质量的热情提升到了全新的高度。请阅读这本书吧,见证你自己成为一个更好的测试工程师。James是这方面的权威,这个星球上的软件测试工程师和开发工程师,无论他们是真正关心软件质量,或者只是想在自己的日常工作中增加更多的乐趣,都应该阅读这本书。”   ——Cisco Systems公司高级工程主管Kaushal K. Agrawal “James Whittaker 是测试领域中一位真正有远见的人士。Utest和我们的QA专业全球社区经常向James咨询以获得他的灵感、他对测试未来趋势的解读和他的各种测试理念。现在,他终于为大家写出了这本书,我们这个行业会由于这本书而变得更有智慧。”   ——uTest公司CEO和合伙人Doron Reuveni “只有像James Whittaker这样的人才会把旅游和软件测试以小说的形式结合起来,也只有James才能把它做到这么天衣无缝。漫游方法不仅提供了令人难忘的有效思考模式,还把适当的结构和组织与广泛的探索和创造结合在一起。bug们,小心啦!”   ——谷歌公司Alberto Savoia “James是软件测试主题最出色的演讲者之一,读他的书就像聆听他的演讲。如果你希望增加测试知识并成为一个更优秀的测试人员,这本书就是为你而写的。”   ——TCL集团公司主席和合伙人Stewart Noakes “我从事探索性测试已经有段时间了,James的漫游测试法给我所使用的各种方法起了名字,定义了测试重点,更重要的是给了我实际的指导。这本书将会使探索式测试的教学和应用变得更方便。”   ——iMeta Technologies公司高级测试顾问Rob Lambert “我为这项工作感到非常激动,它概念新潮却又合情合理。连我这样的普通读者都能轻松地理解和使用,而不用首先去学习一些华而不实的过时理论。在阅读本书时,我也从不需要借助字典。测试领域长久以来就一直期盼着这样的创新之作,我由衷地认为本书在这方面走在行业最前沿。”   ——Netjets公司QA部门经理Linda Wilkinson

编辑推荐

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

图书封面




    探索式軟件測試下載



用户评论 (总计18条)

 
 

  •     很喜歡作者的敘事風格,像讀小說一樣,把軟件測試說的很透徹。其實書里的很多場景我們從業人員都遇到過,只是沒有總結過。書後面的也比較有意思,暢想一下軟件測試的未來,對自己的職業有信心了。推薦購買!
  •     很不錯的書,對于測試的思想很有幫助
  •     書本質量很高,內容也很通俗,主要交了探索式測試法,不同于常規的測試方法
  •     作者經驗豐富,探索式測試對于提高測試效率和質量,充分發揮測試者的智慧是很好的一種思想
  •     很喜歡,簡單易懂,還不錯
  •     還沒細看內容,質量很好
  •     很不錯的圖書,可以買來看看。
  •     想具體學習一下探索式測試的理論基礎,看看還是不錯的,第四章是精華。
  •     第一次買的書,沒怎麼看,書送人了。又買了一本,瀏覽了一倍,這本書感覺沒什麼層次感,博客堆積,不夠深入。探索測試,更適合測試專家進行測試方法,普通的測試人員不適合。
  •     看了這本書,我才把我用了很久的測試方法上升成了理論。唯一感覺別扭的就是里面的話有點繁瑣。
  •     灰常好的書,內容精要,知識概況精煉。
  •     內容應該還不錯,但讀起來很枯燥乏味!看著看著就想睡覺(可能是俺的水平差吧),能明白,但看不下去,組織得比較亂,不吸引人。
  •     故事形式。說了很多隱喻。
  •     這本書是寫得很好,但是書的印刷質量太差了,竟然有十幾頁是空白的。我一直對亞馬遜的質量都很滿意的,第一次給亞馬遜差評的,這次卻大的失望了∼
  •     還沒看,不知道
  •     探索式測試
  •     挺好的 沒什麼缺點
  •     探索式軟件測試

类似《探索式軟件測試》的图书资源

 

計算機與互聯網 PDF免费下载,軟件工程及軟件方法學PDF免费下载。 计算机教程网 

计算机教程网 @ 2017