軟件測試基礎習題及答案

千里之行，始于足下。第2頁/共2頁精品文檔推薦軟件測試基礎習題及答案1、軟件測試的定義？

軟件測試是一具過程或者一系列過程，用來確認計算和代碼完成了其應該完成的功能，同時別執(zhí)行其別應該有的操作。

2、軟件測試的目標是啥？

是想以最少的人力、物力和時刻找出軟件中潛在的各種錯誤和缺陷，經(jīng)過修正各種錯誤和缺陷提高軟件質(zhì)量，落低軟件公布后由于潛在的軟件錯誤和缺陷造成的隱患所帶來的商業(yè)風險。

3、簡單描述一下軟件測試的原則？

所有的軟件測試都應追溯到用戶需求

應當把“盡早地和別斷地舉行軟件測試”作為測試者的座右銘

GoodEnough原則

質(zhì)量第一

充分注意測試中的群集現(xiàn)象

程序員應幸免檢查自個兒的程序

有據(jù)可依

盡可能幸免軟件測試的隨意性，要有預期結(jié)果

重視回歸測試

妥善保存一切測試過程文檔

4、軟件測試中驗證和確認的區(qū)不？

Verfication驗證：

是保證軟件正真的現(xiàn)特定功能的一系列活動和過程。

目的是保證軟件生命周期中的每一具時期的成果滿腳上一具時期設定的目標。

Validation確認：

是保證軟件滿腳用戶需求的一系列的活動和過程。

目的是在軟件開辟后保證與用戶需求符合

5、軟件測試按照測試的基本策略可分為哪兩種并加以詳細講明？

白盒測試：

白盒測試也稱結(jié)構(gòu)測試或邏輯驅(qū)動測試，是指基于一具應用代碼的內(nèi)部邏輯知識，即基于覆蓋全部代碼、分支、路徑、條件的測試，它是懂產(chǎn)品內(nèi)部工作過程，可經(jīng)過測試來檢測產(chǎn)品內(nèi)部動作是否按照規(guī)格講明書的規(guī)定正常舉行，按照程序內(nèi)部的結(jié)構(gòu)測試程序，檢驗程序中的每條通路是否都有能按預定要求正確工作，而別顧它的功能，白盒測試的要緊辦法有邏輯驅(qū)動、基路測試等，要緊用于軟件驗證。

黑盒測試：

黑盒測試是指別基于內(nèi)部設計和代碼的任何知識，而基于需求和功能性的測試，黑盒測試也稱功能測試或數(shù)據(jù)驅(qū)動測試，它是在已知產(chǎn)品所應具有的功能，經(jīng)過測試來檢測每個功能是否都能正常使用，在測試時，把程序看作一具別能打開的黑盆子，在徹底別思考程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的事情下，測試者在程序接口舉行測試，它只檢查程序功能是否按照需求規(guī)格講明書的規(guī)定正常使用，程序是否能適當?shù)亟邮蛰斎霐?shù)鋸而產(chǎn)生正確的輸出信息，同時保持外部信息（如數(shù)據(jù)庫或文件）的完整性。黑盒測試辦法要緊有等價類劃分、邊值分析、因—果圖、錯誤猜測等，要緊用于軟件確認測試。

6、整個軟件生命周期中，需要舉行哪幾項測試？

單元測試、集成測試、系統(tǒng)測試、驗收測試

單元測試

單元測試是對軟件中的基本組成單位舉行的測試，如一具模塊、一具過程等等。它是軟件動態(tài)測試的最基本的部分，也是最重要的部分之一，其目的是檢驗軟件基本組成單位的正確性。因為單元測試需要懂內(nèi)部程序設計和編碼的細節(jié)知識，普通應由程序員而非測試員來完成，往往需要開辟測試驅(qū)動模塊和樁模塊來輔助完成單元測試。所以應用系統(tǒng)有一具設計非常好的體系結(jié)構(gòu)就顯得尤為重要。

