2020年軟件測試工程師面試基礎(chǔ)題

2020年軟件測試工程師面試基礎(chǔ)題

軟件測試復(fù)習(xí)內(nèi)容

以下列舉出來的問題大部分是要掌握的，可參考思維導(dǎo)圖來看。

1.什么是測試？

答：

（美國電器和電子工程師協(xié)會(huì)）IEEE

提出的軟件工程標(biāo)準(zhǔn)術(shù)語，使用人工和自動(dòng)

手段來運(yùn)行或測試某個(gè)系統(tǒng)的過程，目的在

于檢驗(yàn)它是否滿足規(guī)定的需求或是弄清預(yù)

期結(jié)果與實(shí)際結(jié)果之間的差別。

簡單定義:找出軟件中的BUG

2.為什么要測試？

答：

在軟件開發(fā)過程中容易出現(xiàn)缺乏有效

溝通,軟件復(fù)雜，編程錯(cuò)誤，需求不斷變更,

時(shí)間的壓力，缺乏文檔的代碼,軟件開發(fā)工

具和人員的自大等原因引發(fā)的錯(cuò)誤,通過測

試能夠找出其中的錯(cuò)誤,解決錯(cuò)誤,從而提

高軟件的質(zhì)量

3.軟件的生命周期分為哪幾個(gè)階段?具體的內(nèi)容

是什么？

答：

計(jì)劃

工作內(nèi)容

1.確定軟件開發(fā)總目標(biāo)；

2.給出軟件的功能、性能、可靠性以及接口等方

面的設(shè)想；

3.研究完成該項(xiàng)目的可行性，探討問題解決方

案；

4.對(duì)可供開發(fā)使用的資源、成本、可取得的效益

和開發(fā)進(jìn)度作出估計(jì)；

5.制定完成開發(fā)任務(wù)的實(shí)施計(jì)劃。

需求分析

工作內(nèi)容

對(duì)開發(fā)的軟件進(jìn)行詳細(xì)的定義，由需

求分析人員和用戶共同討論決定，哪些需求

是能夠滿足的，并且給予確切的描述，寫出

軟件需求說明書SRS(Software

RequirementSpecification)o

設(shè)計(jì)

工作內(nèi)容

設(shè)計(jì)是軟件工程的技術(shù)核心,這個(gè)階段

需要完成設(shè)計(jì)說明書

1.概要設(shè)計(jì)(HLD),在設(shè)計(jì)階段把各項(xiàng)需求轉(zhuǎn)換

成相應(yīng)的體系結(jié)構(gòu)，每一部分是功能明確的模

塊；

2.詳細(xì)設(shè)計(jì)(LLD),對(duì)每個(gè)模塊要完成的工作進(jìn)

行具體的描述。

編碼

工作內(nèi)容

把軟件設(shè)計(jì)轉(zhuǎn)換成計(jì)算機(jī)能夠接

受的程序，即寫成以某個(gè)程序設(shè)計(jì)語言

表示的源程序清單，建立數(shù)據(jù)庫。

測試

工作內(nèi)容

測試是檢驗(yàn)軟件是否符合客戶需求,達(dá)

到質(zhì)量要求，一般由獨(dú)立的小組執(zhí)行，測試

工作分為：

單元測試；集成測試；系統(tǒng)測試

運(yùn)行和維護(hù)

工作內(nèi)容

這個(gè)階段將軟件交付用戶投入正

式使用，以后便進(jìn)入維護(hù)階段，可能有

多種原因需要對(duì)它進(jìn)行修改，如軟件錯(cuò)

誤、系統(tǒng)軟件升級(jí)、增強(qiáng)軟件功能、提

高性能等。

4.研發(fā)團(tuán)隊(duì)的組織構(gòu)架與流程是什么？

答：

組織架構(gòu)

?軟件開發(fā)組

開發(fā)經(jīng)理

分析人員

設(shè)計(jì)人員

開發(fā)人員

?軟件測試組

測試經(jīng)理

測試人員

?配置管理組

配置經(jīng)理

CMO（配置管理員）

研發(fā)流程

?瀑布模型

應(yīng)用的最為廣泛的一種模型，也是最容

易理解和掌握的模型，然而它的缺陷也

