1.軟體的生命週期

同任何事物一樣，軟體也有一個孕育，誕生，成長，成熟，衰亡的過程，這個過程被稱為軟體生命週期

大致可分為以下幾個階段：

制定規劃->系統與與軟體需求分析->軟體設計->程式設計與單元測試->整合與系統測試->執行與維護

每個階段都有每個階段要完成的任務

（按以上階段的順序進行每個階段任務簡要的描述）

（1）確定開發軟體的總目標，給出功能，效能，可靠性以及介面等方面的要求

（2）與客戶合作，獲得待開發軟體的具體功能，效能，可靠性以及介面等方面的要求，以及其他質量需求，然後對這些需求進行分析和建模，從而得到詳細的定義

（3）設計人員把各項需求轉換成一個個相應的體系結構。設計每個意義明確的模組為概要設計，進而對各個模組要完成的工作進行具體的描述為程式設計打下基礎為詳細設計

（4）把設計詳細轉換成可以接受的程式程式碼

（5）把開發完成的各個模組按照規定的順序組裝起來，進行系統的測試，確定軟體是否符合開發的需求規格

（6）對已經投入使用的軟體進行維護和修改等

軟體測試伴隨著整個軟體生命週期，而並不只是在軟體開發完成後才進行測試的

測試的物件也不僅僅是程式，還包括需求定義文件，設計文件等，使錯誤和缺陷儘可能早的被發現以減小損失

測試過程和開發過程貫穿著整個軟體生命週期，它們是相輔相成，互相依賴的關係，概括起來有三點：

（1）測試過程和開發過程是同時開始同時結束的，兩者保持同步的關係

（2）測試過程是對開發過程中產生的各種中間產品和最終產品進行確認的過程

（3）測試和開發的工作重點是不一樣的，兩者有各自的特點

如果測試結果軟體的功能能夠正常的完成，出現的錯誤已與修改，那麼可以斷定：

（1）軟體的質量和可靠性已經到達可以接受的程度

（2）所做的測試不足以發現嚴重的錯誤

2.需求獲取和分析階段的測試

1）需求規格說明的評審

評審內容主要有：

（1）清晰性：系統的目標是否已定義，需求的描述是否清晰，是否對整個系統進行了功能概括等

（2）完整性：是否列出了系統所必須的依賴，假設和約束等

（3）依從性：文件是否是否遵守了文件的編寫標準

（4）一致性：需求說明是否存在直接相互矛盾的條目

（5）可行性：所描述的功能是否必要並充分的滿足客戶的需求，描述的詳細程度是否足以進行詳細設計等

（6）可管理性：是否所有的需求都可以追溯到相應的需求材料等

使用用例法（用例圖）建立功能模型時應該避免的問題：

（1）用例過多

（2）用例過於複雜

（3）在用例中包含了介面設計

（4）在用例中包含了資料定義

（5）使用者無法理解用例

（6）新的業務流程

（7）濫用包含和擴充關係

3.設計階段的測試

設計階段為什麼需要測試，因為設計人員應該有一個範圍廣泛的質量目標

測試的目的就是確認設計是否滿足了這些質量目標

而設計又可分為概要設計和詳細設計

對於兩種設計所產生的設計規格說明書有著不同的評審內容

4.程式設計階段的測試

程式設計階段的測試主要集中在程式程式碼和程式碼符合設計規格的程度上

白盒測試也可以看做程式設計過程的一部分，因為當程式模組在與系統進行整合之前或者之後，程式設計師通常會對模組進行白盒測試

而黑盒測試人員不必花時間學習程式原始碼，相反，他們從外部來研究程式

原始碼的靜態分析和動態測試：

進行靜態分析時不必執行程式，目的是收集程式程式碼的結構資訊而不是排錯

動態測試的目的則是相反

因此黑盒和白盒測試都是動態測試

5.迴歸測試

1）迴歸測試的概念：

軟體因為各種各樣的原因必須進行一些修改和升級，但是無論何時這種修改必須保證：

按照設計進行修改和補充

修改和補充的功能不能對已有有效的內容造成破壞，而且繼續有效

執行迴歸測試的目的就是為了保證以上兩個保證

2）迴歸測試的型別：

常規迴歸測試：在軟體的生命週期各個階段之間進行，保證缺陷修改已經完成，並且不會影響原有的功能

最終迴歸測試：在軟體釋出前確認產品的最終版本，釋出版的所有缺陷必須在最終測試版本中得到修正，因為這是保證到達客戶的經過測試的唯一測試

最終迴歸測試必須在規定好的一段時間內進行，因為有些缺陷是要經過一段時間才能被發現的（如記憶體洩露等）

3）迴歸測試的實施：

迴歸測試是軟體釋出前最後實施的一類測試，所以異常重要，不同團隊的做法各不相同，但是一下步驟應該是相同的

（1）實施第一次冒煙或摸底測試

只要對軟體進行了修改，首先就要保證沒有破壞什麼東西

冒煙測試包括一下工作：

確定產品必須滿足的基本功能

設計測試用例，並保證這些基本功能都是有效的，並裝入冒煙測試包

保證每次構建產品時，都能在執行其他測試之前成功的執行這個測試包

如果測試包沒有通過，請開發人員確定該變更，並可以退回到執行冒煙測試包成功的狀態

（2）理解選擇測試用例的準則

一是對於各個不同的版本都用一組不變的測試用例，缺點是可能無法測試出所有的缺陷

二是通過評審測試用例，動態的選擇測試用例，缺點是必須瞭解當前版本有哪些缺陷和變更

（3）測試用例分類

為了使迴歸測試選擇合適的測試用例，可以根據其重要性和客戶使用情況將測試用例按優先順序分類

（4）選測試用例的方法

根據缺陷或修改的影響程度選擇相關優先順序的測試用例

（5）重新設定測試用例以進行歸回測試

（6）總結迴歸測試的結果