軟件測試基礎(chǔ)知識整理

1、精選優(yōu)質(zhì)文檔-傾情為你奉上軟件測試基礎(chǔ)教程測試是軟件生存周期中十分重要的一個過程，是產(chǎn)品發(fā)布、提交給最終用戶前的穩(wěn)定化階段。 一、測試的分類：l 從測試方法的角度分為：（1）手工測試：不使用任何測試工具，根據(jù)事先設(shè)計好的測試用例來運行系統(tǒng)，測試各功能模塊。（2）自動化測試：利用測試工具，通過編寫測試腳本和輸入測試數(shù)據(jù)，自動運行測試程序。目前最常用的自動化測試工具是基于GUI的自動化測試工具，基本原理都是錄制、回放技術(shù)。l 從整體的角度分為：（1）單元測試：是針對軟件設(shè)計的最小單位程序模塊，進行正確性檢驗的測試工作。一般包括邏輯檢查、結(jié)構(gòu)檢查、接口檢查、出錯處理、代碼注釋、輸入校驗、邊界值檢查。

2、單元測試的依據(jù)是系統(tǒng)的詳細設(shè)計；一般由項目組開發(fā)人員自己完成。（2）集成測試：在單元測試的基礎(chǔ)上，將所有模塊按照設(shè)計要求組裝進行測試。一般包括邏輯關(guān)系檢查、數(shù)據(jù)關(guān)系檢查、業(yè)務(wù)關(guān)系檢查、模塊間接口檢查、外部接口檢查。（3）系統(tǒng)測試：系統(tǒng)測試是在所有單元、集成測試后，對系統(tǒng)的功能及性能的總體測試。（4）確認測試：模擬用戶運行的業(yè)務(wù)環(huán)境，運用黑盒測試方法，驗證軟件系統(tǒng)是否滿足用戶需求或軟件需求說明書中指明的軟件特性（功能、非功能）上的。l 從測試原理上分為：（1）白盒測試：是通過程序的源代碼進行測試而不使用用戶界面。這種類型的測試需要從代碼句法發(fā)現(xiàn)內(nèi)部代碼在算法，溢出，路徑，條件等等中的缺點或者錯誤

3、，進而加以修正。（2）黑盒測試：是通過使用整個軟件或某種軟件功能來嚴格地測試， 而并沒有通過檢查程序的源代碼或者很清楚地了解該軟件的源代碼程序具體是怎樣設(shè)計的。測試人員通過輸入他們的數(shù)據(jù)然后看輸出的結(jié)果從而了解軟件怎樣工作。在測試時，把程序看作一個不能打開的黑盆子，在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，測試者在程序接口進行測試，它只檢查程序功能是否按照需求規(guī)格說明書的規(guī)定正常使用，程序是否能適當(dāng)?shù)亟邮蘸驼_的輸出。黑盒測試方法主要有等價類劃分、邊界值分析、因果圖、錯誤推測法。A、等價類劃分：是把所有可能的輸入數(shù)據(jù)，即程序的輸入域劃分成若干部分（子集），然后從每一個子集中選取少數(shù)具有代表性

4、的數(shù)據(jù)作為測試用例。該方法是一種重要的，常用的黑盒測試用例設(shè)計方法。B、邊界值分析：長期的測試工作經(jīng)驗告訴我們，大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上，而不是發(fā)生在輸入輸出范圍的內(nèi)部。因此針對各種邊界情況設(shè)計測試用例，可以查出更多的錯誤。C、錯誤推測法：基于經(jīng)驗和直覺推測程序中所有可能存在的各種錯誤， 從而有針對性的設(shè)計測試用例的方法。錯誤推測方法的基本思想： 列舉出程序中所有可能有的錯誤和容易發(fā)生錯誤的特殊情況，根據(jù)他們選擇測試用例。 例如， 在單元測試時曾列出的許多在模塊中常見的錯誤。 以前產(chǎn)品測試中曾經(jīng)發(fā)現(xiàn)的錯誤等， 這些就是經(jīng)驗的總結(jié)。 還有， 輸入數(shù)據(jù)和輸出數(shù)據(jù)為0的情況。 輸入表

