前言

本文章主要為備戰(zhàn)金三銀四的同仁準(zhǔn)備纬傲，幫助您更好的應(yīng)對面試官提問的同時并加強鞏固前面所學(xué)知識，其中包括以下幾類內(nèi)容：測試技術(shù)類面試題（理論面試題（必背+拓展+測試用例）肤频、數(shù)據(jù)庫面試題叹括、自動化及工具面試題和其他技術(shù)面試題）！

以上只截取其中一部分哦Ｏ摹Ｖ住！

1.什么是兼容性測試报咳？兼容性測試側(cè)重哪些方面侠讯？

參考答案：

兼容測試主要是檢查軟件在不同的硬件平臺、軟件平臺上是否可以正常的運行少孝，即是通常說的軟件的可移植性继低。

兼容的類型，如果細(xì)分的話稍走，有平臺的兼容袁翁，網(wǎng)絡(luò)兼容，數(shù)據(jù)庫兼容婿脸，以及數(shù)據(jù)格式的兼容粱胜。

兼容測試的重點是，對兼容環(huán)境的分析狐树。通常焙压，是在運行軟件的環(huán)境不是很確定的情況下，才需要做兼容抑钟。根據(jù)軟件運行的需要涯曲，或者根據(jù)需求文檔，一般都能夠得出用戶會在什么環(huán)境下使用該軟件在塔，把這些環(huán)境整理成表單幻件，就得出做兼容測試的兼容環(huán)境了。

兼容和配置測試的區(qū)別在于蛔溃，做配置測試通常不是Clean OS下做測試绰沥，而兼容測試多是在Clean OS的環(huán)境下做的篱蝇。

2.測試的策略有哪些？

參考答案：

黑盒/白盒徽曲，靜態(tài)/動態(tài)零截，手工/自動，冒煙測試秃臣，回歸測試涧衙，公測（Beta測試的策略）

3.描述測試用例設(shè)計的完整過程？

參考答案：

需求分析 + 需求變更的維護(hù)工作甜刻；

根據(jù)需求得出測試需求绍撞；

設(shè)計測試方案，評審測試方案得院；

方案評審?fù)ㄟ^后傻铣，設(shè)計測試用例，再對測試用例進(jìn)行評審祥绞；

4.單元測試的策略有哪些非洲？

參考答案：

邏輯覆蓋、循環(huán)覆蓋蜕径、同行評審两踏、桌前檢查、代碼走查兜喻、代碼評審梦染、景泰數(shù)據(jù)流分析。

5.你所熟悉的軟件測試類型都有哪些朴皆？請試著分別比較這些不同的測試類型的區(qū)別與聯(lián)系（如功能測試帕识、性能測試……）？

參考答案：

Compatibility Testing（兼容性測試）遂铡，也稱“Configuration testing（配置測試）”肮疗，測試軟件是否和系統(tǒng)的其它與之交互的元素之間兼容，如：瀏覽器扒接、操作系統(tǒng)伪货、硬件等。驗證測試對象在不同的軟件和硬件配置中的運行情況钾怔。

Functional testing (功能測試)碱呼，也稱為behavioral testing（行為測試），根據(jù)產(chǎn)品特征宗侦、操作描述和用戶方案巍举，測試一個產(chǎn)品的特性和可操作行為以確定它們滿足設(shè)計需求。本地化軟件的功能測試凝垛，用于驗證應(yīng)用程序或網(wǎng)站對目標(biāo)用戶能正確工作懊悯。使用適當(dāng)?shù)钠脚_、瀏覽器和測試腳本梦皮，以保證目標(biāo)用戶的體驗將足夠好炭分，就像應(yīng)用程序是專門為該市場開發(fā)的一樣。

Performance testing（性能測試）剑肯，評價一個產(chǎn)品或組件與性能需求是否符合的測試捧毛。包括負(fù)載測試、強度測試让网、數(shù)據(jù)庫容量測試呀忧、基準(zhǔn)測試等類型。

6.Beta測試與Alpha測試有什么區(qū)別溃睹？

參考答案：

Beta testing(β測試),測試是軟件的多個用戶在一個或多個用戶的實際使用環(huán)境下進(jìn)行的測試而账。開發(fā)者通常不在測試現(xiàn)場。

