軟件測試筆試題目總結(jié)

時(shí)間：2021-06-17 13:09:36 筆試題目我要投稿

軟件測試年終總結(jié) 推薦度：
軟件測試總結(jié)報(bào)告推薦度：
軟件測試經(jīng)理年終總結(jié) 推薦度：
軟件測試工作總結(jié) 推薦度：
軟件測試年終工作總結(jié) 推薦度：
相關(guān)推薦

2017軟件測試筆試題目總結(jié)

　　接下來CN人才網(wǎng)小編為大家?guī)淼氖?017軟件測試筆試題目總結(jié)，歡迎大家閱讀借鑒。

2017軟件測試筆試題目總結(jié)

　　1.什么是軟件測試?

　　軟件測試是為了發(fā)現(xiàn)錯(cuò)誤而執(zhí)行程序的過程�；蛘哒f，軟件測試是根據(jù)軟件開發(fā)各階段的規(guī)格說明和程序內(nèi)部結(jié)構(gòu)而精心設(shè)計(jì)的一批測試用例(即輸入數(shù)據(jù)及其預(yù)期的輸出結(jié)果)，并用這些測試用例去運(yùn)行程序，以發(fā)現(xiàn)程序錯(cuò)誤的過程。

　　2.軟件測試的目的?

　　軟件測試的目的是想以最少的人力、物力和時(shí)間找出軟件中潛在的各種錯(cuò)誤和缺陷，通過修正錯(cuò)誤和缺陷提高軟件質(zhì)量，回避軟件發(fā)布后由于潛在的軟件缺陷和錯(cuò)誤造成的隱患帶來的商業(yè)風(fēng)險(xiǎn)。

　　3.需求文檔測試：

　　主要測試需求中是否存在邏輯矛盾以及需求在技術(shù)上是否可以實(shí)現(xiàn)。

　　4.設(shè)計(jì)文檔測試

　　測試設(shè)計(jì)是否符合全部需求以及設(shè)計(jì)是否合理

　　5.白盒測試

　　又稱為邏輯驅(qū)動(dòng)測試，，他是知道產(chǎn)品內(nèi)部工作過程，可通過測試來檢驗(yàn)產(chǎn)品內(nèi)部動(dòng)作是否按照規(guī)格說明書的規(guī)定正常進(jìn)行，按照程序內(nèi)部的結(jié)構(gòu)測試程序，檢驗(yàn)程序的每條通路是否都能按預(yù)期要求正常工作，而不顧他的功能，白盒測試的主要方法是邏輯驅(qū)動(dòng)、基路測試等，主要用于軟件驗(yàn)證。

　　6.白盒測試的方法有哪幾種?

　　白盒測試也稱為結(jié)構(gòu)測試或者邏輯驅(qū)動(dòng)測試，他是想知道程序產(chǎn)品內(nèi)部工作過程，可通過測試來檢測產(chǎn)品內(nèi)部動(dòng)作是否按照規(guī)格說明書的規(guī)定正常進(jìn)行，按照程序內(nèi)部的結(jié)構(gòu)測試程序，檢驗(yàn)程序的每條通路是否都能按預(yù)期要求正常工作，而不顧他的功能，白盒測試的主要方法有邏輯驅(qū)動(dòng)測試，基路測試等，主要用于軟件驗(yàn)證。“白盒”法是程序窮舉路徑測試。

　　對(duì)開發(fā)語言的支持：白盒測試工具是對(duì)源代碼進(jìn)行的測試，測試的主要內(nèi)容包括詞法分析和語法分析、靜態(tài)錯(cuò)誤分析、動(dòng)態(tài)監(jiān)測等。目前測試工具主要支持的開發(fā)語言包括：標(biāo)準(zhǔn)C,C++,Visual C++,Java,Visual J++等。

　　7.黑盒測試

　　已知產(chǎn)品的功能設(shè)計(jì)規(guī)格，可以進(jìn)行測試證明每個(gè)實(shí)現(xiàn)了的功能是否符合要求。它意味著測試要在軟件測試的接口處進(jìn)行。這種方法是把測試對(duì)象看成一個(gè)黑盒子，測試人員完全不考慮程序的邏輯結(jié)構(gòu)和內(nèi)部特征，只依據(jù)程序的需求規(guī)格說明書，檢查程序的功能是否符合他的功能說明書。因此黑盒測試又叫功能測試或數(shù)據(jù)驅(qū)動(dòng)測試。

