（1）軟件基本概念

軟件（software）是指一系列按照某種特定規則組織在一起，實現用戶需求的計算機數據和指令的集合體。從狹義理解即運行在計算機、手機、手持設備等電子設備上的應用程序，都稱為軟件。從廣義理解，軟件不僅僅包含實現用戶需求的源代碼（計算機數據、指令），還包含與之相匹配的數據文檔、支撐源代碼運行的配置數據。三者構成一個完整的軟件實體。

（2）軟件生命周期

計劃-需求分析-計劃-編碼-測試-運維

計劃工作內容：

?確定軟件開發總目標；

?給出軟件的功能、性能、可靠性以及接口等方面的設想；

?研究完成該項目的可行性，探討問題解決方案；

?對可供開發使用的資源、成本、可取得的效益和開發進度作出估計；

?制定完成開發任務的實施計劃。

需求分析：

有需求分析人員和客戶共同商討制定軟件需求說明書srs（SoftwareRequirement? Specification2%22%7D;）

設計：

?設計是軟件工程的技術核心，這個階段需要完成設計說明書

?概要設計（HLD），在設計階段把各項需求轉換成相應的體系結構，每一部分是功能明確的模塊；

? 詳細設計（LLD），對每個模塊要完成的工作進行具體的描述

編碼:

?把軟件設計轉換成計算機可以接受的程序，即寫成以某個程序設計語言表示的源程序清單，使用RDBMS工具建立數據庫。

測試：

?測試是檢驗軟件是否符合客戶需求，達到質量要求，一般由獨立的小組執行，測試工作分為：

?單元測試

?集成測試

?系統測試

運維：

這個階段將軟件交付用戶投入正式使用，以后便進入維護階段，可能有多種原因需要對它進行修改，如軟件錯誤、系統軟件升級、增強軟件功能、提高性能等。

（3）軟件開發模式

軟件研發模型（software development model）是軟件生產過程中分析、設計、研發活動所遵循的框架模式。

瀑布模型

嚴格遵循預先計劃的需求分析、設計、編碼、集成、測試、維護的步驟順序進行。

主要的問題

?嚴格分級導致的自由度降低

?開發成果輸出過晚，風險高

?后期需求的變化難以調整，代價高昂

瀑布式方法在需求不明并且在項目進行過程中可能變化的情況下基本是不可行的

原型模型

用戶很難將需求表達得既具體又明確，用戶與需求開發人員的知識背景不同。當需求表述錯誤時，在瀑布模型下往往到后期才能發現。原型模型在很大程度上解決了這個問題。原型模型是在瀑布模型基礎上演進的一種較為先進的研發模型。利用該模型，產品設計者實現用戶與軟件系統的交互，當原型研發生產完成后，由用戶根據自身的實際需求對原型進行評價，從而進一步細化待開發軟件的需求

迭代模型

?迭代模型(iterative ? model)是由IBM公司提出的一種軟件開發方法，該方法包括一系列的增量的步驟或迭代，每個迭代都包括很多的開發活動(需求、分析、設計、實現等)

?實現軟件的每項功能反復求精的過程，是從模糊到清晰的開發過程。每次迭代是從功能的深度和細化程度來劃分的。

?迭代模型最適合使用與前期需求不穩定，需求多變的項目

增量模型

增量模型是把待開發的軟件系統模塊化，將每個模塊作為一個增量組件，從而分批次地分析、設計、編碼和測試這些增量組件。運用增量模型的軟件開發過程是遞增式的過程。相對于瀑布模型而言，采用增量模型進行開發，開發人員不需要一次性地把整個軟件產品提交給用戶，而是可以分批次進行提交。

敏捷開發

?敏捷軟件開發又稱敏捷開發， 是一種從1990年代開始逐漸引起廣泛關注的一些新型軟件開發方法，是一種應對快速變化的需求的一種軟件開發能力。

?在敏捷開發中，軟件項目在構建初期被切分成多個子項目，各個子項目的成果都經過測試，具備可視、可集成和可運行使用的特征。換言之，就是把一個大項目分為多個相互聯系，但也可獨立運行的小項目，并分別完成，在此過程中軟件一直處于可使用狀態。

-人和交互?? 重于過程和工具。

-可以工作的軟件??? 重于求全而完備的文檔。

