軟件測試規范

由安博測試空間技術中心提供

目錄

一、簡介........................................................................3

（一）軟件測試的定義............................................................3

（二）軟件測試類型的劃分........................................................3

（三）測試中權衡的三個重要維度..................................................4

（四）不同階段測試精度的把握....................................................4

（五）測試順序..................................................................4

二、測試工作流程................................................................5

（一）測試準備..................................................................5

（二）測試的實施................................................................5

（三）測試問題處理流程..........................................................7

（四）測試驗收..................................................................8

（五）測試總結..................................................................8

三、測試人員的組織與培訓........................................................8

（一）測試人員的組織............................................................8

（二）測試人員的培訓...........................................................10

四、測試工作機制一會議與討論...................................................11

（一）測試工作啟動會議.........................................................11

（二）階段性會議...............................................................11

（三）專題會議.................................................................12

（四）討論.....................................................................12

五、測試案例的編寫.............................................................12

（一）案例編寫的原則...........................................................12

（二）測試案例的取舍...........................................................13

六、測試相關文檔...............................................................14

（一）測試計劃書...............................................................14

（二）測試方案書...............................................................15

（三）測試報告.................................................................17

（四）其他文檔資料.............................................................18

一、簡介

(一)軟件測試的定義

軟件測試的定義是“為了發現程序中的錯誤而執行程序的過程”，具體地說，軟件測試

是根據軟件開發的產品設計說明書和程序的內部結構而精心設計出一批測試案例，并利用測

試案例來運行程序，以發現程序錯誤的過程。

(二)軟件測試類型的劃分

軟件測試貫穿于整個開發過程中，軟件系統的開發過程是一個自頂向下逐步細化的過

程，而測試過程則是按相反順序逆行的集成過程，根據測試的階段、測試的執行人，可劃分

為：單元測試(unittesting)>組合測試(incrementalintegrationtesting)、集成測試

(integrationtesting)、系統測試(systemtesting)、用戶驗收測試。根據測試內容的不

同可分為:功能測試(functionaltesting)>安全性測試(securitytesting)、恢復測試

(recoverytesting),兼容性測試(硬件兼容、版本兼容)、容錯性測試、性能/壓力/負載

測試(performance/stress/loadtesting)、安裝/卸載測試(install/uninstall

testing)在本文中，我們使用測試階段的劃分標準。

圖一:軟件生命周期“臺階”模型圖：

（三）測試中權衡的三個重要維度

測試時間、測試成本和測試質量構成測試過程中需要關注的三個重要維度，三個維度相

互制約、相互影響。在測試中，永遠無法實現時間、成本和質量的三贏，為其中任何2個目

標所做的努力，都必須以付出第三個目標的損失為代價，此外我們永遠都不可能窮盡所有的

測試內容。因此必須綜合權衡作出取舍。

圖二：制約測試的三個要素

（四）不同階段測試精度的把握

考慮到測試時間、測試成本的制約，在不同的測試階段，對測試精度有不同的要求。從

單元測試、集成測試到系統測試、用戶驗收測試階段，對測試精度的要求也呈現一個從粗到

細的過程。單元測試是發現錯誤最多、預防質量隱患最重要的測試階段，需要最大的測試精

度，缺少單元測試，宜接進行集成和系統測試，缺陷隱患多。

圖三：不同測試階段測試精度模型圖

單元測試集成測試系統測試用戶驗收測試

工程安裝測試

（五）測試順序

對于一項復雜產品的測試，遵循一定的測試順序，可以是測試工作有條不紊，提高測試

工作效率。同時按照一定的測試順序展開測試，一定程度上可以確保測試工作的全面性。

測試順序的原則是由淺入深、由易而難。在具體的測試內容上表現為：

?先聯機測試后批量測試；

?首先單元測試，其次集成測試，然后進行系統測試及驗收測試；

?先進行基本功能測試再進行輔助功能測試；

?先進行正常情況案例的測試，再進行反常情況案例的測試；

?對于一項交易先進行輸入項的測試,再進行輸出項的測試,然后進行賬務處理的測試。

二、測試工作流程

(一)測試準備

在技術實現編碼階段的工作結束時，進入產品的測試準備階段，為真正開展產品測試

做好前期準備工作。

測試準備階段的主要工作包括制定測試工作計?劃、設計測試方案、組織協調測試人員、

測試所需硬件設施等其他準備工作。測試準備階段的工作由參加產品設計說明書的主創人員

負責完成。

1、制定測試工作計劃和測試方案

相關內容見測試文檔編寫

2、組織協調測試人員

根據測試計劃和測試方案，組織協調相關人員，形成測試工作組。

