Stories

Detail Return Return

軟件測試必須知道的方法和知識 - Stories Detail

“軟件測試技術是軟件開發過程中的一個重要組成部分,是貫穿整個軟件開發生命週期、對軟件產品(包括階段性產品)進行驗證和確認的活動過程,其目的是儘快儘早地發現在軟件產品中所存在的各種問題——與用户需求、預先定義的不一致性。檢查軟件產品的bug。寫成測試報告,交於開發人員修改。軟件測試人員的基本目標是發現軟件中的錯誤。”

 

image

 

01 軟件測試步驟
第一步為測試計劃。編寫測試計劃通俗一點講就是什麼人在什麼時間做什麼事,最後產出什麼東西。測試人員要測試哪些模塊、在什麼期限內,提交哪些文檔。

第二步為測試設計與開發。主要是編寫測試用例,測試用例就是指導測試的文檔,比如我們要測試商城登錄、買東西等功能,通過測試方法和策略設計測試用例。評審就是評價審查,不能想當然該怎麼測。不能只是輸入正確的用户名和密碼,能登錄進去就完事了。作為軟測工程師需要有破壞性,比如密碼輸錯時怎麼辦,會不會有相應的報錯等等。

第三步為執行測試。bug就是缺陷,發現bug之後,要提交給開發人員讓他們去修改,然後進行迴歸測試,驗證開發人員有沒有改好。

02 軟件測試模型-V模型

image

 


V模型的階段包括:需求説明、系統功能設計、概要設計、詳細設計、編碼、單元測試、集成測試、系統測試、驗收測試。

V模型左邊表示開發過程中的各階段,右邊表示測試過程中的各階段

V模型中每個開發階段對應一個測試階段

 

image

 

V模型水平虛線上部表明,其需求分析、功能設計和驗收測試等主要工作是面向用户,要和用户進行充分的溝通和交流或者是和用户一起完成

V模型水平虛線下部的大部分工作,相對來説,都是技術工作,在開發組織內部進行,由工程師完成

V模型優點

將負責的測試工作按階段劃分為各個小階段來實現

從多角度測試系統找出更多的缺陷

V模型缺點

軟件測試容易誤導為軟件開發的最後一個階段

需求、設計階段產生的問題不能很早發現

質量控制和測試效率無高效發揮

03 軟件測試類型
軟件測試可以從不同維度進行分類,可以從按照開發階段劃分、按照測試實施組織劃分、按照測試技術劃分、按照測試執行方式劃分、按照測試對象類型劃分。

 

image

 

單元測試又稱模塊測試,是針對軟件設計的最小單元(程序模塊)進行正確性驗證的工作。

單元測試可以作為無錯誤編碼的一種輔助手段,也可以作為規格説明書來工作

單元測試原則

應該儘早地進行軟件單元測試

應該保證單元測試的可重複性

儘可能採用測試自動化手段來支持單元測試活動

單元測試包括單元功能測試、單元接口測試、單元局部數據結構測試、單元中重要的執行路徑測試、單元的各類錯誤處理路徑測試、單元邊界條件測試

集成測試又稱組裝測試、聯合測試、子系統測試或部件測試。集成測試是在單元測試的基礎上,將所有模塊按照設計要求組成子系統或系統進行的測試活動。

集成測試的目的是要找出在模塊接口上面,包括整體系統結構上的問題。

集成策略包括增值策略和非增值策略,其優缺點如下

  優點 缺點
增值策略(漸增式組裝) 能較早發現模塊間接口錯誤;發現問題易於定位 測試周期長;投入的人力物力受限
非增值策略 方法簡單;允許多個測試人員並行工作,對人力、物力資源利用率較高 必須為每個模塊準備驅動模塊與樁模塊測試成本較高;難以定位及糾正錯誤


集成測試包括模塊間接口測試、模塊間數據傳遞、全局數據結構測試。

系統測試是對已經集成好的軟件系統進行測試,以驗證軟件系統的正確性和性能等是否滿足其規約所指定的要求。

