第1章軟件測試核心概念

一、測試員在測試過程中應(yīng)盡量追求完美。該描述正確嗎？

錯。不能窮盡測試，成本太高。

二、軟件測試的目的是發(fā)現(xiàn)缺陷。該描述正確嗎，

正確。軟件測試的目的就是為了發(fā)現(xiàn)軟件中的缺陷，從這個怠義上面說上面的這個論斷

是正確的。不少人會認為軟件測試可以保證軟件的質(zhì)量，其實這個觀點是錯誤，測試只是軟

件質(zhì)量控制中的一個角色，其活動并不能達成軟件質(zhì)量保證的效果。所以不要認為一個公司

里面如果有了軟件測試人員，產(chǎn)品的質(zhì)量就會好起來。

三、自動化測試的難點在于如何快速學會使用測試工具?該描述正確嗎？

該描述正確，因為國內(nèi)對使用測試工具技術(shù)方面還不成熟。

隨著國內(nèi)企業(yè)軟件開發(fā)及;則試水平的提升，許多企業(yè)開始嘗試開展自動化測試的應(yīng)用，以提

高測試效率和測試質(zhì)量。雖然在國外自動化測試工具應(yīng)月已經(jīng)很普遍，但國內(nèi)許多企業(yè)對于

軟件自動化測試的理解還停留在表面上，沒有深入的理解到企業(yè)實施自動化測試所要具備的

條件以及自動化測試本身的局限性，導(dǎo)致自動化并沒有給企業(yè)帶來多少實際的價值，反而還

浪費了資源。

四、為什么說軟件的需求規(guī)格說明書往往是軟件缺陷的最大來源?對軟件測試工

作有何啟發(fā)？

軟件缺陷；存在于軟件（文檔、數(shù)據(jù)、程序）之中的那些不希望或不可接受的偏差，

Bug是口語化的缺陷。缺陷在沒有被激活的狀態(tài)下，軟件可以正常運行，但是一旦在某一觸

發(fā)條件下，缺陷被激活，軟件內(nèi)部就會出現(xiàn)故障。

因為軟件缺陷產(chǎn)生的原因有很多，典型的原因如下：

軟件本身的復(fù)雜性，開發(fā)人員的問題，需求的變化，進度的壓力，對文檔不重視，溝通

不暢，偏差的累積。

各種來源導(dǎo)致缺陷會廣泛分布在軟件開發(fā)的各個階段，需求規(guī)格說明書、軟件設(shè)計、代

碼中都可以看到缺陷的身影。特別是由于需求的變化和人們對文檔的輕視，導(dǎo)致需求規(guī)格說

明書中的缺陷通常會占缺陷總數(shù)一半還多。

五、請仿照NextDate問題，針對PrevDate問題設(shè)計測試用例。PrevDate問題

的功能簡述如下：當用戶輸入有效日期時（從1800年1月1日到2050年12月

31日之間的所有日期:，系統(tǒng)將自動計算出前一天的日期。否則，系統(tǒng)不執(zhí)行日

期的計算，并給出消息提示輸入無效。

略

六、請根據(jù)測試用例的定義和管理的需要，設(shè)計一個測試用例報告的模板。

略

第2章軟件測試背景

七、軟件測試的目的是什么？

1、提高軟件的質(zhì)量

軟件測試的首要目的就是提高軟件的質(zhì)量，也就是讓用戶對產(chǎn)品有更好的體驗，保證軟

件的高質(zhì)量。

2、保證軟件的安全

軟件測試的第二大目的就是保證軟件的安全，有一些軟件是經(jīng)過數(shù)據(jù)加密的，比如各大

銀行系統(tǒng)的APP。涉及到資金的支出和存入，對軟件的安全性要求是特別高的。所以要通

過反復(fù)測試來提高產(chǎn)品的安全性，保證產(chǎn)品在上線之后不會出現(xiàn)bug,尤其對于金融方面的

APP來說，任何漏洞都是致命的。

3、降低軟件開發(fā)成本

軟件測試的另外一個目的就是降低軟件的開發(fā)成本，在開發(fā)過程中發(fā)現(xiàn)bug及時調(diào)整,

這樣的損失是很小的，一旦產(chǎn)品上線或是即將完成開發(fā)而發(fā)現(xiàn)bug,那么可能會造成產(chǎn)品大

改動，這樣就意味著以往的精力全部白費。因此測試的存在就是為了降低開發(fā)成本。比如迪

士尼的一款獅子王的軟件，借著獅子王的名聲，預(yù)期本應(yīng)是好評如潮，也能通過這款軟件獲

益不匪。但因為在很多系統(tǒng)上都無法使用，所以造成了大量的用戶投訴和下線、卸載等。對

成本造成「非常大的損失，那如果當時這款軟件能夠在不同的系統(tǒng)上進行測試，在上線前將

所有的問題全部解決掉，肯定會大大降低成本。

4、降低企業(yè)風險

除了降低開發(fā)成本，還可以降低企業(yè)風險，試想，如果軟件存在的問題過多，亳無疑問

會影響企業(yè)的信譽，最終直接導(dǎo)致企業(yè)的合作企業(yè)變少，直接損害公司的收益。但如果有測

試人員在中間嚴格把關(guān)，就完全不會出現(xiàn)這樣的問題。

5、提升用戶體驗感

開發(fā)人員在開發(fā)過程中都是以順向思維來寫程序代碼的，所以很少有開發(fā)人員能夠站在

用戶角度去思考，但測試人員不一樣，測試要以逆向思維來思考程序會在哪一步有問題，站

在用戶的角度進行測試，這樣上線的產(chǎn)品將很符合用戶的需求，用戶使用時也比較順手，增

加用戶體驗感。

八、為什么國內(nèi)軟件測試的發(fā)展相比歐美等發(fā)達國家存在較大的差距？