一具軟件單元的正確性是相關于該單元的規(guī)約而言的。所以，單元測試以被測試單位的規(guī)約為基準。單元測試的要緊辦法有操縱流測試、數(shù)據(jù)流測試、排錯測試、分域測試等等。

集成測試

集成測試是在軟件系統(tǒng)集成過程中所舉行的測試，其要緊目的是檢查軟件單位之間的接口是否正確。它依照集成測試打算，一邊將模塊或其他軟件單位組合成越來越大的系統(tǒng)，一邊運行該系統(tǒng)，以分析所組成的系統(tǒng)是否正確，各組成部分是否合拍。集成測試的策略要緊有自頂向下和自底向上兩種。

系統(tǒng)測試

系統(tǒng)測試是對差不多集成好的軟件系統(tǒng)舉行完全的測試，以驗證軟件系統(tǒng)的正確性和性能等滿腳其規(guī)約所指定的要求，檢查軟件的行為和輸出是否正確并非一項簡單的任務，它被稱為測試的“先知者咨詢題”。所以，系統(tǒng)測試應該按照測試打算舉行，其輸入、輸出和其他動態(tài)運行行為應該與軟件規(guī)約舉行對照。軟件系統(tǒng)測試辦法非常多，要緊有功能測試、性能測試、隨機測試等等。

驗收測試

驗收測試旨在向軟件的購買者展示該軟件系統(tǒng)滿腳其用戶的需求。它的測試數(shù)據(jù)通常是系統(tǒng)測試的測試數(shù)據(jù)的子集。所別同的是，驗收測試常常有軟件系統(tǒng)的購買者代表在現(xiàn)場，甚至是在軟件安裝使用的現(xiàn)場。這是軟件在投入使用之前的最終測試。

簡述集成測試和系統(tǒng)測試的區(qū)不？

1、集成測試的要緊依據(jù)是概要設計講明書，系統(tǒng)測試的要緊依據(jù)是需求設計講明

書

2、集成測試是系統(tǒng)模塊的測試，系統(tǒng)測試是對整個系統(tǒng)的測試，包括相關的軟硬

件平臺，網(wǎng)絡及相關的外設的測試

7、系統(tǒng)測試的策略有哪些？

功能測試，性能測試，可靠性測試，負載測試，易用性測試，強度測試，安全測試，配置測試，安裝測試，卸載測試，文擋測試，容錯性測試，界面測試，容量測試，兼容性測試，分布測試，可用性測試等。

8、文檔測試要緊包括哪些內(nèi)容？

聯(lián)機幫助文檔或用戶手冊

指導和向?qū)?/p>

安裝、設置指南

示例及模板

錯誤提示信息

用于演示的圖像和聲音

授權(quán)/注冊登記表及用戶許可協(xié)議

軟件的包裝、廣告宣傳材料

9、停止測試的條件？

符合用戶的需求

在一段時刻內(nèi)測試別出新缺陷

注：在企業(yè)實際開辟過程中，版本公布時會有遺留咨詢題

10、測試的基本文檔包括哪些？

?測試打算》：指明測試范圍、辦法、資源，以及相應測試活動的時刻進度安排表的文檔。

?《測試方案》：指明為完成軟件或軟件集成特性的測試而舉行的設計測試辦法的細節(jié)文檔。

?《測試用例》：指明為完成一具測試項的測試輸入，預期結(jié)果，測試執(zhí)行條件等因素的文檔。

?《測試規(guī)程》：指明執(zhí)行測試時測試活動序列的文檔。

?《測試報告》：指明執(zhí)行測試結(jié)果的文檔。

11、簡要的講明一下軟件工程中的V模型？

12、為啥要開展測試工作？

因為沒有通過測試的軟件非常難在公布之前懂該軟件的質(zhì)量，就好比ISO質(zhì)量認證一樣，測試同樣也需要質(zhì)量的保證，那個時候就需要在團隊中開展軟件測試的工作。在測試的過程發(fā)覺軟件中存在的咨詢題，及時讓開辟人員得知并修改咨詢題，在即將公布時，從測試報告中得出軟件的質(zhì)量事情

