初級軟體測試工程師零基礎入門指南_測試

１.基本概念

　１.１軟體

　軟體就是可以在電腦上啟動並執行電腦程式，如作業系統Windows、辦公軟體Office、聊天ＱＱ、手機遊戲等。軟體和我們的生活和工作之間的聯絡越來越密切。

 

１.２軟體測試

　軟體測試的經典定義是：在規定的條件下對程式進行操作，以發現程式錯誤，衡量軟體品質，並對其是否能滿足設計要求進行評估的過程。

　軟體測試的現實定義是：軟體測試是貫穿整個軟體開發生命週期、對軟體產品（包括階段性產品）進行驗證和確認的活動過程，其目的是儘快儘早地發現在軟體產品中所存在的各種問題——與使用者需求、預先定義的不一致性。

 

１.３測試的方法

 

軟體測試一般分為白盒測試和黑箱測試。

 

黑箱測試

黑箱測試，軟體測試的主要方法之一，也可以稱為功能測試、資料驅動測試或基於規格說明的測試。測試應用程式的功能，而不是其內部結構或運作。測試者不需具備應用程式的代碼、內部結構和程式設計語言的專門知識。測試者只需知道什麼是系統應該做的事，即當鍵入一個特定的輸入，可得到一定的輸出，這是從使用者的角度針對軟體介面、功能及外部結構進行測試，而不考慮程式內部邏輯結構。測試案例是應用系統應該做的功能，照規範、規格或要求等設計。測試者選擇有效輸入和無效輸入來驗證是否正確的輸出。此測試方法可適合大部分的軟體測試，例如單元測試(unit testing)、整合測試(integration testing)以及系統測試(system testing)。

 

白盒測試

 

白盒測試（又稱透明盒測試、結構測試等）是一個測試軟體的方法，測試應用程式的內部結構或運作，而不是測試應用程式的功能（即黑箱測試）。在白箱測試時，以程式設計語言的角度來設計測試案例。測試者輸入資料驗證資料流在程式中的移動路徑，並確定適當的輸出，類似測試電路中的節點。

白箱測試可以應用於單元測試、整合測試和系統的軟體測試流程，可測試在整合過程中每一單元之間的路徑，或者主系統跟子系統中的測試。儘管這種測試的方法可以發現許多的錯誤或問題，它可能無法檢測未使用部分的規範。

 

 

１.４測試的類型

 

功能測試  

按照測試軟體的各個功能劃分進行有條理的測試，在功能測試部分要保證測試項覆蓋所有功能和各種功能條件組合。

更詳細的描述請參見“黑箱測試”。

 

系統測試  

對一個完整的軟體以使用者的角度來進行測試，系統測試和功能測試的區別是，系統測試利用的所有測試資料和測試的方法都要類比成和使用者的實際使用環境完全一樣，測試的軟體也是經過系統整合以後的完整軟體系統，而不是在功能測試階段利用的每個功能模組單獨編譯後產生的可執行程式。

 

極限值測試       

對軟體在各種特殊條件，特殊環境下能否正常運行和軟體的效能進行測試。

特殊條件一般指的是軟體規定的最大值，最小值，以及在超過最大，小值條件下的測試。

特殊環境一般指的是軟體啟動並執行機器處於CPU高負荷，或是網路高負荷狀態下的測試，根據軟體的不同，特殊環境也有過不同。

 

效能測試  

效能測試是對軟體效能的評價。簡單的說，軟體效能衡量的是軟體具有的響應及時度能力。因此，效能測試是採用測試手段對軟體的響應及時性進行評價的一種方式。根據軟體的不同類型，效能測試的側重點也不同。

 

　壓力測試

壓力測試，確立系統穩定性的一種測試方法，在軟體工程、金融風險管理等領域應用比較普遍。通常在系統正常運作範圍之外進行，以考察其功能極限和隱患。

 

壓力測試與效能測試的區別

