選擇題

I、系統(tǒng)測試使用(C)技術(shù)，重要測試被測應(yīng)用的高級互操作性需求，而無需考慮被測試

應(yīng)用的內(nèi)部構(gòu)造。

A、單元測試B、集成測試C、黑盒測試D、白盒測試

2、單元測試重要的測試技術(shù)不包括(B)。

A、白盒測試B、功能測試

C、靜態(tài)測試1)、以上都不是

3、(A)的目的是對最終軟件系統(tǒng)進(jìn)行全面的測試，保證最終軟件系統(tǒng)滿足產(chǎn)品需求并

且遵照系統(tǒng)設(shè)計。

A、系統(tǒng)測試B、集成測試

C、單元測試D、功能測試

4、假如一種產(chǎn)品中次嚴(yán)重的缺陷基本完畢修正并通過復(fù)測，這個階段的成品是(A)。

A、Alpha版B、Beta版

C、正版D、以上都不是

5、自底向上法需要寫(A)。

A、驅(qū)動程序B、樁程序C、驅(qū)動程序和樁程序D、.以上都不是

6、測試ATM取款功能，已知取款數(shù)只能輸入正整數(shù)，每次取款數(shù)規(guī)定是100的倍數(shù)且不能

不小于500,下面哪個是對的的無效等價類(C)

A、(0,100)、(100,200)、(200,300)、(300,400)、(400,500)、(500,+?>);

B、(500,+8)

C、(500,+8)、任意不小于0不不小于500的非100倍數(shù)的整數(shù);

D、(-8,100)、(100,200)、(200,300)、(300,400)、(400,500)、(500,+<?)；

7、因果圖/鑒定表工程措施在如下那種狀況下不合用(C)

A、輸入輸出明確，或輸入輸出因果關(guān)系明確的狀況下

B、被分析的特性或功能點復(fù)雜，輸入項目諸多的狀況下

C、系統(tǒng)輸入之間互相約束多，需要做大范圍的組合測試狀況下

I)、系統(tǒng)輸入之間基本沒有互相聯(lián)絡(luò)

8、如下說法不對的的是(D)

A、測試原始需要明確了產(chǎn)品將要實現(xiàn)了什么

B、產(chǎn)品測試規(guī)格明確了測試設(shè)計內(nèi)容

C、測試用例明確了測試實現(xiàn)內(nèi)容

D、以上說法均不對的

9、可測試性中，有關(guān)系統(tǒng)可觀測性的理解，下面說法那個是錯誤的(B)

A、系統(tǒng)所有歐J輸出成果可觀測，錯誤輸出易于識別；

B、系統(tǒng)運行狀態(tài)和內(nèi)部處理的過程信息可觀測；

C、系統(tǒng)內(nèi)部變量名及其取值可觀測；

1)、系統(tǒng)內(nèi)部重要對象的)狀態(tài)和屬性可觀測；

E、系統(tǒng)內(nèi)部重要的操作的處理時間可觀測；

F、系統(tǒng)內(nèi)部重要的資源的占用狀況及單個資源的創(chuàng)立、保持、釋放過程可觀測

10、測試腳本的編寫規(guī)范強調(diào)：(ABCD)

A、可讀行B、可重用性C、可維護(hù)性D、可移植性

11、當(dāng)繼承某個特性是，一般會從哪些角度對該特性進(jìn)行測試分析？(AC)

A、失效影響度B、成熟度C、繼承方式D、顧客原始需求

12、從下列有關(guān)軟件測試的論述中，選出對時的論述(CD)

A、用黑盒法測試時，測試用例是根據(jù)程序內(nèi)部邏輯設(shè)計的

B、測試的目的是驗證該軟件已對的的實現(xiàn)了顧客的規(guī)定

C、發(fā)現(xiàn)錯誤多的程序塊，殘留在模塊中的錯誤也多

D、測試設(shè)計時，應(yīng)充足考慮異常的輸入狀況

13、軟件驗收測試的合格通過準(zhǔn)則是：(ABCD)

A.軟件需求分析闡明書中定義的所有功能已所有實現(xiàn)，性能指標(biāo)所有到達(dá)規(guī)定。

B.所有測試項沒有殘存一級、二級和三級錯誤。

C.立項審批表、需求分析文檔、設(shè)計文檔和編碼實現(xiàn)一致。

D.驗收測試工件齊全。

13、軟件測試計劃評審會需要哪些人員參與？(ABCD)

A.項目經(jīng)理

B.SQA負(fù)責(zé)人

C.配置負(fù)責(zé)人

D.測試組

14.測試設(shè)計員的職責(zé)有：(BC)

A.制定測試計劃

B.設(shè)計測試用例

C.設(shè)計測試過程、腳本

1).評估測試活動

15.軟件實行活動的進(jìn)入準(zhǔn)則是：(ABC)

A.需求工件已經(jīng)被基線化

