探索式測試-江政為

StoneJiangExploratoryTesting

Agenda三種測試方法介紹產(chǎn)品質(zhì)量現(xiàn)狀探索式測試局部探索式測試全局探索式測試探索式測試與基與用例的ScriptedTesting探索式測試的適用時機探索式測試的優(yōu)缺點總結(jié)2金句良言寫出沒有錯誤的程序有兩種途徑，可惜只有第三種才有用。

--艾倫.佩利（AlanJ.Perlis）

用戶購買功能的同時也在忍受缺陷。

--史考特-沃茲沃思（ScottWadsworth）客戶流失是有缺陷軟件的最主要的負面效應(yīng)。

--詹姆斯.惠特克（JamesA.Whittaker）

SeeingisnotBelieving,TestingisBelieving。

--無名氏

生命不息，測試不止。

--無名氏3手工測試ManualTesting優(yōu)點手腦并用，設(shè)計出符合軟件設(shè)計效果的真實場景。復(fù)雜的業(yè)務(wù)邏輯相關(guān)的缺陷，手工測試是最理想的選擇。發(fā)揮測試人員的主觀能動積極性。缺點慢，對于復(fù)雜系統(tǒng)，需要大量人力和時間成本。不能反復(fù)使用。發(fā)現(xiàn)問題有時候很難重現(xiàn)，不能移植。4自動化測試AutomaticTesting優(yōu)點提高測試效率，縮短測試的時間。能及時發(fā)現(xiàn)比較極端的問題，比如程序崩潰（Crash），死機（Hang）突發(fā)異常（Exception）?？梢詧?zhí)行一些手工測試難以模擬的多用戶，多文件等比較困難或者不可能進行的測試。缺點版本經(jīng)常迭代，自動化代碼需要經(jīng)常維護。業(yè)務(wù)邏輯極強的缺陷往往發(fā)現(xiàn)不了。測試腳本本身有存在一些缺陷，往往導(dǎo)致新的問題。5即興測試Ad-hocTesting特點臨時準備的，隨機性太強。

針對一些重要功能的重復(fù)測試。

嚴重依賴測試人員的經(jīng)驗，需要由具有豐富測試經(jīng)驗進行。

一般在軟件上線前期進行。

Ad-hoc測試應(yīng)該嚴格控制，做有計劃的測試。

6產(chǎn)品質(zhì)量現(xiàn)狀無論使用手工測試，自動化測試，Ad-hocTesting，還是其他的測試手段，也無論自動化程度多高，即使是全部都自動化，上線后的產(chǎn)品中依舊存在不少缺陷（業(yè)務(wù)邏輯上的+性能+UI等等），從而有可能導(dǎo)致客戶滿意度下降，甚至客戶流失。作為專業(yè)的測試人員，我們需要從測試的角度盡可能把缺陷排除在軟件測試開發(fā)周期之外，以便減少錯誤并提高軟件質(zhì)量，持續(xù)改進。7什么是探索式測試同時設(shè)計測試和執(zhí)行測試Scientific,Real-timeConsideration強調(diào)個人自由與責(zé)任的一種測試方法。測試結(jié)果、測試實例和測試文檔都會在運行時創(chuàng)建。（截屏等）讓人腦不受各種條條框框約束，發(fā)揮智慧，把精力完全集中在發(fā)現(xiàn)缺陷和驗證軟件功能上。探索式測試最適用于使用“敏捷開發(fā)（Agile）”的web應(yīng)用程序上。這種程序開發(fā)周期短，功能變化快。8探索式測試目的理解應(yīng)用程序工作，他的接口看起來怎樣，它實現(xiàn)了那些功能

強迫軟件展示其全部能力。

找到缺陷探索應(yīng)用程序各種復(fù)雜情況，發(fā)現(xiàn)潛在問題。探索性測試人員不應(yīng)該只是簡單地發(fā)現(xiàn)缺陷，而應(yīng)該有目的地降低缺陷數(shù)量。

