軟件研發流程中的軟件測試流程設計

　　軟件測試生命周期一般包括7個階段：1)計劃 2)分析，3)設計，4)構建，5)測試周期，6)最后測試和實施，7)實施后。

　　1. 計劃(產品定義階段)

　　 高層次的測試計劃(包含多重測試周期)

　　 質量保證計劃(質量目標，測試標準等 )

　　 確定計劃評審的時間

　　 報告問題過程

　　 確定問題的分類

　　 確定驗收標準-給質量保證員和用戶。

　　 建立應用程序測試數據庫

　　 確定衡量標準，例如缺陷數量/嚴重程度和缺陷起源(僅舉幾個例子) 。

　　 確定項目質量度量

　　 開始制定項目整體測試時間表(時間，資源等)

　　 必需階段：評審產品定義文檔

　　 文檔中加入質量保證標準，作為工程改善進程的一部分

　　 根據該產品的特點幫助確定問題的范圍

　　 大約每月要花5 -1 0小時在這一方面

　　 計劃在數據庫管理所有測試用例，包括手工方面或者自動化方面。

　　2. 分析(外部文檔階段)

　　 根據業務需求開發功能驗證矩陣。

　　 制定測試用例格式-估計時間和分配優先級。

　　 制定測試周期矩陣與時間線

　　 根據功能驗證矩陣開始編寫測試用例

　　 根據業務需求計劃測試用例基準數據

　　 確定用于自動化測試的測試用例。

　　 自動化團隊開始在測試工具中創建變量文件和高層次的測試腳本。

　　 為自動化系統中的跟蹤組件設置路徑和自動化引導。

　　 界定壓力和性能測試的范疇。

　　 按照每個測試用例的數據要求開始建立基準數據庫。

　　 定義維護基準數據庫的過程，即備份，恢復，驗證。

　　 開始規劃項目所需的測試周期數，和回歸測試次數。

　　 開始文檔復查，如：功能設計文檔，業務需求文檔，產品規格說明書，產品外部文檔等。

　　 審查測試環境和實驗室，前端與后端系統都要。

　　 準備使用McCabe工具，以支持白盒測試中代碼的研發和復雜性分析

　　 建立反饋機制并開始錄入文檔。

　　 必需階段：審查外部文件

　　 文檔中加入質量保證標準，作為工程改善進程的一部分。

　　 根據群體執行反饋編寫測試用例

　　 開始研制測試用例估計數目，每個用例的執行時間，和用例是否自動化這些方面的度量

　　 為每個測試用例確定基準數據，

　　 大約每月要花25小時在這一方面

　　3. 設計(文檔架構階段)

　　 根據變更修改測試計劃

　　 修改測試周期矩陣和時間線

　　 核實測試計劃和用例用到的數據都輸入到數據庫，或是否必需的。

　　 修改功能驗證矩陣

　　 繼續編寫測試用例，根據變化添加新的用例

　　 制定風險評估標準

　　 規范自動化測試和多用戶測試的細節。

　　 挑選出一套用于自動化測試的測試用例，并且把這些用例腳本化

　　 規范壓力測試和性能測試的細節。

　　 最終確定的測試周期。 (根據用例的估計時間和優先權確定每個周期所用的測試用例數)

　　 最終確定的測試計劃

　　 估計單元測試所需資源

　　 必需階段：審查架構文件

　　 文檔中加入質量保證標準，作為工程改善進程的一部分。

　　 確定要進行編碼的的實際組件或模塊

　　 在這定義單元測試標準，通過/失敗準則等。

　　 單元測試報告，報告進行單元測試后的模塊質量如何，白盒測試和黑盒測試都要包括輸入/輸出數據和所有決定點。

　　 列出所有要進行單元測試的模塊

　　4. 構建(單元測試階段)

　　 完成所有計劃

　　 完成測試周期矩陣和時間線

　　 完成所有測試用例。 (手動)

　　 完成第一套自動化測試用例的測試腳本。

　　 完成壓力和性能測試的計劃

　　 開始壓力和性能測試

　　 McCabe工具支持-提供度量

　　 測試自動化測試系統，并修復錯誤。

　　 發展單元測試

　　 運行質量保證驗收測試套件，以確保軟件已經可以交給QA測試。

　　5. 測試周期/ 錯誤修正( 重復/系統測試階段)

　　 測試周期1，執行第一套的測試用例(前端和后端)

　　 報告錯誤

　　 錯誤審核-不斷開展的活動。

　　 根據需求修改測試用例

　　 根據需求增加測試用例

　　 測試周期二

　　 測試周期三

　　6. 最后的測試和實施(代碼凍結階段)

　　 執行所有前端測試用例-人工和自動化。

　　 執行所有后端測試案例-人工和自動化。

