軟件測試面試題集合（一）

1.軟件的生命週期（prdctrm）

計劃階段（planning）-〉需求分析（requirement）-〉設計階段（design）-〉編碼

（coding）->測試（testing）->運行與維護（running maintrnacne）

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

首先，將問題提交到缺陷管理庫裏面進行備案。

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

若是沒有文檔依據，
1）能夠根據同行或相似軟件的通常特性來講明是否存在不一致的地方，來確認是不是缺陷；
2）根據用戶的通常使用習慣，來確認是不是缺陷；
3）與設計人員、開發人員和客戶表明等相關人員探討，確認是不是缺陷；
合理的論述，向測試經理說明本身的判斷的理由，等待測試經理作出最終決定，若是仍然存在爭議，能夠經過公司政策所提供的渠道，向上級反映，並有上級作出決定。

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

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

制定測試計劃，肯定測試範圍和測試策略，通常包括如下幾個部分：功能性測試；界面測試；性
能測試；數據庫測試；安全性測試；兼容性測試

設計測試用例：
功能性測試能夠包括，但不限於如下幾個方面：
連接測試。連接是否正確跳轉，是否存在空頁面和無效頁面，是否有不正確的出錯信息返回。
提交功能的測試。
多媒體元素是否能夠正確加載和顯示。
多語言支持是否可以正確顯示選擇的語言等。
界面測試能夠包括但不限於一下幾個方面：

頁面是否風格統一，美觀
頁面佈局是否合理，重點內容和熱點內容是否突出
控件是否正常使用
對於必須但未安裝的控件，是否提供自動下載並安裝的功能
文字檢查
性能測試通常從如下兩個方面考慮：

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

數據庫測試要具體決定是否須要開展。數據庫通常須要考慮連結性，對數據的存取操做，數據內

容的驗證等方面。

安全性測試：

基本的登陸功能的檢查
是否存在溢出錯誤，致使系統崩潰或者權限泄露
相關開發語言的常見安全性問題檢查，例如SQL注入等
若是須要高級的安全性測試，肯定得到專業安全公司的幫助，外包測試，或者獲取支持
兼容性測試，根據需求說明的內容，肯定支持的平臺組合：

瀏覽器的兼容性；
操做系統的兼容性；
軟件平臺的兼容性；
數據庫的兼容性
開展測試，並記錄缺陷。合理的安排調整測試進度，提早獲取測試所需的資源，創建管理體系（

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

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

四、問：一臺客戶端有三百個客戶與三百個客戶端有三百個客戶對服務器施壓，有什麼區別?

300個用戶在一個客戶端上，會佔用客戶機更多的資源，而影響測試的結果。
線程之間可能發生干擾，而產生一些異常。
300個用戶在一個客戶端上，須要更大的帶寬。
IP地址的問題，可能須要使用IP Spoof來繞過服務器對於單一IP地址最大鏈接數的限制。
全部用戶在一個客戶端上，沒必要考慮分佈式管理的問題；

而用戶分佈在不一樣的客戶端上，須要考慮使用控制器來總體調配不一樣客戶機上的用戶。同時，還須要給予相應的權限配置和防火牆設置。

五、軟件生存週期及其模型是什麼？

軟件生存週期（Software life cycle）又稱爲軟件生命期，生存期。是指從造成開發軟件概念起

，所開發的軟件使用之後，直到失去使用價值消亡爲止的整個過程。通常來講，整個生存週期包

括 ：問題的定義及規劃、需求分析/評審、軟件設計、軟件編碼、測試階段、運行維護 六個時期，每一個時期又劃分爲若干個階段。每一個階段有明確的任務。

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

瀑布模型

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

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

生命週期階段：
軟件計劃與可行性分析
需求分析
軟件設計
編碼
軟件測試
運行與維護

六、什麼是軟件測試？軟件測試的目的與原則

定義：
在規定的條件下對程序進行操做，以發現程序錯誤，衡量軟件質量，並對其是否能知足設計要求進行評估的過程。

目的：
測試是程序的執行過程，目的在於發現錯誤
軟件測試爲了發現程序中存在的代碼或業務邏輯錯誤
軟件測試爲了檢驗產品是否符合用戶的需求
軟件測試爲了提升用戶體驗

軟件測試的原則：

