- 相關(guān)推薦
軟件測試筆試題目分享
無(wú)論是在學(xué)校還是在社會(huì )中，我們最不陌生的就是試題了，借助試題可以更好地對被考核者的知識才能進(jìn)行考察測驗。大家知道什么樣的試題才是好試題嗎？下面是小編精心整理的軟件測試筆試題目分享，僅供參考，歡迎大家閱讀。
軟件測試筆試題目分享
1、軟件測試、的目的是盡可能多的找出軟件的缺陷。（Y)
2Beta、測試是驗收測試的一種。（Y)
Acceptance、testing
驗收測試是部署軟件之前的最后一個(gè)測試操作。驗收測試的目的是確保軟件準備就緒，并且可以讓最終用戶(hù)將其用于執行軟件的既定功能和任務(wù)。
3、驗收測試是由最終用戶(hù)來(lái)實(shí)施的。（N）
是由測試人員來(lái)實(shí)施的
4、項目立項前測試人員不需要提交任何工件。（Y）、工件：加工過(guò)程中生產(chǎn)對象
5、單元測試能發(fā)現約80%、的軟件缺陷。（Y）
6、代碼評審是檢查源代碼是否達到模塊設計的要求。（N）
代碼評審也稱(chēng)代碼復查，是指通過(guò)閱讀代碼來(lái)檢查源代碼與編碼標準的符合性以及代碼質(zhì)量的活動(dòng)。
7、自底向上集成需要測試員編寫(xiě)驅動(dòng)程序。（Y）
自頂向下綜合測試的具體步驟為：
1、以主控模塊作為測試驅動(dòng)模塊，把對主控模塊進(jìn)行單元測試時(shí)引入的所有樁模塊用實(shí)際模塊替代;
2、依據所選的集成策略(深度優(yōu)先或廣度優(yōu)先)，每次只替代一個(gè)樁模塊;
3、每集成一個(gè)模塊立即測試一遍;
4、只有每組測試完成后，才著(zhù)手替換下一個(gè)樁模塊;
5、為避免引入新錯誤，須不斷地進(jìn)行回歸測試(即全部或部分地重復已做過(guò)的測試)。
自底向上綜合測試的步驟分為：
1、把低層模塊組織成實(shí)現某個(gè)子功能的模塊群(cluster);
2、開(kāi)發(fā)一個(gè)測試驅動(dòng)模塊，控制測試數據的輸入和測試結果的輸出;
3、對每個(gè)模塊群進(jìn)行測試;
4、刪除測試使用的驅動(dòng)模塊，用較高層模塊把模塊群組織成為完成更大功能的新模塊群。
8、負載測試是驗證要檢驗的系統的能力最高能達到什么程度。（N）
負載測試(Load、testing)，通過(guò)測試系統在資源超負荷情況下的表現，以發(fā)現設計上的錯誤或驗證系統的負載能力。在這種測試中，將使測試對象承擔不同的工作量，以評測和評估測試對象在不同工作量條件下的性能行為，以及持續正常運行的能力。負載測試的目標是確定并確保系統在超出最大預期工作量的情況下仍能正常運行。此外，負載測試還要評估性能特征。例如，響應時(shí)間、事務(wù)處理速率和其他與時(shí)間相關(guān)的方面。
9、測試人員要堅持原則，缺陷未修復完堅決不予通過(guò)。（N）
10、代碼評審員一般由測試員擔任。（N）
11、我們可以人為的使得軟件不存在配置問(wèn)題。（N）
是一種標識、組織和控制修改的技術(shù)。軟件配置管理應用于整個(gè)軟件工程過(guò)程。我們知道，在軟件建立時(shí)變更是不可避免的，而變更加劇了項目中軟件開(kāi)發(fā)者之間的混亂。
12、集成測試計劃在需求分析階段末提交。（N）
執行階段
1)時(shí)間安排、單元測試已經(jīng)完成后就可以開(kāi)始執行集成測試了
2)輸入、需求規格說(shuō)明書(shū)、概要設計、集成測試計劃、集成高度設計、集成測試例、集成測試規程、集成測試代碼(如果有)、集成測試腳本、集成測試工具、詳細設計、代碼、單元測試報告
3)入口條件、單元測試階段已經(jīng)通過(guò)基線(xiàn)化評審
4)活動(dòng)步、驟、執行集成測試用例、回歸集成測試用例、撰寫(xiě)集成測試報告
5)輸出、集成測試報告
6)出口條件、集成測試報告通過(guò)集成測試階段基線(xiàn)評審
二、選擇題
1、軟件驗收測試的合格通過(guò)準則是：(ABCD)
A、軟件需求分析說(shuō)明書(shū)中定義的所有功能已全部實(shí)現，性能指標全部達到要求。
B、所有測試項沒(méi)有殘余一級、二級和三級錯誤。
C、立項審批表、需求分析文檔、設計文檔和編碼實(shí)現一致。
D、驗收測試工件齊全。
2、軟件測試計劃評審會(huì )需要哪些人員參加?（ABCD）
A、項目經(jīng)理
B、SQA、負責人
軟件質(zhì)量保證(SQA)是建立一套有計劃
目標、1：軟件質(zhì)量保證工作是有計劃進(jìn)行的。
目標、2：客觀(guān)地驗證軟件項目產(chǎn)品和工作是否遵循恰當的標準、步驟和需求。
目標、3：將軟件質(zhì)量保證工作及結果通知給相關(guān)組別和個(gè)人。
目標、4：高級管理層接觸到在項目?jì)炔坎荒芙鉀Q的不符合類(lèi)問(wèn)題。
C、配置負責人
D、測試組
3、下列關(guān)于alpha、測試的描述中正確的是：（AD）
A、alpha、測試需要用戶(hù)代表參加
B、alpha、測試不需要用戶(hù)代表參加
C、alpha、測試是系統測試的一種
D、alpha、測試是驗收測試的一種
4、測試設計員的職責有：（BC）
A、制定測試計劃
B、設計測試用例
C、設計測試過(guò)程、腳本
D、評估測試活動(dòng)
5、軟件實(shí)施活動(dòng)的進(jìn)入準則是：（ABC）
A、需求工件已經(jīng)被基線(xiàn)化
工件加工過(guò)程中的生產(chǎn)對象。
基線(xiàn)化、一個(gè)文檔如果經(jīng)過(guò)討論被通過(guò)了，被固定了，就可以說(shuō)這個(gè)文檔被“基線(xiàn)化”了，然后所有人就可以在這個(gè)“基線(xiàn)”的基礎上工作。
B、詳細設計工件已經(jīng)被基線(xiàn)化
C、構架工件已經(jīng)被基線(xiàn)化
D、項目階段成果已經(jīng)被基線(xiàn)化
三、添空
1、軟件驗收測試包括：_正式驗收測試，alpha測試，beta測試。
2、系統測試的策略有：功能測試，性能測試，可靠性測試，負載測試，易用性測試，強度測試，安全測試，配置測試，安裝測試，卸載測試，文擋測試，故障恢復測試，界面測試，容量測試，兼容性測試，分布測試，可用性測試
(有的可以合在一起，分開(kāi)寫(xiě)只要寫(xiě)出15、就滿(mǎn)分哦)
3、設計系統測試計劃需要參考的項目文擋有：軟件測試計劃，軟件需求工件和迭代計劃。
4、對面向過(guò)程的系統采用的集成策略有：自頂向下，自底向上兩種。
5、通過(guò)畫(huà)因果圖來(lái)寫(xiě)測試用例的步驟為：
(1)根據程序規格說(shuō)明書(shū)描述，分析并確定因(輸入條件)和果(輸出結果或程序狀態(tài)的改變)，畫(huà)出因果圖。
(2)將得到的因果圖轉換為判定表。
(3)為判定表中每一列所表示的情況設計一個(gè)測試用例。
四、簡(jiǎn)答
1、區別階段評審的與同行評審
答：
同行評審目的:發(fā)現小規模工作產(chǎn)品的錯誤,只要是找錯誤;
階段評審目的:評審模塊、階段作品的正確性、可行性、及完整性
同行評審人數:3-7人、人員必須經(jīng)過(guò)同行評審會(huì )議的培訓,由SQA指導
階段評審人數:5人左右、評審人必須是專(zhuān)家、具有系統評審資格
同行評審內容:內容小、一般文檔、<40頁(yè)、代碼、<500行
階段評審內容：內容多,主要看重點(diǎn)
同行評審時(shí)間:一小部分工作產(chǎn)品完成
階段評審時(shí)間：通常是設置在關(guān)鍵路徑的時(shí)間點(diǎn)上!
2、什么是軟件測試
答：測試是為發(fā)現錯誤而執行程序的過(guò)程
軟件測試就是利用測試工具按照測試方案和流程對產(chǎn)品進(jìn)行功能和性能測試，甚至根據需要編寫(xiě)不同的測試工具，設計和維護測試系統，對測試方案可能出現的問(wèn)題進(jìn)行分析和評估。執行測試用例后，需要跟蹤故障，以確保開(kāi)發(fā)的產(chǎn)品適合需求。
3、簡(jiǎn)述集成測試的過(guò)程
答：系統集成測試主要包括以下過(guò)程：
1、構建的確認過(guò)程。
2、補丁的確認過(guò)程。
3、系統集成測試測試組提交過(guò)程。
4、測試用例設計過(guò)程。
5、測試代碼編寫(xiě)過(guò)程。
6Bug的報告過(guò)程。
7、每周/每?jì)芍艿臉嫿ㄟ^(guò)程。
8、點(diǎn)對點(diǎn)的測試過(guò)程。
9、組內培訓過(guò)程。
5、白盒測試有幾種方法
答：總體上分為靜態(tài)方法和動(dòng)態(tài)方法兩大類(lèi)。
靜態(tài)：關(guān)鍵功能是檢查軟件的表示和描述是否一致,沒(méi)有沖突或者沒(méi)有歧義。
動(dòng)態(tài)：語(yǔ)句覆蓋、判定覆蓋、條件覆蓋、判定條件覆蓋、條件組合覆蓋、路徑覆蓋。
6、系統測試計劃是否需要同行審批，為什么
答：需要，系統測試計劃屬于項目階段性關(guān)鍵文檔，因此需要評審。
7Alpha、測試與beta、的區別
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)管理。
答：Alpha、測試、在系統開(kāi)發(fā)接近完成時(shí)對應用系統的測試;測試后仍然會(huì )有少量的設計變更。這種測試一般由最終用戶(hù)或其它人員完成，不能由程序或測試員完成。
Beta、測試、當開(kāi)發(fā)和測試根本完成時(shí)所做的測試，最終的錯誤和問(wèn)題需要在最終發(fā)行前找到。這種測試一般由最終用戶(hù)或其它人員完成，不能由程序員或測試員完成。
8、比較負載測試，容量測試和強度測試的區別
答：負載測試：在一定的工作負荷下，系統的負荷及響應時(shí)間。
強度測試：在一定的負荷條件下，在較長(cháng)時(shí)間跨度內的系統連續運行給系統性能所造成的影響。
容量測試：容量測試目的是通過(guò)測試預先分、析出反映軟件、系統應用特征的某項指標的極限值(如最大并發(fā)用戶(hù)數、數據庫記錄數等)，系統在其極限值狀態(tài)下沒(méi)有出現任何軟件故障或還能保持主要功能正常運行。容量測試、還將確定測試對象在給定時(shí)間內能夠持續處理的最大負載或工作量。容量測試的目的是使系統承受超額的數據容量來(lái)發(fā)現它是否能夠正確處理。容量測試是面向數據、的，并且它的目的是顯示系統可以處理目標內確定的數據容量。
9、測試結束的標準是什么?
答：用例全部測試。
覆蓋率達到標準。
缺陷率達到標準。
其他指標達到質(zhì)量標準。
10、描述軟件測試活動(dòng)的生命周期?
答：
測試周期分為計劃、設計、實(shí)現、執行、總結。其中：
計劃：對整個(gè)測試周期中所有活動(dòng)進(jìn)行規劃，估計工作量、風(fēng)險，安排人力物力資源，安排進(jìn)度等;
設計：完成測試方案，從技術(shù)層面上對測試進(jìn)行規劃;
實(shí)現：進(jìn)行測試用例和測試規程設計;
執行：根據前期完成的計劃、方案、用例、規程等文檔，執行測試用例。
總結：記錄測試結果，進(jìn)行測試分析，完成測試報告。
11、軟件的缺陷等級應如何劃分?
A、類(lèi)—、嚴重錯誤，包括以下各種錯誤：
1、由于程序所引起的死機,、非法退出
2、死循環(huán)
3、數據庫發(fā)生死鎖
4、因錯誤操作導致的程序中斷
5、功能錯誤
6、與數據庫連接錯誤
7、數據通訊錯誤
B、類(lèi)—、較嚴重錯誤，包括以下各種錯誤：
1、程序錯誤
2、程序接口錯誤
3、數據庫的表、業(yè)務(wù)規則、缺省值未加完整性等約束條件
C、類(lèi)—、一般性錯誤，包括以下各種錯誤：
1、操作界面錯誤(包括數據窗口內列名定義、含義是否一致)
2、打印內容、格式錯誤
3、簡(jiǎn)單的輸入限制未放在前臺進(jìn)行控制
4、刪除操作未給出提示
5、數據庫表中有過(guò)多的空字段
D、類(lèi)—、較小錯誤，包括以下各種錯誤：
1、界面不規范
2、輔助說(shuō)明描述不清楚
3、輸入輸出不規范
4、長(cháng)操作未給用戶(hù)提示
5、提示窗口文字未采用行業(yè)術(shù)語(yǔ)
6、可輸入區域和只讀區域沒(méi)有明顯的區分標志
E、類(lèi)—、測試建議
4、怎么做好文檔測試
仔細閱讀，跟隨每個(gè)步驟，檢查每個(gè)圖形，嘗試每個(gè)示例。
檢查文檔的編寫(xiě)是否滿(mǎn)足文檔編寫(xiě)的目的
內容是否齊全，正確
內容是否完善
標記是否正確
軟件測試筆試題目分享(二)
1、TCP是互聯(lián)網(wǎng)中的(1、A)協(xié)議，使用(2C)次握手協(xié)議建立連接。當主動(dòng)發(fā)出SYN連接請求后，等待對方回答(3、A)。這種連接的方法可以防止(4D)，TCP使用的流量控制協(xié)議是(5B)。
(1)A.傳輸層B.網(wǎng)絡(luò )層C會(huì )話(huà)層D.應用層
(2)A.1B.2C.3D.4
(3)A.SYN,ACKB.FIN,ACKC.PSH,ACKD.RST,ACK
(4)A.出現半連接B.無(wú)法連接C.假冒的連接D.產(chǎn)生錯誤的連接
(5)A.固定大小的滑動(dòng)窗口協(xié)議B.可變大小的滑動(dòng)窗口協(xié)議C.后退N幀ARQ協(xié)議D.選擇重發(fā)ARQ協(xié)議
2、下列敘述中，與提高軟件可移植性相關(guān)的是D。
A.選擇時(shí)間效率高的算法
B.盡可能減少注釋
C.選擇空間效率高的算法
D.盡量用高級語(yǔ)言編寫(xiě)系統中對效率要求不高的部分
D軟件可移植性是指與軟件可從某一環(huán)境移植到另一環(huán)境的能力有關(guān)的一組屬性。高級語(yǔ)言具有較好的可移植性，所以可以盡量用高級語(yǔ)言編寫(xiě)系統中對效率要求不高的部分。減少注釋、選擇時(shí)間/空間效率高的算法都不能提高軟件的可移植性。
3、用邊界值分析法，假定1 A.X=1，X=100;B.X=0，X=1，X=100，X=101; C.X=2，X=99;D.X=O，X=101; 4、在網(wǎng)絡(luò )應用測試中，網(wǎng)絡(luò )延遲是一個(gè)重要指標。以下關(guān)于網(wǎng)絡(luò )延遲的理解，正確的是__D____ A.指響應時(shí)間; B.指報文從客戶(hù)端發(fā)出到客戶(hù)端接收到服務(wù)器響應的間隔時(shí)間; C.指報文在網(wǎng)絡(luò )上的傳輸時(shí)間; D.指從報文開(kāi)始進(jìn)入網(wǎng)絡(luò )到它開(kāi)始離開(kāi)網(wǎng)絡(luò )之間的時(shí)間 網(wǎng)絡(luò )延遲：在傳輸介質(zhì)中傳輸所用的時(shí)間，即從報文開(kāi)始進(jìn)入網(wǎng)絡(luò )到它開(kāi)始離開(kāi)網(wǎng)絡(luò )之間的時(shí)間。 5、軟件可靠性是指在指定的條件下使用時(shí)，軟件產(chǎn)品維持規定的性能級別的能力，其子特性(C)是指在軟件發(fā)生故障或者違反指定接口的情況下，軟件產(chǎn)品維持規定的性能級別的能力。 A.成熟性;B.易恢復性;C.容錯性;D.可靠性依從性 國家標準GB/T、16260《軟件產(chǎn)品評價(jià)-質(zhì)量特性及其使用指南》規定了軟件產(chǎn)品的六個(gè)質(zhì)量特性，并推薦了與之對應的27個(gè)子特性，質(zhì)量特性和子特性列表如下： 質(zhì)量特性描述子特性子特性描述功能性 當軟件在指定條件下使用時(shí)，軟件產(chǎn)品滿(mǎn)足明確和隱含要求功能的能力適合性軟件產(chǎn)品為指定的任務(wù)和用戶(hù)目標提供一組合適的功能的能力準確性軟件產(chǎn)品具有所需精確度的正確或相符的結果及效果的能力互操作性軟件產(chǎn)品與一個(gè)或更多的規定系統進(jìn)行交互的能力功能性依從性軟件產(chǎn)品依附于同功能性相關(guān)的標準、約定或法規以及類(lèi)似規定的能力安全保密軟件產(chǎn)品保護信息和數據的能力，以使未授權的人員或系統不能閱讀或修改這些信息和數據，但不拒絕授權人員或系統對它們的訪(fǎng)問(wèn)�？煽啃攒浖a(chǎn)品維持規定的性能級別的能力成熟性軟件產(chǎn)品避免因軟件中錯誤的發(fā)生而導致失效的能力容錯性在軟件發(fā)生故障或者違反指定接口的情況下，軟件產(chǎn)品維持規定的性能級別的能力易恢復性在失效發(fā)生的情況下，軟件產(chǎn)品重建規定的性能級別并恢復受直接影響的數據的能力可靠性依從性軟件產(chǎn)品依附于同可靠性相關(guān)的標準、約定或規定的能力易用性軟件產(chǎn)品在指定條件下使用時(shí)，軟件產(chǎn)品被理解、學(xué)習、使用和吸引用戶(hù)的能力易理解性軟件產(chǎn)品使用戶(hù)能理解軟件是否適合以及如何能將軟件用于特定的任務(wù)和使用環(huán)境的能力。易學(xué)性軟件產(chǎn)品使用戶(hù)能學(xué)習它的能力易操作性軟件產(chǎn)品使用戶(hù)能操作和控制它的能力吸引性軟件產(chǎn)品吸引用戶(hù)的能力易用性依從性軟件產(chǎn)品依附于同易用性相關(guān)的標準、約定或規定的能力效率在規定條件下，相對于所用資源的數量，軟件產(chǎn)品提供適當的性能的能力時(shí)間特性在規定條件下，軟件產(chǎn)品執行其功能時(shí)，提供適當的相應時(shí)間和處理時(shí)間以及吞吐率的能力資源特性在規定條件下，軟件產(chǎn)品執行其功能時(shí)，使用合適的數量和類(lèi)型的資源的能力效率依從性軟件產(chǎn)品依附于同效率相關(guān)的標準、約定或規定的能力維護性軟件產(chǎn)品可被修改的能力。修改可能包括修正、改進(jìn)或軟件適應環(huán)境、需求和功能規格說(shuō)明中的變化易分析性軟件產(chǎn)品診斷軟件中的缺陷或失效原因，以及判定待修改的部分的能力易改變性指軟件產(chǎn)品使指定的修改可以被實(shí)現的能力穩定性軟件產(chǎn)品避免由于軟件修改而造成以外結果的能力易測試性軟件產(chǎn)品使已修改軟件能被確認的能力維護性依從性軟件產(chǎn)品依附于同維護性相關(guān)的標準、約定或規定的能力可移植性軟件產(chǎn)品從一種環(huán)境遷移到另外一種環(huán)境的能力適應性指軟件產(chǎn)品無(wú)需采用有別于為考慮該軟件的目的而準備的活動(dòng)或手段，就可能適應不同的指定環(huán)境的能力易安裝性軟件產(chǎn)品在指定環(huán)境中被安裝的能力共存性軟件產(chǎn)品在公共環(huán)境中同與其分享公共資源的其他獨立軟件共存的能力易替換性軟件產(chǎn)品在環(huán)境相同、目的相同的情況下替代另一個(gè)指定軟件產(chǎn)品的能力可移植性依從性軟件產(chǎn)品依附于同可移植性相關(guān)的標準、約定或規定的能力 6、關(guān)于軟件質(zhì)量的描述，正確的是__B____ A.軟件質(zhì)量是指軟件滿(mǎn)足規定用戶(hù)需求的能力; B.軟件質(zhì)量特性是指軟件的功能性、可靠性、易用性、效率、可維護性、可移植性; C.軟件質(zhì)量保證過(guò)程就是軟件測試過(guò)程; D.以上描述都不對 解析：軟件質(zhì)量就是“軟件與明確的和隱含的定義的需求相一致的程度”。 7、(1A)是面向對象程序設計語(yǔ)言不同于其它語(yǔ)言的主要特點(diǎn)，是否建立了豐富的(2B)是衡量一個(gè)面向對象程序設計語(yǔ)言成熟與否的重要標志之一。 (1)A.繼承性;B.消息傳遞;C.多態(tài)性;D.靜態(tài)聯(lián)編; (2)A.函數庫;B.類(lèi)庫;C.類(lèi)型庫;D.方法庫; 8、8位ASCII編碼的最大編碼值為_(kāi)__D___ A.128B.127C.256D.255 9、對計算機軟件和硬件資源進(jìn)行管理和控制的軟件是_D_____ A.文件管理程序B.輸入輸出管理程序C.命令處理程序D.操作系統 操作系統(Operating、System，簡(jiǎn)稱(chēng)OS)是一管理電腦硬件與軟件資源的程序，同時(shí)也是計算機系統的內核與基石。 10、下列說(shuō)法正確的是___D___ A.給計算機加電稱(chēng)為熱啟動(dòng) B.計算機死機后常用冷啟動(dòng)計算機 C.可用Ctrl+Alt+Del鍵對計算機冷啟動(dòng) D.可用Ctrl+Alt+Del按鈕對計算機熱啟動(dòng) 熱啟動(dòng)就是、按、ctrl+alt+、的重啟。冷啟動(dòng)是按機箱上的電源(power)按鈕的開(kāi)機。 11、1024B是___A___ A.1KBB.1MBC.1GBD.1Gb 1個(gè)字節等于8位二進(jìn)制，1TB=1024GB、1GB=1024MB、1MB=1024KB、1KB=1024Byte 12、衡量計算機的平均無(wú)故障時(shí)間是計算機的__A____ A.可靠性B.可維護性C.適應性D.穩定性 MTBF，即平均無(wú)故障時(shí)間，英文全稱(chēng)是“Mean、TimeBetween、Failure”。是衡量一個(gè)產(chǎn)品(尤其是電器產(chǎn)品)的可靠性指標。 13、十進(jìn)制102轉換為二進(jìn)制是___B___ A.1100111B.1100110C.1100001D.101111 102=1100110 14、在Windows中，下列可以作為文件名的是___D___ A.a?.txtB.abc>.docC.abc*.xlsD.Rula.bmp 1、允許文件或者文件夾名稱(chēng)不得超過(guò)255個(gè)字符。 2、文件名除了開(kāi)頭之外任何地方都可以使用空格。 3、文件名中不能有下列符號：“?”、“、”、“╲”、“*”、““”、“”“、“”、“|”。 4、Windows、98文件名不區分大小寫(xiě)，但在顯示時(shí)可以保留大小寫(xiě)格式。 5、文件名中可以包含多個(gè)間隔符，如“我的文件。我的圖片。001”。 15、SNMP、所采用的傳輸層協(xié)議是__A____ A.UDPB.ICMPC.TCPD.IP 簡(jiǎn)單網(wǎng)絡(luò )管理協(xié)議(SNMP)是目前TCP/IP網(wǎng)絡(luò )中應用最為廣泛的網(wǎng)絡(luò )管理協(xié)議，SNMP使用UDP(用戶(hù)數據報協(xié)議)作為第四層協(xié)議(傳輸協(xié)議)，進(jìn)行無(wú)連接操作。 16、為保證測試活動(dòng)的可控性，必須在軟件測試過(guò)程中進(jìn)行軟件測試配置管理，一般來(lái)說(shuō)，軟件測試配置管理中最基本的活動(dòng)包括__A____ A.配置項標識、配置項控制、配置狀態(tài)報告、配置審計 B.配置基線(xiàn)確立、配置項控制、配置報告、配置審計 C.配置項標識、配置項變更、配置審計、配置跟蹤 D.配置項標識、配置項控制、配置狀態(tài)報告、配置跟蹤 17、___B___方法根據輸出對輸入的依賴(lài)關(guān)系設計測試用例。 A.路徑測試B.等價(jià)類(lèi)C.因果圖D.邊界值 18、在C++語(yǔ)言中，若類(lèi)C中定義了一個(gè)方法int、f(int、a，int、b)，那么方法___A___不能與該方法同時(shí)存在于類(lèi)C中 A.int、f(int、x，int、y)B.int、f(float、a，int、b) C.float、f(int、x，float、y)D.int、f(int、x，float、y) 19、下列關(guān)于軟件驗收測試的合格通過(guò)準則錯誤的是：____C__ A、軟件需求分析說(shuō)明書(shū)中定義的所有功能已全部實(shí)現，性能指標全部達到要求; B、所有測試項沒(méi)有殘余一級、二級和三級錯誤; C、立項審批表、需求分析文檔、設計文檔和編碼實(shí)現不一致; D、驗收測試工件齊全 軟件驗收測試合格通過(guò)準則：1軟件需求分析說(shuō)明書(shū)中定義的所有功能已全部實(shí)現，性能指標全部達到要求。2所有測試項沒(méi)有殘余的一級二級三級的錯誤。3立項審批表、需求分析文檔、設計文檔和編碼實(shí)現一致。4驗收測試工件齊全(測試計劃，測試用例，測試日志，測試通知單，測試分析報告) 20、測試設計員的職責有：___B___ �、僦贫y試計劃、②設計測試用例、③設計測試過(guò)程、腳本、④評估測試活動(dòng) A.①④B.②③C.①③D.以上全是 測試設計員的職責：確定并描述相應的測試技術(shù)、確定相應的測試支持工具、定義并維護測試自動(dòng)化架構、 詳述和驗證需要的測試環(huán)境配置、驗證與評估測試途徑 21、對于業(yè)務(wù)流清晰的系統可以利用D貫穿整個(gè)測試用例設計過(guò)程廣在用例中綜合使用各種測試方法，對于參數配置類(lèi)的軟件，要用C選擇較少的組合方式達到最佳效果，如果程序的功能說(shuō)明中含有輸入條件的組合情況，則一開(kāi)始就可以選用B和判定表驅動(dòng)法 A.等價(jià)類(lèi)劃分B.因果圖法C.正交試驗法D.場(chǎng)景法、 因果圖適合于檢查程序輸入條件涉及的各種組合情況，正交實(shí)驗法就是利用排列整齊的表、-正交表來(lái)對試驗進(jìn)行整體設計、綜合比較、統計分析，實(shí)現通過(guò)少數的實(shí)驗次數找到較好的生產(chǎn)條件，以達到最高生產(chǎn)工藝效果 22、下列軟件實(shí)施活動(dòng)的進(jìn)入準則描述錯誤的是：__D____ A.需求工件已經(jīng)被基線(xiàn)化 B.詳細設計工件已經(jīng)被基線(xiàn)化 C.構架工件已經(jīng)被基線(xiàn)化 D.項目階段成果已經(jīng)被基線(xiàn)化 23、軟件的六大質(zhì)量特性包括：___A___ �、俟δ苄�、可靠性、②可用性、效率、③穩定性、可移植、④兼容性、可擴展性 A.①②③B.②③④C.①③④D.①②④ 24、正式的技術(shù)評審FTR(Formal、Technical、Review)是軟件工程師組織的軟件質(zhì)量保證活動(dòng)，下面關(guān)于FTR指導原則中錯誤的是___C___ A.評審產(chǎn)品，而不是評審生產(chǎn)者的能力 B.要有嚴格的評審計劃，并遵守日程安排 C.對評審中出現的問(wèn)題要充分討論，以求徹底解決 D.限制參與者人數，并要求評審會(huì )之前做好準備 正式技術(shù)評審(FTR)是一種由軟件工程師和其他人進(jìn)行的軟件質(zhì)量保障活動(dòng)。 1、目標 (1)、發(fā)現功能、邏輯或實(shí)現的錯誤 (2)、證實(shí)經(jīng)過(guò)評審的軟件的確滿(mǎn)足需求 (3)、保證軟件的表示符合預定義的標準 (4)、得到一種一致的方式開(kāi)發(fā)的軟件 (5)、使項目更易管理 2、評審會(huì )議 3-5人參加，不超過(guò)2小時(shí)，由評審主席、評審者和生產(chǎn)者參加，必須做出下列決定中的一個(gè)、：(1)工作產(chǎn)品可不可以不經(jīng)修改而被接受;(2)由于嚴重錯誤而否決工作產(chǎn)品;、(3)暫時(shí)接受工作產(chǎn)品。 3、評審總結報告、回答 評審什么?由誰(shuí)評審?結論是什么?、評審總結報告是項目歷史記錄的一部分，標識產(chǎn)品中存在問(wèn)題的區域，作為行政條目檢查表以指導生產(chǎn)者進(jìn)行改正。 4、評審指導原則 (1)評審產(chǎn)品，而不是評審生產(chǎn)者。注意客氣地指出錯誤，氣氛輕松。 (2)不要離題，限制爭論。有異議的問(wèn)題不要爭論但要記錄在案。 (3)對各個(gè)問(wèn)題都發(fā)表見(jiàn)解。問(wèn)題解決應該放到評審會(huì )議之后進(jìn)行。 (4)為每個(gè)要評審的工作產(chǎn)品建立一個(gè)檢查表。應為分析、設計、編碼、測試文檔都建立檢查表。 (5)分配資源和時(shí)間。應該將評審作為軟件工程任務(wù)加以調度。 (6)評審以前所做的評審 25、下列關(guān)于文檔測試描述錯誤的是___A___ A.文檔測試主要檢查文檔的正確性、完備性、可理解性、可操作性和易維護性; B.正確性是指不要把軟件的功能和操作寫(xiě)錯，也不允許文檔內容前后矛盾; C.完備性是指文檔不可以“虎頭蛇尾”，更不許漏掉關(guān)鍵內容。有些學(xué)生在證明數學(xué)題時(shí)，喜歡用“顯然”兩字蒙混過(guò)關(guān)。文檔中很多內容對開(kāi)發(fā)者可能是“顯然”的，但對用戶(hù)而言不見(jiàn)得都是“顯然”的; D.文檔不可以寫(xiě)成散文、詩(shī)歌或者偵探、言情小說(shuō)，要讓大眾用戶(hù)看得懂，能理解 文檔測試主要檢查文檔的正確性、完備性、可理解性 26、軟件工程的主要環(huán)節有___D___ �、偃藛T管理;②項目管理;③可行性與需求分析;④系統設計;⑤程序設計;⑥測試;⑦維護等 A.①②④⑤⑥⑦B.②③⑤⑥⑦C.①②③④⑤⑥D.以上全是 27、以下關(guān)于集成測試的內容正確的有___D___ �、偌蓽y試也叫組裝測試或者聯(lián)合測試; �、谠诎迅鱾�(gè)模塊連接起來(lái)的時(shí)候，穿越模塊接口的數據是否會(huì )丟失; �、垡粋�(gè)模塊的功能是否會(huì )對另一個(gè)模塊的功能產(chǎn)生不利的影響; �、芨鱾�(gè)子功能組合起來(lái)，能否達到預期要求的父功能; �、萑謹祿Y構是否有問(wèn)題; �、迒蝹�(gè)模塊的誤差累積起來(lái)，是否會(huì )放大，從而達到不能接受的程度; A.①②④⑤⑥B.②③④⑤⑥C.①②③⑤⑥D.以上全部正確 28、新開(kāi)發(fā)的數據庫管理系統中,數據庫管理員張工發(fā)現被用戶(hù)頻繁運行的某個(gè)查詢(xún)處理程序使用了多個(gè)表的連接,產(chǎn)生這一問(wèn)題的原因在于(1A).在保證該處理程序功能的前提下提高其執行效率,他應該(2B). (1)、A.需求分析階段對用戶(hù)的信息要求和處理要求未完全掌握 B.概念結構設計不正確 C.邏輯結構設計階段未能對關(guān)系模式分解到BCNF D.物理設計階段未能正確選擇數據的存儲結構 (2)、A.建立該查詢(xún)處理程序所用到表的視圖,并對程序作相應的修改 B.建立查詢(xún)處理程序所用到表進(jìn)行必要的合并,并對程序作相應的修改 C.修改該程序以減少所使用的表 D.盡可能采用嵌套查詢(xún)實(shí)現該程序的功能 29、在某學(xué)校的綜合管理系統設計階段,教師實(shí)體在學(xué)籍管理子系統中被稱(chēng)為”教師”,而在人事管理子系統中被稱(chēng)為”職工”,這類(lèi)沖突描述正確的為_(kāi)B_____ A.語(yǔ)義沖突B.命名沖突C.屬性沖突D.結構沖突 30、以下選項中,可以用于Internet信息服務(wù)器遠程管理的是__B____ A.TelnetB.RASC.FTPD.SMTP Telnet是進(jìn)行遠程登錄的標準協(xié)議和主要方式，它為用戶(hù)提供了在本地計算機上完成遠程主機工作的能力。在終端使用者的電腦上使用telnet程序，用它連接到服務(wù)器。終端使用者可以在telnet程序中輸入命令，這些命令會(huì )在服務(wù)器上運行，就像直接在服務(wù)器的控制臺上輸入一樣。所以telnet具有Internet信息服務(wù)器遠程管理功能、RAS服務(wù)(Remote、Access、Service，遠程訪(fǎng)問(wèn)服務(wù))，通過(guò)RAS可以在遠程將PC登錄到網(wǎng)站的服務(wù)器上，以便在非工作時(shí)間對網(wǎng)站進(jìn)行緊急維護和內容刪改。所以RAS也具有Internet信息服務(wù)器遠程管理功能。FTP(File、Transfer、Protocol)是個(gè)文件傳輸協(xié)議。正如其名：協(xié)議的任務(wù)是從一臺計算機將文件傳送到另一臺計算機，它與這兩臺計算機所處的位置、聯(lián)系的方式、以及使用的操作系統無(wú)關(guān)。它的目標是提高文件的共享性，提供非直接使用遠程計算機，使存儲介質(zhì)對用戶(hù)透明和可靠高效地傳送數據。SMTP稱(chēng)為簡(jiǎn)單Mail傳輸協(xié)議(Simple、Mail、Transfer、Protocal),目標是向用戶(hù)提供高效、可靠的郵件傳輸。它是個(gè)請求/響應協(xié)議，命令和響應都是基于A(yíng)SCII文本的。 軟件測試筆試題 一、能力題 1、卡車(chē)以每小時(shí)80公里的速度行駛，30、分鐘行駛的路程為： A、15公里 B、30公里 C、40公里 D、80公里 E、以上答案全不對 2.有一種小蟲(chóng)，每隔兩秒鐘分裂一次。分裂后的兩只新的小蟲(chóng)經(jīng)過(guò)兩秒鐘后又會(huì )分裂。如果最初某瓶中只有一只小蟲(chóng)，那么兩秒后變兩只，再過(guò)兩秒后就變四只……兩分鐘后，正好滿(mǎn)滿(mǎn)一瓶小蟲(chóng)�，F在這個(gè)瓶?jì)茸畛醴湃雰芍贿@樣的小蟲(chóng)。 問(wèn)：經(jīng)過(guò)多少時(shí)間后，正巧也是滿(mǎn)滿(mǎn)的一瓶? 3、美國某小鎮車(chē)隊有17輛小公共汽車(chē)，整天在相距197千米的青山與綠水兩個(gè)小鎮之間往返運客。每輛車(chē)到達小鎮后司機都要休息8分鐘。司機杰克上午10點(diǎn)20分開(kāi)車(chē)從青山鎮出發(fā)，在途中不時(shí)地遇到(有時(shí)是迎面駛來(lái)，有時(shí)是互相超越)一輛本車(chē)隊的車(chē)。下午1點(diǎn)55分他到達綠水鎮，休息時(shí)發(fā)現本隊的其他司機一個(gè)都不在。沒(méi)有同伴可以聊天，杰克就靜靜地回憶剛才在路上遇到的本車(chē)隊的那些人。 問(wèn)：杰克一共遇到了本車(chē)隊的幾輛車(chē)? 4、一個(gè)岔路口分別通向誠實(shí)國和說(shuō)謊國。來(lái)了兩個(gè)人，已知一個(gè)是誠實(shí)國的，另一個(gè)是說(shuō)謊國的。誠實(shí)國永遠說(shuō)實(shí)話(huà)，說(shuō)謊國永遠說(shuō)謊話(huà)�，F在你要去說(shuō)謊國，但不知道應該走哪條路，需要問(wèn)這兩個(gè)人。 請問(wèn)應該怎么問(wèn)?(20秒-2分鐘) 二、軟件測試基礎題(多選) 1、V模型本質(zhì)上是一種 A.線(xiàn)性順序模型 B.順序迭代模型 C.線(xiàn)性迭代模型 D、及早見(jiàn)產(chǎn)品模型 2、某軟件公司在招聘軟件評測師時(shí)，應聘者甲對公司作如下保證，你認為應聘者甲的保證中，不正確的是（)。 A、經(jīng)過(guò)自己測試的軟件今后不會(huì )再出現問(wèn)題 B、在工作中對所有程序員一視同仁，不會(huì )因為在某個(gè)程序員編寫(xiě)的程序中發(fā)現的問(wèn)題多，就重點(diǎn)審查該程序，以免不利于團結 C、承諾不需要其他人員，自己就可以獨立進(jìn)行測試工作 D、發(fā)揚咬定青山不放松的精神，不把所有問(wèn)題都找出來(lái)，決不罷休 3、軟件測試執行階段的產(chǎn)品應包括、（)。 A、測試日志 B、測試用例 C、測試事件報告 D、測試職責分工與進(jìn)度計劃 4、為什么要測試?、（) A、以最少的時(shí)間和人力，系統地找出軟件中潛在的各種錯誤和缺陷 B、實(shí)施測試收集到的測試結果數據為可靠性分析提供了依據 C、它只能說(shuō)明軟件中存在錯誤 D、證明測試團隊的實(shí)力 5、一個(gè)好的測試的屬性包括：（) A、一個(gè)好的測試發(fā)現錯誤的可能性很高 B、一個(gè)好的測試并不冗余 C、一個(gè)好的測試應該特別復雜 D、一個(gè)好的測試應該特別簡(jiǎn)單 6.關(guān)于數據庫索引，以下表述正確的是（) �、偃绻麑Ρ韯�(chuàng )建了索引，那么更新、插入和刪除表中的記錄都將導致額外的系統開(kāi)銷(xiāo)。 �、谌頀呙枰欢ū仁褂盟饕膱绦行实�。 �、墼谧侄芜x擇性很低的情況下適用索引。 �、芤粋�(gè)表創(chuàng )建的索引越多，對系統的性能提升越大。 A、①②③B、①③C、①②③④D、①③④ 7.在TCP/IP網(wǎng)絡(luò )中，為各種公共服務(wù)保留的端口號范圍值是（) A.1~255 B.1~1023 C.1~1024 D.1~65535 軟件測試筆試題 什么是軟件測試? 軟件測試是為了發(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ǔ)言包括：標準CC++、VisualC++、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)、基路測試等，主要用于軟件驗證�！鞍缀小狈ㄈ媪私獬绦騼炔窟壿嫿Y構、對所有邏輯路徑進(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)行重新測試。 軟件測試筆試題 一、選擇填空 1.有一個(gè)文件test.txt里面有四列(name、class、address、age)，問(wèn)：用_____shell命令打印出class列的內容。 -----awk、‘{print、$2}’、test.txt 2.英特網(wǎng)的遠程登錄的工作模式是_____工作模式。 -----客戶(hù)機/服務(wù)器 3.防止系統區被破壞的方法有兩種：存儲保護鍵和______。 -----定時(shí)備份 4.多播IP用的是哪類(lèi)地址(D) A.A類(lèi)地址B.B類(lèi)地址C.C類(lèi)地址D.D類(lèi)地址 5.關(guān)系代數的優(yōu)化策略是_______。 ------盡早執行選擇運算 6.在分解中，無(wú)損連接，函數依賴(lài)屬于_______。 7.在完成了數據庫的模式的定義之后，數據字典里面應該包括______。 8.可重定位內存分配的目的是_______。 ------解決碎片和緊縮問(wèn)題 9.unix的目錄結構是______。 10.連接方式存儲的隊列，在刪除一個(gè)節點(diǎn)時(shí)(D)、選項可能記不清了，大概是這樣 A.只改動(dòng)頭指針B.只改動(dòng)尾指針C.頭指針和尾指針都改動(dòng)D.頭指針和尾指針可能改動(dòng) 11.不帶頭指針的單鏈表的隊列，在刪除一個(gè)節點(diǎn)時(shí)(D)、10和11這兩個(gè)題目有什么區別，不解? A.只改動(dòng)頭指針B.只改動(dòng)尾指針C.頭指針和尾指針都改動(dòng)D.頭指針和尾指針可能改動(dòng) 12.完整性約束包括：主鍵約束，外鍵約束，和全局約束。 -----所以應該是：用戶(hù)自定義約束 13.IEEE802.3物理地址是(C)位 A.32bitB.64bitC、48bitD.16bit 14.哪一種數據的查詢(xún)需要優(yōu)化 A.層次數據庫B.網(wǎng)狀數據庫C.關(guān)系數據庫D.無(wú)關(guān)系數據庫 15.負責壓力測試不包括 A.訪(fǎng)問(wèn)量B.點(diǎn)擊次數C.業(yè)務(wù)處理時(shí)間D.業(yè)務(wù)請求吞吐量 16、在五層的網(wǎng)絡(luò )模型中，傳輸層屬于第___4___層。 二、問(wèn)答 1、你的測試職業(yè)發(fā)展是什么? 測試經(jīng)驗越多，測試能力越高。所以我的職業(yè)發(fā)展是需要時(shí)間積累的，一步步向著(zhù)高級測試工程師奔去。而且我也有初步的職業(yè)規劃，前3年積累測試經(jīng)驗，按如何做好測試工程師的要點(diǎn)去要求自己，不斷更新自己改正自己，做好測試任務(wù)。 2、你認為測試人員需要具備哪些素質(zhì) 做測試應該要有一定的協(xié)調能力，因為測試人員經(jīng)常要與開(kāi)發(fā)接觸處理一些問(wèn)題，如果處理不好的話(huà)會(huì )引起一些沖突，這樣的話(huà)工作上就會(huì )不好做。還有測試人員要有一定的耐心，有的時(shí)候做測試很枯燥乏味。除了耐心，測試人員不能放過(guò)每一個(gè)可能的錯誤。 3、你為什么能夠做測試這一行 雖然我的測試技術(shù)還不是很成熟，但是我覺(jué)得我還是可以勝任軟件測試這個(gè)工作的，因為做軟件測試不僅是要求技術(shù)好，還有有一定的溝通能力，耐心、細心等外在因素。綜合起來(lái)看我認為我是勝任這個(gè)工作的。 4、測試的目的是什么? 測試的目的是找出軟件產(chǎn)品中的錯誤，是軟件盡可能的符合用戶(hù)的要求。當然軟件測試是不可能找出全部錯誤的。 5、測試分為哪幾個(gè)階段? 一般來(lái)說(shuō)分為5個(gè)階段：?jiǎn)卧獪y試、集成測試、確認測試、系統測試、驗收測試 6、單元測試的測試對象、目的、測試依據、測試方法? 測試對象是模塊內部的程序錯誤，目的是消除局部模塊邏輯和功能上的錯誤和缺陷。測試依據是模塊的詳細設計，測試方法是采用白盒測試。 7、怎樣看待加班問(wèn)題 加班的話(huà)我沒(méi)有太多意見(jiàn)，但是我還是覺(jué)得如果能夠合理安排時(shí)間的話(huà)，不會(huì )有太多時(shí)候加班的。 8、結合你以前的學(xué)習和工作經(jīng)驗，你認為如何做好測試。 根據我以前的工作和學(xué)習經(jīng)驗，我認為做好工作首先要有一個(gè)良好的溝通，只有溝通無(wú)障礙了，才會(huì )有好的協(xié)作，才會(huì )有更好的效率，再一個(gè)就是技術(shù)一定要過(guò)關(guān)，做測試要有足夠的耐心，和一個(gè)良好的工作習慣，不懂的就要問(wèn)，實(shí)時(shí)與同事溝通這樣的話(huà)才能做好測試工作。 9、你為什么選擇軟件測試行業(yè) 因為之前了解軟件測試這個(gè)行業(yè)，覺(jué)得他的發(fā)展前景很好。 10、根據你以前的工作或學(xué)習經(jīng)驗描述一下軟件開(kāi)發(fā)、測試過(guò)程，由哪些角色負責，你做什么 要有架構師、開(kāi)發(fā)經(jīng)理、測試經(jīng)理、程序員、測試員。我在里面主要是負責所分到的模塊執行測試用例。 11、根據你的經(jīng)驗說(shuō)說(shuō)你對軟件測試/質(zhì)量保證的理解 軟件質(zhì)量保證與測試是根據軟件開(kāi)發(fā)階段的規格說(shuō)明和程序的內部結構而精心設計的一批測試用例(即輸入數據和預期的輸出結果)，并根據這些測試用例去運行程序，以發(fā)現錯誤的過(guò)程。它是對應用程序的各個(gè)方面進(jìn)行測試以檢查其功能、語(yǔ)言有效性及其外觀(guān)排布。 12、軟件測試的流程是什么? 需求調查：全面了解系統概況、應用領(lǐng)域、軟件開(kāi)發(fā)周期、軟件開(kāi)發(fā)環(huán)境、開(kāi)發(fā)組織、時(shí)間安排、功能需求、性能需求、質(zhì)量需求及測試要求等。根據系統概況進(jìn)行項目所需的人員、時(shí)間和工作量估計以及項目報價(jià)。 制定初步的項目計劃。 測試準備：組織測試團隊、培訓、建立測試和管理環(huán)境等。 測試設計：按照測試要求進(jìn)行每個(gè)測試項的測試設計，包括測試用例的設計和測試腳本的開(kāi)發(fā)等。 測試實(shí)施：按照測試計劃實(shí)施測試。 測試評估：根據測試的結果，出具測試評估報告。 13、你對SQA的職責和工作活動(dòng)(如軟件度量)的理解? SQA就是獨立于軟件開(kāi)發(fā)的項目組，通過(guò)對軟件開(kāi)發(fā)過(guò)程的監控，來(lái)保證軟件的開(kāi)發(fā)流程按照指定的CMM規程(如果有相應的CMM規程),對于不符合項及時(shí)提出建議和改進(jìn)方案，必要時(shí)可以向高層經(jīng)理匯報以求問(wèn)題的解決。通過(guò)這樣的途徑來(lái)預防缺陷的引入，從而減少后期軟件的維護成本。SQA主要的工作活動(dòng)包括制定SQA工作計劃，參與階段產(chǎn)物的評審，進(jìn)行過(guò)程質(zhì)量、功能配置及物理配置的審計等;對項目開(kāi)發(fā)過(guò)程中產(chǎn)生的數據進(jìn)行度量等等。 14、說(shuō)說(shuō)你對軟件配置管理的理解 項目在開(kāi)發(fā)過(guò)程中要用相應的配置管理工具對配置項(包括各個(gè)階段的產(chǎn)物)進(jìn)行變更控制，配置管理的使用取決于項目規模和復雜性及風(fēng)險的水平。軟件的規模越大，配置管理就越顯得重要。還有在配置管理中，有一個(gè)很重要的概念，那就是基線(xiàn)，是在一定階段各個(gè)配置項的組合，一個(gè)基線(xiàn)就提供了一個(gè)正式的標準，隨后的工作便基于此標準，并只有經(jīng)過(guò)授權后才能變更這個(gè)標準。配置管理工具主要有CC，VSS,CVS,SVN等，我只用過(guò)SVN，對其他的工具不是很熟悉。 15、怎樣寫(xiě)測試計劃和測試用例 簡(jiǎn)單點(diǎn)，測試計劃里應有詳細的測試策略和測試方法，合理詳盡的資源安排等，至于測試用例，那是依賴(lài)于需求(包括功能與非功能需求)是否細化到功能點(diǎn)，是否可測試等。 軟件測試經(jīng)典筆試題 一、判斷題(每題1分，共12、分，正確的T，錯誤的F) 1.軟件需求是度量軟件質(zhì)量的基礎、。不符合需求的軟件就不具備質(zhì)量。(T) 2.全面質(zhì)量管理的定義是：一個(gè)組織以質(zhì)量為中心，以全員參與為基礎，目的在于通過(guò)讓顧客滿(mǎn)意和本組織所有成員及社會(huì )受益而達到長(cháng)期成功的管理途徑。(T) 3.發(fā)現錯誤是軟件測試的唯一目的。(F) 4.白盒測試可以找出軟件遺漏功能和代碼錯誤問(wèn)題。（F) 5.軟件的質(zhì)量有測試組決定。（F) 6.在設計測試用例時(shí)，應包括合理的輸入條件和不合理的輸入條件。（T) 7.測試從不可知內部條件開(kāi)始，結果是不可預見(jiàn)的。(F) 8.軟件缺陷一定是由編碼所引起的、。(F) 9.軟件測試等于程序測試。(F) 10.Beta測試是軟件的多個(gè)用戶(hù)在實(shí)際使用環(huán)境下進(jìn)行的測試。(T) 11.經(jīng)驗表明，測試后程序殘存的錯誤數目與該程序中以發(fā)現的錯誤數目或檢錯率成正比。(T) 12.驗收測試比較適合采用軟件自動(dòng)化測試工具進(jìn)行測試。(F) 二、單項選擇題(每題2分，共12、分) 1.某次程序調試沒(méi)有出現預計的結果，下列(B）不可能是導致出錯的原因。 A、變量沒(méi)有初始化B、編寫(xiě)的語(yǔ)句書(shū)寫(xiě)格式不規范 C、循環(huán)控制出錯D、代碼輸入有誤 2.軟件測試是軟件開(kāi)發(fā)過(guò)程的重要階段，是軟件質(zhì)量保證的重要手段，下列哪個(gè)(些)是軟件測試的任務(wù)?(B) A預防軟件發(fā)生錯誤B發(fā)現改正程序錯誤C提供診斷錯誤信息D.都是 3.下面的哪一項測試步驟中需要進(jìn)行局部數據結構測試：、(A) A.單元測試B.集成測試C.確認測試D.系統測試 4.白盒測試是根據程序的(C）來(lái)設計測試用例 A.功能B.性能C.內部邏輯D.內部數據 5.(C）方法根據輸出對輸入的依賴(lài)關(guān)系設計測試用例。 A.路徑測試B.等價(jià)類(lèi)C.因果圖D.歸納測試 6.有一組測試用例，它使被測程序中的每一個(gè)分支至少執行一次，它滿(mǎn)足的覆蓋標準是：(B) A.語(yǔ)句覆蓋B、判定覆蓋C、條件覆蓋D.路徑覆蓋 三、問(wèn)答題、(每題9分，共54、分) 1.什么是軟件質(zhì)量?請寫(xiě)出ISO/IEC9126中如何評價(jià)和度量軟件質(zhì)量的。 ISO、8402中把軟件質(zhì)量定義為“反映實(shí)體滿(mǎn)足明確和隱含需要的能力和特性總合”。即軟件質(zhì)量是軟件一些特性的組合。 在ISO/IEC9126中將質(zhì)量特性定義為6(包括個(gè)21個(gè)子特性)，即： a、功能性：在指定條件下使用時(shí)，軟件產(chǎn)品提供滿(mǎn)足明確和隱含需求功能的能力; b、可靠性：在指定條件下使用時(shí)，軟件產(chǎn)品維持規定的性能級別的能力; c、易用性：在指定條件下使用時(shí)，軟件產(chǎn)品被理解、學(xué)習、使用及其吸引用戶(hù)的能力; d、效率：在規定條件下，相對于所用資源的數量，軟件產(chǎn)品可提供適當性能的能力; e、易維護性：軟件產(chǎn)品可被修改的能力，修改可能包括修正、改進(jìn)或者適應環(huán)境、需求和功能規約的變化; f、易移植性：軟件產(chǎn)品從一種環(huán)境遷移到另一種環(huán)境的能力; 這6個(gè)特性作為軟件質(zhì)量的內部度量和外部度量，同時(shí)ISO/IEC9126還定義了使用質(zhì)量度量，包括4個(gè)特性： 有效性：軟件產(chǎn)品在指定使用環(huán)境下，使用戶(hù)準確、完整地獲得規定目標的能力; 生產(chǎn)率：軟件產(chǎn)品在指定使用環(huán)境下，使用戶(hù)花費合適的與有效性相關(guān)的資源數量的能力; 安全性：軟件產(chǎn)品在指定使用環(huán)境下，獲得可接受的損害人類(lèi)、商務(wù)、軟件、財產(chǎn)或環(huán)境風(fēng)險級別的能力; 滿(mǎn)意度：軟件產(chǎn)品在指定使用環(huán)境下，使用戶(hù)滿(mǎn)意的能力。 2、怎樣做好文檔測試? 文檔測試：是檢查用戶(hù)文檔(如需求、用戶(hù)手冊、安裝手冊等)的正確性、清晰性和精確性，檢驗文檔是否和實(shí)際應用存在的差別。對用戶(hù)文檔中所使用的例子必須在測試中一一試過(guò)，確保敘述正確無(wú)誤。 對文檔的測試一般從正確性、完備性和易理解性幾個(gè)方面去測試，具體包括以下內容： (1)檢查產(chǎn)品說(shuō)明書(shū)屬性 (2)檢查是否完整 (3)檢查是否準確 (4)檢查是否精確 (5)檢查是否一致 (6)檢查是否貼切 (7)檢查是否合理 (8)檢查代碼無(wú)關(guān) (9)檢查可測試性。 3、請簡(jiǎn)要描述幾種主要的軟件測試模型。 4、請描述實(shí)現軟件自動(dòng)化測試用例的幾個(gè)主要技術(shù)。 5、請描述對一個(gè)嵌套循的環(huán)循環(huán)測試。 6、什么是黑盒測試?黑盒測試主要采用的技術(shù)有哪些? 【軟件測試筆試題目分享】相關(guān)文章： java筆試題，筆試題目分享08-10 軟件研發(fā)工程師筆試題目及答案分享07-25 世嘉軟件 筆試經(jīng)歷分享08-10 最新尼爾森筆試題題目分享08-10 思科筆試題，題目答案分享08-10 中行筆試題題目分享08-10 運算類(lèi)的筆試題目分享08-10 軟件公司筆試題目08-02