　　 執行所有壓力和性能測試。

　　 提供對正在進行的缺陷跟蹤度量。

　　 提供對正在進行的復雜性和設計的度量。

　　 更新測試用例和測試計劃的估計時間。

　　 文件測試周期，回歸測試，并更新相應文檔。

　　7. 實施后

　　 開展實施后評估會議以回顧整項工程。 (經驗所得)

　　 準備最終的缺陷報告和相關度量。

　　 制定戰略以防止類似的問題在今后的項目中重復出現。

　　 創建如何改進流程的計劃目標和里程碑，

　　 McCabe工具-制作最后的報道和分析。

　　 自動化測試組-1 )審查測試用例以評估其他可用于自動化回歸測試的用例2 )清理自動化測試用例和變量，和3 )審查自動化測試和手工測試結果的整合過程

　　 測試實驗室和測試環境-清理測試環境，標記和存檔用過測試用例和數據，恢復測試儀器到原始狀態等。

　　1、 引言

　　有很多種不同的生命周期模型用于軟件的開發。軟件開發的生命周期是以對軟件的需求定義為起點，以對軟件的正式驗收作為終點。

　　它并不是獨立存在的，而是一個完整產品生命周期實實在在的一部分。在產品生命周期之中，軟件的開發會不斷改正其自身的錯誤并且時常針對軟件的需求而進行調整。軟件產品最簡單的形式只不過是一個程序軟件，但實際上確沒有那么簡單，由于軟件產品是由開發出的不同軟件部分所構成的一個完整的系統，這將會使產品變的非常復雜。

　　有許多不同的軟件開發生命周期模型，但是它們都有一個共同的特點，那就是在生命周期中的某一時刻，軟件都會被測試。這篇文章概述了一些常用的軟件生命周期模型，并重點強調了在各個模型中的測試工作。

　　2、 順序生命周期模型

　　軟件開發生命周期模型以需求定義為開端，以對需求的正式驗收作為終結。傳統意義上，被用于軟件開發生命周期的模型應該是順序的并且開發過程的各個階段都經過完善的定義。通常用V型生命周期模型和瀑布生命周期模型來表示這種順序的開發過程。而事實上，這兩種生命周期模型有許多不同的形態，將不同的階段引入生命周期模型，并在不同階段之間設立邊界。以下介紹的生命周期模型的各個階段是經過許多最有經驗的開發者經過反復實踐而得來的。

　　圖1、V型生命周期模型

　　圖2、瀑布生命周期模型

　　* 需求分析階段

　　這個階段主要是收集并分析用戶的需求，并且根據軟件需求建立完整而明確的需求說明書。

　　* 概要設計階段

　　在這個階段，針對用戶需求的軟件結構將會被設計，并確定軟件內部各個部件的相關聯系。

　　* 詳細設計階段

　　軟件各個部件的執行功能將被詳細說明。

　　* 遍碼與單元測試階段

　　在本階段，將對軟件的各個部件進行編碼，并且進行單元測試以確定各個部分確實執行了詳細設計階段所制定的目標。

　　* 軟件集成階段

　　這個階段被測試過的各個部件被逐漸集成起來測試直到構成了一個完整的軟件。

　　* 系統集成階段

　　這個階段將軟件程序集成起來，構成產品并進行測試。

　　* 驗收測試階段

　　這個階段將進行測試以驗證軟件確實完整的執行了用戶的需求。

　　3、 漸進開發生命周期模型

　　順序模型(V型和瀑布生命周期模型)只是代表著一種理想化的軟件開發模型。但實際上出于種種原因，例如需求的多變性和為應付過長的開發時間而開發零時系統的需要，還有其它的生命周期模型將會被采用。

　　現在，讓我們以漸進開發的迭代生命周期為例，來看一下其它的生命周期模型。軟件開發所具有的一個問題就是用戶急需軟件產品，但是開發者卻要花費很長的時間去完整地進行開發。那么取一個折中的解決方法就是節省一些時間，但在功能上打一點折扣——開發出一個功能有所縮減的試用版給用戶，作為完整版發布前的一個跳板。也可以將這個跳板作為軟件減少軟件開發風險的一種方式。

　　在軟件開發中，通常將這種方法稱為漸進開發或是執行階段。與之相對應的生命周期模型被稱為漸進開發生命周期模型。在漸進開發的生命周期之中，每一個獨立的階段都將遵從V型和瀑布型生命周期模型。

　　圖3、漸進開發生命周期

　　每一個軟件的發布都會經過驗收測試以證明軟件的各個部分所構成的整體確實實現了需求。但是每個階段的測試和集成將會耗費大量的時間和精力。由于過多的開發周期會增加成本，耗費時間，所以應該經過認真估算，盡早地規劃好到底應該使用多少個周期來進行軟件的開發。

