探索性測試及基本用例

1 測試決策5要素

測試目標：所有的重要任務都完成了，而剩下沒做的事情是比較次要的，我們做到這一點就可以盡早盡可能地降低發布風險。

測試方法：測試是一個不斷抉擇的過程，測試人員必須理解運行測試用例時和分析現有信息所涉及的各種復雜性。

測試決策5要素：用戶輸入、狀態、代碼路徑、用戶數據、執行環境。

• 用戶輸入
  • 輸入：環境產生的刺激，該刺激導致被測試的應用有所響應。主要分原子輸入(輸入一個數字、按鈕)和抽象輸入（1-25535之間的任何一個原子輸入長度值，類似於等價類划分）兩類。
  • 考慮各種輸入之間會相互影響：單獨輸入、混合輸入。
  • 輸入值的順序：組合輸入。
  • 核心功能：接收輸入、產生輸出、存儲數據、進行運算。[正向測試、逆向測試]
  • 錯誤處理程序[error handler]：輸入篩選器、輸入檢查、異常處理代碼。
  • 常規輸入[字母和數字]、非常規輸入[比如輸入ctrl+c、shift+c、esc、ctrl鍵、alt、操作系統的保留字、不同的字符集，本地化的問題]
  • 默認輸入[空格、空白、默認值]
  • 使用輸出來指導輸入。
• 狀態：狀態控件中的一個點，由所有內部數據結構的取值進行決定。
• 代碼路徑：一連串的代碼語句[基於白盒]。
• 用戶數據：測試數據盡量與上線環境的數據保持一致。
• 執行環境：操作系統、當前配置、其他應用程序、網絡拓撲、驅動程序、文件系統、網絡帶寬、性能。

2 缺陷檢測

• 1.自動化測試：通過編寫代碼來測試一個應用。（擅長找到的問題：程序崩潰、系統死機、程序掛起、突發異常、原有能用的功能出現問題）
• 2.手工測試：使用程序的用戶界面，手工輸入數據進行測試。（缺點:速度慢、沒有規律、不可反復使用、發現問題也不能重視、人員水平決定測試質量、使用喜歡的測試用例又缺乏變通）。測試用例的編寫不要太使用細節的描述，盡量描述一些用戶使用場景，同時結合自動化測試工具進行使用。
  • 1.需要測試人員編寫代碼。
  • 2.花費太多的時間來開發測試代碼，而減少了測試項目的時間。
  • 3.自動化測試可以重復運行。

3 探索性測試

探索性軟件測試模型圖：

3.1 探索性測試的定義

探索性測試：測試學習、測試設計、測試執行、測試結果評估等活動同時進行的軟件測試技術。

• 1.測試學習：學習任何可以指導測試的知識，可能要學習的內容包括行業背景、領域知識、技術平台、測試技術、產品缺陷、項目風險等。
• 2.測試設計：安排測試計划，擬定測試策略，開發測試想法，制定測試支持材料。
• 3.測試執行 ：執行測試並收集結果。
• 4.測試結果分析：分析並解讀從測試中學到的知識，可能的活動包括判定測試是否通過、理解產品實現、發掘風險區域、評估測試方法是否有效等。

簡單說就是事先不進行計划和設計的一種特殊類型的測試，由有經驗的測試人員根據實際情況，憑借自身的測試經驗和對系統的認識來進行測試。即完全拋開測試用例，使用定義的比較籠統的測試用例。

探索性測試是一種新的測試思維方式，強調系統軟件學習、測試設計、測試執行的同時進行。本質上是敏捷，可以很好地應用於敏捷項目。

探索性測試目標：

• 1.理解應用程序如何工作，接口看起來怎樣，實現哪些功能，提供必須信息，給測試人員提供測試切入點。
• 2.展示其全部能力：驗證軟件可以達到設計和發布要求。
• 3.找到缺陷：探索各種軟件的極端情況來發現潛在的問題，發現未測過的功能或者包含缺點多的功能。

探索性測試特點：

• 1.在測試過程中不斷學習被測系統，在根據學習的內容來指導測試，是一循環過程。
• 2.軟件系統學習、測試設計、測試執行同時進行。
• 3.探索式測試適用於"敏捷開發過程"。
• 4.測試人員有可能沒有測試重點。

強調測試者的主觀能動性，以及測試設計和測試執行的同時性。

