軟件測試規(guī)范概述

《軟件測試規(guī)范》（草案）

ComputerSoftwareTestingCriterion一、目的與適用范圍1、目的軟件測試是軟件工程的重要組成部分，測試工作的質(zhì)量直接影響軟件產(chǎn)品的生命力。測試工作的標準化是軟件質(zhì)量保證(QualityAssurance)重要而且必須的環(huán)節(jié)。制定本標準的目的在于使測試流程更標準，測試過程更規(guī)范。從而使整個軟件生產(chǎn)納入更系統(tǒng)化、更專業(yè)化的軌道。2、適用范圍本標準適用于軟件測試流程的管理和測試的具體操作過程。本標準的使用者可以是企業(yè)內(nèi)部的測試人員和開發(fā)人員。二、測試方法軟件測試的方法和技術是多種多樣的。以下將介紹比較常用的一些測試方法：1、靜態(tài)測試靜態(tài)方法是指不運行被測程序本身，僅通過分析或檢查源程序的文法、結構、過程、接口等來檢查程序的正確性。靜態(tài)方法通過程序靜態(tài)特性的分析，找出欠缺和可疑之處，例如不匹配的參數(shù)、不適當?shù)难h(huán)嵌套和分支嵌套、不允許的遞歸、未使用過的變量、空指針的引用和可疑的計算等。靜態(tài)測試結果可用于進一步的查錯，并為測試用例選取提供指導。2、動態(tài)測試動態(tài)方法是指通過運行被測程序，檢查運行結果與預期結果的差異，并分析運行效率和健壯性等性能，這種方法由三部分組成：構造測試實例、執(zhí)行程序、分析程序的輸出結果。3、黑盒測試黑盒測試也稱功能測試或數(shù)據(jù)驅(qū)動測試，它是在已知產(chǎn)品所應具有的功能，通過測試來檢測每個功能是否都能正常使用，在測試時，把程序看作一個不能打開的黑盆子，在完全不考慮程序內(nèi)部結構和內(nèi)部特性的情況下，測試者在程序接口進行測試，它只檢查程序功能是否按照需求規(guī)格說明書的規(guī)定正常使用，程序是否能適當?shù)亟邮蛰斎霐?shù)鋸而產(chǎn)生正確的輸出信息，并且保持外部信息(如數(shù)據(jù)庫或文件)的完整性。黑盒測試方法主要有等價類劃分、邊值分析、因—果圖、錯誤推測等，主要用于軟件確認測試?！昂诤小狈ㄖ塾诔绦蛲獠拷Y構、不考慮內(nèi)部邏輯結構、針對軟件界面和軟件功能進行測試?！昂诤小狈ㄊ歉F舉輸入測試，只有把所有可能的輸入都作為測試情況使用，才能以這種方法查出程序中所有的錯誤。實際上測試情況有無窮多個，人們不僅要測試所有合法的輸入，而且還要對那些不合法但是可能的輸入進行測試。4、白盒測試白盒測試也稱結構測試或邏輯驅(qū)動測試，它是知道產(chǎn)品內(nèi)部工作過程，可通過測試來檢測產(chǎn)品內(nèi)部動作是否按照規(guī)格說明書的規(guī)定正常進行，按照程序內(nèi)部的結構測試程序，檢驗而不顧它的功能，白盒測試的主要方法程序中的每條通路是否都有能按預定要求正確工作，有邏輯驅(qū)動、基路測試等，主要用于軟件驗證。而不顧它的功能，白盒測試的主要方法“白盒”法全面了解程序內(nèi)部邏輯結構、對所有邏輯路徑進行測試。 “白盒”法是窮舉路徑測試。在使用這一方案時，測試者必須檢查程序的內(nèi)部結構， 從檢查程序的邏輯著手，得出測試數(shù)據(jù)。貫穿程序的獨立路徑數(shù)是天文數(shù)字。但即使每條路徑都測試了仍然可能有錯誤。第一，窮舉路徑測試決不能查出程序違反了設計規(guī)范，即程序本身是個錯誤的程序。第二，窮舉路徑測試不可能查出程序中因遺漏路徑而出錯。第三，窮舉路徑測試可能發(fā)現(xiàn)不了一些與數(shù)據(jù)相關的錯誤。5、 ALAC(Act-like-a-customer)測試ALAC測試是一種基于客戶使用產(chǎn)品的知識開發(fā)出來的測試方法。ALAC測試是基于復雜的軟件產(chǎn)品有許多錯誤的原則。最大的受益者是用戶，缺陷查找和改正將針對哪些客戶最容易遇到的錯誤。6、 單元測試方法單元測試任務單元測試任務包括：u模塊接口測試；u模塊局部數(shù)據(jù)結構測試；u模塊邊界條件測試；u模塊中所有獨立執(zhí)行通路測試；u模塊的各條錯誤處理通路測試。模塊接口測試是單元測試的基礎。只有在數(shù)據(jù)能正確流入、流出模塊的前提下，其他測試才有意義。接口測試測試接口正確與否應該考慮下列因素：u輸入的實際參數(shù)與形式參數(shù)的個數(shù)是否相同；u輸入的實際參數(shù)與形式參數(shù)的屬性是否匹配；u輸入的實際參數(shù)與形式參數(shù)的量綱是否一致；u調(diào)用其他模塊時所給實際參數(shù)的個數(shù)是否與被調(diào)模塊的形參個數(shù)相同；u調(diào)用其他模塊時所給實際參數(shù)的屬性是否與被調(diào)模塊的形參屬性匹配；u調(diào)用其他模塊時所給實際參數(shù)的量綱是否與被調(diào)模塊的形參量綱一致；u調(diào)用預定義函數(shù)時所用參數(shù)的個數(shù)、屬性和次序是否正確；u是否存在與當前入口點無關的參數(shù)引用；u是否修改了只讀型參數(shù)；u對全程變量的定義各模塊是否一致；u是否把某些約束作為參數(shù)傳遞。如果模塊內(nèi)包括外部輸入輸出，還應該考慮下列因素：u文件屬性是否正確；uOPEN/CLOSE語句是否正確；u格式說明與輸入輸出語句是否匹配；u緩沖區(qū)大小與記錄長度是否匹配；u文件使用前是否已經(jīng)打開；u是否處理了文件尾；u是否處理了輸入/輸出錯誤；u輸出信息中是否有文字性錯誤；6.3數(shù)據(jù)測試檢查局部數(shù)據(jù)結構是為了保證臨時存儲在模塊內(nèi)的數(shù)據(jù)在程序執(zhí)行過程中完整、正確。局部數(shù)據(jù)結構往往是錯誤的根源，應仔細設計測試用例，力求發(fā)現(xiàn)下面幾類錯誤：u不合適或不相容的類型說明；u變量無初值；u變量初始化或省缺值有錯；u不正確的變量名（拼錯或不正確地截斷）；u出現(xiàn)上溢、下溢和地址異常。除了局部數(shù)據(jù)結構外，如果可能，單元測試時還應該查清全局數(shù)據(jù)（例如FORTRAN的公用區(qū)）對模塊的影響。6.4控制流測試在模塊中應對每一條獨立執(zhí)行路徑進行測試，單元測試的基本任務是保證模塊中每條語句至少執(zhí)行一次。此時設計測試用例是為了發(fā)現(xiàn)因錯誤計算、不正確的比較和不適當?shù)目刂屏髟斐傻腻e誤。此時基本路徑測試和循環(huán)測試是最常用且最有效的測試技術。計算中常見的錯誤包括：u誤解或用錯了算符優(yōu)先級；u混合類型運算；u變量初值錯；u精度不夠；u表達式符號錯。比較判斷與控制流常常緊密相關，測試用例還應致力于發(fā)現(xiàn)下列錯誤：u不同數(shù)據(jù)類型的對象之間進行比較；u錯誤地使用邏輯運算符或優(yōu)先級；u因計算機表示的局限性，期望理論上相等而實際上不相等的兩個量相等；u比較運算或變量出錯；u循環(huán)終止條件或不可能出現(xiàn)；u迭代發(fā)散時不能退出；u錯誤地修改了循環(huán)變量。6.5出錯處理測試一個好的設計應能預見各種出錯條件，并預設各種出錯處理通路，出錯處理通路同樣需要認真測試，測試應著重檢查下列問題：u輸出的出錯信息難以理解；u記錄的錯誤與實際遇到的錯誤不相符；u在程序自定義的出錯處理段運行之前，系統(tǒng)已介入；u異常處理不當；u錯誤陳述中未能提供足夠的定位出錯信息。6.6邊界條件測試邊界條件測試是單元測試中最后，也是最重要的一項任務。眾的周知，軟件經(jīng)常在邊界上失效，采用邊界值分析技術，針對邊界值及其左、右設計測試用例，很有可能發(fā)現(xiàn)新的錯誤。7、集成測試的基本方法某設計人員習慣于把所有模塊按設計要求一次全部組裝起來，然后進行整體測試，這稱為非增量式集成。這種方法容易出現(xiàn)混亂。因為測試時可能發(fā)現(xiàn)一大堆錯誤，為每個錯誤定位和糾正非常困難，并且在改正一個錯誤的同時又可能引入新的錯誤，新舊錯誤混雜，更難斷定出錯的原因和位置。與之相反的是增量式集成方法，程序一段一段地擴展，測試的范圍一步一步地增大，錯誤易于定位和糾正，界面的測試亦可做到完全徹底。下面討論兩種增量式集成方法。7.1自頂向下集成自頂向下集成是構造程序結構的一種增量式方式，它從主控模塊開始，按照軟件的控制層次結構，以深度優(yōu)先或廣度優(yōu)先的策略，逐步把各個模塊集成在一起。深度優(yōu)先策略首先是把主控制路徑上的模塊集成在一起，至于選擇哪一條路徑作為主控制路徑，這多少帶有隨意性，一般根據(jù)問題的特性確定。自頂向下集成測試的具體步驟為：u以主控模塊作為測試驅(qū)動模塊，把對主控模塊進行單元測試時引入的所有樁模塊用實際模塊替代；u依據(jù)所選的集成策略（深度優(yōu)先或廣度優(yōu)先），每次只替代一個樁模塊；u每集成一個模塊立即測試一遍；u只有每組測試完成后，才著手替換下一個樁模塊；u為避免引入新錯誤，須不斷地進行回歸測試（即全部或部分地重復已做過的測試）；u從第二步開始，循環(huán)執(zhí)行上述步驟，直至整個程序結構構造完畢。自頂向下集成的優(yōu)點在于能盡早地對程序的主要控制和決策機制進行檢驗， 因此較早地發(fā)現(xiàn)錯誤。缺點是在測試較高層模塊時，低層處理采用樁模塊替代，不能反映真實情況，重要數(shù)據(jù)不能及時回送到上層模塊，因此測試并不充分。解決這個問題有幾種辦法，第一種是把某些測試推遲到用真實模塊替代樁模塊之后進行，第二種是開發(fā)能模擬真實模塊的樁模塊；第三種是自底向上集成模塊。第一種方法又回退為非增量式的集成方法，使錯誤難于定位和糾正，并且失去了在組裝模塊時進行一些特定測試的可能性；第二種方法無疑要大大增加開銷；第三種方法比較切實可行。7.2自底向上集成自底向上測試是從“原子”模塊（即軟件結構最低層的模塊）開始組裝測試，因測試到較高層模塊時，所需的下層模塊功能均已具備，所以不再需要樁模塊。自底向上綜合測試的步驟分為：u把低層模塊組織成實現(xiàn)某個子功能的模塊群（ cluster）;u開發(fā)一個測試驅(qū)動模塊，控制測試數(shù)據(jù)的輸入和測試結果的輸出；u對每個模塊群進行測試；u刪除測試使用的驅(qū)動模塊，用較高層模塊把模塊群組織成為完成更大功能的新模塊群；u從第一步開始循環(huán)執(zhí)行上述各步驟，直至整個程序構造完畢。自底向上集成方法不用樁模塊，測試用例的設計亦相對簡單，但缺點是程序最后一個模塊加入時才具有整體形象。它與自頂向綜合測試方法優(yōu)缺點正好相反。因此，在測試軟件系統(tǒng)時，應根據(jù)軟件的特點和工程的進度，選用適當?shù)臏y試策略，有時混和使用兩種策略更為有效，上層模塊用自頂向下的方法，下層模塊用自底向上的方法。此外，在集成測試中尤其要注意關鍵模塊，所謂關鍵模塊一般都具有下述一或多個特征：①對應幾條需求；②具有高層控制功能；③復雜、易出錯；④有特殊的性能要求。關鍵模塊應盡早測試，并反復進行回歸測試。8、 確認測試的基本方法8.1確認測試標準實現(xiàn)軟件確認要通過一系列黑盒測試。確認測試同樣需要制訂測試計劃和過程，測試計劃應規(guī)定測試的種類和測試進度，測試過程則定義一些特殊的測試用例，旨在說明軟件與需求是否一致。無論是計劃還是過程，都應該著重考慮軟件是否滿足合同規(guī)定的所有功能和性能，文檔資料是否完整、準確，人機界面和其他方面（例如，可移植性、兼容性、錯誤恢復能力和可維護性等）是否令用戶滿意。確認測試的結果有兩種可能，一種是功能和性能指標滿足軟件需求說明的要求，用戶可以接受；另一種是軟件不滿足軟件需求說明的要求，用戶無法接受。項目進行到這個階段才發(fā)現(xiàn)嚴重錯誤和偏差一般很難在預定的工期內(nèi)改正，因此必須與用戶協(xié)商，尋求一個妥善解決問題的方法。8.2配置復審確認測試的另一個重要環(huán)節(jié)是配置復審。復審的目的在于保證軟件配置齊全、分類有序，并且包括軟件維護所必須的細節(jié)。8?3aB測試事實上，軟件開發(fā)人員不可能完全預見用戶實際使用程序的情況。例如，用戶可能錯誤的理解命令，或提供一些奇怪的數(shù)據(jù)組合，亦可能對設計者自認明了的輸出信息迷惑不解，等等。因此，軟件是否真正滿足最終用戶的要求，應由用戶進行一系列“驗收測試”。驗收測試既可以是非正式的測試，也可以有計劃、有系統(tǒng)的測試。有時，驗收測試長達數(shù)周甚至數(shù)月，不斷暴露錯誤，導致開發(fā)延期。一個軟件產(chǎn)品，可能擁有眾多用戶，不可能由每個用戶驗收，此時多采用稱為aB測試的過程，以期發(fā)現(xiàn)那些似乎只有最終用戶才能發(fā)現(xiàn)的問題。a測試是指軟件開發(fā)公司組織內(nèi)部人員模擬各類用戶行對即將面市軟件產(chǎn)品（稱為a版本）進行測試，試圖發(fā)現(xiàn)錯誤并修正。 a測試的關鍵在于盡可能逼真地模擬實際運行環(huán)境和用戶對軟件產(chǎn)品的操作并盡最大努力涵蓋所有可能的 用戶操作方式。經(jīng)過a測試調(diào)整的軟件產(chǎn)品稱為B版本。緊隨其后的B測試是指軟件開發(fā)公司組織各方面的典型用戶在日常工作中實際使用B版本，并要求用戶報告異常情況、提出批評意見。然后軟件開發(fā)公司再對B版本進行改錯和完善。9、 系統(tǒng)測試的基本方法9?1恢復測試恢復測試主要檢查系統(tǒng)的容錯能力。當系統(tǒng)出錯時，能否在指定時間間隔內(nèi)修正錯誤并重新啟動系統(tǒng)?；謴蜏y試首先要采用各種辦法強迫系統(tǒng)失敗，然后驗證系統(tǒng)是否能盡快恢復。對于自動恢復需驗證重新初始化(reinitialization)、檢查點(checkpointingmechanisms)、數(shù)據(jù)恢復(datarecovery)和重新啟動(restart)等機制的正確性；對于人工干預的恢復系統(tǒng)，還需估測平均修復時間，確定其是否在可接受的范圍內(nèi)。9.2安全測試安全測試檢查系統(tǒng)對非法侵入的防范能力。安全測試期間，測試人員假扮非法入侵者，采用各種辦法試圖突破防線。 例如，①想方設法截取或破譯口令；②專門定做軟件破壞系統(tǒng)的保護機制；③故意導致系統(tǒng)失敗，企圖趁恢復之機非法進入；④試圖通過瀏覽非保密數(shù)據(jù)，推導所需信息，等等。理論上講，只要有足夠的時間和資源，沒有不可進入的系統(tǒng)。因此系統(tǒng)安全設計的準則是，使非法侵入的代價超過被保護信息的價值。此時非法侵入者已無利可圖。9.3強度測試強度測試檢查程序?qū)Ξ惓Ｇ闆r的抵抗能力。強度測試總是迫使系統(tǒng)在異常的資源配置下運行。例如，①當中斷的正常頻率為每秒一至兩個時，運行每秒產(chǎn)生十個中斷的測試用例；②定量地增長數(shù)據(jù)輸入率，檢查輸入子功能的反映能力；③運行需要最大存儲空間(或其他資源)的測試用例；④運行可能導致虛存操作系統(tǒng)崩潰或磁盤數(shù)據(jù)劇烈抖動的測試用例，9.4性能測試對于那些實時和嵌入式系統(tǒng)，軟件部分即使?jié)M足功能要求，也未必能夠滿足性能要求，雖然從單元測試起，每一測試步驟都包含性能測試，但只有當系統(tǒng)真正集成之后，在真實環(huán)境中才能全面、可靠地測試運行性能系統(tǒng)性能測試是為了完成這一任務。性能測試有時與強度測試相結合，經(jīng)常需要其他軟硬件的配套支持。10、回歸測試方法回歸測試的價值在于它是一個能夠檢測到回歸錯誤的受控實驗。 當測試組選擇縮減的回歸測試時，有可能刪除了將揭示回歸錯誤的測試用例，消除了發(fā)現(xiàn)回歸錯誤的機會。然而，如果采用了代碼相依性分析等安全的縮減技術，就可以決定哪些測試用例可以被刪除而不會讓回歸測試的意圖遭到破壞。選擇回歸測試策略應該兼顧效率和有效性兩個方面。常用的選擇回歸測試的方式包括：再測試全部用例：選擇基線測試用例庫中的全部測試用例組成回歸測試包， 這是一種比較安全的方法，再測試全部用例具有最低的遺漏回歸錯誤的風險，但測試成本最高。全部再測試幾乎可以應用到任何情況下，基本上不需要進行分析和重新開發(fā)，但是，隨著開發(fā)工作的進展，測試用例不斷增多，重復原先所有的測試將帶來很大的工作量，往往超出了我們的預算和進度?；陲L險選擇測試：可以基于一定的風險標準來從基線測試用例庫中選擇回歸測試包。 首先運行最重要的、關鍵的和可疑的測試，而跳過那些非關鍵的、優(yōu)先級別低的或者高穩(wěn)定的測試用例，這些用例即便可能測試到缺陷，這些缺陷的嚴重性也僅有三級或四級。一般而言，測試從主要特征到次要特征10.3基于操作剖面選擇測試：如果基線測試用例庫的測試用例是基于軟件操作剖面開發(fā)的，測試用例的分布情況反映了系統(tǒng)的實際使用情況。回歸測試所使用的測試用例個數(shù)可以由測試預算確定，回歸測試可以優(yōu)先選擇那些針對最重要或最頻繁使用功能的測試用例，釋放和緩解最高級別的風險，有助于盡早發(fā)現(xiàn)那些對可靠性有最大影響的故障。這種方法可以在一個給定的預算下最有效的提高系統(tǒng)可靠性，但實施起來有一定的難度。10.4再測試修改的部分：當測試者對修改的局部化有足夠的信心時，可以通過相依性分析識別軟件的修改情況并分析修改的影響，將回歸測試局限于被改變的模塊和它的接口上。 通常，一個回歸錯誤一定涉及一個新的、修改的或刪除的代碼段。在允許的條件下，回歸測試盡可能覆蓋受到影響的部分。再測試全部用例的策略是最安全的策略，但已經(jīng)運行過許多次的回歸測試不太可能揭示新的錯誤，而且很多時候，由于時間、人員、設備和經(jīng)費的原因，不允許選擇再測試全部用例的回歸測試策略，此時，可以選擇適當?shù)牟呗赃M行縮減的回歸測試。三、測試階段的劃分根據(jù)開發(fā)過程和實際需求將測試階段劃分為：設計階段、代碼檢測單元測試階段、集成測試階段、系統(tǒng)測試階段、驗收測試階段、回歸測試（復測）階段。各階段中使用的測試方法詳見本規(guī)范的測試方法。1、設計階段核心工作是對軟件產(chǎn)品功能說明書進行檢查，軟件產(chǎn)品功能說明書是對軟件產(chǎn)品最終需要實現(xiàn)的功能的描述。編寫軟件測試計劃。2、單元測試階段單元測試完成對軟件最小的結構的測試，一般用來驗證模塊的功能屬性，它利用設計文檔作為指導，主要使用白盒測試技術；但也可以測試其它項目，如性能、可用性等等，可使用“黑盒”或“白盒”方法進行。在單元測試中，檢查出模塊內(nèi)部的錯誤是單元測試的主要工作。該階段的測試工作，由編程組內(nèi)部人員進行交叉測試（避免編程人員測試自己的程序）。單元測試過程：一般認為單元測試應緊接在編碼之后，當源程序編制完成并通過復審和編譯檢查，便可開始單元測試。測試用例的設計應與復審工作相結合，根據(jù)設計信息選取測試數(shù)據(jù)，將增大發(fā)現(xiàn)上述各類錯誤的可能性。在確定測試用例的同時，應給出期望結果。提高模塊的內(nèi)聚度可簡化單元測試，如果每個模塊只能完成一個，所需測試用例數(shù)目將顯著減少，模塊中的錯誤也更容易發(fā)現(xiàn)。3、集成測試階段時常有這樣的情況發(fā)生，每個模塊都能單獨工作，但這些模塊集成在一起之后卻不能正常工作。主要原因是，模塊相互調(diào)用時接口會引入許多新問題。例如，數(shù)據(jù)經(jīng)過接口可能丟失；一個模塊對另一模塊可能造成不應有的影響；幾個子功能組合起來不能實現(xiàn)主功能；誤差不斷積累達到不可接受的程度；全局數(shù)據(jù)結構出現(xiàn)錯誤，等等。集成測試是組裝軟件的系統(tǒng)測試技術，按設計要求把通過單元測試的各個模塊組裝在一起之后，進行集成測試以便發(fā)現(xiàn)與接口有關的各種錯誤。4、確認測試階段確認測試的目的是向未來的用戶表明系統(tǒng)能夠像預定要求那樣工作。經(jīng)集成測試后，已經(jīng)按照設計把所有的模塊組裝成一個完整的軟件系統(tǒng)，接口錯誤也已經(jīng)基本排除了，接著就應該進一步驗證軟件的有效性，這就是確認測試的任務，即軟件的功能和性能如同用戶所合理期待的那樣。5、系統(tǒng)測試階段計算機軟件是基于計算機系統(tǒng)的一個重要組成部分，軟件開發(fā)完畢后應與系統(tǒng)中其它成分集成在一起，此時需要進行一系列系統(tǒng)測試。包括恢復測試、安全測試、強度測試和性能測試等。在系統(tǒng)測試之前，軟件工程師應完成下列工作：（1） 為測試軟件系統(tǒng)的輸入信息設計出錯處理通路；（2） 設計測試用例，模擬錯誤數(shù)據(jù)和軟件界面可能發(fā)生的錯誤，記錄測試結果，為系統(tǒng)測試提供經(jīng)驗和幫助；（3） 參與系統(tǒng)測試的規(guī)劃和設計，保證軟件測試的合理性。系統(tǒng)測試應該由若干個不同測試組成，目的是充分運行系統(tǒng)，驗證系統(tǒng)各部件是否都能工作并完成所賦予的任務。6、回歸測試（復測）階段回歸測試就是漏洞修復完成后再對軟件進行測試，以確保軟件沒有產(chǎn)生“回歸”或因修復而變得更糟，這種測試一般要重新運行最初發(fā)現(xiàn)問題的原始測試程序。有關回歸測試有兩個焦點：有沒有產(chǎn)生新的漏洞，修復是否確實使缺陷消除。回歸測試的過程：有了測試用例庫的維護方法和回歸測試包的選擇策略，回歸測試可遵循下述過程進行：u識別出軟件中被修改的部分u從原基線測試用例庫中排除所有不再適用的測試用例，確定那些對新的軟件版本依然有效的測試用例u如果必要，生成新的測試用例集，用于測試原來測試用例集無法充分測試的部分u依據(jù)一定的策略選擇測試用例測試被修改的軟件。u進行測試，并記錄測試結果到測試報告u分析測試報告u修正和測試工作u完成測試產(chǎn)品提交配置四、測試類型的劃分