1.我國現(xiàn)代工業(yè)體系起步晚，工業(yè)軟件發(fā)展存在代差

（1）工業(yè)軟件較發(fā)達的國家，如美國、法國、德國等，都是完成了工業(yè)化進程的工業(yè)強

國，已經(jīng)經(jīng)歷了幾十年的發(fā)展，工業(yè)軟件配套體系比較完整。

（2）國內(nèi)起步落后于國外20-30年，與國外相比具有技術(shù)代差，單元應(yīng)用與系統(tǒng)應(yīng)用舉

步維艱，需要一定時間去耐心追趕。

<3）在引進國外先進設(shè)備與工藝的同時，大量國外軟件產(chǎn)品“乘虛而入”并形成依賴,

國產(chǎn)工業(yè)軟件市場占率極低，關(guān)鍵領(lǐng)域和環(huán)節(jié)技術(shù)產(chǎn)品嚴重受制于人。

2.工業(yè)軟件基礎(chǔ)與核心技術(shù)薄弱

(1)過去幾十年來，國內(nèi)CAD(計算機輔助設(shè)計)和CAE(計算機輔助仿真)等核心

工業(yè)基礎(chǔ)軟件，卻一直由西門子、達索、歐特克等歐美企業(yè)研發(fā)的軟件做主導(dǎo)，國產(chǎn)工業(yè)軟

件長期缺位。我國工業(yè)軟件自主基礎(chǔ)與核心技術(shù)薄弱，特別是三維幾何引擎(CAD內(nèi)核)、

CAE求解器等核心技術(shù)存在卡脖子風險。

(2)工業(yè)軟件是買不來的關(guān)鍵技術(shù)，對于國產(chǎn)工業(yè)軟件來說，“核心技術(shù)”不僅在于簡

單的開發(fā)和應(yīng)用，還在于后期的管理以及標準建設(shè)。

3.工業(yè)軟件產(chǎn)品產(chǎn)用脫節(jié)，形成惡性循環(huán)

我國航天、航空、船帕、電子、石油化工等重點制造領(lǐng)域產(chǎn)品創(chuàng)新設(shè)計、仿真模擬、工

藝流程控制等高端工業(yè)軟件幾乎都是清一色的國外工業(yè)軟件，不僅影響我國工業(yè)產(chǎn)品正向設(shè)

計能力，而且使得國外軟件不斷拉大與國內(nèi)軟件的差距，形成了應(yīng)用生態(tài)壁壘。

4.行業(yè)高端人才和復(fù)合型人才缺口較大

(1)行業(yè)高端專業(yè)人才緊缺，高端專業(yè)人才是指深入掌握專業(yè)知識的領(lǐng)軍人才。工業(yè)軟

件企業(yè)難以給予具有競爭力的薪酬待遇，造成工業(yè)軟件行業(yè)高端領(lǐng)軍的缺失。

(2)復(fù)合型人才缺失，工業(yè)軟件開發(fā)人員在掌握一定軟件開發(fā)能力的同時，還要掌握相

關(guān)工業(yè)領(lǐng)域?qū)I(yè)知識，更需要對復(fù)雜工業(yè)機理、產(chǎn)品對象、業(yè)務(wù)場景、操作流程等具有較為

深入的理解和認知，復(fù)合型人才培養(yǎng)難度大。

九、根據(jù)國內(nèi)軟件測試從業(yè)人員的現(xiàn)狀分析，你認為如何才能做一個合格的軟件

測試工程師呢？

1.專業(yè)技術(shù)能力

熟練掌握測試基礎(chǔ)知識，永遠是成為合格的軟件測試工程師的決定性條件。

2.團隊協(xié)作能力

(I)合理進行人員分工

合理的進行人員分工是提高工作效率的重要保證。

(2)協(xié)助組員解決問題

比如說測試在趕進度，或者這個軟件項目的質(zhì)量把控是一個團隊來把控的，協(xié)助組員解

決問題就顯得尤為關(guān)鍵。

(3)配合完成測試任務(wù)

一個團隊里邊的人員分工，他們的任務(wù)都是不一樣的，這就是咱們說的配合。你的東西

做完了，要輪到我了，我的性能測完了之后該輪到你了，所以整個的一個流程下來之后，大

家應(yīng)該是各司其職，配合得非常緊密的一個過程。

(4)配合開發(fā)重現(xiàn)缺陷

我給你提bug,你改我的bug,咱們的目的只有一個，就是讓這個軟件變得更好，所以

在這樣的情況下，咱們就一定要配合開發(fā)。

(5)督促項目整體進度

既然是一個團隊協(xié)作的過程，就一定要互相的去督促對方，包括督促開發(fā)人員去改bug,

因為開發(fā)人員他們有時候工作很忙，他們不知道要先改哪些問題，要后改哪些問題，但是往

往有一些缺陷，它影響了測試的這個時間，影響了測試的進度，那么這個時候就需要測試員

去督促開發(fā)人員，讓他盡快的去解決你棘手的問題。這個東西能夠提高咱們的測試效率。

(6)出現(xiàn)問題勇于承擔責任

愿意背鍋的最后都成為了領(lǐng)導(dǎo)，不愿意背鍋的最后依然是員工。

3.樂觀的心態(tài)和耐心的態(tài)度。

測試工程師每天面對的是程序中的“錯誤”，而程序員每天都在創(chuàng)造代碼。

第3章黑盒測試技術(shù)

十、在3.2節(jié)介紹的邊界值測試中，為何不區(qū)分邊界點的有效性，即不考慮邊界

點是否為系統(tǒng)可以接受的數(shù)據(jù)，且不考慮邊界點附近的測試數(shù)據(jù)是否為系統(tǒng)可以

接受的數(shù)據(jù)？

如果是閉區(qū)間，有效性包括邊界點，如果是開區(qū)間，邊界點包含在無效輸入里。人們從