B.詳細(xì)設(shè)計工件已經(jīng)被基線化

C.構(gòu)架工件已經(jīng)被基線化

D.項目階段成果已經(jīng)被基線化

16.軟件驗收測試的合格通過準(zhǔn)則是：(ABCD)

A.軟件需求分析闡明書中定義的所有功能己所有實現(xiàn)，性能指標(biāo)所有到達(dá)規(guī)定。B.所有

測試項沒有殘存一級、二級和三級錯誤。C.立項審批表、需求分析文檔、設(shè)計文檔和編碼

實現(xiàn)一致。D.驗收測試工件齊全。

17.軟件測試計劃評審會需要哪些人員參與？(ABCD)

A.項目經(jīng)理B.SQA負(fù)責(zé)人C.配置負(fù)責(zé)人D.測試組

18.下列有關(guān)alpha測試的描述中對日勺I的是：(AD)

A.alpha測試需要顧客代表參與

B.alpha測試不需要顧客代表參與

C.alpha測試是系統(tǒng)測試區(qū)I一種

D.alpha測試是驗收測試的一種

19.測試設(shè)計員的職責(zé)有：(BC)

A.制定測試計劃B.設(shè)計測試用例C.設(shè)計測試過程、腳本D.評估測試活動

20.軟件實行活動時進(jìn)入準(zhǔn)則是：（ABC）

A.需求工件已經(jīng)被基線化B.詳細(xì)設(shè)計工件已經(jīng)被基線化C.構(gòu)架工件已經(jīng)被基線化D.項

目階段成果已經(jīng)被基線化

判斷題

1.軟件測試的目的是盡量多的找出軟件的缺陷。（Y）

2.負(fù)載測試是驗證要檢查的系統(tǒng)的能力最高能到達(dá)什么程度。（N）

3.測試人員要堅持原則，缺陷未修復(fù)完堅決不予通過。（N）

4.自動化測試能比手工測試發(fā)現(xiàn)更多的缺陷（N）

5.錯誤猜測法基于這樣一種假設(shè)，此前犯過的錯誤，后來同樣會犯，我犯過的錯誤他人同樣

會犯，前人犯過的錯誤，后人同樣會犯（N）

6.軟件測試中的二八原則暗示著測試發(fā)現(xiàn)的錯誤中的80%很也許來源于程序模塊的20%（Y）

7.某WEB系統(tǒng)設(shè)計中，顧客點擊“退出”按鈕從系統(tǒng)中退出，界面回到初始登陸界面。此時

不關(guān)閉窗口，使用瀏覽器日勺回退功能，可以回到之前的顧客界面，繼續(xù)進(jìn)行顧客操作。這種

合適日勺人性化設(shè)計，恩那個防止顧客誤點擊退出按鈕后重新登錄的繁瑣操作；這種說法與否

對的（N）

8.在確定性能測試指標(biāo)值時，參照的國際原則、國標(biāo)、運行商規(guī)范中對此規(guī)定并不一樣樣，

可以視狀況選擇有助于我們的指標(biāo)值，但必須要比競爭對手高，這樣才有助于市場競爭力（N）

9.測試執(zhí)行時，應(yīng)當(dāng)對每一種測試成果做全面的檢查，包括日志，這種說法與否對日勺（N）

10.在測試執(zhí)行時，我們重要是基于顧客的使用場景來考慮功能實現(xiàn)的對的性，關(guān)鍵機要數(shù)

據(jù)在數(shù)據(jù)庫內(nèi)與否加密存儲或日志輸出中與否采用加密、掩碼處理不是我們測試關(guān)注的范

圍，畢竟那產(chǎn)品的內(nèi)部實現(xiàn)，顧客看不到時，自然也是不關(guān)懷的。這種說法與否對的。（）

11.軟件測試的目的是盡量多的找出軟件的缺陷。（Y）

12.Beta測試是驗收測試的一種。（Y）

13.驗收測試是由最終顧客來實行的。（N）

14.項目立項前測試人員不需要提交任何工件。（Y）

15.單元測試能發(fā)現(xiàn)約80%的軟件缺陷。（Y）

16.代碼評審是檢查源代碼與否到達(dá)模塊設(shè)計的規(guī)定。（N）

17.自底向上集成需要測試員編寫驅(qū)動程序。（Y）

18.負(fù)載測試是驗證要檢查的系統(tǒng)的能力最高能到達(dá)什么程度。（N）

19.測試人員要堅持原則，缺陷未修復(fù)完堅決不予通過。（N）

20.代碼評審員一般由測試員擔(dān)任。（N）

21.我們可以人為的使得軟件不存在配置問題。（N）

22.集成測試計劃在需求分析階段末提交。（N）

簡答

一、區(qū)別階段評審時與同行評審

同行評審目的:發(fā)現(xiàn)小規(guī)模工作產(chǎn)品的錯誤，只要是找錯誤；

