軟件研發(fā)流程中的軟件測試流程設計

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

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

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

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

　　 確定計劃評審的時(shí)間

　　 報告問(wèn)題過(guò)程

　　 確定問(wèn)題的分類(lèi)

　　 確定驗收標準-給質(zhì)量保證員和用戶(hù)。

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

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

　　 確定項目質(zhì)量度量

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

　　 必需階段：評審產(chǎn)品定義文檔

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

　　 根據該產(chǎn)品的特點(diǎn)幫助確定問(wèn)題的范圍

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

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

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

　　 根據業(yè)務(wù)需求開(kāi)發(fā)功能驗證矩陣。

　　 制定測試用例格式-估計時(shí)間和分配優(yōu)先級。

　　 制定測試周期矩陣與時(shí)間線(xiàn)

　　 根據功能驗證矩陣開(kāi)始編寫(xiě)測試用例

　　 根據業(yè)務(wù)需求計劃測試用例基準數據

　　 確定用于自動(dòng)化測試的測試用例。

　　 自動(dòng)化團隊開(kāi)始在測試工具中創(chuàng )建變量文件和高層次的測試腳本。

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

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

　　 按照每個(gè)測試用例的數據要求開(kāi)始建立基準數據庫。

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

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

　　 開(kāi)始文檔復查，如：功能設計文檔，業(yè)務(wù)需求文檔，產(chǎn)品規格說(shuō)明書(shū)，產(chǎn)品外部文檔等。

　　 審查測試環(huán)境和實(shí)驗室，前端與后端系統都要。

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

　　 建立反饋機制并開(kāi)始錄入文檔。

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

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

　　 根據群體執行反饋編寫(xiě)測試用例

　　 開(kāi)始研制測試用例估計數目，每個(gè)用例的執行時(shí)間，和用例是否自動(dòng)化這些方面的度量

　　 為每個(gè)測試用例確定基準數據，

　　 大約每月要花25小時(shí)在這一方面

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

　　 根據變更修改測試計劃

　　 修改測試周期矩陣和時(shí)間線(xiàn)

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

　　 修改功能驗證矩陣

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

　　 制定風(fēng)險評估標準

　　 規范自動(dòng)化測試和多用戶(hù)測試的細節。

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

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

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

　　 最終確定的測試計劃

　　 估計單元測試所需資源

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

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

　　 確定要進(jìn)行編碼的的實(shí)際組件或模塊

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

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

　　 列出所有要進(jìn)行單元測試的模塊

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

　　 完成所有計劃

　　 完成測試周期矩陣和時(shí)間線(xiàn)

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

　　 完成第一套自動(dòng)化測試用例的測試腳本。

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

　　 開(kāi)始壓力和性能測試

　　 McCabe工具支持-提供度量

　　 測試自動(dòng)化測試系統，并修復錯誤。

　　 發(fā)展單元測試

　　 運行質(zhì)量保證驗收測試套件，以確保軟件已經(jīng)可以交給QA測試。

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

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

　　 報告錯誤

　　 錯誤審核-不斷開(kāi)展的活動(dòng)。

　　 根據需求修改測試用例

　　 根據需求增加測試用例

　　 測試周期二

　　 測試周期三

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

　　 執行所有前端測試用例-人工和自動(dòng)化。

　　 執行所有后端測試案例-人工和自動(dòng)化。

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

　　 提供對正在進(jìn)行的缺陷跟蹤度量。

　　 提供對正在進(jìn)行的復雜性和設計的度量。

　　 更新測試用例和測試計劃的估計時(shí)間。

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

　　7. 實(shí)施后

　　 開(kāi)展實(shí)施后評估會(huì )議以回顧整項工程。 (經(jīng)驗所得)

　　 準備最終的缺陷報告和相關(guān)度量。

　　 制定戰略以防止類(lèi)似的問(wèn)題在今后的項目中重復出現。

　　 創(chuàng )建如何改進(jìn)流程的計劃目標和里程碑，

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

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

　　 測試實(shí)驗室和測試環(huán)境-清理測試環(huán)境，標記和存檔用過(guò)測試用例和數據，恢復測試儀器到原始狀態(tài)等。

　　1、 引言

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

　　它并不是獨立存在的，而是一個(gè)完整產(chǎn)品生命周期實(shí)實(shí)在在的一部分。在產(chǎn)品生命周期之中，軟件的開(kāi)發(fā)會(huì )不斷改正其自身的錯誤并且時(shí)常針對軟件的需求而進(jìn)行調整。軟件產(chǎn)品最簡(jiǎn)單的形式只不過(guò)是一個(gè)程序軟件，但實(shí)際上確沒(méi)有那么簡(jiǎn)單，由于軟件產(chǎn)品是由開(kāi)發(fā)出的不同軟件部分所構成的一個(gè)完整的系統，這將會(huì )使產(chǎn)品變的非常復雜。

　　有許多不同的軟件開(kāi)發(fā)生命周期模型，但是它們都有一個(gè)共同的特點(diǎn)，那就是在生命周期中的某一時(shí)刻，軟件都會(huì )被測試。這篇文章概述了一些常用的軟件生命周期模型，并重點(diǎn)強調了在各個(gè)模型中的測試工作。