Alpha testing (α測試),是由一個用戶在開發(fā)環(huán)境下進(jìn)行的測試因篇，也可以是公司內(nèi)部的用戶在模擬實際操作環(huán)境下進(jìn)行的受控測試泞辐。

7.軟件的評審一般由哪些人參加？其目的是什么竞滓？

參考答案：

在正式的會議上將軟件項目的成果（包括各階段的文檔咐吼、產(chǎn)生的代碼等）提交給用戶、客戶或有關(guān)部門人員對軟件產(chǎn)品進(jìn)行評審和批準(zhǔn)商佑。其目的是找出可能影響軟件產(chǎn)品質(zhì)量锯茄、開發(fā)過程、維護(hù)工作的適用性和環(huán)境方面的設(shè)計缺陷茶没，并采取補救措施肌幽，以及找出在性能、安全性和經(jīng)濟(jì)方面的可能的改進(jìn)礁叔。

人員：用戶牍颈、客戶或有關(guān)部門開發(fā)人員，測試人員琅关，需求分析師都可以煮岁，就看處于評審那個階段。

8.測試活動中涣易，如果發(fā)現(xiàn)需求文檔不完善或者不準(zhǔn)確画机，怎么處理？

參考答案：

測試需求分析 發(fā)現(xiàn)需求文檔不完善或者不準(zhǔn)確新症，應(yīng)該立即和相關(guān)人員進(jìn)行協(xié)調(diào)交流步氏。

9.階段評審與項目評審有什么區(qū)別？

參考答案：

階段評審 對項目各階段評審：對階段成果和工作徒爹；

項目評審 對項目總體評審：對工作和產(chǎn)品荚醒。

10.什么是樁模塊芋类？什么是驅(qū)動模塊？

參考答案：

樁模塊：被測模塊調(diào)用模塊

驅(qū)動模塊：調(diào)用被測模塊

11.你認(rèn)為做好測試用例工作的關(guān)鍵是什么界阁？

參考答案：

需求和設(shè)計文檔的理解程度侯繁，對系統(tǒng)的熟悉程度。

12.簡述一下缺陷的生命周期泡躯？

參考答案：

提交->確認(rèn)->分配->修復(fù)->驗證->關(guān)閉贮竟。

13.你覺得軟件測試通過的標(biāo)準(zhǔn)應(yīng)該是什么樣的？

參考答案：

缺陷密度值達(dá)到客戶的要求较剃。

14.一套完整的測試應(yīng)該由哪些階段組成咕别？

參考答案：

測試計劃、測試設(shè)計與開發(fā)写穴、測試實施惰拱、測試評審與測試結(jié)論

15.單元測試的主要內(nèi)容？

參考答案：

　 模塊接口測試确垫、局部數(shù)據(jù)結(jié)構(gòu)測試弓颈、路徑測試、錯誤處理測試删掀、邊界測試

16.集成測試也叫組裝測試或者聯(lián)合測試翔冀，請簡述集成測試的主要內(nèi)容？

參考答案：

（1）在把各個模塊連接起來的時候披泪，穿越模塊接口的數(shù)據(jù)是否會丟失纤子；

（2）一個模塊的功能是否會對另一個模塊的功能產(chǎn)生不利的影響；

（3）各個子功能組合起來款票，能否達(dá)到預(yù)期要求的父功能控硼；

（4）全局?jǐn)?shù)據(jù)結(jié)構(gòu)是否有問題；

　 （5）單個模塊的誤差累積起來艾少，是否會放大卡乾，從而達(dá)到不能接受的程度。

17.簡述集成測試與系統(tǒng)測試關(guān)系缚够？

參考答案：

（1）集成測試的主要依據(jù)概要設(shè)計說明書幔妨，系統(tǒng)測試的主要依據(jù)是需求設(shè)計說明書；

　 （2）集成測試是系統(tǒng)模塊的測試谍椅，系統(tǒng)測試是對整個系統(tǒng)的測試误堡，包括相關(guān)的軟硬件平臺、網(wǎng)絡(luò)以及相關(guān)外設(shè)的測試雏吭。

18.軟件測試的文檔測試應(yīng)當(dāng)貫穿于軟件生命周期的全過程锁施，其中用戶文檔是文檔測試的重點。那么軟件系統(tǒng)的用戶文檔包括哪些？

