288.軟件開發過程與軟件測試

1.軟件開發過程概述

 

1.1 軟件開發的階段、活動及角色

一、軟件工程的階段
軟件工程的三個階段:
定義、開發、檢驗交付與維護

 

(1)定義階段：可行性研究初步項目計劃、需求分析。如圖2-1所示。

圖2-1軟件工程的定義階段

 

(2)開發階段：概要設計、詳細設計、實現、測試。如圖2-2所示。

圖2-2 軟件工程的開發階段

 

(3)檢驗交付與維護階段：運行、維護、廢棄。如圖2-3所示。

圖2-3 軟件工程的檢驗交付與維護階段

 

 

 

二、軟件開發過程的活動
一般包括四種基本過程活動：
（1）軟件規格說明：規定軟件的功能、性能及其運行限制。
（2）軟件開發：產生知足規格說明的軟件，包括設計與編碼等工做。
（3）軟件確認：確認軟件可以知足客戶提出的要求，對應於軟件測試。
（4）軟件演進(軟件的維護)：爲知足客戶的變動要求，軟件必須在使用過程當中演進，以求儘可能延長軟件的生命週期。

 

 

三、開發過程當中的角色
（1）項目經理：負責管理業務應用開發和系統開發項目。
（2）業務分析人員：理解和描繪客戶的要求，引導和協調用戶和業務需求的收集和確認，並使文檔化。
（3）架構師：負責理解系統的業務需求，並建立合理、完善的系統體系架構。並決定相關技術的選擇。
（4）數據設計人員：負責定義詳細的數據庫設計。
（5）程序員：設計、編寫程序代碼及內部設計規格說明。
（6）測試人員：負責制定測試計劃，並根據計劃進行相關測試，找出產品中的問題。
（7）產品經理：負責產品的交付和發佈，以及銷售產品。
（8）技術支持表明：負責處理客戶的投訴，以及售後服務問題。

 

 

 

1.2 軟件開發的過程模型

一、線性順序模型（瀑布模型）

（1）各個階段的劃分徹底固定，階段之間產生大量的文檔，極大地增長了工做量；
（2）因爲開發模型是線性的，用戶只有等到整個過程的末期才能見到開發成果，從而增長了開發的風險；
（3）早期的錯誤可能要等到開發後期的測試階段才能發現，進而帶來嚴重的後果。

圖2-4 線性順序模型

 

 

二、（快速）原型模型

原型模型從需求收集開始，開發者與用戶在一塊兒定義軟件的整體目標，標識出已知的需求，並規劃出進一步定義的區域，而後快速地設計並進行編碼實現，創建好原型。在原型模型的基礎上，運行、評估、修改，屢次迭代進行，直到知足用戶的需求爲止。

 

 圖2-5 原型模型

 

 

三、快速開發模型

採用RAD模型時，系統的每個主要功能部件均可由一個單獨的RAD工做組完成，最後將全部的部件集成起來構成完整的軟件。

RAD模型強調可複用程序構件的開發，並支持多小組並行工做。但若一個系統很難模塊時，構件的複用和建造會出現許多問題，不適用於技術風險高、採用新技術的項目。

 

 圖2-6快速開發模型

 

 

 

四、演化軟件過程模型

（1）增量模型：將線性模型與原型模型結合起來，隨着日程/時間的進展而交錯析線性序列集合。如圖2-7所示。

 

 

（2）螺旋模型：也是將線性模型與原型模型結合起來，並加入風險分析。如圖2-8所示：

螺旋模型被劃分爲若干框架活動：用戶通訊、計劃、風險分析、工程、建造及發佈、用戶評估等。

螺旋模型適應於計算機軟件產品的整個生命週期。對於大型系統的開發是一種模型方法。

 

 

 

 

1.3 軟件測試與軟件開發的關係

軟件測試在軟件開發過程當中佔有重要的地位，在傳統的瀑布模型中，軟件測試只成爲其階段性的一段工做——進行代碼的測試。而現代軟件工程思想將軟件測試認爲是貫穿整個軟件生命週期，而且是保證軟件質量的重要手段之一。

有些研究數據顯示，在國外軟件開發的工做量中，軟件測試的工做量佔有總工做量的40%左右；軟件開發的總費用中軟件測試佔有30%-50%。對於一些高科技開發系統，軟件測試佔有的時間和費用可能更多更高。

 

 

2.軟件測試的基本原則