階段評審目的:評審模塊階段作品的對的性可行性及完整性

同行評審人數(shù)：3-7人人員必須通過同行評審會議的培訓(xùn)I,由SQA指導(dǎo)

階段評審人數(shù)：5人左右評審人必須是專家具有系統(tǒng)評審資格

同行評審內(nèi)容：內(nèi)容小一般文檔＜40頁，代碼＜500行

二、為何要在一種團(tuán)體中開展軟件測試工作？

由于沒有通過測試的軟件很難在公布之前懂得該軟件的質(zhì)量,就好比ISO質(zhì)量認(rèn)證一

樣，測試同樣也需要質(zhì)量的保證，這個時候就需要在團(tuán)體中開展軟件測試的工作。在測試的

過程發(fā)現(xiàn)軟件中存在的問題，及時讓開發(fā)人員得知并修改問題，在即將公布時，從測試匯報

中得出軟件的質(zhì)量狀況。

三、您在以往的測試工作中都曾經(jīng)詳細(xì)從事過哪些工作？其中最擅長哪部分工

作？

我曾經(jīng)做過web測試后臺測試客戶端軟件，其中包括功能測試，性能測試，顧客體驗

測試。最擅長的是功能測試

四、您所熟悉的軟件測試類型均有哪些？請試著分別比較這些不一樣。

測試類型有：功能測試，性能測試，界面測試。

功能測試在測試工作中占的比例最大，功能測試也叫黑盒測試。是把測試對象看作一種

黑盒子。運用黑盒測試法進(jìn)行動態(tài)測試時，需要測試軟件產(chǎn)品的功能，不需測試軟件產(chǎn)品的

內(nèi)部構(gòu)造和處理過程。采用黑盒技術(shù)設(shè)計測試用例的措施有：等價類劃分、邊界值分析、錯

誤推測、因果圖和綜合方略。

性能測試是通過自動化口勺測試工具模擬多種正常、峰值以及異常負(fù)載條件來對系統(tǒng)的各

項性能指標(biāo)進(jìn)行測試。負(fù)載測試和壓力測試都屬于性能測試，兩者可以結(jié)合進(jìn)行。通過負(fù)載

測試，確定在多種工作負(fù)載下系統(tǒng)的性能，目的是測試當(dāng)負(fù)載逐漸增長時，系統(tǒng)各項性能指

標(biāo)的變化狀況。壓力測試是通過確定一種系統(tǒng)的瓶頸或者不能接受的性能點，來獲得系統(tǒng)能

提供的最大服務(wù)級別的測試。

界面測試，界面是軟件與顧客交互的最直接的層，界面的好壞決定顧客對軟件的第一印

象。并且設(shè)計良好的界面可以引導(dǎo)顧客自己完畢對應(yīng)的操作，起到向?qū)У淖饔?。同步界面?/p>

同人的面孔，具有吸引顧客的直接優(yōu)勢。設(shè)計合理的界面能給顧客帶來輕松愉悅的感受和成

功的感覺，相反由于界面設(shè)計的失敗，讓顧客有挫敗感，再實用強大的功能都也許在顧客的

畏懼與放棄中付諸東流。

區(qū)別在于，功能測試關(guān)注產(chǎn)品的所有功能上，要考慮到每個細(xì)節(jié)功能，每個也許存在的

功能問題。性能測試重要關(guān)注于產(chǎn)品整體的多顧客并發(fā)下的穩(wěn)定性和強健性。界面測試更關(guān)

注于顧客體驗上，顧客使用該產(chǎn)品的時候與否易用，與否易懂，與否規(guī)范（快捷鍵之類的），

與否美觀（能否吸引顧客的注意力），與否安全（盡量在前臺防止顧客無意輸入無效的數(shù)據(jù)，

當(dāng)然考慮到體驗性，不能太粗魯?shù)膹棾鼍妫孔瞿硞€性能測試的時候，首先它也許是個功

能點，首先要保證它的功能是沒問題的，然后再考慮該功能點的性能測試。

五、請試著比較一下黑盒測試、白盒測試、單元測試、集成測試、系統(tǒng)測試、

驗收測試區(qū)）區(qū)別與聯(lián)絡(luò)。

黑盒測試：已知產(chǎn)品的功能設(shè)計規(guī)格，可以進(jìn)行測試證明每個實現(xiàn)了的功能與否符合規(guī)

定。

白盒測試：已知產(chǎn)品的內(nèi)部工作過程，可以通過測試證明每種內(nèi)部操作與否符合設(shè)計規(guī)

格規(guī)定，所有內(nèi)部成分與否以通過檢查。

軟件的黑盒測試意味著測試要在軟件的接口處進(jìn)行。這種措施是把測試對象看做一種黑

盒子,測試人員完全不考慮程序內(nèi)部的邏輯構(gòu)造和內(nèi)部特性，只根據(jù)程序的需求規(guī)格闡明書,