測試應儘早啓動、介入（需求分析階段）
全部的測試應追溯到用戶需求
測試證實軟件存在缺陷
不可能執行窮盡測試，徹底測試是不可能的，測試須要終止。
二八原則，測試發現的錯誤中80%極可能的起源於20%的模塊中。（缺陷存在羣集現象）
對錯誤結果要進行一個確認的過程（測試的詳細數據，截圖，前置條件等）
制定嚴格的測試計劃
妥善保管測試過程當中的全部文檔
程序員儘可能避免本身的檢查程序
設計測試用例是應該考慮到合法的輸入和不合法的輸入

七、什麼是軟件質量？

歸納地說，軟件質量就是「軟件與明確的和隱含的定義的需求相一致的程度」。具體地說，軟件

質量是軟件符合明確敘述的功能和性能需求、文檔中明確描述 的開發標準、以及全部專業開發的
軟件都應具備的隱含特徵的程度。 影響軟件質量的主要因素，這些因素是從管理角度對軟件質量
的度量。可劃分爲三組，分別反應用戶在使用軟件產品時的三種觀點。正確性、健壯性、效率、
完整性、可用性、風險（產品運行）；可理解性、可維修性、靈活性、可測試性（產品修改）；
可移植性、可再用性、互運行性（產品轉移）。

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

白盒測試：邏輯覆蓋、循環覆蓋、基本路徑覆蓋
黑盒測試：邊界值分析法、等價類劃分、錯誤猜想法、因果圖法、狀態圖法、測試大綱法、隨機
測試、場景法

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

軟件安全性測試包括程序、數據庫安全性測試。根據系統安全指標不一樣測試策略也不一樣。
用戶認證安全的測試要考慮問題：
1）明確區分系統中不一樣用戶權限 、系統中會不會出現用戶衝突 、系統會不會因用戶的權限的改變形成混亂 、
2）用戶登錄密碼是不是可見、可複製 、是否能夠經過絕對途徑登錄系統（拷貝用戶登錄後的連接直接進入系統）、
3）用戶退出系統後是否刪除了全部鑑權標記，是否可使用後退鍵而不經過輸入口令進入 系統 、

系統網絡安全的測試要考慮問題 ：
1）測試採起的防禦措施是否正確裝配好，
2）有關係統的補丁是否打上 、
3）模擬非受權***，
4）看防禦系統是否堅固 、
5）採用成熟的網絡漏洞檢查工具檢查系統相關漏洞（即用最專業的******工具***試一下，如今最經常使用的是 NBSI 系列和 IPhacker IP ）
6)採用各類***檢查工具檢查系統***狀況
7)採用各類防外掛工具檢查系統各組程序的外掛漏洞

數據庫安全考慮問題：
1）系統數據是否機密（好比對銀行系統，這一點就特別重要，通常的網站就沒有過高要求）
2）系統數據的完整性（我剛剛結束的企業實名覈查服務系統中就曾存在數據 的不
3）完整，對於這個系統的功能實現有了障礙） 、系
4）統數據可管理性 、
5）系統數據的獨立性 、
6）系統數據可備份和恢復能力（數據備份是否完整，能否恢復，恢復是否能夠完整）

十、什麼是測試用例 什麼是測試腳本 二者的關係是什麼？

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

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

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

十一、簡述什麼是靜態測試、動態測試、黑盒測試、白盒測試、α測試 β測試

靜態測試：
是不運行程序自己而尋找程序代碼中可能存在的錯誤或評估程序代碼的過程。
動態測試：
是實際運行被測程序，輸入相應的測試實例，檢查運行結果與預期結果的差別，斷定執行結果是
否符合要求，從而檢驗程序的正確性、可靠性和有效性，並分析系統運行效率和健壯性等性能。

黑盒測試：
通常用來確認軟件功能的正確性和可操做性,目的是檢測軟件的各個功能是否能得以實現,把被測試
的程序看成一個黑盒,不考慮其內部結構,在知道該程序的輸入和輸出之間的關係或程序功能的狀況
下,依靠軟件規格說明書來肯定測試用例和推斷測試結果的正確性。

白盒測試：
根據軟件內部的邏輯結構分析來進行測試,是基於代碼的測試，測試人員經過閱讀程序代碼或者通
過使用開發工具中的單步調試來判斷軟件的質量，通常黑盒測試由項目經理在程序員開發中來實現。

α測試：
是由用戶在開發環境下進行的測試，也能夠是公司內部的用戶在模擬實際操做環境下進行的受控測
試，Alpha測試不能由程序員或測試員完成。

