常用軟件測試方法及類型解析【樂搏TestPRO】 一、軟件測試概述 二、常用的軟件測試方法 三、軟件測試的類型 五、成爲優秀測試工程師的要求

常用軟件測試方法及類型解析

 一、軟件測試概述

  軟件測試是軟件開發過程的重要組成部分,是用來確認一個程序的品質或性能是否符合開發之前所提出的一些要求。軟件測試的目的,第一是確認軟件的質量,其一方面是確認軟件做了你所期望的事情(Do the right thing),另一方面是確認軟件以正確的方式來做了這個事件(Do it right)。第二是提供信息,比如提供給開發人員或程序經理的反饋信息,爲風險評估所準備的信息。第三軟件測試不僅是在測試軟件產品的本身,而且還包括軟件開發的過程。如果一個軟件產品開發完成之後發現了很多問題,這說明此軟件開發過程很可能是有缺陷的。因此軟件測試的第三個目的是保證整個軟件開發過程是高質量的。

  軟件質量是由幾個方面來衡量的:一、在正確的時間用正確的的方法把一個工作做正確(Doing the right things right at the right time.)。二、符合一些應用標準的要求,比如不同國家的用戶不同的操作習慣和要求,項目工程中的可維護性、可測試性等要求。三、質量本身就是軟件達到了最開始所設定的要求,而代碼的優美或精巧的技巧並不代表軟件的高質量(Quality is defined as conformance to requirements, not as “goodness” or “elegance”.)。四、質量也代表着它符合客戶的需要(Quality also means “meet customer needs”.)。作爲軟件測試這個行業,最重要的一件事就是從客戶的需求出發,從客戶的角度去看產品,客戶會怎麼去使用這個產品,使用過程中會遇到什麼樣的問題。只有這些問題都解決了,軟件產品的質量纔可以說是上去了。

  測試人員在軟件開發過程中的任務:

  1、尋找Bug;

  2、避免軟件開發過程中的缺陷;

  3、衡量軟件的品質;

  4、關注用戶的需求。

  總的目標是:確保軟件的質量。

  二、常用的軟件測試方法

  1. 黑盒測試

  黑盒測試顧名思義就是將被測系統看成一個黑盒,從外界取得輸入,然後再輸出。整個測試基於需求文檔,看是否能滿足需求文檔中的所有要求。黑盒測試要求測試者在測試時不能使用與被測系統內部結構相關的知識或經驗,它適用於對系統的功能進行測試。

  黑盒測試的優點有:

  1)比較簡單,不需要了解程序內部的代碼及實現;

  2)與軟件的內部實現無關;

  3)從用戶角度出發,能很容易的知道用戶會用到哪些功能,會遇到哪些問題;

  4)基於軟件開發文檔,所以也能知道軟件實現了文檔中的哪些功能;

  5)在做軟件自動化測試時較爲方便。

  黑盒測試的缺點有:

  1)不可能覆蓋所有的代碼,覆蓋率較低,大概只能達到總代碼量的30%;

  2)自動化測試的複用性較低。

  2. 白盒測試

  白盒測試是指在測試時能夠了解被測對象的結構,可以查閱被測代碼內容的測試工作。它需要知道程序內部的設計結構及具體的代碼實現,並以此爲基礎來設計測試用例。如下例程序代碼:

  HRESULT Play( char* pszFileName )

  {

  if ( NULL == pszFileName )

  return;

  if ( STATE_OPENED == currentState )

  {

  PlayTheFile();

  }

  return;

  }

  讀了代碼之後可以知道,先要檢查一個字符串是否爲空,然後再根據播放器當前的狀態來執行相應的動作。可以這樣設計一些測試用例:比如字符串(文件)爲空的話會出現什麼情況;如果此時播放器的狀態是文件剛打開,會是什麼情況;如果文件已經在播放,再調用這個函數會是什麼情況。也就是說,根據播放器內部狀態的不同,可以設計很多不同的測試用例。這些是在純粹做黑盒測試時不一定能做到的事情。

  白盒測試的直接好處就是知道所設計的測試用例在代碼級上哪些地方被忽略掉,它的優點是幫助軟件測試人員增大代碼的覆蓋率,提高代碼的質量,發現代碼中隱藏的問題。

   白盒測試的缺點有:

   1)程序運行會有很多不同的路徑,不可能測試所有的運行路徑;

   2)測試基於代碼,只能測試開發人員做的對不對,而不能知道設計的正確與否,可能會漏掉一些功能需求;

   3)系統龐大時,測試開銷會非常大。

   3. 基於風險的測試

   基於風險的測試是指評估測試的優先級,先做高優先級的測試,如果時間或精力不夠,低優先級的測試可以暫時先不做。有如下一個圖,橫軸代表影響,豎軸代表概率,根據一個軟件的特點來確定:如果一個功能出了問題,它對整個產品的影響有多大,這個功能出問題的概率有多大?如果出問題的概率很大,出了問題對整個產品的影響也很大,那麼在測試時就一定要覆蓋到。對於一個用戶很少用到的功能,出問題的概率很小,就算出了問題的影響也不是很大,那麼如果時間比較緊的話,就可以考慮不測試。   

  基於風險測試的兩個決定因素就是:該功能出問題對用戶的影響有多大,出問題的概率有多大。其它一些影響因素還有複雜性、可用性、依賴性、可修改性等。測試人員主要根據事情的輕重緩急來決定測試工作的重點。

   4. 基於模型的測試

   模型實際上就是用語言把一個系統的行爲描述出來,定義出它可能的各種狀態,以及它們之間的轉換關係,即狀態轉換圖。模型是系統的抽象。基於模型的測試是利用模型來生成相應的測試用例,然後根據實際結果和原先預想的結果的差異來測試系統,過程如下圖所示。   

 [NextPage]

 三、軟件測試的類型

   常見的軟件測試類型有:

   BVT (Build Verification Test) 

  BVT是在所有開發工程師都已經檢入自己的代碼,項目組編譯生成當天的版本之後進行,主要目的是驗證最新生成的軟件版本在功能上是否完整,主要的軟件特性是否正確。如無大的問題,就可以進行相應的功能測試。BVT優點是時間短,驗證了軟件的基本功能。缺點是該種測試的覆蓋率很低。因爲運行時間短,不可能把所有的情況都測試到。   Scenario Tests(基於用戶實際應用場景的測試)

   在做BVT、功能測試的時候,可能測試主要集中在某個模塊,或比較分離的功能上。當用戶來使用這個應用程序的時候,各個模塊是作爲一個整體來使用的,那麼在做測試的時候,就需要模仿用戶這樣一個真實的使用環境,即用戶會有哪些用法,會用這個應用程序做哪些事情,操作會是一個怎樣的流程。加了這些測試用例後,再與BVT、功能測試配合,就能使軟件整體都能符合用戶使用的要求。Scenario Tests優點是關注了用戶的需求,缺點是有時候難以真正模仿用戶真實的使用情況。

   Smoke Test

   在測試中發現問題,找到了一個Bug,然後開發人員會來修復這個Bug。這時想知道這次修復是否真的解決了程序的Bug,或者是否會對其它模塊造成影響,就需要針對此問題進行專門測試,這個過程就被稱爲Smoke Test。在很多情況下,做Smoke Test是開發人員在試圖解決一個問題的時候,造成了其它功能模塊一系列的連鎖反應,原因可能是隻集中考慮了一開始的那個問題,而忽略其它的問題,這就可能引起了新的Bug。Smoke Test優點是節省測試時間,防止build失敗。缺點是覆蓋率還是比較低。

   此外,Application Compatibility Test(兼容性測試),主要目的是爲了兼容第三方軟件,確保第三方軟件能正常運行,用戶不受影響。Accessibility Test(軟件適用性測試),是確保軟件對於某些有殘疾的人士也能正常的使用,但優先級比較低。其它的測試還有Functional Test(功能測試)、Security Test(安全性測試)、Stress Test(壓力測試)、Performance Test(性能測試)、Regression Test(迴歸測試)、Setup/Upgrade Test(安裝升級測試)等。