檢查程序的功能與否符合它的功能闡明。因此黑盒測試又叫功能測試或數(shù)據(jù)驅(qū)動測試。黑盒

測試重要是為了發(fā)現(xiàn)如下幾類錯誤:

1、與否有不對的或遺漏的功能？2、在接口上，輸入與否能對的的接受？能否輸出

對的的成果？3、與否有數(shù)據(jù)構(gòu)造錯誤或外部信息（例如數(shù)據(jù)文獻(xiàn)）訪問錯誤？4、性能

上與否可以滿足規(guī)定？5、與否有初始化或終止性錯誤？

軟件的白盒測試是對軟件日勺過程性細(xì)節(jié)做細(xì)致的檢查。這種措施是把測試對象看做一種

打開的盒子，它容許測試人員運用程序內(nèi)部的邏輯構(gòu)造及有關(guān)信息，設(shè)計或選擇測試用例，

對程序所有邏輯途徑進(jìn)行測試。通過在不一樣點檢查程序狀態(tài)，確定實際狀態(tài)與否與預(yù)期的

狀態(tài)一致。因此白盒測試又稱為構(gòu)造測試或邏輯驅(qū)動測試。白盒測試重要是想對程序模塊進(jìn)

行

如下檢查：

1、對程序模塊的所有獨立的執(zhí)行途徑至少測試一遍。

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

3、在循環(huán)的邊界和運行的界線內(nèi)執(zhí)行循環(huán)體。

4、測試內(nèi)部數(shù)據(jù)構(gòu)造的有效性，等等。

單元測試（模塊測試）是開發(fā)者編寫的一小段代碼，用于檢查被測代碼的一種很小的、

很明確的功能與否對的。一般而言，一種單元測試是用于判斷某個特定條件（或者場景）下

某個特定函數(shù)的行為。

單元測試是由程序員自己來完畢，最終受益的也是程序員自己。可以這樣說，程序員有

責(zé)任編寫功能代碼，同步也就有責(zé)任為自己的代碼編寫單元測試。執(zhí)行單元測試，就是為了

證明這段代碼的行為和我們期望的一致。

集成測試（也叫組裝測試，聯(lián)合測試）是單元測試的邏輯擴(kuò)展。它的最簡樸的形式是:

兩個已經(jīng)測試過的單元組合成一種組件,并且測試它們之間的接口。從這一層意義上講,

組件是指多種單元的集成聚合。在現(xiàn)實方案中，許多單元組合成組件，而這些組件又聚合成

程序的更大部分。措施是測試片段的組合，并最終擴(kuò)展進(jìn)程，將您的模塊與其他組的模塊

一起測試。最終，將構(gòu)成進(jìn)程的所有模塊一起測試。

系統(tǒng)測試是將通過測試的子系統(tǒng)裝配成一種完整系統(tǒng)來測試。它是檢查系統(tǒng)與否確實

能提供系統(tǒng)方案闡明書中指定功能的有效措施。（常見的聯(lián)調(diào)測試）

系統(tǒng)測試的目的是對最終軟件系統(tǒng)進(jìn)行全面的測試,保證最終軟件系統(tǒng)滿足產(chǎn)品需求并

且遵照系統(tǒng)設(shè)計。

驗收測試是布署軟件之前的最終一種測試操作。驗收測試的目的是保證軟件準(zhǔn)備就緒，

并且可以讓最終顧客將其用于執(zhí)行軟件的既定功能和任務(wù)。

驗收測試是向未來的顧客表明系統(tǒng)可以像預(yù)定規(guī)定那樣工作。經(jīng)集成測試后，已經(jīng)按照

設(shè)計把所有的模塊組裝成一種完整的軟件系統(tǒng)，接口錯誤也已經(jīng)基本排除了，接著就應(yīng)當(dāng)深

入驗證軟件的有效性，這就是驗收測試的任務(wù)，即軟件的功能和性能如同顧客所合理期待的

那樣?

六、測試計劃工作的目的是什么？測試計劃工作的內(nèi)容都包括什么？其中哪些

是最重要的J?

軟件測試計劃是指導(dǎo)測試過程的大綱性文獻(xiàn)，包括了產(chǎn)品概述、測試方略、測試措施、

測試區(qū)域、測試配置、測試周期、測試資源、測試交流、風(fēng)險分析等內(nèi)容。借助軟件測試計

劃，參與測試的項目組員，尤其是測試管理人員，可以明確測試任務(wù)和測試措施，保持測試

實行過程的順暢溝通，跟蹤和控制測試進(jìn)度，應(yīng)對測試過程中的多種變更。

測試計劃和測試詳細(xì)規(guī)格、測試用例之間是戰(zhàn)略和戰(zhàn)術(shù)的關(guān)系，測試計劃重要從宏觀上

規(guī)劃測試活動的I范圍、措施和資源配置，而測試詳細(xì)規(guī)格、測試用例是完畢測試任務(wù)的詳細(xì)

