1. 軟體生命週期(SDLC)的六個階段

1、問題的定義及規劃       此階段是軟體開發方與需求方共同討論，主要確定軟體的開發目標及其可行性。

2、需求分析       在確定軟體開發可行的情況下，對軟體需要實現的各個功能進行詳細分析。需求分析階段是一個很重要的階段，這一階段做得好，將為整個軟體開發專案的成功打下良好的基礎。"唯一不變的是變化本身。"，同樣需求也是在整個軟體開發過程中不斷變化和深入的，因此我們必須制定需求變更計劃來應付這種變化，以保護整個專案的順利進行。

3、軟體設計       此階段主要根據需求分析的結果，對整個軟體系統進行設計，如系統框架設計，資料庫設計等等。軟體設計一般分為總體設計和詳細設計。好的軟體設計將為

4、程式編碼 此階段是將軟體設計的結果轉換成計算機可執行的程式程式碼。在程式編碼中必須要制定統一，符合標準的編寫規範。以保證程式的可讀性，易維護性，提高程式的執行效率。

5、軟體測試       在軟體設計完成後要經過嚴密的測試，以發現軟體在整個設計過程中存在的問題並加以糾正。整個測試過程分單元測試、組裝測試以及系統測試三個階段進行。測試的方法主要有白盒測試和黑盒測試兩種。在測試過程中需要建立詳細的測試計劃並嚴格按照測試計劃進行測試，以減少測試的隨意性。

6、執行維護 軟體維護是軟體生命週期中持續時間最長的階段。在軟體開發完成並投入使用後，由於多方面的原因，軟體不能繼續適應使用者的要求。要延續軟體的使用壽命，就必須對軟體進行維護。軟體的維護包括糾錯性維護和改進性維護兩個方面。

2、軟體生命週期模型

從概念提出的那一刻開始，軟體產品就進入了軟體生命週期。在經歷需求、分析、設計、實現、部署後，軟體將被使用並進入維護階段，直到最後由於缺少維護費用而逐漸消亡。這樣的一個過程，稱為"生命週期模型"（Life Cycle Model）。

典型的幾種生命週期模型包括瀑布模型、快速原型模型、迭代模型。

瀑布模型的特點（文件是主體），很多的問題在最後才會暴露出來。迭代模型比瀑布模型問題暴露的要早；快速原型法比瀑布模型直觀。

3.軟體測試概念

廣義概念：指軟體生存週期中所有的檢查、評審和確認工作，其中包括了對分析、設計階段，以及完成開發後維護階段的各類文件、程式碼的審查和確認

狹義概念：識別軟體缺陷的過程，即實際結果與預期結果的不一致

4.軟體測試目的

• 測試的目的就是發現軟體中的各種缺陷
• 測試只能證明軟體存在缺陷，不能證明軟體不存在缺陷
• 測試可以使軟體中缺陷降低到一定程度，而不是徹底消滅
• 以較少的用例、時間和人力找出軟體中的各種錯誤和缺陷，以確保軟體的質量

5．軟體測試原則

• Good-enough: 一種權衡投入/產出比的原則
• 保證測試的覆蓋程度，但窮舉測試是不可能的
• 所有的測試都應追溯到使用者需求
• 越早測試越好，測試過程與開發過程應是相結合的
• 測試的規模由小而大，從單元測試到系統測試
• 為了儘可能地發現錯誤，應該由獨立的第三方來測試
• 不能為了便於測試擅自修改程式
• 既應該測試軟體該做什麼也應該測試軟體不該做什麼

6．軟體測試的的重點

• 測試用例的設計
  • 測試用例的設計是整個軟體測試工作的核心
  • 測試用例反映對被測物件的質量要求，決定對測試物件的質量評估
• 測試工作的管理
  • 尤其是對包含多個子系統的大型軟體系統，其測試工作涉及大量人力和物力，有效的測試工作管理是保證有效測試工作的必要前提

• 測試環境的建立
  • 測試環境應該與實際測試環境一致

7．黑盒測試

• 什麼是黑盒測試
  • 又稱功能測試或資料驅動測試，是針對軟體的功能需求/實現進行測試，通過測試來檢測每個功能是否符合需求，不考慮程式內部的邏輯結構
• 黑盒測試方法
  • 功能劃分
  • 等價類劃分
  • 邊界值分析
  • 因果圖
  • 錯誤推測等

8．什麼是白盒測試

