探索式測試的問與答（2）

　 　探索就是在陌生的環境中玩（play）。你需要自由地探索才能學習。我們不僅僅接受資訊，而是親自探索和建構思維模型。玩引入了一種新奇的感覺，也就是 樂趣。用一種好玩的方式學習新資料或者解決問題，可以讓這個過程變得更讓人享受，也讓學習變得更容易。為了更好地學習，請更好地玩。

　　你需要自由地創造--不介意自己的創造沒有成功。通過構造來學習，而不是通過學習來構造。這是“原型”、“曳光彈” 、持續內建等方法獲得成功的原因之一。

　　你需要在日常實踐中應用到你學到的東西。你持續使用和實踐的技能會在腦皮層競争中占據統治地位，大腦會為它們提供更多友善。

　　這種探索應該相對沒有風險，因為你肯定不想因擔心害怕而止住探索的腳步。安全有助于更好地利用回報，讓失敗也變得有意義。

　　雖然andrew讨論的是廣義的學習與探索，但是他的話解釋了探索式測試的成功之道：探索式測試在本質上鼓勵測試人員去自由地探索、創造和應用。

　　探索是帶着使命在某個空間中有目的的漫遊，但沒有預先确定的路線。探索包括不斷學習和實踐。

　　探索式測試者持續應用他所學到的知識。所謂“學而時習之，不亦說乎”，探索式測試将學習與應用作為互相支援的活動逐漸展開，為測試者的知識提升提供了平滑的學習曲線。

　　探索式測試有助于測試人員在合适的時間學習合适的内容，并立即應用，以獲得真實回報。這提高了學習效率和效果，并降低了浪費測試資源的風險。

　　在探索式測試中，測試者創造出一切有助于學習和實踐的資料和工具。它們包括測試輸入資料、結果檢查腳本、資料分析報告和業務流程圖表等。

　　探索式測試是一項富有智力挑戰的活動，充滿了樂趣。

　　答：探索式測試有助于“機動性”，該特性在現在比以往任何時候都更重要。

　 　首先，探索式測試将許多測試決策置于更合理的時機，進而避免了浪費。在web應用等高競争性領域中，開發組織面臨模糊且持續變更的使用者需求。更重要的 是，他們必須在一切明朗之前着手行動，因為傳遞的時機将在很大程度上決定市場的反應，此外真實的使用者回報将有助于下一次更準确地傳遞。面對高變動性的開發 過程，測試人員需要将測試設計合理地配置設定到整個開發周期，根據目前的開發進度和真實的測試回報，做出恰當的測試決策。這有助于避免在資訊不充分的情況下做 出錯誤的決定，進而導緻嚴重的浪費和返工。

　　其次，探索式測試不停地根據實際情況，調整測試計劃，優化測試政策，是以能夠更有針對性地測 試，進而更快速地穩定（stabilize）産品。探索式測試和語境驅動測試建議，測試人員總是自問：“我現在可以測試什麼？應該如何測試？”這有助于測 試人員更動态地審視被測試産品和測試政策，并運用多樣化的手段去探索産品。随着對業務領域的認識不斷深入，随着逐漸了解産品的設計和弱點，随着對測試技術 和工具的更加熟悉，測試人員會不斷調整測試政策，使得在整個産品開發過程中，重要錯誤的發現率都保持在比較高的水準[kaner01]。而及時地發現重要 錯誤能夠幫助開發組織降低風險、快速推進。

　　測試需要探索，而探索要要大量的思考。積極思考的探索式測試是具有挑戰性的智力過程，常常需要以不确定的順序反複實施鑽研、嘗試、迂回、調整、評估等活動。好的探索式測試不會使測試更簡單，但是它會使測試更有效，進而在測試速度和缺陷發現上獲得更多的回報。

　　問：探索式測試是否隻适用于功能性測試？

　　答：作為一種測試風格，探索式測試可應用于各種類型的測試。

問：在功能實作之前，探索式測試是不是無用武之地？

　　答：對于探索式測試有一個誤解，那就是探索式測試隻通過運作測試以獲得知識。實際上，探索式測試者能夠也必須通過其他手段探索被測試軟體。

　　語境驅動測試認為：産品是一種解決方案，它必須解決現實世界中的問題。是以，探索式測試者必須從項目關系人（包括軟體使用者、項目投資人和開發團 隊等）的視角考察整個産品，研究顯式規格說明和隐式規格說明，進而發現軟體在概念、需求、設計、實作等層面上的缺陷。值得強調的是，測試人員應該主動探究 隐式規格說明，進而拓寬探索的範圍。以下是一些常見的隐式規格說明。

　　競争産品。競争産品不一定是軟體，例如筆記軟體的競争者就包括紙質筆記本和鉛筆。

　　相關産品。軟體套裝（如microsoft office）中的軟體往往互相補充、互相限制。

　　同一軟體的已釋出版本。向前相容可能是非常重要的限制。

　　口頭讨論、采訪、閑聊。

　　電子郵件、會議記錄、采訪記錄。

　　使用者回報：電話支援記錄、論壇讨論、beta測試回報。

　　技術回報：軟體送出的崩潰資訊、錯誤消息。