長期的測試工作中總結(jié)出一個經(jīng)驗：大量缺陷發(fā)生在被測對象的輸入域或輸出域的邊界(即

極值)卜，而非輸入或輸某域的內(nèi)部°設(shè)計測試用例時,如果針對邊界附沂重點加以檢驗.

常常可取得良好的測試效果，取得較高的測試回報率。邊界值測試符合人們的一個基本假設(shè):

如果軟件在能力達到極限的時候能夠運行，那么其在正常情況下一般也不會有什么問題。

十一、請對3.2節(jié)的傭金問題，采用邊界值測試方法，從輸入域的角度設(shè)計測試

用例。

略

十二、針對無效等價類，為何不采用強組合方式設(shè)計測試用例，即測試到所有可

能的無效等價類組合情況？

等價類劃分法是黑盒；則試中非常重要的測試方法，采用等價類劃分法時，無需考慮程序

內(nèi)部結(jié)構(gòu)，設(shè)計測試用例是依據(jù)游戲策劃案進行設(shè)計的。

等價類是輸入條件的一個子數(shù)據(jù)集合，該輸入集合中的數(shù)據(jù)對于揭示程序中的錯誤是等

價的，從每一個子集中選取少數(shù)代表性的數(shù)據(jù)，從而進行梳理，組合成測試用例。

等價類劃分法分為：有效等價類、無效等價類。

有效等價類：有效等價類代表對程序的有效輸入數(shù)據(jù)

無效等價類：無效等價類則是以任何方式的無效輸入數(shù)據(jù)。

有效等價類和無效等價類都是使用等價類劃分法設(shè)計用例時所必須的，被測程序需要能

夠保證正確的數(shù)據(jù)輸入以及錯誤的輸入數(shù)據(jù)檢驗，這樣才能確保游戲具有更高的可靠性。

等價類劃分法的優(yōu)缺點

優(yōu)點：

使用等價類劃分法能對某一個數(shù)據(jù)子集進行詳細的劃分，順序性強，邏輯清晰，確保無

冗余。等價類劃分法能夠?qū)o窮的輸入數(shù)據(jù)限制在一個指定范圍，能夠使用少量數(shù)據(jù)發(fā)現(xiàn)更

多Bugo

缺點：

數(shù)據(jù)集成輸入間的內(nèi)容過少，數(shù)據(jù)與數(shù)據(jù)之間的牽連性會存在考慮不周全，還需要其他

用例設(shè)計方法來補充測試，例如邊界值分析法，等價類劃分法通常與邊界值分析法在數(shù)據(jù)輸

入的場景配合使用。

十三、請對3.3節(jié)的傭金問題，采用等價類測試方法，從輸入域的角度設(shè)計測試

用例。

略

十四、當在某個校驗點上可能得到的備選流數(shù)量很多時，將導(dǎo)致備選流數(shù)目的激

增，如何解決該問題？

1、首先，使用“分層聚類”分析。

2、其次，選擇聚類類別，SPSSAU默認聚為三類。

3、最后，結(jié)合樹狀圖進行分析，分層聚類出來，具體聚成幾個類別較好，需要結(jié)合樹

狀圖結(jié)果及實際數(shù)據(jù)情況進行分析對比。

第4章黑盒測試案例實踐

十五、下面是一個有關(guān)人壽保險的案例。描述如下：某保險公司的人壽保險的保

費計算方式為投保額X保險費率，其中保險費率依點數(shù)不同而有區(qū)別，10點及

10點以上保險費率為0.6%,10點以下保險費率為0.1%,且點數(shù)由投保人的年齡、

性別、婚姻狀況和撫養(yǎng)人數(shù)來共同決定，具體規(guī)則如下：

年齡性別婚姻撫養(yǎng)人數(shù)

20-3940?59其他女男已婚未婚

1人扣0.5點,最多扣3點（四舍五入取整）

6點4點2點5點3點3點5點

特別地，當人的年齡達到80歲或撫養(yǎng)人數(shù)達10人時，不接受投保。請針對該人

壽保險金的計算問題，利用本章所介紹的測試方法來設(shè)計測試用例，并關(guān)注這些

測試用例是否切實可行，是否符合常理。

略

十六、如何快速校驗劃分出的等價類能否體現(xiàn)真正的“等價”？

有兩種途徑：

第一種方式是正向判斷法。即從正向觀察系統(tǒng)是輸入和輸出，在劃分得到的等價類中隨

便選擇幾個數(shù)據(jù)，并從如下方面來觀察：

?這些數(shù)據(jù)是否包含相同的輸入條件。

?這些數(shù)據(jù)是否導(dǎo)致程序執(zhí)行類似的處理。

?這些數(shù)據(jù)是否影響相同的輸出結(jié)果。

?這曲數(shù)據(jù)要么都讓軟件執(zhí)行錯誤處理.，要么都不讓。

若以上方面中任何?方面不成立，則等價類劃分肯定有問題。

第二種方法是結(jié)合決策表方法,若從該等價類劃分無法得到精確無誤的決策表，則說明

該等價類劃分是不“等價”的。

十七、當時間有限時，應(yīng)優(yōu)先針對輸入域進行測試，還是針對輸出域進行測試?

為什么？

當時間有限時，應(yīng)優(yōu)先從輸入域考慮邊界值測試。因為系統(tǒng)總是根據(jù)輸入情況來決定如

何進行輸出響應(yīng)。且輸出域的邊界值測試用例與輸入域的測試用例有很多重復(fù)的情況。因此,

一般情況下，先對輸入域展開測試，然后根據(jù)輸出域的特殊性，補充更多邊界測試用例。

第5章白盒測試技術(shù)

十八、給定以下代碼，請以判定表達式為測試重點，選擇合適的覆蓋指標設(shè)計測

試用例。

boolTestLogicCoverage(boola,boolb,boolc)

