第二章軟件測(cè)試基礎(chǔ)寧華287263358@

本章要點(diǎn)：知識(shí)目標(biāo)掌握軟件測(cè)試的目的、原則掌握軟件測(cè)試的分類熟悉軟件質(zhì)量保證與軟件測(cè)試掌握軟件測(cè)試的模型技能目標(biāo)掌握軟件測(cè)試過程中模型的應(yīng)用1、軟件測(cè)試的目的軟件測(cè)試的目的決定了如何去組織測(cè)試。如果測(cè)試的目的是為了盡可能多地找出錯(cuò)誤，那么測(cè)試就應(yīng)該直接針對(duì)軟件比較復(fù)雜的部分或是以前出錯(cuò)比較多的位置。如果測(cè)試目的是為了給最終用戶提供具有一定可信度的質(zhì)量評(píng)價(jià)，那么測(cè)試就應(yīng)該直接針對(duì)在實(shí)際應(yīng)用中會(huì)經(jīng)常用到的商業(yè)假設(shè)。不同的機(jī)構(gòu)會(huì)有不同的測(cè)試目的；相同的機(jī)構(gòu)也可能有不同測(cè)試目的，可能是測(cè)試不同區(qū)域或是對(duì)同一區(qū)域的不同層次的測(cè)試。在談到軟件測(cè)試時(shí)，許多人都引用GrenfordJ.Myers在《TheArtofSoftwareTesting》一書中的觀點(diǎn)：①軟件測(cè)試是為了發(fā)現(xiàn)錯(cuò)誤而執(zhí)行程序的過程。②測(cè)試是為了證明程序有錯(cuò)，而不是證明程序無錯(cuò)誤。③一個(gè)好的測(cè)試用例是在于它能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯(cuò)誤。④一個(gè)成功的測(cè)試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯(cuò)誤的測(cè)試。這種觀點(diǎn)可以提醒人們測(cè)試要以查找錯(cuò)誤為中心，而不是為了演示軟件的正確功能

僅憑字面意思理解這一觀點(diǎn)可能會(huì)產(chǎn)生誤導(dǎo)，認(rèn)為發(fā)現(xiàn)錯(cuò)誤是軟件測(cè)試的唯一目的，查找不出錯(cuò)誤的測(cè)試就是沒有價(jià)值的，事實(shí)并非如此。首先，測(cè)試并不僅僅是為了要找出錯(cuò)誤。通過分析錯(cuò)誤產(chǎn)生的原因和錯(cuò)誤的分布特征，可以幫助項(xiàng)目管理者發(fā)現(xiàn)當(dāng)前所采用的軟件過程的缺陷，以便改進(jìn)。同時(shí)，這種分析也能幫助我們?cè)O(shè)計(jì)出有針對(duì)性地檢測(cè)方法，改善測(cè)試的有效性。其次，沒有發(fā)現(xiàn)錯(cuò)誤的測(cè)試也是有價(jià)值的，完整的測(cè)試是評(píng)定測(cè)試質(zhì)量的一種方法。2、軟件測(cè)試的原則基于軟件測(cè)試是為了尋找軟件的錯(cuò)誤與缺陷，評(píng)估與提高軟件質(zhì)量，我們提出一組如下測(cè)試原則：1、所有的軟件測(cè)試都應(yīng)追溯到用戶需求2、應(yīng)當(dāng)把“盡早地和不斷地進(jìn)行軟件測(cè)試”作為軟件測(cè)試者的座右銘3、完全測(cè)試是不可能的，測(cè)試需要終止4、測(cè)試無法顯示軟件潛在的缺陷5、充分注意測(cè)試匯總的群集現(xiàn)象6、程序員應(yīng)避免檢查自己的程序7、盡量避免測(cè)試的隨意性3、軟件測(cè)試的分類軟件測(cè)試的方法和技術(shù)是多種多樣的。對(duì)于軟件測(cè)試技術(shù)，可以從不同的角度加以分類：

