【測試理論】如何作好探索性測試—基礎篇

前不久國慶檔上映的一部電影《爬山者》，相信你們都已經看過了，在劇中，中國爬山隊那種不畏困難，敢於探索未知領域的精神着實讓人敬佩，特別是最後一刻吳京飾演的方五洲帶領隊員，終於再次登頂。若是單純的從事務的本質來看，探索未知區域（好比爬山探險）和探索軟件有很是多的共通點：

• 有無數的驚喜和奇遇在等着你(好比發現驚天大bug)
• 探索中，你能夠藉助於工具。
• 探索有時候是歡樂之旅，有時候卻艱苦跋涉，有時候你則是如履薄冰（不少時候，驚喜的bug老是在上線後才暴露出來）。
• 若手上的地圖和探索的未知區域不符時，應該相信未知地域（要相信本身發現的問題）。

順着這個思路，計劃寫三篇關於探索性測試的文章（理論篇、深刻篇、情景實踐篇），在寫文章的過程當中，參考Elisabeth Hendrickson的一本書《探索吧，深刻理解探索式軟件測試》。文章理論知識偏多，因此看上去會比較枯燥，不過我會在文中加一些小案例，方便你們理解，如今讓咱們一塊兒進入探索測試的世界吧。

常規測試和探索性測試的關係

所謂的常規測試，指的是咱們常規思路的測試：儘量的寫測試用例、依照測試用例執行測試。而探索性測試指的是針對要測試的產品，選定一個模塊/方面，選擇不少可能變化的點（變量），而後深刻進去，挖掘潛在的問題，舉個例子：不少產品都有保存圖片或文件的需求，這就牽扯到保存文件的路徑，這裏文件路徑就是個變量，咱們基於文件路徑這一因素，能夠提出不少可探索的點：

• 選擇的文件路徑沒有權限。
• 選擇的文件路徑下有相同的文件。
• 文件路徑所在磁盤空間，是否夠用。

我以爲全部的軟件測試工程師，都有這樣的經歷，不管本身的測試用例寫的多麼完善，只要產品上線，就會有大大的驚喜在等待你。那是否是常規測試就不重要呢？換句話說，咱們是否是應該更多的進行探索性測試來替代常規測試。其實否則，常規測試和探索性測試是相輔相成的關係，以下圖所示：

常規測試就如同上圖中的網，而探索性測試則要覆蓋網沒法覆蓋的區域（也就是網格），二者只有所有兼顧到，才能保證產品的質量。一個完善的測試策略應該能融合兩種方式作到兼容幷包：已測試=已檢查+已探索。

探索性測試策略

與寫測試用例同樣，探索性測試也有對應的設計模板（姑且稱之爲探索性測試用例模板吧），其實寫測試用例的思想（好比邊界值、等價類）徹底適用於探索性測試。可是須要注意的是，探索性測試的用例不會像通常測試用例那樣具體，咱們下面經過例子再來詳細說明，一般來說探索性測試的設計包含下面三要素：

• 目標：你要探索何處？它多是一個特性，一個需求或一個模板。
• 資源：有什麼資源是你能夠用的？某個工具、數據集、技術、配置等。
• 信息：你但願找到什麼有用的信息/結果？能夠說明系統的安全性、性能、穩定性等。

優質的探索性測試策略

先來看一個比較差的探索性測試策略：

目標：探索編輯姓名
資源：使用輸入值 「xuan‘ke」
信息：爲了發現【編輯姓名的功能】是否能處理名稱裏包含’的狀況
複製代碼

你們對上面的策略熟悉嗎？其實這就是一個比較具體的測試用例，只不過換了一種形式。接下來咱們再來看一個比較正常的探索性測試策略：

目標：探索瀏覽器輸入的地址
資源：使用javascript和sql注入式攻擊
信息：爲了發現系統的安全弱點信息
複製代碼

能夠看到上面的測試策略並無說明，須要具體使用什麼javascript腳本或者什麼sql語句注入，而是提供了某一個方向或者靈感，剩下的工做須要你本身去探索和嘗試。

工做中應該如何挖掘探索性測試的點

爲了你們能找到有價值的探索性測試點，這裏幫你們概括幾個能夠尋找測試點的思路。

需求評審

需求評審是挖掘探索性測試點的理想時機，下面舉個例子（例子中人員角色：Alex是軟件測試工程師、Pat是開發工程師、Binh是業務分析師）：

Alex針對上面的對話狀況，制定了以下的測試策略：

目標：探索編輯檔案
資源：使用非法用戶名
信息：爲了發現用戶名限制規則未被觸發的狀況
複製代碼

因此以後的需求評審中，咱們又多了一件能夠作的事情，能夠嘗試去發現針對產品可探索性測試的點。

