您好,登錄后才能下訂單哦!
“任何足夠先進的技術,看上去都與魔法無異”,出自英國著名未來學家亞瑟 克拉克,他曾于出版了經典科幻小說《2001天空漫游》。
探索式測試(Exploratory Testing,也稱探索性測試)是一種軟件測試方法,最先是Cem Kaner 在1983年提出的。這是一種強調個人自由與責任的測試方法,讓獨立測試人員可以借用不斷的學習來改善測試的規劃與測試的執行,而在測試的過程中也會同時改善測試案例達到相輔相成的效果。在Nortel和微軟的很多項目中,都采用了這一新穎、有趣和富有創意的測試方法。探索式軟件測試的實踐者,軟件測試大師James Whittaker在其新作《探索式軟件測試》中,對此方法進行了全面的演繹和創新,呈現了微軟內部使用此方法的心得體會。
此方法在很早的時候已經被提出,在我國有很多人也開始學習和研究,但用于企業的卻很少,最近一段時間發現此方法漸漸地被人們所接受,不管你是去聽分享會或者沙龍等都有所哦涉及,那我們就來了解了解吧。
根據度娘告知:探索性測試可以說是一種測試思維技術。它沒有很多實際的測試方法、技術和工具,但是卻是所有測試人員都應該掌握的一種測試思維方式。探索性強調測試人員的主觀能動性,拋棄繁雜的測試計劃和測試用例設計過程,強調在碰到問題時及時改變測試策略。
頂測認為探索式測試就是采用新的測試思路,邊學習、邊設計、邊測試、邊思考。
一、探索性測試的基本過程
a.探索性測試識別軟件系統的目的;
b.識別軟件系統提供的功能;
c.識別軟件系統潛在的不穩定的區域;
d.在探索軟件系統的過程中記錄關于軟件的信息和問題;
二、探索式軟件測試類型
a.自由式探索式測試;
b.基于場景的探索式測試;
c.基于策略的探索式測試;
d.基于反饋的探索式測試;
三、探索式測試的目的
a.需要快速學習一款產品;
b.需要尋求多樣化的測試;
c.在進行腳本測試后,還想要進行多樣化的測試;
d.想要在最短的時間內發現最多嚴重的bug;
e.想要檢查一個測試人員的工作;
四、探索式測試的條件
a.項目要求;
b.產品穩定;
c.產品重要;
d.測試員要求;
e.有激情感興趣;
f.掌握探索式測試理論和方法;
五、what情況或者what時間使用探索式測試
我們所進行的軟件測試通過幾輪之后,基本功能相對穩定,根據Test Requirement(測試需求)編寫Test Case(測試用例),在過程中必然會出現難以發現的部分問題,測試人員需轉換相關思路,補充更多的測試細節。
六、如何進行探索式測試
a.看 PRD(Product requirements document,產品需求文檔) 和原型等各種可提供的文檔;
b.確定核心功能模塊;
c.與項目組測試人員溝通,確定bug最多風險最大的模塊;
d.制定探索式計劃: 測程數、每個測程的任務、每個測程的時間;
e.根據計劃執行;
f.根據計劃,邊學習、邊設計、邊測試、邊思考;根據具體情況隨時修改測試策略;
g.發送缺陷報告;
七、測試結果總結
a.閱讀需求文檔,確定核心模塊;
b.查看bug管理系統或與測試人員溝通,確定問題較多的模塊;
c.根據需求,探索核心模塊的功能;
d.根據啟發式測試策略模型和漫游測試模型挑選補充測試策略進行測試;
e.根據計劃,邊學習、邊設計、邊測試、邊思考;根據具體情況隨時修改測試策略;
八、存在的誤區
誤區1:探索式測試是一種測試技術。
探索式測試作為一種方法,可以運用于任何用例測試中,如單元測試、功能測試、性能測試、系統測試等等,只要有探索性的思想并貫徹于實踐中,探索式測試就會發揮它的重要作用,找到用例測試沒有涵蓋的危險區域。
誤區2:探索式測試是一種黑盒測試。
探索式測試提倡的原則之一就是“努力深入了解待測產品”。伴隨著對產品的了解越來越深入,探索式測試會逐步發現更多的隱藏的潛在風險,通常情況下在白盒狀態下的探索式測試更具價值,因為其成果都是建立在堅實的知識和理解基礎上,其指向更有針對性。
誤區3:探索式測試就是隨機測試。
探索式測試會存在文字記錄,會做覆蓋率分析,比隨機測試更為有序和可控。
誤區4:探索式測試階段在用例測試之后。
探索式測試應用于測試的各個階段,盡可能最大化它的價值。
誤區5:探索式測試需要老手來做。
敏捷測試專家Lisa Crispin總結了必要的技能:
小心的觀察者:觀察不正常和不期望的結果,并對正確性的假定很小心,能夠細微的觀察軟件特征或模式。
認真的思考者:在運行中檢查測試并將其改到非預期的方向上,能夠解釋尋找缺陷的邏輯并提供清晰的測試狀態。
系統的叛逆者:思維嚴密、系統化,同時還要具有多樣化的觀點。
資源的挖掘者:探索測試人員應該發掘更多他們可以使用的工具、技術、測試數據、朋友和信息源。
探索性測試在游戲中應用也是有指導性的意義。連續多次使用探索性測試可以將你的對應方法的測試思維熟練化;同一種思路發現的方法在測試類似功能的時候很容易借鑒。
最近一次參加的測試沙龍中,有一位老師這么比喻的:ST 相當于跟團游,ET相當于叢林探險。
通過資料的整理,相信大家也比較明確了。
Smpidus發表一下個人觀點:
1.學習能力弱的新手,無法第一時間達到需求所要求結果,但就因為他們過于簡單的思路卻讓我們更看清了本質。(唉,分明在說我,我就是這一類的)
2.學習能力強的新手,通過新鮮的事物更好地去發掘。
3.經驗豐富的老手,將原有的事物更細化、更完善。
衡量一個人是否適合使用ST,是用我們的技能去探索的,而不是新手還是老手。處于產品比較穩定,進一步作出補充,覆蓋系統測試所不及的場景。
既然我們從事于某個行業,就沒有適不適合一說,而是我們應該站在什么角度去考慮問題。整理的不是很完善,希望大家可以提出不足和自己的觀點。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。