9探索式測試之局部探索式測試當(dāng)一個測試人員面對一個網(wǎng)頁、一個對話框等，他往往需要一些很明確的建議指導(dǎo)他如何進行處理這種狀況，問題是在需要面臨一系列這樣“小”的決定的時候，往往不知所措。針對測試人員運行測試用例需要做出很多細微的戰(zhàn)術(shù)層面決定，局部探索式測試方法提高有效的指導(dǎo)意見。局部探索式測試試圖把制定計劃，進行測試，重新修訂計劃等多個過程有機結(jié)合在一起，幫助測試人員合理高效完成決定，提升軟件測試效率，提高軟件質(zhì)量。10局部探索性測試測試人員各種“決定”起決于應(yīng)用程序的5個屬性用戶輸入input狀態(tài)state代碼路徑codepath用戶數(shù)據(jù)userdata執(zhí)行環(huán)境executionenvironment11局部探索性測試-用戶輸入Input用戶輸入會執(zhí)行四項基本任務(wù)接受輸入、產(chǎn)生輸出、存儲數(shù)據(jù)和進行運算。合法輸入和非法輸入，通常非法輸入，會有一段錯誤處理（error-handling）。三種方式定義錯誤處理輸入篩選器--非法輸入值擋在應(yīng)用程序之外。比如某面板只能接受正整數(shù)，比如下拉列表框功能是否實現(xiàn)，非法值不能歸類合法值，合法輸入不能歸于非法能不能繞過屏蔽器，比如鐵路訂票網(wǎng)站可以選上中下鋪，檢查輸入--通常會通過類似IF、THEN、ELSE結(jié)構(gòu)語句（或者CASE、SELECT或者查找表）來實現(xiàn)。非法產(chǎn)生錯誤消息并中止運行。仔細閱讀每一條錯誤信息，從錯誤消息中獲取導(dǎo)致應(yīng)用軟件失效的種種條件使用異常--把整個例程當(dāng)做一個整體開發(fā)，檢測每一個發(fā)生的錯誤。如果測試發(fā)現(xiàn)空泛的信息，通常我們需要反復(fù)測試同一個函數(shù)，稍加修改剛剛使用的數(shù)據(jù)，測試軟件失效情況。12局部探索性測試-用戶輸入Input常規(guī)輸入還是非常規(guī)輸入特殊語言字符，國家化語言測試（安裝語言包和字體等）特殊平臺字符，windows設(shè)備名COM1，AUX等計算機鍵盤上的CtrlAltEsc默認輸入還是用戶提供的輸入空白值的處理默認值的測試，默認值本身是否合理，默認值關(guān)聯(lián)功能是否正確實現(xiàn)。比如默認顯示過去1到18月數(shù)據(jù)，打印是否也是同樣的數(shù)據(jù)。。使用輸出來指導(dǎo)輸入選擇明確自己希望軟件產(chǎn)生的預(yù)期結(jié)果，然后選擇哪些輸入會引發(fā)相應(yīng)的輸出，在測試中使用這些值。觀察輸出結(jié)果，在選擇新的輸入和輸出。在CC2中我們要經(jīng)常使用mofidy來判斷系統(tǒng)功能實現(xiàn)的完整性。13局部探索性測試-狀態(tài)（State）軟件接受到輸入，內(nèi)部存儲后，軟件狀態(tài)會發(fā)生改變。

狀態(tài)可以是臨時的temporary，程序終止，狀態(tài)被忘卻了。比如導(dǎo)入結(jié)構(gòu)錯誤的文件。

狀態(tài)也可以長期保存（Persistent），存儲在數(shù)據(jù)庫里或者某一個文件內(nèi)，程序?qū)磉\行的時候可以存取這個值。

輸入和狀態(tài)之間的關(guān)系相當(dāng)關(guān)鍵，是測試的一個難點。使用狀態(tài)信息來幫助尋找相關(guān)的輸入，相關(guān)聯(lián)的組合放在一起測試，以確保所有重要的情況和變化都有被測試到。例如折扣卷不能用于打折的商品。