　　2、 順序生命周期模型

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

　　圖1、V型生命周期模型

　　圖2、瀑布生命周期模型

　　* 需求分析階段

　　這個(gè)階段主要是收集并分析用戶(hù)的需求，并且根據軟件需求建立完整而明確的需求說(shuō)明書(shū)。

　　* 概要設計階段

　　在這個(gè)階段，針對用戶(hù)需求的軟件結構將會(huì )被設計，并確定軟件內部各個(gè)部件的相關(guān)聯(lián)系。

　　* 詳細設計階段

　　軟件各個(gè)部件的執行功能將被詳細說(shuō)明。

　　* 遍碼與單元測試階段

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

　　* 軟件集成階段

　　這個(gè)階段被測試過(guò)的各個(gè)部件被逐漸集成起來(lái)測試直到構成了一個(gè)完整的軟件。

　　* 系統集成階段

　　這個(gè)階段將軟件程序集成起來(lái)，構成產(chǎn)品并進(jìn)行測試。

　　* 驗收測試階段

　　這個(gè)階段將進(jìn)行測試以驗證軟件確實(shí)完整的執行了用戶(hù)的需求。

　　3、 漸進(jìn)開(kāi)發(fā)生命周期模型

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

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

　　在軟件開(kāi)發(fā)中，通常將這種方法稱(chēng)為漸進(jìn)開(kāi)發(fā)或是執行階段。與之相對應的生命周期模型被稱(chēng)為漸進(jìn)開(kāi)發(fā)生命周期模型。在漸進(jìn)開(kāi)發(fā)的生命周期之中，每一個(gè)獨立的階段都將遵從V型和瀑布型生命周期模型。

　　圖3、漸進(jìn)開(kāi)發(fā)生命周期

　　每一個(gè)軟件的發(fā)布都會(huì )經(jīng)過(guò)驗收測試以證明軟件的各個(gè)部分所構成的整體確實(shí)實(shí)現了需求。但是每個(gè)階段的測試和集成將會(huì )耗費大量的時(shí)間和精力。由于過(guò)多的開(kāi)發(fā)周期會(huì )增加成本，耗費時(shí)間，所以應該經(jīng)過(guò)認真估算，盡早地規劃好到底應該使用多少個(gè)周期來(lái)進(jìn)行軟件的開(kāi)發(fā)。

　　在早期開(kāi)發(fā)出來(lái)的產(chǎn)品沒(méi)有任何的實(shí)用價(jià)值，只是作為下一步開(kāi)發(fā)的一個(gè)原型。這些原型僅僅是用來(lái)滿(mǎn)足、核對用戶(hù)關(guān)鍵需求所走的一個(gè)捷徑?？墒侨绻渲锌s減了文檔的書(shū)寫(xiě)和對軟件的測試，那么就有必要將這些將這個(gè)原型拋棄并從下一個(gè)階段開(kāi)始重新設計。因為一個(gè)缺乏質(zhì)量的原形不可能給下一步的開(kāi)發(fā)打下一個(gè)好基礎。

　　4、 迭代生命周期模型

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

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

　　圖4、迭代生命周期模型

　　*　需求分析階段

　　在這個(gè)階段，主要是收集并分析用戶(hù)的需求，并且制定這個(gè)迭代模型最終并且完整的需求說(shuō)明書(shū)。

　　*　定義階段

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

　　*　執行、測試階段

　　在這個(gè)階段，將對軟件進(jìn)行編碼，集中并進(jìn)行測試。

　　*　審查階段

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

　　在迭代模型的每一個(gè)周期，都要作出一個(gè)決定：要將編寫(xiě)出的軟件拋棄，還是作為下一個(gè)周期的起點(diǎn)。如果軟件完全符合了需求，那么就可以進(jìn)行發(fā)布，否則就是一個(gè)失敗的開(kāi)始。

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

　　也許經(jīng)過(guò)不斷的類(lèi)比也不能找到解決方案，而迭代的過(guò)程不是在可行的解決方案周?chē)P(pán)旋就是逐漸遠離目標。而且需要迭代的次數太過(guò)龐大會(huì )使軟件開(kāi)發(fā)變得不切實(shí)際，在很多軟件開(kāi)發(fā)的過(guò)程中我們都能發(fā)現這個(gè)問(wèn)題。

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

　　5、 維護

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

　　6、 概要和結論

　　無(wú)論何種生命周期模型被用于軟件的開(kāi)發(fā)，都會(huì )對軟件進(jìn)行測試。質(zhì)量、功能都很完美的軟件產(chǎn)品需要在其軟件開(kāi)發(fā)生命周期的早期進(jìn)行測試，并且無(wú)論發(fā)生什么變故，都要進(jìn)行完善的回歸測試。

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

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

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

　　AdaTEST 和 Cantata是使軟件測試能夠便捷，自動(dòng)化，可重復，可維護的工具。對于A(yíng)da、C、C++的軟件開(kāi)發(fā)有重要的意義。在漸進(jìn)模型或是迭代模型采用AdaTEST或是 Cantata進(jìn)行重復的維護性軟件測試，對于軟件開(kāi)發(fā)會(huì )有更大的收益。

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

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