壓力測試常常和效能測試相混淆。它們主要不同點是，壓力測試要求進行超過規定效能指標的測試。例如一個網站設計容量是100個人同時點擊，壓力測試就要是採用120個同時點擊的條件測試。

 

１.５測試的階段

 

單元測試

單元測試是對軟體組成單元進行測試，其目的是檢驗軟體基本組成單位的正確性，測試的對象是軟體設計的最小單位---模組。單元測試一般由開發人員完成。

 

整合測試

整合測試又稱組裝測試，是將程式模組採用適當的整合策略組裝起來，對系統的介面及整合後的功能進行正確性檢測的測試工作。其主要目的是檢查軟體單位之間的介面是否正確，整合測試的對象是已經經過單元測試的模組。

實踐表明，有時模組雖然可以單獨工作，但是並不能保證組裝起來也可以同時工作。

 

系統測試

系統測試主要包括功能測試、介面測試、可靠性測試、易用性測試、效能測試。 功能測試主要針對包括功能可用性、功能實現程度（功能流程&商務程序、資料處理&業務資料處理）方面測試。

 

迴歸測試

迴歸測試是為了檢測代碼修改而引入的錯誤所進行的測試活動。迴歸測試是軟體測試階段的重要工作，有研究表明，迴歸測試帶來的耗費佔軟體生命週期的1/3總費用以上。

與普通的測試不同，在迴歸測試過程開始的時候，測試者有一個完整的測試案例集可供使用，因此，如何根據代碼的修改情況對已有測試案例集進行有效複用是迴歸測試研究的重要方向，此外，迴歸測試的研究方向還涉及自動化工具，物件導向迴歸測試，測試案例優先順序，迴歸測試用例補充產生等。

 

Alpha測試

α測試通常是階段性的開發完成後所開始進行，一直持續到進入Beta測試階段前的階段。α測試是一種驗證測試，在類比的環境中以類比的資料來運行。

在這個階段中，通常是在開發單位由開發人員與測試的測試人員，以類比或實際操作性的方式進行驗證測試。

 

Beta測試

在系統測試中通常先進行α測試以驗證資訊系統符合使用者以及設計需求所期望的功能。當α階段完成後，開發過程進入到β階段；由公眾參與的測試的階段。β測試可稱為確認測試，在一個真實的環境中以實際的資料來運行測試，以確認效能、系統運行有效率，系統撤消與備份作業正常，通過測試讓資訊系統日後可以

 

　Beta測試和黑箱測試的區別

對Alpha和Beta測試常見的一個認識誤區是“Beta測試＝黑箱測試”。實際上，Alpha和Beta測試對應在軟體產品發布之前的Alpha和Beta階段，而白盒、黑盒和灰盒測試技術是從技術和方法層面對測試的描述，不應該將這兩部分概念混淆。

 

　驗收測試

驗收測試是系統部署到使用者環境後，使用者運行系統，考察系統是否滿足使用者需求的過程。驗收測試是使用者主導的，使用者可能聘請專家協助驗收測試。

 

１.６軟體測試的作用

 

1.對產品品質完成全面的評估，為軟體產品發布（如驗收測試）、軟體系統部署（如效能規劃測試）、軟體產品評鑑（第三方獨立測試）委託方和被委託方糾紛仲裁（第三方獨立測試）和其它決策提供資訊；

 

2.通過持續的測試（包括需求評審、設計評審、程式碼檢閱等）可以對產品品質提供持續的、快速的反饋，從而在整個開發過程中不斷地、及時地改進產品的品質，並減少各種返工，降低軟體開發的成本；

 

3.通過測試發現所要交付產品的缺陷，特別是儘可能地發現各種嚴重的缺陷，降低或消除產品品質風險，提高客戶的滿意度，擴大市場份額，提高客戶的忠誠度。

 

4.通過對缺陷進行分析，找出缺陷發生的根本原因（軟體過程中的問題，包括錯誤的行為方式）或總結出軟體產品的缺陷模式，避免將來犯同樣的錯誤或產生類似的產品問題，達到缺陷預防的目的

 