3、測試人員的培訓

正式開展測試工作之前，對所有測試人員進行測試工作的集中培訓。通過測試培訓，

使測試人員明確測試目標和要求、了解待測系統、統一測試方法和流程，保質保量的開展和

進行測試工作。

4、測試所需要硬件設施和其他準備工作

與相關部門聯系協調對測試工作所需的設施：服務器、測試機等在測試準備階段全部

到位。

(-)測試的實施

測試實施是軟件測試工作的核心階段，測試實施階段嚴格按照測試計劃和測試方案展

開。

1、搭建測試環境

根據產品的實際需要搭建的運行環境及準備相關測試所需初始數據。包括：測試人員、

測試工具等。

2、單元測試

單元編碼完成后，進行單元測試。單元測試指構建者的角度出發，檢測產品的各個部分

是否是正常、合理、安全的，換句話說，就是通過檢測要保證軟件產品滿足用戶操作的質量

標準。

單元測試關注的重點是產品的內部結構、框架以及技術實現是否符合產品設計說明書等

等。

單元測試可以并行進行。對于彼此獨立的單元，進行并行測試可以加速測試的進程。

單元測試按照測試進程可分為聯機功能測試和批量功能測試兩個階段，其中批量測試階

段需要建立手工賬，以便于同系統處理結果相互核對。

3、集成測試

集成測試在所有單元測試完成之后進行。集成測試也稱綜合測試，即將已分別通過測試

的單元按要求組合起來再進行的測試，以檢查這些單元之間的接口是否存在問題。或按設計

要求把通過單元測試的各個模塊組裝在一起之后，進行測試以便發現與接口有關的各種錯

誤。

集成測試的重點是各個模塊之間的接口的功能進行測試。

4、系統測試

系統測試是整個測試階段的最后一步，所有的開發和測試在這一點上，集中表現為生成

一個具有一定功能的軟件系統，整個系統開發完成，即將交付用戶使用。

系統測試主要對系統的準確性及完整性等方面進行測試。分別進行：運行測試、強度測

試、恢復測試、安全性測試等。

目前系統測試的主要工作由技術人員完成，業務測試人員協助工作。

5、需求維護

需求維護指測試過程中根據每項測試結果發現前期需求不合理之處并對其進行相應的

調整和改正。

需求維護工作貫穿整個測試過程。

測試階段的需求維護工作是整個產品產生過程中需求維護工作的一部分。

（三）測試問題處理流程

測試問題處理流程可以采用以下兩種形式

形式1:

形式1與形式2之間的主要差別在于測試問題的分析流程，形式一由開發人員對測試問

題統一分析，查明原因后交給相應的人員解決修改；形式二業務人員在測試中發現問題后，

繼而分析問題緣由，由測試人員將問題交給相應人員解決修改。

（四）測試驗收

測試驗收階段的主要工作是：以客戶使用的角度，再次確認系統的可操作性、正確性、

全面性和完整性。為產品的上線應用、推廣營銷最后把關。

測試驗收工作相關業務由上?？偛考拔靼惭邪l部共同組織人員負責。

測試驗收階段依舊沿襲測試實施階段使用到的各種測試形式和方法，依據測試實施階段

產生的測試問題報告單、交易記賬憑證、報表、測試案例單、階段性測試總結等各種文檔和

資料展開。

（五）測試總結

測試總結階段是測試工作的最后一個階段，要進行以下四項工作：

1、對測試階段工作完成情況、工作方法進行總結。

一方面總結好的方法和經驗用于指導將來的測試工作；另一方面發現不足需改進之處，

引起借鑒，并在今后的工作中加以避免。

2、對測試驗收階段的遺留問題的進行匯總、統計和分析，并提出解決和修改建議。

3、整理文檔。

包括：產品設計說明書最終版本、產品培訓教材、產品操作手冊以及測試階段生成的各

種文檔資料。

4、編寫測試報告。

詳見相關測試文檔規范。

三、測試人員的組織與培訓

（一）測試人員的組織

1、具體組織形式

測試T作的組織形式分為項目經理、測試組、支持組0項目經理自責全面地組織和協調

工作。測試的工作實體(最小組織單位)是測試組和支持組，分別設組長全權負責。測試組由

測試人員組成，負責測試案例的編寫、具體的測試操作、測試問題的記錄與反饋，以及對己

修改問題的回歸測試和驗收等工作。根據測試工作內容的具體需求，測試組可以按照業務種

類或其他分為若干小組開展工作。支持組由朱莉負責主要工作是測試的后勤保障和日常管理

工作，如網絡管理、數據備份、文檔管理、設備管理和維護、日常事務管理和檢查等。