β測試
由軟件的一個或多個用戶在實際使用環境下進行的測試， 開發者一般不在測試現場，Beta測試
不能由程序員或測試員完成。

十二、軟件產品質量特性是什麼?

功能性：適應性、準確性、互操做性、依從性、安全性。
可靠性：成熟性、容錯性、易恢復性。
可以使用性：易理解性、易學習性、易操做性。
效率：時間特性、資源特性。
可維護性：易分析性、易變動性、穩定性、易測試性。
可移植性： 適應性、易安裝性、遵循性、易替換性

1三、軟件測試的策略是什麼?

軟件測試策略：在必定的軟件測試標準、測試規範的指導下，依據測試項目的特定環境約束而規
定的軟件測試的原則、方式、方法的集合。

1四、軟件測試分爲幾個階段 各階段的測試策略和要求是什麼?

測試過程會依次經歷單元測試、集成測試、系統測試、驗收測試四個主要階段

單元測試：
單元測試是針對軟件設計的最小單位––程序模塊甚至代碼段進行正確性檢驗的測試工做，一般由開發人員進行。

集成測試：
集成測試是將模塊按照設計要求組裝起來進行測試，主要目的是發現與接口有關的問題。因爲在
產品提交到測試部門前，產品開發小組都要進行聯合調試，所以在大部分企業中集成測試是由開
發人員來完成的。

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

驗收測試：
驗收測試以需求階段的《需求規格說明書》爲驗收標準，測試時要求模擬實際用戶的運行環境。
對於實際項目能夠和客戶共同進行，對於產品來講就是最後一次的系統測試。測試內容爲對功
能模塊的全面測試，尤爲要進行文檔測試。

單元測試測試策略：
自頂向下的單元測試策略：比孤立單元測試的成本高不少，不是單元測試的一個好的選擇。
自底向上的單元測試策略：比較合理的單元測試策略，但測試周期較長。
孤立單元測試策略：最好的單元測試策略。

集成測試的測試策略：
大爆炸集成：適應於一個維護型項目或被測試系統較小
自頂向下集成：適應於產品控制結構比較清晰和穩定；高層接口變化較小；底層接口未定義或經
常可能被修改；產口控制組件具備較大的技術風險，須要儘早被驗證；但願儘早能看到產品的系
統功能行爲。
自底向上集成：適應於底層接口比較穩定；高層接口變化比較頻繁；底層組件較早被完成。
基於進度的集成
優勢：具備較高的並行度；可以有效縮短項目的開發進度。
缺點：樁和驅動工做量較大；有些接口測試不充分；有些測試重複和浪費。

系統測試的測試策略：

數據和數據庫完整性測試；功能測試；用戶界面測試；性能評測；負載測試；強度測試；容量測
試；安全性和訪問控制測試；故障轉移和恢復測試；配置測試；安裝測試；加密測試；可用性測
試；版本驗證測試；文檔測試

1五、軟件測試各個階段一般完成什麼工做？各個階段的結果文件是什麼？包括什麼內容？

單元測試階段：
各獨立單元模塊在與系統地其餘部分相隔離的狀況下進行測試，單元測試針對每個程序模塊進
行正確性校驗，檢查各個程序模塊是否正確地實現了規定的功能。生成單元測試報告，提交缺陷
報告。

集成測試階段：
集成測試是在單元測試的基礎上，測試在將全部的軟件單元按照概要設計規格說明的要求組裝成
模塊、子系統或系統的過程當中各部分工做是否達到或實現相應技術指標及要求的活動。該階段生
成集成測試報告，提交缺陷報告。

系統測試階段：
將經過確認測試的軟件，做爲整個給予計算機系統的一個元素，與計算機硬件、外設、某些支持
軟件、數據和人員等其餘系統元素結合在一塊兒，在實際運行環境下，對計算機系統進行全面的功
能覆蓋。該階段須要提交測試總結和缺陷報告。

1六、測試人員在軟件開發過程當中的任務是什麼？

一、儘量早的找出系統中的Bug；
二、避免軟件開發過程當中缺陷的出現；
三、衡量軟件的品質，保證系統的質量；
四、關注用戶的需求，並保證系統符合用戶需求。
總的目標是：確保軟件的質量。

1七、在您以往的工做中，一條軟件缺陷（或者叫Bug）記錄都包含了哪些內容？
如何提交高質量的軟件缺陷（Bug）記錄？

