part2 軟體測試基礎面試題（含答案）

1.軟體的生命周期（prdctrm）

計劃階段（planning）-〉需求分析（requirement）-〉設計階段（design）-〉編碼（coding）->測試（testing）->運作與維護（running maintrnacne）

2、問：你在測試中發現了一個bug，但是開發經理認為這不是一個bug，你應該怎樣解決？

首先，将問題送出到缺陷管理庫裡面進行備案。

然後，要擷取判斷的依據和标準：根據需求說明書、産品說明、原型圖、設計文檔等，确認實際結果是否與計劃有不一緻的地方，提供缺陷是否确認的直接依據；

如果沒有文檔依據，

1）可以根據同行或類似軟體的一般特性來說明是否存在不一緻的地方，來确認是否是缺陷；

2）根據使用者的一般使用習慣，來确認是否是缺陷；

3）與設計人員、開發人員和客戶代表等相關人員探讨，确認是否是缺陷；

合理的論述，向測試經理說明自己的判斷的理由，等待測試經理做出最終決定，如果仍然存在争議，可以通過公司政策所提供的管道，向上級反映，并有上級做出決定。

3、給你一個網站，你如何測試？

首先，查找需求說明、網站設計等相關文檔，分析測試需求。

制定測試計劃，确定測試範圍和測試政策，一般包括以下幾個部分：功能性測試；界面測試；性能測試；資料庫測試；安全性測試；相容性測試

設計測試用例：

功能性測試可以包括，但不限于以下幾個方面：

連結測試。連結是否正确跳轉，是否存在空頁面和無效頁面，是否有不正确的出錯資訊傳回。

送出功能的測試。

多媒體元素是否可以正确加載和顯示。

多語言支援是否能夠正确顯示選擇的語言等。

界面測試可以包括但不限于一下幾個方面：

頁面是否風格統一，美觀

頁面布局是否合理，重點内容和熱點内容是否突出

控件是否正常使用

對于必須但未安裝的控件，是否提供自動下載下傳并安裝的功能

文字檢查

性能測試一般從以下兩個方面考慮：

壓力測試；負載測試；強度測試

資料庫測試要具體決定是否需要開展。資料庫一般需要考慮連結性，對資料的存取操作，資料内容的驗證等方面。

安全性測試：

基本的登入功能的檢查

是否存在溢出錯誤，導緻系統崩潰或者權限洩露

相關開發語言的常見安全性問題檢查，例如SQL注入等

如果需要進階的安全性測試，确定獲得專業安全公司的幫助，外包測試，或者擷取支援相容性測試，

根據需求說明的内容，确定支援的平台組合：

浏覽器的相容性；

作業系統的相容性；

軟體平台的相容性；

資料庫的相容性

開展測試，并記錄缺陷。合理的安排調整測試進度，提前擷取測試所需的資源，建立管理體系（

例如，需求變更、風險、配置、測試文檔、缺陷報告、人力資源等内容）。

定期評審，對測試進行評估和總結，調整測試的内容。

4、問：一台用戶端有三百個客戶與三百個用戶端有三百個客戶對伺服器施壓，有什麼差別?

300個使用者在一個用戶端上，會占用客戶機更多的資源，而影響測試的結果。線程之間可能發生幹擾，而産生一些異常。

300個使用者在一個用戶端上，需要更大的帶寬。

IP位址的問題，可能需要使用IP Spoof來繞過伺服器對于單一IP位址最大連接配接數的限制。

所有使用者在一個用戶端上，不必考慮分布式管理的問題；

而使用者分布在不同的用戶端上，需要考慮使用控制器來整體調配不同客戶機上的使用者。同時，還需要給予相應的權限配置和防火牆設定。

5、軟體生存周期及其模型是什麼？

軟體生存周期（Software life cycle）又稱為軟體生命期，生存期。是指從形成開發軟體概念起，所開發的軟體使用以後，直到失去使用價值消亡為止的整個過程。一般來說，整個生存周期包括 ：問題的定義及規劃、需求分析/評審、軟體設計、軟體編碼、測試階段、運作維護 六個時期，每個時期又劃分為若幹個階段。每個階段有明确的任務。