從是否需要執(zhí)行被測(cè)軟件的角度，可分為靜態(tài)測(cè)試和動(dòng)態(tài)測(cè)試。

從測(cè)試是否針對(duì)系統(tǒng)的內(nèi)部結(jié)構(gòu)和具體實(shí)現(xiàn)算法的角度來看，可分為白盒測(cè)試和黑盒測(cè)試。

按測(cè)試策略和過程：?jiǎn)卧獪y(cè)試、集成測(cè)試、確認(rèn)測(cè)試、系統(tǒng)測(cè)試、驗(yàn)收測(cè)試。按照實(shí)施組織劃分：開發(fā)方測(cè)試（α測(cè)試）、用戶測(cè)試（β測(cè)試）、第三方測(cè)試。3.1、靜態(tài)測(cè)試顧名思義，靜態(tài)測(cè)試就是通過對(duì)被測(cè)程序的靜態(tài)審查，發(fā)現(xiàn)代碼中潛在的錯(cuò)誤。它一般用人工方式脫機(jī)完成，故亦稱人工測(cè)試或代碼評(píng)審（CodeReview）;也可借助于靜態(tài)分析器在機(jī)器上以自動(dòng)方式進(jìn)行檢查，但不要求程序本身在機(jī)器上運(yùn)行。按照評(píng)審的不同組織形式，代碼評(píng)審又可分為代碼會(huì)審，走查以及辦公桌檢查，同行評(píng)分4種。對(duì)某個(gè)具體的程序，通常只使用一種評(píng)審方式。3.2、動(dòng)態(tài)測(cè)試動(dòng)態(tài)方法是通過源程序運(yùn)行時(shí)體現(xiàn)出來的特征來進(jìn)行跟蹤、時(shí)間分析以及測(cè)試覆蓋等方面的測(cè)試。動(dòng)態(tài)測(cè)試是正在運(yùn)行被測(cè)程序，在執(zhí)行過程中，通過輸入有效的測(cè)試用例對(duì)其輸入與輸出的對(duì)應(yīng)關(guān)系進(jìn)行分析，以達(dá)到檢測(cè)的目的。

在動(dòng)態(tài)測(cè)試中，基于程序結(jié)構(gòu)的是白盒測(cè)試，基于功能的是黑盒測(cè)試。3.3、黑盒測(cè)試黑盒測(cè)試也稱功能測(cè)試或數(shù)據(jù)驅(qū)動(dòng)測(cè)試，它是在已知產(chǎn)品所應(yīng)具有的功能，通過測(cè)試來檢測(cè)每個(gè)功能是否都能正常使用，在測(cè)試時(shí)，把程序看作一個(gè)不能打開的黑盆子，在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，測(cè)試者在程序接口進(jìn)行測(cè)試，它只檢查程序功能是否按照需求規(guī)格說明書的規(guī)定正常使用，程序是否能適當(dāng)?shù)亟邮蛰斎霐?shù)鋸而產(chǎn)生正確的輸出信息，并且保持外部信息（如數(shù)據(jù)庫或文件）的完整性。黑盒測(cè)試方法主要有等價(jià)類劃分、邊值分析、因果圖、錯(cuò)誤推測(cè)等，主要用于軟件確認(rèn)測(cè)試。

3.4、白盒測(cè)試白盒測(cè)試也稱結(jié)構(gòu)測(cè)試或邏輯驅(qū)動(dòng)測(cè)試，它是知道產(chǎn)品內(nèi)部工作過程，可通過測(cè)試來檢測(cè)產(chǎn)品內(nèi)部動(dòng)作是否按照規(guī)格說明書的規(guī)定正常進(jìn)行，按照程序內(nèi)部的結(jié)構(gòu)測(cè)試程序，檢驗(yàn)程序中的每條通路是否都有能按預(yù)定要求正確工作，而不顧它的功能。

