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