Exploratory Testing

參考網址:探索式测试中的几种误区

參考網址:探索性测试

感覺探索測試主要可以讓測試人員更瞭解待測產品,同時將這些學習到的新東西注入到測試上面,所以他有提到探索測試是將『學習』『探索』『測試』一起進行,也可以讓每個測試人員進行完探索測試後提出討論,在激發彼此更多的想法。裡面有提到說以往我們根據測試步驟去做測試是比較被動,但是探索測試主要是讓測試人員更有想法,更主動。所以也許等我們之後比較完整後,可以來試試探索測試,才能比較瞭解所謂探索測試的觀念。

參考網址:Exploratory testing – where do its pitfalls lie?

這篇文章主要再講一些探索測試有可能的缺陷,所以我們在進行探索測試時,還是必須有規劃性的,也必須去記錄說 測了哪些東西,發現哪些問題,哪些東西是原先的測試沒有加入的。文章也提到說不能對探索測試有太大的期望,認為它是無所不能的,應該是要將原本的手工測試,或是一些其他的測試再結合探索測試,也就是其實不可能只是使用單一測試就想要保證待測軟體沒有問題,應該是結合不同的方法去測試軟體。

參考網址:How to get started with Exploratory Testing

這篇文章主要在說要怎麼開始進行探索測試,首先要先去討論說系統哪個部分需要去探索,或是主要需要著重在哪個部分,然後在測試的過程中要保持記錄,可以讓我們之後知道那邊已經測試過,或是發現哪些問題。最後提到了個重點就是,探索測試是你打算要去測試什麼,但與傳統的測試不同是,不會去說明詳細步驟,或是操作過程。

參考網址:What is Exploratory Testing?

這篇文章提到說,探索測試有別於以往的腳本測試,它是一邊設計測試一邊執行測試,可以與腳本測試互相平衡,互相輔助,而不有衝突。最後提到說,探索測試可以讓測試人員對於被測產品有更多新的見解。

參考網址:Let’s explore – Exploratory Testing!

這篇文章除了稍微比較了腳本測試跟探索測試的不同外,也提到了探索測試準備的五個步驟。
1. Create a Bug Taxonomy
2. Test Charter
3. Time Box
4. Review Results
5. Debriefing
並且比較了探索測試的優缺點,還有挑戰。

參考網址:探索式测试:基本概念

文章提到說,探索測試主要就是將設計測試案例,執行測試,分析測試結果,是一個循環快速的迭代,不斷地收集回饋再來調整測試案例。感覺探索測試主要就是讓我們先假設,然後去執行,看假設是否正確,不斷的思考,然後透過執行結果再來重新思考下一步。

參考網址:Exploratory Testing

探索測試比起以往的腳本測試可以減少測試案例的準備,也可以增加測試人員的思考,適合用在當一個新功能或是新產品推出時,或是想要快速瞭解待測軟體時。不過進行探索測試時,除了一邊設計測試案例一邊進行測試外,也要記錄自己的猜測,執行結果等,這樣之後才能重新審視問題。

參考網址:Finding more defects with Agile exploratory testing

探索測試除了可以讓我們更瞭解關於我們自己本身軟體的一些相關功能外,也可以讓我們去找到一些自動化測試不容易找到的問題,因為自動化測試有時候比較難去檢測到一些較複雜的場景。在進行 CPL 的探索測試中,除了照既有的步驟外,延伸出很多其它想法,「如果換一種方式或是另外一種情況下,狀況是否一樣?還是會有不同的行為?或著是原本我們預期為如何,結果出來卻不符合」。所以探索測試可以讓我們透過每個人思考不同,而去做更多的測試。

參考網址:认清探索性测试

文中提探索測試是根據上一步測試會影響到下一步測試,透過這種上下文的方式,將範圍越來越小,越靠近核心。另外也提到,探索測試與腳本測試不是只能都一使用,是可以先以腳本測試為主,探索測試為輔,來確保軟體質量。

參考網址:Where Does Exploratory Testing Fit?

文中提到說,探索測試在測試的初期可以用來瞭解產品,然後再去編寫測試案例,在測試中期使用探索測試,則可以增加測試腳本所沒有涵蓋到的範圍,更深入去探索一些比較複雜,或是風險比較高的部分,然後可以更多樣化的去測試你的產品。

參考網址:软件探索性测试方法

裡面提到說, ST 像是已經準備好演講稿準備去演講,ET 比較像是一種對話,沒有準備好該怎麼去說明。也提到說單一使用 ST 或是 ET 都太過極端,最好的方法就是介於中間。這幾天在嘗試著用 ET 時覺得其實當下的記錄很重要,因為 ET 沒有特定的步驟,所以當下發現問題就要立刻將步驟與情況記錄下來,才能讓事後較為容易追蹤與理解。

參考網址:Introduction to Exploratory Testing

探索測試的過程中,除了可以讓我們越來越瞭解我們的產品外,也會思考有哪些可能會造成我們測試失敗。如果當測試人員以既有的腳本測試沒有在發現任何的 bug ,維持相同的覆蓋率時,我們也可以透過探索測試來幫助自己有更多的靈感,從既有的腳本測試來延伸我們的探索測試。另外也提到像我們昨天討論的,當修正一個 bug 後,用原本相同的方式如果發現 bug 已經解決了,測試人員可以在嘗試另外一種方式看看是否能夠再次找出問題,這也是探索測試的一種。

參考網址:神奇的曲线:探索式测试与基于脚本的测试之关系

ST 與 ET 是相輔相成的,可以讓我們的測試更完整。如果一開始自動化測試不夠完整,或是沒有自動化測試,則在前期可以大量使用探索測試去了解產品,後期就專注在開發腳本去穩固回歸測試。同樣的,如果自動化水平夠高,前期開發完腳本後,後期就可以投入 ET,讓測試人員有更多的想法。

參考網址:Exploratory Testing on Chat

文中提到說,如果探索測試只是單靠直覺去做的話,這樣很容易沒有測到產品的某部分,所以在測試之前還是要擬定測試策略,與測試計畫,像是先以那部份開始測試,並且將不同的部分分給不同的人去做探索測試,但是不會去擬定更多的細節。最後透過報告來繼續追之前遇到的問題,或是透過這份報告來調整下一次的探索測試。

參考網址:Exploratory testing: Misunderstood concepts and common challenges addressed

文章中也提到什麼時我們可能需要開始做探索測試,像是某個區域可能特別需要品質特別好,或是一個新功能開始時。我們除了可以透過探索測試更了解產品的功能外,也可以透過探索測試配對 , 彼此互相分享彼此想法,腦力激盪 。所以像現在兩個人一起做探索測試時,有時候另外一個人也會提出說,那如果我們怎樣怎樣會不會也會容易有問題,可以讓我們思考到更多的範圍。

 

廣告

發表迴響

Please log in using one of these methods to post your comment:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s