-客戶協作???? 重于合同談判。

-隨時應對變化???? 重于循規蹈矩。

?因此敏捷方法更適用于較小的隊伍，40、30、20、10人或者更少。

原則： 主張簡單 擁抱變化 遞增的變化 快速反饋

（4）測試定義，目的，原則：

定義：使用人工和自動手段來運行或測試某個系統的過程，其目的在于檢驗它是否滿足規定的需求或是弄清預期結果與實際結果之間的差別

目的：

1.發現被測對象與用戶需求之間的差異，即缺陷

2.通過測試發現并解決問題，讓客戶對軟解質量有信心

3.通過測試了解軟件質量，為決策提供數據

4.通過測試積累經驗，預防缺陷出現，降低產品失敗風險

原則：

1.測試證明軟件存在缺陷

2.不能執行無窮盡的測試

3.測試應盡早介入

4.缺陷存在群集現象（二八原理）

5.殺蟲劑悖論

6.不同的測試活動依賴于不同的測試背景

7.不存在缺陷謬論

（5）測試階段

單元測試（unit testing）

集成測試（integration testing）

系統測試（system testing）

驗收測試（acceptance testing）

UT

單元測試是針對軟件基本組成單元函數內部的語句、條件分支來進行正確性檢驗的測試工作

單元測試的目的是檢測軟件模塊對《詳細設計說明書》LLD的符合程度

IT（集成測試）

集成測試是在單元測試的基礎上，將所有模塊按照概要設計要求組裝成為子系統或系統，驗證組裝后功能以及模塊間接口是否正確的測試工作?

?集成測試的目的是檢測軟件模塊對《概要設計說明書》HLD的符合程度

ST

?系統測試是將已經集成好的軟件系統，作為整個基于計算機系統的一個元素，與計算機硬件、外設、某些支持軟件、數據和人員等其他系統元素結合在一起，在實際運行（使用）環境下，對計算機系統進行一系列的測試工作

?系統測試的目的在于通過與《需求規格說明書》作比較，發現軟件與系統需求定義不符合或與之矛盾的地方

單元測試（ut） 集成測試（it） 系統測試（st）之間的區別

?測試方法不同

–? 單元測試屬于白盒測試范疇

–? 集成測試屬于灰盒測試范疇

–? 系統測試屬于黑盒測試范疇

??測試對象不同

–?單元測試主要測試單元內部的數據結構、邏輯控制、異常處理等

–?集成測試主要測試模塊之間的接口和接口數據傳遞關系，以及模塊

??組合后的整體功能

–? 系統測試主要測試整個系統相對于需求的符合度

??判斷標準不同

–? 單元測試判斷標準是詳細設計說明書

–? 集成測試的判斷標準是概要設計說明書

–? 系統測試的判斷標準是軟件需求規格說明書

驗收測試

是以用戶為主的測試，主要測試方法有3種

α測試:開發環境下進行，軟件在自然狀態下使用，有開發人員在旁，測試可控制。目的主要是評價軟件產品的FLURPS（即功能、局域化、可用性、可靠性、性能和技術支持）

β測試：多個用戶在多個實際情況下使用，開發人員不在旁，測試不可控制。

UAT測試：即用戶接受度測試。一般用于商業用戶驗收系統的可用性。

?一般用于商業用戶驗證系統的可用性，通常情況由終端用戶或利益相關方對被測試對象進行選擇性功能驗證。

? 也有可能根據法律法規、行業現行標準進行驗收測試。

（6）測試方法

按是否關系產品內部結構劃分: 黑盒測試，灰盒測試，白盒測試；

按是否運行程序劃分：靜態測試 動態測試；

按測試執行方式：手工測試 ?自動化測試；

軟件測試兩種極端情況：

1.已知產品的需求規格，但不知道其內部實現，可以進行測試證明每個需求是否實現。

2.已知產品的內部實現過程，可以通過測試證明每種內部操作是否符合設計規格的要求，所有內部成分是否已經過檢查

白盒測試：

分析軟件內部構造，?根據內部構造設計用例，對內部控制流程進行測試，不顧軟件整體功能實現情況

是基于內部結構的邏輯驅動測試

又可稱為玻璃盒測試、透明盒測試、開放盒測試、結構化測試、邏輯驅動測試