２.初級軟體測試工程師主要工作

２.１編寫功能測試用例

 

１）測試案例設計步驟

 　　設計測試案例的時候，需要有清晰的測試思路，對要測試什麼，按照什麼已排序的測試，覆蓋哪些需求做到心中有數。測試案例編寫者不僅要掌握軟體測試的技術和流程，而且要對被測軟體的設計、功能規格說明、使用者試用情境以及程式/模組的結構都有比較透徹的理解。測試案例設計一般包括以下幾個步驟：
1、測試需求分析
　　從軟體需求文檔中，找出待測試軟體/模組的需求，通過自己的分析、理解，整理成為測試需求，清楚被測試對象具有哪些功能。測試需求的特點是：包含軟體需求，具有可測試性。
　　測試需求應該在軟體需求基礎上進行歸納、分類或細分，方便測試案例設計。測試案例中的測試集與測試需求的關係是多對一的關係，即一個或多個測試案例集對應一個測試需求。
2、商務程序分析
　　軟體測試，不單純是基於功能的黑箱測試，還需要對軟體的內部處理邏輯進行測試。為了不遺漏測試點，需要清楚的瞭解軟體產品的商務程序。建議在做複雜的測試案例設計前，先畫出軟體的商務程序。如果設計文檔中已經有商務程序設計，可以從測試角度對現有流程進行補充。如果無法從設計中得到商務程序，測試工程師應通過閱讀設計文檔，與開發人員交流，最終畫出商務程序圖。商務程序圖可以協助理解軟體的處理邏輯和資料流向，從而指導測試案例的設計。
從商務程序上，應得到以下資訊：
A、 主流程是什麼
B、 條件備選流程是什麼
C、 資料流向是什麼
D、 關鍵的判斷條件是什麼
3、測試案例設計
　　完成了測試需求分析和軟體流程分析後，開始著手設計測試案例。測試案例設計的類型包括功能測試，邊界測試，異常測試，效能測試，壓力測試等。在用例設計中，除了功能測試用例外，應盡量考慮邊界、異常、效能的情況，以便發現更多的隱藏問題。
黑箱測試的測試案例設計方法有：等價類別劃分、邊界值劃分、因果圖分析和錯誤猜測，白盒測試的測試案例設計方法有：語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、多重條件覆蓋。在這裡主要討論黑箱測試。在設計測試案例的時候可以使用軟體測試案例設計方法，結合前面的需求分析和軟體流程分析進行設計：
功能測試：測試某個功能是否滿足需求的定義，功能是否正確，完備。
適合的技術：由業務需求和設計說明匯出的功能測試、等價類別劃分
邊界測試：對某個功能的邊界情況進行測試。
          適合的技術：邊界值劃分
異常測試：對某些功能來說，其邊界情況無法簡單的瞭解或某些操作不完全是正確的但又是可能發生的，類似這樣的情況需要書寫相關的異常測試。
          適合的技術：由業務需求和設計說明匯出的特殊商務程序、錯誤猜測法、邊界值分析、內部邊界值測試、
效能測試：檢查系統是否滿足在需求中所規定達到的效能，效能主要包括瞭解程式的內外部效能因素。內部效能因素包括測試環境的配置，系統資源使用狀況；外部因素包括回應時間，輸送量等。
         適合的技術：業務需求和設計說明匯出的測試
壓力測試：壓力測試又稱強度測試，主要是檢查系統運行環境在極限情況下軟體啟動並執行能力，比如說給一個相當大的負荷或網路流量給應用軟體相容測試：測試軟體產品在不同的平台，不同的工具，相同工具的不同版本下功能的相容性。
4、測試案例評審
測試案例設計完成後，為了確認測試過程和方法是否正確，是否有遺漏的測試點，需要進行測試案例的評審。
測試案例評審一般是由測試leader安排，參加的人員包括：測試案例設計者、測試leader、專案經理、開發工程師、其它相關開發測試工程師。測試案例評審完畢，測試工程師根據評審結果，對測試案例進行修改，並記錄修改日誌。

