軟體測試（理論基礎）

Chapter 1_軟體測試概述

軟體測試的IEEE定義：使用人工或自動的手段來運作或測量軟體系統的過程，目的是檢驗軟體系統是否滿足規定的需求，并找出與預期結果之間的差異。

軟體測試的發展趨勢：

① 測試工作将進一步前移。軟體測試不僅僅是單元測試、內建測試、系統測試和驗收測試，還對需求的精确性和完整性的測試技術、對系統設計的測試技術将成為新的研究熱點。

② 軟體架構師，開發工程師，QA人員，測試工程師将進行更好的融合

③ 測試職業将得到更充分的尊重。

④ 設定獨立的軟體測試部門将成為越越來軟體公司的共識。

⑤ 測試外包服務将快速增長，和軟體開發外包一樣，軟體測試外包将成為全球化的趨勢。

軟體測試工程師的素質：

責任心；溝通能力；團隊合作精神；耐心、細心和信心；保持懷疑的态度，有缺陷預防的意識；不斷學習的能力。

合格的測試工程師應具有的能力：

① 一般能力：包括表達、交流、協調、管理、品質意識、軟體開發過程方法、軟體工程等；

② 測試技能及方法：包括測試基本概念及方法、對測試工具的掌握、對專業測試标準的熟悉程度等；

③ 測試規劃能力：包括風險分析及防範能力、測試目标及計劃的制定能力等；

④ 測試執行能力：包括測試資料/腳本/用例的制定能力、測試比較及分析能力、缺陷記錄及處理能力；

⑤ 測試分析、報告和改進能力：包括測試度量、統計技術、測試報告、過程監測及持續改進能力。

測試工程師的職責：

測試人員要了解項目需求内容，從使用者的角度提出自己的測試看法；

測試人員要編寫合理的測試計劃并與項目整體計劃有機地整合在一起；

測試人員要編寫覆寫率高的測試用例；

測試人員要認真仔細的實施測試工作，并送出測試報告以供項目參考；

測試人員要進行缺陷跟蹤和分析。

Chapter 2_軟體測試基礎

軟體的概念：

軟體是計算機系統中與硬體互相依存的一部分，包括程式、資料、與其相關文檔的完整結合。軟體 = 程式 + 資料 + 文檔。

軟體的特點：

① 軟體是一種邏輯體，而不是具體的實體體，因而它具有抽象性；

② 軟體的生産與硬體不同，它沒有明顯的制造過程，對軟體品質的控制，必須在開發方面下功夫；

③ 在軟體運作和使用期間，沒有硬體那樣的機械磨損和老化問題，然而它存在退化問題，必須進行多次的修改和維護；

④ 軟體的開發和運作常常受計算機系統的制約，對計算機系統有着不同程度的依賴性，為了解除這種依賴性，在軟體開發過程中提出了軟體移植問題。

⑤ 軟體本身是複雜的，軟體的複雜性可能來自它所反映問題的複雜性，也可能來自程式邏輯結構的複雜性。

⑥ 軟體成本的昂貴。軟體的研制工作需要投入大量的、複雜的、高強度的腦力，它的成本比較高。

軟體的分類：

按照功能劃分：

系統軟體：如作業系統、資料庫管理系統，各種驅動軟體等

應用軟體：如Office、金山詞霸、QQ等

按照技術結構劃分：

單機版本：如Office，畫圖工具等

C/S結構軟體：如QQ、MSN等

B/S結構軟體：如新浪、搜狐、google等

按照使用者劃分：

産品軟體：Office、财務處理軟體、金山毒霸等

項目軟體：如為企業定制的OA系統等

按照開發規模劃分：

類别 參與人數 開發時間

小型 10人以下 1-4個月

中型 10-100人 1年以下

大型 100人以上 1年

軟體測試的概念：

軟體測試就是為了發現錯誤而執行程式的過程(狹義觀點)。

使用人工或自動的手段，來運作或測試軟體系統的過程，目的是檢驗軟

件系統是否滿足規定的需求，并找出與預期結果之間的差異。(标準定義IEEE )