一條Bug記錄最基本應包含：
bug編號；
bug嚴重級別，優先級；
bug產生的模塊；
首先要有bug摘要，闡述bug大致的內容；
bug對應的版本；
bug詳細現象描述，包括一些截圖、錄像....等等；
bug出現時的測試環境，產生的條件即對應操做步驟；

高質量的Bug記錄：

1) 通用UI要統1、準確
缺陷報告的UI要與測試的軟件UI保持一致，便於查找定位。

2) 儘可能使用業界慣用的表達術語和表達方法
使用業界慣用的表達術語和表達方法，保證表達準確，體現專業化。

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

4) 不可重現的缺陷也要報告
首先缺陷報告必須展現重現缺陷的能力。不可重現的缺陷要盡力重現，若盡力以後仍不能重現，
仍然要報告此缺陷，但在報告中要註明沒法再現，缺陷出現的頻率。

5) 明確指明缺陷類型
根據缺陷的現象，總結判斷缺陷的類型。例如，即功能缺陷、界面缺陷、數據缺陷，合理化建議
這是最多見的缺陷或缺陷類型，其餘形式的缺陷或缺陷也從屬於其中某種形式。

6) 明確指明缺陷嚴重等級和優先等級時刻明確嚴重等級和優先等級之間的差異。高嚴重問題可能

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

8) 短行之間使用自動數字序號，使用相同的字體、字號、行間距
短行之間使用自動數字序號，使用相同的字體、字號、行間距，能夠保證各條記錄格式一致，作
到規範專業。

9) 每個步驟儘可能只記錄一個操做保證簡潔、條理井然，容易重複操做步驟。

10) 確認步驟完整，準確，簡短
保證快速準確的重複缺陷，「完整」即沒有缺漏，「準確」即步驟正確，「簡短」即沒有多餘的步驟。

11) 根據缺陷，可選擇是否進行圖象捕捉
爲了直觀的觀察缺陷或缺陷現象，一般須要附加缺陷或缺陷出現的界面，以圖片的形式做爲附件
附着在記錄的「附件」部分。爲了節省空間，又能真實反映缺陷或缺陷本質，能夠捕捉缺陷或缺
陷產生時的全屏幕，活動窗口和局部區域。爲了迅速定位、修正缺陷或缺陷位置，一般要求附加
中文對照圖。
 附加必要的特殊文檔和我的建議和註解
若是打開某個特殊的文檔而產生的缺陷或缺陷，則必須附加該文檔，從而能夠迅速再現缺陷或缺
陷。有時，爲了使缺陷或缺陷修正者進一步明確缺陷或缺陷的表現，能夠附加我的的修改建議或
註解。

12) 檢查拼寫和語法缺陷
在提交每條缺陷或缺陷以前，檢查拼寫和語法，確保內容正確，正確的描述缺陷。

13) 儘可能使用短語和短句，避免複雜句型句式
軟件缺陷管理數據庫的目的是便於定位缺陷，所以，要求客觀的描述操做步驟，不須要修飾性的
詞彙和複雜的句型，加強可讀性。
以上歸納了報告測試缺陷的規範要求，隨着軟件的測試要求不一樣，測試者通過長期測試，積累了
相應的測試經驗，將會逐漸養成良好的專業習慣，不斷補充新的規範書寫要求。此外，常常閱讀
、學習其餘測試工程師的測試缺陷報告，結合本身之前的測試缺陷報告進行對比和思考，能夠不
斷提升技巧。

14) 缺陷描述內容
缺陷描述的內容能夠包含缺陷操做步驟，實際結果和指望結果。操做步驟能夠方便開發人員再現
缺陷進行修正，有些開發的再現缺陷能力不好，雖然他明白你所指的缺陷，但就是沒法再現特別
是對系統不熟悉的新加入開發人員，介紹步驟能夠方便他們再現。實際結果可讓開發明白錯誤
是什麼，指望結果可讓開發瞭解正確的結果應該是如何。

1八、黑盒測試和白盒測試是軟件測試的兩種基本方法，請分別說明各自的優勢和缺點！

黑盒測試的優勢有：
比較簡單，不須要了解程序內部的代碼及實現；
與軟件的內部實現無關；
從用戶角度出發，能很容易的知道用戶會用到哪些功能，會遇到哪些問題；
基於軟件開發文檔，因此也能知道軟件實現了文檔中的哪些功能；在作軟件自動化測試時較爲方便。

