《軟件測試規范》(草案)

ComputerSoftwareTestingCriterion

目的與合用范

1、目的

軟件測試是軟件工程的重要組成部分，測試工作的質量直接影響軟件產品的生命力。測試工

作的標準化是軟件質量保證(QualityAssurance)重要并且必須的環節。制定本標準的目的在于

使測試流程更標準，測試過程更規范。從而使整個軟件生產納入更系統化、更專業化的軌道。

2、合用范圍

木標準合用于軟件測試流程的管理和測試的具體操作過程.木標準的使用者可以是公司內部

的測試人員和開發人員。

二、測試方法

軟件測試的方法和技術是多種多樣的。以下將介紹比較常用的一些測試方法：

1、靜態測試

靜態方法是指不運營被測程序自身，僅通過度析或檢查源程序的文法、結構、過程、接II等

來檢查程序的對的性。靜態方法通過程序靜態特性的分析，找出欠缺和可疑之處，例如不匹

配的參數、不適當的循環嵌套和分支嵌套、不允許的遞歸、未使用過的變量、空指針的引用

和可疑的計算等。靜態測試結果可用于進一步的查錯，并為測試用例選取提供指導。

2、動態測試

動態方法是指通過運營被測程序，檢查運營結果與預期結果的差異，并分析運營效率和健

壯性等性能，這種方法由三部分組成：構造測試實例、執行程序、分析程序的輸出結果。

3、黑盒測試

黑盒測試也稱功能測試或數據驅動測試，它是在已知產品所應具有的功能，通過測試來

檢測每個功能是否都能正常使用，在測試時，把程序看作一個不能打開的黑盆子，在完全不

考慮程序內部結構和內部特性的情況下，測試者在程序接口進行測試，它只檢查程序功能是

否按照需求規格說明書的規定正常使用，程序是否能適本地接受輸入數鋸而產生對的的輸出

信息，并且保持外部信息(如數據庫或文獻)的完整性.黑盒測試方法重要有等價類劃分、

邊值分析、因一果圖、錯誤推測等，重要用于軟件確認測試。

“黑盒”法著眼于程序外部結構、不考慮內部邏輯結構、針對軟件界面和軟件功能進行測

試?！昂诤小狈ㄊ歉F舉輸入測試，只有把所有也許的輸入都作為測試情況使用，才干以這種方

法查出程序中所有的錯誤，事實上測試情況有無窮多個，人們不僅要測試所有合法的輸入，

并且還要對那些不合法但是也許的輸入進行測試。

4、白盒測試

白盒測試也稱結構測試或邏輯驅動測試，它是知道產品內部工作過程，可通過測試來檢

測產品內部動作是否按照規格說明書的規定正常進行，按照程序內部的結構測試程序，檢查

程序中的每條通路是否都有能按預定規定對的工作，而不顧它的功能，白盒測試的重要方法

有邏輯驅動、基路測試等，重要用于軟件驗證。

“白盒”法全面了解程序內部邏輯結構、對所有邏輯途徑進行測試。“白盒”法是窮舉途徑

測試。在使用這一方案時，測試者必須檢查程序的內部結構，從檢查程序的邏輯著手，得出

測試數據。貫穿程序的獨立途徑數是天文數字。但即使每條途徑都測試了仍然也許有錯誤。

第一，窮舉途徑測試決不能查出程序違反了設計規范，即程序自身是個錯誤的程序。第二，

窮舉途徑測試不也許查出程序中因漏掉途徑而犯錯。第三，窮舉途徑測試也許發現不了一些

與數據相關的錯誤。

5、ALAC(Act-like.a?customer)測試

ALAC測試是一種基于客戶使用產品的知識開發出來的測試方法。ALAC測試是基于

復雜的軟件產品有許多錯誤的原則。最大的受益者是用戶，缺陷查找和改正將針對哪些客戶

最容易碰到的錯誤。

6、單元測試方法

6.1單元測試任務

單元測試任務涉及：

U模塊接口測試；

U模塊局部數據結構測試；

U模塊邊界條件測試；

u模塊中所有獨立執行通路測試；

U模塊的各條錯誤解決通路測試。

