你還不知道怎麼學習軟體測試嗎?看完這篇文章,你就明白了!

2020-09-24 15:00:47

軟體測試過程中,最主要的就是要掌握好軟體測試的方法,掌握好了軟體測試方法,有利於測試技能的大幅度提高。

軟體測試方法

== 軟體測試方法是指測試軟體的方法。隨著軟體測試技術的不斷髮展,測試方法也越來越多樣化,針對性更強;選擇合適的軟體測試方法可以讓我們事半功倍。==

一、根據是否要走查程式碼,分為白盒測試、灰盒測試、黑箱測試;

二、分為手工測試、自動化測試和效能測試:

手工測試:UI測試、冒煙測試、隨機測試、在地化測試、安裝測試、解除安裝測試;
自動化測試:
效能測試:健全測試、衰竭測試、負載測試、強迫測試、壓力測試、恢復測試;

三、根據是否要執行程式,分為靜態測試和動態測試;

四、按測試階段可分為:單元測試、整合測試、系統測試、迴歸測試、驗收測試、α測試_Alpha測試、β測試,英文是Beta testing。又稱Beta測試,使用者驗收測試(UAT);

五、其他測試方法:端到端測試、接受測試、安全測試、相容性測試、可用性測試、比較測試、邊界測試、強力測試、裝配安裝測試、隱藏資料測試、等價劃分測試、判定表測試、深度測試、基於設計、檔案測試、域測試、介面測試、逆向測試、非功能性測試、極限測試等。

其中一些測試方法的定義

端到端測試

端到端測試,英文是End to End Testing。

端到端測試類似於系統測試,測試級的「宏大」的端點,涉及整個應用系統環境在一個現實世界使用時的模擬情形的所有測試。

例如與資料庫對話,用網路通訊,或與外部硬體、應用系統或適當的系統對話。端到端架構測試包含所有存取點的功能測試及效能測試。

端到端架構測試實質上是一種"灰盒"測試,一種集合了白盒測試和黑箱測試的優點的測試方法。

健全測試

== 健全測試,英文是Sanity testing。==

健全測試是指一個初始化的測試工作,以決定一個新的軟體版本測試是否足以執行下一步大的測試能 力。
例如,如果一個新版軟體每5分鐘與系統衝突,使系統陷於泥潭,說明該軟體不夠「健全」,不具備進一步測試的條件。

衰竭測試

衰竭測試,英文是Failure Testing。

衰竭測試是指軟體或環境的修復或更正後的「再測試」。可能很難確定需要多少遍再次測試。尤其在接近開發週期結束時。自動測試工具對這類測試尤其有用。

負載測試

負載測試,英文是Load testing。
負載測試是測試一個應用在重負荷下的表現。例如測試一個 Web 站點在大量的負荷下,何時系統的響應會退化或失敗,以發現設計上的錯誤或驗證系統的負載能力。在這種測試中,將使測試物件承擔不同的工作量,以評測和評估測試物件在不同工作量條件下的效能行為,以及持續正常執行的能力。

負載測試的目標是確定並確保系統在超出最大預期工作量的情況下仍能正常執行。此外,負載測試還要評估效能特徵,例如,響應時間、事務處理速率和其他與時間相關的方面。

強迫測試

強迫測試,英文是Force Testing。

強迫測試是在交替進行負荷和效能測試時常用的術語。也用於描述物件在異乎尋常的過載下的系統功能測試之類的測試,如某個動作或輸入大量的重複,大量資料的輸入,對一個資料庫系統大量的複雜查詢等。

壓力測試

壓力測試,英文是Stress Testing。和負載測試差不多。

壓力測試是一種基本的品質保證行為,它是每個重要軟體測試工作的一部分。壓力測試的基本思路很簡單:不是在常規條件下執行手動或自動測試,而是在計算機數量較少或系統資源匱乏的條件下執行測試。通常要進行壓力測試的資源包括內部記憶體、CPU 可用性、磁碟空間和網路頻寬等。一般用並行來做壓力測試。

恢復測試

== 恢復測試,英文是Recovery testing。==

恢復測試是測試一個系統從如下災難中能否很好地恢復,如遇到系統崩潰、硬體損壞或其他災難性問題。恢復測試指通過人為的讓軟體(或者硬體)出現故障來檢測系統是否能正確的恢復,通常關注恢復所需的時間以及恢復的程度。

==恢復測試主要檢查系統的容錯能力。==當系統出錯時,能否在指定時間間隔內修正錯誤並重新啟動系統。恢復測試首先要採用各種辦法強迫系統失敗,然後驗證系統是否能儘快恢復。對於自動恢復需驗證重新初始化(reinitialization)、檢查點(checkpointing mechanisms)、資料恢復(data recovery)和重新啟動 (restart)等機制的正確性;對於人工干預的恢復系統,還需估測平均恢復時間,確定其是否在可接受的範圍內。

可用性測試

可用性測試,英文是Practical Usability Testing。

可用性測試是對「使用者友好性」的測試。顯然這是主觀的,且將取決於目標終端使用者或客戶。使用者面談、調查、使用者對話的錄象和其他一些技術都可使用。程式設計師和測試員通常都不宜作可用性測試員。

比較測試

比較測試,英文是Compare Testing。

比較測試是指與競爭夥伴的產品的比較測試,如軟體的弱點、優點或實力。來取長補短,以增強產品的競爭力。

強力測試

強力測試,英文是Mightiness Testing。