參考答案：

用戶手冊

安裝和設(shè)置指導(dǎo)

聯(lián)機(jī)幫助

指南悉抵、向?qū)?/p>

樣例肩狂、示例和模板

授權(quán)/注冊登記表

最終用戶許可協(xié)議

19.軟件系統(tǒng)中除用戶文檔之外，文檔測試還應(yīng)該關(guān)注哪些文檔基跑？

參考答案：

開發(fā)文檔

軟件需求說明書

　　　　數(shù)據(jù)庫設(shè)計說明書

　　　　概要設(shè)計說明書

　　　　詳細(xì)設(shè)計說明書

　　　　可行性研究報告

管理文檔

　　　　項目開發(fā)計劃

　　　　測試計劃

　　　　測試報告

　　　　開發(fā)進(jìn)度月報

　　　 開發(fā)總結(jié)報告

20.簡述軟件系統(tǒng)中用戶文檔的測試要點婚温？

參考答案：

（1）讀者群。文檔面向的讀者定位要明確媳否。對于初級用戶、中級用戶以及高級用戶應(yīng)該有不同的定位

（2）術(shù)語荆秦。文檔中用到的術(shù)語要適用與定位的讀者群篱竭，用法一致，標(biāo)準(zhǔn)定義與業(yè)界規(guī)范相吻合步绸。

（3）正確性掺逼。測試中需檢查所有信息是否真實正確，查找由于過期產(chǎn)品說明書和銷售人員夸大事實而導(dǎo)致的錯誤瓤介。檢查所有的目錄吕喘、索引和章節(jié)引用是否已更新，嘗試鏈接是否準(zhǔn)確刑桑，產(chǎn)品支持電話祖很、地址和郵政編碼是否正確捏肢。

（4）完整性。對照軟件界面檢查是否有重要的分支沒有描述到，甚至是否有整個大模塊沒有描述到哥桥。

（5）一致性。按照文檔描述的操作執(zhí)行后站粟，檢查軟件返回的結(jié)果是否與文檔描述的相同浦妄。

（6）易用性。對關(guān)鍵步驟以粗體或背景色給用戶以提示吴超，合理的頁面布局钉嘹、適量的圖表都可以給用戶更高的易用性。需要注意的是文檔要有助于用戶排除錯誤鲸阻。不但描述正確操作跋涣，也要描述錯誤處理辦法。文檔對于用戶看到的錯誤信息應(yīng)當(dāng)有更詳細(xì)的文檔解釋赘娄。

（7）圖表與界面截圖仆潮。檢查所有圖表與界面截圖是否與發(fā)行版本相同。

（8）樣例與示例遣臼。像用戶一樣載入和使用樣例性置。如果是一段程序，就輸入數(shù)據(jù)并執(zhí)行它揍堰。以每一個模塊制作文件鹏浅，確認(rèn)它們的正確性嗅义。

（9）語言。不出現(xiàn)錯別字隐砸，不要出現(xiàn)有二義性的說法之碗。特別要注意的是屏幕截圖或繪制圖形中的文字。

　 （10）印刷與包裝季希。檢查印刷質(zhì)量褪那；手冊厚度與開本是否合適；包裝盒的大小是否合適式塌；有沒有零碎易丟失的小部件等等博敬。

21.如何理解壓力、負(fù)載峰尝、性能測試測試偏窝？

參考答案：

性能測試是一個較大的范圍，實際上性能測試本身包含了性能武学、強度祭往、壓力、負(fù)載等多方面的測試內(nèi)容火窒。

壓力測試是對服務(wù)器的穩(wěn)定性以及負(fù)載能力等方面的測試硼补，是一種很平常的測試。增大訪問系統(tǒng)的用戶數(shù)量沛鸵、或者幾個用戶進(jìn)行大數(shù)據(jù)量操作都是壓力測試括勺。而負(fù)載測試是壓力相對較大的測試，主要是測試系統(tǒng)在一種或者集中極限條件下的相應(yīng)能力曲掰，是性能測試的重要部分疾捍。100個用戶對系統(tǒng)進(jìn)行連續(xù)半個小時的訪問可以看作壓力測試，那么連續(xù)訪問8個小時就可以認(rèn)為負(fù)載測試栏妖，1000個用戶連續(xù)訪問系統(tǒng)1個小時也可以看作是負(fù)載測試乱豆。