2、主要職責

(1)項目經理(李永平)

職責：

①擬定產品測試階段的總體工作思路、測試方案等。

②產品測試階段測試人員、支持人員的組織工作。

③把握工作進度，監督、控制、督促產品測試工作按計劃進行。

④對測試組和支持組的工作進行必要的溝通和協調，建立測試組與支持組相互配合、

支持、協作的橋梁。

⑤對產品測試階段工作的總結和評估；包括分階段性工作、總體工作的總結與評估。

?與相關部門就測試工作所需的軟、硬件設施進行溝通和協調：如：測試工作場地、

網絡環境、所需設施、其他憑證、報表等。

⑦參與產品測試階段的具體測試工作。

(2)測試組組長

職責：

①擬定產品測試階段的總體工作思路、測試計劃、測試方案等。

②組織本組測試人員的開展本組負責的測試工作，包括組員的工作安排、工作檢查和

問題反饋等。

③把握工作進度，監督、控制、督促本組測試工作按計劃進行。

④與支持組互相配合、支持、協作。

⑤對測試組工作的總結和評估；包括分階段性工作、總體工作的總結與評估。

⑥對產品測試中發現的問題總結、分析，形成問題報告單，與支持組進行溝通。

⑦參與產品測試階段的具體測試工作。

（3）支持組

職責：

①對測試組的測試工作進行業務、技術以及后勤設備各方面的支持。

②與測試組互相配合、支持、協作。

③日常測試支持性工作。

④參與產品測試階段的具體支持工作。

（4）測試人員

職責：

①根據測試方案編寫測試案例。

②按照測試計劃開展所負責的測試工作。

③提交問題，協助測試組長完成問題報告單。

④測試作中需求的解群和維護_L作。

⑤配合測試組長對測試階段工作進行總結；包括分階段性工作、總體工作的總結。

⑥組長分配的其他工作。

測試組成員應對熟悉負責測試的業務，參加過產品測試工作，掌握一定的測試方法和技

巧。

（二）測試人員的培訓

1、培訓人員的選擇

在測試準備階段要首先確定進行培訓的人員。

進行測試培訓的培訓人員應參加過前期產品設計，對所測產品的創意、產品構架、業務

流程、主要功能等方面非常熟悉；具測試工作經驗，參加過產品測試工作，熟悉測試工作流

程，掌握一定的測試方法和技巧；同時具有培訓經驗，擅長溝通和表達。

2、培訓內容

測試培訓包括兩方面內容：一方面是測試方法和技巧、測試形式、相關測試工具等；

另一方面圍繞產品設計說明書對待測產品進行詳細的介紹和講解，其中重點在于新產品的突

破創新之處、整體架構、業務流程、主要功能等。

3、培訓形式

培訓形式以授課方式為主，包括講授和基本操作的演示。培訓課程之外可以采用測試經

驗交流、提問和討論等各種形式對培訓課程未能涉及的方面進行補充。

四、測試工作機制一會議與討論

會議是測試工作中進行溝通和交流的有效的方式和手段。

（一）測試工作啟動會議

在啟動會議中要明確測試工作的目標、任務，協調人員配置，強調工作紀律。同時會議

應詳細介紹測試工作計劃和方案，使與會的測試組成員明確測試工作的整體思路、各自的主

要工作和責任，做到心中有數。測試工作啟動會議是測試工作的開端，標志著正式進入產品

測試階段。

測試工作啟動會議由測試主管主持，測試工作組全體成員和非測試組成員代表參加。

（二）階段性會議

不同測試階段的測試工作重點不同，召開階段性會議，對前階段的測試工作進行總結，

同時對下階段的測試工作進行安排。包括強調測試重點、介紹此階段的測試方法和形式、人

員的調整和分工、需要完成的相關文檔等內容。

階段性會議由測試主管支持，測試工作組全體成員參加。

階段性會議也可由測試組、支持組組內定期召開，對本組階段性工作進行總結和下階段

工作的安排。

（三）專題會議

測試過程中測試組、支持組，或測試組與支持族之間針對某個測試工作中具體問題的商

議、解決可以采用專題會議的形式

針對具體問題的專題會議可以召集會議主題涉及到成員參加。

（四）討論

討論是測試工作中進行溝通和交流的另一種有效的方式和手段。

對于測試工作中發現的??般性問題，由測試組通過組內討論，研究解決方案，組內自行

解決。

對于測試工作中發現的重大問題，測試組以及其他相關開發人員展開討論，共同協商，

尋求解決方案.

五、測試用例的編寫