{

1boolx=false;

2if((a||b)&&c)

3x=tu;

4clse

5x=false;

6re(urnx

判定入達式只。??.為Ta||b)&&c個科電條件?這里?我

達大分收2，分,05tfia||b稗"la||b)&&c

于這個表達由與這個表達式.啊州翻

5,—WK.?bM——T

表中可以曾出需試用例2和4nl以體］laM(“|b)的/響,用例3加4可

以體現(xiàn)bW(a||b)的彩響用例】與兌他比較不能&出aufbM(allb)的

影響刷試用例1世冗余的?修正5

冉6(a||b)&&c.MF6個表達式.由(a||b)'ic>響誼個表達式.從

。影峋題中的x.轎(a||b)。成一個整體均利的％祟如下：

友中可以11出篇忒用倒】和3，1r“標也叫b)時(a||b)&&c尚影響,用倒

裊中叫H*IE.?HFl?：3、體;"a||b)r，a||b)&&c的，口以依

1HJ2-111ftWc*t(?||b?&U?>.Mf-4JtF.t-KWfifL(a||b)

，"紂"||b4&c'F??.明*41工余的?"d.Hi

耨表1用及2lEi>d?

十九、當判定表達式具有3個簡單邏輯判斷條件時，所有可能構(gòu)成的表達式形式

如表5.36所示。請針對下表中的4種組合情況，分別采用修正的判定/條件覆蓋

指標設(shè)計測試用例。

希363個柳?廝轆蹄礴濟淀罰弒

ABCAAND(BANDC)AAND(B0RC)AOR(BANDC)AOR(BORC)

TTTTTTT

TTFFTTT

TFTFTTT

TFFFFTT

FTTFFTT

FTFFFFT

FFTFFFT

FFFFFFF

略

二十、請針對傭金問題代碼進行基路徑測試。

連通路徑i18/5+2=5

1測試川川uaMLB?nlKt；

Case18090100IABC2

X*o10101ABDEFG2

3*o20301ABDEHIG2

|CM<M2020301ABDEWKG2

CaseS7080901ABDEHJLM2

二十一、請用反證法證明獨立路徑之間是線性無關(guān)的。

線性無關(guān)是維性的史的"期間瓢..它被廣泛地應(yīng)用王睢優(yōu)蜘泛的分析中，有關(guān)線性無關(guān)的許多問題都可用反證法^解決.

例1設(shè)A是編拄間卜±69轆艘，如射C‘⑹叫回/⑷叫我工A&）,????A‘"）（Q°）蜴線關(guān).

證明假設(shè)臬A（《）?…，A’’6）線性相關(guān)，則存在不全為零的敵使得

儲+仇@+?一+九4'⑷=0.

假設(shè)〃是不等于零的系數(shù)中下標國JWA個，則有

M（G+&A%）+???+如A-⑷=0.

等式兩端同｛餃換Al,得

//”）+，，（＜）+…+*A”々舁=。，

曲/⑷=o,得"）=。,從而1=0,這Y

第6章白盒測試案例實踐

二十二、當時間有限時，是優(yōu)先進行黑盒測試，還是優(yōu)先進行白盒測試?為什么?

優(yōu)先黑盒，黑盒測試基本上類似于模擬用戶測試，尤其是可以測試漏洞，后門溢出，服務(wù)

器穩(wěn)定性等重要問題，最起碼基本功能能達到基本完善。

就測試來說，當源代碼較長時，可采用獨立測試的思想，將源代碼中較為獨立的結(jié)構(gòu)化

設(shè)計代碼段抽取出來，單獨設(shè)計測試用例，然后對整個代碼設(shè)計測試用例，這樣得到的測試

不容易出錯。

盡管人壽保險金問題也是一個函數(shù)層面的案例，然而，如果函數(shù)代碼設(shè)計不合理，會對

測試工作造成巨大的障礙，因此，白盒測試一般是要求程序員來完成的，主要目的是使得程

序員帶著測試的思想來編寫代碼，提高代碼的質(zhì)量,這樣才能更有效地確保軟件產(chǎn)品的質(zhì)量。

二十三、當對代碼進行測試時，若發(fā)現(xiàn)被測代碼結(jié)構(gòu)不合理，或過于復(fù)雜，測試

人員能否修改代碼結(jié)構(gòu)?為什么？

略

二十四、具備良好的測試習慣能夠幫助程序員提高代碼編寫的質(zhì)量嗎？

1.注重代碼質(zhì)量

良好的編程習慣之?是注重代碼質(zhì)量。編程人員應(yīng)該編寫易于理解、易于維護和易于擴

展的代碼。這樣做可以幫助他們快速定位和修復(fù)錯誤，并且更容易推出新的功能。此外，優(yōu)

秀的代碼質(zhì)量也可以提高產(chǎn)品質(zhì)量和用戶體驗O

2.堅持測試和調(diào)試

另一個良好的編程習慣是堅持測試和調(diào)試。編程人員應(yīng)該編寫測試用例，確保代碼能夠

正常運行，并盡早發(fā)現(xiàn)和解決錯誤。他們還應(yīng)該使用調(diào)試器和其他的工具來分析代碼并找到

錯誤的根源。這些實踐可以幫助他們提高代碼的質(zhì)量和穩(wěn)定性，并且減少錯誤的數(shù)量。

3.保持文檔更新

編程人員還應(yīng)該保持文檔的更新。編程代碼本身并不足以解釋軟件的所有細節(jié)和設(shè)計決

策。因此，他們應(yīng)該編寫卻維護文檔，記錄軟件的特性、設(shè)計技術(shù)和其他重要的信息，從而

方便團隊成員和其他人員了解產(chǎn)品和開發(fā)過程。這樣做匕以幫助編程人員更好地協(xié)作并促進

知識共享。

4.不斷學習和改進

最后一個重要的編程習慣是不斷學習和改進。編程技術(shù)一直在不斷發(fā)展和改進，因此編

程人員必須保持更新并學習新技術(shù)和更好的實踐。他們可以通過參加培訓、閱讀文獻、觀看

培訓視頻等方式來學習并掌握新技術(shù)。這樣做可以幫助他們更好地完成工作，并且為未來的

職業(yè)生涯做好準備。

良好的編程習慣對職場人士來說非常重要。它們可以提高代碼質(zhì)量和穩(wěn)定性、減少錯誤

的數(shù)量、促進知識共享、提高工作效率以及為未來的職業(yè)生涯做好準備。職場人士應(yīng)該注重

這些良好的編程習慣，并不斷改進和提高自己的技能和實踐。這樣做可以幫助他們更好地實

現(xiàn)自己的職業(yè)目標，并為公司的成功做出貢獻。

第7章單元測試

二十五、良好的單元測試是否能夠代替集成測試，

不能。單元測試和集成測試有很多共性，例如都是為了確保程序可以正確運行、減少錯

誤；同時，兩者都需要編寫相應(yīng)的測試用例、執(zhí)行測試、分析測試結(jié)果等。但是，兩者也有

一些區(qū)別。

首先，單元測試強調(diào)代碼功能的獨立性，感覺模塊與其他部分解耦后，才能使用自動化

測試框架進行測試。而集成測試強調(diào)不同模塊之間的互聯(lián)互動及完整性，因此需要將所有模

塊一起整合才進行測試。其次，單元測試關(guān)注程序內(nèi)部邏輯是否正確，而集成測試則驗證模

塊之間的交互是否正確。最后，單元測試和集成測試的測試成本和風險不同，前者成本較低，

缺陷更容易被修復(fù)，但不足以覆蓋整個系統(tǒng)；后者成本較高，缺陷修復(fù)困難，但可以保證系

統(tǒng)整體性和一致性。

單元測試和集成測試各有其優(yōu)點和限制，因此在軟件開發(fā)過程中，需要設(shè)計一個有效的

測試策略來平衡二者之間的關(guān)系。

下面是一些相關(guān)建議：1.避免過度依賴單元測試。雖然單元測試能夠檢測程序的小錯誤,

但它不足以覆蓋所有場景及交互，因此不能完全取代集成測試。2.明確測試目標和范圍。在

測試中，需要明確測試目標和測試用例并提出相應(yīng)的測試計劃，以幫助確保測試的準確性和

全面性。3.合理安排測試時間。測試是個重要的工作，但是不能占用軟件開發(fā)時間的大部分，

需要也需要權(quán)衡人力資源和時間投入等方面的問題。4.使用良好的集成測試工具。采用自動

化測試和持續(xù)集成可降低則試成本及風險。

二十六、什么是驅(qū)動模塊?什么是樁模塊?如何設(shè)計驅(qū)動模塊和樁模塊?

樁模塊:一個軟件組件框架的實現(xiàn)或特殊FI的的實現(xiàn)川于開發(fā)和測試另一個調(diào)試或依賴

于該組件的組件，它代替了被調(diào)用的組件。

驅(qū)動模塊:代替某個軟件組件來模擬控制和/或調(diào)用其他組件或系統(tǒng)的軟件或測試工具。

驅(qū)動模塊一般是應(yīng)用于自底向上的集成測試環(huán)境中

樁模塊一般是應(yīng)用于自頂向下的集成測試環(huán)境中

在自底向上的集成測試環(huán)境中：

?E、F、G、D是被測試模塊，此時需要模擬出兩個上級模塊來為這四個數(shù)據(jù)傳遞數(shù)據(jù)，那

么中間位置的兩個模塊就是驅(qū)動模塊，同理當測試中間兩個模塊的時候，最終的模塊也就是

驅(qū)動模塊（被多個同級模塊調(diào)用但是被虛擬假設(shè)出來的）

自哽向上臬或

在自頂向下的集成測試環(huán)境中:

是先從Ml開始測試的，然后逐層的向下進行分解測試，在測試上層模塊的過程中需要調(diào)用

下層的模塊完成輸入輸出就被稱為樁模塊（例如M2、M3、M4就稱為Ml的樁模塊）

M1■

M2M3S4

M5M6S7

M8

二十七、單元測試的過程是怎樣的？

通常單元測試在編碼階段進行。在源程序代碼編制完成，經(jīng)過評審和驗證，確認沒有語

法錯誤之后，就開始進行單元測試的測試用例設(shè)計。利用設(shè)計文檔，設(shè)計可以驗證程序功能、

找出程序錯誤的多個測試用例。對于每一組輸入，應(yīng)有預(yù)期的正確結(jié)果。

模塊并不是一個獨立的程序，在考慮測試模塊時，同時要考慮它和外界的聯(lián)系，用一些

輔助模塊去模擬與被測模塊相聯(lián)系的其它模塊。這些軸助模塊分為兩種：

驅(qū)動模塊：相當于被測模塊的主程序。它接收測試數(shù)據(jù)，把這些數(shù)據(jù)傳送給被測模塊，

最后輸出實測結(jié)果。

樁模塊：用以代替被測模塊調(diào)用的子模塊。樁模塊可以做少量的數(shù)據(jù)操作，不需要把子

模塊所有功能都帶進來，但不允許什么事情也不做。

被測模塊、與它相關(guān)的驅(qū)動模塊及樁模塊共同構(gòu)成了一個“測試環(huán)境”。

如果一個模塊要完成多種功能，且以程序包或?qū)ο箢惖男问匠霈F(xiàn)，例如Ada中的包，

