最新面試題目分享
你在測試中發現了一個bug，但是開發經理認為這不是一個bug，你應該怎樣解決？
首先，將問題提交到缺陷管理庫進行備案。
然后，要獲取判斷的依據和標准：
根絕需求說明書，產品說明、設計文檔等，確認實際結果是否與計划有不一致的地方，提供缺陷是都確認的直接依據；
如果沒有文檔依據，根據類似軟件的一般特性來說明是否存在不一致的地方，來確認是否是缺陷；
根據用戶的一般使用習慣，來確認是否是缺陷；
與設計人員，開發人員和客戶代表等相關人員探討，確認是否是缺陷；
合理論述，客觀嚴謹的向測試經理說明自己的判斷理由；
等待測試經歷做出最終決定，如果仍然存在爭議，可以通過公司政策所提供的渠道，向上級反應，並由上級做出決定
2、給你一個網站，你如何測試？
首先，查找需求說明、網站設計等相關文檔，分析測試需求；
制定測試計划，確定測試范圍和測試策略，一般包括以下及部分，功能性測試、界面測試、性能測試、數據庫測試、安全性測試、兼容性測試；
設計測試用例：
功能測試（包括不限於）：
鏈接測試。鏈接是否正確跳轉，是否存在空頁面和無效頁面，是否有不正確的出錯信息返回
瀏覽器兼容：是否都可以打開 鏈接配置類型是否都可以支持
提交功能的測試
多媒體元素是否可以正確加載和顯示
多語言支持是否能夠正確顯示選擇的語言
界面測試（包括但不限於）：
頁面是否風格統一，美觀
頁面布局是否合理，重點內容和熱點內容是否突出
空間是否正常使用
對於必須但未安裝的控件，是否提供自動下載並安裝的功能
文字檢查
性能測試：
壓力測試
負載測試
強度測試
數據庫測試：
具體決定是否需要展開。數據庫一般需要考慮連結性，對數據的存取操作，數據內容的驗證等方面。
安全性測試：
基本的登陸功能的檢查
是否存在溢出錯誤，導致系統崩潰或者權限泄露
相關開發語言的常見安全性問題檢查，例如：SQL注入
如果需要高級的安全性問題，確定獲得專業安全公司的幫助，外包測試，或者獲取支持
兼容性測試，根據需求說明的內容，確定支持的平台組合：
瀏覽器的兼容性
操作系統的兼容性
軟件平台的兼容性
數據庫的兼容性
開展測試，並記錄缺陷，合理的安排調整測試進度，提前獲取測試所需的資源，建立管理體系（例如：需求變更，風險，配置，測試文檔，缺陷報告，人力資源等內容）
定期評審，對測試進行評估和總結，調整測試內容
3、在搜索引擎中輸入漢字就可以解析到對應的域名，請問如何使用LoadRunner進行測試
建立測試計划，確定測試標准和測試范圍
設計典型場景的測試用例，都改常用業務流程和不常用的業務流程等
根據測試用例，開發自動化測試腳本和場景
錄制測試腳本：新建一個腳本（Web/HTML協議）；點擊錄制按鈕，在彈出的對話框的URL中輸入”about:blank”；在打開的瀏覽器中進行正常操作流程后，結束錄制；調試腳本並保存，可能要注意到字符集的關聯。
設置測試場景：針對性能設置測試場景，主要判斷在正常情況下，系統的平均事務響應時間是否達標；針對壓力負載設置測試場景，主要判斷在長時間處於滿負荷或者超出系統承載能力的條件下，系統是否會崩潰；執行測試，獲取測試結果，分析測試結果
4、目前主要的測試用例方法是？
白盒測試：路徑覆蓋、代碼 走查、靜態分析
黑盒測試：邊界值分析，等價類划分，錯誤推測法，因果圖，狀態圖法
5、軟件測安全性從哪幾個方面測試？
軟件安全性測試包括：程序、數據庫安全測試
用戶認證安全的測試要考慮問題：明確區分系統中不同用戶權限 、系統中會不會出現用戶沖突 、系統會不會因用戶的權限的改變造成混亂 、用戶登陸密碼是否是可見、可復制 、是否可以通過絕對途徑登陸系統（拷貝用戶登陸后的鏈接直接進入系統）、用戶退出系統后是否刪除了所有鑒權標記，是否可以使用后退鍵而不通過輸入口令進入 系統 、系統網絡安全的測試要考慮問題 、測試采取的防護措施是否正確裝配好，有關系統的補丁是否打上 、模擬非授權攻擊，看防護系統是否堅固 、采用成熟的網絡漏洞檢查工具檢查系統相關漏洞（即用最專業的黑客攻擊工具攻擊試一下，現在最常用的是 NBSI 系列和 IPhacker IP ） 、采用各種木馬檢查工具檢查系統木馬情況 、采用各種防外掛工具檢查系統各組程序的外掛漏洞
數據庫安全考慮問題：系統數據是否機密、系統數據的完整性 、系統數據可管理性 、系統數據的獨立性 、系統數據可備份和恢復能力（數據備份是否完整，可否恢復，恢復是否可以完整）
6、什么是測試用例？什么是測試腳本？兩者關系？
測試用例：為實現測試而向被測試系統提供的輸入數據、操作或各種環境設置以及期望結果的一個特定的合集
A
測試腳本：為了進行自動化測試而編寫的腳本
關系：測試腳本的編寫必須對應相應的測試用例
7、簡述：靜態測試、動態測試、黑盒測試、白盒測試、α測試 、β測試
靜態測試：不運行程序本身而尋找程序代碼中可能存在的錯誤或評估程序代碼的過程
動態測試：實際運行被測程序，輸入相應的測試實例，檢查運行結果與預期結果的差異，判定執行結果是否符合要求，從而檢測程序的正確性、可靠性、有效性、並分析系統運行效率和健壯性等性能
黑盒測試：一般用來確認軟件功能的正確性和可操作性，目的是檢測軟件的各個功能是否得以實現，把被測程序當作一個黑盒，不考慮其內部結構,在知道該程序的輸入和輸出之間的關系或程序功能的情況下,依靠軟件規格說明書來確定測試用例和推斷測試結果的正確性
白盒測試：根據軟件內部的邏輯結構分析來進行測試,是基於代碼的測試，測試人員通過閱讀程序代碼或者通過使用開發工具中的單步調試來判斷軟件的質量，一般黑盒測試由項目經理在程序員開發中來實現。
α測:由一個用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操作環境下進行的受控測試，Alpha測試不能由程序員或測試員完成
β測試: 軟件的多個用戶在一個或多個用戶的實際使用環境下進行的測試，開發者通常不在測試現場，Beta測試不能由程序員或測試員完成
8、軟件測試分為幾個階段，各階段的測試策略和要求是什么？
和開發過程相對應，測試過程會依次經歷單元測試、集成測試、系統測試、驗收測試四個主要階段：
單元測試：單元測試是針對軟件設計的最小單位––程序模塊甚至代碼段進行正確性檢驗的測試工作，通常由開發人員進行。
集成測試：集成測試是將模塊按照設計要求組裝起來進行測試，主要目的是發現與接口有關的問題。由於在產品提交到測試部門前，產品開發小組都要進行聯合調試，因此在大部分企業中集成測試是由開發人員來完成的。
系統測試：系統測試是在集成測試通過后進行的，目的是充分運行系統，驗證各子系統是否都能正常工作並完成設計的要求。它主要由測試部門進行，是測試部門最大最重要的一個測試，對產品的質量有重大的影響。
驗收測試：驗收測試以需求階段的《需求規格說明書》為驗收標准，測試時要求模擬實際用戶的運行環境。對於實際項目可以和客戶共同進行，對於產品來說就是最后一次的系統測試。測試內容為對功能模塊的全面測試，尤其要進行文檔測試。
單元測試測試策略：
自頂向下的單元測試策略：比孤立單元測試的成本高很多，不是單元測試的一個好的選擇。
自底向上的單元測試策略：比較合理的單元測試策略，但測試周期較長。
孤立單元測試策略：最好的單元測試策略。
集成測試的測試策略：
大爆炸集成：適應於一個維護型項目或被測試系統較小
自頂向下集成：適應於產品控制結構比較清晰和穩定；高層接口變化較小；底層接口未定義或經常可能被修改；產口控制組件具有較大的技術風險，需要盡早被驗證；希望盡早能看到產品的系統功能行為。
自底向集成：適應於底層接口比較穩定；高層接口變化比較頻繁；底層組件較早被完成。
基於進度的集成
優點：具有較高的並行度；能夠有效縮短項目的開發進度。
缺點：樁和驅動工作量較大；有些接口測試不充分；有些測試重復和浪費。
系統測試的測試策略：
數據和數據庫完整性測試；功能測試；用戶界面測試；性能評測；負載測試；強度測試；容量測試；安全性和訪問控制測試；故障轉移和恢復測試；配置測試；安裝測試；加密測試；可用性測試；版本驗證測試；文檔測試
9、測試人員在軟件開發過程中的任務是什么？
1、盡可能早的找出系統中的Bug；
2、避免軟件開發過程中缺陷的出現；
3、衡量軟件的品質，保證系統的質量；
4、關注用戶的需求，並保證系統符合用戶需求。
總的目標是：確保軟件的質量。
10、在您以往的工作中，一條軟件缺陷（或者叫Bug）記錄都包含了哪些內容？如何提交高質量的軟件缺陷（Bug）記錄？
一條Bug記錄最基本應包含：
bug編號；
bug嚴重級別，優先級；
bug產生的模塊；
首先要有bug摘要，闡述bug大體的內容；
bug對應的版本；
bug詳細現象描述，包括一些截圖、錄像....等等；
bug出現時的測試環境，產生的條件即對應操作步驟；
高質量的Bug記錄：
1) 通用UI要統一、准確
缺陷報告的UI要與測試的軟件UI保持一致，便於查找定位。
2) 盡量使用業界慣用的表達術語和表達方法
使用業界慣用的表達術語和表達方法，保證表達准確，體現專業化。
3) 每條缺陷報告只包括一個缺陷
每條缺陷報告只包括一個缺陷，可以使缺陷修正者迅速定位一個缺陷，集中精力每次只修正一個缺陷。校驗者每次只校驗一個缺陷是否已經正確修正。
4) 不可重現的缺陷也要報告
首先缺陷報告必須展示重現缺陷的能力。不可重現的缺陷要盡力重現，若盡力之后仍不能重現，仍然要報告此缺陷，但在報告中要注明無法再現，缺陷出現的頻率。
5) 明確指明缺陷類型
根據缺陷的現象，總結判斷缺陷的類型。例如，即功能缺陷、界面缺陷、數據缺陷，合理化建議這是最常見的缺陷或缺陷類型，其他形式的缺陷或缺陷也從屬於其中某種形式。
6) 明確指明缺陷嚴重等級和優先等級
時刻明確嚴重等級和優先等級之間的差別。高嚴重問題可能不值得解決，小裝飾性問題可能被當作高優先級。
7) 描述 (Description) ，簡潔、准確，完整，揭示缺陷實質，記錄缺陷或缺陷出現的位置
描述要准確反映缺陷的本質內容，簡短明了。為了便於在軟件缺陷管理數據庫中尋找制定的測試缺陷，包含缺陷發生時的用戶界面（UI）是個良好的習慣。例如記錄對話框的標題、菜單、按鈕等控件的名稱。
8) 短行之間使用自動數字序號，使用相同的字體、字號、行間距
短行之間使用自動數字序號，使用相同的字體、字號、行間距，可以保證各條記錄格式一致，做到規范專業。
9) 每一個步驟盡量只記錄一個操作
保證簡潔、條理井然，容易重復操作步驟。
10) 確認步驟完整，准確，簡短
保證快速准確的重復缺陷，“完整”即沒有缺漏，“准確”即步驟正確，“簡短”即沒有多余的步驟。
11) 根據缺陷，可選擇是否進行圖象捕捉
為了直觀的觀察缺陷或缺陷現象，通常需要附加缺陷或缺陷出現的界面，以圖片的形式作為附件附着在記錄的“附件”部分。為了節省空間，又能真實反映缺陷或缺陷本質，可以捕捉缺陷或缺陷產生時的全屏幕，活動窗口和局部區域。為了迅速定位、修正缺陷或缺陷位置，通常要求附加中文對照圖。
? 附加必要的特殊文檔和個人建議和注解
如果打開某個特殊的文檔而產生的缺陷或缺陷，則必須附加該文檔，從而可以迅速再現缺陷或缺陷。有時，為了使缺陷或缺陷修正者進一步明確缺陷或缺陷的表現，可以附加個人的修改建議或注解。
12) 檢查拼寫和語法缺陷
在提交每條缺陷或缺陷之前，檢查拼寫和語法，確保內容正確，正確的描述缺陷。
13) 盡量使用短語和短句，避免復雜句型句式
軟件缺陷管理數據庫的目的是便於定位缺陷，因此，要求客觀的描述操作步驟，不需要修飾性的詞匯和復雜的句型，增強可讀性。
以上概括了報告測試缺陷的規范要求，隨着軟件的測試要求不同，測試者經過長期測試，積累了相應的測試經驗，將會逐漸養成良好的專業習慣，不斷補充新的規范書寫要求。此外，經常閱讀、學習其他測試工程師的測試缺陷報告，結合自己以前的測試缺陷報告進行對比和思考，可以不斷提高技巧。
14) 缺陷描述內容
缺陷描述的內容可以包含缺陷操作步驟，實際結果和期望結果。操作步驟可以方便開發人員再現缺陷進行修正，有些開發的再現缺陷能力很差，雖然他明白你所指的缺陷，但就是無法再現特別是對系統不熟悉的新加入開發人員，介紹步驟可以方便他們再現。實際結果可以讓開發明白錯誤是什么，期望結果可以讓開發了解正確的結果應該是如何。
11、黑盒測試和白盒測試是軟件測試的兩種基本方法，請分別說明各自的優點和缺點！
黑盒測試
優點：比較簡單，不需要了解程序內部的代碼及實現；與軟件的內部實現無關； 從用戶角度出發，能很容易的知道用戶會用到哪些功能，會遇到哪些問題；基於軟件開發文檔，所以也能知道軟件實現了文檔中的哪些功能；在做軟件自動化測試時較為方便。
缺點：不可能覆蓋所有的代碼，覆蓋率較低，大概6只能達到總代碼量的30%；自動化測試的復用性較低。
白盒測試
優點：幫助軟件測試人員增大代碼的覆蓋率，提高代碼的質量，發現代碼中隱 藏的問題。
缺點：程序運行會有很多不同的路徑，不可能測試所有的運行路徑；測試基於代碼，只能測試開發人員做的對不對，而不能知道設計的正確與否，可能會漏掉一些功能需求；系統龐大時，測試開銷會非常大。
12、如何測試一個紙杯？
用戶文檔：使用手冊是否對杯子的用法、限制、使用條件等有詳細描述
功能度：用水杯裝水看漏不漏；水能不能被喝到
安全性：杯子有沒有毒或細菌
可靠性：杯子從不同高度落下的損壞程度
可移植性：杯子在不同的地方、溫度等環境下是否都可以正常使用
兼容性：杯子是否能夠容納果汁、白水、酒精、汽油等
易用性：杯子是否燙手、是否有防滑措施、是否方便飲用
疲勞測試：將杯子盛上水（案例一）放24小時檢查泄漏時間和情況；盛上汽油（案例二）放24小時檢查泄漏時間和情況等
壓力測試：用根針並在針上面不斷加重量，看壓強多大時會穿透
13、測試計划工作的目的是什么？測試計划文檔的內容應該包括什么？其中哪些是最重要的？
軟件測試計划是指導測試過程的綱領性文件：
領導能夠根據測試計划進行宏觀調控，進行相應資源配置等
測試人員能夠了解整個項目測試情況以及項目測試不同階段的所要進行的工作等
便於其他人員了解測試人員的工作內容，進行有關配合工作
包含了產品概述、測試策略、測試方法、測試區域、測試配置、測試周期、測試資源、測試交流、風險分析等內容。借助軟件測試計划，參與測試的項目成員，尤其是測試管理人員，可以明確測試任務和測試方法，保持測試實施過程的順暢溝通，跟蹤和控制測試進度，應對測試過程中的各種變更。
測試計划編寫6要素（5W1H）：
why——為什么要進行這些測試；
what—測試哪些方面，不同階段的工作內容；
when—測試不同階段的起止時間；
where—相應文檔，缺陷的存放位置，測試環境等；
who—項目有關人員組哪些測試人員進行測試；
how—如何去做，使用哪些測試工具以及測試方法進行測試
測試計划和測試詳細規格、測試用例之間是戰略和戰術的關系，測試計划主要從宏觀上規划測試活動的范圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。所以其中最重要的是測試測試策略和測試方法（最好是能先評審）。
14、詳細的描述一個測試活動完整的過程
（以瀑布模型為例）
項目經理通過和客戶的交流，完成需求文檔，由開發人員和測試人員共同完成需求文檔的評審，評審的內容包括：需求描述不清楚的地方和可能有明顯沖突或者無法實現的功能的地方。項目經理通過綜合開發人員，測試人員以及客戶的意見，完成項目計划。然后SQA進入項目，開始進行統計和跟蹤
開發人員根據需求文檔完成需求分析文檔，測試人員進行評審，評審的主要內容包括是否有遺漏或雙方理解不同的地方。測試人員完成測試計划文檔，測試計划包括的內容上面有描述。
測試人員根據修改好的需求分析文檔開始寫測試用例，同時開發人員完成概要設計文檔，詳細設計文檔。此兩份文檔成為測試人員撰寫測試用例的補充材料。
測試用例完成后，測試和開發需要進行評審。
測試人員搭建環境
開發人員提交第一個版本，可能存在未完成功能，需要說明。測試人員進行測試，發現BUG后提交給BugZilla。
開發提交第二個版本，包括Bug Fix以及增加了部分功能，測試人員進行測試。
重復上面的工作，一般是3-4個版本后BUG數量減少，達到出貨的要求。
如果有客戶反饋的問題，需要測試人員協助重現並重新測試。
15、BUG管理工具的跟蹤過程（用BugZilla為例子）
測試人員發現了BUG，提交到Bugzilla中，狀態為new，BUG的接受者為開發接口人員
開發接口將BUG分配給相關的模塊的開發人員，狀態修改為已分配，開發人員和測試確認BUG，如果是本人的BUG，則設置為接收；如果是別的開發人員的問題，則轉發出去，由下一個開發人員來進行此行為；如果認為不是問題，則需要大家討論並確認后，拒絕這個BUG，然后測試人員關閉此問題。
如果開發人員接受了BUG，並修改好以后，將BUG狀態修改為已修復，並告知測試在哪個版本中可以測試。
2
測試人員在新版本中測試，如果發現問題依然存在，則拒絕驗證；如果已經修復，則關閉BUG。
16、軟件產品質量特性是什么?
功能性：適應性、准確性、互操作性、依從性、安全性。
可靠性：成熟性、容錯性、易恢復性。
可使用性：易理解性、易學習性、易操作性。
效率：時間特性、資源特性。
可維護性：易分析性、易變更性、穩定性、易測試性。
可移植性：適應性、易安裝性、遵循性、易替換性
17、一台客戶端有三百個客戶與三百個客戶端有三百個客戶對服務器施壓，有什么區別?
300個用戶在一個客戶端上，會占用客戶機更多的資源，而影響測試的結果。線程之間可能發生干擾，而產生一些異常。
300個用戶在一個客戶端上，需要更大的帶寬。
IP地址的問題，可能需要使用IP Spoof來繞過服務器對於單一IP地址最大連接數的限制。
所有用戶在一個客戶端上，不必考慮分布式管理的問題；而用戶分布在不同的客戶端上，需要考慮使用控制器來整體調配不同客戶機上的用戶。同時，還需要給予相應的權限配置和防火牆設置。
18、試述軟件的概念和特點？軟件復用的含義？構件包括哪些？
軟件是計算機系統中與硬件相互依存的另一部分，與計算機系統操作有關的計算機程序、規程、規則，以及可能有的文件、文檔及數據。
軟件復用(SoftWare Reuse)是將已有軟件的各種有關知識用於建立新的軟件，以縮減軟件開發和維護的花費。軟件復用是提高軟件生產力和質量的一種重要技術。早期的軟件復用主要是代碼級復用，被復用的知識專指程序，后來擴大到包括領域知識、開發經驗、設計決定、體系結構、需求、設計、代碼和文檔等一切有關方面。
可以被復用的軟件成分一般稱作可復用構件
19、軟件生存周期及其模型是什么？
軟件生存周期（Software life cycle）又稱為軟件生命周期，生存期。是指從形成開發軟件概念起，所開發的軟件使用以后，直到失去使用價值消亡為止的整個過程。一般來說，整個生存周期包括，計划、開發、運行（維護）三個時期，每個時期又划分為若干個階段，每個階段有明確的任務。
周期模型（典型的幾種）：
瀑布模型
快速原型模型：快速原型模型允許在需求分析階段對軟件的需求進行初步而非完全的分析和定義，快速設計開發出軟件系統的原型，該原型向用戶展示待開發軟件的全部或部分功能和性能；用戶對該原型進行測試評定，給出具體改進意見以豐富細化軟件需求；開發人員據此對軟件進行修改完善，直至用戶滿意認可之后，進行軟件的完整實現及測試、維護。
迭代模型：迭代包括產生產品發布（穩定、可執行的產品版本）的全部開發活動和要使用該發布必需的所有其他外圍元素。在某種程度上，開發迭代是一次 完整地經過所有工作流程的過程：需求分析、設計、實施和測試工作流程。實質上，它類似小型的瀑布式項目。RUP認為，所有的階段都可以細分為迭代。每一次 的迭代都會產生一個可以發布的產品，這個產品是最終產品的一個子集。
生命周期階段：
軟件計划與可行性分析
需求分析
軟件設計
編碼
軟件測試
運行與維護