測試過程中每筆交易或每項操作都要根據專門編制的具體案例進行。

（一）案例編寫的原則

案例編寫應遵照完整性、針對性、關聯性和規范性四項原則。

1、完整性

完整性也可以理解為仝面性，指設計測試案例要同時考慮到系統實際運行情況中可能會

出現的各種情況，并通過測試案例的模擬操作，發現問題，完善產品。

為了保證案例編制的完整性，在編制案例時從以下方面入手：

（1）從案例編制的整體考慮，應覆蓋所測產品業務流程中的每項交易：

（2）針對單項交易編制的案例應從人機交互、業務邏輯、賬務處理等方面考慮。

一般情況下，首先該交易操作的每項輸入項都是一個測試點，根據輸入性的性質取值

類型分別設定該輸入項的正常值、邊界值以及越界值進行測試。對于列表選擇的輸入項，要

充分考慮到不同輸入項的不同列表取值的組合情況。對于不同的組合測試案例中要窮舉。

其次考慮單個交易內部的業務邏輯，例如：各輸入項之間的相互制約、相互控制的關

系

產品自身狀態對交易的限制、相關制度對具體產品的規定等。

（3）要考慮到每項金融性交易的相應的賬務處理。

（4）通過對每項交易輸出項是否完整、正確，能否如實反映賬務處理的檢驗，驗證系統

對該項交易的處理過程。

（5）對于每項交易的每個測試點，不僅僅要考慮正常發生的情況，還要同時兼顧反常情

況下系統的處理及反映。如：對于錯誤信息的輸入，系統是否進行控制、是否給與

相應的錯誤提示等。

（6）確保案例編制的完整性，可參考技術人員提供的錯誤信息代碼，根據錯誤信息提示

的情況，編制案例。

（7）系統每個層次的顯示界面是否合理、全面、美觀，是否符合操作者的使用習慣。

2、針對性

針對性指每個測試案例要明確測試意圖。一方面要考慮各種更雜的實際應用情況系統

地規劃，避免出現對任何功能的遺漏，同時編制一個案例應盡可能多的涉及該系統各項功能,

避免出現大量案例重復編制，無意義地加大工作量，降低了效率。

3、關聯性

關聯性，一方面指整個系統各個交易之間的關聯性；另一方面指單項交易涉及到的各個

要素之間的內在關系。

例：一個用于貸款業務的測試案例設計時要考慮放款、還款、展期、形態轉移等一系列

交易及相互的影響和控制。另外所有查詢類、報表類交易也都基于基本交易的結果和基礎上

進行。

單項交易涉及到的各個要素包括：產品科目、期限、利率及靜態表的維護之間的相互關

聯。

4、規范性

測試案例要嚴格依據產品設計說明書編制。同時為了便于統計和管理，應按照統一的格

式、編碼、內容和規范進行編制。

（-）測試案例的取舍

在測試過程中，如果待測試軟件功能復雜，在受測試時間和測試資源限制的情況下，不

可能將測試資源平均用于所有案例測試，因此我們在測試案例的編寫過程和測試過程中需要

對測試內容按照功能和內容對測試案例進行優先等級的劃分，以把握測試和驗收重點。

測試案例劃分的方法簡單總結如下，供參考：

“功能優先級”的劃分標準為：

3.重要功能:

2.一般功能

1.不常用功能;

“內容優先級”的劃分標準為：

3.正常情況;

2.重要的異常情況;

1，不重要的異常情況。

案例優先級=功能優先級X內容優先級

其取值范圍為：[9、6、4、3、2、1]

舉例：“外匯寶客戶簽約，正常情況”

功能優先級=3

內容級別=3

案例優先級=3*3=9

六、測試相關文檔

(-)測試計劃書

測試工作計劃是測試工作開展的基礎，測試計劃為整個測試工作建立完整的框架結構,

是測試工作的起始步驟和重要環節。制定測試工作計劃書應該包括以下方面：

1、測試項目的基本簡介

通過測試產品基本情況簡介使測試者對所測試的產品有所了解，形成整體認識。

測試產品基本情況的介紹應該圍繞該產品創意展開，主要包括產品項目背景、項目目

標、業務范圍、產品及核算架構、與其他子系統的關系等五方面內容。

2、測試工作進度安排

測試工作時間安排是測試計劃的核心內容之一，按照測試工作內容、進程，排定時間表。

測試工作時間表不僅統籌整體工作進展，并且應將具體的工作內容細化到周或工作日。另外,

時間表中還應考慮到測試工作分階段進行的階段性總結與反饋。

3、測試策略

測試策略對測試工作進行指導，針對具體問題具體分析，對不同情況提供具體的處理和