是顯而易見的。

?螺旋模型

綜合了基本的瀑布式模型和演化/漸增

原型方法。

?RUP流程

所有工作流在各個(gè)階段都有體現(xiàn)。

?IPD流程

從整個(gè)產(chǎn)品角度出發(fā)，不僅僅針對(duì)研

發(fā)。

5.測試階段怎么劃分？

答：

1.測試計(jì)劃階段

2.測試設(shè)計(jì)階段

3.測試實(shí)施階段

4.測試執(zhí)行階段

6.什么是UT,IT,ST?它們有什么區(qū)別？

答：

UT:單元測試

IT：集成測試

ST:系統(tǒng)測試

區(qū)另U：

測試方法考察范圍評(píng)估標(biāo)準(zhǔn)

單控制流測法單元內(nèi)部的數(shù)據(jù)邏輯覆蓋率

元數(shù)據(jù)流測法結(jié)構(gòu)、邏輯控制

測排錯(cuò)測法、異常處理等

試分域測法

集自頂向下增至測試方法接口與接口數(shù)據(jù)接口覆蓋率

成自底向上增至測試方法傳遞關(guān)系，

測混合增至測試方法模塊組合后的

試整體功能

恢復(fù)測試方法這個(gè)系統(tǒng)對(duì)需測試用例對(duì)需求

安全測試方法求的符合度規(guī)格的覆蓋率

系強(qiáng)度測試方法

統(tǒng)性能測試方法

測容量測試方法

試正確性測試方法

可靠性測試方法

兼容性測試方法

7.什么是回歸測試?為什么要回歸測試？回歸測

試的流程是什么？回歸測試的測試策略有哪

些？

答：

回歸測試是指軟件系統(tǒng)被修改或擴(kuò)充

（如系統(tǒng)功能增強(qiáng)或升級(jí)）后重新進(jìn)行的測

試，是為了保證對(duì)軟件所做的修改沒有引入

新的錯(cuò)誤而重新進(jìn)行的測試。

回歸測試目的是驗(yàn)證缺陷得到了正確

的修復(fù)，同時(shí)對(duì)系統(tǒng)的變更沒有影響以前的

功能。

流程：

1.在測試策略制定階段,制定回歸測試策略

2.確定需要回歸測試的版本

3.測試版本發(fā)布后,按照回歸測試策略來執(zhí)行回

歸測試

4.回歸測試通過，關(guān)閉缺陷跟蹤單

5.回歸測試不通過，缺陷跟蹤單返回給開發(fā)人

員，

測試策略：

1.完全重復(fù)測試:重新執(zhí)行前期設(shè)計(jì)的用例，來

確認(rèn)問題修改的真確性和修改的擴(kuò)散局部影

響性

2.選擇性重復(fù)測試：

1）覆蓋修改法:針對(duì)被修改的部分,選取或重新

構(gòu)造測試用例驗(yàn)證沒有錯(cuò)誤再次發(fā)生的選擇

方法

2）周邊影響法:該方法包括覆蓋修改法,還要分

析修改后對(duì)擴(kuò)散的影響

3）指標(biāo)達(dá)成法:先確定一個(gè)達(dá)成的指標(biāo),基于這

種要求選擇一個(gè)最小的測試用例集合

8.畫V&V模型?

答：

9.軟件質(zhì)量的定義是什么?影響軟件質(zhì)量的因素

是哪些?ISO的八大原則是什么？

答：

定義:一個(gè)實(shí)體的所有特性，基于這些

特性能夠滿足明顯的或隱含的需求。而質(zhì)量

就是實(shí)體基于這些特性滿足需求的程度

因素：

流程、技術(shù)、組織。

流程:一組活動(dòng)（活動(dòng)是否都是必須的；活

動(dòng)角色之間的關(guān)系）

過程:一組將輸入轉(zhuǎn)化為輸出的相關(guān)聯(lián)或相

互作用的活動(dòng)。

原則；

1.以顧客為中心:組織依存于其顧客，因此，組

織應(yīng)理解顧客當(dāng)前的和未來的需求，滿足顧客

要求并爭取趕超顧客期望。