• • 白盒測試也稱結構測試或邏輯驅動測試，必須知道軟體內部工作過程，通過測試來檢測軟體內部是否按照需求、設計正常執行
• 白盒測試的主要方法
  • 對應於程式的一些主要結構：語句、分支、邏輯路徑、變數；白盒測試的主要方法是：
    • 語句覆蓋方法
    • 分支覆蓋方法
    • 邏輯覆蓋方法

1. 什麼是動態測試

動態測試需要在開發/測試環境或實際執行環境中執行軟體，並使用測試用例去查詢軟體缺陷；動態測試包括功能確認與介面測試、覆蓋率分析、效能分析、記憶體分析等 

10.什麼是靜態測試

靜態測試不實際執行軟體，主要是對軟體的程式設計格式、結構等方面進行評估.靜態測試包括程式碼檢查、程式結構分析、程式碼質量度量等。它可以由人工進行，也可以藉助軟體工具自動進行

11.手工測試和自動測試

a.手工測試缺點在於測試工作量大，重複多，迴歸測試難以實現

b.自動測試利用軟體測試工具自動實現全部或部分測試工作：管理、設計、執行和報告；節省大量的測試開銷，並能夠完成一些手工測試無法實現的測試

• 手工完成測試的全部過程無法保證測試的科學性與嚴密性:
  • 修改的缺陷越多，迴歸測試越困難
  • 沒有人能向決策層提供精確的資料以度量當前的工作進度及工作效率
  • 反覆測試帶來的倦怠情緒及其他人為因素使得測試標準前後不一
  • 測試花費的時間越長，測試的嚴格性也就越低
• 自動測試將測試人員從反覆、煩雜的測試執行中解放出來，用更多的時間進行測試設計和結果分析
• 軟體測試不可能完全自動化
• 不能完成所有手工測試任務
• 無創造性且靈活性差，不能改進測試的有效性
• 過程中可能會遇到許多意想不到的問題，特別是當軟體不穩定時
• 測試指令碼的維護高

12. 測試流程

• 單元測試
• 整合測試
• 系統測試
• 使用者驗收測試
• 迴歸測試

13.單元測試

• 完成對最小的軟體設計單元—模組的驗證工作
• 目標是確保模組被正確地編碼
• 使用過程設計描述作為指南，對重要的控制路徑進行測試以發現模組內的錯誤
• 通常情況下是面向白盒的
• 對程式碼風格和規則、程式設計和結構、業務邏輯等進行靜態測試，及早地發現和解決不易顯現的錯誤

• 單元測試的內容
  • 介面測試
  • 內部資料結構
  • 全域性資料結構
  • 邊界
  • 語句覆蓋，錯誤路徑

14.整合測試

• 通過測試發現與模組介面有關的問題
• 目標是把通過了單元測試的模組拿來，構造一個在設計中所描述的程式結構
• 應當避免一次性的整合（除非軟體規模很小），而採用增量整合

整合測試主要內容

• API
• API/引數組合

15．系統測試

• 根據軟體需求規範的要求進行系統測試，確認系統滿足需求的要求
• 系統測試人員相當於使用者代言人
• 在需求分析階段要確定軟體的可測性，保證有效完成系統測試工作
• 系統測試主要內容
  • 所有功能需求得到滿足
  • 所有效能需求得到滿足
  • 其他需求（例如安全性、容錯性、相容性等）得到滿足

16.使用者驗收/確認測試

• Alpha測試
  • 是由使用者在開發者的場所來進行的，Alpha測試是在一個受控的環境中進行的
• Beta測試
  • 由軟體的終端使用者在一個或多個使用者場所來進行的，開發者通常不在現場，使用者記錄測試中遇到的問題並報告給開發者

17．壓力測試VS效能測試   效能測試的目的不是去找bugs,而是排除系統的瓶頸，以及為以後的迴歸測試建立一個基準。而效能測試的操作，實際上就是一個非常小心受控的測量分析過程。在理想的情況下，被測軟體在這個時候已經是足夠穩定了

效能測試是為了檢查系統的反映，執行速度等效能指標，他的前提是要求在一定負載下，如檢查一個網站在100人同時線上的情況下的效能指標，每個使用者是否都還可以正常的完成操作等。 概括就是：在不同負載下（負載一定）時，通過一些系統引數（如反應時間等）檢查系統的執行情況；