解決方法。例如：對于測試中出現的重大事故問題，集合技術人員和業務人員共同召開會議

研究；對于測試組內對于某問題產生的不同意見，采用小組討論的形式解決等等。

4、測試記錄

測試記錄指對測試工作詳細、完整的文檔紀錄。包括：階段性的測試工作總結、測試

問題報告單、測試問題工作量統計表、測試案例單等。

5、測試資源配置

一方面包括測試工作所需的硬件設施：測試環境等。另一方面包括測試工作需要的測

試人員的組織。

測試計劃完成之后，應與技術人員進行討論、協商，對完成的測試計劃進行評審，形成

反饋意見，并對測試計劃修改和完善，形成最終予以實施的版本。

（二）測試方案書

測試方案具體指導測試工作的開展、進行；是測試工作實施的依據。全面、合理的測試

方案一定程度上能夠推動測試工作的進展，提高工作效率。

設計出全面、合理測試方案，做到心中有數，是測試準備階段的重要工作之一。完整的

測試方案應包括以下方面：

1、測試目標、原則和要求

測試是保證軟件產品質量最重要的手段。目的在于檢驗軟件是否滿足規定的需求或是弄

清實際結果和預期結果之間的差別。尋找程序錯誤，尋找與用戶需求不一致和存在的缺陷。

以較少的案例、時間和人力找出軟件潛在的各種錯誤和缺陷，以確保系統的質量。具體表現

在以下幾個方面：（1）確保軟件產品達到需求功能的說明；（2）確保軟件產品滿足性能需求；

（3）（壓力測試）確認程序能夠處理用戶要求的負載；（4）確保軟件產品在要求的硬件和軟件

平臺上工作正常。

測試工作按照全面性、有效性和正確性的原則進行。

全面性指測試工作應涵蓋所測系統所有交易，包括金融類和管理類交易，并需檢測系統

在各時段（模式）運行時的功能實現情況。

有效性指以實際業務情形為基礎，從可操作性等方面進行測試，檢測系統是否已滿足營

業網點和管理行各項業務處理和管理的需要。

正確性指檢測系統業務處理流程的正確合理性、賬務組織的完整性、金融性交易賬務處

理的正確性以及會計和業務統計報表真實、準確性.

測試工作的要求包括測試工作的完成情況和工作態度兩方面的要求。

2、測試內容、范圍

根據所測試的金融產品的主要業務和功能，確定測試內容和范圍°例如資產業務系統的

測試工作內容指主要的資產業務，包括個人貸款、對公貸款、質押貸款、系統內拆借、同業

拆借、委托貸款、貼現、轉貼現以及額度管理等業務的測試。

3、測試方式

測試方式指測試工作不同的切入點和不同方面。即測試工作需要從幾下方面分別進行：

常規性測試指模擬實際業務正常發生情況進行的測試。

反常規性測試指針對除實際業務正常發生情況以外的非正常情況進行的測試。通過反常

規性測試，檢驗系統是否進行了相應的控制，能否做出正確的反饋。

驗收測試是從用戶的角度出發，也可以由產品的使用者來對產品進行的檢測。使用者關

注的重點是使用產品的感受，關心軟件的界面是否美觀、菜單的位置是否合適，各個交易的

操作是否方便，是否能夠滿足使隹者的需要等，通過驗收測試認定該軟件產品是否滿足規定

的質量要求。

回歸測試指對測試過程中發現并提交問題的修改結果進行再次測試和驗收。

完整的測試工作應同時從以上方面著手，兼顧全面。

4、測試依據

測試依據指測試工作得以正常開展所參考的相關制度和資料。包括產品設計說明書、測

試計劃、相關管理制度和規定等。

5、測試環境

測試環境指建立測試硬件環境、軟件環境、網絡環境、測試數據、賬務環境等。

6、測試人員與職責說明

測試方案中應根據所測試系統的具體內容和要求，對參加測試的人員進行安排和分工。

包括人員分組、指定責任人并根據測試進程確定每個測試人員具體工作任務等。

7、測試問題處理流程

測試問題處理流程指測試人員、后臺技術人員、前臺技術人員對測試中發現的問題處

理解決的具體的過程。即誰發現問題，交由誰進行分析，由誰具體解決等，建立統一的責任

和規范。

測試方案要對測試處理問題處理流程進行明確。

8、測試案例

根據實際業務發生情況模擬編制的用于檢測每項交易的輸入項、輸出項、賬務處理等

方面正確性、全面性、合理性的實例。

詳見附件。

(三)測試報告

完整的測試報告應包括以下幾方面：

1、測試任務