模塊接口測試是單元測試的基礎。只有在數據能對的流入、流出模塊的前提下，其

他測試才故意義。

6.2接口測試

測試接口對的與否應當考慮下列因素：

U輸入的實際參數與形式參數的個數是否相同；

U輸入的實際參數與形式參數的屬性是否匹配；

U輸入的實際參數與形式參數的量綱是否一致；

U調用其他模塊時所給實際參數的個數是否與被調模塊的形參個數相同；

U調用其他模塊時所給實際參數的屬性是否與被調模塊的形參屬性匹配；

U調用其他模塊時所給實際參數的量綱是否與被調模塊的形參量綱一致；

U調用預定義函數時所用參數的個數、屬性和順序是否對的；

U是否存在與當前入口點無關的參數引用；

U是否修改了只讀型參數；

U對全程變量的定義各模塊是否一致；

U是否把某些約束作為參數傳遞。

假如模塊內涉及外部輸入輸出，還應當考慮下列因素：

U文獻屬性是否對的；

OPEN/CLOSE語句是否對的;

U表達式符號錯。

比較判斷與控制流經常緊密相關，測試用例還應致力于發現下列錯誤：

U不同數據類型的對象之間進行比較；

U錯誤地使用邏輯運算符或優先級；

U因計算機表達的局限性，盼望理論I?.相等而事實上不相等的兩個量相等；

U比較運算或變量犯錯；

U循環終止條件或不也許出現；

U迭代發散時不能退出；

U錯誤地修改了循環變量。

6.5犯錯解決測試

一個好的設計應能預見各種犯錯條件，并預設各種犯錯解決通路，犯錯解決通路同樣需要認

真測試，測試應著重檢查下列問題：

U輸出的犯錯信息難以理解；

U記錄的錯誤與實際碰到的錯誤不相符；

u在程序自定義的犯錯解決段運營之前，系統已介入；

U異常解決不妥；

U錯誤陳述中未能提供足夠的定位犯錯信息。

6.6邊界條件測試

邊界條件測試是單元測試中最后，也是最重要的一項任務。眾的周知，軟件經常在邊界上失

效，采用邊界值分析技術，針對邊界值及其左、右設計測試用例，很有也許發現新的錯誤。

7、集成測試的基本方法

某設計人員習慣于把所有模塊按設計規定一次所有組裝起來，然后進行整體測試,

這稱為非增量式集成。這種方法容易出現混亂。由于測試時也許發現?大堆錯誤，為每個錯

誤定位和糾正非常困難，并且在改正一個錯誤的同時又也許引入新的錯誤，新舊錯誤混雜,

更難斷定犯錯的因素和位置。與之相反的是增量式集成方法，程序一段一段地擴展，測試的

范圍?步一步地增大，錯誤易于定位和糾正，界面的測試亦可做到完全徹底。下面討論兩種

增量式集成方法。

7.1自頂向下集成

自頂向下集成是構造程序結構的一種增量式方式，它從主控模塊開始，按照軟件的

控制層次結構，以深度優先或廣度優先的策略，逐步把各個模塊集成在一起。深度優先策略

一方面是把主控制途徑上的模塊集成在一起，至于選擇哪一條途徑作為主控制途徑，這多少

帶有隨意性，一般根據問題的特性擬定。

自頂向下集成測試的具體環節為：

U以主控模塊作為測試驅動模塊，把對主控模塊進行單元測試時引入的所有樁模塊用實

際模塊替代；

U依據所選的集成策略（深度優先或廣度優先），每次只替代一個樁模塊；

U每集成一個模塊立即測試一遍；

u只有每組測試完畢后，才著手替換下一個樁模塊；

U為避免引入新錯誤，須不斷地進行回歸測試（即所有或部分地反復已做過的測試）；

U從第二步開始，循環執行上述環節，直至整個程序結構構造完畢。

自頂向下集成的優點在于能盡早地對程序的重要控制和決策機制進行檢查，因此較

早地發現錯誤。缺陷是在測試較高層模塊時，低層解決采用樁模塊替代，不能反映真實情況,