5、測試案例更新完善
測試案例編寫完成之後需要不斷完善，軟體產品新增功能或更新需求後，測試案例必須配套修改更新；在測試過程中發現設計測試案例時考慮不周，需要對測試案例進行修改完善；在軟體交付使用後客戶回函的軟體缺陷，而缺陷又是因測試案例存在漏洞造成，也需要對測試案例進行完善。一般小的修改完善可在原測試案例文檔上修改，但文檔要有更改記錄。軟體的版本升級更新，測試案例一般也應隨之編製升級更新版本。測試案例是“活”的，在軟體的生命週期中不斷更新與完善。

 

２）測試案例設計方法

 

黑箱測試的測試案例設計方法有：等價類別劃分、邊界值劃分、因果圖分析和錯誤猜測，白盒測試的測試案例設計方法有：語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、多重條件覆蓋。在這裡，主要討論的是黑箱測試的測試案例的設計方法。

一、等價類別劃分

等價列劃分設計方法是把所有可能的輸入資料劃分成若干部分（子集），然後從每一個子集中選取少量具有代表性的資料作為測試案例，測試某等價類別的代表值就等於對這一類其他值的測試。

使用等價類別劃分方法設計測試案例主要有兩個步驟：（1）確定等價類別；（2）產生測試案例。

1、劃分等價類別

等價類別劃分有兩種不同的情況：有效等價類別代表對程式的有效輸入和無效等價類別代表不正確的輸入值，設計時要同時考慮這兩種等價類別。下面是確定等價類別的原則：

（1）在輸入條件規定了取值範圍的情況下，則可以確立一個有效等價類別（在取值範圍之內）和兩個無效等價類別（小於取值範圍和大於取值範圍）。 例如：使用手機傳送簡訊的時候，簡訊內容長度必須在70個字元之內，則有效等價類別：簡訊內容長度在70個字元之內，無效等價類別：簡訊內容長度為0、簡訊內容長度大於70。

（2）在輸入條件規定了取值的個數的情況下，則可以確立一個有效等價類別（在取值個數範圍之內）和兩個無效等價類別（小於取值個數和大於取值個數）。例如：一名學生一個學期可以選修一至五門課程，則有效等價類別為：1<=學生選修課程<=5，無效等價類別為：沒有選修課程、選修課程大於5

（3）在輸入條件規定了輸入值的集合的情況下，則可以確立一個有效等價類別和一個無效等價類別。 比如：傳送簡訊的編碼的取值範圍是0、3、4、8、15或16，則有效等價類別是：簡訊編碼為0或3或4或8或15或16，無效等價類別是：簡訊編碼不是0或3或4或8或15或16其中任何一種。

（4）在輸入條件規定了 “必須如何”的條件的情況下，則可以確立一個有效等價類別和一個無效等價類別。 例如：變數的命名比如以大寫字母開頭，則有效等價類別為：變數命名以大寫字母開頭，無效等價類別為：變數開頭非答寫字母開頭。

（5）在輸入條件是一個布爾量的情況下，可以確立一個有效等價類別和一個無效等價類別。 例如：在神州行手機號碼預計費成功的情況下，允許該使用者傳送簡訊，則有效等價類別為：神州行預計費成功，無效等價類別為神州行預計費失敗。

（6）在規定了輸入資料的一組值（假定n個），並且程式要對每一個輸入值分別處理的情況下，可以確立n個有效等價類別和一個無效等價類別。

（7）在規定了輸入資料必須遵守的規則的情況下，可以確立一個有效等價類別（符合規則）和若干個無效等價類別（從不同角度違反規則）。

（8） 在確知已劃分的等價類別中各元素在程式處理中的方式不同的情況下，則應再將該等價類別進一步的劃分為更小的等價類別。

