軟體測試方案

1.測試前期準備工作1

1.1 測試環境準備1

1.2測試方法2

a.測試模型選擇2

1 .w模型2

2 .v模型2

1.3測試需求分析3

a需求分析3

b.需求確認3

c.需求變更3

1.4測試計畫4

a測試估算4

b任務分配4

1.5風險級別分析及控制5

a.風險分析5

b.風險控制5

c.風險跟蹤5

1.6缺陷管理6

a.缺陷管理流程6

b.提交缺陷6

c.分配缺陷6

d.修改，關閉，保留缺陷6

1.7評估出口準則和報告7

1.8測試結束活動8

1.9 測試文件的管理9

a.每個階段產生的文件9

b.缺陷管理產生的文件9

2.0團隊管理

a.分工合作10

b.績效考核10

環境基本要求：

a.穩定、可控的測試環境，可使測試人員花費較少時間完成測試用例的執行。

b.可保證每乙個被提交的缺陷被準確的重現。

c.經過良好規劃和管理的測試環境，可以盡可能的減少環境的變動對測試工作的不利影響。

1.2 測試方法

a. 測試模型選擇：

v模型在於它非常明確地標明了測試過程中存在的不同級別，並且清楚地描述了這些測試階段和開發過程期間各階段的對應關係.

w模型強調的是測試伴隨著整個軟體開發周期，而且測試的物件不僅僅是程式，需求、功能和設計同樣要測試。測試與開發是同步進行的，從而有利於盡早地發現問題。通常根據不同的專案選擇不同的測試方法

1.3 測試需求分析

測試需求的分析為四個部分:

a、明確需求的範圍：

1. rtm中的srs列表（粒度）

2. qc中的需求描述（不同層次）

3. uml的用例檢視（actor usecase）

b、明確每乙個功能的業務處理過程

1.拆點: 對應的每乙個功能點將其對應的輸入,處理和輸出進行提取

2.連線 :將每一功能所對應的輸入,處理和輸出形成業務活**;

c、不同的功能點作業務的組合

d、挖掘顯式需求背後的隱式需求

需求確認：對需求確認的過程主要採用的方法是同行評審，在專案過程中設立明確的需求評審點，邀請使用者代表及同行專家就測試需求分析的完備性、正確性等進行評審。

需求變更：當使用者或者測試團隊內部出現了乙個變更需求，變更提出人首先書面提出變更申請，通過相應的評審得到變更許可之後才能根據團隊已經定義的變更流程啟動變更，更改後的測試需求需要重新通過確認。在完成測試需求的變更後，要同步調整測試計畫、測試資源、測試策略等一系列與此相關的活動，並保證活動干係人得到必要的變更資訊。

1.4測試計畫

根據測試的種類，測試計畫分為功能測試和效能測試計畫。測試計畫旨在說明各測試階段任務、人員分配、時間安排、測試要點、工作規範等。測試計畫在策略和方法方面說明如何計畫、組織和管理測試專案。

測試計畫包含足夠的資訊使測試人員明白專案需要做什麼是如何運作的。測試計畫不包括測試用例的細節和系統功能的詳細資訊。測試計畫的制定請參閱《測試計畫》模板。

測試計畫應附有測試功能點矩陣、測試效能點矩陣。

測試計畫應在專案組內進行評審。參與測試計畫評審的人員包括：專案經理、測試組長、開發組長、測試組員

a測試估算：

試估算必須在測試計畫前制訂。根據三點發來進行估算，估算內容大致有：測試人員的人數，本次測試的工作量，測試用例/套件的數量，預計的測試指令碼，預計缺陷的數量，預計測試週期數，每個測試的平均工作量以及回歸測試週期的數目，預計各階段測試的開始時間結束時間等。

得出測試估算結果後，需要將結果提交給leader，並說明測試的價值。估算應採用迭代式的方法，每當變更時，我們就要重新制訂測試估算，隨著不斷的變更，系統逐漸完善，估算也會越精確。估算的文件要提交到檔案管理系統中，leader必須要根據最新的測試估算重新進行測試策略的安排，測試計畫的制定。

最後測試工作完成後要進行該產品潛在缺陷的估算，和發現風險並且修復的成本估算，並且與團隊制定應對的方案。

b任務分配：

必須將每個任務進行劃分落實到哪個人測試那個功能點編寫哪些測試用例等。各小組長每週與leader進行會議報告，報告本週的計畫，和上週發現的問題、缺陷和遺留下的任務。leader則將其記錄儀週報的形式上傳到文件管理系統中。

發生變更時，小組長應該與小組成員討論，變更後我們要估算預計增加/減少的測試用例/套件，小組長要將討論結果記錄。

1.5風險級別分析及控制

a風險分析：

可以由多個有經驗的測試人員或專家根據以前的測試專案經驗分別對風險發生的概率、風險發生後的嚴重性及其影響範圍、風險可能發生的時機以及風險發生後維持多長時間進行估計，通過加權平均法估計風險影響程度，由此得到軟體愛你測試的風險估計，然後通過對風險進行量化和排序確定風險的優先順序，最終形成風險列表作為風險計畫和風險控制的基礎。

b風險控制：

風險控制又包括風險管理和控制，要進行風險控制就要先進行風險管理。測試控制必須根據測試過程中產生的資訊，結合專案或任務的變更條件做出回應。例如，如果動態測試在認為不會出現較多缺陷的地方發現了缺陷群，或者由於測試的開始時間被推遲因而要縮短測試執行的時間，那麼必須對風險分析和測試計畫進行相應的修改。

c.風險跟蹤：

監視風險的狀況，檢查風險的對策是否有效、跟蹤機制是否在執行，不斷識別新的風險並制定相應的應對措施。

1.6缺陷管理

a.缺陷管理流程

b.提交缺陷

測試人員將缺陷填寫到管理工具中，選擇指派人為開發組長或相應的開發人員。

c.分配缺陷

開發人員分別對自己收到的缺陷進行評審。評審後如果對提交的缺陷有疑問，可以與提交人協商。對未能達成一致的缺陷由專案經理組織專案組成員評審。評審人員可以是專案組人員。

如果缺陷初次分配的開發人員無法修改該缺陷，初次分配的開發人員可以將缺陷再次分配給其他開發人員。但為避免缺陷被多次分配，專案經理應跟蹤3天以上未修改的缺陷。

d.修改，關閉，保留缺陷

開發人員對已確認的缺陷進行修改，填寫修改記錄，修改缺陷狀態為「已修改」或其他狀態。測試人員對已修改的缺陷進行驗證。如果已修改完成，測試人員將缺陷狀態設定為關閉。

如果沒有修改或引起回歸問題，將修改缺陷狀態為「重新開啟」或新增缺陷，由開發工程師繼續修改。對於有爭議的缺陷進行，將有專案經理最終決定是否修改。如果缺陷是由於技術原因、版本原因不能修改，則保留該缺陷。

軟體測試方案

軟體測試測試方案

軟體測試方案

軟體測試方案

相關推薦