白盒測(cè)試的主要方法有邏輯驅(qū)動(dòng)、基路測(cè)試等，主要用于軟件驗(yàn)證。

3.5、單元測(cè)試定義：?jiǎn)卧獪y(cè)試：?jiǎn)卧獪y(cè)試又稱模塊測(cè)試，是針對(duì)軟件設(shè)計(jì)的最小單位－程序模塊進(jìn)行正確性檢驗(yàn)的測(cè)試工作，其目的在于檢查每個(gè)程序單元能否正確實(shí)現(xiàn)詳細(xì)設(shè)計(jì)說明中的模塊功能、性能、接口和設(shè)計(jì)約束等要求，發(fā)現(xiàn)各模塊內(nèi)部可能存在的各種錯(cuò)誤。目標(biāo)：確保各單元模塊被正確地編碼。單元測(cè)試除了保證測(cè)試代碼的功能性，還需要保證代碼在結(jié)構(gòu)上具有可靠性和健全性，并且能夠在所有條件下正確響應(yīng)。進(jìn)行全面的單元測(cè)試，可以減少應(yīng)用級(jí)別所需的工作量，并且徹底減少系統(tǒng)產(chǎn)生錯(cuò)誤的可能性。如果手動(dòng)執(zhí)行，單元測(cè)試可能需要大量的工作，自動(dòng)化測(cè)試會(huì)提高測(cè)試效率。內(nèi)容：?jiǎn)卧獪y(cè)試的主要內(nèi)容有：A.模塊接口測(cè)試；B.局部數(shù)據(jù)結(jié)構(gòu)測(cè)試；C.獨(dú)立路徑測(cè)試；D.錯(cuò)誤處理測(cè)試；E.邊界條件測(cè)試模塊接口測(cè)試中的被測(cè)模塊并不是一個(gè)獨(dú)立的程序，在考慮測(cè)試模塊時(shí)，同時(shí)要考慮它和外界的聯(lián)系，用一些輔助模塊去模擬與被測(cè)模塊相關(guān)聯(lián)的模塊。這些輔助模塊可分為兩種：(1)驅(qū)動(dòng)模塊（driver）：相當(dāng)于被測(cè)模塊的主程序。它接收測(cè)試數(shù)據(jù)，把這些數(shù)據(jù)傳送給被測(cè)模塊，最后輸出實(shí)測(cè)結(jié)果。(2)樁模塊（stub）：用以代替被測(cè)模塊調(diào)用的子模塊。樁模塊可以做少量的數(shù)據(jù)操作，不需要把子模塊所有功能都帶進(jìn)來，但不允許什么事情也不做。3.6、集成測(cè)試定義：集成測(cè)試：集成測(cè)試也叫組裝測(cè)試。通常在單元測(cè)試的基礎(chǔ)上將所有的程序模塊進(jìn)行有序的、遞增的測(cè)試。它分成一次性集成和增殖式集成，增殖式集成又分成自頂向下的增殖方式和自底向上的增值方式。層次：集成測(cè)試內(nèi)部對(duì)于傳統(tǒng)軟件和面向?qū)ο蟮膽?yīng)用系統(tǒng)有兩種層次的劃分。對(duì)于傳統(tǒng)軟件來講，可以把集成測(cè)試劃分為三個(gè)層次：A.模塊內(nèi)集成測(cè)試；B.子系統(tǒng)內(nèi)集成測(cè)試；C.子系統(tǒng)間集成測(cè)試。對(duì)于面向?qū)ο蟮膽?yīng)用系統(tǒng)來說，可以把集成測(cè)試分為兩個(gè)階段：A.類內(nèi)集成測(cè)試；B.類間集成測(cè)試。模式：選擇什么方式把模塊組裝起來形成一個(gè)可運(yùn)行的系統(tǒng)，直接影響到模塊測(cè)試用例的形式、所用測(cè)試工具的類型、模塊編號(hào)的次序和測(cè)試的次序、生成測(cè)試用例的費(fèi)用和調(diào)試的費(fèi)用。通常，把模塊組裝成為系統(tǒng)的測(cè)試方式有兩種：⑴一次性集成測(cè)試方式（No-IncrementalIntegration）一次性集成測(cè)試方式也稱作非增值式集成測(cè)試。先分別測(cè)試每個(gè)模塊，再把所有模塊按設(shè)計(jì)要求放在一起結(jié)合成所需要實(shí)現(xiàn)的程序。⑵增值式集成測(cè)試方式把下一個(gè)要測(cè)試的模塊同已經(jīng)測(cè)好的模塊結(jié)合起來進(jìn)行測(cè)試，測(cè)試完畢，再把下一個(gè)應(yīng)該測(cè)試的模塊結(jié)合進(jìn)來繼續(xù)進(jìn)行測(cè)試。在組裝的過程中邊連接邊測(cè)試，以發(fā)現(xiàn)連接過程中產(chǎn)生的問題。通過增值逐步組裝成為預(yù)先要求的軟件系統(tǒng)。增值式集成測(cè)試方式有三種：A.自頂向下增值測(cè)試方式（Top-downIntegration）B.自底向上增值測(cè)試方式（Bottom-upIntegration）C.混合增值測(cè)試方式（ModifiedTop-downIntegration）