使用狀態(tài)信息來辨識重要的輸入序列。當(dāng)輸入一個導(dǎo)致狀態(tài)信息被更新時，多次使用相同的輸入會導(dǎo)致一連串的變化。比如連續(xù)打印局部探索性測試-代碼路徑程序會根據(jù)代碼規(guī)定的邏輯一行又一行的執(zhí)行下去測試人員需要知道程序里可能有哪些分支，理解哪些輸入會導(dǎo)致軟件走這一個分支而不是另一條。循環(huán)語句導(dǎo)致代碼路徑的總數(shù)變得無窮大，通常循環(huán)條件的取值跟用戶輸入相關(guān)。比如用戶網(wǎng)購，用戶決定終止向購物車添加新的商品，當(dāng)前代碼離開購物的循環(huán)，進入結(jié)賬的代碼。15局部探索性測試-用戶數(shù)據(jù)（UserData）模擬軟件真實用戶的數(shù)據(jù)出乎意料的困難真實用戶數(shù)據(jù)庫中數(shù)據(jù)都是不斷更新，常年累月積累下來的。測試在有限的時間內(nèi)制造大量的數(shù)據(jù)。真實用戶的數(shù)據(jù)可能還包含測試人員不了解的關(guān)系和結(jié)構(gòu)，有些數(shù)據(jù)在測試環(huán)境正常，換到真實用戶數(shù)據(jù)，軟件就會失效。測試人員同樣要關(guān)注PII(Personalidentifiableinformation)，謹慎處理真實用戶的敏感數(shù)據(jù)。16局部探索性測試-執(zhí)行環(huán)境（ExecutionEnvironment）環(huán)境本身就是一種輸入，同樣的測試用例在PC1上很好，換一臺PC就沒法正常運行。測試人員在產(chǎn)品發(fā)布之前必須盡量嘗試各種各樣的測試環(huán)境。CC2目前有瀏覽器和OS兼容性測試。有部分韓文，中國字符，日文的打印支持。17探索式測試之全局探索式測試法針對測試人員編制測試計劃和測試用例設(shè)計需要考慮的哪些廣泛性的戰(zhàn)略性的問題，全局探索式測試方法將提供一些指導(dǎo)建議。

探索式測試人員在實際開始測試之前，需要建立起一個全局目標，用于指導(dǎo)測試過程?；萏乜薟hittaker引進了旅游類比法，提出“漫游測試法”。18全局探索式測試法19ScriptedTestVSExploratoryTesting手工測試和自動化測試都是基于TestCase來展開的從測試用例的角度來看ScriptedTest和ExploratoryTesting20STET測試與測試用例的關(guān)系測試用例在之前就設(shè)計和記錄好，過后再測試執(zhí)行或被其他測試人員執(zhí)行測試設(shè)計和執(zhí)行時在同一時間完成，而且他們不是必須記錄下來，但也有可能與測試執(zhí)行的關(guān)系可以控制測試執(zhí)行可以提升測試設(shè)計過程的交互性就像做個已準備好的演講，由之前想好的想法引導(dǎo)著就像一個對話，是自動向?qū)У奶剿魇綔y試的適用時機當(dāng)測試者是新手，可以一邊訓(xùn)練一邊測試（要安排明確的計劃）需要快速的對程序進行評估在傳統(tǒng)的測試腳本（TestScript）中發(fā)現(xiàn)新的問題需要快速驗證當(dāng)有需要去確認另一位測試者的工作狀況當(dāng)團隊內(nèi)有熟悉相關(guān)領(lǐng)域知識（DomainKnowledge）的測試者當(dāng)需要做煙霧測試當(dāng)程序設(shè)計完后并沒有預(yù)先規(guī)劃并準備好測試腳本當(dāng)專案使用敏捷軟件開發(fā)專案很復(fù)雜并且難以了解當(dāng)測試者并沒有權(quán)限去創(chuàng)建測試案例當(dāng)想要針對某個程序錯誤進行深入調(diào)查當(dāng)專案尚未穩(wěn)定到可以執(zhí)行腳本測試（ScriptTest）當(dāng)想要擴大腳本測試的多樣性時21探索式測試的優(yōu)點鼓勵測試人員的創(chuàng)造性。增加機會找到新的、未知的難以發(fā)現(xiàn)的缺陷。允許測試者花較多的時間去測試感興趣的或復(fù)雜的用例。可較快速的對受測的系統(tǒng)做出快速的評量。可讓你知道系統(tǒng)是否容易使用?？勺兺ǖ?，有彈性的。它比腳本測試有趣，因為它不會一成不變。我們不用花很多時間在編寫那些簡單和繁瑣的測試用例。它可以促使測試人員快速的學(xué)習(xí)一個產(chǎn)品。它可以檢查其他測試人員的測試工作。22探索式測試的局限不容易被協(xié)調(diào)及調(diào)整。無法對系統(tǒng)作全面性的測試。提供有限的測試可信度。非常的依靠測試者的領(lǐng)域知識（domainknowledge）以及技術(shù)。無法