周期模型（典型的幾種）：

1）瀑布模型

2）快速原型模型：快速原型模型允許在需求分析階段對軟體的需求進行初步而非完全的分析和定義，快速設計開發出軟體系統的原型，該原型向使用者展示待開發軟體的全部或部分功能和性能；使用者對該原型進行測試評定，給出具體改進意見以豐富細化軟體需求；開發人員據此對軟體進行修改完善，直至使用者滿意認可之後，進行軟體的完整實作及測試、維護。

3）疊代模型：疊代包括産生産品釋出（穩定、可執行的産品版本）的全部開發活動和要使用該釋出必需的所有其他外圍元素。在某種程度上，開發疊代是一次 完整地經過所有工作流程的過程：需求分析、設計、實施和測試工作流程。實質上，它類似小型的瀑布式項目。RUP認為，所有的階段都可以細分為疊代。每一次 的疊代都會産生一個可以釋出的産品，這個産品是最終産品的一個子集。

生命周期階段：

軟體計劃與可行性分析

需求分析

軟體設計

編碼

軟體測試

運作與維護

6、什麼是軟體測試？軟體測試的目的與原則

定義：

在規定的條件下對程式進行操作，以發現程式錯誤，衡量軟體品質，并對其是否能滿足設計要求進行評估的過程。

目的：

測試是程式的執行過程，目的在于發現錯誤

軟體測試為了發現程式中存在的代碼或業務邏輯錯誤

軟體測試為了檢驗産品是否符合使用者的需求

軟體測試為了提高使用者體驗

軟體測試的原則：

測試應盡早啟動、介入（需求分析階段），所有的測試應追溯到使用者需求，測試證明軟體存在缺陷，不可能執行窮盡測試，完全測試是不可能的，測試需要終止。

二八原則，測試發現的錯誤中80%很可能的起源于20%的子產品中。（缺陷存在群集現象）

對錯誤結果要進行一個确認的過程（測試的詳細資料，截圖，前置條件等），制定嚴格的測試計劃；妥善保管測試過程中的所有文檔；程式員盡量避免自己的檢查程式；設計測試用例是應該考慮到合法的輸入和不合法的輸入

7、什麼是軟體品質？

概括地說，軟體品質就是“軟體與明确的和隐含的定義的需求相一緻的程度”。具體地說，軟體品質是軟體符合明确叙述的功能和性能需求、文檔中明确描述 的開發标準、以及所有專業開發的軟體都應具有的隐含特征的程度。 影響軟體品質的主要因素，這些因素是從管理角度對軟體品質的度量。可劃分為三組，分别反應使用者在使用軟體産品時的三種觀點。正确性、健壯性、效率、完整性、可用性、風險（産品運作）；可了解性、可維修性、靈活性、可測試性（産品修改）；可移植性、可再用性、互運作性（産品轉移）。

8、目前主要的測試用例設計方法是什麼？

白盒測試：邏輯覆寫、循環覆寫、基本路徑覆寫

黑盒測試：邊界值分析法、等價類劃分、錯誤猜測法、因果圖法、狀态圖法、測試大綱法、随機測試、場景法

9、軟體的安全性應從哪幾個方面去測試？

軟體安全性測試包括程式、資料庫安全性測試。根據系統安全名額不同測試政策也不同。

使用者認證安全的測試要考慮問題：

1）明确區分系統中不同使用者權限 、系統中會不會出現使用者沖突 、系統會不會因使用者的權限的改變造成混亂

2）使用者登陸密碼是否是可見、可複制 、是否可以通過絕對途徑登陸系統（拷貝使用者登陸後的連結直接進入系統）

3）使用者退出系統後是否删除了所有鑒權标記，是否可以使用後退鍵而不通過輸入密碼進入 系統

系統網絡安全的測試要考慮問題 ：

1）測試采取的防護措施是否正确裝配好

2）有關系統的更新檔是否打上

3）模拟非授權***

4）看防護系統是否堅固

5）采用成熟的網絡漏洞檢查工具檢查系統相關漏洞（即用最專業的***工具試一下，現在最常用的是 NBSI 系列和 IPhacker IP ）

6)采用各種檢查工具檢查系統情況