一次性集成方式自頂向下增值測(cè)試方式自底向上增值測(cè)試方式一次性集成測(cè)試方式與增值式集成測(cè)試方式的比較:增值式集成方式需要編寫的軟件較多，工作量較大，花費(fèi)的時(shí)間較多。一次性集成方式的工作量較??；增值式集成方式發(fā)現(xiàn)問題的時(shí)間比一次性集成方式早；增值式集成方式比一次性集成方式更容易判斷出問題的所在，因?yàn)槌霈F(xiàn)的問題往往和最后加進(jìn)來的模塊有關(guān)；增值式集成方式測(cè)試的更為徹底；使用一次性集成方式可以多個(gè)模塊并行測(cè)試。這兩種模式各有利弊，在時(shí)間條件允許的情況下采用增值式集成測(cè)試方式有一定的優(yōu)勢(shì)。組織和實(shí)施:集成測(cè)試是一種正規(guī)測(cè)試過程，必須精心計(jì)劃，并與單元測(cè)試的完成時(shí)間協(xié)調(diào)起來。在制定測(cè)試計(jì)劃時(shí)，應(yīng)考慮如下因素：1.采用何種系統(tǒng)組裝方法來進(jìn)行組裝測(cè)試；2.組裝測(cè)試過程中連接各個(gè)模塊的順序；3.模塊代碼編制和測(cè)試進(jìn)度是否與組裝測(cè)試的順序一致；4.測(cè)試過程中是否需要專門的硬件設(shè)備。3.7、確認(rèn)測(cè)試定義：確認(rèn)測(cè)試最簡(jiǎn)明、最嚴(yán)格的解釋是檢驗(yàn)所開發(fā)的軟件是否能按用戶提出的要求運(yùn)行。若能達(dá)到這一要求，則認(rèn)為開發(fā)的軟件是合格的。因而有的軟件開發(fā)部門把確認(rèn)測(cè)試稱為合格性測(cè)試(QualificationTesting)。確認(rèn)測(cè)試又稱為有效性測(cè)試。它的任務(wù)是驗(yàn)證軟件的功能和性能及其特性是否與客戶的要求一致。對(duì)軟件的功能和性能要求在軟件需求規(guī)格說明中已經(jīng)明確規(guī)定。確認(rèn)測(cè)試的工作：結(jié)果：在全部軟件測(cè)試的測(cè)試用例運(yùn)行完后，所有的測(cè)試結(jié)果可以分為兩類：1、測(cè)試結(jié)果與預(yù)期的結(jié)果相符。說明軟件的這部分功能或性能特征與需求規(guī)格說明書相符合，從而這部分程序被接受；2、測(cè)試結(jié)果與預(yù)期的結(jié)果不符。說明軟件的這部分功能或性能特征與需求規(guī)格說明不一致，因此要為它提交一份問題報(bào)告。通過與用戶的協(xié)商，解決所發(fā)現(xiàn)的缺陷和錯(cuò)誤。確認(rèn)測(cè)試應(yīng)交付的文檔有：確認(rèn)測(cè)試分析報(bào)告、最終的用戶手冊(cè)和操作手冊(cè)、項(xiàng)目開發(fā)總結(jié)報(bào)告。軟件配置審查：軟件配置審查是確認(rèn)測(cè)試過程的重要環(huán)節(jié)。其的目的是保證軟件配置的所有成分都齊全，各方面的質(zhì)量都符合要求，具備維護(hù)階段所必需的細(xì)資料并且已經(jīng)編排好分類的目錄。除了按合同規(guī)定的內(nèi)容和要求，由工人審查軟件配置之外，在確認(rèn)測(cè)試的過程，應(yīng)當(dāng)嚴(yán)格遵守用戶手冊(cè)和操作手冊(cè)中規(guī)定的使用步驟，以便檢查這些文檔資料的完整性和正確性。必須仔細(xì)記錄發(fā)現(xiàn)的遺漏和錯(cuò)誤，并且適當(dāng)?shù)匮a(bǔ)充和改正。3.8、系統(tǒng)測(cè)試系統(tǒng)測(cè)試：將軟件作為基于計(jì)算機(jī)系統(tǒng)的一個(gè)元素，與計(jì)算機(jī)硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其它系統(tǒng)元素結(jié)合在一起，在實(shí)際運(yùn)行（使用）環(huán)境下，對(duì)計(jì)算機(jī)系統(tǒng)進(jìn)行一系列的組裝測(cè)試和確認(rèn)測(cè)試。系統(tǒng)測(cè)試的通過原則包括規(guī)定的測(cè)試用例都已經(jīng)執(zhí)行；BUG都已經(jīng)確認(rèn)修復(fù)；軟件需求說明書中規(guī)定的功能都已經(jīng)實(shí)現(xiàn)；并且測(cè)試結(jié)果都已經(jīng)得到評(píng)估確認(rèn)。工作流程：目標(biāo)1、確保系統(tǒng)測(cè)試的活動(dòng)是按計(jì)劃進(jìn)行的；2、驗(yàn)證軟件產(chǎn)品是否與系統(tǒng)需求用例不相符合或與之矛盾；3、建立完善的系統(tǒng)測(cè)試缺陷記錄跟蹤庫；4、確保軟件系統(tǒng)測(cè)試活動(dòng)及其結(jié)果及時(shí)通知相關(guān)小組和個(gè)人。方針1、為項(xiàng)目指定一個(gè)測(cè)試工程師負(fù)責(zé)貫徹和執(zhí)行系統(tǒng)測(cè)試活動(dòng)；2、測(cè)試組向各事業(yè)部總經(jīng)理/項(xiàng)目經(jīng)理報(bào)告系統(tǒng)測(cè)試的執(zhí)行狀況；3、系統(tǒng)測(cè)試活動(dòng)遵循文檔化的標(biāo)準(zhǔn)和過程；4、向外部用戶提供經(jīng)系統(tǒng)測(cè)試驗(yàn)收通過的項(xiàng)目；5、建立相應(yīng)項(xiàng)目的（BUG）缺陷庫，用于系統(tǒng)測(cè)試階段項(xiàng)目不同生命周期的缺陷記錄和缺陷狀態(tài)跟蹤；6、定期對(duì)系統(tǒng)測(cè)試活動(dòng)及結(jié)果進(jìn)行評(píng)估，向各事業(yè)部經(jīng)理項(xiàng)目辦總監(jiān)/項(xiàng)目經(jīng)理匯報(bào)項(xiàng)目的產(chǎn)品質(zhì)量信息及數(shù)據(jù)。3.9、驗(yàn)收測(cè)試驗(yàn)收測(cè)試：在通過了系統(tǒng)的有效性測(cè)試及軟件配置審查之后，就開始系統(tǒng)的驗(yàn)收測(cè)試，它是以用戶為主的測(cè)試，軟件開發(fā)人員和QA人員應(yīng)參與。在測(cè)試過程中，除了考慮軟件的功能和性能之外，還應(yīng)對(duì)軟件的可移植性、兼容性、可維護(hù)性、錯(cuò)誤的恢復(fù)功能等進(jìn)行確認(rèn)。驗(yàn)收測(cè)試的通過原則包括軟件需求分析說明書中定義的所有功能已全部實(shí)現(xiàn)，性能指標(biāo)全部達(dá)到要求；所有測(cè)試項(xiàng)沒有殘余一級(jí)、二級(jí)和三級(jí)錯(cuò)誤；立項(xiàng)審批表、需求分析文檔、設(shè)計(jì)文檔和編碼實(shí)現(xiàn)一致；驗(yàn)收測(cè)試工件齊全。標(biāo)準(zhǔn)