重要數據不能及時回送到上層模塊，因此測試并不充足。解決這個問題有幾種辦法，第一種

是把某些測試推遲到用真實模塊替代樁模塊之后進行，第二種是開發能模擬真實模塊的樁模

塊；第三種是自底向上集成模塊。第一種方法又回退為豐增量式的集成方法，使錯誤難于定

位和糾正，并且失去了在組裝模塊時進行一些特定測試的也許性；第二種方法無疑要大大增

長開銷；第三種方法比較切實可行。

7.2自底向上集成

自底向上測試是從“原子”模塊（即軟件結構最低層的模塊）開始組裝測試，因測試

到較高層模塊時，所需的下層模塊功能均已具有，所以不再需要樁模塊。

自底向上綜合測試的環節分為：

u把低層模塊組織成實現某個子功能的模塊群（cluster）;

u開發?個測試驅動模塊，控制測試數據的輸入和測試結果的輸出；

u對每個模塊群進行測試；

U刪除測試使用的驅力模塊，用較高層模塊把模塊群組織成為完畢更大功能的新模塊群;

U從第一步開始循環執行上述各環節，直至整個程序構造完畢。

自底向上集成方法不用樁模塊，測試用例的設t-亦相對簡樸，但缺陷是程序最后一

個模塊加入時才具有整體形象。它與自頂向綜合測試方法優缺陷正好相反。因此，在測試軟

件系統時，應根據軟件的特點和工程的進度，選用適當的測試策略，有時混和使用兩種策略

更為有效，上層模塊用自頂向下的方法，下層模塊用自底向上的方法。

此外，在集成測試中特別要注意關鍵模塊，所謂關鍵模塊一般都具有下述一或多個

特性：①相應幾條需求；②具有高層控制功能；③復雜、易犯錯；④有特殊的性能規定。關

犍模塊應盡早測試，并反要進行回歸測試。

8、確認測試的基本方法

8.1確認測試標準

實現軟件確認要通過一系列黑盒測試。確認測試同樣需要制訂測試計劃和過程，

測試計劃應規定測試的種類和測試進度，測試過程則定義一些特殊的測試用例，旨在說明軟

件與需求是否一致。無論是計劃還是過程，都應當著重考慮軟件是否滿足協議規定的所有功

能和性能，文檔資料是否完整、準確，人機界面和其他方面（例如，可移植性、兼容性、錯

誤恢復能力和可維護性等）是否令用戶滿意。

確認測試的結果有兩種也許，一種是功能和性能指標滿足軟件需求說明的規定，

用戶可以接受；另一種是軟件不滿足軟件需求說明的規定，用戶無法接受。項目進行到這個

階段才發現嚴重錯誤和偏差?般很難在預定的工期內改正，因此必須與用戶協商，尋求?個

妥善解決問題的方法。

8.2配置復審

確認測試的另一個重要環節是配置復審。復審的目的在于保證軟件配置齊全、

分類有序，并且涉及軟件維護所必須的細節。

8.3a、0測試

事實上，軟件開發人員不也許完全預見用戶實際使用程序的情況。例如，用戶也許

錯誤的理解命令，或提供一些奇怪的數據組合，亦也許對設計者自認明了的輸出信息迷惑不

解，等等。因此，軟件是否真正滿足最終用戶的規定，應由用戶進行一系列“驗收測試”。驗

收測試既可以是非正式的則試，也可以有計劃、有系統的測試。有時，驗收測試長達數周甚

至數月，不斷暴露錯誤，導致開發延期。一個軟件產品，也許擁有眾多用戶，不也許由每個

用戶驗收，此時多采用稱為a、p測試的過程，以期發現那些似乎只有最終用戶才干發現的

問題。

a測試是指軟件開發公司組織內部人員模擬各類用戶行對即將面市軟件產品(稱為

a版本)進行測試，試圖發現錯誤并修正。a測試的關鍵在于盡也許逼真地模擬實際運營環

境和用戶對軟件產品的操作并盡最大努力涵蓋所有也許的用戶操作方式。通過a測試調整

的軟件產品稱為0版本。緊隨其后的。測試是指軟件開發公司組織各方面的典型用戶在平常