強力測試通常驗證軟體的效能在各種極端的環境和系統條件下是否還能正常工作。或者說是驗證軟體的效能在各種極端環境和系統條件下的承受能力。比如,在最低的硬碟機空間或系統記憶容量條件下,驗證程式重複執行開啟和儲存一個巨大的檔案1000次後也不會崩潰或宕機。

裝配安裝

裝配/安裝/設定測試是驗證軟體程式在不同廠家的硬體上,所支援的不同語言的新舊版本平臺上,和不同方式安裝的軟體都能夠如預期的那樣正確執行。比如,把英文版的 Microsoft Office 2003安裝在韓文版 的Windows Me 上,再驗證所有功能都正常執行。

隱藏資料

隱藏資料測試在軟體驗收和確認階段是十分必要和重要的一部分。程式的品質不僅僅通過使用者介面的視覺化資料來驗證,而且必須包括遍歷系統的所有資料。

假設一個應用程式要求使用者兩條資訊-----使用者名稱和密碼來建立帳戶。這個使用者輸入這兩條資料後儲存。最後,一個確認視窗將通過資料庫中找到這條資料來顯示使用者名稱和密碼給使用者。為了驗證所有的資料儲存是否正確,一個QA測試人員會在這個確認視窗簡單的檢視下使用者名稱和密碼。如果他們成功了?假設資料庫記錄了第三條資訊----建立日期,它可能不會出現在確認視窗,而只在存檔中才出現。如果建立日期保留的不正確,而QA測試人員只驗證螢幕上的資料,那麼這個問題就不可能被發現。建立日期可能就是一個bug,由於一個使用者帳戶儲存了一個錯誤的日期到資料庫中,這個問題也不可能會被引起注意,因為它被使用者介面所隱藏。這只是一個簡單的例子,但是它卻演化出了一點:隱藏資料測試的重要性。

判定表

判定表的英文是decision table,是指一個表格,用於顯示條件和條件導致動作的集合。

定義:判定表是分析和表達多邏輯條件下執行不同操作的情況的工具。

判定表的優點:能夠將複雜的問題按照各種可能的情況全部列舉出來,簡明並避免遺漏。因此,利用判定表能夠設計出完整的測試用例集合。

在一些資料處理問題當中,某些操作的實施依賴於多個邏輯條件的組合,即:針對不同邏輯條件的組合值,分別執行不同的操作。判定表很適合於處理這類問題

深度測試

深度測試的英文Depth test ,是指執行一個產品的一個特性的所有細節,但不測試所有特性。

當比較函數返回真的時候才顯示出效果來。必須啟用「#深度測試」,才能執行測試。不使用的時候需要關閉。

基於設計

基於設計的測試的英文是design-based testing,是根據軟體的構架或詳細設計引出測試用例的一種方法。

一種基於設計模型的測試方法(Model Based TestIng System,MATIS).該方法利用使用者介面自動生成方法,把設計模型中的類屬性定義和實現中的控制元件屬性組織在一起,構建描述介面的邏輯對照表,輔助測試指令碼引擎執行自動測試指令碼.藉助設計模型中擴充套件的類定義,MATIS方法可以自動生成測試用例和測試資料。

域測試

== 域測試的英文是domain testing,定義參考等價劃分測試(equivalence partition testing);==

一般分為單域測試和多域測試,其中單域測試包括裝置測試和業務測試,裝置測試包括測試某個系統的軟交換裝置、中繼媒體閘道器裝置、信令閘道器裝置、接入媒體閘道器和IAD等裝置。

等價類劃分有兩種不同的情況:有效等價類和無效等價類。設計時要同時考慮這兩種等價類,因為軟體不僅要能接收合理的資料,也要能經受意外的考驗。

一有效等價類:是指對於程式的規格說明來說是合理的、有意義的輸入資料構成的集合。利用有效等價類可檢驗程式是否實現了規格說明中所規定的功能和效能。

二無效等價類:與有效等價類的定義恰巧相反。

逆向測試

== 逆向測試/反向測試/負面測試的英文是Negative Testing,測試瞄準於使系統不能工作。==

負面測試與正面測試的比較:

負面測試(Negative testing)是相對於正面測試(Positive testing)而言的。
它們也是測試設計時的兩個非常重要的劃分。簡單點說,正面測試就是測試系統是否完成了它應該完成的工作;而負面測試就是測試系統是否不執行它不應該完成的操作。形象一點,正面測試就象一個畢恭畢敬的小學生,老師叫我做什麼,我就做什麼;而負面測試就象一個調皮搗蛋的孩子,你叫我這樣做,我偏不這樣做,而且和你對著幹。開發人員也是最討厭修改此類bug的。

非功能性

非功能性需求測試的英文是non-functional requirements testing ,是與功能不相關的需求測試,如:效能測試、可用性測試等。

為什麼非功能性需求很重要?

在您設計解決方案的過程中滿足功能性需求當然是很重要的。但是,如果沒有考慮非功能性需求,您的解決方案則很難取得實效。

非功能性需求特點:1.不要脫離實際環境;2.可靠性;3.可用性;4.有效性;5.可維護性;6.可移植性。

極限測試

簡介:極限測試本質上是為了滿足極限測試的思想和流程而設計的一套測試策略和流程,其本身並不侷限於使用特定的測試技術和方法。

過程
1.單元測試

2.驗收測試

要熟記各個測試方法的意義,並且,靈活的運用它,這樣,測試技能,將能更上一層樓。

需要領取面試資料,軟體測試資料全集,點選連結加入群聊【Python自動化測試交流群】領取!