白盒測試一般在測試前期進行，通過測試讓內部結構達到一定邏輯覆蓋率指標，使內部控制問題盡可能達到最小，使軟件代碼達到更大質量保證，而且而且測試前期發現問題解決成本低

黑盒測試:

考慮整體功能實現情況，不顧內部構造

基于規則的測試

對更大的代碼單元（子系統甚至系統級）測試效率比白盒高，對測試人員的代碼語音能力要求比白盒低，從用戶的角度測試，容易被理解接受，有助于暴露任何規格不一致或有歧義的問題。

灰盒測試：

?根據利用的被測對象信息的不同，會采用不同的方法進行測試。?

?利用被測對象的整體特性信息，采用黑盒測試方法?

??利用被測對象的內部具體實現信息，采用白盒測試方法?

?如果既利用被測對象的整體特性信息，又利用被測對象的內部具體實現信息，采用的就是灰盒測試方法。兩種信息占的比例不同，相應的灰度就不同。完全是整體特性信息，就是黑盒測試，完全是內部具體實現信息，就是白盒測試?

??典型的灰盒測試比如集成測試和系統測試時借助log信息

靜態測試：

不運行被測試的軟件系統，而是采用其他手段和技術對被測試軟件進行檢測的一種測試技術。例如：代碼走讀、文檔評審、程序分析等都是靜態測試的范疇。常用技術有靜態分析技術。

靜態分析技術：

?定義：靜態分析是一種不通過執行程序而分析程序執行的技術

?功能：檢查軟件的表示和描述是否一致，沒有沖突或者沒有歧義，它瞄準的是糾正軟件系統在描述、表示和規格上的錯誤，因此是任何進一步測試執行的前提。

主要有三種不同的程序測試可能性：

?考慮程序是否滿足編碼規則，語法上是否具有一致性和完整性；

?考慮文檔描述是否規范、準確、便于查閱；

?考慮程序和文檔之間的一致性。

動態測試：

按照預先設計的數據和步驟去運行被測軟件系統，從而對被測軟件系統進行檢測的一種測試技術。常用技術有動態分析技術

人工測試：

測試活動（如評審、測試設計、測試執行等）由人來完成，狹義上是指測試執行由人工完成，這是最基本的測試形式

自動化測試：

一般是指通過計算機模擬人的測試行為，替代人的測試活動，狹義上是指測試執行由計算機來完成

自動化測試意義:

?對程序新版本運行前一版本執行的測試，提高回歸測試效率

?可以運行更多更頻繁的測試，比如冒煙測試

?可以執行手工測試困難或不可能做的測試，比如大量的重復操作或者集成測試

?更好地利用資源，比如測試儀器或者被測對象

自動化測試限制：

?不能取代手工測試，自動化測試只能提高測試效率，不能提高測試有效性，即不可能發現更多缺陷

?手工測試比自動測試發現的缺陷更多

?對測試設計依賴性極大，測試設計的不好會遺漏問題

?自動化測試對軟件開發具有很大的依賴性，開發上出現變更可能導致前面的自動化測試完全失效

?工具本身并不具備想象力，工具不具有智能

(7)測試模型

與開發模型一樣，軟件測試根據不同的被測對象、測試背景、被測對象質量要求、項目進度要求等，可以采用不同的測試模型實施測試活動，來指導軟件測試活動安排。

業界常見模型：

V模型 ? ? 從上至下 ?從左至右 ? ? ? ?缺點：項目早期的缺陷，在后期才能發現

W模型（雙V模型） ? 測試活動與研發并行， 文檔測試

X模型?單獨的程序片段進行獨立的編碼和測試活動 ? ?探測性測試

H模型 開發與測試獨立 ? ? 分測試準備，測試執行

敏捷模型 客戶角度進行測試 預防缺陷重于發現缺陷

V模型：

?V模型是所有軟件測試模型中最為大家熟知的一種模型。它是從瀑布研發模型演變而來的測試模型，如圖所示。

V模型流程是從上至下，從左到右

①測試工程師在研發人員編程過程中，對其生成的代碼函數做單元測試

②單元測試通過后進行集成測試

③集成測試通過后做系統測試、驗收測試

V模型缺點：項目早期的缺陷，在后期才能

W模型：

