劇本式測試

隨著軟件技術(shù)的發(fā)展，軟件開發(fā)過程中對軟件測試的需求越來越龐大，從原來單純的尋找軟件缺陷，到后來的學習軟件、挖掘軟件中存在的缺陷、評估軟件可用性、性能等等方面，軟件測試發(fā)揮著重要作用。

考慮到軟件測試如此的重要，難免會有不少的測試人員試圖完成“完全測試”——通俗地說即使想將軟件的方方面面、每一行代碼都測試覆蓋到。

但是，“完全測試”是不存在的，是一個難以實現(xiàn)的夢想，究其原因，軟件測試的投入（時間、人力等）是一個巨大的限制因素。我們不可能圍繞一個軟件投入無窮的時間和人力進行測試，并且軟件是一個不斷發(fā)展和迭代的產(chǎn)品，當測試人員在前一個迭代周期測試的一個功能可能在下一個迭代周期就會發(fā)生變化，測試的要點也會相應(yīng)的發(fā)生變化。

眾所周知，傳統(tǒng)的腳本式測試流程的主要包括測試設(shè)計和測試執(zhí)行。測試人員嚴格地按照設(shè)計好的測試用例執(zhí)行測試，比對期望輸出和實際測試輸出，最終判定測試結(jié)果通過與否。

由此可見，腳本測試嚴重依賴于測試設(shè)計人員對被測功能的熟悉度，忽視了測試執(zhí)行人員在測試過程中發(fā)揮的作用（某種程度上認為測試人員只需要機械性地嚴格按照測試腳本執(zhí)行即可）。

但在實際工作中，劇本式測試往往存在以下問題：

1)測試設(shè)計人員不可能嚴格的、精確的描述每一個測試用例

在工業(yè)實踐和真實的生產(chǎn)環(huán)境中，測試用例往往很難設(shè)計，實踐人員也很少會嚴格按照設(shè)計的測試用例進行測試，預(yù)期結(jié)果的設(shè)計和評估都需要依靠測試人員要根據(jù)經(jīng)驗和隱性知識，而不是嚴格地記錄技術(shù)和結(jié)果。

2)測試人員需要花費大量的時間維護測試腳本

軟件應(yīng)用具有開放性、快速迭代、頻繁變更、存在多種接口、重用戶體驗等特點，相應(yīng)的測試用例也需要頻繁修改，因此需要耗費大量人力和時間成本維護測試用例或測試腳本。

3)劇本式測試忽略了測試人員在測試執(zhí)行中的創(chuàng)造性

有數(shù)據(jù)表明，不同的測試人員使用相同的測試策略、按照相同的測試腳本執(zhí)行測試，測試結(jié)果（挖掘出的缺陷數(shù)量和缺陷質(zhì)量）也會存在較大差異。

4)劇本式測試的機械性特點導致測試人員的功能性被削弱，測試人員的可替代性被增強

正是由于劇本式測試的機械性，已有的許多關(guān)于劇本式測試的研究的關(guān)注點都在于自動化測試用例的設(shè)計、生成和優(yōu)先級，或者測試技術(shù)的選擇，而非測試人員本身，導致生產(chǎn)實踐中不少企業(yè)或個人都認為軟件測試是一項可以被機器替代的工作。

探索性測試

無數(shù)經(jīng)驗告訴我們，影響用例設(shè)計、用例執(zhí)行過程的不只是單純的測試技術(shù)，測試經(jīng)驗和智力性創(chuàng)造也發(fā)揮著重要作用。為了提高測試工作的效率，充分發(fā)揮測試人員在測試工作中的智力性，“探索性測試”在劇本式測試的包圍圈中異軍突起。

探索性測試最早是由測試專家 Cem Kaner 博士在 1983 年提出，并發(fā)展成為一門學科。它指的不是某種具體的測試技術(shù)，而是一種自由的測試風格或者說測試思維技術(shù)。