軟體測試就是為了證明程式有錯，而不是證明程式無錯誤(辨證觀點) 。

測試被定義為“對軟體系統中潛在的各種風險進行評估的活動”。 (風險觀點)

軟體測試就是“驗證（Verification）”和“有效性确認（Validation）”活動構成的整體，即軟體測試V&V 。(标準觀點)

要完整了解軟體測試，就要從不同方面去審視軟體測試，概括起來，軟體測****試就是貫穿整個軟體開發生命周期，對軟體産品（包括階段性産品）進行驗證和确認的活動過程，其目的是盡快盡早地發現在軟體的缺陷。

軟體測試的對象：

① 源程式/目标代碼

② 各開發階段的文檔（需求規格說明、概要設計說明、詳細設計說明及其它相關文檔）

軟體測試的目的：

從使用者角度看的目的：通過軟體測試發現隐藏的錯誤和缺陷，考慮是否可以接受該産品。

從開發者角度看的目的：表明軟體産品不存在錯誤，驗證軟體實作了所有使用者的要求。

從測試人員角度看的目的：發現錯誤，預測錯誤，提供軟體可靠性錯誤，對軟體做出評價。

① 幫助開發人員、測試工程師發現問題、分析問題。

② 減少軟體的缺陷數目或者降低軟體缺陷的密度。

③ 提高軟體的可靠性

④ 評估軟體的性能名額。

⑤ 增加使用者對軟體的信心。

⑥ 測試的最終目的是盡快盡早地發現在軟體中的缺陷，通過修正各種錯誤和缺陷提高軟體品質，回避軟體釋出後由于潛在的軟體缺陷和錯誤造成的隐患所帶來的商業風險。

軟體測試的原則：

① 所有測試的都應追溯到使用者需求。

② 應當把“盡早地和不斷地進行軟體測試”作為軟體測試者的座右銘。

③ 由于軟體的複雜性和抽象性，在軟體生命周期各個階段都可能産生錯誤，是以不應把軟體測試僅僅看作是軟體開發的一個獨立階段的工作，而應當把它貫穿到軟體開發的各個階段中。在軟體開發的需求和設計階段就應開始測試工作，編寫相應的測試文檔。

④ 完全測試是不可能的，測試需要終止。

⑤ 想要進行完全的測試，在有限的時間和資源條件下，找出所有的軟體缺陷和錯誤 使軟體趨于完美是不可能的主要有三個原因： ①輸入量太大; ③輸出結果太多；③路徑組合太多。

⑥ 測試無法顯示軟體潛在的缺陷：進行測試是可以查找并報告發現的軟體缺陷和錯誤，但不能保證軟體缺陷和錯誤全部找到。

⑦ 充分注意集試中群集現象（二八定理）：經驗表明，在所測試程式段中，若發現的錯誤數目多，則殘存的錯誤數目也較多。缺陷的二八定理指的是，一般情況下，80%軟體缺陷出現在20%的功能區域，在測試過程中，投入主要的人力和精力重點測試這20%的功能區域。

⑧ 開發人員應避免檢查自己的程式：基于心理因素，揭露自己程式中的問題總不是一件愉快的事，不願否認自己的工作；由于思維定勢，人們難于發現自己的錯誤。是以為達到測試的目的，應由客觀、公正、嚴格的獨立的測試部門或獨立的第三方測試機構進行測試。

⑨ 盡量避免測試的随意性：應從工程的角度了解測試，它是有組織、有計劃、有步驟的活動。

軟體測試誤區：

誤區一：如果釋出出去的軟體有品質問題，都是軟體測試人員的錯。

誤區二：軟體測試技術要求不高，至少比程式設計容易多了。

誤區三：有時間就多測試一些，來不及就少測試一些。

誤區四：軟體測試是測試人員的事，與開發人員無關。

誤區五：根據軟體開發瀑布模型，軟體測試是開發後期的一個階段。

Chapter 3_軟體測試分類

單元測試：

單元測試又稱子產品測試，針對軟體設計中的最小機關——程式子產品，進行正确性檢查的測試工作。單元測試需要從程式的内部結構出發設計測試用例。多個子產品可以平行地獨立進行單元測試。