實際上壓力測試和負(fù)載測試沒有明顯的區(qū)分。測試人員應(yīng)該站在關(guān)注整體性能的高度上來對系統(tǒng)進(jìn)行測試吊趾。

22.軟件文檔測試主要包含什么宛裕？

參考答案：

隨著軟件文檔系統(tǒng)日益龐大，文檔測試已經(jīng)成為軟件測試的重要內(nèi)容论泛。文檔測試對象主要如下：

-包裝文字和圖形揩尸；

-市場宣傳材料、廣告以及其它插頁屁奏；

-授權(quán)岩榆、注冊登記表；

-最終用戶許可協(xié)議；

-安裝和設(shè)置向?qū)В?/p>

-用戶手冊勇边；

-聯(lián)機(jī)幫助犹撒；

-樣例、示范例子和模板粒褒；

-……

文檔測試的目的是提高易用性和可靠性识颊，降低支持費用，因為用戶通過文檔就可以自己解決問題奕坟。因文檔測試的檢查內(nèi)容主要如下：

-讀者對象——主要是文檔的內(nèi)容是否能讓該級別的讀者理解祥款；

-術(shù)語——主要是檢查術(shù)語是否適合讀者；

-內(nèi)容和主題——檢查主題是否合適执赡、是否丟失镰踏、格式是否規(guī)范等；

-圖標(biāo)和屏幕抓圖——檢查圖表的準(zhǔn)確度和精確度沙合；

-樣例和示例——是否與軟件功能一致；

-拼寫和語法跌帐；

-文檔的關(guān)聯(lián)性——是否與其它相關(guān)文檔的內(nèi)容一致首懈，例如與廣告信息是否一致；

文檔測試是相當(dāng)重要的一項測試工作谨敛，不但要給予充分的重視究履，更要要認(rèn)真的完成，象做功能測試一樣來對待文檔測試脸狸。

23.沒有產(chǎn)品說明書和需求文檔地情況下能夠進(jìn)行黑盒測試嗎最仑？

參考答案：

這個問題是國內(nèi)測試工程師經(jīng)常遇到的問題，根源就是國內(nèi)軟件開發(fā)文檔管理不規(guī)范炊甲，對變更的管理方法就更不合理了泥彤。實際上沒有任何文檔的時候，測試人員是能夠進(jìn)行黑盒測試的卿啡，這種測試方式我們可以稱之為探索測試吟吝，具體做法就是測試工程師根據(jù)自己的專業(yè)技能、領(lǐng)域知識等不斷的深入了解測試對象颈娜、理解軟件功能剑逃，進(jìn)而發(fā)現(xiàn)缺陷。

在這種做法基本上把軟件當(dāng)成了產(chǎn)品說明書官辽，測試過程中要和開發(fā)人員不斷的進(jìn)行交流蛹磺。尤其在作項目的時候，進(jìn)度壓力比較大同仆，可以作為加急測試方案萤捆。最大的風(fēng)險是不知道有些特性是否被遺漏。

軟件測試的風(fēng)險主要體現(xiàn)在哪里？

參考答案：

我們沒有對軟件進(jìn)行完全測試鳖轰，實際就是選擇了風(fēng)險清酥，因為缺陷極有可能存在沒有進(jìn)行測試的部分。舉個例子蕴侣，程序員為了方便焰轻，在調(diào)試程序時會彈出一些提示信息框，而這些提示只在某種條件下會彈出昆雀，碰巧程序發(fā)布前這些代碼中的一些沒有被注釋掉辱志。在測試時測試工程師又沒有對其進(jìn)行測試。如果客戶碰到它狞膘，這將是代價昂貴的缺陷揩懒，因為交付后才被客戶發(fā)現(xiàn)。

因此挽封，我們要盡可能的選擇最合適的測試量已球，把風(fēng)險降低到最小。

25.發(fā)現(xiàn)的缺陷越多辅愿，說明軟件缺陷越多嗎智亮？

參考答案：

這是一個比較常見的現(xiàn)象。測試工程師在沒有找到缺陷前會絞盡腦汁的思考点待，但是找到一個后阔蛉，會接二連三的發(fā)現(xiàn)很多缺陷，頗有個人成就感癞埠。其中的原因主要如下：

