軟件測試生命周期

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

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

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

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

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

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

Planning - this is the product definition phase

這是產(chǎn)品測試概念定義的階段。我覺(jué)得這部分的工作主要是管理人員在做，然后讓測試組員進(jìn)入某些活動(dòng)。

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

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

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

4. Problem Reporting Procedures 制定錯誤報告的流程。比如說(shuō)那些問(wèn)題要報，那些問(wèn)題暫時(shí)不用報。書(shū)寫(xiě)的格式，跟蹤的方法等等。

5. Identify Problem Classification 制定錯誤報告的類(lèi)型。比如說(shuō)那些是UI的，那些是功能的，那些是性能的等等。

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

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

8. Identify measurement criteria制定錯誤的優(yōu)先級別。分為緊急啊，一般啊，較高啊之類(lèi)的級別。用來(lái)給開(kāi)發(fā)人員參考，那些需要先修改。

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

11. Review Product Definition Document 復檢產(chǎn)品定義文檔。主要是重新對設計文檔進(jìn)行閱讀，對現在開(kāi)發(fā)的產(chǎn)品進(jìn)行檢驗，防止出現誤差。并且對一些設計提出用戶(hù)角度的觀(guān)點(diǎn)等等。這個(gè)應該不用所有測試人員參與。生成的應該是設計文檔的一個(gè)修改和一個(gè)會(huì )議記錄之類(lèi)的文檔。

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

Analysis -This is external document phase
這是一個(gè)外部文檔階段。之所以說(shuō)是外部文檔，是因為這個(gè)階段的工作主要都是從客戶(hù)和開(kāi)發(fā)組得到的文檔。在這個(gè)階段，對這些外部文檔進(jìn)行分析和總結。根據得到的信息，去創(chuàng )建測試的框架和文檔。所以本階段主要的工作是完成分析，搭出框架，書(shū)寫(xiě)大綱等。并不是要所有的文檔工作都在本階段內完成。

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

Design - This is architecture document phase

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

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

包括的主要工作是：
1. Revise Test plan base on changes 根據具體的變化重新調整測試計劃。
2. Revise Test Cycle matrices and timelines 根據計劃的調整，調整各個(gè)測試輪次的內容和時(shí)間。
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 繼續書(shū)寫(xiě)已經(jīng)設定的測試用例和添加新的測試用例。一個(gè)測試用例，在本文中在上個(gè)階段書(shū)寫(xiě)的時(shí)候可能只有一個(gè)簡(jiǎn)單的描述，具體的測試步驟需要后面填寫(xiě)。有的時(shí)候，有些測試用例事先沒(méi)有考慮到，有些是重復的，所以需要刪改。
6. Develop Risk Assessment Criteria 設置風(fēng)險評估標準。通過(guò)設置風(fēng)險評估，可以有效的幫助我們靈活的調整計劃。比如，某個(gè)測試輪次是需要50個(gè)小時(shí)完成，而我們風(fēng)險評估標準將這類(lèi)測試設定為時(shí)間值應該設置為150％，也就是說(shuō)，在計劃中應該填寫(xiě)75小時(shí)為實(shí)際設定完成時(shí)間。
7. Finalize test cycles 最終完成各個(gè)測試輪次的設置。在本階段結束后，除非有其他的特殊情況，通過(guò)預先設置的危機處理方法處理外，不再修改。
8. Finalize Test plan 完成測試計劃。
9. Estimate resource to support development in unit testing 評估支持開(kāi)發(fā)人員進(jìn)行單元測試的可行性。有些項目，需要測試人員去幫助開(kāi)發(fā)人員進(jìn)行單元測試。

Construction - This is unit and model testing phase
本階段是在開(kāi)發(fā)人員編碼的同時(shí)，最終完成系統預先設置的各種測試用例的階段。本階段的很多工作其實(shí)在上個(gè)階段就已經(jīng)涉及到了。本階段完成后，進(jìn)入測試的主要階段，對產(chǎn)品進(jìn)行實(shí)現設定的各種測試。

包括的主要工作是：

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

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

包括的主要工作是：
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
本階段是代碼凍結后的測試階段。這個(gè)時(shí)候需要進(jìn)行的是最后的驗證測試。本輪主要是完成最終的性能，壓力，文檔測試和UI等測試過(guò)程，開(kāi)始形成系統說(shuō)明書(shū)和用戶(hù)手冊。

包括的主要工作是：

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

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

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

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


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