7)采用各種防外挂工具檢查系統各組程式的外挂漏洞

資料庫安全考慮問題：

1）系統資料是否機密（比如對銀行系統，這一點就特别重要，一般的網站就沒有太高要求）

2）系統資料的完整性（我剛剛結束的企業實名核查服務系統中就曾存在資料 的不

3）完整，對于這個系統的功能實作有了障礙） 、系

4）統資料可管理性 、

5）系統資料的獨立性 、

6）系統資料可備份和恢複能力（資料備份是否完整，可否恢複，恢複是否可以完整）

10、什麼是測試用例 什麼是測試腳本 兩者的關系是什麼？

用例：

未實施測試而編制的一組測試輸入、執行條件、各種環境設定以及預期結果以及期望結果的一個特定的集合。

腳本：

測試腳本是為了進行自動化測試而編寫的腳本。

測試腳本的編寫必須對應相應的測試用例

11、簡述什麼是靜态測試、動态測試、黑盒測試、白盒測試、α測試 β測試

靜态測試：是不運作程式本身而尋找程式代碼中可能存在的錯誤或評估程式代碼的過程。

動态測試：是實際運作被測程式，輸入相應的測試執行個體，檢查運作結果與預期結果的差異，判定執行結果是否符合要求，進而檢驗程式的正确性、可靠性和有效性，并分析系統運作效率和健壯性等性能。

黑盒測試：一般用來确認軟體功能的正确性和可操作性,目的是檢測軟體的各個功能是否能得以實作,把被測試的程式當作一個黑盒,不考慮其内部結構,在知道該程式的輸入和輸出之間的關系或程式功能的情況下,依靠軟體規格說明書來确定測試用例和推斷測試結果的正确性。

白盒測試：根據軟體内部的邏輯結構分析來進行測試,是基于代碼的測試，測試人員通過閱讀程式代碼或者通

過使用開發工具中的單步調試來判斷軟體的品質，一般黑盒測試由項目經理在程式員開發中來實作。

α測試：是由使用者在開發環境下進行的測試，也可以是公司内部的使用者在模拟實際操作環境下進行的受控測試，Alpha測試不能由程式員或測試員完成。

β測試：由軟體的一個或多個使用者在實際使用環境下進行的測試， 開發者通常不在測試現場，Beta測試不能由程式員或測試員完成。

12、軟體産品品質特性是什麼?

功能性：适應性、準确性、互操作性、依從性、安全性。

可靠性：成熟性、容錯性、易恢複性。

可使用性：易了解性、易學習性、易操作性。

效率：時間特性、資源特性。

可維護性：易分析性、易變更性、穩定性、易測試性。

可移植性： 适應性、易安裝性、遵循性、易替換性

13、軟體測試的政策是什麼?

軟體測試政策：在一定的軟體測試标準、測試規範的指導下，依據測試項目的特定環境限制而規定的軟體測試的原則、方式、方法的集合。

14、軟體測試分為幾個階段 各階段的測試政策和要求是什麼?

測試過程會依次經曆單元測試、內建測試、系統測試、驗收測試四個主要階段

單元測試：是針對軟體設計的最小機關––程式子產品甚至代碼段進行正确性檢驗的測試工作，通常由開發人員進行。

內建測試：是将子產品按照設計要求組裝起來進行測試，主要目的是發現與接口有關的問題。由于在産品送出到測試部門前，産品開發小組都要進行聯合調試，是以在大部分企業中內建測試是由開發人員來完成的。

系統測試：是在內建測試通過後進行的，目的是充分運作系統，驗證各子系統是否都能正常工作并完成設計的要求。它主要由測試部門進行，是測試部門最大最重要的一個測試，對産品的品質有重大的影響。

驗收測試：以需求階段的《需求規格說明書》為驗收标準，測試時要求模拟實際使用者的運作環境。對于實際項

目可以和客戶共同進行，對于産品來說就是最後一次的系統測試。測試内容為對功能子產品的全面測試，尤其要進行文檔測試。

單元測試測試政策：

自頂向下的單元測試政策：比孤立單元測試的成本高很多，不是單元測試的一個好的選擇。

