軟件測試基礎習題及答案

軟件測試基礎習題及答案軟件測試基礎習題及答案軟件測試基礎習題及答案V:1.0精細整理，僅供參考軟件測試基礎習題及答案日期：20xx年X月軟件測試的定義軟件測試是一個過程或者一系列過程，用來確認計算和代碼完成了其應該完成的功能，并且不執(zhí)行其不應該有的操作。軟件測試的目標是什么是想以最少的人力、物力和時間找出軟件中潛在的各種錯誤和缺陷，通過修正各種錯誤和缺陷提高軟件質量，降低軟件發(fā)布后由于潛在的軟件錯誤和缺陷造成的隱患所帶來的商業(yè)風險。簡單描述一下軟件測試的原則所有的軟件測試都應追溯到用戶需求應當把“盡早地和不斷地進行軟件測試”作為測試者的座右銘GoodEnough原則質量第一充分注意測試中的群集現(xiàn)象程序員應避免檢查自己的程序有據(jù)可依盡量避免軟件測試的隨意性，要有預期結果重視回歸測試妥善保存一切測試過程文檔軟件測試中驗證和確認的區(qū)別Verfication驗證：是保證軟件正確實現(xiàn)特定功能的一系列活動和過程。目的是保證軟件生命周期中的每一個階段的成果滿足上一個階段設定的目標。Validation確認：是保證軟件滿足用戶需求的一系列的活動和過程。目的是在軟件開發(fā)后保證與用戶需求符合軟件測試按照測試的基本策略可分為哪兩種并加以詳細說明白盒測試：白盒測試也稱結構測試或邏輯驅動測試，是指基于一個應用代碼的內部邏輯知識，即基于覆蓋全部代碼、分支、路徑、條件的測試，它是知道產(chǎn)品內部工作過程，可通過測試來檢測產(chǎn)品內部動作是否按照規(guī)格說明書的規(guī)定正常進行，按照程序內部的結構測試程序，檢驗程序中的每條通路是否都有能按預定要求正確工作，而不顧它的功能，白盒測試的主要方法有邏輯驅動、基路測試等，主要用于軟件驗證。黑盒測試：黑盒測試是指不基于內部設計和代碼的任何知識，而基于需求和功能性的測試，黑盒測試也稱功能測試或數(shù)據(jù)驅動測試，它是在已知產(chǎn)品所應具有的功能，通過測試來檢測每個功能是否都能正常使用，在測試時，把程序看作一個不能打開的黑盆子，在完全不考慮程序內部結構和內部特性的情況下，測試者在程序接口進行測試，它只檢查程序功能是否按照需求規(guī)格說明書的規(guī)定正常使用，程序是否能適當?shù)亟邮蛰斎霐?shù)鋸而產(chǎn)生正確的輸出信息，并且保持外部信息（如數(shù)據(jù)庫或文件）的完整性。黑盒測試方法主要有等價類劃分、邊值分析、因—果圖、錯誤推測等，主要用于軟件確認測試。6、整個軟件生命周期中，需要進行哪幾項測試單元測試、集成測試、系統(tǒng)測試、驗收測試單元測試單元測試是對軟件中的基本組成單位進行的測試，如一個模塊、一個過程等等。它是軟件動態(tài)測試的最基本的部分，也是最重要的部分之一，其目的是檢驗軟件基本組成單位的正確性。因為單元測試需要知道內部程序設計和編碼的細節(jié)知識，一般應由程序員而非測試員來完成，往往需要開發(fā)測試驅動模塊和樁模塊來輔助完成單元測試。因此應用系統(tǒng)有一個設計很好的體系結構就顯得尤為重要。一個軟件單元的正確性是相對于該單元的規(guī)約而言的。因此，單元測試以被測試單位的規(guī)約為基準。單元測試的主要方法有控制流測試、數(shù)據(jù)流測試、排錯測試、分域測試等等。集成測試集成測試是在軟件系統(tǒng)集成過程中所進行的測試，其主要目的是檢查軟件單位之間的接口是否正確。它根據(jù)集成測試計劃，一邊將模塊或其他軟件單位組合成越來越大的系統(tǒng)，一邊運行該系統(tǒng)，以分析所組成的系統(tǒng)是否正確，各組成部分是否合拍。集成測試的策略主要有自頂向下和自底向上兩種。系統(tǒng)測試系統(tǒng)測試是對已經(jī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ū)別集成測試的主要依據(jù)是概要設計說明書，系統(tǒng)測試的主要依據(jù)是需求設計說明書集成測試是系統(tǒng)模塊的測試，系統(tǒng)測試是對整個系統(tǒng)的測試，包括相關的軟硬件平臺，網(wǎng)絡及相關的外設的測試7、系統(tǒng)測試的策略有哪些功能測試，性能測試，可靠性測試，負載測試，易用性測試，強度測試，安全測試，配置測試，安裝測試，卸載測試，文擋測試，容錯性測試，界面測試，容量測試，兼容性測試，分布測試，可用性測試等。文檔測試主要包括哪些內容聯(lián)機幫助文檔或用戶手冊指導和向導安裝、設置指南示例及模板錯誤提示信息用于演示的圖像和聲音授權/注冊登記表及用戶許可協(xié)議軟件的包裝、廣告宣傳材料停止測試的條件符合用戶的需求在一段時間內測試不出新缺陷注：在企業(yè)實際開發(fā)過程中，版本發(fā)布時會有遺留問題測試的基本文檔包括哪些測試計劃》：指明測試范圍、方法、資源，以及相應測試活動的時間進度安排表的文檔?！稖y試方案》：指明為完成軟件或軟件集成特性的測試而進行的設計測試方法的細節(jié)文檔?！稖y試用例》：指明為完成一個測試項的測試輸入，預期結果，測試執(zhí)行條件等因素的文檔?！稖y試規(guī)程》：指明執(zhí)行測試時測試活動序列的文檔。《測試報告》：指明執(zhí)行測試結果的文檔。簡要的說明一下軟件工程中的V模型項目規(guī)劃項目規(guī)劃項目需求分析項目概要分析項目詳細分析代碼編寫測試代碼編寫測試需求分析系統(tǒng)測試計劃集成測試計劃單元測試計劃產(chǎn)品發(fā)布測試系統(tǒng)測試集成測試單元測試為什么要開展測試工作因為沒有經(jīng)過測試的軟件很難在發(fā)布之前知道該軟件的質量，就好比ISO質量認證一樣，測試同樣也需要質量的保證，這個時候就需要在團隊中開展軟件測試的工作。在測試的過程發(fā)現(xiàn)軟件中存在的問題，及時讓開發(fā)人員得知并修改問題，在即將發(fā)布時，從測試報告中得出軟件的質量情況測試團隊在項目中的基本責任是什么發(fā)現(xiàn)軟件程序、系統(tǒng)或產(chǎn)品中所有的問題盡早地發(fā)現(xiàn)問題督促和協(xié)助開發(fā)人員盡快地解決程序中的缺陷。幫助項目管理人員制定合理的開發(fā)計劃對缺陷進行跟蹤、分析和分類總結，以便讓項目的管理人員和相關的負責人能夠及時、清楚地了解產(chǎn)品當前的質量狀態(tài)。幫助改善開發(fā)流程、提高產(chǎn)品的開發(fā)效率促進程序編寫的規(guī)范性、易讀性、可維護性等。軟件缺陷的定義是什么從產(chǎn)品內部看，軟件缺陷是軟件產(chǎn)品開發(fā)或維護過程中所存在的錯誤、毛病等各種問題；從外部看，軟件缺陷是系統(tǒng)所需要實現(xiàn)的某種功能的失效或違背。因此軟件缺陷就是軟件產(chǎn)品中所存在的問題，最終表現(xiàn)為用戶所需要的功能沒有完全實現(xiàn)，沒有滿足用戶的需求。軟件錯誤的分類有哪些軟件需求錯誤功能和性能錯誤軟件結構錯誤數(shù)據(jù)錯誤實現(xiàn)和編碼錯誤軟件集成錯誤操作系統(tǒng)調用錯誤測試定義和測試執(zhí)行錯誤一個優(yōu)秀的測試工程師需要具備的素質有哪些目標：發(fā)現(xiàn)軟件缺陷，并盡可能早些。探索精神，軟件測試員不害怕進入陌生環(huán)境。障礙排除高手，善于發(fā)現(xiàn)問題的癥結。追求完美，他們力求完美，但是知道無法企及時，不去強求。不懈努力，不停嘗試，他們不會心存僥幸，而是盡一切可能去尋找。判斷準確，要覺得測試內容，測試時間以及看到的內容是否是真正的軟件缺陷。老練穩(wěn)重，不害怕壞消息，知道怎樣和不夠老練的程序員合作。具有說服力，善于表達觀點。軟件質量的定義是什么軟件質量是軟件產(chǎn)品特性的總和，滿足明確或隱含要求的能力。質量有哪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)境的難易程度。CMMI的中文名稱是什么，共分為幾級軟件能力成熟度模型集成，共分為5級缺陷報告的定義是什么缺陷報告是用來解釋預期結果和實際結果之間差距的文檔，包含怎么樣再現(xiàn)缺陷的場景缺陷的來源有哪些需求問題設計缺陷：功能問題系統(tǒng)和軟件架構問題實現(xiàn)缺陷代碼問題相容性問題測試問題缺陷主要有哪些狀態(tài) New：測試人員提交新bug的狀態(tài)標識 Open：測試經(jīng)理審核測試人員提交的bug，審核通過后將該bug狀態(tài)改為open并提交給開發(fā)經(jīng)理。開發(fā)經(jīng)理對bug進行審核并分配給對應的開發(fā)人員。 Fixed：開發(fā)人員已修改bug并自測通過的標識，由開發(fā)人員修改為此狀態(tài) Closed：測試驗證bug并通過的標識，由測試人員修改為此狀態(tài) Rejected：開發(fā)人員認為不是Bug、描述不清、重復、不采納所提意見建議或者測試人員提錯，從而拒絕的問題。由Bug分配人或者開發(fā)人員來設置。 Later：確認是bug，但此bug目前暫時無法解決且對產(chǎn)品影響不大，或無法重現(xiàn)的問題等，通過會議評審可以暫緩或放入下個版本再解決Reopen：測試人員驗證bug未通過，修改為此狀態(tài)軟件缺陷報告有哪些屬性軟件缺陷的屬性：缺陷標識：缺陷的唯一標識，用于識別、跟蹤、查下、排序、存儲管理等，可以使用數(shù)字序號表示標題：對缺陷的概括性描述，方便列表、瀏覽、管理等。詳細描述：包括前提、操作步驟、預期結果、實際結果等環(huán)境：缺陷發(fā)現(xiàn)時所處的測試環(huán)境，包括操作系統(tǒng)、瀏覽器等所屬項目/模塊：缺陷所屬哪個具體的項目或模塊，要求精確定位至模塊、組件級產(chǎn)品信息：屬于哪個版本等狀態(tài)：缺陷一旦被發(fā)現(xiàn)之后，其被跟蹤過程中所處的狀態(tài)嚴重程度：因缺陷引起的故障對軟件產(chǎn)品使用或某個質量特性的影響程度優(yōu)先級：缺陷被修復的緊急程度或先后次序，主要取決于缺陷的嚴重程度、產(chǎn)品對業(yè)務的實際影響，需要考慮開發(fā)過程的需求（對測試進展的影響）、技術限制等因素類型：屬于哪方面的缺陷，如：功能、用戶界面、性能、接口等可能性：缺陷產(chǎn)生的頻率缺陷提交人：會和郵件地址聯(lián)系起來缺陷指定解決人：來源：缺陷產(chǎn)生的地方，如：產(chǎn)品需求定義書、設計規(guī)格說明書、代碼的具體組件或模塊，數(shù)據(jù)庫，在線幫助，用戶手冊等產(chǎn)生原因：產(chǎn)生缺陷的根本原因，包括過程、方法、工具、算法錯誤、溝通問題等，以尋求流程改進、完善編程規(guī)范和加強培訓等，有助于缺陷預防。構建包跟蹤：用戶每日構建軟件包跟蹤，是新發(fā)現(xiàn)的缺陷還是回歸缺陷，基準是上一個軟件包版本跟蹤：用戶產(chǎn)品版本質量特性的跟蹤，是新發(fā)現(xiàn)的缺陷還是回歸缺陷，基準是上一個版本提交時間：修正時間：驗證時間：書寫缺陷報告的基本原則（5C原則）是什么Correct（準確）：每個組成部分的描述準確，不會引起誤解Clear（清晰）：每個組成部分的描述清晰，易于理解Concise（簡潔）：只包含必不可少的信息，不包括任何多余的內容。Complete（完整）：包含復現(xiàn)該缺陷的完整步驟和其他本質信息。Consistent（一致）：按照一致的格式書寫全部缺陷報告。一般情況下，缺陷報告的組織結包括哪些內容缺陷的標題缺陷的基本信息，包括以下幾方面測試的軟件和硬件條件測試的軟件的版本缺陷的類型缺陷的嚴重程度缺陷的優(yōu)先級復現(xiàn)缺陷的操作步驟缺陷的實際結果描述缺陷的預期結果描述注釋文字和截取的缺陷圖像或log缺陷報告需要注意的問題有哪些盡量避免出現(xiàn)錯誤不要把幾個bug錄入到同一個id添加必要的截圖和文件完成一個bug的錄入后應進行檢查27,、一般缺陷嚴重等級如何劃分，并描述每個嚴重等級對應的錯誤內容致命(可對應目前BUG體系中的“非常嚴重”)：致命性問題主要為：系統(tǒng)無法執(zhí)行、崩潰或嚴重資源不足、應用模塊無法啟動或異常退出、無法測試、造成系統(tǒng)不穩(wěn)定。具體基本上可分為：○嚴重花屏○內存泄漏○用戶數(shù)據(jù)丟失或破壞○系統(tǒng)崩潰/死機/凍結○模塊無法啟動或異常退出○嚴重的數(shù)值計算錯誤○功能設計與需求嚴重不符○其它導致無法測試的錯誤●嚴重（可對應目前BUG體系中的“嚴重”）嚴重性問題主要為：影響系統(tǒng)功能或操作，主要功能存在嚴重缺陷，但不會影響到系統(tǒng)穩(wěn)定性。具體基本上可分為：○功能未實現(xiàn)○功能錯誤○系統(tǒng)刷新錯誤○語音或數(shù)據(jù)通訊錯誤○輕微的數(shù)值計算錯誤○系統(tǒng)所提供的功能或服務受明顯的影響●一般（可對應于目前BUG體系中的“普通”）一般性問題主要為：界面、性能缺陷具體基本上可分為：○操作界面錯誤（包括數(shù)據(jù)窗口內列名定義、含義是否一致）○邊界條件下錯誤○提示信息錯誤（包括未給出信息、信息提示錯誤等）○長時間操作無進度提示○系統(tǒng)未優(yōu)化（性能問題）○光標跳轉設置不好，鼠標（光標）定位錯誤●提示（可對應于目前BUG體系中的“輕微及建議”）提示性問題主要為：易用性及建議性問題具體基本上可分為：○界面格式等不規(guī)范○輔助說明描述不清楚○操作時未給用戶提示○可輸入?yún)^(qū)域和只讀區(qū)域沒有明顯的區(qū)分標志○個別不影響產(chǎn)品理解的錯別字○文字排列不整齊等一些小問題○建議缺陷優(yōu)先級常用的劃分方法是什么P1立即解決：缺陷導致系統(tǒng)幾乎不能運行、使用或嚴重妨礙測試的執(zhí)行，需立即修正、盡快修正；P2高優(yōu)先級：缺陷嚴重，影響測試，需要優(yōu)先考慮修正，如不超過24小時；P3正常排隊：缺陷需要修正，但可以正常排隊等待修正；P4低優(yōu)先級：缺陷可以在開發(fā)人員有時間的時候被修正，如沒有時間，可以不修正列出一些控件的名稱菜單、按鈕、對話框、消息提示框、文本框、單選按鈕、復選按鈕、工具欄、懸浮框、托盤、下拉列表等。測試用例的定義測試用例是一系列的測試步驟，用以幫助測試人員發(fā)現(xiàn)缺陷描述測試用例設計的完整過程需求分析+需求變更的維護工作根據(jù)需求，得出測試需求設計測試方案，評審測試方案測試方案通過評審后，設計測試用例，再對測試用例進行評審測試用例的元素有哪些用例ID、標題、優(yōu)先級、預置條件、操作步驟、預期結果等測試用例設計的步驟軟件測試用例的設計遵守下列4部曲：制定測試用例設計的策略和思想，在測試方案中描述出來設計測試用例的框架，也就是測試用例的結構細節(jié)結構，逐步設計出具體的測試用例通過測試用例的評審，不斷優(yōu)化測試用例測試用例設計的基本思想是什么設計測試用例時，要尋求系統(tǒng)設計、功能設計的弱點。測試用例需要確切地反映功能設計中可能存在的各種問題，而不要簡單拷貝產(chǎn)品規(guī)格設計說明書的內容。設計正面的測試用例，應該參照設計規(guī)格說明書，根據(jù)關聯(lián)的功能、操作路徑等設計。而對孤立的功能則直接按功能設計測試用例?；臼录臏y試用例應包含所有需要實現(xiàn)的需求功能，覆蓋率達100%。設計負面的、異常的測試用例，如考慮錯誤的或者異常的輸入，往往可以發(fā)現(xiàn)更多的軟件缺陷，這顯得更為重要。例如，在進行電子郵件地址校驗的時候，考慮錯誤的、不合法的（如沒有@符號的輸入）或者帶有異常字符（單引號、斜杠、雙引號等）的電子郵件地址輸入，尤其是在做web頁面測試的時候，通常會出現(xiàn)因一些字符轉義問題而造成異常情況。測試用例執(zhí)行的步驟有哪些審核測試內容ReviewContent.準備測試環(huán)境PrepareEnvironment.測試用例步驟執(zhí)行Testcasestepexecution.檢查執(zhí)行結果Conductresultcheck.測試結果報告Testresultreport.測試用例的更新Testcaseupdate.黑盒測試用例設計有哪些方法等價類劃分法、邊界值分析法、因果圖法、功能圖法、錯誤推測法、正交實驗設計法、場景設計法按照覆蓋度由低到高寫出白盒測試用例設計的方法語句覆蓋、判定覆蓋、條件覆蓋、判定條件覆蓋、條件組合覆蓋、路徑覆蓋。寫出全球化、國際化和本地化的簡稱和它們之間的關系全球化：G11Nglobalization的簡寫國際化：I18Ninternationalization的簡寫本地化：L10Nlocalization的簡寫全球化=國際化+本地化國際化測試的特殊需求有哪些支持unicode字符集。如建立用于本地字符編碼（ANSI或OEM）和unicode之間變換的字符映射表，既可以處理類似于英文的單字節(jié)語言，又能處理類似于中文、日文等雙字節(jié)或多字節(jié)語言。支持不同時區(qū)的設定、顯示和切換分離程序代碼和顯示內容（文本、圖片、對話框和按鈕等）。如建立資源文件（*.rc）來存儲這些內容。消除硬代碼（指程序代碼中所包含的一些特定的數(shù)據(jù)），而盡量使用變量處理，將數(shù)據(jù)存儲在數(shù)據(jù)庫或初始化文件中。使用Headerfiles定義經(jīng)常被調用的代碼段。彈出的窗口、按鈕、菜單等的尺寸具有自動伸縮性或可靈活地調整，以適應不同語言顯示文本的長度變化。吃吃各個國家的鍵盤設置，但要統(tǒng)一熱鍵。支持文字排序和大小寫轉換。支持各國家的度量衡、時間、貨幣單位等不同格式的顯示方式。支持顏色字體等自定義。擁有國際化用戶界面設計。軟件國際化的測試就是驗證軟件產(chǎn)品是否支持上述特性。本地化測試的基本內容是什么功能性測試數(shù)據(jù)格式測試可用性測試翻譯驗證測試兼容性測試文檔測試42、一套完整的測試應該由哪些階段組成測試計劃、測試設計與開發(fā)、測試實施、測試評審與測試結論43、如何理解壓力、負載、性能測試性能測試是一個較大的范圍，實際上性能測試本身包含了性能、強度、壓力、負載等多方面的測試內容。壓力測試是對服務器的穩(wěn)定性以及負載能力等方面的測試，是一種很平常的測試，增大訪問系統(tǒng)的用戶數(shù)量、或者幾個用戶進行大數(shù)據(jù)量操作都是壓力測試。而負載測試是壓力相對較大的測試，主要是測試系統(tǒng)在一種或幾種極限條件下的相應能力，是性能測試的重要部分。100個用戶對系統(tǒng)進行連續(xù)半個小時的訪問可以看做壓力測試，那么連續(xù)訪問8個小時就可以認為負載測試，1000個用戶連續(xù)訪問系統(tǒng)1個小時也可以看做是負載測試。實際上壓力測試和負載測試沒有明顯的區(qū)分。測試人員應該站在關注整體性能的高度上來對系統(tǒng)進行測試。44、所有的軟件缺陷都能修復嗎所有的軟件缺陷都要修復嗎從技術上講，所有的軟件缺陷都是能夠修復的，但是沒有必要修復所有的軟件缺陷。測試人員要做的是能夠正確判斷什么時候不能追求軟件的完美。對于整個項目團隊，要做的是對每一個軟件缺陷進行取舍，根據(jù)風險決定哪些缺陷要修復。發(fā)生這種現(xiàn)象的主要原因如下：沒有足夠的時間資源。在任何一個項目中，通常情況下開發(fā)人員和測試人員都是不夠用的。而且在項目中沒有預算足夠的回歸測試時間，再加上修改缺陷可能引入的新缺陷，因此在交付期限的強大壓力下，必須放棄某些缺陷的修改。有些缺陷只是特殊情況下出現(xiàn)，這種缺陷處于商業(yè)利益考慮，可以在以后升級中進行修復不是缺陷的缺陷。我們經(jīng)常會碰到某些功能方面的問題被當成缺陷來處理，這類問題可以以后有時間考慮