軟件測試筆試題2015

　　什么是軟件測試?

　　軟件測試是為了發(fā)現錯誤而執行程序的過(guò)程�；蛘哒f(shuō)，軟件測試是根據軟件開(kāi)發(fā)各階段的規格說(shuō)明和程序的內部結構而精心設計一批測試用例(即輸入數據及其預期的輸出結果)，并利用這些測試用例去運行程序，以發(fā)現程序錯誤的過(guò)程。

　　軟件測試的目的?

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

　　需求文檔測試：

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

　　設計文檔測試：

　　測試設計是否符合全部需求以及設計是否合理。

　　α測試:

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

　　β測試

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

　　驅動(dòng)模塊:

　　驅動(dòng)模塊在大多數場(chǎng)合稱(chēng)為"主程序"，它接收測試數據并將這些數據傳遞到被測試模塊.單元測試一個(gè)函數單元時(shí)，被測單元本身是不能獨立運行的，需要為其傳送數據，為此 寫(xiě)驅動(dòng)

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

　　1、接受測試輸入;

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

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

　　4、接受被測單元執行結果，并對結果進(jìn)行判斷;

　　5、將判斷結果作為用例執行結果輸出測試報告。

　　樁模塊

　　比如對函數A做單元測試時(shí)，被測的函數單元下還包括了一個(gè)函數B，為了更好的錯誤，定位錯誤，就要為函數B寫(xiě)樁，來(lái)模擬函數B的功能，保證其正確。

　　白盒測試

　　白盒測試(White-box Testing，又稱(chēng)邏輯驅動(dòng)測試,結構測試),它是知道產(chǎn)品內部工作過(guò)程，可通過(guò)測試來(lái)檢測產(chǎn)品內部動(dòng)作是否按照規格說(shuō)明書(shū)的規定正常進(jìn)行，按照程序內部的結構測試程序，檢驗程序中的每條通路是否都有能按預定要求正確工作，而不顧它的功能，白盒測試的主要方法有邏輯驅動(dòng)、基路測試等，主要用于軟件驗證。

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

　　靜態(tài)測試

　　動(dòng)態(tài)通過(guò)評審文檔、閱讀代碼等方式測試軟件稱(chēng)為靜態(tài)測試,通過(guò)運行程序測試軟件稱(chēng)為測試.在動(dòng)態(tài)測試中,通常使用白盒測試和黑盒測試從不同的角度設計測試用例,查找軟件代碼中的錯誤.

　　回歸測試

　　回歸測試的目的是在程序有修改的情況下，保證原有功能正常的一種測試策略和方法。

　　說(shuō)白了就是，我們測試人員在對程序進(jìn)行測試時(shí)發(fā)現bug，然后返還程序員修改，程序員修改后發(fā)布新的軟件包或新的軟件補丁包給我們測試人員，我們就要重新對這個(gè)程序測試，已保證程序在修正了以前bug的情況下，正常運行，且不會(huì )帶來(lái)新的錯誤的這樣一個(gè)過(guò)程。 一般情況下是不需要全面測試的，而是根據修改的情況進(jìn)行有效的測試。

　　白盒測試有哪幾種方法?

　　白盒測試也稱(chēng)結構測試或邏輯驅動(dòng)測試，它是知道產(chǎn)品內部工作過(guò)程，可通過(guò)測試來(lái)檢測產(chǎn)品內部動(dòng)作是否按照規格說(shuō)明書(shū)的規定正常進(jìn)行，按照程序內部的結構測試程序，檢驗程序中的每條通路是否都有能按預定要求正確工作，而不顧它的功能，白盒測試的主要方法有邏輯驅動(dòng)、基路測試等，主要用于軟件驗證�！鞍缀小狈ㄈ�面了解程序內部邏輯結構、對所有邏輯路徑進(jìn)行測試�！鞍缀小狈ㄊ歉F舉路徑測試。

　　軟件的缺陷等級應如何劃分?

　　1.致命錯誤，可能導致本模塊以及其他相關(guān)模塊異常，死機等問(wèn)題;

　　2.嚴重錯誤，問(wèn)題局限在本模塊，導致模塊功能失效或異常退出

　　3.一般錯誤，模塊功能部分失效;

　　4.建議問(wèn)題，由問(wèn)題提出人對測試對象的改進(jìn)意見(jiàn);

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

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

　　黑盒測試：已知產(chǎn)品的功能設計規格，可以進(jìn)行測試證明每個(gè)實(shí)現了的功能是否符合要求。

　　白盒測試：已知產(chǎn)品的內部工作過(guò)程，可以通過(guò)測試證明每種內部操作是否符合設計規格要求，所有內部成分是否以經(jīng)過(guò)檢查。

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

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

　　2、在接口上，輸入是否能正確的接受?能否輸出正確的結果?