2.領(lǐng)導(dǎo)作用：,并創(chuàng)造使員工能夠充參與實(shí)現(xiàn)組

織目標(biāo)的環(huán)境。

3.全員參與:各級(jí)人員是組織之本，只有他們的

充分參與，才能使他們的才干為組織帶來最大

的收益。

4.過程方法：將相關(guān)的資源和活動(dòng)作為過程進(jìn)

行管理，能夠更高效地得到期望的結(jié)果。

5.管理系統(tǒng)方法:針對(duì)設(shè)定的目標(biāo),，有助于提高

組織的有效性和效率。

6.持續(xù)改進(jìn):持續(xù)改進(jìn)是組織的一個(gè)永恒的目

標(biāo)。

7.基于事實(shí)的決策方法:對(duì)數(shù)據(jù)和信息的邏輯分

析或直覺判斷是有效決策的基礎(chǔ)。

8.互利的供方關(guān)系:通過互利的關(guān)系，增強(qiáng)組織

及其供方創(chuàng)造價(jià)值的能力。其中與軟件產(chǎn)品產(chǎn)

品優(yōu)其相關(guān)有：（）

10.CMM/CMMI是什么？它的等級(jí)怎么劃分?有什

么目的?有什么作用？

答：

（1）能力成熟度模型；一種比較流行的軟件

質(zhì)量管理體系

（2）劃分:初始級(jí)；可重復(fù)級(jí)；已定義級(jí)；

已管理級(jí)；優(yōu)化級(jí)；

（3）目的:評(píng)估軟件承包商能力

協(xié)助軟件組織改進(jìn)過程，提高過

程能力

（4）作用:業(yè)界的實(shí)施標(biāo)準(zhǔn)

業(yè)界的一種交流語言

是中國企業(yè)獲取國際訂單的門

檻

是向下采購的保障

是降低軟件聲場風(fēng)險(xiǎn)的有力手

段

11.描述軟件質(zhì)量模型中的內(nèi)容？

答：

功能性：

當(dāng)軟件在指定的條件下使用時(shí),軟件產(chǎn)品提

供滿足明確和隱含需求的功能的能力

1.適合性Suitability軟件產(chǎn)品為指定的任

務(wù)和用戶目標(biāo)提供一組合適的功能的能力。

2.準(zhǔn)確性Accuracy——軟件產(chǎn)品提供具有所需

精確度的正確或相符的結(jié)果或效果的能力。

3.互操作性interoperability--軟件產(chǎn)品與

一個(gè)或更多的規(guī)定系統(tǒng)進(jìn)行交互的能力。

4.保密安全性security--軟件產(chǎn)品保護(hù)信息

和數(shù)據(jù)的能力，以使未授權(quán)的人員或系統(tǒng)不能

閱讀或修改這些信息和數(shù)據(jù)，而不拒絕授權(quán)人

員或系統(tǒng)對(duì)它們的訪問。

5.功能性的依從性functionality

compliance-軟件產(chǎn)品遵循與功能相關(guān)的標(biāo)

準(zhǔn)、約定或法規(guī)以及類似規(guī)定的能力。這些標(biāo)

準(zhǔn)要考慮國際標(biāo)準(zhǔn)、國家標(biāo)準(zhǔn)、行業(yè)標(biāo)準(zhǔn)、企

業(yè)內(nèi)部規(guī)范等。

可靠性：

在指定條件下使用時(shí)，軟件產(chǎn)品維持規(guī)定的

性能級(jí)別的能力

L成熟性maturity--軟件產(chǎn)品為避免由軟件

中錯(cuò)誤而導(dǎo)致失效的能力。

2.容錯(cuò)性faulttolerance-在軟件出現(xiàn)故障

或者違反指定接口的情況下，軟件產(chǎn)品維持規(guī)

定的性能級(jí)別的能力。

3.易恢復(fù)性recoverability--在失效發(fā)生的

情況下，軟件產(chǎn)品重建規(guī)定的性能級(jí)別并恢復(fù)

受直接影響的數(shù)據(jù)的能力

4.可靠性的依從性reliability

comp1iance軟件產(chǎn)品遵循與可靠性相關(guān)的

標(biāo)準(zhǔn)、約定或法規(guī)的能力。

易用性：

