探索性測試及基本用例
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 小時。
一個測程測試完畢後測試工程 師與測試經理及其他測試工程師一起討論測試記錄總結如下內容:
- 需要進一步學習哪些專業知識、業務知識和其他知識。
- 系統中這次發現的哪些問題是有效的缺陷,討論後填寫到缺陷管理軟體中去。
- 下一次需要重點測試哪些模組,使用哪些方法和技巧。
然後進入下一輪測程。
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. 能正常跳轉到xx頁 |
2. 點選操作欄【編輯】按鈕 |
2. 能正常跳轉到編輯頁 |
6.2 輸入框有效、無效查詢
|
|
6.3 翻頁功能
2. 輸入不同的情況進行翻頁檢視
|
2. 2.1.能友好跳轉到對應頁面 2.2.不顯示翻頁功能 2.3. 不能進行點選上一頁,且可以點選其他頁 2.4. 不能點選下一頁,且可以點選其他按鈕 2.5. 翻頁後,列表資料能友好進行提示 2.6. 勾選列表資料,能友好勾選前後翻頁選擇的資料 2.7. 能友好顯示指定翻頁條數 2.8. 能友好提示,不產生異常
|