顯著區(qū)別于其他測試方法的地方在，它不依賴于設(shè)計好的測試用例，強調(diào)測試設(shè)計和測試執(zhí)行同時進行，其本質(zhì)是邊學習、邊設(shè)計、邊測試、邊思考。

探索性方法的重點是基于前面測試的結(jié)果，動態(tài)識別和測試具有高風險的測試場景，而不是基于一些靜態(tài)的覆蓋率概念。

在某種意義上，探索性測試反映了測試方法的完全轉(zhuǎn)變，其中測試執(zhí)行是基于測試人員當前和改進的對系統(tǒng)的理解。這種理解來源于：測試期間觀察到的產(chǎn)品行為，熟悉應(yīng)用程序、平臺、缺陷過程、可能出現(xiàn)的缺陷類型失敗，與特定產(chǎn)品相關(guān)的風險，等等。

探索性測試從誕生至今，經(jīng)過不斷地發(fā)展已經(jīng)取得了不小的實踐成果。不少人認為：相較于劇本式測試，探索性測試可以讓人腦不受各種先入為主的條條框框約束，能夠更好地利用人的創(chuàng)造性、經(jīng)驗?zāi)芰图记伞?/p>

探索性測試效益

Q1：相較于劇本式測試，探索性測試能夠發(fā)現(xiàn)更多數(shù)量、更多類型、更嚴重的缺陷嗎？

軟件中發(fā)現(xiàn)缺陷的數(shù)量主要取決于測試人員測試軟件的技能。傳統(tǒng)的腳本測試很少能體現(xiàn)出測試人員的重要性，更多的是檢查需求的一致性?；谖墨I中的實驗和真實案例分析：由于探索性測試的自由性，測試人員可以不必花費過多的時間在文檔上（如學習需求文檔、使用說明等），而將時間更多的用于被測產(chǎn)品的學習和探索。

Q2：相較于劇本式測試，探索性測試能夠降低缺陷誤報率、提高檢測缺陷的效率嗎？

相較于劇本式測試，探索性測試的缺陷誤報率更低?？焖俜答?，縮短開發(fā)人員與測試人員之間的反饋時間。因為探索性測試人員可以對產(chǎn)品的變更做出快速反應(yīng)并提供測試將結(jié)果反饋給開發(fā)人員。探索性測試人員可以基于系統(tǒng)實際行為的信息重點針對疑區(qū)域進行測試，而不是僅僅依賴于規(guī)范和設(shè)計計劃測試時的文檔。

有文獻表明，使用探索性測試能夠在較短的時間內(nèi)完成測試，在單位時間內(nèi)能夠發(fā)現(xiàn)數(shù)量更多的缺陷，相較于劇本式測試更高效。

Q3：相較于劇本式測試，探索性測試能為測試人員帶來什么好處？

同步學習。探索性測試可以幫助測試人員提高對測試的興趣，當測試人員不遵循預(yù)先指定的腳本時，他們會積極地學習被測試的系統(tǒng)，并獲得關(guān)于系統(tǒng)行為和失敗的知識。

鼓勵測試人員在完成測試任務(wù)時探索任何看起來有趣、可疑或有價值的東西，以獲得技能或知識，這也可以激發(fā)測試人員保持持續(xù)性學習的動力。特別是對于新手來說，探索性學習是獲取新系統(tǒng)重要知識的有效途徑。探索性測試花在文檔上的時間更少（即，只專注于日志、測試筆記和執(zhí)行后的視頻的文檔)，測試人員能夠更好的利用資源，快速反饋測試過程中發(fā)現(xiàn)的問題。

當測試人員不跟隨事先設(shè)定的腳本進行測試時，他們會在測試過程中積極學習被測系統(tǒng)的行為、表現(xiàn)和發(fā)現(xiàn)的缺陷，從而幫助他們提高測試能力，在測試過程中不斷完善，幫助測試人員提出更好、更強大的測試。

探索性測試的挑戰(zhàn)