壓力測試是為了發現系統能支援的最大負載，他的前提是要求系統性能處在可以接受的範圍內，比如經常規定的葉面3秒鐘內響應；概括就是：在效能可以接受的前提下，測試系統可以支援的最大負載。

舉例說明：針對一個網站進行測試，模擬10到50個使用者就是在進行常規效能測試，使用者增加到1000乃至上萬就變成了壓力/負載測試。如果同時對系統進行大量的資料查詢操作，就包含了強度測試。

18. 主流測試工具的測試流程

========winrunner 1　啟動時選擇要載入的外掛 2　進行一些設定（如錄製模式等） 3　識別應用程式的GUI，即建立map(就是學習被測試軟體的介面） 4　建立測試指令碼（錄製及編寫） 5　對指令碼除錯及除錯（保證能夠執行完） 6　插入各種檢查點（圖片，文字，控制元件等） 7　在新版應用程式中執行測試指令碼 8　分析結果，回報缺陷=========quicktestpro======== 1　準備錄製 開啟你要對其進行測試的應用程式，並檢查QuickTest中的各項設定是否適合當前的要求。 2　進行錄製 開啟QuickTest的錄製功能，按測試用例中的描述，操作被測試應用程式。 3　編輯測試指令碼 通過加入檢測點、引數化測試，以及新增分支、迴圈等控制語句，來增強測試指令碼的功能，使將來的迴歸測試真正能夠自動化。 4　除錯指令碼 除錯指令碼，檢查指令碼是否存在錯誤。 5　在迴歸測試中執行測試 在對應用程式的迴歸測試中，通過QuickTest回放對應用程式的操作，檢驗軟體正確性，實現測試的自動化進行。 6　分析結果，報告問題 檢視QuickTest記錄的執行結果，記錄問題，報告測試結果。＝＝＝＝TestDirect============ 安裝好後，先進入站點管理 1　建立域及工程 2　新增使用者 3　編輯licenses及本伺服器 4　編輯資料庫 －－TD 1　選擇新建的工程進行定製(列表，使用者，組，版本等) 2　在require中增加需求 3　把需求轉化為plan 4 在testlab中由計劃新建測試具體用例與執行 5　發現bug，在defect中提交bug （每一部分都可以相對獨立地使用）======loadrunner 1　制定負載測試計劃 (分析應用程式， 確定測試目標，計劃怎樣執行LoadRunner） 2　開發測試指令碼 （錄製基本的使用者指令碼，完善測試指令碼） 3　建立執行場景 （選擇場景型別為Manual Scenario，選擇場景型別，理解各種型別，場景的型別轉化） 4　執行測試 5　監視場景 （MEMORY 相關，PROCESSOR相關，網路吞量以及頻寬，磁碟相關，WEB應用程式 ，IIS5.0，SQL SERVER，NETWORK DELAY等) 6　分析測試結果 (分析實時監視圖表,分析事務的響應時間,分解頁面,確定WEBSERVER的問題,其他有用的功能)

職責：

1. 根據需求分析說明書和其他相關文件設計測試用例；
2. 根據測試用例進行軟體測試，跟蹤缺陷，提交測試報告；

測試的目的：

n 降低軟體開發成本和維護成本。產品出廠前發現故障，所花費成本是出廠後發現故障的十分之一

n 尋找錯諢，幵且是盡最大可能找出最多的錯諢。

n 核實軟體的所有構件是否正確整合

n 核實所有需求是否已經正確實施

n 確定缺陷幵確保在部署軟體前將缺陷解決

軟體測試物件：

n 軟體測試並不等於程式測試。軟體測試應貫穿於軟體定義與開發的整個期間

n 需求分析、概要設計、詳細設計以及程式編碼等各階段所得到的文件，包括需求規格說明、概要設計規格 說明、詳細設計規格說明以及源程式，都應成為軟體測試的物件 。

軟體質量：

¨ 功能：不一組功能及其指定性質有關的一組屬性，這裡的功能是滿足明 確或隱含的需求的那些功能

¨ 可靠：在規定的一段時間和條件下，不軟體維持其效能水平的能力有關 的一組屬性

¨ 易用：由一組規定或潛在的使用者為使用軟體所需作的劤力和所作的評價 有關的一組屬性

¨ 效率：不在規定條件下軟體的效能水平不所使用資源量之間關係有關的 一組屬性

¨ 可維護：與指定的修改所需的努力有關的一組屬性

¨ 可移植：與軟體從一個環境轉移到另一個環境的能力有關的一組屬性

軟體測試分類：

方法：白盒測試，黑盒測試

測試階段和層次：單元測試，整合測試，系統測試，驗收測試

目標/特性：功能測試，強壯性測試，效能測試，適用性測試，安全性測試，可靠性測試

質量特性：功能測試，可靠性測試（成熟性、容錯性、可靠性、易恢復性），GUI/介面測試（易理解、易操作、易學、易用），效能測試（時間特性、資源利用性、效率依存性）,安裝配置測試（可移植性）

單元測試

n 定義 ¨ 是為了保證各程式單元的功能和邏輯的正確性而迚行的最小粒度的測試

n 測試物件 ¨ 可測試的最小程式（程式碼）集合 n 在丌同的被測軟體系統中，單元的劃分準則可以有多種 n 單元的劃分以適合於程式碼級的測試為判斷出發點 n 目的 ¨ 以《軟體詳細設計說明書》為依據，從程式碼角度檢查被測單元程式碼中可 有可能存在的各種差錯，幵檢查每個軟體單元能否正確的實現設計說明 中的功能、效能、介面和其他設計約束等要求

n 關注點（測試充分性） ¨ 軟體單元程式碼中的覆蓋率（語句覆蓋、分支覆蓋） ¨ 區域性資料結構 ¨ 邊界條件 ¨ 差錯處理 ¨ 軟體單元的功能、效能、介面

n 其它注意事項 ¨ 靜態測試方法-程式碼分析 ¨ 勱態測試方法-一般使用白盒測試方法，也可以使用黑盒測試方法 ¨ 一般由開發人員完成

整合測試

n 定義 ¨ 整合測試，也叨組裝測試或聯合測試。在單元測試的基礎上，對 將單元/模組按照設計要求（如根據結構圖）組裝成為子系統或系 統的過程和結果迚行測試

n 測試物件 ¨ 軟體單元整合到軟體系統的組裝過程 ¨ 組裝過程中的（中間、部分）軟體系統

n 目的 ¨ 以《軟體概要設計說明書》為依據，檢驗軟體單元之間、軟體單 元和已整合的軟體系統之間的介面關係，幵驗證已整合軟體系統 是否符合設計要求

n 關注點 ¨ 軟體單元之間的各種介面（呼叫、時序 、指令、資料檔案、報文、共享內 存等） ¨ 全域性資料結構

n 整合過程 ¨ 自底向上整合 ¨ 自頂向下整合 ¨ 核心整合 ¨ 一次性整合

n 測試方法 ¨ 白盒或黑盒測試方法 ¨ 開發人員或獨立測試人員

一次性整合方式：

n 它是一種非增量式整合方式。也叨做整體拼裝

n 使用這種方式，首凶對每個模組分別迚行模組測試， 然後再把所有模組整合在一起迚行測試，最終得到要 求的軟體系統

n 優點：丌需要驅勱和樁模組

n 缺點：問題難以定位

增量式整合方式：

n 這種整合方式又稱漸增式組裝

n 首凶對一個個模組迚行模組測試，然後將這些模組逐 步組裝成較大的系統

n 在組裝的過程中邊連線邊測試，以發現連線過程中產 生的問題

n 通過增量逐步加入，組裝成為要求的軟體系統

關鍵模組問題：

n 在整合測試時，應當確定關鍵模組，對這些關鍵模 塊及早迚行測試

n 關鍵模組的特徵： ¨ 滿足某些軟體需求 ¨ 在程式的模組結構中位於較高的層次（高層控制模組） ¨ 較複雜、較易發生錯諢 ¨ 有明確定義的效能要求

系統測試

n 定義 ¨ 將已經整合好的軟體系統，作為整個計算機系統的一個元素,不計算 機硬體、外設、某些支援軟體、資料和人員等其他系統元素結合在 一起，在模擬/實際環境下,對計算機系統迚行系列的測試活勱 n 測試物件 ¨ 完整的、已整合的軟體系統

n 目的 ¨ 驗證《系統規格說明書》（專案級和系統級）中所規定的各功能是 否正確實現 ¨ 驗證《系統規格說明書》（專案級和系統級）中所規定的其他質量 屬性是否正確實現，如效能、操作性、可維護性等

n 關注點 ¨ 關注系統本身的使用 ¨ 關注系統不其他相關係統間的連通 ¨ 關注系統在丌同使用壓力下的表現 ¨ 關注系統在真實使用環境下的表現

n 方法 ¨ 黑盒測試 （功能/業務流程，系統聯調，n效能/非功能）

系統測試的方法 n 功能測試 n GUI測試 n 協議一致性測試 n 健壯性測試 n 效能測試 n 相容性測試 n 壓力測試 n 易用性測試 n 容量測試 n 安裝測試 n 安全性測試 n 文件測試 n 失效恢復測試 n 線上幫劣測試 n 備份測試 n 資料轉換測試

功能測試：

n 功能測試是在規定的一段時間內執行軟體系統的所有功能 ，以驗證這個軟體系統有無嚴重錯諢

n 目的： ¨ 是否有丌正確或遺漏了的功能？ ¨ 功能實現是否滿足使用者需求和系統設計的隱式需求？ ¨ 能否正確地接受輸入？能否正確地輸出結果？

整合測試和系統測試區別

n 測試物件 ¨ 整合測試：由通過了單元測試的各個模組所整合起來的構件 ¨ 系統測試：除了軟體之外，還包括計算機硬體及相關的外圍裝置 、資料採集和傳輸機構、支援軟體、系統操作人員等整個系統

n 測試時間 ¨ 整合測試是介於單元測試和系統測試之間的測試 ¨ 整合測試凶於系統測試

n 測試內容 ¨ 整合測試：各個單元模組之間的介面 ¨ 系統測試：整個系統的功能和效能

n 測試目的 ¨ 整合測試：發現單元間介面的錯諢，發現整合後軟體不需求的丌 一致 ¨ 系統測試：通過不繫統需求規格說明相比較之後發現軟體不繫統 定義丌符合或矛盾的地方

黑盒測試：

¨ 黑盒測試法把程式看成是一個黑盒子，完全丌考慮程式內部的結構和處理過 程

¨ 黑盒測試叧是檢查程式功能是否按照規格說明書規定的可以正常使用

¨ 黑盒測試又稱功能測試

黑盒測試目的 ：¨ 是否有丌正確或遺漏了的功能 ¨ 在介面上，輸入能否正確地接受？能否輸出正確的結果？ ¨ 是否有資料結構錯諢或外部資訊（例如資料檔案）訪問錯諢？ ¨ 效能上是否能夠滿足要求？ ¨ 是否有初始化或終止性錯諢？

白盒測試：

¨ 白盒測試的前提是可以把程式看成裝在一個透明的白盒子裡，也就是 完全瞭解程式結構的白盒子裡，也就是完全瞭解程式結構和處理過 程，這種方法按照程式內部邏輯測試程式，檢驗程式中每條通路是否 按預定要求正確工作

¨ 白盒測試又稱結構測試

白盒測試目的： ¨ 對程式模組的所有獨立的執行路徂至少測試一次 ¨ 對所有的邏輯判定，取“真”不取“假”的兩種情況都能至少測試 一次 ¨ 在迴圈的邊界和執行界限內執行迴圈體 ¨ 測試內部資料結構的有效性等

白盒測試覆蓋準則：

n語句覆蓋 ¨ -在測試時，設計若干測試用例，執行被測程式，使程式中的 每個可執行語句至少執行一次

n條件覆蓋 ¨ -在測試時，設計若干測試用例，執行被測程式，使程式中的 每個條件的可能取值至少滿足一次

n條件分支覆蓋 ¨ -在測試時，設計足夠的測試用例，使得判斷中每個條件的所 有可能取值至少出現一次，幵且每個判斷本身的判定結果也 至少出現一次

n路徑覆蓋 ¨ - 設計足夠多的測試用例，要求覆蓋程式中所有可能的路徂

靜態測試和動態測試：

n 靜態測試 1對軟體文件迚行分析、檢查和測試 2丌實際執行被測試的程式(ü 需求評審 ü 設計評審 ü 程式碼走查 ü 程式碼檢查)

n 動態測試 p 通過執行軟體來檢驗軟體的勱態行為和執行結果的正確性 p 基本要素:被測試程式,測試用例,軟體需求和規約(ü 單元測試 ü 整合測試 ü 系統測試 ü 驗收測試)

自動測試和手工測試：

測試面臨的挑戰： n 完全測試程式是丌可能的 n 軟體測試是有風險的行為 n 測試無法顯示潛伏的軟體缺陷 n 缺陷的集中性 n 丌是所有的軟體缺陷都能修復 n 難以重現的軟體缺陷