戰(zhàn)術(shù)。因此其中最重要的是測試測試方略和測試措施（最佳是能先評審）

七、您認(rèn)為做好測試計劃工作的關(guān)鍵是什么？

a.明確測試的目的，增強測試計劃的實用性

編寫軟件測試計劃得重要目的就是使測試過程可以發(fā)現(xiàn)更多的軟件缺陷，因此軟件測試

計劃的價值取決于它對協(xié)助管理測試項目，并且找出軟件潛在的缺陷。因此，軟件測試計劃

中陳J測試范圍必須高度覆蓋功能需求，測試措施必須切實可行，測試工具并且具有較高的實

用性，便于使用，生成的測試成果直觀、精確。

b.堅持“5W”規(guī)則，明確內(nèi)容與過程

“5W”規(guī)則指的是“What（做什么）"、“Why（為何做）"、“When（何時做）”、

“Where（在哪里）"、“How（怎樣做）”。運用“5W”規(guī)則創(chuàng)立軟件測試計劃，可以

協(xié)助測試團(tuán)體理解測試的目的（Why）,明確測試的范圍和內(nèi)容（What）,確定測試的開

始和結(jié)束日期（When）,指出測試的措施和工具（How）,給出測試文檔和軟件的寄存位

置（Where）。

c.采用評審和更新機制，保證測試計劃滿足實際需求

測試計劃寫作完畢后，假如沒有通過評審，直接發(fā)送給測試團(tuán)體，測試計劃內(nèi)容的也許

不精確或遺漏測試內(nèi)容，或者軟件需求變更引起測試范圍的增減，而測試計劃的內(nèi)容沒有及

時更新，誤導(dǎo)測試執(zhí)行人員。

d.分別創(chuàng)立測試計劃與測試詳細(xì)規(guī)格、測試用例

應(yīng)把詳細(xì)的測試技術(shù)指標(biāo)包括到獨立創(chuàng)立的測試詳細(xì)規(guī)格文檔，把用于指導(dǎo)測試小組執(zhí)

行測試過程的測試用例放到獨立創(chuàng)立的測試用例文檔或測試用例管理數(shù)據(jù)庫中。測試計劃和

測試詳細(xì)規(guī)格、測試用例之間是戰(zhàn)略和戰(zhàn)術(shù)的關(guān)系，測試計劃重要從宏觀上規(guī)劃測試活動的

范圍、措施和資源配置，而測試詳細(xì)規(guī)格、測試用例是完畢測試任務(wù)的詳細(xì)戰(zhàn)術(shù)。

八、您所熟悉日勺測試用例設(shè)計措施均有哪些？請分別以詳細(xì)的例子來闡明這些

措施在測試用例設(shè)計工作中的應(yīng)用。

a.等價類劃分

劃分等價類：等價類是指某個輸入域的子集合.在該子集合中，各個輸入數(shù)據(jù)對于揭發(fā)

程序中的錯誤都是等效的.并合理地假定:測試某等價類的I代表值就等于對這一類其他值的

測試.因此,可以把所有輸入數(shù)據(jù)合理劃分為若干等價類,在每一種等價類中取一種數(shù)據(jù)作

為測試的輸入條件,就可以用少許代表性的測試數(shù)據(jù).獲得很好的測試成果.等價類劃分可

有兩種不一樣的狀況:有效等價類和無效等價類.

b.邊界值分析法

邊界值分析措施是對等價類劃分措施的補充。測試工作經(jīng)驗告訴我,大量的錯誤是發(fā)生

在輸入或輸出范圍的邊界上,而不是發(fā)生在輸入輸出范圍的內(nèi)部.因此針對多種邊界狀況設(shè)

計測試用例,可以查出更多的錯誤.

使用邊界值分析措施設(shè)計測試用例,首先應(yīng)確定邊界狀況.一般輸入和輸出等價類的邊

界，就是應(yīng)著重測試的邊界狀況.應(yīng)當(dāng)選用恰好等于,剛剛不小于或剛剛不不小于邊界的值

作為測試數(shù)據(jù)，而不是選用等價類中的經(jīng)典值或任意值作為測試數(shù)據(jù).

c.錯誤推測法

基于經(jīng)驗和直覺推測程序中所有也許存在的多種錯誤，從而有針對性的設(shè)計測試用例

的措施.錯誤推測措施的基本思想：列舉出程序中所有也許有的錯誤和輕易發(fā)生錯誤的

特殊狀況,根據(jù)他們選擇測試用例.例如，在單元測試時曾列出的許多在模塊中常見的錯

誤.此前產(chǎn)品測試中曾經(jīng)發(fā)現(xiàn)口勺錯誤等，這些就是經(jīng)驗的總結(jié).尚有，輸入數(shù)據(jù)和輸出

數(shù)據(jù)為0的狀況.輸入表格為空格或輸入表格只有一行.這些都是輕易發(fā)生錯誤的狀況.