3.2 探索性測試方法

探索性測試包含4種方法：自由式探索、基於場景的探索性能測試、基於策略的探索性測試、基於反饋的探索性測試。

3.2.1 探索性測試方法

包含2種方法：局部探索性測試法和全局探索性測試方法。

• 局部探索性測試法：測試人員不需要知道很多信息就可以完成測試任務，重點：測試經驗、專業知識、軟件在操作環境下如何構建和運行的知識結合在一起，使我們在測試過程中做出正確的決定。
  • 針對測試對象的局部內容進行測試的策略，例如一個頁面、一個輸入框等的測試策略。
• 全局探索性測試方法：
• 1.使用測試集用來確定軟件是否已經滿足正式發布所需達到的質量標准。
• 2.測試集中的測試用例都是相互有聯系的整體。
• 3.確定了如何對軟件進行探索式測試的整體方向。

探索性測試主要用的方法：

• 指南測試法：通過閱讀用戶手冊並嚴格遵守手冊的建議執行操作。盡量執行手冊中提交的場景，驗證軟件實現的軟件特性，也驗證了用戶手冊的准確性。[比如博客測試法、專家測試法、競爭對手測試法]
• 賣點測試法：用戶希望使用的功能。
• 地標測試法：使用指南測試法和賣點測試法，找到相關的地標。
• 權限測試法：向軟件提出很多難以回答的問題。
• 快遞測試法：測試人員專注與數據，確定哪些存儲起來的數據，跟隨他們走遍軟件。
• 深夜測試法：非賣點的功能在夜間或系統非繁忙的時刻執行。
• 遍歷測試法：選定一個目標，然后使用發現的最短路徑訪問目標包含的所有對象。
• 歷史區測試類型：惡鄰測試法[80%的測試放在20%的模塊]、博物館測試法、上一版本測試法。
• 娛樂區測試法：配角測試法、深巷測試法、通宵測試法。
• 旅游區測試類型：收藏家測試法、長路徑測試法、超模測試法。
• 混合探索式測試技術：講述用戶故事、描述需求、演示產品功能、演示集成場景、描述設置和安裝、描述警告和出錯場景。

單個特性測試方法：

 交互特性測試方法：

 系統測試方法：

3.2.2 探索式軟件測試的測試方法

1.頭腦風暴法

測試需求：圖片文件上傳，選擇圖片文件，單擊（上傳）按鍵，正式上傳，圖片不得超過5MB。經過5個人一個小時的討論，得出19個測試用例。

頭腦風暴法：
需求：圖片文件上傳，選擇圖片文件，單擊（上傳）按鍵，正式上傳，圖片不得超過5MB。
討論后產生的用例：
（1）上傳正常的圖片文件。
（2）上傳文本文件。
（3）上傳的文本文件后綴改為 jpg 后綴再上傳。
（4）上傳圖片正被預覽。
（5）上傳圖片正在編輯。
（6）上傳圖片名在選擇圖片文件后，單擊（上傳）按鍵前已修改。
（7）上傳圖片在選擇圖片文件后，單擊（上傳）按鍵前已刪除。
（8）上傳圖片大小>5MB。
（9）上傳圖片大小=5MB。
（10）上傳圖片大小=0MB。
（11）上傳圖片服務器硬盤空間不夠。
（12）上傳客戶端與服務器網絡中斷。
（13）斷電重連后重傳。
（14）單擊上傳后沒選擇任何文件。
（15）上傳重復文件。
（16）上傳文件失敗后，重傳該文件。
（17）大量用戶同時上傳圖片：測試並發。
（18）網絡延時大的情況下上傳文件。
（19）圖片格式 png、bmp、gif 和 jpeg。
（20）上傳 exe 文件。
（21）上傳服務器的文件夾被刪除。

2 車輪圖測試法

　　車輪圖測試法：結合ISO 225000的6個要素，及功能性、可靠性、易用性、效率、可維護性和可移植性進行的測試方法。

 

3 wiki法

wiki指的是一種超文本系統，支持面向社群的協作式寫作，同時也包括一組支持這種協作。在公司可以建立內部的以測試設計技巧為內容的wiki網站，把自己的軟件測試經驗書寫在這里，方便其他同事的使用和學習。

4 閱讀bug報告和測試日志