　　8.如果能夠執(zhí)行完美的黑盒測試，還需要進(jìn)行白盒測試嗎?(白盒與黑盒的區(qū)別)

　　任何工程產(chǎn)品(注意是任何工程產(chǎn)品)都可以使用一下兩種方法之一進(jìn)行測試。

　　黑盒測試：一直產(chǎn)品的功能設(shè)計(jì)規(guī)格，可以進(jìn)行測試證明每個(gè)實(shí)現(xiàn)了的功能是否符合要求。白盒測試：一直產(chǎn)品的內(nèi)部工作過程，可以通過測試證明每種內(nèi)部操作是否符合設(shè)計(jì)規(guī)格要求，所有內(nèi)部成分是否以經(jīng)過檢查。

　　軟件的黑盒測試意味著測試要在軟件的接口處進(jìn)行。這種方法是把測試對(duì)象看做一個(gè)黑盒子，測試人員程序內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程序內(nèi)部的需求規(guī)格說明書，檢查程序的功能是否符合他的功能說明書。因此黑盒測試又叫功能測試或數(shù)據(jù)驅(qū)動(dòng)測試。黑盒測試主要是為了發(fā)現(xiàn)以下幾類錯(cuò)誤：

　　1)是否有不正確或者遺漏的功能?

　　2)在接口上輸入是否能正確的接受?能否輸出正確的結(jié)果?

　　3)是否有數(shù)據(jù)結(jié)構(gòu)錯(cuò)誤或外部信息(例如數(shù)據(jù)文件)訪問錯(cuò)誤?

　　4)性能上是否能夠滿足要求?

　　5)是否有初始化或者終止性錯(cuò)誤?

　　軟件的白盒測試是對(duì)軟件的過程細(xì)節(jié)做細(xì)致的檢查。這種方法是把測試對(duì)象看做一個(gè)打開的盒子，他允許測試人員利用程序內(nèi)部的邏輯結(jié)構(gòu)以及有關(guān)信息，設(shè)計(jì)或選擇測試用例，對(duì)程序所有程序路徑進(jìn)行測試。通過在不同點(diǎn)檢查程序狀態(tài)，確定實(shí)際狀態(tài)是否與預(yù)期狀態(tài)一致。因此白盒測試主要是相對(duì)程序模塊進(jìn)行如下檢查：

　　1)對(duì)程序模塊的所有獨(dú)立的執(zhí)行路徑至少測試一遍

　　2)對(duì)所有的邏輯判定，取“真”與取“假”的兩種情況至少都測試一遍。

　　3)在循環(huán)的邊界和運(yùn)行的界限內(nèi)執(zhí)行循環(huán)體。

　　4)測試內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性，等等

　　以上事實(shí)說明，軟件測試有一個(gè)致命的缺陷，即測試的不完全、不徹底性。由于任何程序只能進(jìn)行少量(相對(duì)于窮舉的巨大數(shù)量而言)的有限的測試，在為發(fā)現(xiàn)錯(cuò)誤時(shí)，不能說明程序沒有錯(cuò)誤。

　　9.回歸測試

　　回歸測試的目的是在程序有修改的情況下，保證原有功能正常的一種測試策略和方法。說白了就是，我們測試人員在對(duì)程序進(jìn)行測試時(shí)發(fā)現(xiàn)bug，然后返還程序員修改，程序員修改后發(fā)布新的軟件包或新的軟件補(bǔ)丁包給我們測試人員，我們就要重新對(duì)這個(gè)程序進(jìn)行測試，已保證程序在修正了以前的bug的情況下，正常運(yùn)行，且不會(huì)帶來新的錯(cuò)誤的這樣一個(gè)過程。一般情況下是不需要進(jìn)行全面測試的，而是根據(jù)修改的情況進(jìn)行有效的測試。

　　10.驗(yàn)收測試的兩種

　　Alpha測試：是由用戶在開發(fā)環(huán)境下進(jìn)行的測試，也可以是在公司內(nèi)部的用戶在模擬實(shí)際操作環(huán)境下進(jìn)行的受控測試，Alpha測試發(fā)現(xiàn)的錯(cuò)誤，可以在測試現(xiàn)場立刻反饋給開發(fā)人員，由開發(fā)人員及時(shí)分析和處理，目的是評(píng)價(jià)軟件的功能、可使用性、可靠性、性能和支持。尤其注重產(chǎn)品的界面和特色。Alpha測試可以從軟件產(chǎn)品編碼結(jié)束之后開始，也可以在確認(rèn)測試過程中產(chǎn)品達(dá)到一定的穩(wěn)定和可靠程度再開始。有關(guān)的手冊(cè)(草稿)等應(yīng)該在Alpha測試前準(zhǔn)備好。

