书评 - 《展望敏捷软件测试》
借Selenium誕生十周年慶典之機，來自于ThoughtWorker公司的幾位專家共同推出了一本精選書，其中收錄了他們在軟件測試方法、工具和文化方面的一些文章。這本精選書以電子書的形式提供，書名為《展望敏捷軟件測試》（Perspectives On Agile Software Testing），可以在ThoughtWorks的網站上進行免費下載。
\\本書的篇幅雖然簡短，但包含的信息量卻相當豐富，其中提到了測試工具的演變、在敏捷環境中的測試、對移動設備進行測試、對移動應用使用BDD及持續交付等等。本書中的某些部分很有看點，例如對不同工具的比較。雖然篇幅簡短，但內容豐富，對移動設備的測試進行了深入的描述，包括持續集成與持續部署等概念。
\\Anand Bagmar首先介紹了Selenium這一工具及它的使用方式。2004年，Jason Huggins在對ThoughtWorks的一個內部應用程序進行測試時，創建了JavaScriptTestRunner工具，正是它改變了對基于瀏覽器的測試進行自動化的方式。該工具隨后演變成了“Selenium”，并最終實現了開源。
\\Alabe Duarte和Fabio Maia介紹了移動測試方面的內容。在移動測試中常見的挑戰包括測試內網延遲、3G/4G連接、WiFi以及與地理位置相關的特性。為了對web應用進行測試，并且保持單元測試的快速執行，他們會經常使用Test Double（替身）。這種技術有助于避免代碼與任何進程或無法控制的外部依賴進行通信。這方面一個非常有趣的例子是Appium，它允許任何人為基于不同語言開發的移動應用編寫測試。Appium能夠實現這一點的原因在于它實現了Selenium的webdriver API，因此每種語言都可以通過webdriver與之進行連接。
\\Prateek Baheti和Vishnu karthik接下來介紹了在移動應用中進行BDD風格測試的方法。在BDD風格測試中，通過一種中立的、并且非常特定于具體領域的語言表達出測試的規格。BDD的實現需要工具的支持，通過工具將測試規格與底層的實現結合連接在一起。
\\作者舉了一個例子，描述了某個消息發送應用的一個具體測試場景：
\\- 我要以foo@foo.com帳號登錄 \\
- 我對user@user.com發送了一條消息“Lorem ipsum dolor sit amet”（一段著名的用于測試排版的假文字） \\
- “user@user.com”會收到一條通知，告訴他有新的消息來了 \
以上這個測試不會與底層的細節打交道，而是以自然語言、使用領域術語描述了這一測試場景。在這個測試用例中，收到一條通知就是一個領域術語，而它的具體實現在不同的平臺上可能是完全不同的。
\\Gayathri Mohan介紹了在移動應用中使用持續交付方面的內容。在這一章節中，她在對移動應用進行手動測試或自動化測試的上下文中對持續交付進行了闡述。她還對持續集成和跨平臺自動測試框架進行了深入講解。
\\InfoQ有幸與本書的作者們進行了一次訪談，話題涉及了本書的內容，以及測試方面的最佳實踐。
\\InfoQ：對于讀者來說，閱讀這本書能學到什么新東西？
\\\本書收集了一系列優秀的文章，它們從不同的維度對測試進行了講解，包括——
\\Anand Bagmar在書中分析了Selenium是否已經成熟，使用Selenium實現自動化與測試自動化金字塔（Test Automation Pyramid）有怎樣的關系。并且對這個時代的測試人員如何做好準備迎接未來的挑戰提供了一些建議。
\\- 如何在移動應用中開展BDD風格的測試（Prateek Baheti和Vishnu Karthik）， \\
- Gayathri Mohan將這一點更進一步，探討了如何在應用程序中實現持續交付。 \\
- Vikrant Chauhan和Sushant Chaudhary介紹了在移動測試中可能遇到的各種挑戰。\
InfoQ：你們在書中提到了測試金字塔反模式，能為我們詳細解釋一下嗎？
\\\自動化測試的目的在于為團隊提供快速的反饋信息：最近的某次改動是否造成了原先能夠正常運行的功能出現了故障？
\\Martin Fowler在他的博客帖子中對測試自動化金字塔進行了解釋。
\\在理想的測試金字塔中，發生在最接近于源代碼的地方的自動化測試數量應當最大話，例如在單元測試這一層，而發生在金字塔頂層的測試的自測數量應當最小話，例如在功能性UI（用戶界面）層。此外，單元測試應當對產品代碼中的細粒度的片段進行測試，而UI測試應當專注于對構建與部署后的產品進行業務功能方面的確認，例如對用戶的訪問過程和場景進行測試。不過，要實現并長期維持一個“良好”的金字塔，需要團隊在流程和實踐方面投入巨大的精力。
\\許多團隊對于（各種類型的）自動化測試的投入依然有所不足。有些團隊采取了某種快捷方式，在代碼開發完成之后，設立一個獨立的團隊專門編寫UI層的測試。而這種方式的結果是，團隊對于金字塔底層的自動化測試方面的關注相當不足。而且，就如大家都意識到的一樣，UI自動化的實現和運行都相當緩慢，并且非常容易被破壞，對于UI任何一點微小的改動都有可能造成測試失敗。因此，盡管許多團隊已經在UI自動化方面投入了許多資源，但他們還是要將大部分的精力投入到對UI測試的缺陷修復、更新以及維護上，并且需要專門安排一組測試人員手動地進行重復式的回歸測試。這就形式了一種蛋筒式反模式（Ice-Cream Cone）（即倒金字塔形狀）。
\\有些情況下，測試團隊是整個組織中的一個獨立團隊，或者有可能將測試任務交給第三方或合作伙伴完成。他們對于產品的測試方式無法達到開發者之間那樣的合作能力。開發者與測試者之間也不會對于哪些測試要進行自動化，哪些不需要自動化等方面進行交流。其結果是可能會產生開發者與測試者之間的測試用例產生了重復。而更嚴重的問題在于，在自動化測試中有可能會遺漏許多測試用例或測試場景。這是一種雙向測試金字塔反模式。
\\Fabio Pereira用另外一種有趣的方式對雙向測試金字塔反模式進行了描述，并將其稱為紙杯蛋糕反模式（Cupcake）。他也提出了某些技術，可以通過使用這些技術讓團隊遠離這些反模式，而實現理想的測試金字塔。
\\\InfoQ：書中提到，QA的角色正在變得越來越復雜，他們需要進行心態上的轉變，同時在技術方向上也要需求突破。請對這種說法表達一下你們的意見。
\\\當團隊開始使用敏捷開發方法之后，團隊中的每位成員都需要加快他們工作的腳步。下面這張圖來自于Agile QA Process，它表現了QA人員在每個迭代中需要經歷的一系列活動。
\\ \\在短小的迭代中，這一流程會顯得非常緊張。此外，QA通常在這種工作方式中通常需要經歷三個不同性質的階段。
\\- 過去 —— 對于之前迭代中完成的工作提供支持。 \\
- 現在——保證創建的特性是“正確”的，并且實現的方式也是“正確”的。 \\
- 將來——對于下一階段的開發中可能到來的任務做好準備，并且開始考慮如何對其進行測試。 \
最后，自動化測試對于保證團隊取得成功是一項必不可少的要求，而為了讓團隊實現這一點，QA在其中扮演了十分重要的角色。這不僅要求QA具有優秀的手工測試和探索性測試技術，并且要求QA對于測試中的產品在技術方面也要有相當程度的理解，從而保證確定了正確的測試，并且在測試金字塔的正確環節實現自動化。
\\由于QA在這一流程中需要經歷大量的活動，并且經歷這些不同的階段，因此他（或她）需要對工作的方式進行優化，并且做到對下一階段必須要做的事持續不斷地對優先級進行適當的調整。因此，QA這一角色變得更加復雜，為了取得成功，必須換一種不同的思考方式。
\\\InfoQ：你對QA在三個不同維度中所扮演的角色：商業、技術與DevOps進行了很好的詮釋。QA在這三個方面的不同角色有哪些相似之處和不同之處呢？
\\\這三個維度的共同點在于，QA對于產品的質量和自動化測試必須具有主人翁意識，他們需要讓團隊專注于交付高質量的產品，確保它易于維護和實現新的特性。
\\這三種類型的QA之間也有一些不同之處：
\\- 在商業維度上的QA是由業務驅動的，并且需要很好的與客戶交流的溝通技巧。他們將通過各種示例對產品規格有一個很好的了解，并且需要具有優秀的聆聽技巧，以從客戶那里獲得所需的驗收測試項目。 \\
- 在技術維度上的QA具有優秀的編程技術，并成為自動化測試方面的專家。他們對關注代碼的可維護性，總是尋求各種優秀的實踐，例如整潔的代碼、最佳實踐和設計模式等等。這些QA會與開發者結對工作，共同創建解決方案。 \\
- 在DevOps維度上的QA需要具備持續交付與對重復性任務進行自動化的知識。他們將幫助團隊打造一個測試金字塔，以實現某種持續交付的周期。 \
InfoQ：本書介紹了Appium這門工具，它實現了Selenium webdriver API，專門用于移動測試。那么這個工具與其它類型的移動測試工作有什么不同呢？使用它能為我帶來怎樣的好處？
\\\Appium的社區非?；钴S。由于它的開源本質，有許多貢獻都是來自于社區，這也使它能夠更快地實現新的特性和修復缺陷。并且如果你需要在云端環境中運行你的測試，以實現更大的規模，Saucelabs服務同樣也支持Appium。
\\并且由于它實現了標準自動化規格，因此可以很容易地找到一種以你所熟悉的語言編寫的Selenium webdriver的具體實現。比方說，QA團隊可以很容易地找到Java語言 (Android)或Objective-C語言 (iOS)以外的不同實現。
\\其它的好處還包括：
\\- 如果你的移動應用是跨平臺的，那么你也能夠在每個平臺上都使用相同的測試。 \\
- Appium能夠對接近生產版本的應用進行測試，更妙的是，即使是你打算提交到marketplace上的版本，Appium同樣可以進行測試。 \
InfoQ：對于持續集成和持續交付在移動應用開發中的重要性，你們是怎么看的？
\\\在這個快節奏的社會中，作為商業組織，我們需要盡快地將產品和服務展現給用戶，但是，如果產品本身質量不過關，那么僅僅做到快速推向市場也是不夠的。持續集成（CI）和持續交付（CD）這樣的實踐能夠讓團隊在將產品交付給客戶時充滿信心。
\\這些實踐適用于基于Web的產品，同樣也適用于基于移動的產品。區別僅在于使用的工具不同，并且需要對這些實踐的各個部分進行微調，以確保得到最佳的結果。
\\\InfoQ：在移動開發中使用BDD有什么好處呢？
\\\BDD最大的好處在于，團隊之間可以用相同的領域術語和業務術語進行交流，最終可以消除在項目干系人和團隊成員之間產生的所有理解的歧義。
\\如果能夠正確地使用BDD，那它就能夠隱藏實現細節，并且幫助開發者專注于該特性或功能所試圖解決的商業目標。
\\如果能夠正確地使用BDD，它就能夠隱藏特定于平臺的細節。
\\*：就像其它任何工具一樣，你必須正確地使用BDD，并且使用在適當的上下文中，這樣才能夠發揮出它的價值所在。
\\**：BDD意味著你在你的開發環境中又多加了一層額外的代碼（和工具）。無論你添加了哪種類型的工具或流程，它都伴隨著相應的成本。在你決定在開發周期中使用任何工具、技術和流程之前，都應該全面地了解它的所有優點與缺點。
\\\InfoQ：對于敏捷QA來說，最關鍵的技術是什么？
\\\除了必備的測試技能之外，以下技能（排名不分先后）對于QA在敏捷團隊中獲得成功也是相當重要的：
\\- 能夠對不同的測試活動排列優先級的能力。 \\
- 要將心態轉變為：“幫助團隊實現迭代中所包含的每個需求的‘完成定義（Definition of Done）’。” \\
- 與業務分析師或產品負責人進行協商，以探討當前階段需求的真實價值，以確保在短時間之內創建出“正確”的產品。 \\
- 保持開放的心態 —— 這有助于你以一種更優的方式學習新的工作方法。 \\
- 盡可能幫助團隊在測試金字塔的底部實現自動化。 \
InfoQ：你們是否打算在不久的將來，在新書中涵蓋更多有關敏捷和測試的概念。
\\\我們對于下一本書已經有了許多點子，它將基于這本書中已經涵蓋的內容。不過，我們也樂于傾聽讀者的意見，我們會盡量在下一本書中加入他們在反饋和建議中所提到的內容！
\\\關于本書作者
\\Anand Bagmar是一位動手能力很強并且注重結果的軟件質量福音傳道師，在IT領域已經具有17年以上的經驗。他創建了各種與軟件測試相關的開源工具，包括WAAT（Web Analytics Automation Testing Framework）、TaaS（用于在不同系統間進行的集成測試進行自動化）以及TTA（Test Trend Analyzer）。
\\Daniel Amorim在ThoughtWorks擔任敏捷顧問QA。他從2007年開始在IT領域開始工作，始終致力于提倡敏捷測試的最佳實踐，并為開發團隊作出貢獻。
\\Alabê Duarte從2007年起在ThoughtWorks擔任顧問開發者。
\\Fábio Maia是ThoughtWorks的一位高級開發顧問。他對于由Qt/C++或C#編寫的桌面應用程序特別感興趣，他也是一位使用C#/XNA的游戲開發者。
\\Prateek Baheti是ThoughtWorks的一位應用程序開發者，他參與Twist項目已經有兩年的時間了。
\\Vishnu Karthik是ThoughtWorks的一位開發者。他曾經參與過Twist和自動化測試的項目。
\\Gayathri Mohan是一位ThoughtWorks的高級質量分析師，在公司里有超過5年的經驗了。她的工作經歷包括多個領域，例如旅行、零售、電子商務，以及多種平臺，例如.NET、Rails、Android和iOS。
\\Vikrant Chauhan是一位技術狂熱分子。他密切地關注開源測試工具的發展，并且總是在任何可能的情況下使用它們。
\\Sushant Choudhary是一位充滿熱情的技術愛好者，也是一位體育迷?？紤]到不斷變化的技術方案和它對社會的影響，他總是時刻進行探索，并且在軟件工程中應用新的開發技術。
\\Nicholas Pufal從少年時代開始就對編程產生了濃厚的興趣，當時他已經開始嘗試編寫開源代碼項目了。他對于設計模式、優秀的開發實踐，以及改善敏捷團隊的溝通技巧和交付質量的各種方式保持著很高的熱情。
\\Juraci Vieira也是一位技術狂熱者，他的職業生涯開始于測試人員的崗位。他被自動化所深深吸引，然后才明白質量本身就是由軟件產生的，從那之后，他搖身一變成為了一名熱情洋溢的開發人員。
\\Paul Hammant已經40多歲了，他從2002開始就在ThoughtWorks擔任首席顧問，1989年起就進行各種顧問工作。除了從客戶那邊賺錢之外，他也常常幫助ThoughtWorks進行各種開源活動。
\\查看英文原文：Perspectives On Agile Software Testing - Book Review
總結
以上是生活随笔為你收集整理的书评 - 《展望敏捷软件测试》的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： poj Buy Tickets
- 下一篇： 团队开发博客成员介绍（发在个人博客中了）