系統測試的目的是在真實系統工作環境下通過與系統的需求定義作比較,檢驗完整的軟件配置項能否和系統正確連接,發現軟件與系統設計文檔或軟件開發合同規定不符合或與之矛盾的地方。並且還要檢驗系統的文檔是否完成、有效。

系統測試一般使用黑盒測試,並由獨立的測試人員完成。

系統測試包括從用户角度對系統做功能性的驗證和非功能性的驗證。

驗收測試是在軟件產品完成了功能測試和系統測試之後、產品發佈前進行的軟件測試活動,是技術測試的最後一個階段,也被稱為交付測試、發佈測試或確認測試。

驗收測試是按照項目任務書或合同、供需雙方約定的驗收依據文檔進行的對整個系統的測試與評審,決定是否接收系統。

驗收測試包括易用性測試、兼容性測試、安裝測試、文檔(如用户手冊、操作手冊)等內容。

驗收測試完成標準

完全執行了驗收測試計劃中的每個測試用例

在驗收測試中發現的錯誤已經得到修改並且通過了測試

完成軟件驗收測試報告

驗收測試注意事項

必須編寫正式的、單獨的驗收測試計劃

驗收測試必須在實際用户運行環境中運行

由用户和測試部門共同執行比較好

驗收測試包括對整個系統的測試與評審、根據驗收通過準則分析測試結果、決定是否接收系統及測試評價。

 

image

 

開發方測試也叫驗證測試或者Alpha測試即α測試。開發方通過檢測和提供客户證據,證實軟件的實現是否滿足規定的需要。

開發方測試特點

由公司內部的用户進行的受控測試

證實軟件滿足規定的需求

注重產品的界面和特色

用户測試也叫Beta測試(即β測試),該測試是在用户的應用環境下,用户通過運行和使用軟件,檢測與核實該軟件實現是否符合自己預期的要求。

用户測試特點

由最終用户在客户場所進行驗證

不受開發者控制

注重產品的支持性

第三方測試也稱為獨立測試,是介於軟件開發方和用户之間的測試組織的測試,其目的是為了保證測試工作的客觀性,並且儘量多地發現程序中的錯誤。

第三方測試特點

介於開發方和用户方間的組織的測試

保證測試工作的客觀性

評審需求、設計、用户類文檔

單元測試、功能測試、性能測試等

 

image

 

黑盒測試也稱為功能測試,在測試中把程序看成一個不能打開的黑盒子,在接口處進行測試而不是考慮程序內部結構。

黑盒測試優點

簡單,不需要了解程序內部代碼及實現

與軟件的內部實現無關

從用户角度出發

基於軟件開發文檔測試,能瞭解軟件實現了文檔的哪些功能

做自動化測試方便

黑盒測試缺點

代碼覆蓋率較低,只有總代碼量的30%

自動化測試的複用性較低

黑盒測試主要用於發現以下幾類錯誤

功能不正確或遺漏

界面措施

輸入和輸出錯誤

數據庫訪問錯誤

性能錯誤

初始化和終止錯誤

黑盒測試包括對界面測試、對功能測試、從用户的角度出發。

白盒測試又稱為結構測試,把程序看成是裝在一個透明的盒子裏,能清楚瞭解程序結構和處理過程。

白盒測試優點

可以檢查內存的泄露

檢查異常處理分支語句是否正確

執行了多少邏輯,可以作為衡量測試是否完整的一個指標

白盒測試原則

保證一個模塊中的所有獨立路徑至少被測一次

所有邏輯覆蓋均需測試真和假兩種情況

檢查程序的內部數據結構,保證其結構的有效性

在上下邊界及可操作範圍內運行所有循環

白盒測試包括檢查所有的結構及路徑是否正確、檢查軟件內部動作是否按照規定進行。

灰盒測試是一種綜合測試法,它將“黑盒”測試與“白盒”測試結合在一起,是基於程序運行時的外部表現又結合內部邏輯結構來設計用例,執行程序並採集路徑執行信息和外部用户接口結果的測試技術。

灰盒測試優點

