模板
教程
環境
性能
功能
管理
軟件測試組織與管理及測試系列方法(三)
(2)域測試。這是一種基于程序結構的測試方法。這里的“域”是指程序的輸入空間。域測試正是在分析輸入空間的基礎上，選擇適當的測試點以后進行測試的。
(3)符號測試。符號測試是基于代數運算的一種結構測試方法。符號測試方法受分支問題、二義性問題和大程序問題的困擾，這些問題嚴重地影響著它的發展前景。
(4)數據流測試。數據流測試是指一個基于通過程序的控制流，從建立的數據目標狀態的序列中發現異常的結構測試方法。
(5)定義域測試。定義域測試的重點在分類方面，它還要判斷出定義域的正確性。定義域測試與集合理論密切相關。
(6)程序變異測試。這是一種基于程序錯誤的測試方法，它的目的是要說明程序中不含有某些特定的錯誤。
3.測試步驟
軟件測試過程一般按四個步驟進行，即單元測試、集成測試、確認測試和系統測試。
(1)單元測試
也稱模塊測試，這是針對軟件設計的最小單位-模塊進行正確性檢驗的測試工作，其目的在于發現各模塊內部可能存在的各種差錯。單元測試的依據是詳細設計描述，單元測試應對模塊內所有重要的控制路徑設計測試用例，以便發現模塊內部的錯誤。單元測試多采用結構測試(白盒測試)技術，系統內多個模塊可以并行地進行測試。
a.單元測試的任務
單元測試任務包括：(1)模塊接口測試;(2)模塊局部數據結構測試;(3)模塊邊界條件測試;(4)模塊中所有獨立執行通路測試;(5)模塊的各條錯誤處理通路測試。
模塊接口測試是單元測試的基礎。只有在數據能正確流入、流出模塊的前提下，其他測試才有意義。測試接口正確與否應該考慮下列因素：(1)輸入的實際參數與形式參數的個數是否相同;(2)輸入的實際參數與形式參數的屬性是否匹配;(3)輸入的實際參數與形式參數的量綱是否一致;(4)調用其他模塊時所給實際參數的個數是否與被調模塊的形參個數相同;(5)調用其他模塊時所給實際參數的屬性是否與被調模塊的形參屬性匹配;(6)調用其他模塊時所給實際參數的量綱是否與被調模塊的形參量綱一致;(7)調用預定義函數時所用參數的個數、屬性和次序是否正確;(8)是否存在與當前入口點無關的參數引用;(9)是否修改了只讀型參數;(10)各模塊對全程變量的定義是否一致;(11)是否把某些約束作為參數傳遞。
如果模塊內包括外部輸入輸出，還應該考慮下列因素：(1)文件屬性是否正確;(2)OPEN/CLOSE語句是否正確;(3)格式說明與輸入輸出語句是否匹配;(4)緩沖區大小與記錄長度是否匹配;(5)文件使用前是否已經打開;(6)是否處理了文件尾;(7)是否處理了輸入/輸出錯誤;(8)輸出信息中是否有文字性錯誤。
檢查局部數據結構是為了保證臨時存儲在模塊內的數據在程序執行過程中完整、正確。局部數據結構往往是錯誤的根源，應仔細設計測試用例，力求發現以下幾類錯誤：(1)不合適或不相容的類型說明;(2)變量無初值;(3)變量初始化或省缺值有錯;(4)不正確的變量名(拼錯或不正確地截斷);(5)出現上溢、下溢和地址異常。
除局部數據結構外，如果可能，單元測試時還應該查清全局數據對模塊的影響。
在模塊中應對每一條獨立執行路徑進行測試，單元測試的基本任務是保證模塊中每條語句至少執行一次。此時設計測試用例是為了發現因錯誤計算、不正確的比較和不適當的控制流造成的錯誤。此時基本路徑測試和循環測試是最常用且最有效的測試技術。計算中常見的錯誤包括：(1)誤解或用錯了算符優先級;(2)混合類型運算;(3)變量初值錯;(4)精度不夠;(5)表達式符號錯。
比較判斷與控制流緊密相關，測試用例還應致力于發現下列錯誤：(1)不同數據類型的對象之間進行比較;(2)錯誤地使用邏輯運算符或優先級;(3)因計算機表示的局限性，期望理論上相等而實際上不相等的兩個量相等;(4)比較運算或變量出錯;(5)循環終止條件不可能出現;(6)迭代發散時不能退出;(7)錯誤地修改了循環變量。
一個好的設計應能預見各種出錯條件，并預設各種出錯處理通路，出錯處理通路同樣需要認真測試，測試應著重檢查下列問題：(1)輸出的出錯信息難以理解;(2)記錄的錯誤與實際遇到的錯誤不相符;(3)在程序自定義的出錯處理段運行之前，系統已介入;(4)異常處理不當;(5)錯誤陳述中未能提供足夠的定位出錯信息。
邊界條件測試是單元測試中最后也是最重要的一項任務。眾所周知，軟件經常在邊界上失效。采用邊界值分析技術，針對邊界值及其左、右設計測試用例，很有可能發現新的錯誤。
b.單元測試過程
一般認為單元測試應緊接在編碼之后，當源程序編制完成并通過復審和編譯檢查，便可開始單元測試。測試用例的設計應與復審工作相結合，根據設計信息選取測試數據，將增大發現上述各類錯誤的可能性。在確定測試用例的同時，應給出期望結果。
提高模塊的內聚度可簡化單元測試，如果每個模塊只能完成一個，所需測試用例數目將顯著減少，模塊中的錯誤也更容易發現。
(2)集成測試
也稱組裝測試。在單元測試之后，需要按照設計時作出的結構圖，將它們聯結起來，進行集成測試。集成測試是組裝軟件的系統測試技術，按設計要求把通過單元測試的各個模塊組裝在一起之后，進行綜合測試以便發現與接口有關的各種錯誤。
把所有模塊按設計要求一次全部組裝起來，然后進行集成測試，這稱為非增量式集成。這種方法容易出現混亂。因為測試時可能發現一大堆錯誤，為每個錯誤定位和糾正非常困難，并且在改正一個錯誤的同時又可能引入新的錯誤。新舊錯誤混雜，更難斷定出錯的原因和位置。與之相反的是增量式集成方法，程序一段一段地擴展，測試的范圍一步一步地增大，錯誤易于定位和糾正，界面的測試亦可做到完全徹底。常用的有下面兩種增量式集成方法。
a.自頂向下集成
自頂向下集成是構造程序結構的一種增量式方式，它從主控模塊開始，按照軟件的控制層次結構，以深度優先或廣度優先的策略，逐步把各個模塊集成在一起。深度優先策略首先是把主控制路徑上的模塊集成在一起，至于選擇哪一條路徑作為主控制路徑，這多少帶有些隨意性，要根據問題的特性確定。
自頂向下集成測試的具體步驟為:(1)以主控模塊作為測試驅動模塊，把對主控模塊進行單元測試時引入的所有樁模塊用實際模塊替代;(2)依據所選的集成策略，每次只替代一個樁模塊;(3)每集成一個模塊立即測試一遍;(4)只有每組測試完成后，才著手替換下一個樁模塊;(5)為避免引入新錯誤，須不斷地進行回歸測試。從第(2)步開始，循環執行上述步驟，直至整個程序結構構造完畢。
自頂向下集成的優點在于能盡早地對程序的主要控制和決策機制進行檢驗，因此能較早地發現錯誤。缺點是在測試較高層模塊時，低層處理采用樁模塊替代，不能反映真實情況，重要數據也不能及時回送到上層模塊，因此測試并不充分。解決這個問題有幾種辦法，第一種是把某些測試推遲到用真實模塊替代樁模塊之后進行，第二種是開發能模擬真實模塊的樁模塊;第三種是自底向上集成模塊。第一種方法又回退為非增量式的集成方法，使錯誤難于定位和糾正，并失去了在組裝模塊時進行一些特定測試的可能性;第二種方法無疑要大大增加開銷;第三種方法更切實可行。
b.自底向上集成
自底向上測試是從軟件結構最低層的模塊開始組裝測試。因測試到較高層模塊時，所需的下層模塊功能均已具備，所以不再需要樁模塊。
自底向上集成測試的步驟分為:(1)把低層模塊組織成實現某個子功能的模塊群;(2)開發一個測試驅動模塊，控制測試數據的輸入和測試結果的輸出;(3)對每個模塊群進行測試;(4)刪除測試使用的驅動模塊，用較高層模塊把模塊群組織成為完成更大功能的新模塊群。從第(1)步開始循環執行上述各步驟，直至整個程序構造完畢。
自底向上集成方法不用樁模塊，測試用例的設計亦相對簡單，但缺點是程序最后一個模塊加入時才具有整體形象。它與自頂向上集成測試方法優缺點相反。因此，在測試軟件系統時，應根據軟件的特點和工程的進度，選用適當的測試策略。有時混和使用兩種策略更為有效，上層模塊用自頂向下的方法，下層模塊用自底向上的方法。
此外，在集成測試中尤其要注意關鍵模塊。所謂關鍵模塊一般都具有下述一個或多個特征:(1)對應幾條需求;(2)具有高層控制功能;(3)復雜、易出錯;(4)有特殊的性能要求。關鍵模塊應盡早測試，并反復進行回歸測試。
(3)確認測試
也稱合格性測試，這是檢驗所開發的軟件是否按用戶要求運行。確認測試應檢查軟件能否按合同要求進行工作，即是否滿足軟件需求說明書中的確認標準。
a.確認測試標準
實現軟件確認要通過一系列黑盒測試。確認測試同樣需要制訂測試計劃和過程，測試計劃應規定測試的種類和測試進度，測試過程則定義一些特殊的測試用例，旨在說明軟件與需求是否一致。無論是測試計劃還是測試過程，都應該著重考慮軟件是否滿足合同規定的所有功能和性能，文檔資料是否完整、準確，人機界面、可移植性、兼容性、可維護性等是否令用戶滿意。
確認測試的結果有兩種可能，一種是功能和性能指標滿足軟件需求說明的要求，用戶可以接受;另一種是軟件不滿足軟件需求說明的要求，用戶無法接受。項目進行到這個階段才發現嚴重錯誤和偏差一般很難在預期內改正，因此必須與用戶協商，尋求一個妥善解決問題的方法。
b.配置復審
確認測試的另一個重要環節是配置復審。復審的目的在于保證軟件配置齊全、分類有序，并且包括軟件維護所必須的細節。
c.α、β測試
事實上，軟件開發人員不可能完全預見用戶實際使用程序的情況。例如，用戶可能錯誤地理解命令，或提供一些奇怪的數據組合，亦可能對設計者自認明了的輸出信息迷惑不解。因此，軟件是否真正滿足最終用戶的要求，應由用戶進行一系列“驗收測試”。驗收測試既可以是非正式的測試，也可以是有計劃、有系統的測試。有時，驗收測試長達數周甚至數月，不斷暴露錯誤，導致開發延期。一個軟件產品，可能擁有眾多用戶，不可能由每個用戶驗收，此時多采用稱為α、β測試的過程，以期發現那些似乎只有最終用戶才能發現的問題。
α測試是指軟件開發公司組織內部人員模擬各類用戶對即將面市的軟件產品(稱為α版本)進行測試，試圖發現錯誤并修正。α測試的關鍵在于盡可能逼真地模擬實際運行環境和用戶對軟件產品的操作并盡最大努力涵蓋所有可能的用戶操作方式。經過α測試調整的軟件產品稱為β版本。緊隨其后的β測試是指軟件開發公司組織各方面的典型用戶在日常工作中實際使用β版本，并要求用戶報告異常情況、提出批評意見。然后軟件開發公司再對β版本進行改錯和完善。
(4)系統測試
軟件開發完成后，還要與系統中其他部分配套運行，進行系統測試。包括恢復測試、安全測試、強度測試和性能測試等。
計算機軟件是基于計算機系統的一個重要組成部分，軟件開發完畢后應與系統中其他成分集成在一起，此時需要進行一系列系統集成和確認測試。對這些測試的詳細討論已超出軟件工程的范圍，這些測試也不可能僅由軟件開發人員完成。
在系統測試之前，軟件工程師應完成下列工作:(1)為測試軟件系統的輸入信息設計出錯處理通路;(2)設計測試用例，模擬錯誤數據和軟件界面可能發生的錯誤，記錄測試結果，為系統測試提供經驗和幫助;(3)參與系統測試的規劃和設計，保證軟件測試的合理性。
系統測試應該由若干個不同測試組成，目的是充分運行系統，驗證系統各部件是否都能工作并完成所賦予的任務。下面簡單介紹幾類系統測試。
(1)恢復測試
恢復測試主要檢查系統的容錯能力。當系統出錯時，能否在指定時間間隔內修正錯誤并重新啟動系統?；謴蜏y試首先要采用各種辦法強迫系統失敗，然后驗證系統是否能盡快恢復。對于自動恢復需驗證重新初始化、檢查點、數據恢復和重新啟動等機制的正確性;對于人工干預的恢復系統，還需估測平均修復時間，確定其是否在可接受的范圍內。
(2)安全測試
安全測試檢查系統對非法侵入的防范能力。安全測試期間，測試人員假扮非法入侵者，采用各種辦法試圖突破防線。
例如：
?、傧敕皆O法截取或破譯口令;
?、趯ｉT定做軟件破壞系統的保護機制;
?、酃室鈱е孪到y失敗，企圖趁恢復之機非法進入;
?、茉噲D通過瀏覽非保密數據，推導所需信息。
理論上講，只要有足夠的時間和資源，沒有不可進入的系統。因此系統安全設計的準則是使非法侵入的代價超過被保護信息的價值。此時非法侵入者已無利可圖。
(3)強度測試
強度測試檢查程序對異常情況的抵抗能力。強度測試總是迫使系統在異常的資源配置下運行。例如，當中斷的正常頻率為每秒一至兩個時，運行每秒產生十個中斷的測試用例;定量地增長數據輸入率，檢查輸入子功能的反映能力;運行需要最大存儲空間(或其他資源)的測試用例;運行可能導致虛存操作系統崩潰或磁盤數據劇烈抖動的測試用例等等。
(4)性能測試
對于那些實時和嵌入式系統，軟件部分既使能滿足功能要求，也未必能夠滿足性能要求。雖然從單元測試起，每一測試步驟都包含性能測試，但只有當系統真正集成之后，在真實環境中才能全面、可靠地測試運行性能系統。性能測試是為了完成這一任務。性能測試有時與強度測試相結合，經常需要其他軟硬件的配套支持。
只有經過上述測試過程測試后，軟件才能基本滿足開發要求。測試宣告結束，經驗收后，將軟件提交用戶使用。
《涉外信息綜合管理系統》軟件測試的組織實施
北京市公安局出入境管理處《涉外信息綜合管理系統》采用UNIX和Windows NT操作系統，ORACLE數據庫，Compaq小型機為主服務器，多臺高檔PC服務器支持關鍵應用，采用C/S及B/S方式實現臨時入境人員業務、公民因私出境業務、外國人簽證業務、三資企業業務、港澳臺暫住人員業務、外國長住人員業務、涉外違法案件業務等幾大類信息的采集、取像、審批、制證等業務工作的信息化管理。同時，對公安內部用戶提供綜合查詢、統計、數據析取分析處理等功能。此應用系統信息涉及單位所有業務，應用軟件設計比較復雜，軟件測試工作在保障軟件質量，開發出高質量的軟件中起到了重要作用。
北京市公安局出入境管理處在軟件開發初期就建立專門的軟件測試小組來實現軟件測試過程的組織與管理。測試小組的主要職能就是查找軟件中的錯誤，且這個小組不直接參與開發，這樣就能排除測試期間開發者可能遇到的心理上的“利益沖突”，即開發者大多不情愿看到自己的工作遭到否定。建立測試小組的另一好處是避免了開發者在測試過程中容易陷入的“思維定式”，能夠從多方面觀察問題。
軟件測試本身是一個復雜的過程。因此，早在需求分析和設計階段，北京市公安局出入境管理處測試小組的測試人員就對各種說明書進行仔細分析，提取了有關的測試信息，編寫了測試計劃和測試規程。適時采用各種軟件測試方法對軟件進行測試，在測試過程中，把發現的錯誤及時反饋給開發人員，確保測試人員與開發人員的及時溝通。對開發人員修正過的軟件，還要分析修改部分對整個系統的影響，有針對性地對受影響的部分進行重新測試。測試人員在測試的同時還完成了各種測試文件的編寫工作。
作為保證系統軟件質量的一種重要手段，軟件測試是必不可少的，但是僅僅依靠測試來保證軟件質量是不夠的，還需要有良好的質量管理體系。軟件質量管理的一條主要途徑就是建立質量保證小組，這個小組要參與軟件開發和確認的各個階段，并承擔以下任務：
(1)保證對系統需求說明書、設計文本、軟件代碼和測試步驟的嚴格控制，確保被測軟件與設計需求、文本的高級要求說明一致;(2)代碼化之前復審軟件設計;(3)參與設計和開發活動的技術審查和復審;(4)進行復審以保證軟件與標準和規程一致;(5)記錄軟件的問題和不一致之處并監控正確的操作;(6)復審并核準合格的測試計劃和測試規程;(7)監控測試操作。
總結
軟件質量是軟件產品的生命之所在，軟件測試作為保證軟件質量的手段，愈來愈受到人們的重視。而如何提高軟件產品質量，嚴格的測試是重要的一環。
軟件測試理論和方法在不斷完善，測試工具也在蓬勃發展。測試已從簡單的檢查程序邏輯走向“確認、驗證和測試”，又走向全面形式化的道路。
本文介紹了軟件測試的各種方法、測試過程的管理及我處《涉外信息綜合管理系統》的軟件測試組織實施。限于篇幅，有些部分不得不簡略敘述。我熱切地期望，從事軟件開發人員能予軟件測試以足夠的重視，并應用先進的技術、管理手段，使開發出的軟件產品具備卓越的品質。