概要說明本次測試所承擔的具體任務及應達到的目標。

2、測試組織方案

(1)測試時間

描述整個測試工作的起止時間。

(2)測試地點

描述測試工作的具體地點。

(3)測試環境

描述測試工作所應用的硬件及軟件環境。

硬件

設備類型配置數量

主機

終端

打印機

軟件

軟件類型名稱

操作系統

數據庫

開發工具

應用軟件

其他

（4）人員安排

描述參與測試的人員應承擔的工作任務及職責。

姓名所屬部門職責

3、測試情況回顧

（1）測試數據準備

描述為測試工作進行的必要的數據準備。

（2）測試案例準備

概要描述案例種類（正常案例和糾錯案例）及數量等，并將測試案例單作為附件。

（3）測試功能及結果

按照具體交易分別描述交易功能及測試結果。

交易代碼交易名稱功能描述測試結果測試員

（4）測試中出現問題的統計

交易代碼交易名稱問題描述類型測試員

4、總體評價

對整個測試工作的任務完成情況、與其他部門配合情況及需要在以后的測試中注意的其

他問題等進行總結。

（四）其他文檔資料

附件一：《測試案例單》

附件二：《測試問題報告單》

附件三：《測試問題匯總統計表》

附件四：《需求變更申請單》

附件五：《需求變更記錄表》

附件六：《功能與案例對照表》

附件一:

測試案例單

編號:

子系統交易測試測試

交易碼

名稱名稱人員時間

測試說明

測試初始

數據準備

測試案例

預期結果

實際結果

是否通過是口否口

測試案例

預期結果

實際結果

是否通過是口否口

測試案例

預期結果

實際結果

是否通過是口否口

附件二：

測試問題報告單（第一聯）

報告單編號:

子系統名稱：交易碼：交易名稱：

涉及平臺：UNIXDAS400口ES9000D測試日期：測試案例單編號：

問題描述：（此處由負責測試的人員對問題的現象作詳細描述）

問題發現人簽字：測試負責人簽字：問題修改人簽字：備注：

口期：日期：日期

測試問題報告單（第二聯）

報告單編號:

子系統名稱；交易碼：交易名稱：

涉及平臺：UNIXDAS400QES9000口測試日期：測試案例單編號：

問題描述：（此處由負責測試的人員對問題的現象作詳細描述）

問題發現人簽字：測試負責人簽字：問題修改人簽字：備注：

口期：日期：日期

附件三:

測試問題匯總統計表

產品名稱程序版本程序提交日

序號案例編號測試問題描述測試人員是否修改修改方案/不開發結果

修改原因人員

附件四：

需求變更申請單

年月日編號:

業務種類：申請人：組長：

希望完成日期：實際完成日期：

需求描述:

反饋意見:

經辦人：組長：

附件五:

需求變更記錄表

修訂時間修訂人修訂內容版本審批人備注

附件六:

功能與案例對照表

序號功能編號功能名稱案例編號案例名稱

軟件項目測試規范

一、概述

本規范是對項目軟件測試的一份規范性文件，對軟件測試過程中所涉及

到的測試類型、測試方法、測試標準、測試流程以及軟件產品責任單位

所承擔的職責進行總體規范，以有效保證軟件產品的質量。

軟件測試是對軟件設計的一種控制手段，是對軟件產品質量的一種檢查

和審核手段。軟件設計單位應采取有效措施保證軟件產品的質量，軟件

測試應按本規范要求對軟件進行檢查、測試，軟件設訐單位應保證對測

試錯誤進行修正。測試過程中發現的軟件錯誤必須及時改正，這就是軟

件測試的任務。為了改正錯誤，首先必須確定故障的準確位置，這是測

試過程中最困難和任務。需要周密審慎的思考和推理。改正錯誤常常包

括修正原來的設計，必須通盤考慮而不能“頭痛醫頭腳痛醫腳”，應該

盡量避免在測試過程中引進新的故障。

二、測試類型

項目軟件測試類型包括單元測試、集成測試（組裝測試）、有效性測試

（功能測試）、系統測試、回歸測試和用戶測試（驗收測試）。

單元測試

主要針對軟件設計單元、功能模塊進行測試，測試內容包括模塊程序結

構檢查、代碼測試和模塊內功能測試。

集成測試（組裝測試）

主要針對軟件設計單元、功能模塊組裝、集成為系統時，對軟件單元、

功能模塊的接口、連接進行測試。

有效性測試（功能測試）

按照系統功能需求規定對系統的功能、流程、數據、業務規則等進行測

試，以及對系統基本特征如操作、界面、報表等的合理性、一致性進行

測試。