13、測試團隊在項目中的基本責任是啥？

1、發(fā)覺軟件程序、系統(tǒng)或產(chǎn)品中所有的咨詢題

2、盡早地發(fā)覺咨詢題

3、催促和協(xié)助開辟人員盡快地解決程序中的缺陷。

4、幫助項目治理人員制定合理的開辟打算

5、對缺陷舉行跟蹤、分析和分類總結(jié)，以便讓項目的治理人員和相關的負責人可以及時、清晰地了解產(chǎn)品當前的質(zhì)量狀態(tài)。

6、幫助改善開辟流程、提高產(chǎn)品的開辟效率

7、促進程序編寫的規(guī)范性、易讀性、可維護性等。

14、軟件缺陷的定義是啥？

從產(chǎn)品內(nèi)部看，軟件缺陷是軟件產(chǎn)品開辟或維護過程中所存在的錯誤、毛病等各種咨詢題；從外部看，軟件缺陷是系統(tǒng)所需要實現(xiàn)的某種功能的失效或違背。所以軟件缺陷算是軟件產(chǎn)

品中所存在的咨詢題，最后表現(xiàn)為用戶所需要的功能沒有徹底實現(xiàn)，沒有滿腳用戶的需求。

15、軟件錯誤的分類有哪些？

軟件需求錯誤

功能和性能錯誤

軟件結(jié)構(gòu)錯誤

數(shù)據(jù)錯誤

實現(xiàn)和編碼錯誤

軟件集成錯誤

操作系統(tǒng)調(diào)用錯誤

測試定義和測試執(zhí)行錯誤

16、一具優(yōu)秀的測試工程師需要具備的素養(yǎng)有哪些？

目標：發(fā)覺軟件缺陷，并盡量早些。

探究精神，軟件測試員別膽怯進入陌生環(huán)境。

障礙排除高手，善于發(fā)覺咨詢題的癥結(jié)。

追求完美，他們力求完美，然而懂無法企及時，別去強求。

別懈努力，別停嘗試，他們不可能心存僥幸，而是盡一切也許去尋覓。

推斷準確，要覺得測試內(nèi)容，測試時刻以及看到的內(nèi)容是否是真正的軟件缺陷。

老練穩(wěn)重，別膽怯壞消息，懂怎么樣和別夠老練的程序員合作。

具有講服力，善于表達觀點。

17、軟件質(zhì)量的定義是啥？

軟件質(zhì)量是軟件產(chǎn)品特性的總和，滿腳明確或隱含要求的能力。

18、質(zhì)量有哪6個特性？

1）功能性（functionality）：

制作的功能，達到設計規(guī)范和滿腳使用者需求的程度。

2）可靠性（reliability）：

在規(guī)定期限和條件下，仍能維持其性能水平的程度。

3）易使用性（usability）：

使用者學習、操作、預備輸入、明白輸出所作努力的程度。

4）效率（efficiency）：

軟件執(zhí)行某項功能所需的計算機資源（含時刻）的有效程度。

5）可維護性（maintainability）：

當環(huán)境改變或軟件發(fā)生錯誤時，執(zhí)行修改所做努力的程度。

6）可移植性（portability）：

從一具電腦系統(tǒng)或環(huán)境移到另一具電腦或環(huán)境的難易程度。

19、CMMI的中文名稱是啥，共分為幾級？

軟件能力成熟度模型集成，共分為5級

20、缺陷報告的定義是啥？

缺陷報告是用來解釋預期結(jié)果和實際結(jié)果之間差距的文檔，包含如何樣再現(xiàn)缺陷的場景

21、缺陷的來源有哪些？

需求咨詢題

設計缺陷：

?功能咨詢題

?系統(tǒng)和軟件架構(gòu)咨詢題

實現(xiàn)缺陷