可選擇這些狀況下的例子作為測試用例.

d.因果圖措施

前面簡介的等價類劃分措施和邊界值分析措施,都是著重考慮輸入條件,但未考慮輸入

條件之間的聯(lián)絡(luò)，互相組合等.考慮輸入條件之間的互相組合，也許會產(chǎn)生某些新的狀

況.但要檢查輸入條件的組合不是一件輕易的事情，雖然把所有輸入條件劃提成等價類，

他們之間的合狀況也相稱多.因此必須考慮采用一種適合于描述對于多種條件的組合,時

應(yīng)產(chǎn)生多種動作的形式來考慮設(shè)計測試用例.這就需要運用因果圖（邏輯模型）。因果圖

措施最終身成的就是鑒定表.它適合于檢查程序輸入條件的多種組合狀況.

九、軟件測試的I目的I?

測試的目區(qū)I是想以至少的人力、物力和時間找出軟件中潛在的多種錯誤和缺陷，通過修

正種錯誤和缺陷提高軟件質(zhì)量，回避軟件公布后由于潛在的軟件缺陷和錯誤導(dǎo)致的隱患帶來

的商業(yè)風(fēng)險。

十、什么是軟件測試？

使用人工或自動手段來運行或測定某個系統(tǒng)的過程,其目的在于檢查它與否滿足規(guī)定的

需求或是弄清預(yù)期成果與實際成果之間的差異。

軟件測試就是在軟件投入運行前，對軟件需求分析、設(shè)計規(guī)格闡明和編碼的最終復(fù)審,

是軟件質(zhì)量保證的關(guān)鍵環(huán)節(jié)。軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。

十一、基于WEB信息管理系統(tǒng)測試時應(yīng)考慮的原因有哪些？

1、功能測試

a）鏈接測試

b）表單測試

c）Cookies測試

d）設(shè)計語言測試

e）數(shù)據(jù)庫測試

2、性能測試

a）連接速度測試

b）負(fù)載測試

c）壓力測試

3、可用性測試

a）導(dǎo)航測試

b）圖形測試

c）內(nèi)容測試

d）整體界面測試

4、客戶端兼容性測試

a）平臺測試

b）瀏覽器測試

5、安全性測試

十二、軟件當(dāng)?shù)鼗瘻y試比功能測試均有哪些方面需要注意？

軟件當(dāng)?shù)鼗瘻y試的目的：

軟件當(dāng)?shù)鼗瘻y試的測試方略：1.當(dāng)?shù)鼗浖诙喾N當(dāng)?shù)鼗僮飨到y(tǒng)上安裝并測試。2.

源語言軟件安裝在另一臺相似源語言操作系統(tǒng)上，作為對比測試。3.重點測試因當(dāng)?shù)鼗?/p>

的）軟件的功能和軟件界面的錯誤。4.測試當(dāng)?shù)鼗浖姆g質(zhì)量。5.手工測試和自動測試

相結(jié)合。

十三、軟件測試項目從什么時候開始？為何？

軟件測試應(yīng)當(dāng)在需求分析階段就介入，由于測試的對象不僅僅是程序編碼,應(yīng)當(dāng)對軟件

開發(fā)過程中產(chǎn)生的所有產(chǎn)品都測試,并且軟件缺陷存在放大趨勢.缺陷發(fā)現(xiàn)的越晚，修復(fù)它所

花費的成本就越大.

十四、需求測試注意事項有哪些？

一種良好的需求應(yīng)當(dāng)具有一下特點：

完整性：每一項需求都必須將所要實現(xiàn)的功能描述清晰，以使開發(fā)人員獲得設(shè)計和實現(xiàn)

這些功能所需的所有必要信息。

對時性：每一項需求都必須精確地陳說其要開發(fā)的功能。

一致性：一致性是指與其他軟件需求或高層（系統(tǒng)，業(yè)務(wù)）需求不相矛盾。

可行性：每一項需求都必須是在已知系統(tǒng)和環(huán)境的權(quán)能和限制范圍內(nèi)可以實行日勺。

無二義性：對所有需求闡明的讀者都只能有一種明確統(tǒng)一的解釋，由于自然語言極易導(dǎo)

致二義性，因此盡量把每項需求用簡潔明了的顧客性的語言體現(xiàn)出來。

強健性：需求的闡明中與否對也許出現(xiàn)的異常進(jìn)行了分析，并且對這些異常進(jìn)行了容錯

處理。

必要性：“必要性”可以理解為每項需求都是用來授權(quán)你編寫文檔的“本源”。要使每

項需求

都能回溯至某項客戶的輸入，如UseCase或別的來源。

可測試性：每項需求都能通過設(shè)計測試用例或其他口勺驗證措施來進(jìn)行測試。

可修改性：每項需求只應(yīng)在SRS中出現(xiàn)一次。這樣更改時易于保持一致性。此外，

