軟體測試基礎與常識

軟體測試基礎

 

一、軟體測試概述

軟體測試是軟體開發過程的重要組成部分，是用來確認一個程式的品質或效能是否符合開發之前所提出的一些要求。軟體測試的目的，第一是確認軟體的品質，其一方 面是確認軟體做了你所期望的事情（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）發現代碼中隱藏的問題
白盒測試的缺點有：
1）程式運行會有很多不同的路徑，不可能測試所有的運行路徑；
2）測試基於代碼，只能測試開發人員做的對不對，而不能知道設計的正確與否，可能會漏掉一些功能需求；
3）系統龐大時，測試開銷會非常大。

3. 基於風險的測試

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

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

4. 基於模型的測試

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

三、軟體測試的類型

常見的軟體測試類型有：

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上浪費時間。

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

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

結束語： 微軟的軟體開發經驗積澱深厚，微軟工程師們的授課生動溢彩，其中有些內容是結合編程代碼所作的詳細講解，較難用介紹性文字加以概括提煉，加之筆者受 能力和精力所限，只能擷取部分精華內容整理成文以饗讀者，因此難免是掛一漏萬，甚至會有失誤之處，敬請對本系列文章的粉絲諒解及指正。最後對微軟老師們 的辛勤付出再表由衷謝意！

 

轉載聲明： 本文轉自 http://yueyelmm.blog.163.com/blog/static/2981247320099993240603/

=============================================================================

 

軟體測試常識

 

軟體開發和使用的曆史已經留給了我們很多由於軟體缺陷而導致的巨大財力、物力損失的經驗教訓。這些經驗教訓迫使我們這些測試工程師們必須採取強有力的檢測措施來檢測未發現的隱藏的軟體缺陷。

生產軟體的最終目的是為了滿足客戶需求，我們以客戶需求作為評判軟體品質的標準，認為軟體缺陷（ Software Bug ）的具體含義包括下面幾個因素：
1  軟體未達到客戶需求的功能和效能；
2  軟體超出客戶需求的範圍；
3  軟體出現客戶需求不能容忍的錯誤；
4  軟體的使用未能符合客戶的習慣和工作環境。

考慮到設計等方面的因素，我們還可以認為軟體缺陷還可以包括軟體設計不符合規範，未能在特定的條件（資金、範圍等）達到最佳等。可惜的是，我們中的很多人更傾向於把軟體缺陷看成運行時出現問題上來，認為軟體測試僅限於程式提交之後。

在目前的國內環境下，我們幾乎看不到完整準確的客戶需求說明書，加以客戶的需求時時在變，追求完美的測試變得不太可能。因此作為一個優異的測試人員，追求軟 件品質的完美固然是我們的宗旨，但是明確軟體測試現實與理想的差距，在軟體測試中學會取捨和讓步，對軟體測試是有百益而無一弊的。

下面是一些軟體測試的常識，對這些常識的理解和運用將有助於我們在進行軟體測試時能夠更好的把握軟體測試的尺度。

1  測試是不完全的（測試不完全）

很顯然，由於軟體需求的不完整性、軟體邏輯路徑的組合性、輸入資料的大量性及結果多樣性等因素，哪怕是一個極其簡單的程式，要想窮盡所有邏輯路徑，所有輸入 資料和驗證所有結果是非常困難的一件事情。我們舉一個簡單的例子，比如說求兩個整數的最大公約數。其輸入資訊為兩個正整數。但是如果我們將整個正整數域的 數字進行一番測試的話，從其數目的無限性我們便可證明是這樣的測試在實際生活中是行不通的，即便某一天我們能夠窮盡該程式，只怕我們乃至我們的子孫都早已 作古了。為此作為軟體測試，我們一般採用等價類別和邊界值分析等措施來進行實際的軟體測試，尋找最小用例集合成為我們精簡測試複雜性的一條必經之道。

2  測試具有免疫性（軟體缺陷免疫性）

軟體缺陷與病毒一樣具有可怕的 “ 免疫性 ” ，測試人員對其採用的測試越多，其免疫能力就越強，尋找更多軟體缺陷就更加困難。由數學上的機率論我們可以推出這一結論。假設一個 50000 行的程式中有 500 個軟體缺陷並且這些軟體錯誤分布時均勻的，則每 100 行可以找到一個軟體缺陷。我們假設測試人員用某種方法花在尋找軟體缺陷的精力為 X 小時 /100 行。照此推算，軟體存在 500 個缺陷時，我們尋找一個軟體缺陷需要 X 小時，當軟體只存在 5 個錯誤時，我們每尋找一個軟體缺陷需要 100X 小時。實踐證明，實際的測試過程比上面的假設更為苛刻，為此我們必須更換不同的測試方式和測試資料。該例子還說明了在軟體測試中採用單一的方法不能高效和 完全的針對所有軟體缺陷，因此軟體測試應該儘可能的多採用多種途徑進行測試。

3  測試是 “ 泛型概念 ” （全程測試）