W模型是在V模型的基礎上演變而來的，一般又稱為雙V模型。在V模型中，研發活動沒有完成、無任何輸出物時，測試工程師無法開展測試工作，相對而言，測試活動嚴重滯后。為了解決V模型的缺點，W模型提出了測試活動與研發活動并行的概念，并且在生產流程演進過程中，增加了驗證與確認活動

W模型從用戶需求開始，研發團隊根據用戶需求進行需求分析、概要設計、詳細設計、編碼開發等活動，測試團隊則根據用戶需求進行驗收測試、系統測試、集成測試及單元測試設計。測試工作與研發活動分離，實現了并行操作。測試活動伴隨著整個研發過程，而不僅在研發有成果輸出后才參與。

W模型強調了測試活動不僅僅包括研發活動所產生的軟件源代碼，還考慮各種文檔，如需求文檔、概要設計文檔、詳細設計文檔、代碼等。

W模型要求測試活動從用戶需求階段就介入，有利于盡早地發現問題，在模型實施過程中，時刻進行確認（validation）、驗證（verification）活動

X模型：

?X模型產生的背景亦與V模型有關，V模型的缺點是測試活動滯后于研發活動，無法盡早地開展測試活動。而X模型與W模型一樣，提出的初衷都是解決V模型的缺點。

?X模型的基本思想是由Marick提出的， Robin F.Goldsmith進行了完善。X模型如圖所示。

X模型左邊表明針對單獨的程序片段n進行獨立的編碼和測試活動，以此為基本過程，不斷迭代，通過集成活動最終成為可執行程序，然后再對這些可執行程序進行測試。通過集成測試的成品可以進行封裝并提交給系統測試環節或直接給用戶。多條并行的曲線表示變更可以在各個部分發生。

探索性測試:探索性測試與常規的測試方法不同，無須事先制定測試計劃或設計，有經驗的測試工程師可根據自己的思維活動及對被測對象的理解，在測試計劃之外發現更多的軟件錯誤。但探索性測試通常情況下僅作為其他測試方法的補充，因其消耗測試資源較多，且受制于測試工程師的經驗，所以不能成為獨立的測試方法。

? ? H模型：

H模型將測試活動與其他研發流程獨立，測試活動分為測試準備與測試執行兩個部分，便于測試設計與測試執行活動定義，如圖所示。測試準備活動包括測試需求分析、測試計劃、測試設計、測試編碼、測試驗證等，測試執行包括測試運行、測試報告、測試結果分析、確認回歸測試等

? ??H模型與W模型一樣，揭示了軟件測試活動應該是一個獨立的軟件生產流程，貫穿整個軟件生命周期，測試活動應該盡早準備、盡早執行，當測試準備工作完成后，一旦到達測試就緒點，就可開展測試執行活動，不會受制于研發活動。

敏捷測試：

強調從客戶角度進行測試；

重點關注迭代測試新功能，不再強調測試階段

盡早測試，不間斷測試，具備條件即測試

強調持續反饋

預防缺陷重于發現缺陷

?傳統測試：測試是質量的最后保護者?????????? ? ? ? ?敏捷測試：開發和測試人員是緊密合作，大家都有責任對軟件負責；

? ? ? ? ? ? ? ? ? ? ? 嚴格的變更管理 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 變更是可接受的，擁抱變

? ? ? ? ? ? ? ? ? ? ? 預先的計劃和細節的準備 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 計劃隨著進展時常調整

? ? ? ? ? ? ? ? ? ? ? ?重量級文檔 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?只需要絕對必要的文檔

? ? ? ? ? ? ? ? 各階段測試嚴格的入口和出口標準 ? ? ? ? ? ? ? ? ? ? ? ? ? 各迭代之間已經沒有明顯的入口和出口標準

? ? ? ? ? ? ? ?更多在回歸測試時進行重量級的自動化測試 ? ? ? ? ? ?所有階段都需要自動測試，每個人都需要做，是項目集成 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?的一部分；

? ? ? ? ? ? ? 嚴格依賴流程執行 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?流程不再需要嚴格執行

? ? ? ? ? ? ? 測試團隊和開發團隊是相對獨立的 ? ? ? ? ? ? ? ? ? ? ? ? ? ?團隊合作是無縫隙合作