實(shí)現(xiàn)軟件確認(rèn)要通過一系列黑盒測(cè)試。驗(yàn)收測(cè)試同樣需要制訂測(cè)試計(jì)劃和過程，測(cè)試計(jì)劃應(yīng)規(guī)定測(cè)試的種類和測(cè)試進(jìn)度，測(cè)試過程則定義一些特殊的測(cè)試用例，旨在說明軟件與需求是否一致。無論是計(jì)劃還是過程，都應(yīng)該著重考慮軟件是否滿足合同規(guī)定的所有功能和性能，文檔資料是否完整、準(zhǔn)確，人機(jī)界面和其他方面（例如，可移植性、兼容性、錯(cuò)誤恢復(fù)能力和可維護(hù)性等）是否令用戶滿意。驗(yàn)收測(cè)試的結(jié)果有兩種可能，一種是功能和性能指標(biāo)滿足軟件需求說明的要求，用戶可以接受；另一種是軟件不滿足軟件需求說明的要求，用戶無法接受。如果項(xiàng)目進(jìn)行到這個(gè)階段才發(fā)現(xiàn)有嚴(yán)重錯(cuò)誤和偏差一般很難在預(yù)定的工期內(nèi)改正，因此必須與用戶協(xié)商，尋求一個(gè)妥善解決問題的方法。內(nèi)容軟件驗(yàn)收測(cè)試應(yīng)完成的工作內(nèi)容如下：要明確驗(yàn)收項(xiàng)目，規(guī)定驗(yàn)收測(cè)試通過的標(biāo)準(zhǔn)；確定測(cè)試方法；決定驗(yàn)收測(cè)試的組織機(jī)構(gòu)和可利用的資源；選定測(cè)試結(jié)果分析方法；指定驗(yàn)收測(cè)試計(jì)劃并進(jìn)行評(píng)審；設(shè)計(jì)驗(yàn)收測(cè)試所用的測(cè)試用例；審查驗(yàn)收測(cè)試的準(zhǔn)備工作；執(zhí)行驗(yàn)收測(cè)試；分析測(cè)試結(jié)果；做出驗(yàn)收結(jié)論，明確通過驗(yàn)收或不通過驗(yàn)收，給出測(cè)試結(jié)果。3.10、開發(fā)方測(cè)試、用戶測(cè)試、第三方測(cè)試開發(fā)方測(cè)試（α測(cè)試）：企業(yè)內(nèi)部通過檢測(cè)和提供客觀證據(jù)，證實(shí)軟件的實(shí)現(xiàn)是否滿足規(guī)定的需求。用戶測(cè)試（β測(cè)試）：主要是把軟件產(chǎn)品有計(jì)劃地免費(fèi)分發(fā)到目標(biāo)市場(chǎng)，讓用戶大量使用，并評(píng)價(jià)、檢查軟件。第三方測(cè)試：介于軟件開發(fā)方和用戶方之間的測(cè)試組織的測(cè)試。第三方測(cè)試也稱為獨(dú)立測(cè)試。3.10、其他的常見軟件測(cè)試1、冒煙測(cè)試一個(gè)初始的快速的測(cè)試工作，以決定軟件或者新發(fā)布的版本測(cè)試是否可以執(zhí)行下一步的“正規(guī)”測(cè)試。如果軟件或者新發(fā)布的版本每5分鐘與系統(tǒng)沖突，使系統(tǒng)陷于泥潭，說明該軟件不夠“健全”，目前不具備進(jìn)一步測(cè)試的條件。2、回歸測(cè)試軟件或環(huán)境的修復(fù)或更正后的“再測(cè)試”，自動(dòng)測(cè)試工具對(duì)這類測(cè)試尤其有用。3、性能測(cè)試測(cè)試軟件的運(yùn)行性能。這種測(cè)試常與壓力測(cè)試結(jié)合進(jìn)行，如傳輸連接的最長時(shí)限、傳輸?shù)腻e(cuò)誤率、計(jì)算的精度、記錄的精度、響應(yīng)的時(shí)限和恢復(fù)時(shí)限等。4、負(fù)載測(cè)試測(cè)試軟件在重負(fù)荷下的運(yùn)行表現(xiàn)，系統(tǒng)的響應(yīng)減慢或崩潰。5、壓力測(cè)試測(cè)試系統(tǒng)在某一條件達(dá)到最高限度時(shí)各項(xiàng)功能是否能依舊運(yùn)行。6、可用性測(cè)試測(cè)試用戶是否能夠滿意使用。具體體現(xiàn)為操作是否方便、用戶界面是否友好等。7、安裝/卸載測(cè)試對(duì)軟件的全部、部分、升級(jí)安裝或者卸載處理過程的測(cè)試。8、接受測(cè)試基于客戶或最終用戶的需求的最終測(cè)試，或基于用戶一段時(shí)間的使用后，看軟件是否滿足客戶要求。9、恢復(fù)測(cè)試采用人工的干擾使軟件出錯(cuò)，中斷使用，檢測(cè)系統(tǒng)的恢復(fù)能力。10、安全測(cè)試驗(yàn)證安裝在系統(tǒng)內(nèi)的保護(hù)機(jī)構(gòu)確實(shí)能夠?qū)ο到y(tǒng)進(jìn)行保護(hù)，使之不受各種干擾。11、兼容測(cè)試測(cè)試軟件在多個(gè)硬件、軟件、操作系統(tǒng)、網(wǎng)絡(luò)等環(huán)境下是否能正確運(yùn)行。12、Alpha測(cè)試在公司內(nèi)部系統(tǒng)開發(fā)接近完成時(shí)對(duì)軟件的測(cè)試，測(cè)試后仍然會(huì)有少量的設(shè)計(jì)變更。α測(cè)試時(shí)，開發(fā)者坐在用戶旁邊，隨時(shí)記錄用戶發(fā)現(xiàn)的問題。13、Beta測(cè)試當(dāng)開發(fā)和測(cè)試根本完成時(shí)所做的測(cè)試，而最終的錯(cuò)誤和問題需要在最終發(fā)行前找到。β測(cè)試時(shí)開發(fā)者不在測(cè)試現(xiàn)場(chǎng)，故是在開發(fā)者無法控制的環(huán)境下進(jìn)行的測(cè)試，通常是由軟件開發(fā)者向用戶散發(fā)β版軟件，然后收集用戶的意見。4、軟件質(zhì)量保證與軟件測(cè)試名詞解釋：質(zhì)量：是“反映實(shí)體滿足明確和隱含需要的能力和特性綜合”。因此，質(zhì)量是一種需要，“是一組固有特性滿足要求的程度”。