使用目錄表、索引和互相參照列表措施將使軟件需求規(guī)格闡明書更輕易修改。

可跟蹤性：應(yīng)能在每項軟件需求與它的本源和設(shè)計元素、源代碼、測試用例之間建立起

鏈接鏈，這種可跟蹤性規(guī)定每項需求以一種構(gòu)造化的，粒度好(fine-grained)

的方式編寫并單獨標(biāo)明，而不是大段大段的論述。

十五、簡述一下缺陷的生命周期

軟件缺陷的生命周期指的是一種軟件缺陷被發(fā)現(xiàn)、匯報到這個缺陷被修復(fù)、驗證直至

最終關(guān)閉的完整過程。

簡樸的軟件缺陷生命周期：

1、發(fā)現(xiàn)一一打開：測試人員找到軟件缺陷并將軟件缺陷提交給開發(fā)人員；

2、打開一一修復(fù)：開發(fā)人員再現(xiàn)、修復(fù)缺陷，然后提交測試人員去驗證；

3、修復(fù)一一關(guān)閉：測試人員驗證修復(fù)過的軟件，關(guān)閉已不存在的缺陷。

不過這是一種理想的狀態(tài)，在實際的工作中是很難有這樣的順利的，需要考慮的多種狀

況都還是非常多的。

復(fù)雜的軟件缺陷生命周期：

1、新建一種軟件缺陷，這個軟件缺陷是(open)狀態(tài)，進(jìn)行bug審查，不是代碼問題,

就是設(shè)計需要修改；

2、新建一種軟件缺陷，這個軟件缺陷是(open)狀態(tài)，進(jìn)行bug審查，后來修改的，

就可以延期；

3、新建一種軟件缺陷，這個軟件缺陷是(open)狀態(tài)，進(jìn)行bug審查，實際沒有這個

bug,可以將其關(guān)閉；

4、新建一種軟件缺陷，這個軟件缺陷是(open)狀態(tài)，看與否清晰可重現(xiàn)，假如不能

重現(xiàn)，就是缺乏信息，需要返回到(open)狀態(tài)；假如可以重現(xiàn)，就進(jìn)行修正，修正后關(guān)閉，

進(jìn)行回歸測試。

十六、為何要寫用例：

我們編寫測試用例，有如下的好處：

便于團(tuán)體交流：假如說一種測試團(tuán)體有10個組員，大家測試日勺時候都各自為政，沒有

統(tǒng)一的原則，測試的效率無疑會大打折扣；假如大家都遵照統(tǒng)一的用例規(guī)范去寫，就會處理

這一問題。

便于反復(fù)測試：大家懂得，軟件在實際開發(fā)過程中是會有不一樣版本的，例如會從L0

升級到10.0,那么假如不寫測試用例13勺話,在測試10.0版本的時候,你能完全記得1.0版

本時你做過哪些測試嗎？測試用例就像一種備忘錄同樣，便于反復(fù)測試。

便于跟蹤記錄：這一點是針對測試經(jīng)理或是項目經(jīng)理來說的，項目負(fù)責(zé)人通過看測試用

例口勺執(zhí)行狀況，就能理解到項目目前的概況，例如已經(jīng)執(zhí)行了哪些測試，尚有哪些測試沒有

執(zhí)行，測試沒有通過的地方重要集中在哪些模塊等。

便于顧客自測：尤其是項目軟件，有的時候顧客但愿自己測試一下軟件產(chǎn)品，不過顧客

大都是非專業(yè)人士，他需要根據(jù)你寫好的用例來更好的檢查產(chǎn)品的質(zhì)量。

說了這樣多編寫測試用例的長處，那它有無缺陷呢？有一種明顯的缺陷就是需要花費大

量的時間，一般編寫測試用例的時間比實際執(zhí)行測試的時間還要長，這一點大家會在實際

工作中有深刻的體會

十七、測試的種類諸多，大概有1、代碼、函數(shù)級測試2、模塊、組件級

測試3、系統(tǒng)測試，請說出這些測試最佳由那些人員完畢，測試的根據(jù)是什么，

并闡明理由。

代碼、函數(shù)級測試一般由白盒測試人員完畢，他們需要測試的是對代碼的測試

模塊、組件級測試重要有灰盒或者黑盒人員測試，需要對所測試的程序內(nèi)部構(gòu)造與原理有較

強的理解，屬于各模塊間的銜接與關(guān)系，可以測試出模塊之間變動而導(dǎo)致對其他模塊的影響

系統(tǒng)測試在于模塊測試與單元測試的基礎(chǔ)上進(jìn)行測試。理解系統(tǒng)功能與性能，根據(jù)測試用例

進(jìn)行全面的測試。

十八、設(shè)計測試用例和測試數(shù)據(jù)時應(yīng)當(dāng)考慮哪些方面，即不一樣的測試用例和

數(shù)據(jù)各自針對那些方面進(jìn)行測試。