在指定條件下使用時(shí)，軟件產(chǎn)品被理解、學(xué)

習(xí)、使用和吸引用戶的能力

1.易理解性u(píng)nderstandability軟件產(chǎn)品使

用戶能理解軟件是否合適以及如何能將軟件

用于特定的任務(wù)和使用環(huán)境的能力。

2.易學(xué)性learnability--軟件產(chǎn)品使用戶能

學(xué)習(xí)其應(yīng)用的能力。

3.易操作性operability-軟件產(chǎn)品使用戶能

操作和控制它的能力。

4.吸引性attractiveness--軟件產(chǎn)品吸引用

戶的能力

5.易用性的依從性u(píng)sabilitycompliance--

軟件產(chǎn)品遵循與易用性相關(guān)的標(biāo)準(zhǔn)、約定、風(fēng)

格指南或法規(guī)的能力。這些標(biāo)準(zhǔn)要考慮國際標(biāo)

準(zhǔn)、國家標(biāo)準(zhǔn)、行業(yè)標(biāo)準(zhǔn)、企業(yè)內(nèi)部規(guī)范等，

例如企業(yè)內(nèi)部的界面規(guī)范。

效率：

在規(guī)定條件下，相對(duì)于所用資源的數(shù)量，軟

件產(chǎn)品可提供適當(dāng)性能的能力

1.時(shí)間特性:timebehavior--在規(guī)定條件下，

軟件產(chǎn)品執(zhí)行其功能時(shí)，提供適當(dāng)?shù)捻憫?yīng)和處

理時(shí)間以及吞吐率的能力。即完成用戶的某個(gè)

功能需要的響應(yīng)時(shí)間。

2.資源利用性：resourceutilization--在規(guī)

定條件下，軟件產(chǎn)品執(zhí)行其功能時(shí)，使用合適

的資源數(shù)量和類別的能力。

3.效率依從性:efficiencycompliance--軟件

產(chǎn)品遵循與效率相關(guān)的標(biāo)準(zhǔn)或約定的能力。

維護(hù)性：

軟件產(chǎn)品可被修改的能力。修改可能包括修

正、改進(jìn)軟件對(duì)環(huán)境、需求、和功能規(guī)格說

明變化的適應(yīng)

1.易分析性analyzability診斷軟件產(chǎn)品

中缺陷或失效原因的能力。

2.易改變性changeability--軟件產(chǎn)品使指定

的修改能夠被實(shí)現(xiàn)的能力。

3.穩(wěn)定性stability—-軟件產(chǎn)品避免由于軟件

修改而造成意外結(jié)果的能力。

4.易測試性testability--軟件產(chǎn)品使已修改

軟件能被確認(rèn)的能力。

5.維護(hù)性的依從性maintainability

compliance-軟件產(chǎn)品遵循與維護(hù)性相關(guān)的

標(biāo)準(zhǔn)或約定的能力。

可移植性：

軟件產(chǎn)品從一種環(huán)境遷移到另一種環(huán)境可

正常使用或滿足用戶需求的能力

1.適應(yīng)性adaptability--軟件產(chǎn)品無需采用

有別于為考慮該軟件的目的而準(zhǔn)備的活動(dòng)和

手段就能夠適應(yīng)不同的環(huán)境的能力。

2.易安裝性installability-—軟件產(chǎn)品在指

定環(huán)境中被安裝的能力。

3.共存性co-existence-軟件產(chǎn)品在公共環(huán)

境中同與其分享公共資源的其它獨(dú)立軟件共

存的能力。

4.易替換性replaceability--軟件產(chǎn)品在同

樣的環(huán)境下，替代另一個(gè)相同用途的指定軟件

產(chǎn)品的能力。

5.可移植性的依從性portability

compliance--軟件產(chǎn)品遵循與可移植性相關(guān)

的標(biāo)準(zhǔn)或約定能力。

12.測試的方法有哪些？

答：

白盒測試、黑盒測試、灰盒測試、0測試，

a測試、可移植性測試、冒煙測試等

13.什么是白盒測試？

答：

白盒測試是根據(jù)被測試程序的內(nèi)部結(jié)

構(gòu)設(shè)計(jì)測試用例的一類測試，有人也稱它為

