軟件測(cè)試基礎(chǔ)知識(shí)整理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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