工作中實際使用P版本，并規定用戶報告異常情況、提出批評意見。然后軟件開發公司再對

。版本進行改錯和完善。

9、系統測試的基本方法

9.1恢復測試

恢復測試重要檢杳系統的容錯能力。當系統犯錯時，能否在指定期間間隔內修正錯

誤并重新啟動系統?；謴蜏y試一方面要采用各種辦法逼迫系統失敗，然后驗證系統是否能盡

快恢復.對于自動恢復需驗證重新初始化(reinitialization),檢查點

(checkpointingmechanisms)數據恢復(datarecovery)和重新啟動(restart)等機制的對的性;

對于人工干預的恢復系統，還需估測平均修復時間，擬定其是否在可接受的范圍內。

9.2安全測試

安全測試檢查系統對非法侵入的防范能力。安全測試期間，測試人員假扮非法入

侵者，采用各種辦法試圖突破防線。例如，①想方設法截取或破譯II令；②專門定做軟件破

壞系統的保護機制；③故意導致系統失敗，企圖趁恢復之機非法進入；④試圖通過瀏覽非保

密數據，推導所需信息，等等。理論上講，只要有足夠的時間和資源，沒有不可進入的系統。

因此系統安全設計的準則是，使非法侵入的代價超過被保護信息的價值。此時非法侵入者已

無利可圖。

9.3強度測試

強度測試檢查程序對異常情況的抵抗能力。強度測試總是迫使系統在異常的資源

配置F運營。例如，①當中斷的正常頻率為每秒一至兩個時，運營每秒產生十個中斷的測試

用例；②定量地增長數據輸入率，檢查輸入子功能的反映能力；③運營需要最大存儲空間(或

其他資源)的測試用例;④運營也許導致虛存操作系統崩潰或磁盤數據劇烈抖動的測試用例，

等等。

9.4性能測試

對于那些實時和嵌入式系統，軟件部分即使滿足功能規定，也未必可以滿足性能

規定，雖然從單元測試起，每一測試環節都包含性能測試，但只有當系統真正集成之后，在

真實環境中才干全面、可靠地測試運營性能系統性能測試是為了完畢這?任務。性能測試有

時與強度測試相結合，經常需要其他軟硬件的配套支持.

10、回歸測試方法

回歸測試的價值在于它是一個可以檢測到回歸錯誤的受控實驗。當測試組選擇縮減的回歸測

試時，有也許刪除了將揭示回歸錯誤的測試用例，消除了發現回歸錯誤的機會。然而，假如

采用了代碼相依性分析等安全的縮減技術，就可以決定哪些測試用例可以被刪除而不會讓回

歸測試的意圖遭到破壞。

選擇回歸測試策略應當兼顧效率和有效性兩個方面。常用的選擇回歸測試的方式涉及：

10」再測試所有用例：

選擇基線測試用例庫中的所有測試用例組成回歸測試包，這是一種比較安全的方法，再測試

所有用例具有最低的漏掉回歸錯誤的風險，但測試成本最高。所有再測試幾乎可以應用到任

何情況下，基本上不需要進行分析和重新開發，但是，隨著開發工作的進展，測試用例不斷

增多，反復原先所有的測試將帶來很大的工作量，往往超過了我們的預算和進度。

10.2基于風險選擇測試：

可以基于一定的風險標準來從基線測試用例庫中選擇I可歸測試包。一方面運營最重要的、關

健的和可疑的測試，而跳過那些非關鍵的、優先級別低的或者高穩定的測試用例，這些用例

即便也許測試到缺陷，這些缺陷的嚴重性也僅有三級或四級。一般而言，測試從重要特性到

次要特性

10.3基于操作剖面選擇測試：

假如基線測試用例庫的測試用例是基于軟件操作剖面開發的，測試用例的分布情況反映了系

統的實際使用情況C回歸測試所使用的測試用例個數可以由測試預算擬定.回歸測試可以優

先選擇那些針對最重要或最頻繁使用功能的測試用例，釋放和緩解最高級別的風險，有助于

盡早發現那些對可靠性有最大影響的故障。這種方法可以在?個給定的預算下最有效的提高