Modula中的模塊，C++中的類。這時可以將這個模塊看成由幾個小程序組成。對其中的每

個小程序先進行單元測試要做的工作，對關(guān)鍵模塊還要做性能測試。對支持某些標準規(guī)程的

程序，更要著手進行互聯(lián)測試。有人把這種情況特別稱為模塊測試，以區(qū)別單元測試。

二十八、請針對第5章白盒測試中的傭金問題進行單元測試實踐。

略

第9章系統(tǒng)測試

二十九、系統(tǒng)測試完成后就可以發(fā)布軟件了嗎？

系統(tǒng)測試不能省略。一般地，對于開發(fā)人員來說，系統(tǒng)測試是產(chǎn)品交付給用戶前的最后

一個測試環(huán)節(jié)，占有重要的地位。當面臨緊迫的交付壓力時，單元測試和集成測試很可能被

取消，但系統(tǒng)測試只能被壓縮，不可能完全不做系統(tǒng)測試。

系統(tǒng)測試主:要是針對需求規(guī)格說明中所描述的系統(tǒng)功能和非功能需求進行測試,對應(yīng)的

測試活動包括功能測試、性能測試、安全性測試、兼容性測試等，下面分別展開討論。

三十、功能測試是功能性測試嗎？

功能測試（FunclionTesling）主要針對系統(tǒng)的功能需求展開測試，以確認被測系統(tǒng)是否滿