透明盒或者玻璃盒測試，涉及到軟件設(shè)計(jì)的

細(xì)節(jié)。比如單元測試一般采用白盒測試方

法，并參考LLD（詳細(xì)設(shè)計(jì)）

14.什么是黑盒測試？

答：

黑盒測試又稱功能測試、數(shù)據(jù)驅(qū)動(dòng)測試

或者基于規(guī)格說明的測試，被測試程序當(dāng)作

黑盒處理，無法了解其內(nèi)部的構(gòu)造。比如系

統(tǒng)測試一般采用黑盒測試方法，并參考SRS

15.什么是靜態(tài)測試？

答：

不運(yùn)行被測試的軟件系統(tǒng)，而是采用其

它手段和技術(shù)對(duì)被測試軟件進(jìn)行檢測的一

種測試技術(shù)。例如:代碼走讀、文檔評(píng)審、

程序分析等都是靜態(tài)測試的范疇。常用技術(shù)

有靜態(tài)分析技術(shù)

16.什么是動(dòng)態(tài)測試？

答：

按照預(yù)先設(shè)計(jì)的數(shù)據(jù)和步驟去運(yùn)行被

測軟件系統(tǒng)，從而對(duì)被測軟件系統(tǒng)進(jìn)行檢測

的一種測試技術(shù)。常用技術(shù)有動(dòng)態(tài)分析技術(shù)

17.什么是人工測試？

答：

測試活動(dòng)（如評(píng)審、測試設(shè)計(jì)、測試執(zhí)

行等）由人來完成，狹義上是指測試執(zhí)行由

人工完成，這是最基本的測試形式

18.什么是自動(dòng)化測試?

答：

一般是指通過計(jì)算機(jī)模擬人的測試行

為，替代人的測試活動(dòng)，狹義上是指測試執(zhí)

行由計(jì)算機(jī)來完成

19.邏輯覆蓋關(guān)注的內(nèi)容是哪些？

答：

1.語句覆蓋

2.判定覆蓋

3.條件覆蓋

4.判定一條件覆蓋

5.路徑覆蓋

20.常見的黑盒測試方法有哪些？

答：

1.等價(jià)類劃分法

2.邊界值分析法

3.因果圖分析法

4.判定表法

5.正交試驗(yàn)法

6.狀態(tài)遷移法

21.什么是同行評(píng)審？

答：

同行評(píng)審：（PeerReview）是一種通過

作者的同行來確認(rèn)缺陷和需要變更區(qū)域的

檢查方法。需要進(jìn)行同行評(píng)審的特定產(chǎn)品在

定義項(xiàng)目軟件過程的時(shí)候被確定并且作為

軟件開發(fā)計(jì)劃的一部分被安排了進(jìn)度。根據(jù)

形式正規(guī)的程度分為：

a）正規(guī)檢視

b）技術(shù)評(píng)審

c）走查

同行評(píng)審的對(duì)象能夠是計(jì)劃、需求文檔、設(shè)

計(jì)圖、代碼等

22.自動(dòng)化測試有什么意義？

答：

1.對(duì)程序新版本運(yùn)行前一版本執(zhí)行的測試，提高

回歸測試效率

2.能夠運(yùn)行更多更頻繁的測試，比如冒煙測試

3.能夠執(zhí)行手工測試?yán)щy或不可能做的測試，比

如大量的重復(fù)操作或者集成測試

4.更好地利用資源，比如測試儀器或者被測對(duì)象

5.測試具有一致性和可重復(fù)性，即自動(dòng)化測試的

步驟和結(jié)果是完全一樣的

6.測試的復(fù)用性，即自動(dòng)化測試腳本能夠拆分開

給其它測試腳本使用

7.能夠更快地將軟件推向市場，軟件發(fā)布前進(jìn)行

高效的回歸測試，減少軟件發(fā)布的時(shí)間

8.增加軟件信任度，通過自動(dòng)化測試提高了測試

效率，可把節(jié)約的時(shí)間拿出來做更多的測試

23.測試用例的八大要素是什么？

答：

1.測試用例編號(hào)

2.測試項(xiàng)目

3.測試標(biāo)題

4.重要級(jí)別