　　3、是否有數據結構錯誤或外部信息(例如數據文件)訪(fǎng)問(wèn)錯誤?

　　4、性能上是否能夠滿(mǎn)足要求?

　　5、是否有初始化或終止性錯誤?

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

　　1、對程序模塊的所有獨立的執行路徑至少測試一遍。

　　2、對所有的邏輯判定，取“真”與取“假”的兩種情況都能至少測一遍。

　　3、在循環(huán)的邊界和運行的界限內執行循環(huán)體。

　　4、測試內部數據結構的有效性，等等。

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

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

　　大體上來(lái)說(shuō)可分為單元測試,集成測試,系統測試,驗收測試,每個(gè)階段又分為以下五個(gè)步驟:

　　測試計劃，測試設計，用例設計，執行結果，測試報告

　　初始測試集中在每個(gè)模塊上，保證源代碼的正確性，該階段成為單元測試，主要用白盒測試方法。

　　接下來(lái)是模塊集成和集成以便組成完整的軟件包。集成測試集中在證實(shí)和程序構成問(wèn)題上。主要采用黑盒測試方法，輔之以白盒測試方法。

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

　　單元測試

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

　　集成測試

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

　　系統測試

　　系統測試是對已經(jīng)集成好的軟件系統進(jìn)行徹底的測試，以驗證軟件系統的正確性和性能等滿(mǎn)足其規約所指定的要求，檢查軟件的行為和輸出是否正確并非一項簡(jiǎn)單的任務(wù)，它被稱(chēng)為測試的“先知者問(wèn)題”。

　　驗收測試

　　驗收測試旨在向軟件的購買(mǎi)者展示該軟件系統滿(mǎn)足其用戶(hù)的需求。它的測試數據通常是系統測試的測試數據的子集.

　　回歸測試

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

　　針對缺陷采取怎樣的管理措施?

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

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

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

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

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

　　單元測試、集成測試、系統測試的側重點(diǎn)是什么?

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

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

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

　　設計用例的方法、依據有那些?

　　白盒測試用例設計有如下方法:基本路徑測試\等價(jià)類(lèi)劃分\邊界值分析\覆蓋測試\循環(huán)測試\數據流測試\程序插樁測試\變異測試.這時(shí)候依據就是詳細設計說(shuō)明書(shū)及其代碼結構

　　黑盒測試用例設計方法:基于用戶(hù)需求的測試\功能圖分析方法\等價(jià)類(lèi)劃分方法\邊界值分析方法\錯誤推測方法\因果圖方法\判定表驅動(dòng)分析方法\正交實(shí)驗設計方法.依據是用戶(hù)需求規格說(shuō)明書(shū),詳細設計說(shuō)明書(shū)。

　　測試用例通常包括那些內容?著(zhù)重闡述編制測試用例的具體做法不同結構的用例包括的不一樣(版本、編號、項目、設計人員、設計日期、輸入、預期輸出……)

　　軟件測試用例的基本要素包括測試用例編號、測試標題、重要級別、測試輸入、操作步驟、預期結果。

　　用例編號：測試用例的編號有一定的規則，比如系統測試用例的編號這樣定義規則： PROJECT1-ST-001 ，命名規則是項目名稱(chēng)+測試階段類(lèi)型(系統測試階段)+編號。定義測試用例編號，便于查找測試用例，便于測試用例的跟蹤。

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

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

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

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

　　1) 測試人員或開(kāi)發(fā)人員發(fā)現bug后，判斷屬于哪個(gè)模塊的問(wèn)題，填寫(xiě)bug報告后，系統會(huì )自動(dòng)通過(guò)Email通知項目組長(cháng)或直接通知開(kāi)發(fā)者。

　　2) 經(jīng)驗證無(wú)誤后，修改狀態(tài)為VERIFIED.待整個(gè)產(chǎn)品發(fā)布后，修改為CLOSED.

　　3) 還有問(wèn)題，REOPENED，狀態(tài)重新變?yōu)椤癗ew"，并發(fā)郵件通知。

　　4) 項目組長(cháng)根據具體情況，重新reassigned分配給bug所屬的開(kāi)發(fā)者。

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

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

　　7) 若不是，重新reassigned分配給項目組長(cháng)或應該分配的開(kāi)發(fā)者。

　　8) 測試人員查詢(xún)開(kāi)發(fā)者已修改的bug，進(jìn)行重新測試。(可創(chuàng )建test case附件)

【軟件測試筆試題】相關(guān)文章：

軟件測試筆試題及答案02-21

軟件測試筆試題及答案下載02-24

大唐移動(dòng)測試工程師筆經(jīng)，筆試題目分享11-21

軟件筆試題 分享11-21

清華同方軟件測試工程師筆試題解答分享11-21

職場(chǎng)跳槽首選軟件測試11-24

面試心理測試題03-03

性別測試筆試題11-18

面試試題行政助理經(jīng)典測試題10-29