單元定義****:

C中指一個函數，Java中指一個類，在圖形化的軟體中，單元一般指1個視窗，1個菜單。

如何進行單元測試：

單元測試主要用白盒測試，先靜态地檢查代碼是否符合規範，然後動态運作代碼，檢查其實際運作結果，檢查程式的運作結果是否正确是一個最基本的要求，還要關注容錯處理，程式的邊界值處理等。

內建測試：

內建測試又叫組裝測試，通常在單元測試的基礎上，将所有程式子產品進行

有序的、遞增的測試。重點測試不同子產品的接口部分。

系統測試：

指将整個軟體系統看為一個整體進行測試，包括對功能、性能、以及軟體所運作的軟硬體環境進行測試。

驗收測試：

驗收測試指按照項目任務書或合同、供需雙方約定的驗收依據文檔進行的對整個系統的測試與評審，決定是否接收或拒收系統。在系統測試的後期，以使用者測試為主或有測試人員等品質保證人員共同參與的測試。

α測試：指的是指的是由使用者，測試人員、開發人員等共同參與的内部測試。

β測試：指的是内測後的公測，即完全交給最終使用者測試

驗收測試的重要性：驗收簽字,收錢。

靜态測試：

指不實際運作被測軟體，而隻是靜态地檢查程式代碼、界面和文檔中可能存在的錯誤的過程。

動态測試：

指實際運作被測程式，輸入相應的測試資料，檢查實際輸出結果與預期結果是否相符。（動态測試方法為結構和正确性測試；動态測試工具Robot、QTP等）

黑盒測試：

指的是把被測的軟體看做一個黑盒子，我們不關心盒子裡面的結構是什麼樣子的，隻關心軟體的輸入資料和輸出

白盒測試：

指的是把盒子打來，去研究裡面的源代碼和程式結構。

軟體公司中，往往采用黑盒測試&白盒測試相結合的方式。

（靜态黑盒測試：看文檔，看頁面等

靜态白盒測試：看源代碼等

動态黑盒測試：使用軟體等

動态白盒測試：運作源代碼等）

灰盒測試：

是介于白盒測試與黑盒測試之間的一種測試，灰盒測試多用于內建測試階段，不僅關注輸出、輸入的正确性，同時也關注程式内部的情況。

功能測試：

是黑盒測試的一方面，它檢查實際軟體的功能是否符合使用者的需求。

邏輯功能測試(functiontesting)

界面測試(UItesting)

易用性測試(usability testing)

安裝測試(installationtesting)

相容性測試(compatibilitytesting)

性能測試：

是軟體測試的高端領域，通常我們所說的進階軟體測試工程師一般就是指性能測試或是白盒測試工程師。

時間性能（事務響應時間等）

空間性能（系統資源消耗）

一般性能測試

可靠性測試

負載測試

壓力測試

回歸測試：

指對軟體的新版本測試時，重複執行上一個版本測試時的用例。

冒煙測試：

是指在對一個新版本進行系統大規模的測試之前，先驗證一下軟體的基本功能是否實作，是否具備可測試性。

随機測試：

是指測試中所有的輸入資料都是随機生成的，其目的是模拟使用者的真實操作，并發現一些邊緣性的錯誤。

軟體測試的過程：

從軟體開發的過程按階段劃分有：需求驗證、單元測試、內建測試、确認測試、系統測試、驗收測試

Chapter 5_白盒測試用例設計方法

測試用例（英文為TestCase,縮寫為TC）：

指的是在測試執行之前設計的一套詳細的測試方案，包括測試環境、測試步驟、測試資料和預期結果。

測試用例可以針對黑盒測試設計用例，也可以針對白盒測試設計用例。

編寫測試用例的唯一标準就是使用者需求,具體的參考資料是《需求規格說明書》。

設計測試用例的原因：

軟體測試是一項有組織、有計劃、有步驟的活動，為了将軟體測試的行為轉換為可管理的、具體量化的模式，需要建立和設計測試用例。

測試用例的四性：