　　Bate測試：是軟件的多用戶在一個(gè)或多個(gè)用戶的實(shí)際使用環(huán)境下進(jìn)行的測試。開發(fā)者通常不在測試現(xiàn)場，Bate測試不能由程序員或測試員完成。因而，Bate測試是在開發(fā)者無法控制的環(huán)境下進(jìn)行的軟件現(xiàn)場應(yīng)用。在Bate測試中，由用戶記下遇到的所有問題，包括真實(shí)的以及主管的認(rèn)定，定期向開發(fā)者報(bào)告，開發(fā)者在綜合用戶的報(bào)告后，做出修改，最后將軟件產(chǎn)品交付給全體用戶使用。Bate測試著重于產(chǎn)品的支持性，包括文檔、客戶培訓(xùn)和支持產(chǎn)品的生產(chǎn)能力。只有Alpha測試達(dá)到一定的可靠程度后才能開始Bate測試。由于Bate測試的`主要目標(biāo)是測試可支持性，所以Bate測試應(yīng)該盡可能由主持產(chǎn)品發(fā)行的人員來管理。

　　11.軟件測試的缺陷等級(jí)應(yīng)如何劃分

　　1)致命錯(cuò)誤，可能導(dǎo)致本模塊以及其他相關(guān)模塊異常，死機(jī)等問題。

　　2)嚴(yán)重錯(cuò)誤，問題局限在本模塊，導(dǎo)致模塊功能失效或異常退出

　　3)一般錯(cuò)誤，模塊功能部分失效

　　4)建議問題，有問題提出人對(duì)測試對(duì)象的改進(jìn)意見

　　12.軟件測試應(yīng)該劃分幾個(gè)階段?簡述各個(gè)階段應(yīng)重點(diǎn)測試的點(diǎn)?各階段的含義?

　　大體上來說可分為單元測試，集成測試，系統(tǒng)測試，驗(yàn)收測試，每個(gè)階段又分為以下五個(gè)步驟：測試計(jì)劃，測試設(shè)計(jì)，用例設(shè)計(jì)，執(zhí)行結(jié)果，測試報(bào)告。

　　初始測試集中在每個(gè)模塊上，保證源代碼的正確性，該階段成為單元測試，主要用白盒測試的方法。接下來是模塊集成和集成以便組成完整的軟件包。集成測試集中在證實(shí)和程序結(jié)構(gòu)成問題上。主要采用黑盒測試的方法，輔之以白盒測試方法。

　　軟件集成后，需要完成確認(rèn)和系統(tǒng)測試。確認(rèn)測試提供軟件滿足所有的功能、性能需求的最后保證。確認(rèn)測試僅僅應(yīng)用黑盒測試的方法。

　　13.驅(qū)動(dòng)模塊和樁模塊

　　驅(qū)動(dòng)模塊：大多數(shù)場合稱為“主程序”，他接收測試數(shù)據(jù)并將這些數(shù)據(jù)傳遞到被測試模塊，單元測試一個(gè)函數(shù)單元時(shí)，被測單元本身是不能獨(dú)立運(yùn)行的，需要為其傳送數(shù)據(jù)，為此寫驅(qū)動(dòng)

　　驅(qū)動(dòng)模塊主要完成以下事情：

　　1)接收測試輸入

　　2)對(duì)輸入進(jìn)行判斷

　　3)將輸入傳給被測單元，驅(qū)動(dòng)被測單元執(zhí)行;

　　4)接受被測單元的執(zhí)行結(jié)果，并對(duì)結(jié)果進(jìn)行判定

　　5)將判斷結(jié)果作為用例執(zhí)行結(jié)果輸出測試報(bào)告

　　樁模塊：比如對(duì)函數(shù)A做單元測試的時(shí)候，被測的函數(shù)單元下還包括了也函數(shù)B，為了更好地定位錯(cuò)誤，就要為B寫樁，來模擬函數(shù)B的功能，保證其正確性。

　　14.各種測試所針對(duì)的問題

　　1)單元測試：是對(duì)軟件中的基本組成單位進(jìn)行的測試，如一個(gè)模塊、一個(gè)過程等等。他是軟件動(dòng)態(tài)測試的最基本部分，也是最重要的部分之一，其目的是檢驗(yàn)軟件基本組成單位的正確性。

　　2)集成測試：是在軟件系統(tǒng)集成過程中所進(jìn)行的測試，其主要目的是檢查軟件單位之間的接口是否正確。

　　3)系統(tǒng)測試：系統(tǒng)測試是對(duì)已經(jīng)集成好的軟件系統(tǒng)進(jìn)行徹底的測試，已驗(yàn)證軟件系統(tǒng)的正確性和性能等滿足其規(guī)約所指定的要求，檢查軟件的行為和輸出是否正確并非一項(xiàng)簡單的任務(wù)，他被稱為測試的“先知者問題”。

　　4)驗(yàn)收測試：驗(yàn)收測試旨在向軟件的購買者展示該軟件系統(tǒng)滿足其用戶需求。他的測試數(shù)據(jù)通常是系統(tǒng)測試的測試數(shù)據(jù)的子集。

　　5)回歸測試：是在軟件維護(hù)階段，對(duì)軟件進(jìn)行修改之后進(jìn)行的測試。其目的是檢驗(yàn)對(duì)軟件進(jìn)行的修改是否正確。

　　15.針對(duì)缺陷采取怎樣的管理措施?

　　1)要更好的管理缺陷，必須引入缺陷管理工具，商用的或者開源的都可以。

　　2)根據(jù)缺陷的生命周期，考慮缺陷提交的管理、缺陷狀態(tài)的管理和缺陷分析的管理。

　　3)所有發(fā)現(xiàn)的缺陷(不管是測試發(fā)現(xiàn)的還是走讀代碼發(fā)現(xiàn)的)都必須全部及時(shí)的、準(zhǔn)確的提交到缺陷管理工具中。

　　4)缺陷提交后，需要及時(shí)的指派給相應(yīng)的開發(fā)人員，提交缺陷的人需要密切注意缺陷的狀態(tài)，幫助缺陷盡快解決。缺陷解決后需要及時(shí)對(duì)缺陷的修復(fù)進(jìn)行驗(yàn)證。這樣的目的有兩個(gè)：一個(gè)是讓缺陷盡快解決;二是方便后面缺陷的分析(保證缺陷相關(guān)的信息準(zhǔn)確，如齡期等)。

　　5)為了更好地改進(jìn)開發(fā)過程和測試過程，需要對(duì)缺陷進(jìn)行分析，總結(jié)如缺陷的類別、缺陷的齡期分布等信息，這是缺陷分析的管理。

　　16.單元測試、集成測試、系統(tǒng)測試的側(cè)重點(diǎn)是什么?

　　單元測試是在軟件開發(fā)過程中要進(jìn)行的最低級(jí)別的測試活動(dòng)，在單元測試活動(dòng)中，軟件的獨(dú)立單元將在與程序的其他部分相隔離的情況下進(jìn)行測試，測試的重點(diǎn)是系統(tǒng)的模塊，包括子程序的正確性驗(yàn)證等。

　　集成測試也叫組裝測試或聯(lián)合測試，在單元測試的基礎(chǔ)上，將所有模塊按照設(shè)計(jì)要求，組裝成為子系統(tǒng)或者系統(tǒng)，進(jìn)行集成測試。實(shí)踐表明，一些模塊雖然能夠單獨(dú)的工作，但并不能保證連接起來也能正常的工作。程序在某些局部反應(yīng)不出來的問題，在全局上很可能暴露出來，影響功能的實(shí)現(xiàn)。測試的重點(diǎn)是模塊間的銜接以及參數(shù)的傳遞等。

　　系統(tǒng)測試是將經(jīng)過測試的子系統(tǒng)裝配成一個(gè)完整的系統(tǒng)來測試，他是檢驗(yàn)系統(tǒng)是否確實(shí)能提供系統(tǒng)方案說明書中指定功能的有效方法。測試重點(diǎn)是整個(gè)系統(tǒng)的運(yùn)行以及與其他軟件的兼容性。

　　17.測試用例的方法、依據(jù)有哪些?

　　白盒測試用例設(shè)計(jì)有如下方法：基本路徑測試、等價(jià)類劃分、邊界值分析、覆蓋測試、循環(huán)測試、數(shù)據(jù)流測試、程序插樁測試、變異測試，這時(shí)候一句就是詳細(xì)設(shè)計(jì)說明書及其代碼結(jié)構(gòu)

　　黑盒測試用例設(shè)計(jì)方法：基于用戶需求的測試、功能圖分析方法、等價(jià)類劃分方法、邊界值分析方法、錯(cuò)誤推測方法、因果圖方法、判定表驅(qū)動(dòng)分析方法、正交試驗(yàn)分析方法。依據(jù)是用戶需求規(guī)格說明書，詳細(xì)設(shè)計(jì)說明書。

　　18.測試用例通常包含哪些內(nèi)容?(著重闡釋編制測試用例的具體做法不同結(jié)構(gòu)的用例包括的不一樣(版本、編號(hào)、項(xiàng)目、設(shè)計(jì)人員、設(shè)計(jì)日期、輸入、預(yù)期輸出。。。))

　　軟件測試用例的基本要素包括測試用例的編號(hào)、測試標(biāo)題、重要級(jí)別、測試輸入、操作步驟、預(yù)期結(jié)果。

　　用例編號(hào)：測試用例的編號(hào)有一定的規(guī)則，比如系統(tǒng)測試用例的編號(hào)這樣定義規(guī)則：

　　PROJECT1-ST-001，命名規(guī)則是項(xiàng)目名稱+測試階段類型(系統(tǒng)測試階段)+編號(hào)。定義測試用例編號(hào)，便于查找測試用例的跟蹤。

　　測試標(biāo)題：對(duì)測試用例的描述，測試用例標(biāo)題應(yīng)該清楚表達(dá)測試用例的用途。比如：“測試用戶登錄時(shí)輸入錯(cuò)誤密碼時(shí)，軟件的響應(yīng)情況”。重要級(jí)別：定義測試用例的優(yōu)先級(jí)別，可以籠統(tǒng)的分為“高”和“低”兩個(gè)級(jí)別。一般來說，如果軟件的優(yōu)先級(jí)別為“高”;反之亦然，測試輸入：提供測試執(zhí)行中的各種輸入條件。根據(jù)需求中的輸入條件，確定測試用例的輸入。測試用例的輸入對(duì)軟件需求當(dāng)中的輸入有很大的依賴性，如果軟件需求中沒有很好地定義需求的輸入，那么測試用例設(shè)計(jì)中將會(huì)遇到很大的障礙。

　　操作步驟：提供測試執(zhí)行過程的步驟。對(duì)于復(fù)雜的測試用例，測試用例的輸入需要分為幾個(gè)步驟完成，這部分內(nèi)容在操作步驟中詳細(xì)列出。

　　預(yù)期結(jié)果：提供測試執(zhí)行的預(yù)期結(jié)果，預(yù)期結(jié)果應(yīng)該根據(jù)軟件需求中的輸出得出。如果在實(shí)際測試過程中，得到的實(shí)際測試結(jié)果與預(yù)期結(jié)果不符，那么測試不通過;反之測試通過。

　　用例編號(hào)

　　19.描述使用bugzilla缺陷管理工具對(duì)軟件缺陷(BUG)跟蹤的管理流程

　　1)測試人員或開發(fā)人員發(fā)現(xiàn)bug之后，判斷屬于哪個(gè)模塊的問題，填寫B(tài)ug報(bào)告后，系統(tǒng)會(huì)自動(dòng)通過Email通知項(xiàng)目組長或直接通知開發(fā)者

　　2)驗(yàn)證無誤后，修改狀態(tài)為VERIFIED，待整個(gè)產(chǎn)品發(fā)布后，修改為CLOSED。

　　3)還有個(gè)問題，REOPENED，狀態(tài)重新改變?yōu)?ldquo;New”，并發(fā)郵件通知。

　　4)項(xiàng)目組長根據(jù)具體情況，重新reassigned分配給bug所屬的開發(fā)者。

　　5)若是，進(jìn)行處理，resolved并給出解決方法。(可創(chuàng)建補(bǔ)丁附件及補(bǔ)充說明)

　　6)開發(fā)者收到Email信息后，判斷是否為自己的修改范圍

　　7)若不是，重新reassigned分配給項(xiàng)目組長或應(yīng)該分配的開發(fā)人員。

　　8)測試人員查詢開發(fā)者已修改的bug，進(jìn)行重新測試。