測試程師筆試及答案一、基礎理論1、軟件測試的結束標準是什么,2、一套完整的測試應該由哪些階段組成分別闡述一下各個階段。3、什么是缺陷報告,4、缺陷報告的作用5、缺陷報告的要點6、軟件測試缺陷報告的“5C”原則7、缺陷的二八定理8、軟件測試的流程9、測試計劃的目的是什么,測試計劃的內容都包括什么其中哪些是最重要的,10、請試著比較一下黑盒測試、白盒測試、單元測試、集成測試、系統測試、驗收測試的區別與聯系。11、Alpha測試與beta測試的區別答案:一、基礎理論1、測試計劃中所有規定的測試內容和回歸測試都已經運行完成或根據上級主管對測試結果的意見，就可以結束本次測試2、計劃階段、設計階段、白盒單元、白盒集成、黑盒單元、黑盒集成、系統測試、回歸測試、驗收測試一套完整的測試應該由五個階段組成1)測試計劃首先，根據用戶需求報告中關于功能要求和性能指標的規格說明書，定義相應的測試需求報告，即制訂黑盒測試的最高標準。以后所有的測試工作

都將圍繞著測試需求來進行，符合測試需求的應用程序即是合格的，反之即是不合格的;同時，還要適當選擇測試內容，合理安排測試人員、測試時間及測試資源等。2)測試設計將測試計劃階段制訂的測試需求分解、細化為若干個可執行的測試過程，并為每個測試過程選擇適當的測試用例測試用例選擇的好壞將直接影響測試結果的有效性)。3)測試開發建立可重復使用的自動測試過程。4)測試執行執行測試開發階段建立的自動測試過程，并對所發現的缺陷進行跟蹤管理，測試執行一般由單元測試、組合測試、集成測試、系統聯調及回歸測試等步驟組成，測試人員應本著科學負責的態度，一步一個腳印地進行測試。5)測試評估結合量化的測試覆蓋域及缺陷跟蹤報告，對于應用軟件的質量和開發團隊的工作進度及工作效率進行綜合評價。3、缺陷報告是描述軟件缺陷現象和重現步驟地集合。軟件缺陷報告BugReport(SBR)或軟件問題報告SoftwareProblemReport(SPR)4、缺陷報告是軟件測試人員的工作成果之一，體現軟件測試的價值缺陷報告可以把軟件存在的缺陷準確的描述出來，便于開發人員修正缺陷報告可以反映項目/產品當前的質量狀態，便于項目整體進度和質量控制軟件測試缺陷報告是軟件測試的輸出成果之一，可以衡量測試人員的工作能力5、標題(Title)簡潔、準確、完整、反映缺陷本質、方便查詢前綴+標題正文，標題正文采用結果和動作，或者現象和位置的方式表達步驟(Steps)可復現、完整、簡潔、準確

按數字編號實際結果(Actualresults)準確、詳細描述軟件的現象和特征期望結果(Expectedresults)準確、豐富、有理有據平臺(Platforms)準確截圖(Screenshots)準確反映缺陷特征注釋(Notes)關于缺陷的輔助說明6、內容準確(Correct):每個組成部分的描述準確，不會引起誤解步驟簡潔(Concise):只包含必不可少的信息，不包括任何多余的內容內容清晰(Clear):每個組成部分的描述清晰，易于理解結構完整(Complete):包含復現該缺陷的完整步驟和其他本質信息風格一致(Consistent):按照一致的格式書寫全部缺陷報告7、在分析、設計、實現階段的復審和測試工作能夠發現和避免的缺陷，而系統測試又能找出其余缺陷中的80%，最后的的缺陷可能只有在用戶大范圍、長時間使用后才會暴露出來。