　　定期到缺陷管理工具中閱讀別人發現的缺陷以及閱讀別人書寫的測試日志，是提高自己 測試能力的一個有效手段。由於探索式測試本身就是一種基於經驗的測試，每個人都有自己 的測試經驗，因而通過閱讀別人的缺陷和日志可以提高自己的測試設計的水平，也可以更好地了解測試的軟件產品質量情況。

5．利用思維導圖工具

　　在進行軟件探索式測試的時候，我們也可以借助於思維導圖工具。

3.3 探索性測試的核心優勢

核心優勢：有助於學習，是指學（獲取知識 ）與習（應用知識）的持續過程。

軟件測試是一個持續學習並實踐的過程，學習范圍主要包括行業知識、用戶角色、軟件產品、計算平台、開發技能、測試技術、程序缺陷、開發團隊。

• 行業知識：為什么需要這個軟件？軟件如何幫助使用它的人和團體去獲得成功？
• 用戶角色：目標用戶是誰，有什么特點，有什么期望，如何幫助他們去獲得個人成就？
• 軟件產品：產品是一種解決方案，解決了行業和用戶所面臨的問題嗎？
• 計算平台：只有深刻理解理解軟件所依賴的計算平台（如操作系統、中間件、網絡協議），才能更好的進行測試。
• 開發技能：理解項目所使用的具體計算，知曉典型的技術缺陷，具備測試開發的能力
• 測試技術：選擇合適的測試技術，並能夠熟練地應用
• 程序缺陷：研究已知的軟件缺陷，提煉錯誤模式，制定緩解或預防方案。
• 開發團隊：語境決定策略和實踐。

3.4 如何評估探索性測試的測試效果

評估探索性測試結果的前提：測試記錄。測試記錄主要包括：測試目標、測試范圍、測試策略、缺陷列表、疑問、復用的測試資源、耗時、時間分配。

• 測試目標：本次測試要提供什么信息？
• 測試范圍：本次測試覆蓋了哪些功能、模塊、用戶情景？
• 測試策略：使用何種測試方法？
• 缺陷列表
• 在測試過程中發現的疑問，值得進一步探索。
• 可以復用的測試資源：被測試軟件配置、測試數據、測試腳本等。
• 測程的耗時
• 測程的時間分配：在測試設計與執行、缺陷調查與報告、測程的啟動與結束和非測試活動上各花費了多少時間。

測程：在一個固定的時間窗口內（60~120分鍾），根據預設的測試目標，對軟件Z探索性測試。類似於科學實驗，主要分三個階段：測試計划、測試執行、測試分析。

• 1.測試計划：明確測試目標，需要獲得什么目標？
• 2.測試執行：設計並執行測試用例，記錄測試所發現的一切。
• 3.測試分析：分析並總結測試所發現的信息，為下一次測試提供目標。

4 傳統的測試和精益與探索式測試區別

4.1 傳統的測試與探索式測試的區別

• 1.兩者互補，不是對立關系。
• 2.傳統的測試通過收集來的各種信息和文檔，編寫出正式的測試用例，測試人員根據測試用例來執行。探索性測試是一種新的測試思維，強調的是測試過程中要有更多的發散思維。
• 3.在執行正式的測試用例的同時，可以使用探索性測試來讓測試用例更加的豐富和富有變化，提高測試代碼的覆蓋率，找到更多的bug。

在探索式軟件測試中基於測程的管理方法是基本的管理方法：

　　第一個測程：測試開始是測試分析、設計、執行一起進行，測試過程中隨時進行記錄。比如測試過哪些模塊，使用了哪些方法，遇到了哪些問題。一個測程一般在 0.5～ 3 小時。

一個測程測試完畢后測試工程 師與測試經理及其他測試工程師一起討論測試記錄總結如下內容：

1. 需要進一步學習哪些專業知識、業務知識和其他知識。
2. 系統中這次發現的哪些問題是有效的缺陷，討論后填寫到缺陷管理軟件中去。
3. 下一次需要重點測試哪些模塊，使用哪些方法和技巧。

　　然后進入下一輪測程。　　

4.2  探索式測試與精益

軟件測試的目的有4個方方面：發現缺陷、增加信心、為領導者做出決策以及預防缺陷。