由于不存在經(jīng)過設(shè)計和評估的測試用例，“執(zhí)行先于設(shè)計或設(shè)計與執(zhí)行同時進行”的特點對探索性測試的風險管理等提出了巨大挑戰(zhàn)。并不能完全替代劇本式測試。

• 首先，探索性測試沒有能力防止缺陷。劇本式測試可以在需求收集期間開始接入設(shè)計測試用例，從而盡早揭示缺陷；

  
  

• 其次，當有規(guī)范的測試報告和測試文檔要求時，劇本式測試的必要性則凸顯出來；

  
  

• 再者，探索性測試對測試結(jié)果的判斷更多依賴于測試人員自身而不是需求文檔、用戶手冊等標準，因此對于測試輸出的正確性難以正確性評估；

  
  

• 此外，考慮到我們經(jīng)常需要反復執(zhí)行相同的測試（如缺陷修復驗證等），探索性測試缺乏可追蹤或記錄性的文檔用例，使得回歸測試變得困難。

當測試人員進行探索性測試時，偶然發(fā)現(xiàn)的缺陷較難復現(xiàn)。尤其是當開發(fā)人員要求詳細的復現(xiàn)步驟時，測試人員關(guān)注于“復現(xiàn)缺陷”本身，而失去了探索性測試的意義。并且，測試的目的不只在于發(fā)現(xiàn)缺陷，還應(yīng)該包含更多其他方面，例如功能覆蓋等。因此，探索性測試并不能完全替代劇本式測試。

為了解決這些問題，有人提出了探索性測試和劇本式測試相結(jié)合的方法。例如，使用探索性測試設(shè)計新的測試，然后編寫為腳本測試用例用于回歸測試。

1)缺乏豐富的、專門的測試方法

高度依賴于測試人員的技能、經(jīng)驗和領(lǐng)域知識。當被測產(chǎn)品很復雜時，測試人員的技能和領(lǐng)域知識往往就會顯得缺乏。雖然探索性測試允許測試人員在完成測試工作時自由地使用任何測試方法，并且允許聯(lián)合多種測試方法（如風險測試、配對測試、需求測試、交叉功能測試等等）完成測試工作。但作為一門研究學科，對專門的測試方法研討仍是不少研究人員關(guān)心的。

為了緩解這一挑戰(zhàn)，James A.Whittaker提出的局部探索式測試方法從用戶輸入、狀態(tài)、代碼路徑、用戶數(shù)據(jù)和運行環(huán)境五個方面給予了測試人員方法指導，幫助測試人員更具方向性地探索軟件細節(jié)。

并且“漫游”型全局探索式測試方法，更是廣大學者討論和研究。它將全局探索性測試比擬為城市旅游，從旅游者的角度出發(fā)探索軟件的“商業(yè)區(qū)”、“歷史區(qū)”、“娛樂區(qū)”等區(qū)域。

已有文獻實驗指出，將“漫游”探索性測試方法應(yīng)用于敏捷開發(fā)項目，能夠提高系統(tǒng)測試的有效性。此外，史亮、高翔所著的《探索式測試》一書，結(jié)合實際案例詳細講述了測試單個特性、交互特性和系統(tǒng)交互的探索性測試方法，例如可用于單個特性探索性測試的聯(lián)想輸入模型，可用于系統(tǒng)交互特性探索性測試的肥皂劇測試模型等等。

2)探索性測試發(fā)展自動化存在瓶頸

自動化測試是業(yè)界發(fā)展探索性測試的主要障礙之一。探索性測試偏重于手工測試，測試執(zhí)行和測試結(jié)果的評估依賴于測試人員本身，難免存在正確性不穩(wěn)定和高成本的問題。

而自動化測試可以幫助測試人員完成每天的回歸測試或檢查，減少軟件開發(fā)的測試資源投入。對于測試結(jié)果的正確性評估也具有可靠性。相較于自動化測試的文檔化管理，探索性測試測試需要知識和技能難以通過文檔傳遞。