自底向上的單元測試政策：比較合理的單元測試政策，但測試周期較長。

孤立單元測試政策：最好的單元測試政策。

內建測試的測試政策：

大爆炸內建：适應于一個維護型項目或被測試系統較小

自頂向下內建：适應于産品控制結構比較清晰和穩定；高層接口變化較小；底層接口未定義或經常可能被修改；産口控制元件具有較大的技術風險，需要盡早被驗證；希望盡早能看到産品的系統功能行為。

自底向上內建：适應于底層接口比較穩定；高層接口變化比較頻繁；底層元件較早被完成。

基于進度的內建

優點：具有較高的并行度；能夠有效縮短項目的開發進度。

缺點：樁和驅動工作量較大；有些接口測試不充分；有些測試重複和浪費。

系統測試的測試政策：

資料和資料庫完整性測試；功能測試；使用者界面測試；性能評測；負載測試；強度測試；容量測試；安全性和通路控制測試；故障轉移和恢複測試；配置測試；安裝測試；加密測試；可用性測試；版本驗證測試；文檔測試

15、軟體測試各個階段通常完成什麼工作？各個階段的結果檔案是什麼？包括什麼内容？

單元測試階段：

各獨立單元子產品在與系統地其他部分相隔離的情況下進行測試，單元測試針對每一個程式子產品進行正确性校驗，檢查各個程式子產品是否正确地實作了規定的功能。生成單元測試報告，送出缺陷報告。

內建測試階段：

內建測試是在單元測試的基礎上，測試在将所有的軟體單元按照概要設計規格說明的要求組裝成子產品、子系統或系統的過程中各部分工作是否達到或實作相應技術名額及要求的活動。該階段生成內建測試報告，送出缺陷報告。

系統測試階段：

将通過确認測試的軟體，作為整個給予計算機系統的一個元素，與計算機硬體、外設、某些支援軟體、資料和人員等其他系統元素結合在一起，在實際運作環境下，對計算機系統進行全面的功能覆寫。該階段需要送出測試總結和缺陷報告。

16、測試人員在軟體開發過程中的任務是什麼？

1、盡可能早的找出系統中的Bug；

2、避免軟體開發過程中缺陷的出現；

3、衡量軟體的品質，保證系統的品質；

4、關注使用者的需求，并保證系統符合使用者需求。

總的目标是：確定軟體的品質。

17、在您以往的工作中，一條軟體缺陷（或者叫Bug）記錄都包含了哪些内容？如何送出高品質的軟體缺陷（Bug）記錄？

一條Bug記錄最基本應包含：

bug編号；

bug嚴重級别，優先級；

bug産生的子產品；

首先要有bug摘要，闡述bug大體的内容；

bug對應的版本；

bug詳細現象描述，包括一些截圖、錄像…等等；

bug出現時的測試環境，産生的條件即對應操作步驟；

高品質的Bug記錄：

通用UI要統一、準确

缺陷報告的UI要與測試的軟體UI保持一緻，便于查找定位。

盡量使用業界慣用的表達術語和表達方法

使用業界慣用的表達術語和表達方法，保證表達準确，展現專業化。

每條缺陷報告隻包括一個缺陷

每條缺陷報告隻包括一個缺陷，可以使缺陷修正者迅速定位一個缺陷，集中精力每次隻修正一個缺陷。校驗者每次隻校驗一個缺陷是否已經正确修正。

不可重制的缺陷也要報告

首先缺陷報告必須展示重制缺陷的能力。不可重制的缺陷要盡力重制，若盡力之後仍不能重制，仍然要報告此缺陷，但在報告中要注明無法再現，缺陷出現的頻率。

明确指明缺陷類型

根據缺陷的現象，總結判斷缺陷的類型。例如，即功能缺陷、界面缺陷、資料缺陷，合理化建議。這是最常見的缺陷或缺陷類型，其他形式的缺陷或缺陷也從屬于其中某種形式。

明确指明缺陷嚴重等級和優先等級時刻明确嚴重等級和優先等級之間的差别。高嚴重問題可能