精益的思想：在探索式初期采用地毯式淺層測試的策略。初期測試階段是為了探索哪些模塊存在缺陷以及缺陷的嚴重程度，所以我 們必須采取“地毯式”的方法，把所有模塊都均勻地摸一遍。采用“淺層”測試由於現在是 偵察兵介入，熟悉一下缺陷在軟件中的分布情況，大規模的測試還沒有開始，所以這個時候 采用“深入”的測試是沒有必要也是不科學的。通過第一次探索式測試，我們對缺陷在軟件中的分布情況有了八九不離十的了解，可以計划在下幾次測程計划中采用不同的測試策略和測試方法進行測試。同樣在每次測程結束，對測試過程的結果進行不斷的總結與反饋，指定下一次測程的計划，這種方法其實就是精益思維方式。

　　精益中一些工具在探索式軟件測試中的使用，比如：OODA 環，OODA包括探索、判斷、決策、行動 4 個活動構成的環。在探索式測試中“觀察”可以理解為觀察前一個測程中的測試結果，然后通過“判斷”來對測試結果進行分析，結合公司文化、以前的測試遺產、新發現的問題和以前的經驗來判斷下一個測程的測試“決策”，從而進入下一輪探索式測試行動。

 

　　精益企業產品從產生到衰敗的過程也正體現了探索式軟件測試中發現缺陷的分布情況，在探索測試初期隨着測試的深入發現的缺陷越來越多，而到了后期發現的缺陷逐步呈現出衰退的趨勢。"創新者"與"早期采納者"階段正是那些很容易被發現的缺陷，探索測試在這個時期正處於深入探索的階 段，通過這個階段的探索，我們可以更加深入地了解產品質量情況、缺陷分布、缺陷類型等 信息。"早期大多數"是指基本上了解了產品本身的一些特征，在這個階段大量的缺陷被發現出來。"晚期大多數"為一些隱藏得比較深的缺陷被逐步地發現。"滯后者"是指一些深層次的、不容易被發現的，甚至沒有被測試出來的缺陷。

　　探索式測試也可以分為增長期、成長期、成熟期、衰退期、滅亡期。探索式測試的成熟度周期與發現缺陷的生命周期是一致的。

　　在探索式軟件測試前期，由於對產品不是很了解，我們主要的精力在於理解探索產品中缺陷的分布以及缺陷的類型，這個時候的投資回報率是負的，隨着對產品質量的逐步了解，探索式測試的投資回報率突破零點，並且達到正回報率，從而取得效益。

 

5 如何實施探索性測試

探索性測試鼓勵測試人員依據當前語境選擇合適的測試流程與技術。SMART原則提供了指導：

• Specifi(具體的):測試需要一個具體的目標。
• Measurable（可度量的）：有明確的指標可以評估目標是否達成。
• Attainable(可實現的)：目標應該是可實現的，要求將一個大目標分解成多個小目標，且每個小目標也是具體的、可度量的、可實現的。而且，追蹤小目標的完成情況提供了整體進度的可度量性。
• Relevant（相關的）：符合團隊利益。
• Time-boxed(有時間限制的)：為每個目標設定一個合理的最后期限。

測試人員可按SMART原則展開探索性測試：

• 1.測試人員制定測試計划。分析被測試應用，確立若干個具體的測試使命（Mission）,每個使命針對一個可能的產品風險。
• 2.測試人員將測試使命分解成一系列測試任務，每個任務都有明確的退出條件和時間限制。
• 3.在短暫的測試計划之后，根據優先級選擇一個任務，在一個固定的時間窗口中執行探索性測試。（測程：一般窗口長度為60-120分鍾，一般90分鍾）
• 4.測試結束后，休息，放松思維
• 5.反思當前測試進展，並優化測試計划，追加一個測程，開始新一輪探索性測試。

根據國外的一些實踐理念，采用session來進行測試范圍的確定：主要需要了解幾個關鍵詞：session、charters、UC。

　　charter:探索性測試過程中使用到的一個非常清晰的任務列表，指出了要測試什么、怎么測試（測試策略）、要尋找什么樣的bug，有哪些bug，要去檢查什么文檔等。

　　sessions:一個基本的測試工作單元，一般對應1-2個UC。探索性測試者所有進行的探索性測試都是基於Session的。