5、格為空格或輸入表格只有一行。 這些都是容易發(fā)生錯誤的情況。 可選擇這些情況下的例子作為測試用例。（3）灰盒測試：灰盒測試就像黑盒測試一樣是通過用戶界面測試，但是測試人員已經(jīng)有所了解該軟件或某種軟件功能的源代碼程序具體是怎樣設(shè)計的。甚至于還讀過部分源代碼。因此測試人員可以有真對性地進行某種確定的條件/功能的測試。 l 從軟件特性上分為功能測試和性能測試。（1）功能測試：是指為了確保軟件系統(tǒng)功能實現(xiàn)的正確性，完整性和其他特性而進行的測試。（2）性能測試：是指為了評估軟件系統(tǒng)的性能狀況，和預(yù)測軟件系統(tǒng)性能趨勢而進行的測試和分析。 二、 項目測試的規(guī)劃l 項目測試分為項目開發(fā)階段測

6、試和項目完工驗收測試兩個部分。l 開發(fā)階段測試內(nèi)容主要包括：模塊功能測試、集成測試和文檔檢查。（1）模塊功能測試：確保系統(tǒng)各功能模塊能夠正常運行，數(shù)據(jù)的IPO符合系統(tǒng)設(shè)計的要求。單元和模塊功能滿足需求定義。（2）集成測試：系統(tǒng)各模塊組裝后，根據(jù)業(yè)務(wù)流程的要求，能夠正確地完成各業(yè)務(wù)功能，并且數(shù)據(jù)的處理和輸出正確。（3）文檔檢查：在項目開發(fā)階段，按照項目進度表，根據(jù)項目文檔測試規(guī)范與標(biāo)準(zhǔn)，對提交的項目文檔和記錄（技術(shù)文檔和管理文檔）進行檢查和驗證，以符合公司質(zhì)量體系和項目制度的要求，對于技術(shù)類文檔的關(guān)鍵要素，驗證是否能夠達到通過標(biāo)準(zhǔn)。l 完工驗收測試內(nèi)容主要包括：安裝測試、功能驗證、性能測試、需求

7、驗證、文檔測試。完工驗收測試實際上是項目在結(jié)項前的一個全面的檢查和驗證?？梢宰鳛轫椖拷Y(jié)項的依據(jù)和放行條件。（1）安裝測試：根據(jù)項目提供的安裝文檔中的安裝步驟，搭建系統(tǒng)運行環(huán)境，檢查系統(tǒng)安裝過程是否正確?？赡馨〝?shù)據(jù)庫服務(wù)器的安裝與配置、應(yīng)用服務(wù)器、控件注冊、客戶端的安裝與配置、應(yīng)用軟件的安裝。（2）功能驗證：按照需求說明書和系統(tǒng)概要設(shè)計，逐項檢查各項功能（功能單元、功能模塊）的可運行性和正確性。（3）性能測試：這部分測試的來源，嚴格來講，取決于用戶對軟件特性的一些特定要求，另外，就是公司的開發(fā)部門對產(chǎn)品的一些基本的性能要求。若用戶從業(yè)務(wù)的角度考慮，對軟件產(chǎn)品本身有特定的非功能要求，則必須在軟件

8、需求說明書中加以說明，使之具有可度量和可測試性。對于一些多用戶環(huán)境或數(shù)據(jù)處理能力和負載方面的測試，很難通過手工搭建測試環(huán)境來測試，所以可以參考使用一些專門的性能測試工具和手工測試相結(jié)合的方式。（4）需求測試：檢查軟件產(chǎn)品是否滿足該項目的需求說明書中規(guī)定的功能需求，檢查需求的完整性、一致性、最新性，該項測試重點是需求滿足的完整性。（5）文檔測試：文檔測試從項目立項時就開始了，實際上就是文檔檢查，包括規(guī)范性檢查和有效性檢查。目的是使項目相關(guān)的文檔和記錄既規(guī)范又有意義，不是為了應(yīng)付的無用文件。對于技術(shù)文檔如：需求說明書、概要設(shè)計、詳細設(shè)計等，在技術(shù)評審時也進行了評測。用戶文檔，如安裝手冊、用戶操作手