系統可靠性，但實行起來有一定的難度。

10.4再測試修改的部分：

當測試者對修改的局部化有足夠的信心時，可以通過相依性分析辨認軟件的修改情況并分析

修改的影響，將回歸測試局限于被改變的模塊和它的接口上。通常，一個回歸錯誤一定涉及

一個新的、修改的或刪除的代碼段。在允許的條件下，回歸測試盡也許覆蓋受到影響的部分。

再測試所有用例的策略是最安全的策略，但已經運營過許多次的回歸測試不太也許揭示新的

錯誤，并且很多時候，由于時間、人員、設備和經費的因素，不允許選擇再測試所有用例的

回歸測試第略，此時，可以選擇適當的第略進行縮減的回歸測試.

三、測試階段的劃分

根據開發過程和實際需求將測試階段劃分為：設計階段、代碼檢測單元測試階段、集

成測試階段、系統測試階段、驗收測試階段、回歸測試（復測）階段。各階段中使用的測試

方法詳見本規范的測試方法。

1、設計階段

核心工作是對軟件產品功能說明書進行檢杳，軟件產品功能說明書是對軟件產品最終

需要實現的功能的描述。編寫軟件測試計劃。

2、單元測試階段

單元測試完畢對軟件最小的結構的測試，一般用來驗證模塊的功能屬性，它運用設計文檔作

為指導，重要使用白盒測試技術；但也可以測試其它項目，如性能、可用性等等，可使用“黑

盒''或“白盒”方法進行。在單元測試中，檢查出模塊內部的錯誤是單元測試的重要工作。該

階段的測試丁作.由編程組內部人員進行交叉測試（避免編程人員測試自己的程序）C

單元測試過程：一般認為單元測試應緊接在編碼之后，當源程序編制完畢并通過復

審和編譯檢查，便可開始單元測試。測試用例的設計應與復審工作相結合，根據設計信息選

取測試數據，將增大發現二述各類錯誤的也許性。在擬定測試用例的同時，應給出盼望結果。

提高模塊的內聚度可簡化單元測試，假如每個模塊只能完畢?個，所需測試用例數目將

顯著減少，模塊中的錯誤也更容易發現。

3、集成測試階段

時常有這樣的情況發生，每個模塊都能單獨工作，但這些模塊集成在一起之后卻不能

正常工作。重要因素是，模塊互相調用時接口會引入許多新問題。例如，數據通過接口也許

去失：一個模塊對另一模塊也許導致不應有的影響：幾個子功能組合起來不能實現主功能:

誤差不斷積累達成不可接受的限度：全局數據結構出現錯誤，等等。集成測試是組裝軟件的

系統測試技術，按設計規定把通過單元測試的各個模塊組裝在一起之后，進行集成測試以便

發現與接口有關的各種錯誤。

4、確認測試階段

確認測試的目的是向未來的用戶表白系統可以像預定規定那樣工作。經集成測試后，

已經按照設計把所有的模塊組裝成一個完整的軟件系統，接11錯誤也己經基本排除了，接著

就應當進一步驗證軟件的有效性，這就是確認測試的任務，即軟件的功能和性能如同用戶所

合理期待的那樣。

5、系統測試階段

計算機軟件是基于計算機系統的一個重要組成部分，軟件開發完畢后應與系統中其它成分集

成在一起，此時需要進行一系列系統測試。涉及恢復測試、安全測試、強度測試和性能測試

等。在系統測試之前，軟件工程師應完畢下列工作：

（I）為測試軟件系統的輸入信息設計犯錯解決通路；

（2）設計測試用例，模擬錯誤數據和軟件界面也許發生的錯誤，記錄測試結果，

為系統測試提供經驗和幫助；

（3）參與系統測試的規劃和設計，保證軟件測試的合理性。

系統測試應當由若干個不同測試組成，目的是充足運營系統，驗證系統各部件是否

都能工作并完畢所賦予的任務。

6、回歸測試（復測）階段

回歸測試就是漏洞修復完畢后再對軟件進行測試，以保證軟件沒有產生"回歸”或因修復而變