5.預(yù)置條件

6.輸入

7.操作步驟

8.預(yù)期輸出

24.什么是缺陷管理?引入的原因有哪些？

答：

是在軟件生命周期中獲取、管理、溝通

任何變更請求的過程。能夠確保你的問題如

需求或者缺陷被跟蹤管理而不丟失

引入原因：

1.開發(fā)過程中缺乏有效溝通，或者沒有溝通

2.軟件負(fù)責(zé)度越來越高

3.編程中產(chǎn)生的錯(cuò)誤

4.需求不斷變更

5.項(xiàng)目進(jìn)度的壓力

6.不重視開發(fā)文檔

7.軟件開發(fā)工具本身隱藏的問題

25.缺陷的屬性有哪些？

答：

1.缺陷發(fā)現(xiàn)人；

2.缺陷發(fā)現(xiàn)時(shí)間；

3.缺陷狀態(tài)；

4.缺陷嚴(yán)重程度；

5.缺陷所屬版本；

6.缺陷修改日期

26.畫缺陷管理流程圖？

答：

BUG管理流程圖

測試人員測試組長開發(fā)經(jīng)理開發(fā)人員

NEW

一

—?<Postpone:>

N

1

Open卜Postpone

_____1

?Abandon

Assign

ReopenaFi>、ed

▲

N

<

Y

▼

Closed

27.如何寫缺陷跟蹤單？

答：

缺陷跟蹤單遵循5W原則；

1.Correct（準(zhǔn)確）：每個(gè)組成部分的描述準(zhǔn)確，不

會(huì)引起誤解

2.Clear（清晰）：每個(gè)組成部分的描述清晰，易于

理解

3.Concise（簡潔）：只包含必不可少的信息，不包

括任何多余的內(nèi)容

4.Complete（完整）：包含復(fù)現(xiàn)該缺陷的完整步驟

和其它本質(zhì)信息

5.Consistent（一致）：按照一致的格式書寫全部

缺陷報(bào)告

28.什么是測試覆蓋率？

答：

覆蓋率是用來度量測試完整性的一個(gè)手段。

覆蓋率是測試技術(shù)有效性的一個(gè)度量。

覆蓋率二（至少被執(zhí)行一次的item數(shù)）/

item的總數(shù)

29.寫計(jì)算語句覆蓋率、判定覆蓋率、條件覆蓋

率、判定-條件覆蓋率、路徑覆蓋率、指令覆

蓋率等的表達(dá)式？

答：

語句覆蓋率二（至少被執(zhí)行一次的語句數(shù)量）/

（可執(zhí)行的語句總數(shù)）

判定覆蓋率二（判定結(jié)果被評(píng)價(jià)的次數(shù)）/

（判定結(jié)果的總數(shù)）

條件覆蓋率二（條件操作數(shù)值至少被評(píng)價(jià)一

次的數(shù)量）/（條件操作數(shù)值的總數(shù)）

分支條件覆蓋率二（條件操作數(shù)值或判定結(jié)

果至少被評(píng)價(jià)一次的數(shù)

量）/（條件操作數(shù)值總

數(shù)+判定結(jié)果總數(shù)）

路徑覆蓋率=（至少被執(zhí)行到一次的路徑數(shù)）

/（總的路徑數(shù)）

指令塊覆蓋二（至少被執(zhí)行一次的指令塊數(shù)

量）/（系統(tǒng)中指令塊總數(shù)）

30.什么是系統(tǒng)測試？

答：

系統(tǒng)測試（SystemTesting）是將已經(jīng)

集成好的軟件系統(tǒng)，作為整個(gè)基于計(jì)算機(jī)系

統(tǒng)的一個(gè)元素，與計(jì)算機(jī)硬件、外設(shè)、某些

支持軟件、數(shù)據(jù)和人員等其它系統(tǒng)元素結(jié)合

在一起，在實(shí)際運(yùn)行（使用）環(huán)境下，對(duì)計(jì)

算機(jī)系統(tǒng)進(jìn)行一系列的測試活動(dòng)

31.系統(tǒng)測試的目的是什么？

答：

1.通過與系統(tǒng)的需求定義做比較，發(fā)現(xiàn)軟件與系