描述 (Description) ，簡潔、準确，完整，揭示缺陷實質，記錄缺陷或缺陷出現的位置描述要準确反映缺陷的本質内容，簡短明了。為了便于在軟體缺陷管理資料庫中尋找制定的測試缺陷，包含缺陷發生時的使用者界面（UI）是個良好的習慣。例如記錄對話框的标題、菜單、按鈕等控件的名稱。

短行之間使用自動數字序号，使用相同的字型、字号、行間距

短行之間使用自動數字序号，使用相同的字型、字号、行間距，可以保證各條記錄格式一緻，做到規範專業。

每一個步驟盡量隻記錄一個操作保證簡潔、條理井然，容易重複操作步驟。

确認步驟完整，準确，簡短

保證快速準确的重複缺陷，“完整”即沒有缺漏，“準确”即步驟正确，“簡短”即沒有多餘的步驟。

根據缺陷，可選擇是否進行圖象捕捉

為了直覺的觀察缺陷或缺陷現象，通常需要附加缺陷或缺陷出現的界面，以圖檔的形式作為附件附着在記錄的“附件”部分。為了節省空間，又能真實反映缺陷或缺陷本質，可以捕捉缺陷或缺陷産生時的全螢幕，活動視窗和局部區域。為了迅速定位、修正缺陷或缺陷位置，通常要求附加中文對照圖。

 附加必要的特殊文檔和個人建議和注解如果打開某個特殊的文檔而産生的缺陷或缺陷，則必須附加該文檔，進而可以迅速再現缺陷或缺陷。有時，為了使缺陷或缺陷修正者進一步明确缺陷或缺陷的表現，可以附加個人的修改建議或注解。

檢查拼寫和文法缺陷

在送出每條缺陷或缺陷之前，檢查拼寫和文法，確定内容正确，正确的描述缺陷。

盡量使用短語和短句，避免複雜句型句式軟體缺陷管理資料庫的目的是便于定位缺陷，是以，要求客觀的描述操作步驟，不需要修飾性的詞彙和複雜的句型，增強可讀性。

以上概括了報告測試缺陷的規範要求，随着軟體的測試要求不同，測試者經過長期測試，積累了相應的測試經驗，将會逐漸養成良好的專業習慣，不斷補充新的規範書寫要求。此外，經常閱讀、學習其他測試工程師的測試缺陷報告，結合自己以前的測試缺陷報告進行對比和思考，可以不斷提高技巧。

缺陷描述内容

缺陷描述的内容可以包含缺陷操作步驟，實際結果和期望結果。操作步驟可以友善開發人員再現缺陷進行修正，有些開發的再現缺陷能力很差，雖然他明白你所指的缺陷，但就是無法再現特别是對系統不熟悉的新加入開發人員，介紹步驟可以友善他們再現。實際結果可以讓開發明白錯誤是什麼，期望結果可以讓開發了解正确的結果應該是如何。

18、黑盒測試和白盒測試是軟體測試的兩種基本方法，請分别說明各自的優點和缺點！

黑盒測試的優點有：

比較簡單，不需要了解程式内部的代碼及實作；

與軟體的内部實作無關；

從使用者角度出發，能很容易的知道使用者會用到哪些功能，會遇到哪些問題；

基于軟體開發文檔，是以也能知道軟體實作了文檔中的哪些功能；在做軟體自動化測試時較為友善。

黑盒測試的缺點有：

不可能覆寫所有的代碼，覆寫率較低，大概隻能達到總代碼量的30%；自動化測試的複用性較低。

白盒測試的優點有：

幫助軟體測試人員增大代碼的覆寫率，提高代碼的品質，發現代碼中隐 藏的問題。

白盒測試的缺點有：

程式運作會有很多不同的路徑，不可能測試所有的運作路徑；

測試基于代碼，隻能測試開發人員做的對不對，而不能知道設計的正确與否，可能會漏掉一些功能需求；系統龐大時，測試開銷會非常大。

19、如何測試一個紙杯？

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

安全性：杯子有沒有毒或細菌

可靠性：杯子從不同高度落下的損壞程度

可移植性：杯子在不同的地方、溫度等環境下是否都可以正常使用

相容性：杯子是否能夠容納果汁、白水、酒精、汽油等