?代碼咨詢題

相容性咨詢題

測試咨詢題

22、缺陷要緊有哪些狀態(tài)？

New：測試人員提交新bug的狀態(tài)標識

Open：測試經(jīng)理審核測試人員提交的bug，審核經(jīng)過后將該bug狀態(tài)改為open并提交給開辟經(jīng)理。開辟經(jīng)理對bug舉行審核并分配給對應的開辟人員。

Fixed：開辟人員已修改bug并自測經(jīng)過的標識，由開辟人員修改為此狀態(tài)

Closed：測試驗證bug并經(jīng)過的標識，由測試人員修改為此狀態(tài)

Rejected：開辟人員以為別是Bug、描述別清、重復、別采用所提意見建議或者測試人員提錯，從而拒絕的咨詢題。由Bug分配人或者開辟人員來設置。

Later：確認是bug，但此bug目前臨時無法解決且對產(chǎn)品妨礙別大，或無法重現(xiàn)的咨詢題等，經(jīng)過會議評審能夠暫緩或放入下個版本再解決

Reopen：測試人員驗證bug未經(jīng)過，修改為此狀態(tài)

23、軟件缺陷報告有哪些屬性？

軟件缺陷的屬性：

缺陷標識：缺陷的唯一標識，用于識不、跟蹤、查下、排序、存儲治理等，能夠使用數(shù)字序號表示

標題：對缺陷的概括性描述，方便列表、掃瞄、治理等。

詳細描述：包括前提、操作步驟、預期結(jié)果、實際結(jié)果等

環(huán)境：缺陷發(fā)覺時所處的測試環(huán)境，包括操作系統(tǒng)、掃瞄器等

所屬項目/模塊：缺陷所屬哪個具體的項目或模塊，要求精確定位至模塊、組件級

產(chǎn)品信息：屬于哪個版本等

狀態(tài)：缺陷一旦被發(fā)覺之后，其被跟蹤過程中所處的狀態(tài)

嚴峻程度：因缺陷引起的故障對軟件產(chǎn)品使用或某個質(zhì)量特性的妨礙程度

優(yōu)先級：缺陷被修復的緊急程度或先后次序，要緊取決于缺陷的嚴峻程度、產(chǎn)品對業(yè)務的實際妨礙，需要思考開辟過程的需求（對測試發(fā)展的妨礙）、技術限制等因素

類型：屬于哪方面的缺陷，如：功能、用戶界面、性能、接口等

也許性：缺陷產(chǎn)生的頻率

缺陷提交人：會和郵件XXX起來

缺陷指定解決人：

來源：缺陷產(chǎn)生的地點，如：產(chǎn)品需求定義書、設計規(guī)格講明書、代碼的具體組件或模塊，數(shù)據(jù)庫，在線幫助，用戶手冊等

產(chǎn)生緣故：產(chǎn)生缺陷的全然緣故，包括過程、辦法、工具、算法錯誤、溝通咨詢題等，以尋求流程改進、完善編程規(guī)范和加強培訓等，有助于缺陷預防。

構(gòu)建包跟蹤：用戶每日構(gòu)建軟件包跟蹤，是新發(fā)覺的缺陷依然回歸缺陷，基準是上一具軟件包

版本跟蹤：用戶產(chǎn)品版本質(zhì)量特性的跟蹤，是新發(fā)覺的缺陷依然回歸缺陷，基準是上一具版本

提交時刻：

修正時刻：

驗證時刻：

24、書寫缺陷報告的基本原則（5C原則）是啥？

1．Correct（準確）：每個組成部分的描述準確，不可能引起誤解

2．Clear（清楚）：每個組成部分的描述清楚，易于明白

3．Concise（簡潔）：只包含必別可少的信息，別包括任何多余的內(nèi)容。

4．Complete（完整）：包含復現(xiàn)該缺陷的完整步驟和其他本質(zhì)信息。

5．Consistent（一致）：按照一致的格式書寫全部缺陷報告。