統(tǒng)定義不符合或與之矛盾的地方；

2.系統(tǒng)測試的測試用例應(yīng)根據(jù)需求分析說明書

來設(shè)計(jì)，并在世界使用環(huán)境下運(yùn)行

32.系統(tǒng)測試的類型有哪些？

答：

功能測試；性能測試；壓力測試；容量

測試；安全性測試；GUI測試；可用性測試;

安裝測試；配置測試；異常測試（恢復(fù)性測

試）；備份測試；健壯性測試；文檔測試；

在線幫助測試；網(wǎng)絡(luò)測試；穩(wěn)定性測試

33.系統(tǒng)測試執(zhí)行的活動(dòng)有哪些？

答：

>系統(tǒng)測試預(yù)測試項(xiàng)執(zhí)行

>系統(tǒng)測試與測試報(bào)告寫作

>系統(tǒng)測試用例執(zhí)行

>系統(tǒng)測試缺陷記錄、修復(fù)

>系統(tǒng)測試日報(bào)寫作

>系統(tǒng)測試報(bào)告寫作

>系統(tǒng)測試缺陷的回歸測試

34.什么是單元測試？目的是什么？

答：

單元測試是對(duì)軟件基本組成單元進(jìn)行

的測試，如函數(shù)(function)或(procedure)

或一個(gè)類的方法(method)

單元測試的目的在于發(fā)現(xiàn)個(gè)模塊內(nèi)部

可能存在的各種錯(cuò)誤，主要是基于白盒測試

1.驗(yàn)證代碼是與設(shè)計(jì)相符合的

2.發(fā)現(xiàn)設(shè)計(jì)和需求中存在的錯(cuò)誤

3.發(fā)現(xiàn)在編碼過程中引入的錯(cuò)誤

35.單元測試的關(guān)注點(diǎn)？

答：

1.單元接口

2.局部數(shù)據(jù)結(jié)構(gòu)

3.邊界條件

4.獨(dú)立路徑

5.出錯(cuò)處理

36.什么是驅(qū)動(dòng)?什么是樁？

答：

驅(qū)動(dòng)單元(Driver):所測函數(shù)的主程

序，它接受測試數(shù)據(jù)，并把數(shù)據(jù)傳送給所測

試單元，最后在輸出實(shí)測結(jié)果，當(dāng)被測試單

元能完成相關(guān)的功能時(shí)，也能夠不要驅(qū)動(dòng)單

元

樁單元(Stub):用來代替所測試單元

調(diào)用的子單元

37.單元測試的測試策略是哪些?各有什么優(yōu)缺

點(diǎn)？

答：

＞孤立的測試策略：

優(yōu)點(diǎn):該方法是最簡單，最容易操作的，

能夠達(dá)到高的結(jié)構(gòu)覆蓋率，該方法是純粹

的單元測試

缺點(diǎn):樁函數(shù)和驅(qū)動(dòng)函數(shù)工作量很大，效

率低.

＞自頂向下的單元測試策略：

優(yōu)點(diǎn):能夠節(jié)省驅(qū)動(dòng)函數(shù)的開發(fā)工作量，

測試效率較高。

缺點(diǎn)：隨著被測單元一個(gè)一個(gè)被加入，測

試過程將變得越來越復(fù)雜，并且開發(fā)和維

護(hù)的成本將增加。

＞自底向上的單元測試策略：

優(yōu)點(diǎn)：能夠節(jié)省樁函數(shù)的開發(fā)工作量，測

試效率較高。

缺點(diǎn)；不是純粹的單元測試，底層函數(shù)的

測試質(zhì)量對(duì)上層函數(shù)的測試將產(chǎn)生很大

影響。

38.什么是集成測試？目的是什么？

答：

集成測試是在單元測試的基礎(chǔ)上，將所有函數(shù)按

照概要設(shè)計(jì)要求組裝成為子系統(tǒng)或系統(tǒng)所進(jìn)

行的測試

集成測試的目的是確保各組件組合在

一起后能夠按既定意圖寫作運(yùn)行，并確保增

量的行為正確。驗(yàn)證軟件的組建對(duì)HLD的符

合程度。集成測試屬于灰盒測試。