系統測試

為系統性能測試，如安全性、可靠性、穩定性測試，以及對系統其它性

能如負載能力、處理能力以及響應時間等進行測試。

回歸測試

在軟件設計錯誤修正、設計修改以及軟件升級后，主要針對軟件修改、

影響部分進行有效性測試和系統測試。

用戶測試（驗收測試）

為用戶方組織的有效性和系統測試。

三、測試的方法

邏輯覆蓋法

根據測試用例，運行被測試程序，使程序中的每個可執行語句、執行條

件至少執行一次。

語句覆蓋

語句覆蓋就是設計若干個測試用例，運行被測程序，使得每一條可執行語句至少執行一次。

判定覆蓋

判定覆蓋就是設計若干個測試用例，運行被測程序，使得程序中每個判斷的取真分支和取假

分支至少經歷一?次,判定覆蓋又稱為分支覆蓋。

條件覆蓋

條件覆蓋就是設計若干個測試用例，運行被測程序，使得程序中每個判斷的每個條件的可能

取值至少執行?次。

判定一條件覆蓋

判定一條件覆蓋就是設計足夠的測試用例，使得判斷中每個條件的所有可能取值至少執行一

次，同時每個判斷中的每個條件的可能取值至少執行一次。

條件組合僵蓋

條件組合構襦就是設計足夠的測試用例，運行被測程序，使得每個判斷的所有可能的條件取

值組合至少執行一次。

路徑測試

路徑測試就是設計足夠的測試用例，覆蓋程序中所有可能的路徑■

條件測試路徑選擇

當程序中判定多于一個時，形成的分支結構可以分為兩類：嵌套型分支結構和連鎖型分支結

構，

對于嵌套型分支結構,若有n個判定語句，需要n+l個測試用例：

對于連鎖型分支結構,若有n個判定語句，需要有2n個測試用例，覆蓋它的2n條路徑.當

n較大時將無法測試。

循環測試路徑選擇

循環分為4種不同類型：簡單循環、連鎖循環、嵌套循環和M結構循環,

(1)簡單循環

①零次循環：從循環入口到出口

②一次循環：檢查循環初始值

③二次循環：檢查多次循環

④m次循環：檢查在多次循環

⑤最大次數循環、比最大次數多一次、少一次的循環。

(2)嵌套循環

①對最內層循環做簡單循環的全部測試.所有其它層的循環變量置為最小值：

②逐步外推，對其外而循環進行測試。測試時保持所有外層循環的能環變量取圾小但，所仃

其它嵌套內層循環的循環變量取“典型”值.

③反更進行，直到所有各層循環測試完畢。

④對全部各層循環同時取最小循環次數，或者同時取最大循環次數。

(3)連鎖循環

如果各個循環互相獨立，則可以用與簡單循環相同的方法進行測試。但如果幾個循環不是互

相獨立的，則需要使用測試嵌套循環的辦法來處理。

(4)加結構循環

這?類循環應該使用結構化程序設計方法重新設計測試用例。

所謂等價類，就是指某個輸入域的集合，集合中的每個輸入對揭露程序

錯誤來說是等效的，把程序的輸入域劃分成若干部分，然后從每個部分

中選取少數代表性數據作為測試用例，這就是等價類劃分方法。它是功

能測試的基本方法。使用這一方法設計測試用例要經歷劃分等價類(列

出等價類表)及選取測試用例兩步。

劃分等價類：有效等價類、無效等價類

確定測試用例：為每個等價類規定一個唯一的編號；設計一個測試用例,

使其盡可能多地覆蓋尚未覆蓋的有效等價類；設計一個新的測試用例，

使其只覆蓋一個無效等價類。

等價類劃分是一種典型的黑盒測試方法,使用這一方法時，完全不考慮程序的內亂結

構，只依據程序的規格說明來設計測試用例.

等價類劃分方法把所有可能的輸入數據，即程序的輸入域劃分成若卜部分，然后從每

一部分中選取少數有代表性的數據做為測試用例。

使用這一方法設ir測試用例要經歷劃分等價類(列出等價類表)和選取測試用例兩步。

劃分等價類

等價類是指某個輸入域的子集合。在該子集合中，各個輸入數據對于揭露程序中的錯

誤都是等效的。測試某等價類的代表值就等價于對這一類其它值的測試。

等價類的劃分有兩種不同的情況：

①有效等價類：是指對于程序的規格說明來說，是合理的，有意義的輸入數據構成的

集合。

②無效等價類：是指對于程序的規格說明來說，是不合理的，尤意義的輸入數據構

成的集合。

在設計測試用例時，要同時考慮有效等價類和無效等價類的設計。