得更糟，這種測試一般要重新運營最初發現問題的原始測試程序。有關回歸測試有兩個焦點：

有沒有產生新的漏洞，修豆是否的確使缺陷消除。

回歸測試的過程：

有了測試用例庫的維護方法和回歸測試包的選擇策略，回歸測試可遵循下述過程進行：

U辨認出軟件中被修改的部分

U從原基線測試用例庫中排除所有不再合用的測試用例，擬定那些對新的軟件版本仍然

有效的測試用例

U假如必要，生成新的測試用例集，用于測試本來測試用例集無法充足測試的部分

U依據一定的策略選攔測試用例測試被修改的軟件。

U進行測試，并記錄測試結果到測試報告

U分析測試報告

U修正和測試工作

U完畢測試產品提交配置

四、測試類型的劃分

I、功能測試：對軟件功能進行的測試，重要檢查軟件功能是否實現了軟件功能說明書（軟

件需求）上的功能規定。

2、界面測試：對軟件的用戶界面進行的測試，重要檢查用戶界面的美觀度、統一性、易用

性等方面的內容。

3、數據解決測試：對軟件數據接口進行的測試，重要檢查軟件數據解決中輸入、解決、輸

出數據過程。

4、流程測試：按操作流程進行的測試，重要有業務流程、數據流程、邏輯流程、正反流程,

檢查軟件在按流程操作時是否可以對的解決。

5、極限測試：在軟件的極限條件下進行的測試，重要有對數據的極限值、邊界值操作，對

軟件進行致命操作等。

6、并發測試：在網絡環境、并發環境、多用戶條件下對軟件進行的測試。

7、安全測試：對軟件安全性方面的測試，重要檢測軟件中加密、解密、數據備份、恢復、

病毒檢測等問題。

8、性能測試：對軟件整體性能的測試，測試內容有適應性、健壯性、可恢復性、劫難恢復

能力等

9、安裝測試：在不同PC條件、操作系統、模擬客戶機等條件下進行軟件的安裝測試，重

要檢查軟件打包或發布之后存在的問題。

五、測試模式

V型模型，實現測試與軟件開發的同步進行。

需求分析蛉收測試

六、測試一開發工作流程

每

91能改EUG竊舲開笈在務

新

版

志

版本更新定期編譯

七、測試工作流程

測試操作流程圖

說明：

設計測試用例、執行測試用例詳見《測試用例》。

描述軟件錯誤即填寫bug登記表，詳見《BUG標準》

八、附錄

附錄一、測試文檔

I測試計劃

1?引言

1.1編寫目的

【闡明編寫測試計劃的目的，指明讀者對象?！?/p>

1.2項目背景

【說明項目的來源、委托單位及主管部門?！?/p>

1.3定義

【列出測試計劃中所用到的專門術語的定義和縮寫詞的原意?！?/p>

1.4參考資料

【列出有關資料的作者、標題、編號、發表日期、出版單位或資料來源，可涉及:

a.項目的計劃任務書、協議或批文；

b.項目開發計劃；

c.需求規格說明書；

d.概要設計說明書；

e.具體設計說明書；

f.用戶操作手冊：

g.本測試計劃中引用的其他資料、采用的軟件開發標準或規范

2.任務概述

2.1目的

2.2運營環境

2.3需求概述

2.4條件與限制

3.計劃

3.1測試方案

【說明擬定測試方法和選取測試用例的原則?！?/p>

3.2測試項目

【列出組裝測試和確認測試中每一項測試的內容、名稱、目的和進度。】

3.3測試準備

3.4測試機構及人員

【測試機構名稱、負責人和職責

4.測試項目說明

【按順序逐個對測試項目做出說明：】

4.1測試項目名稱及測試內容

4.2測試用例

4.2.1輸入

【輸入的數據和輸入命令門

4.2.2輸出

【預期的輸出數據。】

4.2.3環節及操作

4.2.4允許偏差

【給出實測結果與預期結果之間允許偏差的范圍?！?/p>

4.3進度

4.4條件

【給出測試對資源的特殊規定，如設備、軟件、人員等，】

4.5測試資料

【說明測試所需的