-代碼復(fù)用状原、拷貝代碼導(dǎo)致程序員容易犯相同的錯誤。類的繼承導(dǎo)致所有的子類會包含基類的錯誤苗踪，反復(fù)拷貝同一代碼意味可能也復(fù)制了缺陷颠区。

-程序員比較勞累是可以導(dǎo)致某些連續(xù)編寫的功能缺陷較多。程序員加班是一種司空見慣的現(xiàn)象徒探，因此體力不只時容易編寫一些缺陷較多的程序瓦呼。而這些連續(xù)潛伏缺陷恰恰時測試工程師大顯身手的地方。

“缺陷一個連著一個”不是一個客觀規(guī)律测暗，只是一個常見的現(xiàn)象央串。如果軟件編寫的比較好，這種現(xiàn)象就不常見了碗啄。測試人員只要嚴(yán)肅認(rèn)真的測試程序就可以了质和。

26.所有的軟件缺陷都能修復(fù)嗎？所有的軟件缺陷都要修復(fù)嗎稚字？

參考答案：

從技術(shù)上講饲宿，所有的軟件缺陷都是能夠修復(fù)的厦酬，但是沒有必要修復(fù)所有的軟件缺陷。測試人員要做的是能夠正確判斷什么時候不能追求軟件的完美瘫想。對于整個項目團(tuán)隊仗阅，要做的是對每一個軟件缺陷進(jìn)行取舍，根據(jù)風(fēng)險決定那些缺陷要修復(fù)国夜。發(fā)生這種現(xiàn)象的主要原因如下：

-沒有足夠的時間資源减噪。在任何一個項目中，通常情況下開發(fā)人員和測試人員都是不夠用的车吹，而且在項目中沒有預(yù)算足夠的回歸測試時間筹裕，再加上修改缺陷可能引入新的缺陷，因此在交付期限的強大壓力下窄驹，必須放棄某些缺陷的修改朝卒。

-有些缺陷只是特殊情況下出現(xiàn)，這種缺陷處于商業(yè)利益考慮乐埠，可以在以后升級中進(jìn)行修復(fù)抗斤。

-不是缺陷的缺陷。我們經(jīng)常會碰到某些功能方面的問題被當(dāng)成缺陷來處理丈咐，這類問題可以以后有時間時考慮再處理豪治。

最后要說的是，缺陷是否修改要由軟件測試人員扯罐、項目經(jīng)理、程序員共同討論來決定是否修復(fù)烦衣，不同角色的人員從不同的角度來思考歹河，以做出正確的決定。

27.軟件測試人員就是QA嗎花吟？

參考答案：

軟件測試人員的職責(zé)是盡可能早的找出軟件缺陷秸歧，確保得以修復(fù)。而質(zhì)量保證人員（QA）主要職責(zé)是創(chuàng)建或者制定標(biāo)準(zhǔn)和方法衅澈，提高促進(jìn)軟件開發(fā)能力和減少軟件缺陷键菱。測試人員的主要工作是測試，質(zhì)量保證人員日常工作重要內(nèi)容是檢查與評審今布，測試工作也是測試保證人員的工作對象经备。

軟件測試和質(zhì)量是相輔相成的關(guān)系，都是為了提高軟件質(zhì)量而工作部默。

28.什么是軟件測試侵蒙，軟件測試的目的？

參考答案：

定義：使用人工或自動手段來運行或測定某個系統(tǒng)的過程傅蹂，其目的在于檢驗它是否滿足規(guī)定的需求或是弄清預(yù)期結(jié)果與實際結(jié)果之間的差別

目的：確保產(chǎn)品完成了它所承諾或公布的功能纷闺，并且用戶可以訪問到的功能都有明確的書面說明算凿；確保產(chǎn)品滿足性能和效率的要求；確保產(chǎn)品是健壯的和適應(yīng)用戶環(huán)境的 犁功；確保最終交給用戶的產(chǎn)品功能符合用戶的需求氓轰，在產(chǎn)品交給用戶之前盡可能多的發(fā)現(xiàn)并改正問題。

29.簡述負(fù)載測試與壓力測試的區(qū)別浸卦？

參考答案：

壓力測試（Stress Testing）