易用性：杯子是否燙手、是否有防滑措施、是否友善飲用

使用者文檔：使用手冊是否對杯子的用法、限制、使用條件等有較長的描述

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

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

20、黑盒測試的測試用例常見設計方法都有哪些？請分别以具體的例子來說明這些方法在測試用例設計工作中的應用。

1）等價類劃分：

等價類是指某個輸入域的子集合.在該子集合中,各個輸入資料對于揭露程式中的錯誤都是等效的.并合理地假定:測試某等價類的代表值就等于對這一類其它值的測試.是以,可以把全部輸入資料合理劃分為若幹等價類,在每一個等價類中取一個資料作為測試的輸入條件,就可以用少量代表性的測試資料.取得較好的測試結果.等價類劃分可有兩種不同的情況:有效等價類和無效等價類.

2）邊界值分析法：

是對等價類劃分方法的補充。測試工作經驗告訴我,大量的錯誤是發生在輸入或輸出範圍的邊界上,而不是發生在輸入輸出範圍的内部.是以針對各種邊界情況設計測試用例,可以查出更多的錯誤.使用邊界值分析方法設計測試用例,首先應确定邊界情況.通常輸入和輸出等價類的邊界,就是應着重測試的邊界情況.應當選取正好等于,剛剛大于或剛剛小于邊界的值作為測試資料,而不是選取等價類中的典型值或任意值作為測試資料。

3）錯誤猜測法：

基于經驗和直覺推測程式中所有可能存在的各種錯誤, 進而有針對性的設計測試用例的方法。錯誤推測方法的基本思想: 列舉出程式中所有可能有的錯誤和容易發生錯誤的特殊情況,根據他們選擇測試用例. 例如, 在單元測試時曾列出的許多在子產品中常見的錯誤. 以前産品測試中曾經發現的錯誤等, 這些就是經驗的總結. 還有, 輸入資料和輸出資料為0的情況. 輸入表格為空格或輸入表格隻有一行. 這些都是容易發生錯誤的情況. 可選擇這些情況下的例子作為測試用例。

4）因果圖方法：

前面介紹的等價類劃分方法和邊界值分析方法,都是着重考慮輸入條件,但未考慮輸入條件之間的聯系, 互相組合等. 考慮輸入條件之間的互相組合,可能會産生一些新的情況. 但要檢查輸入條件的組合不是一件容易的事情, 即使把所有輸入條件劃分成等價類,他們之間的組合情況也相當多. 是以必須考慮采用一種适合于描述對于多種條件的組合,相應産生多個動作的形式來考慮設計測試用例。這就需要利用因果圖（邏輯模型）。因果圖方法最終生成的就是判定表.它适合于檢查程式輸入條件的各種組合情況。

5）正交表分析法：

可能因為大量的參數的組合而引起測試用例數量上的激增，同時，這些測試用例并沒有明顯的優先級上的差距，而測試人員又無法完成這麼多數量的測試，就可以通過正交表來進行縮減一些用例，進而達到盡量少的用例覆寫盡量大的範圍的可能性。

6）場景分析方法：指根據使用者場景來模拟使用者的操作步驟，這個比較類似因果圖，但是可能執行的深度和可行性更好。

7）狀态圖法：

通過輸入條件和系統需求說明得到被測系統的所有狀态，通過輸入條件和狀态得出輸出條件；通過輸入條件、輸出條件和狀态得出被測系統的測試用例。

8）大綱法：

大綱法是一種着眼于需求的方法，為了列出各種測試條件，就将需求轉換為大綱的形式。大綱表示為樹狀結構，在根和每個葉子結點之間存在唯一的路徑。大綱中的每條路徑定義了一個特定的輸入條件集合，用于定義測試用例。樹中葉子的數目或大綱中的路徑給出了測試所有功能所需測試用例的大緻數量。

讀後感

來這裡找我交流

• QQ群：330374464
• 公衆号：軟體測試資源站(ID:testpu)
• CSDN：https://blog.csdn.net/mcfnhm
• 語雀：https://www.yuque.com/testpu/pro

主攻測開及接口自動化方向，分享爬蟲擷取的稀缺精品資源，歡迎關注微信擷取。