9、冊，根據(jù)文檔檢查規(guī)范進行。l 項目測試的基本流程：（1）項目測試啟動：項目立項后，在測試配置庫中創(chuàng)建項目。（2） 測試計劃：系統(tǒng)詳細設(shè)計后，制定測試計劃，準(zhǔn)備測試資源。（3） 設(shè)計測試用例，主要是與業(yè)務(wù)相關(guān)的測試用例。（4）實施功能模塊測試，搭建運行或開發(fā)環(huán)境，采用功能模塊測試表的方式，開發(fā)人員在功能模塊測試表中更新進度狀態(tài)，測試人員在該表中描述測試進度。形成測試錯誤列表，該表對每個錯誤都有相應(yīng)的測試記錄與之鏈接，在測試記錄中，詳細描述錯誤的情況。在測試記錄中還要包括修正信息和驗證信息。（5）錯誤關(guān)閉后，測試人員維護測試記錄表和更新測試用例庫和問題庫，作為經(jīng)驗積累。（6）項目在結(jié)項時，測試人員

10、進行項目完工驗收測試，填寫項目測試報告。該測試報告可作為用戶驗收的輸入工件。三、Bug管理的流程和幾個重點 .軟件測試的主要目的在于發(fā)現(xiàn)軟件存在的錯誤(Bug)，對于如何處理測試中發(fā)現(xiàn)的錯誤， 將直接影響到測試的效果。只有正確、迅速、準(zhǔn)確地處理這些錯誤，才能消除軟件錯誤，保證 要發(fā)布的軟件符合需求設(shè)計的目標(biāo)。在實際軟件測試過程中，對于每個Bug都要經(jīng)過測試、確認、修復(fù)、驗證等的管理過程，這是軟件測試的重要環(huán)節(jié)。錯誤跟蹤管理系統(tǒng)為了正確跟蹤每個軟件錯誤的處理過程，通常將軟件測試發(fā)現(xiàn)的每個錯誤作為一條條記錄輸入制定的錯誤跟蹤管理系統(tǒng)。目前已有的缺陷跟蹤管理軟件包括Compuware公司的Track

11、Record軟件（商業(yè)軟件）、 Mozilla公司的Buzilla軟件（免費軟件），以及國內(nèi)的微創(chuàng)公司的BMS軟件，這些軟件在功能上各有特點，可以根據(jù)實際情況選用。當(dāng)然，也可以自己開發(fā)缺陷跟蹤軟件，例如基于Notes 或是ClearQuese開發(fā)缺陷跟蹤管理軟件。作為一個缺陷跟蹤管理系統(tǒng)，需要正確設(shè)計每個錯誤的包含信息的字段內(nèi)容和記錄錯誤的處理信息的全部內(nèi)容。字段內(nèi)容可能包括測試軟件名稱，測試版本號，測試人名稱，測試事件，測試軟件和硬件配置環(huán)境，發(fā)現(xiàn)軟件錯誤的類型，錯誤的嚴重等級，詳細步驟，必要的附圖，測試注釋。處理信息包括處理者姓名，處理時間，處理步驟，錯誤記錄的當(dāng)前狀態(tài)。正確的數(shù)據(jù)庫權(quán)限管

12、理是錯誤跟蹤管理系統(tǒng)的重要考慮要素，一般要保證對于添加的錯誤不能從數(shù)據(jù)庫中刪除。l 軟件錯誤的狀態(tài)第一種：a) 新信息(New)：測試中新報告的軟件缺陷；b) 打開(Open)：被確認并分配給相關(guān)開發(fā)人員處理；c) 修正(Fixed)：開發(fā)人員已完成修正，等待測試人員驗證；d) 拒絕(Declined)：拒絕修改缺陷；e) 延期(Deferred)：不在當(dāng)前版本修復(fù)的錯誤，下一版修復(fù)f) 關(guān)閉(Closed)：錯誤已被修復(fù)；另一種：a) 新信息(New)：測試中新報告的軟件缺陷；b) 打開(Open)：被確認并分配給相關(guān)開發(fā)人員處理；c) 處理完畢提交（Resolve）d) Activate(

13、激活) 或REOPEN(重新打開)：如果Tester不同意該Bug的解法，則可激活。該Bug會自動被指派給當(dāng)初解決(Resolve) 的同事，當(dāng)然你在激活的時候應(yīng)該寫上為什么你這么做，讓別人明白你激活它是由道理的。e) 關(guān)閉(Closed)：錯誤已被修復(fù)；l 一個Bug有7種解法：1. By Design - 就是這么設(shè)計的，無效的Bug2. Duplicate - 這個問題別人已經(jīng)發(fā)現(xiàn)了，重復(fù)的Bug3. External - 是個外部因素(比如瀏覽器、操作系統(tǒng)、其他第3方軟件)造成的問題4. Fixed - 問題被修理掉了。Tester要盡可能找到這種Bug5. Not Repro - 無