自動化是測試人員的工具之一，應(yīng)該在任何合理的時候使用，以改進測試，并為其他類型的測試活動釋放人力資源。再者，探索性測試和自動化不是相互排斥的，而是可以相互配合。因此，將探索性測試與自動化測試的可度量性和可重復性結(jié)合，不僅能提高探索性測試缺陷檢測能力和有效性，還能節(jié)省時間和人力投入，提高探索性測試在回歸測試中的可用性。

調(diào)查指出，測試人員在進行探索性測試時時常會同自動化測試結(jié)合。通過添加自動化的支持來增強經(jīng)典的探索性測試方法，這使得整個過程在重復探索性測試期間更加可跟蹤、透明并且成本更低。在此，我們可以將探索性測試的自動化發(fā)展方向稱為“自動化探索性測試“，而業(yè)界研究較多的自動化探索性測試方法主要是將探索性測試方法與模型測試相結(jié)合。

例如：

• 基于規(guī)則的R-BET模型，將基于規(guī)則的自動化測試與探索性測試結(jié)合用于GUI測試，提高了GUI測試的自動化回歸測試能力和通用性缺陷、應(yīng)用性缺陷檢測能力；

  
  

• MBET模型將ECGs模型與探索性測試結(jié)合，自動化生成測試用例，彌補了探索性測試的自動化缺陷和提高了單獨使用模型測試服或探索性測試方法測試覆蓋率；

  
  

• ARME模型將手工進行缺失狀態(tài)和轉(zhuǎn)移路徑的補全過程自動化，不僅可以擴展測試用例數(shù)量，提高探索性測試挖掘缺陷的能力，還能減少測試步驟的數(shù)量，使得測試套件變得更加有效；

  
  

• 模型測試法與探索性測試法結(jié)合，為探索性測試添加自動化輔助，增強了探索性測試過程的可追溯性、透明性，減少了探索性測試重復測試的開銷。
  

3)缺乏結(jié)構(gòu)性的管理方法

探索性測試具有很強的自由度，但探索性測試也應(yīng)該是有計劃的、有組織的、有策略指導和目標導向的。

缺乏準備、組織和指導，測試人員可能會浪費大量的時間徘徊在相同功能的測試上，導致重復測試或忽略重要的測試，特別是當多個測試人員或測試團隊都參與的時候。

此外，由于缺少測試計劃和設(shè)計，難以單獨跟蹤某個功能測試覆蓋率或單獨對某個測試人員測試流程進行跟蹤和管理。因此，缺乏結(jié)構(gòu)性的管理方法是探索性測試的挑戰(zhàn)之一。

為了緩解這一挑戰(zhàn)，James Bach提出的著名的探索性測試管理方法——基于會話的測試管理（SBTM）。

SBTM反映了時間箱的概念，采用測試會話來跟蹤測試（測試會話是基本的測試工作單元），而會話單中的測試章程則被許多實踐者認為是SBTM的重要元素。

SBTM的出現(xiàn)，使探索性測試更加易于管理和指導測試人員使用探索性測試。它清晰地描述了測試目標和測試范圍，被認為是一個高級的測試計劃指導方法。提供了單個測試人員或團隊測試人員之間相互協(xié)作的可能。

在其后的研究中，SBET探索性測試框架在SBTM框架上進行改進，封裝了所有與會話相關(guān)的活動，加強了測試會話過程中的材料追溯（例如提供定制工具來控制、跟蹤和支持ET會議。測試人員的所有操作都通過系統(tǒng)日志連續(xù)地記錄在數(shù)據(jù)庫中）。

TET（團隊探索性測試會話管理）方法，將SBTM方法拓展到團隊級別，邀請具有不同專業(yè)技能和知識背景的人員加入團隊，從不同角度進行探索性測試，依靠團隊協(xié)作提高了探索性測試的有效性和豐富了團隊成員之間的相互學習和交流。

加VX:xiaoxianchen89,回復B站，領(lǐng)20G軟件測試入門學習資料