軟件測試生命周期

MILY: Arial">Software Testing Life Cycle
php?name=%C8%ED%BC%FE%B2%E2%CA%D4">軟件測試生命周期

如同軟件生命周期，我們也可以將軟件測試階段按照生命周期的方法去分析。

【這種思想，我是在一個國外的網站上看到的。對于如何開始和什么時候開始進行軟件測試，我覺得目前來說如果硬性的去規定按照什么什么流程來說，有點形式主義。我個人的經驗來說，很多項目都是在開發人員完成大部分代碼的情況下提交給測試人員測試。很多時候，都沒有任何文檔，即使有也沒有時間去看。這個時候如果按部就班的去制定什么測試計劃，測試用例等等，不是不能，但是基本上都因為時間和項目進度的影響而大量的縮減形成的文檔的數量。

但是，不做不代表著我們不去思考。個人覺得，在當前中國軟件測試水平比較低的狀態下，我們應該做到即使沒有去做，但是也應該想到，而且應該不斷的思考和學習，并且廣泛的交流經驗。為了將來的從事測試行業的新人們能夠提供足夠多的借鑒。所以，盡量做到拋磚引玉吧

這篇文章是借鑒了原作者的思想，將其主要內容用中文表達出來，所以大部分是作者的思想，但是不免帶有我個人的一些主觀想法，所以還請各位諒解。而且由于原作者是共享的是一個公司內部的文檔，所以我也不便將其原文貼出，不過主要思想我是能夠提供給大家的。共同學習�！�

軟件測試周期分為如下的階段：
Planning 計劃階段
Analysis 分析階段
Design    設計階段
Construction 書寫階段
Testing Cycles 測試階段
Final Testing    完成階段
Implementation 執行階段

Planning - this is the product definition phase

這是產品測試概念定義的階段。我覺得這部分的工作主要是管理人員在做，然后讓測試組員進入某些活動。

包含的工作是：
1. High Level Test Plan 制定一個高級別的測試計劃，應該就是測試大綱了，包含多個測試周期的設定等等。

2. Quality Assurance Plan 制定測試的目標，質量參數，beta測試的驗收標準等等。

3. Identify when review will be held 制定各個階段進行review的時間。這個review應該是對上階段的情況進行分析和總結，以調整計劃。也應該有一些討論測試覆蓋率或者某些Test case或者人員的不足啊之類的東西吧。

4. Problem Reporting Procedures 制定錯誤報告的流程。比如說那些問題要報，那些問題暫時不用報。書寫的格式，跟蹤的方法等等。

5. Identify Problem Classification 制定錯誤報告的類型。比如說那些是UI的，那些是功能的，那些是性能的等等。

6. Identify Acceptance Criteria 制定軟件可接受標準。比如說錯誤率在多少，那些錯誤可以暫時不修改，測試多少輪，覆蓋率多少，測試深度多少等等。

7. Identify application testing databases 制定程序測試數據庫。這個可能是模仿用戶需求的數據庫模型是什么，或者也可能是一個包含需要測試的數據的庫

8. Identify measurement criteria制定錯誤的優先級別。分為緊急啊，一般啊，較高啊之類的級別。用來給開發人員參考，那些需要先修改。

9. Identify metrics for the project 制定項目的跟蹤。比如一些跟蹤文檔，每周提交的weekly report之類的。例如在周報里面包含著本周新寫多少個問題，解決了多少個問題，有多少問題是無效的，運行了多少個測試用例，通過率是多少等等。10. Begin overall testing project schedule 制定詳細項目計劃表。包括每個階段的具體時間了，需要的人數了，需要的資源了等等。

11. Review Product Definition Document 復檢產品定義文檔。主要是重新對設計文檔進行閱讀，對現在開發的產品進行檢驗，防止出現誤差。并且對一些設計提出用戶角度的觀點等等。這個應該不用所有測試人員參與。生成的應該是設計文檔的一個修改和一個會議記錄之類的文檔。

12. Plan to manage all test cases in a database, both manual and automated. 設立一個數據庫將手工測試和自動測試用例放到一起管理。我覺得不如只輸入編號，然后剩下得字段用于記錄每個測試用例在不同軟件版本時的情況。例如，是否通過，還是阻塞了和有那些問題報告等等。