我一直反對軟體測試僅存在於程式完成之後。如果單純的只將程式設計階段後的階段稱之為軟體測試的話，需求階段和設計階段的缺陷產生的放大效應會加大。這非常 不利於保證軟體品質。需求缺陷、設計缺陷也是軟體缺陷，記住 “ 軟體缺陷具有生育能力 ” 。軟體測試應該跨越整個軟體開發流程。需求驗證（自檢）和設計驗證（自檢）也可以算作軟體測試（建議稱為：需求測試和設計測試）的一種。軟體測試應該是一 個泛型概念，涵蓋整個軟體生命週期，這樣才能確保周期的每個階段禁得起考驗。同時測試本身也需要有第三者進行評估（資訊系統審計和軟體工程監理），即測試 本身也應當被測試，從而確保測試自身的可靠性和高效性。否則自身不正，難以服人。

另外還需指出的是軟體測試是提高軟體產品品質的必要條件而非充分條件，軟體測試是提高產品品質最直接、最快捷的手段，但決不是一個根本手段。

4  80-20 原則

80% 的軟體缺陷常常生存在軟體 20% 的空間裡。這個原則告訴我們，如果你想使軟體測試有效地話，記住常常光臨其高危多發 “ 地段 ” 。在那裡發現軟體缺陷的可能性會大的多。這一原則對於軟體測試人員提高測試效率及缺陷發現率有著重大的意義。聰明的測試人員會根據這個原則很快找出較多的 缺陷而愚蠢的測試人員卻仍在漫無目的地到處搜尋。

80-20 原則的另外一種情況是，我們在系統分析、系統設計、系統實現階段的複審，測試工作中能夠發現和避免 80% 的軟體缺陷，此後的系統測試能夠協助我們找出剩餘缺陷中的 80% ，最後的 5% 的軟體缺陷可能只有在系統交付使用後使用者經過大範圍、長時間使用後才會曝露出來。因為軟體測試只能夠保證儘可能多地發現軟體缺陷，卻無法保證能夠發現所有 的軟體缺陷。

80-20 原則還能反映到軟體測試的自動化方面上來，實踐證明 80% 的軟體缺陷可以藉助人工測試而發現， 20% 的軟體缺陷可以藉助自動化測試能夠得以發現。由於這二者間具有交叉的部分，因此尚有 5% 左右的軟體缺陷需要通過其他方式進行發現和修正。

5  為效益而測試

為什麼我們要實施軟體測試，是為了提高項目的品質效益最終以提高項目的總體效益。為此我們不難得出我們在實施軟體測試應該掌握的度。軟體測試應該在軟體測試 成本和軟體品質效益兩者間找到一個平衡點。這個平衡點就是我們在實施軟體測試時應該遵守的度。單方面的追求都必然損害軟體測試存在的價值和意義。一般說 來，在軟體測試中我們應該盡量地保持軟體測試簡單性，切勿將軟體測試過度複雜化，拿物理學家愛因斯坦的話說就是： Keep it simple but not too simple 。

6  缺陷的必然性

軟體測試中，由於錯誤的關聯性，並不是所有的軟體缺陷都 能夠得以修複。某些軟體缺陷雖然能夠得以修複但在修複的過程中我們會難免引入新的軟體缺陷。很多軟體缺陷之間是相互矛盾的，一個矛盾的消失必然會引發另外 一個矛盾的產生。比如我們在解決通用性的缺陷後往往會帶來執行效率上的缺陷。更何況在缺陷的修複過程中，我們常常還會受時間、成本等方面的限制因此無法有 效、完整地修複所有的軟體缺陷。因此評估軟體缺陷的重要度、影響範圍，選擇一個折中的方案或是從非軟體的因素（比如提升硬體效能）考慮軟體缺陷成為我們在 面對軟體缺陷時一個必須直面的事實。

7  軟體測試必須有預期結果

沒有預期結果的測試是不可理喻的。軟體缺陷是經過對 比而得出來的。這正如沒有標準無法進行度量一樣。如果我們事先不知道或是無法肯定預期的結果，我們必然無法瞭解測試正確性。這很容易然人感覺如盲人摸象一 般，不少測試人員常常憑藉自身的感覺去評判軟體缺陷的發生，其結果往往是把似是而非的東西作為正確的結果來判斷，因此常常出現誤測的現象。

8  軟體測試的意義 - 事後分析

軟體測試的目的單單是發現缺陷這麼簡單嗎？如果是 “ 是 ” 的話，我敢保，類似的軟體缺陷在下一次新項目的軟體測試中還會發生。古語說得好， “ 不知道曆史的人必然會重蹈覆轍 ” 。沒有對軟體測試結果進行認真的分析，我們就無法瞭解缺陷發生的原因和應對措施，結果是我們不得不耗費的大量的人力和物力來再次尋找軟體缺陷。很可惜，目 前大多測試團隊都沒有意識到這一點，測試報告中缺乏測試結果分析這一環節。

結論：
軟體測試是一個需要 “ 自覺 ” 的過程，作為一個測試人員，遇事沉著，把持尺度，從根本上應對軟體測試有著正確的認識，希望本文對讀者對軟體測試的認識有所協助

 

轉載聲明： 本文轉自 http://yueyelmm.blog.163.com/blog/static/2981247320099993142749/

=============================================================================