質(zhì)量管理：質(zhì)量管理是指以組織為質(zhì)量中心、企業(yè)全員參與為基礎(chǔ)，為追求客戶滿意和組織所有受益者滿意而建立和形成的一整套質(zhì)量方針、目標(biāo)和體系。質(zhì)量管理通過質(zhì)量策劃設(shè)定組織的質(zhì)量目標(biāo)，并規(guī)定必要的過程和相關(guān)資源；通過質(zhì)量控制監(jiān)視內(nèi)部質(zhì)量過程，排除質(zhì)量控制過程中可能存在的缺陷隱患；通過質(zhì)量改進(jìn)提高內(nèi)部的質(zhì)量管理能力，改善組織內(nèi)部的質(zhì)量過程；通過質(zhì)量保證提供足夠的信任證據(jù)，表明組織有能力滿足客戶的質(zhì)量要求。

質(zhì)量管理體系：它是質(zhì)量管理的運(yùn)作實(shí)體，由組織結(jié)構(gòu)、程序、過程、資源4個(gè)基本部分組成。

質(zhì)量策劃：它是“確定質(zhì)量以及采用質(zhì)量管理體系要素和要求的活動(dòng)”，包括產(chǎn)品策劃、質(zhì)量管理體系管理和運(yùn)作策劃、編制質(zhì)量計(jì)劃。