　　第三方評論：雜志文章、部落格文章、社交網絡回報。

　　技術标準。所有軟體都建立在一系列技術标準之上，某些标準會對測試産生重要影響。

　　法律法規。法律可能對軟體有強制性限制。

　　領域專著。測試财會軟體需要學習相關著作，以掌握财會知識。

　　測試人員經驗。

　　cem kaner擁有法律學位，對語言文字非常敏感。他認為積極閱讀（active reading）是探索式測試者需要具備的技能。積極閱讀是一個内涵豐富的主題，廣受好評的經典書籍包括《如何閱讀一本書》 、《探索需求》 和《你的燈亮着嗎？》 。

　　此外，在功能實作之前，可以通過小組讨論、頭腦風暴等方式發掘測試政策和測試思路。針對一個開發中的功能，測試人員可以邀請幾個同僚，組織一個 測試研讨會。在會議上，大家自由發言，提出自己的測試政策，通過腦力震蕩互相啟發，進而獲得一批觀點各異、視角不同的測試政策。會後，測試負責人對這些相 對粗糙的測試思路進行整理，将完善後的結果寫入測試計劃。

　　問：如何評估探索式測試的測試效果？

　　答：評估探索式測試結果的前提是測試記錄。

　　探索式測試者常常在一個固定的時間視窗内（60~120分鐘），根據預設的測試目标，對軟體進行z探索式測試。這樣的測試活動被稱為測程（session）。

　　測程類似于科學實驗。一次科學實驗大緻可以分為以下三個階段。

　　（1）實驗設計：确定實驗目标。科學實驗的常見目的是假設檢驗，那麼此次的假設是什麼？

　　（2）實驗記錄：執行實驗步驟，并記錄實驗所發現的點點滴滴。

　　（3）實驗分析：分析實驗資料，總結實驗結果，為下一次實驗提供目标和假設。

相應地，一次測程包含如下三個階段。

　　（1）測試計劃：明确測試目标。測試是獲得資訊的過程，那麼此次測試要獲得什麼資訊？

　　（2）測試執行：設計并執行測試用例，記錄測試所發現的點點滴滴。

　　（3）測試分析：分析并總結測試所發現的資訊，為下一次測試提供目标。

　　詳細的實驗記錄是科學實驗的基本要求之一。同理，詳略适當的測試記錄也是測試執行的自然結果，是測試評估的基本要求。通常，測試記錄可以包含如下内容。

　　測試目标：本次測試要提供什麼資訊？

　　測試範圍：本次測試覆寫了哪些功能、子產品、使用者情景？

　　測試政策：本次測試使用了何種測試方法？

　　缺陷清單。

　　在測試過程中發現的疑問，它們值得進一步探索。

　　可以複用的測試資源：被測試軟體配置、測試資料和測試腳本等。

　　測程的耗時。

　　測程的時間配置設定：在測試設計與執行、缺陷調查與報告、測程的啟動與結束和非測試活動上各花費了多少時間。

　　測試記錄可以轉化為測試備忘錄，供今後的測程參考。測試記錄也可以提煉為測試報告，反映目前項目的進展。更重要的是，測試記錄是測試評審的素 材。基于測試記錄，測試團隊可以開發出符合項目語境的評估方法，對測程進行專家評審和定量度量。這有助于度量探索式測試結果，并提出改進方案。

　　問：探索式測試隻适合測試專家，不适合測試新手？

　　答：“探索式測試不适合測試新手”是一種似是而非的說法。第一，所有高效的測試都依賴于測試人員的測試技能 和行業知識。測試專家能夠準确地選擇測試政策、有效地運用測試方法，是以測試效果更佳。第二，測試新手采用任何測試方法，都需要指導和幫助。這有助于他們 充分利用方法的優點，并避免方法的潛在陷阱。可見，更有意義的問題是：如何幫助測試新手盡快地掌握測試方法，盡快地成長為測試專家？

　　從個人發展的角度看，探索式測試有助于測試新手快速學習。探索式測試将學習與應用作為互相支援的活動逐漸展開，為測試人員的技能提升提供了平滑 的學習曲線。此外，并行地進行測試學習、測試設計、測試執行和測試評估為測試人員的成長提供了持續、及時、有效的回報，這有助于他主動學習和快速調整。

　　從企業發展的角度看，測試團隊應該積極幫助測試新手成長。可以采用的方法包括：為他安排工作導師、評審其測試文檔、評審其測試記錄、在測程中安 排測試專家與他結對測試、定期進行一對一的會談等。這些活動會消耗測試團隊的人力資源，但是它們是幫助新員工成長最快速、最有效、最廉價的方法。

　　peter drucker指出：知識勞工的創造性（productivity）要求他們被視為企業的資産（asset）而不是開銷（cost）。培養高水準測試人員是測試團隊和測試上司不可回避的職責。

　　問：有什麼工具可以支援探索式測試？

　　答：本書第5章将讨論探索式測試的工具。這裡強調兩個基本觀點。

　　第一，作為一種測試風格，探索式測試可以使用任何開發和測試工具。探索式測試者應該根據語境選擇合适的工具，去完成自己的使命。