足用戶的功能使用要求。它是系統(tǒng)測試中最基本的測試。總體來說，在功能測試中，主要應(yīng)

結(jié)合黑盒測試的基本思想，從系統(tǒng)輸入（包括合法輸入和非法輸入）、系統(tǒng)內(nèi)部處理（包括數(shù)據(jù)

計算和存儲）、系統(tǒng)輸出（包括正常輸出、針對錯誤輸入的提示性輸出、各種輸出設(shè)備等）這三

個方面設(shè)計測試用例。由「不同的應(yīng)用系統(tǒng)具有不同的特點，功能測試的側(cè)重有所不同，在

此不妨將被測系統(tǒng)分為以數(shù)據(jù)為中心的系統(tǒng)（即各種管理信息系統(tǒng)）和以活動序列為中心的

系統(tǒng)（即大部分基于Web的應(yīng)用系統(tǒng)），分別討論測試的設(shè)計。

三十一、當時間緊迫時，可以不做性能測試嗎？

不能。性能測試（PerformanceTesting）就是對軟件的運行性能指標進行測試，判斷系統(tǒng)集

成之后在實際的使用環(huán)境下能否穩(wěn)定、可靠地運行。軟件性能主要考慮系統(tǒng)的時間和空間性

能。其中，時間主要指軟件的一個具體事務(wù)的響應(yīng)時間。不同公司和項目對不同事務(wù)可能具

有不同的響應(yīng)時間要求，例如，某項目中要求所有涉及新增、修改的操作響應(yīng)時間在3秒以

內(nèi)，而針對查詢的響應(yīng)時間僅要求在7秒以內(nèi)即可。空間性能主要指軟件運行時消耗的系統(tǒng)

資源，該指標主要影響系統(tǒng)的最低配置和推薦配置。典型的性能指標包括CPU的使用情況、

I/O的使用情況、主要存儲內(nèi)存的使用情況、每個模塊的執(zhí)行時間百分比、系統(tǒng)反應(yīng)時間、

系統(tǒng)吞吐量等。

三十二、用戶界面測試只不過是在界面上東看看西看看，沒有什么技術(shù)含量，是

這樣的嗎？

不是。用戶界面是軟件與用戶交互的最直接的層，界面質(zhì)量決定了用戶對軟件的第二印

象（安裝是第一印象）。隨著用戶對軟件的要求越來越高，用戶界面設(shè)計越來越重要，而隨著

用戶界面越來越復(fù)雜，用戶界面測試也變得異常困難。

第11章測試應(yīng)用案例實踐

三十三、自動化功能測試適合在什么階段使用？

1、測試需求分析階段。測試需求分析階段主要工作是獲得測試項目的測試需求（測試

規(guī)格）。輸出產(chǎn)物：《可測試性需求說明書》和《測試規(guī)格》。

2、測試計劃階段。以測試需求為基礎(chǔ)，分析產(chǎn)品的總體測試策略。輸出產(chǎn)物：《產(chǎn)品

總體測試策略》。

3、測試方案設(shè)計階段。本階段主要是以測試規(guī)格為基礎(chǔ)獲得特性測試方案，對于有自

動化測試的項目，進行自動化測試的分析，獲得測試策略。輸出產(chǎn)物：《產(chǎn)品或者版本總體

測試方案》。

4、測試用例實現(xiàn)階段。本階段主要是完成各個特性的測試用例的編寫和自動化腳本的

編寫。輸出產(chǎn)物：《產(chǎn)品自動化測試用例》和《手工執(zhí)行測試用例》。

5、測試執(zhí)行階段。本階段是根據(jù)測試策略開展測試執(zhí)行和回歸測試。輸出產(chǎn)品：《產(chǎn)

品或版本測試報告》和《缺陷分析報告》。

6、評估與關(guān)閉階段。只對前面的各個階段的執(zhí)行情況，完成對測試項目的關(guān)閉，同時

提供完整的度量數(shù)據(jù)和項目總結(jié)報告。

三十四、請從Web應(yīng)用測試的角度談?wù)勗诰W(wǎng)絡(luò)教學平臺的系統(tǒng)測試階段，還要從

哪些方面考慮測試，并說明可以使用的測試工具。

面向Web應(yīng)用系統(tǒng)的測試與傳統(tǒng)的軟件測試不同，不僅需要檢查和驗證是否按照需求

規(guī)格說明書的要求運行，而且還要測試Web應(yīng)用系統(tǒng)在不同瀏覽器上顯示是否符合要求，

與不同的數(shù)據(jù)庫連接是否有效、更重要的是在性能、安全性、可用性等方面功能測試、性能

測試、安全性測試、配置和兼容性測試、可用性測試、鏈接測試等。

使用Cookie技術(shù)，當用戶使用Web應(yīng)用系統(tǒng)時，能夠在訪問者的機器上創(chuàng)立一個叫做