8、制訂測試計劃、設計測試用例、實施測試、提交缺陷報告、測試總結。9、測試計劃的目的:編寫軟件測試計劃的目的是指導測試組成員進行工作和讓測試組以外的項目成員了解測試工作的。測試計劃的內容:測試目的和測試項目簡介、測試參考文檔和測試提交文檔、術語和定義、測試策略、確定測試內容、資源、測試進度、測試員的職責與任務分配、項目通過或失敗的標準、暫停和重新啟動測試的標準、風險和問題等。最重要的:測試策略、確定測試內容、資源、測試進度、測試員的職責與任務分配、項目通過或失敗的標準10、黑盒測試:把測試對象當成一個黑盒子，測試人員完全不考慮邏輯結構和內部特性，只依據程式的需求說明書來檢查程式的功能是否滿足它的功能說明。白盒測試:把測試對象當成一個透明的盒子，允許測試人員利用程序內部邏輯結構及相關信息，設計或選擇測試用例，對程式所有邏輯路徑進行測試。單元測試:白盒測試的一種，對軟件設計中的單元模塊進行測試。集成測試:在單元測試的基礎上，對單元模塊之間的連接和組裝進行測試。系統測試:在所有都考慮的情況下，對系統進行測試。驗收測試:第三方進行的確認軟件滿足需求的測試。一、判斷題1(軟件測試的目的是盡可能多的找出軟件的缺陷。2(Beta試是驗收測試的一種。(Y)3(驗收測試是由最終用戶來實施的。4(項目立項前測試人員不需要提交任何工件。5(單元測試能發現約的軟件缺陷。(Y)6(代碼評審是檢查源代碼是否達到模塊設計的要求。7(底向上集成需要測試員編寫驅動程序。(Y)8(負載測試是驗證要檢驗的系統的能力最高能達到什么

程度。(N)9(測試人員要堅持原則，缺陷未修復完堅決不予通過。10(代碼評審員一般由測試員擔任。(N)11(我們可以人為的使得軟件不存在配置問題。12(集成測試計劃在需求分析階段末提交。(N)二、選擇題1(軟件驗收測試的合格通過準則是:(ABCD)A(軟件需求分析說明書中定義的所有功能已全部實現，性能指標全部達到要求。B(所有測試項沒有殘余一級、二級和三級錯誤。C(立項審批表、需求分析文檔、設計文檔和編碼實現一致。D(驗收測試工件齊全。2(軟件測試計劃評審會需要哪些人員參加(ABCD)A(項目經理B(SQA負責人C(配置負責人D(測試組3(下列關于alpha測試的描述中正確的是(AD)A(alpha測試需要用戶代表參加B(alpha測試不需要用戶代表參加C(alpha測試是系統測試的一種D(alpha測試是驗收測試的一種4(測試設計員的職責有:(BC)A(制定測試計劃B(設計測試用例C(設計測試過程、腳本D(評估測試活動

5(軟件實施活動的進入準則是:(ABC)A(需求工件已經被基線化B(詳細設計工件已經被基線化C(構架工件已經被基線化D(項目階段成果已經被基線化三、填空題1.軟件驗收測試包括:正式驗收測試，測試，beta測試。2.系統測試的策略有:功能測試，性能測試，可靠性測試，負載測試，易用性測試，強度測試，安全測試，配置測試，安裝測試，卸載測試，文擋測試，故障恢復測試，界面測試，容量測試，兼容性測試，分布測試，可用性測試，有的可以合在一起，分開寫只要寫出15就滿分哦3.設計系統測試計劃需要參考的項目文擋有軟件測試計劃，軟件需求工件和迭代計劃。4.對面向過程的系統采用的集成策略有自頂向下，自底向上兩種。5.通過畫因果圖來寫測試用例的步驟為(1)分析軟件規格說明描述中，哪些是原因即輸入條件或輸入條件的等價類)，哪些是結果(即輸出條件)，并給每個原因和結果賦予一個標識符。(2)分析軟件規格說明描述中的語義，找出原因與結果之間，原因與原因之間對應的是什么關系?根據這些關系，畫出因果圖。(3)由于語法或環境限制，有些原因與原因之間，原因與結果之間的組合情況不可能出現。為表明這些特殊情況，在因果圖上用一些記號標明約束或限制條件。(4)把因果圖轉換成判定表。(5)把判定表的每一列拿出來作為依據，設計測試用例。四、簡答題

1.區別階段評審的與同行評審同行評審目的:發現小規模工作產品的錯誤只要是找錯誤;階段評審目的:評審模塊階段作品的正確性可行性及完整性同行評審人數:3-7人人員必須經過同行評審會議的培訓由指導階段評審人數:5人左右評審人必須是專家具有系統評審資格同行評審內容:內容小一般文檔<40頁,代碼<500行階段評審內容:內容多,主要看重點同行評審時間:一小部分工作產品完成階段評審時間:通常是設置在關鍵路徑的時間點上2.什么是軟件測試為了發現程序中的錯誤而執行程序的過程3簡述集成測試的過程系統集成測試主要包括以下過程:1.構建的確認過程。2.補丁的確認過程。3.系統集成測試測試組提交過程。4.測試用例設計過程。5.測試代碼編寫過程。6.Bug的報告過程。7.每周/每兩周的構建過程。8.點對點的測試過程。9.組內培訓過程。4怎么做好文檔測試仔細閱讀，跟隨每個步驟，檢查每個圖形，嘗試每個示例。

檢查文檔的編寫是否滿足文檔編寫的目的內容是否齊全，正確內容是否完善標記是否正確5白盒測試有幾種方法總體上分為靜態方法和動態方法兩大類。靜態:關鍵功能是檢查軟件的表示和描述是否一致沒有沖突或者沒有歧義動態:語句覆蓋、判定覆蓋、條件覆蓋、判定條件覆蓋、條件組合覆蓋、路徑覆蓋。6系統測試計劃是否需要同行審批，為什么需要，系統測試計劃屬于項目階段性關鍵文檔，因此需要評審。7Alpha測試與beta的區別,Alpha測試在系統開發接近完成時對應用系統的測試測試后仍然會有少量的設計變更。這種測試一般由最終用戶或其它人員完成，不能由程序或測試員完成。Beta測試當開發和測試根本完成時所做的測試，最終的錯誤和問題需要在最終發行前找到。這種測試一般由最終用戶或其它人員完成，不能由程序員或測試員完成。8比較負載測試，容量測試和強度測試的區別負載測試:在一定的工作負荷下，系統的負荷及響應時間。強度測試:在一定的負荷條件下，在較長時間跨度內的系統連續運行給系統性能所造成的影響。容量測試:容量測試目的是通過測試預先分析出反映軟件系統應用特征的某項指標的極限值(如最大并發用戶數、數據庫記錄數等，系統在其極限值狀態下沒有

出現任何軟件故障或還能保持主要功能正常運行。容量測試還將確定測試對象在給定時間內能夠持續處理的最大負載或工作量。容量測試的目的是使系統承受超額的數據容量來發現它是否能夠正確處理。容量測試是面向數據的，并且它的目的是顯示系統可以處理目標內確定的數據容量。9測試結束的標準是什么,用例全部測試。覆蓋率達到標準。缺陷率達到標準。其他指標達到質量標準10描述軟件測試活動的生命周期,測試周期分為計劃、設計、實現、執行、總結。其中計劃:對整個測試周期中所有活動進行規劃，估計工作量、風險，安排人力物力資源，安排進度等;設計:完成測試方案，從技術層面上對測試進行規劃實現:進行測試用例和測試規程設計;執行:根據前期完成的計劃、方案、用例、規程等文檔，執行測試用例。總結:記錄測試結果，進行測試分析，完成測試報告。11軟件的缺陷等級應如何劃分,A類—嚴重錯誤，包括以下各種錯誤1(由于程序所引起的死機,非法退出2(死循環3(數據庫發生死鎖4(因錯誤操作導致的程序中斷5(功能錯誤6(與數據庫連接錯誤7(數據通訊錯誤B類—較嚴重錯誤，包括以下各種錯誤1(程序錯誤2(程序接口錯誤3(數據庫的表、業務規則、缺省值未加完整性等約束條件

C類—一般性錯誤，包括以下各種錯誤1(操作界面錯誤(包括數據窗口內列名定義、含義是否一致)2(打印內容、格式錯誤3(簡單的輸入限制未放在前臺進行控制4(刪除操作未給出提示5(數據庫表中有過多的空字段D類—較小錯誤，包括以下各種錯誤1(界面不規范2(輔助說明描述不清楚3(輸入輸出不規范4(長操作未給用戶提示5(提示窗口文字未采用行業術語6(可輸入區域和只讀區域沒有明顯的區分標志E類—測試建議五、用例設計隨意選取一個簡單物品，假定是一個喝水的帶廣告圖案的花紙杯，設計出盡可能多的測試用例。測試項目:杯子需求測試:查看杯子使用說明書界面測試:查看杯子外觀功能度:用水杯裝水看漏不漏;水能不能被喝到安全性:杯子有沒有毒或細菌可*性:杯子從不同高度落下的損壞程度可移植性:杯子再不同的地方、溫度等環境下是否都可以正常使用兼容性:杯子是否能夠容納果汁、白水、酒精、汽油等易用性:杯子是否燙手、是否有防滑措施、是否方便飲用用戶文檔:使用手冊是否對杯子的用法、限制、使用條件等有詳細描述疲勞測試:將杯子盛上水(案例一)放小時檢查泄漏時間和情況盛上汽油(案例二)放24小時檢查泄漏時間和情況等壓力測試:用根針并在針上面不斷加重量，看壓強多大時會穿透跌落測試:杯子加包裝(有填充物),在多高的情況摔下不破損

震動測試:杯子加包裝(有填充物),六面震動檢查產品是否能應對惡劣的鐵路\公路\航空運輸測試數據:測試數據具體編寫此處略。其中應用到場景法、等價類劃分法、因果圖法、錯誤推測法、邊界值法等方法期望輸出:該期望輸出需查閱國標、行標以及使用用戶的需求說明書測試:檢查說明書書寫準確性六、網絡、操作系統、語言知識1請你分別劃劃OSI的七層網絡結構圖，和的五層結構圖答:七層結構從上到下依次是:7應用層;6表示層;5會話層;4傳輸層;3網絡層;2數據鏈路層;1物理層五層結構是5應用層;4運輸層;3網絡層;2鏈路層;1物理層。2請你詳細的解釋一下IP協議的定義，在哪個層上面，主要有什么作用TCP與UDP呢,答:UDP，TCP在傳輸層，IP在網絡層，TCP/IP是英文TransmissionControlProtocol/InternetProtocol縮寫，意思是"傳輸控制協議/網際協議"。TCP/IP議組之所以流行，部分原因是因為它可以用在各種各樣的信道和底層協議(例如和X.25、以太網以及RS-232串行接口)之上。確切地說，TCP/IP協議是一組包括協議和IP協議，UDP(UserDatagramProtocol)協議、ICMP(InternetControlMessageProtocol)議和其他一些協議的協議組。TCP/IP協議并不完全符合的七層參考模型。傳統的開放式系統互連參考模型，是一種通信協議的層抽象的參考模型,其中每一層執行

某一特定任務。該模型的目的是使各種硬件在相同的層次上相互通信。這層是:物理層、數據鏈路層、網路層、傳輸層、話路層、表示層和應用層。而通訊協議采用了4層的層級結構，每一層都呼叫它的下一層所提供的網絡來完成自己的需求。這4層分別為:應用層:應用程序間溝通的層，如簡單電子郵件傳輸(SMTP)、文件傳輸協議(FTP)、網絡遠程訪問協議Telnet)等。傳輸層:在此層中，它提供了節點間的數據傳送服務，如傳輸控制協議TCP)、用戶數據報協議(UDP)等，TCP和UDP給數據包加入傳輸數據并把它傳輸到3請問交換機和路由器分別的實現原理是什么分別在哪個層次上面實現的,一般意義上說交換機是工作在數據鏈路層。但隨著科技的發展，現在有了三層交換機，三層交換機已經擴展到了網絡層。也就是說它等于“數據鏈路層+部分網絡層”。交換機中傳的是幀。通過存儲轉發來實現的。路由器是工作在網絡層。路由器中傳的是IP數據報。主要是選址和路由。4請問C++的類和C里面的STRUCT有什么區別答:除關鍵字不同外(class,struct)的唯一區別是結構在默認情況下的成員是公共(public),而類在默認情況下的成員是私有(private)。在C++中,結構是特殊的類。class是從struct發展而來的。之所以將和class保留，是因為:1、提出class是為了強調一種概念。2、保留struct是為了照顧到大多數人的習慣。struct和class是有區別的。struct保證成員按照聲明順序在內存中存儲。不保證等等而它們都可以繼承，實現多態等。但也有少許區別。比如structA{};

classB:A{};//private繼承structC:B{};//public繼承這是由于class默認是private，struct認是public。一般說來，struct和class可以換用當然要注意一些語法問題)。而struct更適合看成是一個數據結構的實現體，class更適合看成是一個對象的實現體，對私有成員進行保護，還提供與外界的接口。從習慣上更喜歡用class。5請講一講析構函數和虛函數的用法和作用答:置于“,”是析構函數;析構函數因使用~"符號(邏輯非運算符)，表示它為膩構造函數，加上類名稱來定義。;析構函數也是特殊的類成員函數，它沒有返回類型，沒有參數，不能隨意調用，也沒有重載，只有在類對象的生命期結束的時候，由系統自動調用。有適放內存空間的做用!虛函數是C++多態的一種表現例如:子類繼承了父類的一個函數(方法，而我們把父類的指針指向子類，則必須把父類的該函數(方法)設為virturl(函數)。使用虛函數，我們可以靈活的進行動態綁定，當然是以一定的開銷為代價。如果父類的函數(方法)根本沒有必要或者無法實現，完全要依賴子類去實現的話，可以把此函數(方法)設為virturl函數名=0我們把這樣的函數(方法)稱為純虛函數。如果一個類包含了純虛函數，稱此類為抽象類6全局變量和局部變量有什么區別,實怎么實現的操作系統和編譯器是怎么知道的,

答:主要的區別是變量的作用范圍不同。全局變量在全局范圍內都有效，而局部變量只在聲明此變量的作用域內有效。全局變量是屬于實例的,在初始化對象的時候初始化，生命周期與該實例相同，之所以叫全局變量是因為該實例中的所有方法或屬性都可以引用局部變量是在實例方法內或static塊中，生命周期從調用該方法到該方法退出，并且只有該方法能夠引用之。全局變量和局部變量的區別是在存儲器中位置不同，具體說，全局變量存儲在數據段中，局部變量都有可能，一般來說在堆棧段7一些寄存器的題目，主要是尋址和內存管理等一些知識。答:尋址方式表示指令中操作數所在的方法稱為尋址方式。有七種基本的尋址方式:立即尋找，寄存器尋址，直接尋址，寄存器間接尋址，寄存器相對尋址，基址加變址尋址，相對基址加變址尋址。直接尋址、寄存器間接尋址、寄存器相對尋址、基址加變址尋址和相對基址加變址尋址，這五種尋址方式屬于存儲器尋址，用于說明操作數所在存儲單元的地址。由于總線接口單元BIU能根據需要自動引用段寄存器得到段值，所以這五種方式也就是確定存放操作數的存儲單元有效地址的方法。有效地址EA是一個16位的無符號數，在利用這五種方法計算有效地址時，所得的結果認為是一個無符號數。除了這些基本的尋址方式外，還有固定尋址和端口尋址等。內存管理主要包括內存的分配和回收整理等，實現內存的高效利用。Q8:8086是多少位的系統,在數據總線上是怎么實現的

答:16位系統,8位數據傳送,通過總線控制邏輯實現數據線和地址線的分時復用.8086是Inter的16位微處理器有16根數據線和20根地址線，它既能處理位數據，也能處理位數據內部數據總線都是按16位設計的，單外部數據總線只有條七、其他一、談談你了解的軟件測試流程及工具一般測試流程:1.需求分析階段:對業務的學習，分析需求點。2.測試計劃階段:測試組長根據SOW開始編寫《測試計劃》，其中包括人員，軟件硬件資源，測試點，集成順序，進度安排和風險識別等內容。3.測試設計階段:測試方案一般由對需求很熟的高資深的測試工程師設計，測試方案要求根據《SRS》上的每個需求點設計出包括需求點簡介，測試思路和詳細測試方法三部分的方案。《測試方案》編寫完成后也需要進行評審。4.測試方案階段:主要是對測試用例和規程的設計。測試用例是根據《測試方案》來編寫的，通過《測試方案》階段，測試人員對整個系統需求有了詳細的理解。這時開始編寫用例才能保證用例的可執行和對需求的覆蓋。測試用例需要包括測試項，用例級別，預置條件，操作步驟和預期結果。其中操作步驟和預期結果需要編寫詳細和明確。測試用例應該覆蓋測試方案，而測試方案又覆蓋了測試需求點，這樣才能保證客戶需求不遺漏。同樣，測試用例也需要評審。5.測試執行階段:執行測試用例，及時提交有質量的和測試日報，測試報告等相關文檔。流程:需求分析?測試計劃?測試設計?測試環境搭建測試執行?測試記錄?缺陷管理?軟件評估?RTM.測試工具:

C/S及B/S架構相關的軟件產品，那么對不同操作系統，如系列、unix、linux甚至蘋果OS等測試環境都是必須的常用的軟件測試工具分為:開源測試管理工具:Bugfree、BugzillaTestLink、mantis開源功能自動化測試工具:Watir、SeleniumMaxQ、WebInject開源性能自動化測試工具:Jmeter、OpenSTA、DBMonsterTPTEST、WebApplicationLoadSimulator[TestDirector]:企業級測試管理工具，也是業界第一個基于的測試管理系統。[QualityCenter]:基于Web的測試管理工具，可以組織和管理應用程序測試流程的所有階段，包括指定測試需求、計劃測試、執行測試和跟蹤缺陷。[QuickTestProfessional]:用于創建功能和回歸測試。[LoadRunner]:預測系統行為和性能的負載測試工具。二、如何發現客戶端軟件中的內存泄露檢測內存泄漏的問題應該盡早進行，它絕不應該是系統測試時的主要目標。也就是說，檢查是否存在內存泄漏，應該從編碼時就要考慮，單元測試和集成測試時要重點檢查。如果前期沒有考慮，等到了系統測試才想起檢查或者才發現泄漏，為時已晚，此時再去定位泄漏的位置，太難太難了，它可能會讓你的交付日期不確定的時間。最近看了一些自動錯誤預防(AEP)的理論，我深受啟發。作為測試人員的我們，從“發現錯誤”轉變到“幫助開發人員預防錯誤”，這將是一個巨大的轉變。所以說，下面我的答案中的第一點，我先說如何預防內存泄漏的問題，然后再講如何發現。1如何在開發過程中有效預防內存泄漏第一步:遵循“好”的編程規則

“好”的編程規則是各位前輩經驗和教訓的集合，好的編程規則堪稱開發者的“圣經”。遵循統一的編程規則，可以讓開發新手少走好多彎路，可以讓項目整體的質量維持一個起碼的“質量底線”。有關內存泄漏方面的規則主要是“內存管理”方面的，舉幾個簡單的，如下×用malloc或new申請內存之后，立即檢查指針值是否為止使用指針值為NULL的內存)×動態內存的申請與釋放是否配對(防止內存泄漏×malloc語句是否正確無誤,例如字節數是否正確類型轉換是否正確×是否出現野指針，例如用free或delete釋放了內存之后，忘記將指針設置為NULL......第二步:積極主動檢測“內存泄漏”嚴格遵循好的編程規則，可以讓程序員在代碼中盡量少的引入，但一旦不小心引入了，怎么辦,這就要求我們在單元測試和集成測試中嚴格把關。在這個階段，單靠程序員或者測試員通過“代碼走查”的方式檢查內存泄漏，客戶的實踐和我的經驗告訴我，這將是“不切實際”的，無論效率還是時間。如果能夠借助于一些專業的工具的話，情況可能就不一樣了。如果你的程序是用VisualC++6.0開發，那么Numega的BoundsChecker是你檢測“內存泄漏”最好的選擇，如果是C++.NET，可以試一下Compuware的DevPartner。如果你的程序基于Unix或者Linux平臺，使用或者C++，可以考慮一下開源的工具valgrind，我的朋友跟我說，它在一定程度上比的Purify更出色。上面的工具都要求程序能夠動態運行起來，而且測試用例需要你自己準備。如果你正處于單元測試或集成測試階段，程序代碼量已經足夠大，而且還不能夠動

態運行，要盡早檢測代碼中的“內存泄漏”問題，該怎么辦此時你可以試用一下目前最新的靜態分析技術:×它不要求代碼能夠動態運行×也不需要你來編寫測試用例×只需要代碼能夠正常編譯，就可以發現代碼只有在執行過程中才出現的錯誤，當然也包括內存泄漏。這方面的工具有Klocwork的K7，CoveritySQS，以及C++test中的Bug