代表性：能夠代表并覆寫各種合理的和不合理合法的和不合法的、邊界的和越界的以及極限的輸入資料、操作等。

針對性：對程式中的可能存在的錯誤有針對性地測試。

可判定性：測試執行結果的正确性是可判定的，每一個測試用例都應有相應的期望結果。

可重制性：對同樣的測試用例，系統的執行結果應當是相同的。

測試用例的基本原則：

利用成熟的測試用例設計方法來指導設計

測試用例的針對性

測試用例的代表性

測試用例的可判定性

測試用例的可重制性

足夠詳細、準确和清晰的步驟

測試用例必須符合内部的規範的要求

語句覆寫：語句覆寫就是設計若幹個測試用例，運作被測試程式，使得每一

條可執行語句至少執行一次；

判定覆寫（也稱為分支覆寫）：設計若幹個測試用例運作所測程式使程式中每個判斷的取真分支和取假分支至少執行一次；

條件覆寫：設計足夠多的測試用例，運作所測程式，使程式中每個判斷的每 條件覆寫設計足夠多的測試用例 行所測程式使程式中每個判斷的每個條件的每個可能取值至少執行一次；

判定****-條件覆寫：設計足夠多的測試用例，運作所測程式，使程式中每個判斷的每個條件的所有可能取值至少執行一次，并且每個可能的判斷結果也至少執行一次，換句話說，即是要求各個判斷的所有可能的條件取值組合至少執行一次；

條件組合測試：設計足夠多的測試用例，運作所測程式，使程式中每個判斷的所有可能的條件取值組合至少執行一次；

路徑測試：設計足夠多的測試用例，運作所測程式，要覆寫程式中所有可能的路徑。

主要測試技術：

分支條件覆寫，基本路徑測試

Chapter 6_黑盒測試用例設計方法

等價類劃分（邊界值分析），因果圖法，（正交實驗法）

Chapter 8_缺陷管理

軟體缺陷：

軟體缺陷是指存在于軟體（程式、資料、文檔）中的那些不符合使用者需求的問題。

軟體缺陷的來源：

需求說明書：需求說明書的錯誤或不清楚引起的錯誤，是缺陷第一大的來源。

設計文檔：設計文檔描述不準确、以及與需求說明書不一緻，是缺陷的第二大來源。

編碼：純粹是由編碼的問題引起。

其它：可能是系統內建、測試引起。

軟體缺陷的根源：

交流不充分（客戶與開發人員、開發人員與測試人員等）

軟體的複雜性（功能複雜、開發複雜、測試複雜）

開發人員的錯誤（對需求的了解、開發壓力、能力與經驗）

需求的變化（需求說明書設計文檔 程式的變更）

進度壓力（項目周期比較緊）

軟體缺陷的發現手段：

同行評審、測試、管理評審、QA發現、項目組内部發現、客戶回報

為了便于缺陷的定位、跟蹤和修改，要對所發現的缺陷，按照缺陷的嚴重程度、優先級、發現階段、修複階段、缺陷的性質、所屬功能子產品、系統環境等方面進行分類和統計。

二八定理：80%的軟體問題總是發生在大約20%的功能子產品中。

缺陷密度：

基本的缺陷測量是以每千行代碼的缺陷數(個/KLOC)來測量的，其測量機關是defects／KLOC。

常見尋找bug的方法：

色彩、功能結構布局、圖檔、頁面大小、字型、窗體大小、界面文字、容錯處理（也為功能缺陷，所謂容錯，就是容忍錯誤的能力。當使用者在使用軟體過程中發生錯誤後，軟體應該能給出引導資訊，指應使用者進行正确的操作）、資料轉換（增删改查）、性能缺陷（黑盒測試）。

Web測試：

Web測試即測試網站系統在不同用戶端（浏覽器）的運作情況及相容性。

Selenium****：

Selenium是一個用于Web應用程式測試的工具。Selenium測試直接運作在浏覽器中,就像真正的使用者在操作一樣。

主攻測開及接口自動化方向，分享爬蟲擷取的稀缺精品資源，歡迎關注微信擷取。