2、產生測試案例

在確立了等價類別後，可建立等價類別表，列出所有劃分出的等價類別，過程為：

（1）為每一個等價類別規定一個唯一的編號。

（2）設計一個新的測試案例，使其儘可能多的覆蓋尚未被覆蓋的有效等價類別，重複這一步，直到所有的有效等價類別都被覆蓋為止。

（3）設計一個新的測試案例，使其僅覆蓋一個尚未被覆蓋的無效等價類別，重複這一步，直到所有的無效等價類別都被覆蓋為止。

二、邊界值分析法

邊界條件指的是輸入和輸入等價類別中剛好處於邊界、或超過邊界或小於邊界的狀態，使用邊界值分析方法設計測試案例應先確定邊界情況，然後選取正好等於、剛剛大於或剛剛小於邊界的值作為測試資料。

基於邊界值分析方法選擇測試案例的原則：

（1）如果輸入條件規定了值的範圍，則應取剛達到這個範圍的邊界值設計有效測試案例，以及剛剛超過這個範圍的邊界值作設計無效測試案例。比如：簡訊內容的有效長度為70個漢字以內，則有效測試案例：簡訊內容長度為1，簡訊內容長度為70個漢字，無效測試案例：簡訊內容長度為0，簡訊內容長度為71個漢字。

（2）如果輸入條件規定了值的數量，則應取最大個數、最小個數、比最小個數少一、比最大個數多一的數作為測試輸入的資料。 例如：簡訊的有效編碼為1~255，則應取0、1、255、256設計邊界值測試案例。

（3）根據規格說明的每個輸出條件，使用前面的原則1。

（4）根據規格說明的每個輸出條件，使用前面的原則2。

（5）如果程式的輸入或輸出是一個有序集合，則應選取集合的第一個元素和最後一個元素設計測試案例。

（6）如果程式中使用了一個內部資料結構，應當選擇這個內部資料結構邊界上的值設計測試案例。

（7）分析規格說明書，找出其他可能的邊界條件。

三、因果圖法

因果圖法是一種適合於描述對於多種條件的組合、相應產生多個動作的形式的測試案例設計方法。

利用因果圖產生測試案例的步驟為：

（1）將規範說明書分解成可執行檔片段。

（2）確定規格說明書中的因果關係。分析軟體規格說明描述中那些是原因，那些是結果，並給每個原因和結果賦予一個標識符。

（3）分析軟體規格說明描述的語義，找出原因和結果之間、原因和原因之間的關係，並將其轉換成因果圖。

（4）在因果圖上加上註解符號，用一些記號表明約束或限制條件。

（5）跟蹤圖中的狀態變化情況，把因果圖轉換為判定表。

（6）把判定表的每一列拿出來作為依據，設計測試案例。

四、錯誤推測法

錯誤推測法就是根據經驗和直覺推測程式中所有可能存在的各種錯誤，從而有針對性地設計測試案例的方法。

錯誤推測法的基本思路是列舉出程式中所有可能有的錯誤和容易發生錯誤的清單，根據清單設計測試案例；另一個思路就是在閱讀規格說明時有哪些容易被程式員忽略的內容來設計測試案例。

錯誤推測法是一種非常有效測試案例設計方法，這要求測試人員有豐富的測試經驗和對業務的處理非常熟悉。比如，在簡訊發送的時候，如果傳送簡訊之後，對方網關沒有響應或者逾時響應或者沒有回複狀態報表，那程式怎樣處理呢。

 

進階參考：

測試案例設計

http://www.cnblogs.com/mayingbao/category/82529.html

 

　　如何編寫有效測試案例

http://blog.csdn.net/smilings/article/details/840917

 

２.２執行功能測試

　　根據測試計劃和測試案例進行測試，在測試過程中記錄測試結果和提交發現的Bug。下班前將當天的測試情況彙報給測試組長或測試經理。

 

２.３提交Bug

 

２.２.１Bug基本概念