25、普通事情下，缺陷報告的組織結(jié)包括哪些內(nèi)容？

（1）缺陷的標題

（2）缺陷的基本信息，包括以下幾方面

1．測試的軟件和硬件條件

2．測試的軟件的版本

3．缺陷的類型

4．缺陷的嚴峻程度

5．缺陷的優(yōu)先級

（3）復現(xiàn)缺陷的操作步驟

（4）缺陷的實際結(jié)果描述

（5）缺陷的預期結(jié)果描述

（6）注釋文字和截取的缺陷圖像或log

26、缺陷報告需要注意的咨詢題有哪些？

盡可能幸免浮現(xiàn)錯誤

別要把幾個bug錄入到同一具id

添加必要的截圖和文件

完成一具bug的錄入后應舉行檢查

27,、普通缺陷嚴峻等級怎么劃分，并描述每個嚴峻等級對應的錯誤內(nèi)容？

致命(可對應目前BUG體系中的“很嚴峻”)：

致命性咨詢題要緊為：系統(tǒng)無法執(zhí)行、崩潰或嚴峻資源別腳、應用模塊無法啟動或異常退出、無法測試、造成系統(tǒng)別穩(wěn)定。

具體都是可分為：

○嚴峻花屏

○內(nèi)存泄漏

○用戶數(shù)據(jù)丟失或破壞

○系統(tǒng)崩潰/死機/凍結(jié)

○模塊無法啟動或異常退出

○嚴峻的數(shù)值計算錯誤

○功能設計與需求嚴峻別符

○其它導致無法測試的錯誤

●嚴峻（可對應目前BUG體系中的“嚴峻”）

嚴峻性咨詢題要緊為：妨礙系統(tǒng)功能或操作，要緊功能存在嚴峻缺陷，但不可能妨礙到系統(tǒng)穩(wěn)定性。

具體都是可分為：

○功能未實現(xiàn)

○功能錯誤

○系統(tǒng)刷新錯誤

○語音或數(shù)據(jù)通訊錯誤

○輕微的數(shù)值計算錯誤

○系統(tǒng)所提供的功能或服務受明顯的妨礙

●普通（可對應于目前BUG體系中的“一般”）

普通性咨詢題要緊為：界面、性能缺陷

具體都是可分為：

○操作界面錯誤（包括數(shù)據(jù)窗口內(nèi)列名定義、含義是否一致）

○邊界條件下錯誤

○提示信息錯誤（包括未給出信息、信息提示錯誤等）

○長時刻操作無進度提示

○系統(tǒng)未優(yōu)化（性能咨詢題）

○光標跳轉(zhuǎn)設置不行，鼠標（光標）定位錯誤

●提示（可對應于目前BUG體系中的“輕微及建議”）

提示性咨詢題要緊為：易用性及建議性咨詢題

具體都是可分為：

○界面格式等別規(guī)范

○輔助講明描述別清晰

○操作時未給用戶提示

○可輸入?yún)^(qū)域和只讀區(qū)域沒有明顯的區(qū)分標志

○個不別妨礙產(chǎn)品明白的錯不字

○文字羅列別整齊等一些小咨詢題

○建議

28、缺陷優(yōu)先級常用的劃分辦法是啥？

P1馬上解決：缺陷導致系統(tǒng)幾乎別能運行、使用或嚴峻影響測試的執(zhí)行，需馬上修正、盡快修正；

P2高優(yōu)先級：缺陷嚴峻，妨礙測試，需要優(yōu)先思考修正，如別超過24小時；

P3正常排隊：缺陷需要修正，但能夠正常排隊等待修正；

P4低優(yōu)先級：缺陷能夠在開辟人員有時刻的時候被修正，如沒有時刻，能夠別修正

29、列出一些控件的名稱？

菜單、按鈕、對話框、消息提示框、文本框、單選按鈕、復選按鈕、工具欄、懸浮框、托盤、下拉列表等。

30、測試用例的定義？