一、測試不是爲了證實系統的正確性，而是爲了證實系統存在缺陷；

二、全部的測試都應該追溯到用戶的需求；

三、測試應當儘早開始和不斷進行；

四、窮舉測試是不可能的；

五、第三方測試會更客觀、更有效；

六、Pareto原則應用於軟件測試；

七、軟件測試是有風險的行爲；但並不是全部的測試都要修復；

八、測試應從小規模開始，逐步轉向大規模；

九、軟件測試是一項講究條理的技術專業。

 

3.軟件測試方法的分類

3.1靜態測試與動態測試

一、靜態測試

靜態測試，是不須要執行被測軟件，而是採用分析和查看的方式，來發現軟件當中的缺陷，包括需求文檔、源代碼、設計文檔、以及其餘與軟件相關文檔中的二義性和錯誤。最好由未參加代碼編寫的我的或小組來完成。測試小組還可以使用一個或多個靜態測試工具，以源程序代碼做爲輸入，產生大量的在測試過程有用的數據。如圖2-9所示。

 

 圖2-9 靜態測試的要素

 

靜態測試經常使用的方法以下：

（1）走查

走查是個非正式的過程，檢查全部與源程序代碼相關的文檔。

（2）審查

審查比走查要求更加正規。

（3）靜態代碼分析工具

靜態結構分析主要是以圖形的方式表現程序的內部結構

 

 

二、動態測試

動態測試是指經過運行實際被測試軟件，經過觀察程序運行時所表現的狀態、行爲等來發現軟件的缺陷。並對被測程序的運行狀況進行分析對比，以便發現程序表現的行爲與設計規格或客戶需求不一致的地方。

動態測試通常包括功能確認與接口測試，覆蓋率分析、性能分析、內存分析等。

動態測試是一種常常運行的測試技術。但也有它的侷限性：必需要藉助測試用例完成；須要搭建特定的測試環境；不能發現文檔中的問題。

因爲動態測試與靜態測試之間存在必定的協同性，又具備相對的獨立性。因此在程序執行前進行靜態測試，儘量多地發現代碼中隱含的缺陷；執行動態測試檢查程序實時的行爲，發現程序在運行時存在的缺陷。

 

 

3.2黑盒測試與白盒測試

一、黑盒測試

黑盒測試又稱功能測試或數據驅動測試；是將被測試軟件看作一個黑盒子，徹底不考慮程序的內部結構和處理過程，只考慮系統的輸入和輸出，在程序的接口進行測試，檢查系統功能是否符合需求規格說明書的要求。

經常使用的測試方法有：等價類劃分、邊界值法、決策表法、因果圖法、錯誤推測試法等。

黑盒測試的優勢:黑盒測試用例與程序如何實現無關；測試用例的設計與程序開發可並行設計；沒有編程經驗的人也能夠設計測試用例。

黑盒測試的侷限性：不可能作到窮舉測試；可能存在漏洞。

 

 

 

二、白盒測試

白盒測試又稱結構測試或邏輯驅動測試；是根據被測試程序源代碼的內部結構來設計測試用例的方法。

經常使用的測試方法有：邏輯覆蓋、基本路徑和數據流測試等。

白盒測試的優勢：能夠利用不一樣的覆蓋準則測試程序代碼的各個分支，發現程序內部的編碼錯誤；能夠直接發現內存泄露問題；能夠充當黑盒測試的檢查手段等。

白盒測試的侷限性：因程序路徑組合太多，一樣不能作到窮舉測試；因爲設計測試用例不是根據客戶需求說明進行的測試，可能存需求方面的漏洞。

 

 

 

三、灰盒測試

灰盒測試結合了白盒測試和黑盒測試的要素，關注輸入的正確性，同時了關注內部的表現；考慮了用戶端、特定的系統知識和操做環境。它在系統組件的協同環境中評價應用軟件的設計。

 

 

3.3 人工測試與自動化測試

按照測試執行時是否須要人工干預進行分類，可分爲人工測試與自動測試。

一、人工測試

人工測試是人爲測試和手工測試的統稱。人爲測試的主要方法有桌前檢查、代碼審查和走查。用於軟件開發各階段的審查或評審都是人爲測試。手工測試主要指在測試過程當中，按照測試計劃一步一步執行程序，得出測試結果並進行分析的測試行爲。

 

二、自動測試

自動化測試指的是利用測試工具對各類測試活動的管理與執行，並對測試結果自動進行分析。在測試的執行過程當中，通常不須要人工干預。經常使用在功能測試、迴歸測試和性能測試等。