Analysis -This is external document phase
這是一個外部文檔階段。之所以說是外部文檔，是因為這個階段的工作主要都是從客戶和開發組得到的文檔。在這個階段，對這些外部文檔進行分析和總結。根據得到的信息，去創建測試的框架和文檔。所以本階段主要的工作是完成分析，搭出框架，書寫大綱等。并不是要所有的文檔工作都在本階段內完成。

包括的主要工作是：
1. Develop Functional validation matrix based on Business requirements 制定功能驗證矩陣，基于商業要求。嗯，我覺得這里應該是根據設計說明書來劃分需要測試的功能區域，每個區域內要測試的元素和功能邏輯。這樣就是建立了一個可以被測試用例和問題分類使用的功能驗證表格。而且可以檢驗測試的覆蓋度。
2. Develop Test Case format 制定測試用例格式。就是制定一系列的文檔格式。對于UI，功能，性能，自動化測試腳本等應該都有不同的格式規范。然后給出測試優先級別，這樣優先級別低，對系統影響小，一般都比較穩定的一些測試用例就可以減少測試頻率和周期次數。然后最好給每個測試用例估計一個時間，這樣便于統計和管理人力資源。
3. Develop Test Cycles matrices and time line 制定測試輪次和時間線。這時候應該是根據寫好的測試用例估計的時間，按照對系統的不同測試點制定測試輪次。然后每個輪次之間有個時間點。例如在剛剛收到產品時，做的都是簡單的功能的驗證測試。這時候可以設置一個測試目標，選擇一批測試用例。然后在測試目標達到后（比如，測試用例通過率達到85％）就可以進行復雜的功能測試。這個就可以稱之為一個輪次。是以測試用例走完一遍為測試輪次的。當然也可以設置，一周或一個月為一個輪次。因此我們看到，找個實際上考驗的是一個領導者制定計劃和管理執行計劃的能力。好的管理人員就能夠制定有效的針對具體系統不同的計劃，而不是一成不變，老是用一套方法。
4. Begin writes Test Case based on Functional Validation matrix 根據功能驗證矩陣書寫測試用例。 這個就沒什么好說了，以前寫過一個怎么寫測試用例的文檔�？傊�一句話，測試用例書寫的標準就是滿足需要，而不是硬套模板。
5. Map baseline data to test cases to business requirements 將用戶需求中的設定測試數據和測試用例鏈接。有些用戶，需要你對某些特殊的數據結構或者數據類型等等進行測試，這時候就需要將那些數據獨立出來，以便能夠復用。
6. Identify test case to automate 標示出能夠使用自動工具的測試用例。將一些能夠使用自動化測試的用例做一個標示，這樣，在人力資源較少的時候，或者需要快速回歸的時候就可以使用自動工具了。有些測試用例是直接就寫成測試腳本使用測試工具測試的。有些是事先寫為手工測試測試用例，可以通過使用已有的自動測試腳本快速的編制成自動測試用例的。畢竟手工測試和自動測試各有利弊。
7. Automation team begins to setup variable files and high-level scripts in Auto tester. 對于自動化測試組來說，這個時候就要做一些基本的工作了。像一些公用的文件和一些一些基礎的公共函數和方法。
8. Define area for Stress and Performance testing 制定出要進行壓力測試和性能測試的區域。并書寫測試用例。
9. Begin setup the test cycles 根據已經完成的測試用例，開始制定測試輪次中包括的測試用例，總輪次，測試時間等等。
10. Review the documents 不斷的復查文檔，防止出現偏差。這個工作可以有一個固定周期，比如一個月內有幾次，分別查看那些文檔等等。
11. Review test environments 檢查測試環境。包括軟件，硬件，人力等等。

Design - This is architecture document phase

本階段是完成測試內部文檔的階段，這些文檔大部分都是在分析階段形成了大體的組織結構和大綱的文檔，像測試用例之類的都有了一些基本的描述，本階段主要的工作就是完成這些文檔的最終書寫。在本階段后，基本上測試計劃，測試時間表，測試數據，各種相關文檔都應該處于完成階段。當然，仍然可以通過設計的危機處理機制進行更新。

但是特別要指出的是，測試用例并不能夠在本階段完成。由于新功能的添加，具體功能的實現方法，修改功能等因素，測試用例只能不斷的更新。