Cookie的文件，把部分信息（訪問過的頁面、登錄用戶名、密碼等）寫進去，來標識用戶狀態(tài)。

如果該用戶下次再訪問這個Web應(yīng)用系統(tǒng)，就能夠讀出這個文件里面的內(nèi)容，正確標識用

戶信息如果Web應(yīng)用系統(tǒng)使用了Cookie,必須檢杳Cookie是否能正常工作，是否按預(yù)定的

時間進行保存內(nèi)容設(shè)計語言測試在Web應(yīng)用系統(tǒng)開發(fā)初始，根據(jù)軟件工程的要求用文檔的

形式確定Web應(yīng)用系統(tǒng)使用哪個版本的HTML標準，允許使用何種腳本語言及版本，允許

使用何種捽件,這樣可以有效的避免Web應(yīng)用系統(tǒng)開發(fā)過程中出現(xiàn)設(shè)計語言問題,

方法是實際破壞Web應(yīng)用系統(tǒng)，測試系統(tǒng)的反應(yīng)壓力測試是測試系統(tǒng)的限制和故障恢

復(fù)能力，也就是測試Web應(yīng)用系統(tǒng)會不會崩潰，在什么情況下會崩潰，崩潰以后會怎么樣。

在Web應(yīng)用系統(tǒng)性能測試過程中，常常將壓力測試和負載測試結(jié)合起來。在負載測試的基

礎(chǔ)上，增大負載最，直到系統(tǒng)崩潰實施性能測試需要注意測試工具靈活使用性能測試計劃的

制定由于數(shù)據(jù)庫安全性導(dǎo)致的Web應(yīng)用系統(tǒng)安全性問題Access數(shù)據(jù)庫文件被下載用戶重要

信息沒有經(jīng)過加密而存于數(shù)據(jù)庫中確認操作系統(tǒng)安全性，避免因操作系統(tǒng)漏洞導(dǎo)致Web應(yīng)

用程序的安全性問題Web應(yīng)用系統(tǒng)多采用登錄的方式，產(chǎn)品發(fā)布時提供默認的管理員用戶

名和密碼確保應(yīng)用系統(tǒng)實際應(yīng)用中可修改默認管理員帳號和密碼用戶名和密碼設(shè)置要求（長

度、大小寫敏感、復(fù)雜度）允許錯誤登錄的次數(shù)是否可以不登錄而直接瀏覽某個頁面保證口

志文件記錄了Web應(yīng)用系統(tǒng)的主要操作過程，并可根據(jù)日志文件追查到系統(tǒng)使用情況:同時

還需要保證日志文件本身的安全性、完整性，防止被入侵者刪除、獲得當Web應(yīng)用系統(tǒng)采

用/SSL等加密技術(shù)之后，需要確認加密、解密后信息傳遞的正確性和完整性需要確認Web

應(yīng)用系統(tǒng)是否有超時設(shè)置，如有，則保證在超時設(shè)置時間內(nèi)，如果未操作Web應(yīng)用系統(tǒng)，

當再次訪問系統(tǒng)，需要重新登錄了解安全漏洞信息，避免Web應(yīng)用系統(tǒng)中出現(xiàn)的漏洞被入

侵者利用;及時升級補丁程序，提高系統(tǒng)安全性Web應(yīng)用系統(tǒng)多采用分布式體系結(jié)構(gòu)，服務(wù)

器端通常包括Web服務(wù)器組件、數(shù)據(jù)庫服務(wù)器組件等。

三十五、請針對分布式搜索系統(tǒng)談?wù)勗撓到y(tǒng)還需從哪些方面展開性能測試。

觀察前端應(yīng)用的返回結(jié)果。這里需要分兩種情況來考慮：第一，按照前端應(yīng)用業(yè)務(wù)功

能點及流程進行操作，觀察返回結(jié)果是否符合業(yè)務(wù)方的需求預(yù)期；第二，操作后端的服務(wù)器

（通常是重啟、宕機、斷網(wǎng)等操作），觀察前端應(yīng)用的返I可結(jié)果是否符合系統(tǒng)的設(shè)計需求。

分析服務(wù)器日志。在功能測試過程中，當我們在啟動服務(wù)器的時候，需要將日志級別定

義為Debug級別（最低級別）。

分析操作系統(tǒng)的一些重要信息。我們測試的分布式系統(tǒng)絕大多數(shù)是基于Linux操作系統(tǒng)

開發(fā)的，在測試的過程中，除了詳細分析程序口志以外，還需要對操作系統(tǒng)的一些重要數(shù)據(jù)

信息進行分析，從而來診斷服務(wù)器程序是否存在異常。

借助其他分析工具。例如，如何判斷服務(wù)器程序是否產(chǎn)生了內(nèi)存泄漏？通常需要借助于

內(nèi)存檢測工具來進行分析，在Linux環(huán)境下，我們常用Valgrind來進行內(nèi)存檢測。

數(shù)據(jù)準備。如何準備海量的測試數(shù)據(jù)并保證模擬數(shù)據(jù)的真實性？以?個分布式的文件系

統(tǒng)為例，預(yù)先存入100GB的數(shù)據(jù)還是存入100TB的數(shù)據(jù)、存入的文件是大小基本一致差別

不大還是各不相同甚至差異很大（例如，從幾十字節(jié)至兒十兆字節(jié)不等），這些因素對于分

布式系統(tǒng)的性能影響是有很大差異的。

性能或壓力測試工具。通常來說，分布式系統(tǒng)的測試需要開發(fā)一些測試工具來滿足性能

測試的需求。如果可以的話，建議這樣的測試工具最好由測試工程師自己來實現(xiàn)，因為測試

工程師更清楚自己的測試需求。

涉及平臺多且硬件雜，測試流程控制困難。在實施自動化測試的過程中，測試腳本需