14、法復(fù)現(xiàn)你這個問題，無效的Bug6. Postponed - 是個問題，但是目前不必修理了，推遲到以后再解7. Won't Fix - 是個問題，但是不值得修理了，不管它吧l Bug管理的一般流程1. 測試人員提交新的Bug入庫，錯誤狀態(tài)為New。2. 高級測試人員驗證錯誤，如果確認是錯誤，分配給相應(yīng)的開發(fā)人員，設(shè)置狀態(tài)為Open。如果不是錯誤，則拒絕，設(shè)置為Declined狀態(tài)。3. 開發(fā)人員查詢狀態(tài)為Open的Bug，如果不是錯誤，則置狀態(tài)為Declined；如果是Bug則修復(fù) 并置狀態(tài)為Fixed。不能解決的Bug，要留下文字說明及保持Bug為Open狀態(tài)。4. 對于不能解決和延期

15、解決的Bug，不能由開發(fā)人員自己決定，一般要通過某種會議（評審 會）通過才能認可。5. 測試人員查詢狀態(tài)為Fixed的Bug，然后驗證Bug是否已解決，如解決置Bug的狀態(tài)為 Closed，如沒有解決置狀態(tài)為Reopen。l 流程雖然簡單，但是在實際使用中還是發(fā)現(xiàn)一些問題：1.bug信息不全：有的信息，比如項目，模塊，指定處理人（也就是指派給誰處理）等，這些信息會用來作統(tǒng)計分析，哪個項目，哪個模塊，誰的bug多，誰發(fā)現(xiàn)的bug多，誰改的bug多等，根據(jù)這些信息可以大致看出一個人的工作量和工作質(zhì)量。所以不要嫌麻煩，把bug的信息寫全些。2.所提供的信息不準(zhǔn)確：有的bug描述一帶而過，表述含糊不清

16、，只是說出現(xiàn)了錯誤，但是錯誤的現(xiàn)象是什么，提示信息是什么，怎么操作才出現(xiàn)的，都不清楚，這樣的bug交給開發(fā)人員，只會給開發(fā)人員增加負擔(dān)，因為他自己還要再作測試，以發(fā)現(xiàn)更多的信息，去排除bug，或者他會到測試那邊其討論，詢問詳情，有時要多次反饋才能確定到底是什么問題。3.開發(fā)人員關(guān)閉bug：只有bug的提交人（也就是發(fā)現(xiàn)人）才能去關(guān)閉該bug，開發(fā)人員只能使用兩個狀態(tài)：“處理中”和“已修正”4.bug的可重現(xiàn)性：這個重要的屬性是在bug管理軟件中無法體現(xiàn)和度量的， 這個任務(wù)主要都在測試這邊，如果你發(fā)現(xiàn)了一個bug，趕緊把開發(fā)人員叫過來，人家來了，你要給他看看這個bug，可是卻怎么也不出現(xiàn)了，連自己都不知道這個bug是怎樣操作后才出現(xiàn)的。這樣不能重現(xiàn)的bug幾乎就不能算作bug，也是最讓人頭疼的問題。那么作為測試人員，你的任務(wù)就是要盡可能的找到bug出現(xiàn)的規(guī)律，嘗試各種可能，即使不能重現(xiàn)，起碼也要讓開發(fā)人員知道你已經(jīng)作了哪些嘗試，而他不必再去走彎路。l 軟件錯誤流程管理要