黑盒測試的缺點有：
不可能覆蓋全部的代碼，覆蓋率較低，大概只能達到總代碼量的30%；
自動化測試的複用性較低。

白盒測試的優勢有：
幫助軟件測試人員增大代碼的覆蓋率，提升代碼的質量，發現代碼中隱 藏的問題。

白盒測試的缺點有：
程序運行會有不少不一樣的路徑，不可能測試全部的運行路徑；
測試基於代碼，只能測試開發人員作的對不對，而不能知道設計的正確與否，可能會漏掉一些功能需求；
系統龐大時，測試開銷會很是大。

1九、如何測試一個紙杯？

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

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

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

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

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

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

用戶文檔：使用手冊是否對杯子的用法、限制、使用條件等有詳細描述

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

時檢查泄漏時間和狀況等

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

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

1）等價類劃分：
等價類是指某個輸入域的子集合.在該子集合中,各個輸入數據對於揭露程序中

的錯誤都是等效的.併合理地假定:測試某等價類的表明值就等於對這一類其它值的測試.所以,可

以把所有輸入數據合理劃分爲若干等價類,在每個等價類中取一個數據做爲測試的輸入條件,就

能夠用少許表明性的測試數據.取得較好的測試結果.等價類劃分可有兩種不一樣的狀況:有效等價類

和無效等價類.

2）邊界值分析法：
是對等價類劃分方法的補充。測試工做經驗告訴我,大量的錯誤是發生在輸入

或輸出範圍的邊界上,而不是發生在輸入輸出範圍的內部.所以針對各類邊界狀況設計測試用例,可

以查出更多的錯誤.

使用邊界值分析方法設計測試用例,首先應肯定邊界狀況.一般輸入和輸出等價類的邊界,就是應着

重測試的邊界狀況.應當選取正好等於,剛剛大於或剛剛小於邊界的值做爲測試數據,而不是選取等

價類中的典型值或任意值做爲測試數據.

3）錯誤猜想法：
基於經驗和直覺推測程序中全部可能存在的各類錯誤, 從而有針對性的設計測試用例的方法.

錯誤推測方法的基本思想: 列舉出程序中全部可能有的錯誤和容易發生錯誤的特殊狀況,根據他們

選擇測試用例. 例如, 在單元測試時曾列出的許多在模塊中常見的錯誤. 之前產品測試中曾經發

現的錯誤等, 這些就是經驗的總結. 還有, 輸入數據和輸出數據爲0的狀況. 輸入表格爲空格或輸

入表格只有一行. 這些都是容易發生錯誤的狀況. 可選擇這些狀況下的例子做爲測試用例.

4）因果圖方法：
前面介紹的等價類劃分方法和邊界值分析方法,都是着重考慮輸入條件,但未考慮

輸入條件之間的聯繫, 相互組合等. 考慮輸入條件之間的相互組合,可能會產生一些新的狀況. 但

要檢查輸入條件的組合不是一件容易的事情, 即便把全部輸入條件劃分紅等價類,他們之間的組合

狀況也至關多. 所以必須考慮採用一種適合於描述對於多種條件的組合,相應產生多個動做的形式

來考慮設計測試用例. 這就須要利用因果圖（邏輯模型）. 因果圖方法最終生成的就是斷定表.

它適合於檢查程序輸入條件的各類組合狀況.

5）正交表分析法：可能由於大量的參數的組合而引發測試用例數量上的激增，同時，這些測試用

例並無明顯的優先級上的差距，而測試人員又沒法完成這麼多數量的測試，就能夠經過正交表

來進行縮減一些用例，從而達到儘可能少的用例覆蓋儘可能大的範圍的可能性。

6）場景分析方法：指根據用戶場景來模擬用戶的操做步驟，這個比較相似因果圖，可是可能執行

的深度和可行性更好。

7）狀態圖法：
經過輸入條件和系統需求說明獲得被測系統的全部狀態，經過輸入條件和狀態得出

輸出條件；經過輸入條件、輸出條件和狀態得出被測系統的測試用例。

8）大綱法：
大綱法是一種着眼於需求的方法，爲了列出各類測試條件，就將需求轉換爲大綱的形

式。大綱表示爲樹狀結構，在根和每一個葉子結點之間存在惟一的路徑。大綱中的每條路徑定義了

一個特定的輸入條件集合，用於定義測試用例。樹中葉子的數目或大綱中的路徑給出了測試全部

功能所需測試用例的大體數量。