質(zhì)量控制：為達(dá)到質(zhì)量要求所采取的作業(yè)技術(shù)和活動(dòng)。質(zhì)量控制的對(duì)象是過程。

質(zhì)量保證：是為了提供足夠的信任證據(jù)，證明組織有關(guān)的各類實(shí)體有能力滿足質(zhì)量要求所實(shí)施并在必要時(shí)進(jìn)行證實(shí)的有計(jì)劃、有系統(tǒng)的活動(dòng)。

質(zhì)量改進(jìn)：是為了向組織的所有受益者提供更多的收益所采用的提高質(zhì)量過程和效率的各種措施。

SQA：從流程和標(biāo)準(zhǔn)上來控制開發(fā)過程，從而提高軟件質(zhì)量。

SQC：通過測(cè)試發(fā)現(xiàn)軟件的問題并確保問題被解決，從而提高軟件質(zhì)量5、如那件測(cè)試過程模型軟件開發(fā)的幾十年中產(chǎn)生了很多的優(yōu)秀模型，比如瀑布模型、螺旋模型、增量模型、迭代模型等，那么軟件測(cè)試又有哪些模型可以指導(dǎo)我們進(jìn)行工作呢？下面我們把一些主要的模型給大家介紹一下。1、V模型V模型是最具有代表意義的測(cè)試模型。它是軟件開發(fā)瀑布模型的變種，它反映了測(cè)試活動(dòng)與分析和設(shè)計(jì)的關(guān)系。V模型問題：A.測(cè)試是開發(fā)之后的一個(gè)階段。B.測(cè)試的對(duì)象就是程序本身。C.實(shí)際應(yīng)用中容易導(dǎo)致需求階段的錯(cuò)誤一直到最后系統(tǒng)測(cè)試階段才被發(fā)現(xiàn)。D.整個(gè)軟件產(chǎn)品的過程質(zhì)量保證完全依賴于開發(fā)人員的能力和對(duì)工作的責(zé)任心，而且上一

步的結(jié)果必須是充分和正確的，如果任何一個(gè)環(huán)節(jié)出了問題，則必將嚴(yán)重的影響整個(gè)工程的質(zhì)量和預(yù)期進(jìn)度。2、W模型W模型由Evolutif公司公司提出，相對(duì)于V模型，