• 1.大概花1-2小時時間看PRD和原型（了解目的和產品背景）
• 2.大概花1-2H時間確定下有哪些主要的功能模塊和貢獻性的功能模塊
• 3.與項目組測試人員溝通哪個功能模塊發現bug最多，哪個最小，哪塊存在的風險比較大。
• 4.確定Session的個數，並指出每個session大概花多長時間，一般是1.5-2H。
• 5.制定探索性測試計划，包含所有session的名稱和測試時間以及緩沖情況。
• 6.根據探索性測試計划，邊學習產品需求，邊測試，發現問題立馬記錄問題描述，最后發送測試報告。
• 7.與項目組測試人員溝通探索性測試的效果以及該產品存在的風險，從用戶易用性角度給該產品總體評價，同時跟蹤確認bug的fix情況。

6 基本測試用例[編輯、輸入框、翻頁] 

Base64編碼：基於64個可打印字符來表示二進制數據的方法，常用於處理文本數據的場合，表示、傳輸、存儲一些二進制數據。在Base64中的字符包括：A-Z,a-z,0-9,+,/ 

6.1 編輯有效、無效的功能

2. 點擊操作欄【編輯】按鈕 3. 編輯無效的xx 3.1. 不填寫任何字段，點擊確認 3.2. 不填寫必填字段，點擊確認 3.3. 留空任意一個必填字段，點擊確認 3.4. 填寫的字段不符合格式（如非法字段），點擊確認 3.5. 填寫的內容過長或過短，點擊確認	2. 能正常跳轉到xx頁 3.  3.1. 必填字段提示不能為空 3.2. 必填字段提示不能為空 3.3. 能對留空的必填字段進行提示 3.4. 能友好對信息進行提示 3.5. 能正常截斷或友好進行提示
2. 點擊操作欄【編輯】按鈕 3. 編輯有效的xx 3.1. 輸入全部字段，點擊確認 3.2. 輸入必填字段，點擊確認 3.3. 輸入必填字段，清空所有的非必填字段，點擊確認	2. 能正常跳轉到編輯頁 3.  3.1. 能有效的xx 3.2. 能有效的編輯xx 3.3. 能有效的編輯xx，且能有效的清空所有的非必填字段

 

6.2 輸入框有效、無效查詢

 

2. 輸入無效的信息進行查詢 2.1.輸入框輸入空格+信息+空格，點擊查詢 2.2.輸入框輸入為空，點擊查詢 2.3.輸入框輸入信息超過一定的長度，點擊查詢 2.4.輸入框輸入信息，多次點擊查詢按鈕 2.5.輸入框輸入JS標記信息等信息，（比如<script>alert('aa');</script> ），點擊查詢按鈕 2.6.輸入框復制、粘貼 2.7.點擊下拉框，不選擇任何數據，直接點擊確認，點擊查詢 2.8.點擊下拉框，選擇某一個數據，點擊確認，然后點擊查詢

2.  2.1. 列表結果能被友好進行搜索並查詢結果友好展示 2.2. 列表搜索結果能被友好進行展示 2.3. 查詢條件能被友好提示，超過長度限制 2.4. 列表搜索結果只展示一次查詢內容 2.5. 列表搜索結果能友好進行展示 2.6. 輸入框能被友好進行復制、粘貼 2.7. 下拉框內不顯示任何其他數據 2.8. 下拉框能被友好顯示，且列表查詢結果顯示對應字段的內容

6.3 翻頁功能

2. 輸入不同的情況進行翻頁查看 2.1.點擊首頁、上一頁、下一頁、尾頁、指定跳轉頁 2.2. 無數據時查看翻頁 2.3. 首頁時，點擊上一頁 2.4. 尾頁時，點擊下一頁 2.5. 翻頁后，列表數據排序 2.6. 中間頁，勾選列表數據 2.7. 指定頁面顯示條數翻頁 2.8. 輸入非法字符（比如0、負數、字符串、中文、特殊字符%）

2. 2.1.能友好跳轉到對應頁面 2.2.不顯示翻頁功能 2.3. 不能進行點擊上一頁，且可以點擊其他頁 2.4. 不能點擊下一頁，且可以點擊其他按鈕 2.5. 翻頁后，列表數據能友好進行提示 2.6. 勾選列表數據，能友好勾選前后翻頁選擇的數據 2.7. 能友好顯示指定翻頁條數 2.8. 能友好提示，不產生異常