要控制的操作系統(tǒng)和應(yīng)用程序很多，而且存在跨平臺的特性，同時還有可能需要控制一些網(wǎng)

絡(luò)設(shè)備。

測試結(jié)果驗證復(fù)雜。對于分布式系統(tǒng)的自動化測試又說，我們需要通過測試腳本來收集

各種測試結(jié)果數(shù)據(jù)以驗證測試結(jié)果的正確性。在實施自動化測試的過程中，我們可以將測試

結(jié)果數(shù)據(jù)收集部分模塊化，通過各子模塊來檢測各項數(shù)據(jù)是否正確。

第8章集成測試

三十六、什么是集成測試？

集成測試，也叫組裝測試或聯(lián)合測試。在單元測試的基礎(chǔ)上，將所有模塊按照設(shè)計要求

（如根據(jù)結(jié)構(gòu)圖）組裝成為子系統(tǒng)或系統(tǒng)，進行集成測試。

實踐表明，i些模塊雖然能夠單獨地工作，但并不能保證連接起來也能正常的工作。--

些局部反映不出來的問題，在全局上很可能暴露出來。

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

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

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

更大部分。方法是測試片段的組合，并最終擴展成進程，將模塊與其他組的模塊一起測試。

最后，將構(gòu)成進程的所有模塊?起測試。此外，如果程序由多個進程組成，應(yīng)該成對測試它

們，而不是同時測試所有進程。

集成測試是單元測試的邏輯擴展。在現(xiàn)實方案中，集成是指多個單元的聚合，許多單元

組合成模塊，而這些模塊又聚合成程序的更大部分，如分系統(tǒng)或系統(tǒng)。集成測試采用的方法

是測試軟件單元的組合能否正常工作，以及與其他組的模塊能否集成起來工作。最后，還要

測試構(gòu)成系統(tǒng)的所有模塊組合能否正常工作。集成測試所持的主要標準是《軟件概要設(shè)計規(guī)

格說明》，任何不符合該說明的程序模塊行為都應(yīng)該加以記載并上報。

三十七、集成測試與單元測試有何區(qū)別？

?測試對象不同。單元測試對象是實現(xiàn)了具體功能的程序單元:集成測試對象是概要設(shè)

計規(guī)劃中的模塊及模塊間的組合。

?測試方法不同。單元測試中的主要方法是基丁?代碼的白盒測試:集成測試中主要使用

基于功能的黑盒測試。

?測試時間不同。集成測試晚于單元測試。

?測試內(nèi)容不同。單元測試主要是模塊內(nèi)程序的邏粗、功能、參數(shù)傳遞、變量引用、出

錯處理及需求和設(shè)計中具體耍求方面的測試:集成測試主耍驗證各個接口、接口之間的數(shù)據(jù)

傳遞關(guān)系，及模塊組合后能否達到預(yù)期效果。

三十八、如何評價某種集成測試方法？

1）集成測試就是在單元測試的基礎(chǔ)上，將所有已通過單元測試的模塊按照概要設(shè)計的要

求組裝為子系統(tǒng)或系統(tǒng)，并進行測試的過程，目的是確保各單元模塊組合在一起后能夠按既定

意圖協(xié)作運行，并確保增量的行為正確。

2）從四個方面對集成測試策略進行評價：

測試用例的規(guī)模

驅(qū)動模塊的設(shè)計

樁模塊的設(shè)計

缺陷的定位

三十九、成對集成與鄰居集成的基本思想是怎樣的?有何特點？

成對集成的基本思想是將每個集成測試用例限定在一對調(diào)用單元上，每個集成測試用例

都是最小的集成單元，僅涉及一對調(diào)用的接口。這樣做最大的好處就是使得缺陷非常容易定

位，一旦某個集成測試用例失敗，可以肯定地說，一定是該用例涉及的這一對模塊的接口有

問題。

鄰居集成的基本思想是將每個集成測試用例限定在某個節(jié)點的鄰居上，針對某個模塊的

集成測試用例應(yīng)同時包含該模塊及其鄰居。所謂鄰居，是對應(yīng)某個模塊的一個特定鄰域模塊

集合，它包括指定的某個模塊、所有直接調(diào)用該模塊的上層模塊以及所有被該模塊直接調(diào)用

的下層模塊。

鄰居的構(gòu)成有兩種方式：

(I)處于中間層的模塊。每個處于調(diào)用圖中間層的模塊既有上層調(diào)用模塊，又有下層被

調(diào)用模塊，自然形成一組鄰居，構(gòu)成一個集成測試用例。

(2)根節(jié)點直接調(diào)用葉子節(jié)點。當根節(jié)點模塊直接調(diào)用葉子節(jié)點模塊時，根模塊與所有

被它直接調(diào)用的葉子模塊共同形成一組鄰居，構(gòu)成一個集成測試用例。

四十、請比較大爆炸集成、自頂向下、自底向上和三明治集成策略。

大爆炸集成(BigBangj是將所有經(jīng)過單元測試的模塊一次性組裝到被測系統(tǒng)中進行測試,

完全不考慮模塊之間的依賴性和可能的風險。

大爆炸集成就是將所有7個模塊放在一起進行測試，即僅需一個測試用例，達到用例規(guī)

模的最小化。同時，由于該測試一次性包含了所有模塊，無須開發(fā)樁和驅(qū)動模塊。顯而易見

的弊端是直接導(dǎo)致缺陷定位異常困難。一旦用例失敗，完全不知道是哪對模塊的調(diào)用接口出

了問題。特別地，即使被測系統(tǒng)能夠一次性集成成功，也會有許多接口缺陷逃過測試而進入

系統(tǒng)測試，給系統(tǒng)測試帶來不良影響，大大增加系統(tǒng)測試的負擔。

大爆炸集成違反了測試從小范圍到大范圍展開的基本原則，一般情況下不采用這種集成

方式，僅在涉及模塊和接口數(shù)最不多的情況下使用