包括的主要工作是：
1. Revise Test plan base on changes 根據具體的變化重新調整測試計劃。
2. Revise Test Cycle matrices and timelines 根據計劃的調整，調整各個測試輪次的內容和時間。
3. Revise Functional Matrix 根據變化調整功能設置。
4. Verify that test case and test data 確認已有的測試用例和測試數據仍然有效。
5. Continual write test cases and add new test cases base on changes 繼續書寫已經設定的測試用例和添加新的測試用例。一個測試用例，在本文中在上個階段書寫的時候可能只有一個簡單的描述，具體的測試步驟需要后面填寫。有的時候，有些測試用例事先沒有考慮到，有些是重復的，所以需要刪改。
6. Develop Risk Assessment Criteria 設置風險評估標準。通過設置風險評估，可以有效的幫助我們靈活的調整計劃。比如，某個測試輪次是需要50個小時完成，而我們風險評估標準將這類測試設定為時間值應該設置為150％，也就是說，在計劃中應該填寫75小時為實際設定完成時間。
7. Finalize test cycles 最終完成各個測試輪次的設置。在本階段結束后，除非有其他的特殊情況，通過預先設置的危機處理方法處理外，不再修改。
8. Finalize Test plan 完成測試計劃。
9. Estimate resource to support development in unit testing 評估支持開發人員進行單元測試的可行性。有些項目，需要測試人員去幫助開發人員進行單元測試。

Construction - This is unit and model testing phase
本階段是在開發人員編碼的同時，最終完成系統預先設置的各種測試用例的階段。本階段的很多工作其實在上個階段就已經涉及到了。本階段完成后，進入測試的主要階段，對產品進行實現設定的各種測試。

包括的主要工作是：

1. Complete unit-testing 完成單元測試
2. Complete all test case manual 完成所有的手工測試用例。隨著系統不斷開發，在拿到一個完整的軟件版本之后，基本上手工測試用例都能夠完成書寫。
3. Complete auto testing tools 完成自動測試工具的開發。這個階段可以設計編寫一些專用的自動測試工具。
4. Complete Stress test case 完成壓力測試用例
5. Complete performance test case 完成性能測試用例
6. Review the functional matrix 重新復檢功能表
7. Complete auto test case 完成自動測試用例

Test Cycle - This is phase that to run Test Cycle(s), report bugs, verifies Bug fixes etc.
這個階段就是最費時間的階段了。按照實現制定好的計劃，利用各種資源，工具，依循實現書寫的測試用例對系統進行一輪輪的測試，直到代碼凍結階段。本階段也包含了不斷設置的回歸測試。

包括的主要工作是：
1) Test Cycle 1, run first set of test cases
2) Report bugs
3) Bug Verification
4) Revise test cases as required
5) Add test cases as required
6) Test Cycle II
7) Test Cycle III
      ..............


Final testing - This is code freeze phase
本階段是代碼凍結后的測試階段。這個時候需要進行的是最后的驗證測試。本輪主要是完成最終的性能，壓力，文檔測試和UI等測試過程，開始形成系統說明書和用戶手冊。

包括的主要工作是：

Execution of all front to end test case – manual and automated

Execution of all back to end test case – manual and automated
上面是在最后進行產品gold的時候，進行的測試，主要是一些大的功能的傳測，測試用例一般是對主要功能的一些驗證。防止出現最終打包出錯等認為因素。

Execute all Stress test
Execute all Performance test
Execute all UI test
Execute all documents test
Do the last cycle regression test
以上測試就是最終的功能測試，這個時候一般不在去修改主要的源代碼，只是對外觀和界面的錯誤進行修復。只是對現有的一些問題進行跟蹤和管理，必要的時候準備出版hot fix版本。

Implementation - This is review entire project phase
本階段是對整個項目進行總結的階段。
主要是書寫一些最終的報告。例如，錯誤分析報告，包括一共有多少個，有效率是多少，分布情況如何等等。這個階段主要是將好的經驗總結下來，對不足進行思考，為下個項目做準備的放松的階段。


從上面的敘述來說，這些階段并不完全的各自獨立的階段。劃分的主要依據是根據主要的工作目標而來。各個階段不但相互影響，而且有時候時間上還會彼此交叉和顛倒。但是，最大的好處就是能夠讓測試人員更好的理解各項工作的目標和作用。而不是獨立的去寫測試用例，不管為什么。個人認為，這樣把開發的生命周期概念融合進來，盡管這樣劃分有待討論，但是可以讓那些不熟悉測試的開發人員和測試人員對測試工作有個整體上的感受。所以，本文就是一個入門的普及讀物吧。