能夠進行基於需求的覆蓋測試和基於程序路徑覆蓋的測試

測試結果可以對應到程序內部路徑,便於Bug的定位、分析和解決

能夠保證設計的黑盒測試用例的完整性,防止遺漏軟件的一些不常用的功能或功能組合

能夠減輕需求或設計不詳細或不完整對測試造成的影響

灰盒測試缺點

投入的時間黑盒測試大概多20%-40%的時間

對測試人員的要求比黑盒測試高

不如白盒測試深入

不適用於簡單系統(只有一個模塊的系統)

灰盒測試關注輸出對於輸入的正確性、關注內部表現、介於白盒和黑盒測試之間。

 

image

 

靜態測試是指不運行程序,通過人工對程序和文檔進行分析與檢查。它實際上是對軟件中的需求説明書、設計説明書、程序源代碼、用户手冊等進行非運行的檢查。

靜態測試方式包括人工進行和藉助軟件工具自動進行。

靜態測試包括代碼檢查、靜態結構分析、代碼質量度量。

動態測試通過運行被測程序,檢查運行結果與預期結果的差異,並分析運行效率結果與預期的差異,分析運行效率和健壯性等性能。

動態測試包括編寫測試用例、執行程序、分析程序輸出結果。

靜態測試和動態測試的區別

靜態測試是用於預防的,動態測試是用於校正

多次的靜態測試比動態測試效率要高

靜態測試綜合測試程序代碼

在相當短的時間裏,靜態測試的覆蓋率能達到100%,而動態測試是50%左右

動態測試比靜態測試更花時間

靜態測試比動態測試更能發現Bug

靜態測試的執行可以在程序編碼編譯前,動態測試只能在編譯後才能執行

04 軟件測試技術
軟件測試技術包括黑盒測試法、白盒測試法。

 

image

 

黑盒測試用例的設計方法包括測試區域確定法、組合覆蓋法、邏輯推斷法、業務路徑覆蓋法等。

 

image

 

等價類劃分法:該方法把所有可能的輸入數據即程序的輸入域劃分為若干部分(子集),然後從每個子集中選取少數具有代表性的數據作為測試用例。如學生成績是0-100分,那麼0≤X≤100就是有效等價類,X>100和X<0就是兩個無效等價類。

邊界值分析法:它是對輸入或輸出的邊界值進行測試的一種黑盒測試方法,如重量在10-50kg範圍內的包裹,其郵費計算公式為....,作為測試用例,我們應該取10及50,以及10.01、49.99、9.99、50.01等。

組合覆蓋市覆蓋率很高的一種方法。

因果圖法:它適用於描述對於多種輸入條件組合的測試方法。

判定表法:是最為嚴格、最具有邏輯性的測試方法。它能夠將複雜問題一一列舉出來,簡明且避免遺漏,同時能夠處理針對不同條件的組合值,進行不同的操作。

大綱法:是着眼於需求的測試方法。

場景分析法:包括四種類型:正常的用例場景、備選的用例場景、異常的用例場景、假定推測的場景。

功能圖法:是黑盒白盒混合用例設計方法,包括狀態遷移圖和邏輯功能模型

 

image

 

白盒測試法包括靜態白盒測試、動態白盒測試,靜態白盒測試包括代碼檢查法、靜態結構分析法、靜態質量度量法,動態白盒測試包括覆蓋測試、控制結構測試、其他白盒測試方法等。


 

歡迎大家關注筆者的公眾號:程序員老奕,專注於軟件測試幹活分享,全套測試資源可免費分享!

最後如果你想學習自動化測試,歡迎加入筆者的交流羣:771645171,裏面會有很多資源和大佬答疑解惑,我們一起交流一起學習!

歡迎大家關注筆者的公眾號:程序員老奕,專注於軟件測試幹活分享,全套測試資源可免費分享!

最後如果你想學習自動化測試,歡迎加入筆者的交流羣:771645171,裏面會有很多資源和大佬答疑解惑,我們一起交流一起學習!

Add a new Comments

Some HTML is okay.