任何一個軟件公司發(fā)布的產品都有缺陷，所以軟件測試是產品開發(fā)過程中必不可少的一部分。經過長期的發(fā)展，軟件測試方法不斷完善，探索式測試方法也是其中的一種。本文將結合實際工作談談對探索式測試方法的理解。
探索式測試方法主要分為兩類：
局部探索式測試法針對測試人員在運行任何一個測試用例時所需要作出的細微決定；
全局探索式測試法針對測試人員在編制測試計劃和測試用例設計時所需要考慮的廣泛的戰(zhàn)略性問題。
一、局部探索式測試法
1 輸入：合法輸入、非法輸入
1）輸入篩選器
第一，開發(fā)是否正確的實現了該功能？
第二，是否可以繞過屏蔽器？或者當輸入值進入系統(tǒng)后還可以修改？
2）輸入檢查
測試時必須仔細閱讀每一條錯誤信息，檢查該信息是否寫錯了，錯誤信息還可以透漏開發(fā)編程時的一些想法。
3）異常處理
如果測試看到一個通用出錯信息，建議測試再反復測試同一段函數，繼續(xù)使用剛才引發(fā)異常的輸入數據，或稍微修改一下，看看會不會導致出錯。嘗試運行其他一些要調用該函數的測試用例，看看會發(fā)生什么情況。
4）常規(guī)輸入和非常規(guī)輸入
和Ctrl、Alt、Esc按鍵組合的字符，操作系統(tǒng)、編程語言、瀏覽器和運行時環(huán)境的特定保留詞或按鍵。
5）使用輸出來指導輸入選擇
①首先確定希望程序產生的輸出結果，然后考察所有用戶場景，來確定輸入；
②先觀察輸出結果，再選擇新的輸入，使新的輸出為重新計算后的結果。
2 狀態(tài)
軟件的一個狀態(tài)就是狀態(tài)空間中的一個點，它由所有內部數據結構的取值來唯一確定。
①使用狀態(tài)信息來幫助尋找相關的輸入，如果兩個或更多個輸入在某種程度上關聯，那么它們應該放在一起測；
②使用狀態(tài)信息來辨識重要的輸入序列，當一個輸入導致狀態(tài)信息被更新時，緊接著再多次使用同樣的輸入會導致一連串的狀態(tài)變化。
對數據庫中的表進行多次更新，查看數據是否會溢出。
3 代碼路徑
測試需明確知道代碼的所有選擇結構，并理解哪些輸入會導致軟件走這條分支而不走另一條。
4 用戶數據
①如何模仿真實的用戶數據
②使用真實的用戶數據時，應考慮如何解決“隱私問題”。
5 執(zhí)行環(huán)境
是指測試使用的操作系統(tǒng)及其當前的配置，還包括運行在同一操作系統(tǒng)上會和被測試軟件進行交互的其他一些應用程序，以及會間接或直接影響被測試軟件本身或影響被測試軟件運行的任何驅動程序、代碼、文件、設置等，還包括軟件當前連接的網絡情況、網絡的可用帶寬、性能等。
二、全局探索式測試法（漫游測試）
在軟件測試中，我們可以把整個測試過程比喻成游客在城市中旅游的過程，測試類型對應城市中的不同區(qū)域，針對每個區(qū)域制定不同的游覽路線。以下將結合實際測試過程中的案例，來簡單闡述全局探索式測試法的應用。
1 商業(yè)區(qū)測試類型（軟件的重要功能模塊）
1）指南測試法：
測試嚴格遵照用戶手冊的建議執(zhí)行操作。在測試一個全新的軟件之前，測試人員需要詳細閱讀需求文檔或使用手冊，積極與開發(fā)人員溝通以充分了解產品功能；在測試產品的新版本之前，查看jira中的新特性描述、新的需求文檔以及之前版本存在bug的用例。
2）地標測試法：
通過指南測試法確定關鍵的軟件特性（地標），再確定地標的前后順序，然后從一個地標執(zhí)行到另一個地標來探索應用程序，直到訪問了所有的地標。在這個過程中，需要記錄已經使用過哪些地標。
在BC-ETL的某次測試過程中，需要測試數據流中的多個流程，此時每個流程都作為一個地標，通過多次調換、添加或刪除流程的來測試整個數據流能否順利執(zhí)行。
3）極限測試法
也稱找麻煩測試法，即故意設置各種障礙來觀察軟件如何反應。
在羅網項目某次迭代中，測試基站查詢模塊，選擇使用基站名稱查詢，在搜索框中輸入覆蓋范圍很大的區(qū)域名稱（如：南通）進行查詢，頁面因加載時間過長導致卡死。
4）深夜測試法
當下班之后軟件執(zhí)行各種維護任務，將數據歸檔，備份文件等，程序不自動執(zhí)行的時候，測試人員強制程序執(zhí)行。
2 歷史區(qū)測試類型
指遺留的代碼，或是在前幾個版本就已經存在的軟件特性，也指那些用于修復已知bug的代碼。
1）惡鄰測試法
某個區(qū)域代碼bug很多，建議對鄰近區(qū)域進行詳細的測試，以此來驗證那些修復已知bug的代碼沒有引入新的缺陷。
2）博物館測試法
找出遺留代碼和老的可執(zhí)行文件，并確保它們在測試中受到和新代碼同樣的待遇。在實際測試過程中，可以理解為對新版本中沒有改動的功能進行回歸冒煙測試。
在羅網項目的某次回歸冒煙測試中，測試研判模型的多案時空碰撞模塊，正確創(chuàng)建分析任務，在任務列表中查看分析結果，頁面右上角提示出錯，無法查看。
3 娛樂區(qū)測試類型（輔助特性）
1）配角測試法
鼓勵測試專注于某些特定功能，特別是緊鄰主要功能的輔助功能。
羅網項目的主要功能為通過研判模型對各類案件及人員進行分析，然而每次審批幾乎都離不開新建工單的過程，所以測試時對研判模型的每個模塊都增加了許多新建工單的用例。
2）通宵測試法
即使程序長時間運行，不去關閉，觀察程序是否會發(fā)生異常。
4 旅游區(qū)測試類型（快速訪問軟件的各種功能）
1）收藏家測試法
收集軟件的輸出，越多越好。確保能觀察到軟件能生成的任何一個輸出。此方法龐大，通常以小組為單位進行。
在廣西上網行為分析項目中，為確保接收到的數據格式和內容都正確，需提前造出大量用戶數據，模擬實際的運行環(huán)境批量發(fā)送數據，批量查看輸出結果。
2）超模測試法
在采購部供應鏈大數據平臺的某次測試中，由于前端頁面沒有設置按比例縮放，導致頁面在小屏幕上無法顯示完全。
5 旅館區(qū)測試類型（經常被忽略或者在測試計劃中較少描述的次要及輔助功能）
1）取消測試法
啟動操作然后停止它。可以對任何提供取消功能或者需要較長時間才能完成的功能做同樣的操作。如果沒有取消按鈕，對于在瀏覽器中運行的程序可以試著按Esc鍵或是程序中的回退按鈕。
2）懶漢測試法
測試人員做盡量少的實際工作。接受所有默認值，保持輸入字段繼續(xù)為空，在表單中盡可能少填數據，在進入下一個界面時不點擊任何按鈕或者輸入任何數據等等。
傳統(tǒng)的手工測試方法需要提前編寫測試用例，然后嚴格地依次執(zhí)行每一個用例，引入探索式測試方法可以在測試過程中更及時地發(fā)現問題并補充用例，兩種方法相結合才能更有效地把控產品的質量。
如果未來開發(fā)技術大幅進步，也許會有一天，測試人員不再是必需的了。這當然是軟件廠商和用戶的福音，但是在可預見的未來，檢測軟件缺陷的最好方法還是使用測試技術，而不是開發(fā)技術。原因很簡單，太多的不確定因素，太多的場景，可能導致自動化測試失效的情況太多了，無法一一跟蹤。這一切都需要“人腦”的介入，現在如此，下個十年不會變，再過幾十年可以依然如此。
作者介紹
孫小霞 中國移動蘇州研發(fā)中心 大數據產品部 技術總監(jiān)
王均 中國移動蘇州研發(fā)中心 大數據產品部 測試工程師
周煜澄 中國移動蘇州研發(fā)中心 大數據產品部 測試工程師