四、微軟的軟件測試工作 

  1. 基本情況

       測試在微軟公司是一項非常重要的工作,微軟公司在此方面的投入是非常巨大的。微軟對測試的重視表現在工程開發隊伍的人員構成上,微軟的項目經理、軟件開發人員和測試人員的比例基本是1:3:3或1:4:4,可以看出開發人員與測試人員的比例是1:1。對於測試的重視還表現在最後產品要發佈的時候,此產品的所有相關部門都必須簽字,而測試人員則具有絕對的否決權。

       測試人員中分成兩種職位,Software Development Engineer in Test(測試組的軟件開發工程師)實際上還是屬於開發人員,他們具備編寫代碼的能力和開發工具軟件的經驗,側重於開發自動化測試工具和測試腳本,實現測試的自動化。Software Test Engineer(軟件測試工程師)具體負責測試軟件產品,主要完成一些手工測試以及安裝配置測試。

    2. 測試計劃

       測試計劃是測試人員管理測試項目,在軟件中尋找Bug的一種有效的工具。測試計劃主要有兩個作用,一是評判團隊的測試覆蓋率以及效率,讓測試工作很有條理的逐步展開。二是有利於與項目經理、開發人員進行溝通。有了測試計劃之後,他們就能夠知道你是如何開展測試工作的,他們也會從中提出很多有益的意見,確保測試工作順利進行。總之,有了測試計劃可以更好的完成測試工作,確保用戶的滿意度。

       測試人員在編寫測試計劃之前,應獲得以下文檔:

       1)程序經理編寫的產品功能說明書或產品開發計劃

       2)程序經理或開發人員提供的開發進度表。

       根據產品的特性及開發進度安排,測試人員制定具體的測試計劃。測試計劃通常包括以下內容:

       1)測試目標和發佈條件:

       a. 給出清晰的測試目標描述;

       b. 定義產品的發佈條件,即在達到何種測試目標的前提下才可以發佈產品的某個特定版本。

       2)待測產品範圍:

       a. 軟件主要特性/功能說明,即待測軟件主要特性的列表;

       b. 特性/功能測試一覽,應涵蓋所有特性、對話框、菜單和錯誤信息等待測內容,並列舉每個測試範圍內要重點考慮的關鍵功能。

       3)測試方法描述:

       a. 定義測試軟件產品時使用的測試方法;

       b. 描述每一種特定的測試方法可以覆蓋哪些測試範圍。

       4)測試進度表:

       a. 定義測試里程碑;

       b. 定義當前里程碑的詳細測試進度。

       5)測試資源和相關的程序經理/開發工程師:

       a. 定義參與測試的人員;

       b. 描述每位測試人員的職責範圍;

       c. 給出與測試有關的程序經理/開發工程師的相關信息。

       6)配置範圍和測試工具:

       a. 給出測試時使用的所有計算機平臺列表;

       b. 描述測試覆蓋了哪些硬件設備;

       c. 測試時使用的主要測試工具。

      此外,還應列出測試中可能會面臨的風險及測試的依賴性,即測試是否依賴於某個產品或某個團隊。比如此項測試依賴性WindowsCE這個操作系統,而這個系統要明年2月份才能做好,那麼此項測試就可能只有在明年5月份才能完成,這樣就存在着依賴關係。如果那個團隊的開發計劃往後推,則此項測試也會被推遲。

       3. 測試用例開發

       一個好的測試用例就是有一個合理的概率來找到Bug,不要冗餘,要有針對性,一個測試只針對一件事情。特別是功能測試的時候,如果一個測試是測了兩項功能,那麼如果測試結果失敗的話,就不知道到底是哪項功能出了問題。

       測試用例開發中主要使用的技術有等價類劃分,邊界值的分析,Error Guessing Testing。

       等價類劃分是根據輸入輸出條件,以及自身的一些特性分成兩個或更多個子集,來減少所需要測試的用例個數,並且能用很少的測試用例來覆蓋很多的情況,減少測試用例的冗餘度。在等價類劃分中,最基本的劃分是一個爲合法的類,一個爲不合法的類。

       邊界值的分析是利用了一個規律,即程序最容易發生錯誤的地方就是在邊界值的附近,它取決於變量的類型,以及變量的取值範圍。一般對於有n個變量時,會有6n+1個測試用例,取值分別是min-1, min, min+1, normal, max-1, max,max+1的組合。邊界值的分析的缺點,是對邏輯變量和布爾型變量不起作用,還有可能會忽略掉某些輸入的組合。

       Error Guessing Testing完全靠的是經驗,所設計的測試用例就是常說的猜測。感覺到軟件在某個地方可能出錯,就去設計相應的測試用例,這主要是靠實際工作中所積累的經驗和知識。其優點是速度快,只要想得到,就能很快設計出測試用例。缺點就是沒有系統性,無法知道覆蓋率會有多少,很可能會遺漏一些測試領域。

       實際上在微軟是採用一些專門的軟件或工具負責測試用例的管理,有一些測試信息可以被記錄下來,比如測試用例的簡單描述,在哪些平臺執行,是手工測試還是自動測試,運行的頻率是每天運行一次,還是每週運行一次。此外還有清晰的測試通過或失敗的標準,以及詳細記錄測試的每個步驟。

       4. Bug跟蹤過程

       在軟件開發項目中,測試人員的一項最重要使命就是對所有已知Bug進行有效的跟蹤和管理,保證產品中出現的所有問題都可以得到有效的解決。一般地,項目組發現、定位、處理和最終解決一個Bug的過程包括Bug報告、Bug評估和分配、Bug處理、Bug關閉等四個階段:

       1)測試工程師在測試過程中發現新的Bug後,應向項目組報告該Bug的位置、表現、當前狀態等信息。項目組在Bug數據庫中添加該Bug的記錄。

       2)開發經理對已發現的Bug進行集中討論,根據Bug對軟件產品的影響來評估Bug的優先級,制定Bug的修正策略。按照Bug的優先級順序和開發人員的工作安排,開發經理將所有需要立即處理的Bug分配給相應的開發工程師。

      3)開發工程師根據安排對特定的Bug進行處理,找出代碼中的錯誤原因,修改代碼,重新生成產品版本

       4)開發工程師處理了Bug之後,測試人員需要對處理後的結果進行驗證,經過驗證確認已正確處理的Bug被標記爲關閉(Close)狀態。測試工程師既需要驗證Bug是否已經被修正,也需要確定開發人員有沒有在修改代碼的同時引入新的Bug。

       5. Bug的不同處理方式

       在某些情況下,Bug已處理並不意味着Bug已經被修正。開發工程師可以推遲Bug的修正時間,也可以在分析之後告知測試工程師這實際上不是一個真正的Bug。也就是說,某特定的Bug經開發工程師處理之後,該Bug可能包括以下幾種狀態。

       已修正:開發工程師已經修正了相應的程序代碼,該Bug不會出現了。

       可推遲:該Bug的重要程度較低,不會影響當前應提交版本的主要功能,可安排在下一版本中再行處理。

       設計問題:該Bug與程序實現無關,其所表現出來的行爲完全符合設計要求,對此應提交給程序經理處理。

       無需修正:該Bug的重要程度非常低,根本不會影響程序的功能,項目組沒有必要在這些Bug上浪費時間。

  五、成爲優秀測試工程師的要求   

要成爲一名優秀的測試工程師,首先對計算機的基本知識要有很好的瞭解,精通一門或多門的編程語言,具備一定的程序調試技能,掌握測試工具的開發和使用技術。同時要比較細心,會按照任務的輕重緩急來安排自己的工作,要有很好的溝通能力。此外,還要善於用非常規的方式思考問題,儘可能多的參加軟件測試項目,在實踐中學習技能,積累經驗,不斷分析和總結軟件開發過程中可能出錯的環節。這樣,一名優秀的測試工程師就從軟件測試的實踐中脫穎而出了。 

需要上市公司測試用例模板的,可以掃碼領取

 


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章