自動化測試的優勢：提升測試效率；下降測試成本；具備一致性和可重複性；下降風險，增長軟件的質量等。

自動化測試的侷限性：自動化測試軟件自己的問題；測試人員指望太高；有些人工測試是不能用自動化測試替代等。

 

3.4 其餘測試分類

一、基於模型的測試與模型檢測

基於模型的測試，是指對軟件行爲進行建模以及根據軟件的形式化模型設計測試的活動。

模型檢測是指，用來驗證軟件特定模型中的一個或多個特性的一類技術。

 

　　模型一般是有限狀態的，是從一些原始材料中提取出來的，這些原始材料多是需求文檔，也多是系統源代碼自己。有窮狀態模型中的每個狀態前都有一個或多個前置條件，當軟件處於該狀態時，這些特性必須知足。見圖2-10所示說明模型檢測過程。

 

 圖2-10模型檢測的要素

 

 

二、冒煙測試

冒煙測試是指在測試中發現問題，也就是說找到了一個缺陷，由開發人員來修復這個缺陷，當修復完成後，是否真的解決了這個缺陷，或對其餘模塊是否存在影響，所以要針對這個問題進行專門的測試，這個測試過程稱爲冒煙測試。

在許多狀況下，通過測試後，發現修復某個問題會引發其餘功能模塊一系列的反應，致使產生新的缺陷。冒煙測試的優勢是節省測試時間，防止建立失敗。缺點是覆蓋率較低。

 

 

三、隨機測試

隨機測試是根據測試說明書執行樣例測試的一種重要補充手段，是保證測試覆蓋完整性的有效方式和過程。隨機測試主要針對系統的一些重要功能進行復測。還對軟件更新和新增的功能要進行重點測試。常與迴歸測試一塊兒進行。

 

 

 4.軟件測試方法在軟件開發過程的運用

 

一、在軟件需求分析與建模階段中，主要進行軟件目標的定義，可行性研究和軟件需求分析工做。這時測試的對象是相關文檔資料，如：需求規格說明書等。從需求的完備、可實現、是否合理、是否可測試等方面進行評審，採用的靜態測試方法。
二、在概要設計與詳細設計階段。概要設計描述整體系統架構中各個模塊的劃分及相互之間的關係；詳細設計則描述各個模塊具體的算法和數據結構。這些都是用文字、圖表的形式進行描述的，測試時也是用靜態測試的方法，對文字、圖表進行評審。

三、在編碼工做階段，主要是採用高級語言對已詳細設計的模塊進行編程。這時的測試工做主要是對已有的程序代碼進行白盒測試，能夠是靜態與動態相結合，採用各類覆蓋方法進行測試，此時主要由程序員進行測試。
四、在測試階段中，此時進行的集成與系統測試。集成測試採用灰盒測試方法（白盒測試與黑盒測試相結合），主要測試產品的接口以及各模塊之間的關係。而系統測試通常採用黑盒測試方法，主要測試系統的功能、性能等；由測試人員來完成測試。
五、在檢驗交付與維護階段，模擬或實際客戶環境，對系統進行驗收測試。大多采用自動化測試工具進行測試驗收。包括功能測試、性能測試、迴歸測試、發佈測試等。

 

5.軟件測試的過程模型

至關於把軟件測試做爲項目

5.1V_model

v-model模型是最先的軟件生存期模型，在20世紀80年代由Paul Rook提出的。
v-model包含了三個等級，分別是生存期模型，分配模型，功能性工具需求模型，闡述了應當實施哪些活動，應當產生哪些結果，諸如此類。

  

V-model指出，單元測試所檢測代碼的開發是否符合詳細設計的要求。集成測試所檢測此前測試過的各組成部分是否能無缺地結合到一塊兒。系統測試所檢測已集成在一塊兒的產品是否符合系統規格說明書的要求。而驗收測試則檢測產品是否符合最終用戶的需求。因此V-model模型軟件測試的策略既包括低層測試又包括高層測試，底層測試是爲了驗證系統源代碼的正確性，高層是爲了測試整個系統是否知足用戶的需求。

V-model的缺陷:僅僅把測試過程做爲在需求分析、系統設計及編碼以後的一個階段忽視了測試對需求分析,系統設計的驗證，一直到後期的驗收測試才被發現。

 

 

 5.2W-model