隱性期待

產品經理和開發工程師思考問題的角度是不同的，因此必然會存在這樣的情況：每一個人從本身的角度考慮，以爲某些事情或需求點太簡單了，不須要再提。但每每是這些隱性期待，形成了溝通障礙，等到最終產品將要上線時，才發現你們對需求的理解都不同。

舉個例子，好比：在開發某一款app時，產品經理指望能打開app就使用某個特別高大上的功能，它的隱性期待是加這個功能不會影響app的啓動速度、包的大小等。可是等到開發完成時發現加上這個功能後，app啓動速度慢了將近10s，這顯然是不可以接受的。雖然產品經理需求文檔中並未說起對app的啓動速度影響，可是你得嘗試發現這些值得探索的隱性期待，將它們加入咱們探索測試的策略中。

有意義的變量

在一個軟件/系統中，會存在不少變量，而這些變量是能夠做爲咱們探索的點，下面列出須要注意的變量：

• 可計數的東西：這個很好理解，好比：用戶登陸次數、操做次數、存儲文件的數量等，一般能夠用一些特別的數字做爲探索點：0，1，多，過多，過少。
• 相對位置：位置有「開頭—中間—結尾」的緯度，好比：在一個列表中，操做最後一條可能有問題、操做中間某一條和操做第一條都不會有問題。
• 文件和存儲：文件存儲牽扯到了路徑，好比：將你的某個文件保存到不一樣的目錄（權限問題等）就可能會出現問題。
• 地理位置：地理位置包含一些邏輯上的位置，好比：時區、海拔、郵政編碼等。
• 格式：在程序中的不少東西都有格式，好比：日期、郵寄地址、文件路徑、URL、文件內容、信息等等。而這些格式均可以被改變，來進行探索。
• 大小：在程序中文件是有大小的，好比：圖片、配置文件、上傳的各類文件。
• 深度：在程序中任何帶有層級的東西都有深度，比較常見的有XML配置文件、帶括號的運算操做、程序中的循環。
• 時間點、頻率和持續時間：在程序中頻率和持續時間，是比較容易發現問題的變量因素，好比：你用monkey對某個app作穩定性壓力測試、快速的滑動某個頁面有可能形成crash，或者你能夠試試，讓你的程序運行一夜或者更長時間來驗證問題。
• 輸入和導航: 好比：你在輸入的時候能夠複製粘貼，也能夠直接輸入；在關閉彈窗時，你能夠點擊屏幕上的按鈕，也可使用快捷鍵，這些都是變量。

上面提到的這麼多變量，你能夠結合本身的產品特性來選擇變量做爲本身探索測試的策略。

源代碼

若是你尚未源代碼的權限，必定要問開發要一個「測試」的代碼權限。看代碼的註釋是特別歡樂的事情，而這些註釋也能幫咱們發現探索測試點，好比如下注釋：

• 我也不知道爲何這麼作行得通，可是它就是能夠了，千萬別動它。
• 也不知道哪一個龜兒子寫的代碼，看不懂，修改了下，先用着吧。
• 這是xxx領導讓加的定製化需求。

若是看到代碼中有相似的註釋，那麼說不定這就是值得咱們探索的點。

用戶反饋

無論咱們再怎麼努力的測試，軟件到用戶手上，仍是會出現各類各樣的問題，緣由不少：軟件安裝的環境不一樣、用戶的操做和使用習慣千差萬別、軟件運行的環境（好比網絡情況）不一樣。因此多查看用戶反饋的平臺，也能夠幫咱們挖掘出探索測試的點，將他們記錄下來。

目標一致性

上面提到了幾種探索性測試策略的發現的點，可是也須要注意，你找到的可探索測試的點，須要和開發工程師、產品經理保持目標一致，不然會浪費你的時間。舉個例子：你將切換程序所在的時區做爲一個探索點，花費大量時間在驗證切換時區以後的影響，可是最後產品經理告訴你，咱們的程序只可能在中國使用。

因此在需求評審時、或者常規的用例評審時，能夠將制定的探索性測試策略拿出來，和你們同步下，從而讓你們對測試策略的認知達成一致，同時你也能夠豐富本身的探索性測試策略。

總結

本文主要介紹了探索性測試的基礎內容，能夠幫你初步的瞭解到探索性測試是怎麼設計的。其實我以爲在平時的測試工做中，你們已經有意無心的在用探索性測試的理論了，只是目前仍是以常規的測試爲主，尚未達到和探索性測試相輔相成的效果。但願我能經過【如何作好探索性測試】的這三篇文章，幫助你們優化本身的測試知識體系，同時對我本身來講也是個升級。下一篇文章會更深刻的來認識探索性測試。