1、功能測試：對軟件功能進行的測試，主要檢查軟件功能是否實現(xiàn)了軟件功能說明書（軟件需求）上的功能要求。2、界面測試：對軟件的用戶界面進行的測試，主要檢查用戶界面的美觀度、統(tǒng)一性、易用性等方面的內(nèi)容。3、數(shù)據(jù)處理測試：對軟件數(shù)據(jù)接口進行的測試，主要檢查軟件數(shù)據(jù)處理中輸入、處理、輸出數(shù)據(jù)過程。4、流程測試：按操作流程進行的測試，主要有業(yè)務流程、數(shù)據(jù)流程、邏輯流程、正反流程，檢查軟件在按流程操作時是否能夠正確處理。5、極限測試：在軟件的極限條件下進行的測試，主要有對數(shù)據(jù)的極限值、邊界值操作，對軟件進行致命操作等。6、并發(fā)測試：在網(wǎng)絡環(huán)境、并發(fā)環(huán)境、多用戶條件下對軟件進行的測試。7、安全測試：對軟件安全性方面的測試，主要檢測軟件中加密、解密、數(shù)據(jù)備份、恢復、病毒檢測等問題。8、性能測試：對軟件整體性能的測試，測試內(nèi)容有適應性、健壯性、可恢復性、災難恢復能力等9、安裝測試：在不同PC條件、操作系統(tǒng)、模擬客戶機等條件下進行軟件的安裝測試，主要檢查軟件打包或發(fā)布之后存在的問題。測試模式測試模式V型模型，實現(xiàn)測試與軟件開發(fā)的同步進行。六、測試一開發(fā)工作流程七、測試工作流程『設計ai、\灣試用例轟/執(zhí)折?\試用例 試用例'程序錯俁修正用側(cè)執(zhí)廠一、錯保跟竺J盤匸斗提交說明：設計測試用例、執(zhí)行測試用例詳見《測試用例》 。描述軟件錯誤即填寫bug記錄表，詳見《BUG標準》八、附錄附錄一、測試文檔I測試計劃1引言1.1編寫目的TOC\o"1-5"\h\z【闡明編寫測試計劃的目的，指明讀者對象。 】1.2項目背景【說明項目的來源、委托單位及主管部門。 】1.3定義【列出測試計劃中所用到的專門術語的定義和縮寫詞的原意。 】1.4參考資料【列出有關資料的作者、標題、編號、發(fā)表日期、