軟件測試基礎(chǔ)、過程和方法

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

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

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

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

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

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

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

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

白盒測試的主要方法有邏輯驅(qū)動、基路測試等，主要用于軟件驗證。

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

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

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

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

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

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

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

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

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

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