1.驗(yàn)證接口是否與設(shè)計(jì)相符合的

2.發(fā)現(xiàn)設(shè)計(jì)和需求中存在的錯(cuò)誤

39.集成測試的關(guān)注點(diǎn)是什么？

答：

單元間的接口：

＞在把各個(gè)模塊連接起來的時(shí)候，穿越模塊接口

的數(shù)據(jù)是否會(huì)丟失；

A全局?jǐn)?shù)據(jù)結(jié)構(gòu)是否有問題，會(huì)不會(huì)被一場修

改；

集成后的功能

＞各個(gè)子功能組合起來，能否達(dá)到預(yù)期要求得父

功能；

＞一個(gè)模塊的功能是否會(huì)對(duì)另一個(gè)模塊的功能

產(chǎn)生不利的影響；

＞單個(gè)模塊的誤差積累起來，是否會(huì)放大，從而

達(dá)到不可接受的程度

40.集成測試的測試策略是哪些?各有什么優(yōu)缺

點(diǎn)？

答：

＞大爆炸集成

優(yōu)點(diǎn)：

1.大爆炸集成能夠迅速完成集成測試，并且只要

極少數(shù)的驅(qū)動(dòng)和樁模塊設(shè)計(jì)，它需要的測試用

例也是最少的；

2.該方法比較簡單、易行；

3.多個(gè)測試人員能夠并行工作，對(duì)人力、物力資

源利用率較高

缺點(diǎn)：

1.這種一次性組裝方式試圖在輔助模塊的協(xié)助

下，在模塊單元測試的基礎(chǔ)上，將所測模塊連

接起來進(jìn)行測試，但是由于程序中不可避免地

存在模塊間接口，全局?jǐn)?shù)據(jù)結(jié)構(gòu)等方面的問

題，所以一次試運(yùn)行成功的可能性并不很大；

2.在發(fā)現(xiàn)錯(cuò)誤時(shí)，其問題定位和修改都較困難；

3.即使被測系統(tǒng)能夠一次性集成，但還是會(huì)有許

多接口錯(cuò)誤很容易躲過測試而進(jìn)入到系統(tǒng)測

試范圍內(nèi)

＞自頂向下集成

優(yōu)點(diǎn)：

1.自頂向下的集成方式在測試過程中較早地驗(yàn)

證了主要的控制和判斷點(diǎn)；

2.如果選擇按深度方向組裝的方式，能夠首先實(shí)

現(xiàn)和驗(yàn)證一個(gè)完整的軟件功能；

3.功能可行性較早得到證實(shí)，還能夠給開發(fā)者和

用戶帶來成功的信心；

4.最多只需一個(gè)驅(qū)動(dòng)，減少了驅(qū)動(dòng)器開發(fā)的費(fèi)

用；

5.支持故障隔離

缺陷：

1.樁的開發(fā)和維護(hù)是本策略的最大成本；

2.底層組件行為的驗(yàn)證被推遲了；

3.隨著底層組件的不斷增加，整個(gè)系統(tǒng)越來越復(fù)

雜，導(dǎo)致底層組件的測試不充分，特別是那些

被重用的組件

＞自底向上集成

優(yōu)點(diǎn)：

1.允許對(duì)底層組件行為的早期驗(yàn)證，能夠在任意

一個(gè)葉子節(jié)點(diǎn)已經(jīng)就緒的情況下進(jìn)行集成測

試；

2.在工作的最初可能會(huì)并行進(jìn)行集成，在這一點(diǎn)

上比使用自頂向下的策略效率高；

3.減少了樁的工作量，畢竟在集成測試中，樁的

工作量遠(yuǎn)比驅(qū)動(dòng)的工作量要大得多，但是為了

模擬一些中斷或異常，可能還是需要設(shè)計(jì)一定

的樁

缺點(diǎn)：

1.驅(qū)動(dòng)的開發(fā)工作量也是很龐大的；

2.對(duì)高層的驗(yàn)證被推遲到了最后，設(shè)計(jì)上的錯(cuò)誤

不能被及時(shí)發(fā)現(xiàn)，特別對(duì)那些控制結(jié)構(gòu)在整個(gè)

體系中非常關(guān)鍵

＞三明治集成