W模型由Evolutif公司提出，相對於V-model，W-model更科學,W-model是V-model的發展。因爲V-model的侷限性，沒有明確地說明早期的測試,沒法體現「儘早地和不斷地進行軟件測試」的原則。在V-model中增長軟件各開發階段應同步進行的測試，演化爲W-model。如圖2-12所示。

 

 

W-model，強調的是測試伴隨着整個軟件開發週期，並且測試的對象不只僅是程序，需求、功能和設計一樣要測試。測試與開發是同步進行的，從而有利於儘早地發現問題。以需求爲例，需求分析一完成，咱們就能夠對需求進行測試，而不是等到最後才進行鍼對需求的驗收測試。

 

W-model的侷限性：W模型和V模型都把軟件的開發視爲需求、設計、編碼等一系列串行的活動，軟件開發和測試保持一種線性的先後關係，須要有嚴格的指令表示上一階段徹底結束，才能夠正式開始下一個階段。這樣就沒法支持迭代、自發性以及變動調整。對於當前不少文檔須要過後補充，或者根本沒有文檔的作法下，開發人員和測試人員都面臨一樣的困惑。

 

 

5.3H-model

H-model。它將測試活動徹底獨立出來，造成一個徹底獨立的流程，將測試準備活動和測試執行活動清晰地體現出來。如圖2-13所示：

H-model揭示了：
（1）軟件測試不只僅指測試的執行，還包括不少其餘的活動（測試準備、測試以後的事情）；
（2）軟件測試是一個獨立的流程，貫穿產品整個生命週期，與其餘流程併發地進行；
（3）軟件測試要儘早準備，儘早執行；
（4）軟件測試是根據被測物的不一樣而分層次進行的。不一樣層次的測試活動能夠是按照某個次序前後進行的，但也多是反覆的。

 

 

 

5.4X-model

X-model的基本思想是由Marick提出的，他認爲一個模型必須能處理開發的全部方面，包括交接，頻繁重複的集成，以及需求文檔的缺少等等。 而X-model填補了V-model 的缺陷，並可爲測試人員和開發人員帶來明顯的幫助。如圖2-14所示。

 

 

 

 

5.5 pretest-model

pretest-model，它是將測試和開發緊密結合的模型，該模型提供了輕鬆的方式，可使你的項目加快速度。如圖2-15所示。

Pretest-model體現瞭如下的要點：
（1）開發和測試相結合
（2）對每個交付內容進行測試
（3）在設計階段進行測試計劃和測試設計
（4）測試和開發結合在一塊兒
（5）讓驗收測試和技術測試保持相對獨立

 

 

 

5.6測試模型的使用

　　V-model強調了在整個軟件項目開發中須要經歷的若干個測試級別，並且每個級別都與一個開發級別相對應，但它忽略了測試的對象不該該僅僅包括程序，或者說它沒有明確地之處應該對軟件的需求、設計進行測試。
　　W-model強調了測試計劃等工做的先行覈對系統需求和系統設計的測試，但W-model和V-model同樣也沒有專門對軟件測試流程予以說明，由於事實上，隨着軟件質量要求愈來愈爲你們所重視，軟件測試也逐步發展成爲一個獨立於軟件開發部的組織，就每個軟件測試的細節而言，它都有一個獨立的操做流程。好比，如今的第三方測試，就包含了從測試計劃和測試案例編寫，到測試實施以及測試報告編寫的全過程，
H-model強調測試是獨立的，只要測試準備完成，就能夠執行測試了。
　　X-model和Pretest-model又在此基礎上增長了許多不肯定因素的處理狀況，由於在真實項目中，常常會有變動的發生，例如須要從新訪問前一階段的內容，或者跟蹤並糾正之前提交的內容，修復錯誤，排除多餘的成分，以及增長新發現的功能等。

 

 

本章先簡單介紹了軟件開發過程的三個階段：定義階段、開發階段、檢驗交付與維護階段，軟件開發過程當中的活動與角色，軟件開發的開發模型有線性順序模型、原型模型、快速開發模型、演化軟件過程模型等，軟件開發與軟件測試的關係等。並介紹了軟件測試的七條基本原則，軟件測試方法經常使用有：靜態測試、動態測試、白盒測試、黑盒測試、灰盒測試、人工測試、自動化測試、模型檢測、冐煙測試、隨機測試等。最後介紹了軟件測試的五種過程模型：V-model、W-model、H-model、X-model、 pretest-model。