壓力測試的主要任務(wù)就是獲取系統(tǒng)正確運行的極限署鸡，檢查系統(tǒng)在瞬間峰值負(fù)荷下正確執(zhí)行的能力。例如镐躲，對服務(wù)器做壓力測試時就可以增加并發(fā)操作的用戶數(shù)量储玫；或者不停地向服務(wù)器發(fā)送請求；或一次性向服務(wù)器發(fā)送特別大的數(shù)據(jù)等萤皂∪銮睿看看服務(wù)器保持正常運行所能達(dá)到的最大狀態(tài)。人們通常使用測試工具來完成壓力測試裆熙，如模擬上萬個用戶從終端同時登錄端礼，這是壓力測試中常常使用的方法。

負(fù)載測試（Volume Testing）

用于檢查系統(tǒng)在使用大量數(shù)據(jù)的時候正確工作的能力入录，即檢驗系統(tǒng)的能力最高能達(dá)到什么程度蛤奥。例如，對于信息檢索系統(tǒng)僚稿，讓它使用頻率達(dá)到最大凡桥；對于多個終端的分時系統(tǒng)，讓它所有的終端都開動蚀同。在使整個系統(tǒng)的全部資源達(dá)到“滿負(fù)荷”的情形下缅刽，測試系統(tǒng)的承受能力。

30.寫出bug報告流轉(zhuǎn)的步驟蠢络，每步的責(zé)任人及主要完成的工作衰猛？

參考答案：（要結(jié)合自己實際的工作經(jīng)驗進(jìn)行回答，不同公司略有區(qū)別）

測試人員提交新的Bug入庫刹孔，錯誤狀態(tài)為New啡省。

高級測試員/測試經(jīng)理驗證錯誤，如果確認(rèn)是錯誤髓霞，分配給開發(fā)組卦睹。設(shè)置狀態(tài)為Open。如果不是錯誤酸茴，則拒絕分预，設(shè)置為Declined狀態(tài)。

開發(fā)經(jīng)理分配bug至對應(yīng)的模塊開發(fā)人員薪捍。

開發(fā)人員查詢狀態(tài)為Open的Bug笼痹，如果不是錯誤配喳，則置狀態(tài)為Declined；如果是Bug則修復(fù)并置狀態(tài)為Fixed凳干。不能解決的Bug晴裹，要留下文字說明及保持Bug為Open狀態(tài)。

對于不能解決和延期解決的Bug救赐，不能由開發(fā)人員自己決定涧团，一般要通過某種會議（評審會）通過才能認(rèn)可。

測試人員查詢狀態(tài)為Fixed的Bug经磅，然后驗證Bug是否已解決泌绣，如解決，置Bug的狀態(tài)為Closed预厌，如沒有解決,置bug狀態(tài)為Reopen阿迈。

31.寫出bug報告當(dāng)中一些必備的內(nèi)容？

參考答案：

硬件平臺和操作系統(tǒng)

測試應(yīng)用的硬件平臺（Platform）轧叽，通常選擇“PC”苗沧。

測試應(yīng)用的操作系統(tǒng)平臺（OS）。

a) 版本

提交缺陷報告時通過該字段標(biāo)識此缺陷存在于被測試軟件的哪個版本炭晒。

b) Bug報告優(yōu)先級

c) Bug狀態(tài)

d) Bug的編號

e) 發(fā)現(xiàn)人

f) 提交人

g) 指定處理人

h) 概述

i) 從屬關(guān)系

j) 詳細(xì)描述

k) 嚴(yán)重程度

l) 所屬模塊

m) 附件

n) 提交日期

32.畫出軟件測試的V模型圖待逞。

參考答案：

因個人時間有限以上只列取為軟件測試技術(shù)類面試題中的一部分，如果需要完整面試題网严，都可以點我進(jìn)行領(lǐng)取识樱，如有問題歡迎評論私信留言！

還包括測試軟件學(xué)習(xí)路線圖震束，50多天的測試上課視頻牺荠、16個突擊實戰(zhàn)測試項目，80余個軟件測試用軟件驴一，37份測試文檔，70個軟件測試相關(guān)問題灶壶，40篇測試經(jīng)驗級文章肝断，上千份測試真題分享,還有2022年軟件測試面試寶典，還有軟件測試求職的各類精選簡歷驰凛，希望對大家有所幫助……