劃分等價類等價類的原則。

(1)如果輸入條件規定了取值范圍，或值的個數，則可以確立一個有效等價類和兩個

無效等價類。

例如，在程序的規格說明中，對輸入條件有一句話：

“項數可以從I到999”

則有效等價類是“1W項數《999”

兩個無效等價類是“項數VI”或“項數＞999”。

(2)如果輸入條件規定了輸入值的集合，或者是規定了“必須如何"的條件，這時可確

立一個有效等價類和一個無效等價類。

例如,在Pascal語言中對變量標識符規定為“以字母打頭的……串”。那么所有以字母

打頭的構成有效等價類，而不在此集合內(不以字母打頭)的歸于無效等價類。

(3)如果輸入條件是一個布爾量，則可以確定?個有效等價類和一個無效等價類,

(4)如果規定了愉入數據的一組值，而且程序要對每個輸入值分即進行處理，這時可

為律?個輸入值確立一個有效等價類，此外針對這組值確立?個無效等價類，它是

所有不允許的輸入值的集合。

例如.在教師上崗方案口規定對教授、副教授、講師和助教分別計算分數，做相應的

處理“因此可以確定4個有效等價類為教授、副教授、講師和助教，個無效等價類,它是

所仃不符合以上身分的人員的輸入值的集合.

(5)如果規定了輸入數據必須遵守的規則，則可以確立一個有效箸價類(符合規則)和

若干個無效等價類(從不同角度違反規則)。

例如，Pascal語言規定“一個語句必須以分號結束”這時，可以確定一個有效等價

類"以結束'若干個無效零價類“以“結束”、"以結束，"以“結束”、“以LF結束”

等.

確立測試用例

在確立了等價類之后,建立等價類表，列出所有劃分出的等價類,再從劃分出的等價

類中按以下原則選擇測試用例：

(1)為每一個等價類規定一個唯一編號：

(2)設計一個新的測試用制，使其盡可能多地覆蓋尚未被覆蓋的有效等價類，重復這一

步，直到所有的有效等價類都被覆蓋為止；

(3)設計?個新的測試用例，使其僅覆蓋一個尚未被覆蓋的無效等價類，重復這?步，

直到所有的無效等價類都被陵蓋為止

邊界值分析法

使用邊界值分析方法設計測試方案首先應該確定邊界情況，這需要經驗

和創造性，通常輸入等價類和輸出等價類的邊界，就是應該注重測試的

程序邊界情況。選取的測試數據應該剛好等于、剛剛小于和剛剛大于邊

界值。也就是說，按照邊界值分析法，應該選取剛好等于、稍小于和稍

大于等價類邊界值作為測試數據，而不是選取每個等價類內的典型值或

任意值作為測試數據。

邊界值分析也是一種黑盒測試方法，是對等價類劃分方法的補充，人們從長期的測試

工作”聆得知，大最的錯誤是發生在躲入或輸出范用的動界匕而不累在輸入范用的內部。

因此針對各種邊界情況設汁測試用例，可以查出更多的錯誤。

比如,在做三角形計算時，要輸入三角形的三個邊長：A、B和C。我們應注意到這

二個數值應當滿足A>0、B>0、C>0.A+B>C.A+C>B、B+C>A,才能構成三角形。

但如果把六個不等式中的任何一個大于號錯寫成大于等于號“2”，那就不能構成三角

形。問題恰出現在容易被疏忽的邊界附近，

這里所說的邊界是指，相當于悔入等價類和輸出等價類而言，稍高于其邊界值及稍低于

共邊界值的?些特定情況.

使用邊界值分析方法設計測試用例，首先應確定邊界情況。應當選取正好等于.剛剛

大十，或剛剛小于邊界的位做為測試數據,血不是選取等價類中的典型值或任意值做為測試

數據。

實踐證明，軟件在輸入、輸出域的邊界附近容易出現差錯，邊值分析是考慮邊界條件

而選取測試用例的一種功能測試方法。邊值分析是對等價類劃分的有效補充，

因-果圖法

分析程序規格說明的描述中哪些是原因，哪些是結果。原因是輸入條件

或是輸入條件的等價類。結果是輸出條件。因果圖是一種形式語言，由

自然語言寫成的規范轉換而成，這種形式語言實際上是一種使用簡化記

號表示數字邏輯圖。因果圖法是幫助人們系統地選擇一組高效測試用例

的方法，此外，它還能指出程序規范中的不完全性和二義性。

因果圖的適用范匣

如果在測試時必須考慮輸入條件的各種組合，可使用?種適合于描述對于多種條件的組合，

相應產生