設(shè)計測試用例時需要注意的是，除了對整體流程及功能注意外，還要注意強度測試、性

能測試、壓力測試、邊界值測試、穩(wěn)定性測試、安全性測試等多方面。

設(shè)計測試用例在除了常用數(shù)據(jù)外，還需要考慮極限值、邊界值、反復(fù)值、0值及負(fù)值，即不

一樣的測試用例需要不一樣類型的數(shù)據(jù)值來進(jìn)行測試。

測試用例的設(shè)計

一、某程序規(guī)定：”輸入三個整數(shù)a、b、c分別作為三邊的邊長構(gòu)成三角

形。通過程序鑒定所構(gòu)成的三角形的類型，當(dāng)此三角形為一般三角形、等腰三

角形及等邊三角形時，分別作計算…"。用等價類劃分措施為該程序進(jìn)行測試

用例設(shè)計。（三角形問題的復(fù)雜之處在于輸入與輸出之間的關(guān)系比較復(fù)雜。）

分析題目中給出和隱含的對輸入條件的規(guī)定：

（1）整數(shù)（2）三個數(shù)（3）非零數(shù)（4）正數(shù)

（5）兩邊之和不小于第三邊（6）等腰（7）等邊

假如a、b、c滿足條件（1）~（4）,則輸出下列四種狀況之一：

1）假如不滿足條件（5）,則程序輸出為“非三角形"。

2）假如三條邊相等即滿足條件（7）,則程序輸出為“等邊三角形”。

3）假如只有兩條邊相等、即滿足條件（6）,則程序輸出為“等腰三角形”。

4）假如三條邊都不相等，則程序輸出為“一般三角形”。

列出等價類表并編號

覆蓋有效等價類的測試用例：

abc覆蓋等價類號碼

345(1)—(7)

445(1)—(7),(8)

455(1)—(7),(9)

545(1)—(7),(10)

444(1)—(7),(11)

覆蓋無效等價類的測試用例：

二、假如測試程序向打印機輸送打印內(nèi)容，應(yīng)當(dāng)選用那些破壞性測試用例。

答：用此程序打印大量的）文獻(xiàn)

長時間不停止的使用此軟件進(jìn)行打印操作

長時間不停止的打印大數(shù)量及大文獻(xiàn)的操作；

在打印過程中斷電、重啟等破壞性操作

三、下圖是windows保留對話框，假如為文獻(xiàn)名建立測試用例，等價類應(yīng)當(dāng)怎

樣劃分？

1長文獻(xiàn)名

2短文獻(xiàn)名

3特殊字符/，\、=-等

4中文/英文等

四、假設(shè)由一種文本框規(guī)定輸入10各字符的郵政編碼，對于該文本框應(yīng)當(dāng)怎樣

劃分等價類？

1特殊字符與否可以輸入

2英文字母與否可以輸入

3中文與否................

4與否可以不輸入字符就可以確定

5輸入超過10個字符

6字符可以混合中英數(shù)字

五、給你一臺冰箱，你將怎樣測試它？

首先分析冰箱的重要功能：制冷和保鮮。

首先通上電，檢查冰箱與否能啟動。這是最基本的，假如這一步都不滿足，背面的也就

無法進(jìn)行了。然后找一小碗水放進(jìn)去，一段時間后觀測它與否可以變成冰塊。這個過程中還

可以檢查一下冰箱運行的時候聲音與否太大，與否漏水，冰箱里面與否有異味等。

然后再找一盤蔬菜（熟的和生的）或水果，觀測可以保持幾天的新鮮。此時需要設(shè)定期望值,

參照某些數(shù)據(jù)和資料，事先要懂得該種菜和水果在常溫下保鮮是多少天，有必要時還可以和

其他品牌的冰箱做比較。最終也許還要附加的功能，例如里面的燈與否會亮，溫度與否可調(diào)

等。

六、水杯的測試

一種：

測試項目：杯子

需求測試:查看杯子使用闡明書

界面測試:查看杯子外觀

功能度：用水杯裝水看漏不漏；水能不能被喝到

安全性：杯子有無毒或細(xì)菌

可*性：杯子從不一樣高度落下的損壞程度

可移植性：杯子再不一樣的地方、溫度等環(huán)境下與否都可以正常使用

兼容性：杯子與否可以容納果汁、白水、酒精、汽油等

易用性：杯子與否燙手、與否有防滑措施、與否以便飲用

顧客文檔：使用手冊與否對杯子的使用方法、限制、使用條件等有詳細(xì)描述

疲勞測試：將杯子盛上水（案例一）放24小時檢查泄漏時間和狀況；盛上汽油（案例二）

放24小時檢查泄漏時間和狀況等

壓力測試：用根針并在針上面不停加重量，看壓強多大時會穿透

跌落測試：杯子加包裝（有填充物），在多高的狀況摔下不破損

震動測試：杯子