　　在早期開發出來的產品沒有任何的實用價值，只是作為下一步開發的一個原型。這些原型僅僅是用來滿足、核對用戶關鍵需求所走的一個捷徑?？墒侨绻渲锌s減了文檔的書寫和對軟件的測試，那么就有必要將這些將這個原型拋棄并從下一個階段開始重新設計。因為一個缺乏質量的原形不可能給下一步的開發打下一個好基礎。

　　4、 迭代生命周期模型

　　迭代生命周期模型并不是一開始就完全適應需求，而是先根據說明先開發軟件的部分些可執行部件。而是先開發一些具有部分功能的部件，這些部件要求能夠通過審查以確定更進一步的需求。不斷重復這個過程，為此模型的每一個周期遍寫出更新版本的軟件。

　　一個迭代周期模型由下圖的四個連續部分組成不斷重復組成。

　　圖4、迭代生命周期模型

　　*　需求分析階段

　　在這個階段，主要是收集并分析用戶的需求，并且制定這個迭代模型最終并且完整的需求說明書。

　　*　定義階段

　　在這個階段，設計出適應需求的軟件解決方案。這有可能是一個全新的設計，也有可能是原來設計的一個延伸。

　　*　執行、測試階段

　　在這個階段，將對軟件進行編碼，集中并進行測試。

　　*　審查階段

　　在這個階段，將對軟件進行評估，對目前的需求進行審查，并對其進行修改和更新。

　　在迭代模型的每一個周期，都要作出一個決定：要將編寫出的軟件拋棄，還是作為下一個周期的起點。如果軟件完全符合了需求，那么就可以進行發布，否則就是一個失敗的開始。

　　迭代生命周期模型可以說是采用了一種連續逼近的方式來制作軟件。將這種方式類比成一個連續逼近最終解決方案的數學模型，那么這種方式能否成功的關鍵就是多快能夠形成解決方案。

　　也許經過不斷的類比也不能找到解決方案，而迭代的過程不是在可行的解決方案周圍盤旋就是逐漸遠離目標。而且需要迭代的次數太過龐大會使軟件開發變得不切實際，在很多軟件開發的過程中我們都能發現這個問題。

　　成功運用迭代軟件生命周期模型來開發的關鍵就是要嚴格按照需求，并且根據需求對每個周期制造出來的各版本軟件進行驗收(包括測試)。迭代模型的前三個階段就好比是簡化版本的V型模型或是瀑布模型。迭代模型中的每一個周期所編寫出來的軟件都要為軟件的集中，系統集中和驗收進行單元測試。在迭代模型中軟件的開發經歷了多少個這樣的周期，那么就要進行多少次這樣的測試。

　　5、 維護

　　成功編寫的軟件最終將成為產品的一部分并進入維護階段。在這個階段將不斷地修正軟件的錯誤，并時常對其進行調整以適應多變的需求。正如剛開始開發一樣，軟件的維護也要遵循軟件開發生命周期，但不一定要使用和開始相同的生命周期模型。在整個維護階段，軟件將會得到不斷的測試，修正，并且擴展。對軟件修正和重復多次的測試占用了整個軟件開發所需費用的很大一部分。

　　6、 概要和結論

　　無論何種生命周期模型被用于軟件的開發，都會對軟件進行測試。質量、功能都很完美的軟件產品需要在其軟件開發生命周期的早期進行測試，并且無論發生什么變故，都要進行完善的回歸測試。

　　在漸進、迭代生命周期中，這種行為顯得尤為重要。重復測試對于軟件質量的控制，在漸進、迭代模型中相比于傳統的順序生命周期模型也顯得尤為重要。

　　回歸測試是對軟件進行維護的重要手段。在軟件開發之中，由于不能完全預料到最終的結果，會進行諸多的修改。但如果不對軟件使用完善回歸測試，就會導致產品質量的下降。

　　軟件開發管理中常犯的一個錯誤就是在V型模型或是瀑布模型開發的起始階段，采用了不完善的管理制度，那最終就會引起問題的累積而使局勢無法得到控制。這就是使軟件開發走向失敗的另一種情形。

　　AdaTEST 和 Cantata是使軟件測試能夠便捷，自動化，可重復，可維護的工具。對于Ada、C、C++的軟件開發有重要的意義。在漸進模型或是迭代模型采用AdaTEST或是 Cantata進行重復的維護性軟件測試，對于軟件開發會有更大的收益。

　　還有很多軟件開發生命周期模型在這里沒有提到，然而那些模型大都遵循這里提到的一些形式，基本上共用相同的道具，AdaTEST 和 Cantata都有助于這些模型的開發。

原文轉自：http://www.kjueaiud.com