　　第二，軟體測試存在大量的創新空間，測試人員應該勇于開發自己的探索式測試工具。

　　測試專家james a. whittaker提出過一種測試工具建構方法，值得測試人員參考。

　　（1）尋找缺陷：發現或收集軟體的缺陷。

　　（2）提煉模式：分析出缺陷的根本原因，編寫一個模式，用它捕獲相似的缺陷。一個模式是一個結構化的攻擊手段，它包含如下内容。

　　何時實施該攻擊？

　　該攻擊會捕獲何種錯誤（fault）？

　　利用該攻擊如何識别軟體失敗（failures）？

　　如何實施攻擊？

　　樣例和分析。

　　（3）開發自動化工具：識别出攻擊過程中機械的部分，編寫一個工具去自動化模式的應用。此處的測試自動化不是自動地執行測試用例，而是提供計算機輔助功能，其目的是讓計算機完成高負荷運算，讓人專注于富有智力挑戰的任務。

　　按照james的方法實施軟體測試，測試團隊可以積累一批有益的模式和測試輔助工具。這可以幫助團隊更有效地測試現在和未來的項目。

　　問：探索式測試能用于測試自動化嗎？

　　答：本書第6章将讨論探索式測試與測試自動化。這裡簡單陳述一下筆者的觀點。

　　測試自動化可以大緻分為測試用例自動執行（automated test execution）和計算機輔助測試（computer-assisted testing）。

　　對于測試用例自動執行，探索式測試可以提供一批适合自動執行的測試用例。

　　對于計算機輔助測試，探索式測試要求人盡其才（自由發揮測試者的智能）和物盡其用（充分利用計算機的性能），利用計算機強大的計算能力去幫助測試人員完成測試使命。

　　許多複雜的測試自動化應該以探索式的風格來構造。對于困難的測試，應該先建構簡單的測試代碼，将其投入測試，利用測試回報來改進測試代碼。然 後，将改進後的測試代碼投入測試實踐，分析測試回報，再優化測試代碼。所謂探索式測試自動化，就是将學習、設計、實作、評估納入疊代開發，以逐漸提高測試 自動化和産品的品質。

　　問：探索式測試與靈活測試有何關系？

　　答：探索式測試在本質上是靈活的，且可以很好地應用于靈活項目。

　　2001年，17位軟體專家在美國猶他州雪鳥（snowbird）城集會，締結靈活聯盟，并發表靈活宣言。與會者之一brian marick具有深厚的測試背景，是以軟體測試社群對靈活宣言亦有貢獻。

　　靈活軟體開發宣言

　　我們一直在實踐中探尋更好的軟體開發方法，身體力行，同時也幫助他人。由此我們建立了如下價值觀：

　　個體和互動高于流程和工具

　　工作的軟體高于詳盡的文檔

　　客戶合作高于合同談判

　　響應變化高于遵循計劃

　　也就是說，盡管右項有其價值，我們更重視左項的價值。

　　語境驅動測試的基本原則“任何實踐的價值都取決于其語境”和“人，在一起工作的人，是項目語境中最重要的部分”，與靈活宣言的首條價值觀“個體 和互動高于流程和工具”不謀而合。高效的探索式測試不但需要優秀的測試人員，也要求測試人員、開發人員、客戶和項目關系人緊密協作、頻繁互動。

　　在思想層面，探索式測試要求測試人員不斷地研究産品，通過應對、激勵、擁抱變化來驅動對問題空間的積極探索。這不但符合靈活價值觀，也可以應用 于其他類型的測試項目。靈活測試專家lisa crispin和janet gregory指出：“靈活測試可以發生在靈活項目之外。例如探索式測試，無論它是否應用于靈活項目，其本質是靈活的。通過測試逐漸學習産品，并讓所學信 息指導測試實踐，這無疑符合靈活價值觀：工作的軟體和響應變化。”

　　在實踐層面，探索式測試是評價産品的面向業務測試的主要手段。在使用者故事和測試政策的指導下，測試人員會模拟真實使用者去測試系統。當一部分代碼 被簽入，一部分使用者故事被實作後，測試人員就會探索新的區域，并逐漸完善測試模型和測試政策。随着測試人員對産品的了解，探索式測試不但可以彌補自動化測 試的不足，還可以揭示出更有效的自動化測試區域，為自動化測試設計添磚加瓦。此外，探索式測試能夠發掘新情景（scenario），而這些情景往往會演變 成新的使用者故事，進而在需求層面提高産品品質。

　　從術語的曆史看，“探索式測試”（exploratory testing，cem kaner提出于1983年）的曆史比“靈活軟體開發”（agile software development，靈活宣言締結于2001年）更悠久。它們都是在描述已經長期存在但是沒有得到合适命名的思想及實踐：cem kaner用“探索式測試”來描述一種已經長期存在的測試思維，靈活宣言的締造者們用“靈活”來描述他們對軟體開發的共識。雖然這些思想來自不同的頭腦、 實踐和社群，但是它們擁有相似的核心，并可以互相借鑒與補充。

====================================分割線================================

最新内容請見作者的github頁：http://qaseven.github.io/