1.問：你在測試中發現了一個 bug ，但是開發經理認為這不是一個 bug ，你應該怎樣解決。
- 首先，將問題提交到缺陷管理庫里面進行備案。
- 然后，要獲取判斷的依據和標準：
- 根據需求說明書、產品說明、設計文檔等，確認實際結果是否與計劃有不一致的地方，提供缺陷是否確認的直接依據；
- 如果沒有文檔依據，可以根據類似軟件的一般特性來說明是否存在不一致的地方，來確認是否是缺陷；
- 根據用戶的一般使用習慣，來確認是否是缺陷；
- 與設計人員、開發人員和客戶代表等相關人員探討，確認是否是缺陷；
- 合理的論述，向測試經理說明自己的判斷的理由，注意客觀、嚴謹，不參雜個人情緒。
- 等待測試經理做出最終決定，如果仍然存在爭議，可以通過公司政策所提供的渠道，向上級反映，并由上級做出決定。
2.問：給你一個網站，你如何測試？
- 首先，查找需求說明、網站設計 m 等相關文檔，分析測試需求。
- 制定測試計劃，確定測試范圍和測試策略，一般包括以下幾個部分：
功能性測試；界面測試；性能測試；數據庫測試；安全性測試；兼容性測試 - 設計測試用例：
功能性測試可以包括，但不限于以下幾個方面：
- 鏈接測試。鏈接是否正確跳轉，是否存在空頁面和無效頁面，是否有不正確的出錯信息返回等。
- 提交功能的測試。
多媒體元素是否可以正確加載和顯示。
多語言支持是否能夠正確顯示選擇的語言等。 - 界面測試可以包括但不限于一下幾個方面：
頁面是否風格統一，美觀
頁面布局是否合理，重點內容和熱點內容是否突出
控件是否正常使用
對于必須但為安裝的空間，是否提供自動下載并安裝的功能
文字檢查 - 性能測試一般從以下兩個方面考慮：
壓力測試；負載測試；強度測試 - 數據庫測試要具體決定是否需要開展。數據庫一般需要考慮連結性，對數據的存取操作，數據內容的驗證等方面。
- 安全性測試：
1 基本的登錄功能的檢查
2 是否存在溢出錯誤，導致系統崩潰或者權限泄露
3 相關開發語言的常見安全性問題檢查，例如 SQL 注入等。
4 如果需要高級的安全性測試，確定獲得專業安全公司的幫助，外包測試，或者獲取支持 - 兼容性測試，根據需求說明的內容，確定支持的平臺組合：
瀏覽器的兼容性；操作系統的兼容性；軟件平臺的兼容性；數據庫的兼容性
- 開展測試，并記錄缺陷。合理的安排調整測試進度，提前獲取測試所需的資源，建立管理體系（例如，需求變更、風險、配置、測試文檔、缺陷報告、人力資源等內容）。
- 定期評審，對測試進行評估和總結，調整測試的內容。
3.在搜索引擎中輸入漢字就可以解析 到對應的域名，請問如何用 LoadRunner 進行測試。
- 建立測試計劃，確定測試標準和測試范圍
- 設計典型場景的測試用例，覆蓋常用業務流程和不常用的業務流程等
- 根據測試用例，開發自動測試腳本和場景：
錄制測試腳本
新建一個腳本（Web/HTML 協議）
點擊錄制按鈕，在彈出的對話框的 URL 中輸入”about:blank”。
在打開的瀏覽器中進行正常操作流程后，結束錄制。
調試腳本并保存。可能要注意到字符集的關聯。 - 設置測試場景
針對性能設置測試場景，主要判斷在正常情況下，系統的平均事務響應時間是否達標
針對壓力負載設置測試場景，主要判斷在長時間處于滿負荷或者超出系統承載能力的條件下，系統是否會崩潰。 - 執行測試，獲取測試結果，分析測試結果
4.問：一臺客戶端有三百個客戶與三百個客戶端有三百個客戶對服務器施壓，有什么區別? ?
300 個用戶在一個客戶端上，會占用客戶機更多的資源，而影響測試的結果。
線程之間可能發生干擾，而產生一些異常。
300 個用戶在一個客戶端上，需要更大的帶寬。
IP 地址的問題，可能需要使用 IP Spoof 來繞過服務器對于單一 IP 地址最大連接數的限制。
所有用戶在一個客戶端上，不必考慮分布式管理的問題；而用戶分布在不同的客戶端上，需要考慮使用控制器來整體調配不同客戶機上的用戶。同時，還需要給予相應的權限配置和防火墻設置。
5.試述軟件的概念和特點？軟件復用的含義？構件包括哪些？
- 軟件是計算機系統中與硬件相互依存的另一部分，它是包括程序、文檔的完整集合。
- 軟件復用(Software Reuse)是將已有軟件的各種有關知識用于建立新的軟件,以縮減軟件開發和維護的花費。軟件復用是提高軟件生產力和質量的一種重要技術。早期的軟件復用主要是代碼級復用，被復用的知識專指程序，后來擴大到包括領域知識、開發經驗、設計決定、體系結構、需求、設計、代碼和文檔等一切有關方面。
- 可以被復用的軟件成分一般稱作可復用構件
6.軟件生存周期及其模型是什么？
軟件生存周期是軟件開發全部過程、活動和任務的結構框架，是從可行性研究到需求分析、軟件設計、編碼、測試、軟件發布維護的過程。
在經歷需求、分析、設計、實現、部署后，軟件將被使用并進入維護階段，直到最后由于缺少維護費用而逐漸消亡。這樣的一個過程，稱為"生命周期模型"（Life Cycle Model）。
7.什么是軟件測試？軟件測試的目的與原則
- 使用人工或自動手段，來運行或測試某個系統的過程。其目的在于檢驗它是否滿足規定的需求或弄清預期結果與實際結果之間的差別。
- 軟件測試的目的：
測試是程序的執行過程，目的在于發現錯誤
確保產品滿足用戶需求（功能，性能，兼容性等）
確保產品是健壯的和適應用戶環境的 - 軟件測試的原則：
教材的說法：
軟件測試應盡早執行，并貫穿于整個軟件生命周期
軟件測試應追溯需求
測試應由第三方來構造
窮舉測試是不可能的,要遵循 Good-enough 原則
必須確定預期輸出（或結果）
必須徹底檢查每個測試結果
關注缺陷的修復
8.軟件配置管理的作用？軟件配置包括什么？
軟件配置管理作為軟件開發過程的必要環節和軟件開發管理的基礎，貫穿整個軟件生命周期，同時對軟件開發過程的宏觀管理即項目管理也有重要的支持作用。一個軟件開發組織真正有效的實施軟件配置管理，將會使軟件開發過程有更好的可預測性，使系統具有可重復性，大大提高軟件組織的競爭力。
軟件配置包括如下內容：
配置項識別
工作空間管理
版本控制
變更控制
狀態報告
配置審計
9.什么是軟件質量？
軟件質量：軟件產品的特性可以滿足用戶的功能、性能需求的能力。
10.目前主要的測試用例設計方法是什么？
白盒測試：
邏輯覆蓋
循環覆蓋
基本路徑覆蓋
黑盒測試：
邊界值分析法
等價類劃分
錯誤猜測法
因果圖法
狀態圖法
隨機測試
場景法
11.軟件的安全性應從哪幾個方面 去測試？
軟件安全性測試包括程序、數據庫安全性測試。根據系統安全指標不同測試策略也不同。
- 用戶認證安全的測試要考慮問題：
明確區分系統中不同用戶權限
系統中會不會出現用戶沖突
系統會不會因用戶的權限的改變造成混亂 - 用戶登陸密碼是否是可見、可復制
- 是否可以通過絕對途徑登陸系統（拷貝用戶登陸后的鏈接直接進入系統）
- 用戶退出系統后是否刪除了所有鑒權標記，是否可以使用后退鍵而不通過輸入口令進入系統
- 系統網絡安全的測試要考慮問題
測試采取的防護措施是否正確裝配好，有關系統的補丁是否打上
模擬非授權攻擊，看防護系統是否堅固
采用成熟的網絡漏洞檢查工具檢查系統相關漏洞（即用最專業的黑客攻擊工具攻擊試一下，現在最常用的是 NBSI 系列和 IPhacker IP ）
采用各種木馬檢查工具檢查系統木馬情況
采用各種防外掛工具檢查系統各組程序的外掛漏洞 - 數據庫安全考慮問題：
系統數據是否機密（比如對銀行系統，這一點就特別重要，一般的網站就沒有太高要求）
系統數據的完整性
系統數據可管理性
系統數據的獨立性
系統數據可備份和恢復能力（數據備份是否完整，可否恢復，恢復是否可以完整）
12.什么是測試用例 什么是測試腳本 兩者的關系是什么？
為實施測試而向被測試系統提供的輸入數據、操作或各種環境設置以及期望結果的一個特定的集合。
測試腳本是為了進行自動化測試而編寫的腳本。
測試腳本的編寫必須對應相應的測試用例，
13.簡述什么是靜態測試、動態測試、黑盒測試、白盒測試、α測試 β測試
- 靜態測試是不運行程序本身而尋找程序代碼中可能存在的錯誤或評估程序代碼的過程。
- 動態測試是實際運行被測程序，輸入相應的測試實例，檢查運行結果與預期結果的差異，判定執行結果是否符合要求，從而檢驗程序的正確性、可靠性和有效性，并分析系統運行效率和健壯性等性能。
- 黑盒測試一般用來確認軟件功能的正確性和可操作性,目的是檢測軟件的各個功能是否能得以實現,把被測試的程序當作一個黑盒,不考慮其內部結構,在知道該程序的輸入和輸出之間的關系或程序功能的情況下,依靠軟件規格說明書來確定測試用例和推斷測試結果的正確性。
- 白盒測試根據軟件內部的邏輯結構分析來進行測試,是基于代碼的測試，測試人員通過閱讀程序代碼或者通過使用開發工具中的單步調試來判斷軟件的質量，一般黑盒測試由項目經理在程序員開發中來實現。
- α測試是由一個用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操作環境下進行的受控測試，Alpha 測試不能由程序員或測試員完成。
- β測試是軟件的多個用戶在一個或多個用戶的實際使用環境下進行的測試。開發者通常不在測試現場，Beta 測試不能由程序員或測試員完成。
14.軟件質量保證體系是什么 國家標準中與質量保證管理相關的幾個標準是什么? ? 他們的編號和全稱是什么? ?
SQA 由一套軟件工程過程和方法組成，以保證（軟件的）質量。SQA 貫穿整個軟件開發過程，(它)應包括需求文檔評審、代碼控制、代碼評審、變更管理、配置管理、版本管理和軟件測試。
15.軟件產品質量特性是什么? ?
功能性：適應性、準確性、互操作性、依從性、安全性。
可靠性：成熟性、容錯性、以恢復性。
可使用性：易理解性、易學習性、易操作性。
效率：時間特性、資源特性。
可維護性：易分析性、易變更性、穩定性、易測試性。
可移植性： 適應性、易安裝性、遵循性、易替換性。
16.軟件測試的策略是什么? ?
軟件測試策略：在一定的軟件測試標準、測試規范的指導下，依據測試項目的特定環境約束而規定的軟件測試的原則、方式、方法的集合。
17.軟件測試分為幾個 階段 各階段的測試策略和要求是什么? ?
軟件測試按階段劃分可以分為單元測試、集成測試、系統測試和<驗收測試>（不一定有）幾個階段
- 單元測試測試策略：
自頂向下的單元測試策略
總結：比孤立單元測試的成本高很多，不是單元測試的一個好的選擇。
自底向上的單元測試策略
總結：比較合理的單元測試策略，但測試周期較長。
孤立單元測試策略
總結：最好的單元測試策略。 - 集成測試的測試策略：
大爆炸集成
適應于一個維護型項目或被測試系統較小
自頂向下集成
適應于產品控制結構比較清晰和穩定；高層接口變化較小；底層接口未定義或經常可能被修改；產口控制組件具有較大的技術風險，需要盡早被驗證；希望盡早能看到產品的系統功能行為。
自底向上集成
適應于底層接口比較穩定；高層接口變化比較頻繁；底層組件較早被完成。
基于進度的集成
優點：具有較高的并行度；能夠有效縮短項目的開發進度。
缺點：樁和驅動工作量較大；有些接口測試不充分；有些測試重復和浪費。 - 系統測試的測試策略
數據和數據庫完整性測試；功能測試；用戶界面測試；性能評測；負載測試；強度測試；容量測試；安全性和訪問控制測試；故障轉移和恢復測試；配置測試；安裝測試；加密測試；可用性測試；版本驗證測試；文檔測試
18.在軟件測試各個階段通常完成什么工作？各個階段的結果文件是什么？包括什么內容？
- 單元測試階段。各獨立單元模塊在與系統地其他部分相隔離的情況下進行測試，單元測試針對每一個程序模塊進行正確性校驗，檢查各個程序模塊是否正確地實現了規定的功能。
生成單元測試報告，提交缺陷報告。 - 集成測試階段。集成測試是在單元測試的基礎上，測試在將所有的軟件單元按照概要設計規格說明的要求組裝成模塊、子系統或系統的過程中各部分工作是否達到或實現相應技術指標及要求的活動。
該階段生成集成測試報告，提交缺陷報告。 - 系統測試階段。將通過確認測試的軟件，作為整個給予計算機系統的一個元素，與計算機硬件、外設、某些支持軟件、數據和人員等其他系統元素結合在一起，在實際運行環境下，對計算機系統進行全面的功能覆蓋。該階段需要提交測試總結和缺陷報告。
19.測試人員在軟件開發過程中的任務是什么？
1、尋找 Bug；
2、避免軟件開發過程中的缺陷；
3、衡量軟件的品質；
4、關注用戶的需求。
總的目標是：確保軟件的質量。
20.在您以往的工作中，一條軟件缺陷（或者叫 Bug）記錄都包含了哪些內容？如何提交高質量的軟件缺陷（Bug）記錄？
- 一條 Bug 記錄最基本應包含：編號、Bug 所屬模塊、Bug 描述、Bug 級別、發現日期、發現人、修改日期、修改人、修改方法、回歸結果等等；
- 要有效的發現 Bug 需參考需求以及詳細設計等前期文檔設計出高效的測試用例，然后嚴格執行測試用例，對發現的問題要充分確認肯定，然后再向外發布如此才能提高提交 Bug 的質量。
21.黑盒測試和白盒測試是軟件測試的兩種基本方法，請分別說明各自的優點和缺點！
- 黑盒測試的優點有：
比較簡單，不需要了解程序內部的代碼及實現；
與軟件的內部實現無關；
從用戶角度出發，能很容易的知道用戶會用到哪些功能，會遇到哪些問題；
基于軟件開發文檔，所以也能知道軟件實現了文檔中的哪些功能；
在做軟件自動化測試時較為方便。
黑盒測試的缺點有：
不可能覆蓋所有的代碼，覆蓋率較低，大概只能達到總代碼量的 30%；
自動化測試的復用性較低。 - 白盒測試的優點有：
幫助軟件測試人員增大代碼的覆蓋率，提高代碼的質量，發現代碼中隱藏的問題。
白盒測試的缺點有：
程序運行會有很多不同的路徑，不可能測試所有的運行路徑；
測試基于代碼，只能知道測試開發人員做的對不對，而不能知道設計的正確與否，可能會漏掉一些功能需求；
系統龐大時，測試開銷會非常大。
21.測試計劃工作的目的是什么？測試計劃文檔的內容應該包括什么？其中哪些是最重要的？
答案：軟件測試計劃是指導測試過程的綱領性文件。
包含了產品概述、測試策略、測試方法、測試區域、測試配置、測試周期、測試資源、測試交流、風險分析等內容。借助軟件測試計劃，參與測試的項目成員，尤其是測試管理人員，可以明確測試任務和測試方法，保持測試實施過程的順暢溝通，跟蹤和控制測試進度，應對測試過程中的各種變更。
測試計劃和測試詳細規格、測試用例之間是戰略和戰術的關系，測試計劃主要從宏觀上規劃測試活動的范圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。
所以其中最重要的是測試測試策略和測試方法（最好是能先評審）。
22.黑盒測試的測試用例常見設計方法都有哪些？請分別以具體的例子來說明這些方法在測試用例設計工作中的應用。
- 等價類劃分
劃分等價類: 等價類是指某個輸入域的子集合.在該子集合中,各個輸入數據對于揭露程序中的錯誤都是等效的.并合理地假定:測試某等價類的代表值就等于對這一類其它值的測試.
因此,可以把全部輸入數據合理劃分為若干等價類,在每一個等價類中取一個數據作為測試的輸入條件,就可以用少量代表性的測試數據.取得較好的測試結果.等價類劃分可有兩種不同的情況:有效等價類和無效等價類. - 邊界值分析法
邊界值分析方法是對等價類劃分方法的補充。測試工作經驗告訴我,大量的錯誤是發生在輸入或輸出范圍的邊界上,而不是發生在輸入輸出范圍的內部.因此針對各種邊界情況設計測試用例,可以查出更多的錯誤.
使用邊界值分析方法設計測試用例,首先應確定邊界情況.通常輸入和輸出等價類的邊界,就是應著重測試的邊界情況.應當選取正好等于,剛剛大于或剛剛小于邊界的值作為測試數據,而不是選取等價類中的典型值或任意值作為測試數據. - 錯誤猜測法
基于經驗和直覺推測程序中所有可能存在的各種錯誤, 從而有針對性的設計測試用例的方法.
錯誤推測方法的基本思想: 列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況,根據他們選擇測試用例. 例如, 在單元測試時曾列出的許多在模塊中常見的錯誤. 以前產品測試中曾經發現的錯誤等, 這些就是經驗的總結. 還有, 輸入數據和輸出數據為 0 的情況.輸入表格為空格或輸入表格只有一行. 這些都是容易發生錯誤的情況. 可選擇這些情況下的例子作為測試用例. - 因果圖方法
前面介紹的等價類劃分方法和邊界值分析方法,都是著重考慮輸入條件,但未考慮輸入條件之間的聯系, 相互組合等. 考慮輸入條件之間的相互組合,可能會產生一些新的情況. 但要檢查輸入條件的組合不是一件容易的事情, 即使把所有輸入條件劃分成等價類,他們之間的組合情況也相當多. 因此必須考慮采用一種適合于描述對于多種條件的組合,相應產生多個動作的形式來考慮設計測試用例. 這就需要利用因果圖（邏輯模型）. 因果圖方法最終生成的就是判定表. 它適合于檢查程序輸入條件的各種組合情況. - 正交表分析法
有時候，可能因為大量的參數的組合而引起測試用例數量上的激增，同時，這些測試用例并沒有明顯的優先級上的差距，而測試人員又無法完成這么多數量的測試，就可以通過正交表來進行縮減一些用例，從而達到盡量少的用例覆蓋盡量大的范圍的可能性。 - 場景分析方法
指根據用戶場景來模擬用戶的操作步驟，這個比較類似因果圖，但是可能執行的深度和可行性更好。 - 狀態圖法
通過輸入條件和系統需求說明得到被測系統的所有狀態，通過輸入條件和狀態得出輸出條件；通過輸入條件、輸出條件和狀態得出被測系統的測試用例。
23.詳細的描述一個測試活動完整的過程。
答案：（供參考，本答案主要是瀑布模型的做法）
- 項目經理通過和客戶的交流，完成需求文檔
- 由開發人員和測試人員共同完成需求文檔的評審，評審的內容包括：需求描述不清楚的地方和可能有明顯沖突或者無法實現的功能的地方。
- 項目經理通過綜合開發人員，測試人員以及客戶的意見，完成項目計劃。然后 SQA 進入項目，開始進行統計和跟蹤
- 開發人員根據需求文檔完成需求分析文檔，測試人員進行評審，評審的主要內容包括是否有遺漏或者雙方理解不同的地方。
- 測試人員完成測試計劃文檔，測試計劃包括的內容上面有描述。
- 測試人員根據修改好的需求分析文檔開始寫測試用例，同時開發人員完成概要設計文檔，詳細設計文檔。此兩份文檔成為測試人員撰寫測試用例的補充材料。
- 測試用例完成后，測試和開發需要進行評審。
- 測試人員搭建環境
- 開發人員提交第一個版本，可能存在未完成功能，需要說明。測試人員進行測試，發現 BUG后提交給 BugZilla。
- 開發提交第二個版本，包括 Bug Fix 以及增加了部分功能，測試人員進行測試。
重復上面的工作，一般是 3-4 個版本后 BUG 數量減少，達到出貨的要求。 - 如果有客戶反饋的問題，需要測試人員協助重現并重新測試。
24.BUG 管理工具的跟蹤過程
用 BugZilla 為例子
測試人員發現了 BUG，提交到 Bugzilla 中，狀態為 new，BUG 的接受者為開發接口人員
開發接口將 BUG 分配給相關的模塊的開發人員，狀態修改為已分配，開發人員和測試確認BUG，如果是本人的 BUG，則設置為接收；如果是別的開發人員的問題，則轉發出去，由下一個開發人員來進行此行為；如果認為不是問題，則需要大家討論并確認后，拒絕這個 BUG，
然后測試人員關閉此問題。
如果開發人員接受了 BUG，并修改好以后，將 BUG 狀態修改為已修復，并告知測試在哪個版本中可以測試。
測試人員在新版本中測試，如果發現問題依然存在，則拒絕驗證；如果已經修復，則關閉BUG。
25.您認為在測試人員同開發人員的溝通過程中，如何提高溝通的效率和改善溝通的效果？維持測試人員同開發團隊中其他成員 良好的人際關系的關鍵是什么？
- 盡量面對面的溝通，其次是能直接通過電話溝通，如果只能通過 Email 等非及時溝通工具的話，強調必須對特性的理解深刻以及能表達清楚。
運用一些測試管理工具如 TestDirector 進行管理也是較有效的方法，同時要注意在TestDirector 中對 BUG 有準確的描述。 - 在團隊中建立測試人員與開發人員良好溝通中注意以下幾點：
一真誠
二是團隊精神
三是在專業上有共同語言
四是要對事不對人，工作至上
當然也可以通過直接指出一些小問題，而不是進入 BUG Tracking System 來增加對方的好感。
26.你對測試最大的興趣在哪里？為什么？
回答這個面試題，沒有固定統一的答案，但可能是許多企業都會問到的。提供以下答案供考：
最大的興趣，感覺這是一個有挑戰性的工作；
測試是一個經驗行業，工作越久越能感覺到做好測試的難度和樂趣
通過自己的工作，能使軟件產品越來越完善，從中體會到樂趣
回答此類問題注意以下幾個方面：
盡可能的切合招聘企業的技術路線來表達你的興趣，例如該企業是數據庫應用的企業，那么表示你的興趣在數據庫的測試，并且希望通過測試提升自己的數據庫掌握能力。
表明你做測試的目的是為了提升能力，也是為了更好的做好測試；提升能力不是為了以后轉開發或其他的，除非用人企業有這樣的安排。
不要過多的表達你的興趣在招聘企業的范疇這外。
27.你自認為測試的優勢在哪里？
該面試也沒有固定不變的答案，但可參考以下幾點，并結合自身特點：
有韌性
有耐心
做事有條理性
喜歡面對挑戰
有信心做好每一件事情
較強的溝通能力
從以前的經理處都得到了很好的評價表明我做的很好
28.集成測試通常都有那些策略？
1、大爆炸集成
2、自頂向下集成
3、自底向上集成
4、三明治集成適應于大部分軟件開發項目
5、基干集成
6、分層集成
7、基于功能的集成
8、基于消息的集成
9、基于風險的集成
10、基于進度的集成
29.請你分別畫出 I OSI 的七層網絡結構圖和 P TCP/IP 的四層結構圖。
答：OSI 七層網絡結構圖，由上至下：
應用層 ；表示層 ;會話層 ;傳輸層 ;網絡層 ;數據鏈路層;物理層
TCP/IP 的四層結構圖
應用層;傳輸層;互聯層;鏈路層
30.一個 e byte 幾個單位。( ( 計算機基礎) )
答：8bit。
31.常用 X UNIX 命令x (Linux 的常用命令) ) （至少 0 10 個）； (Unix)
答：ls pwd mkdir rmdir rm cp mv cd ps ping tail more echo adduser passwd logout exit，
32.簡述你在以前的工作中做過哪些事情，比較熟悉什么。
此問題每個人都不一樣。參考答案如下。
我過去的主要工作是系統測試和自動化測試。在系統測試中，主要是對 BOSS 系統的業務邏輯功能，以及軟交換系統的 Class 5 特性進行測試。性能測試中，主要是進行的壓力測試，在各個不同數量請求的情況下，獲取系統響應時間以及系統資源消耗情況。
自動化測試主要是通過自己寫腳本以及一些第三方工具的結合來測試軟交換的特性測試。
在測試中，我感覺對用戶需求的完全準確的理解非常重要。另外，就是對 BUG 的管理，要以需求為依據，并不是所有 BUG 均需要修改。
測試工作需要耐心和細致，因為在新版本中，雖然多數原來發現的 BUG 得到了修復，但原來正確的功能也可能變得不正確。因此要注重迭代測試和回歸測試。
33.在 C/C++中 中 c static 有什么用途？（請至少說明兩種）
1)在函數體，一個被聲明為靜態的變量在這一函數被調用過程中維持其值不變。
- 在模塊內（但在函數體外），一個被聲明為靜態的變量可以被模塊內所用函數訪問，但不能被模塊外其它函數訪問。它是一個本地的全局變量。
- 在模塊內，一個被聲明為靜態的函數只可被這一模塊內的其它函數調用。那就是，這個函數被限制在聲明它的模塊的本地范圍內使用
34.引用與指針有什么區別？
- 引用必須被初始化，指針不必。
- 引用初始化以后不能被改變，指針可以改變所指的對象。
- 不存在指向空值的引用，但是存在指向空值的指針。
35.Internet 采用哪種網絡協議？該協議的主要層次結構？t Internet 物理地址和 P IP 地址轉換采用什么協議？
TCP/IP 協議
主要層次結構為： 應用層/傳輸層/網絡層/數鏈路層。
ARP (Address Resolution Protocol)（地址解析協議）
36.說說你對集成測試中自頂向下集成和自底向上集成兩個策略的理解，要談出它們各自的優缺點和主要適應于哪種類型測試；
- 自頂向下集成
優點：較早地驗證了主要控制和判斷點；按深度優先可以首先實現和驗證一個完整的軟件功能；功能較早證實，帶來信心；只需一個驅動，減少驅動器開發的費用；支持故障隔離。
缺點：柱的開發量大；底層驗證被推遲；底層組件測試不充分。
適應于產品控制結構比較清晰和穩定；高層接口變化較小；底層接口未定義或經常可能被修改；產口控制組件具有較大的技術風險，需要盡早被驗證；希望盡早能看到產品的系統功能行為。 - 自底向上集成
優點：對底層組件行為較早驗證；工作最初可以并行集成，比自頂向下效率高；減少了樁的工作量；支持故障隔離。
缺點：驅動的開發工作量大；對高層的驗證被推遲，設計上的錯誤不能被及時發現。
適應于底層接口比較穩定；高層接口變化比較頻繁；底層組件較早被完成。
37.軟件驗收測試包括正式驗收測試、alpha 測試、beta 測試三種測試。
38.系統測試的策略有很多種的，有性能測試、負載測試、強度測試、易用性測試、安全測試、配置測試、安裝測試、文檔測試、故障恢復測試、用戶界面測試、恢復測試、分布測試、可用性測試。
39.設計系統測試計劃需要參考的項目文檔有軟件測試計劃、軟件需求工件、和迭代計劃。
40.利用因果圖生成測試用例的基本步驟是：
§ 分析軟件規格說明描述中，哪些是原因（即輸入條件或輸入條件的等價類），哪些是結果（即輸出條件），并給每個原因和結果賦予一個標識符。
§ 分析軟件規格說明描述中的語義，找出原因與結果之間，原因與原因之間對應的是什么關系? 根據這些關系，畫出因果圖。
§ 由于語法或環境限制，有些原因與原因之間，原因與結果之間的組合情況不可能出現。為表明這些特殊情況，在因果圖上用一些記號標明約束或限制條件。
§ 把因果圖轉換成判定表。
§ 把判定表的每一列拿出來作為依據，設計測試用例。
一、 測試的種類很多，比如：
代碼、函數級測試
模塊、組件級測試
系統測試
請說出這些測試最好由那些人員完成，測試的是什么？
代碼、函數級測試一般由白盒測試人員完成，他們針對每段代碼或函數進行正確性檢驗，檢查其是否正確的實現了規定的功能。
模塊、組件級測試主要依據是程序結構設計測試模塊間的集成和調用關系，一般由測試人員完成。
系統測試在于模塊測試與單元測試的基礎上進行測試。了解系統功能與性能，根據測試用例進行全面的測試。
41設計測試用例時應該考慮哪些方面，即不同的測試用例針對那些方面進行測試？
設計測試用例時需要注意的是，除了對整體流程及功能注意外，還要注意強度測試、性能測試、壓力測試、邊界值測試、穩定性測試、安全性測試等多方面。（測試用例需要考慮的四個基本要素是輸入、輸出、操作和測試環境；另外，測試用例需要考慮的是測試類型（功能、性能、安全??），這部分可以參照 TP 做答。此外，還需要考慮用例的重要性和優先級）
42.在 windows 下保存一個文本文件時會彈出保存對話框，如果為文件名建立測試用例，等價類應該怎樣劃分？
單字節，如 A；
雙字節， AA、我我；
特殊字符 /‘。‘；、=-等；
保留字，如 com；
文件格式為 8.3 格式的；
文件名格式為非 8.3 格式的；
/,,*等九個特殊字符。
43.假設有一個文本框要求輸入 0 10 個字符的郵政編碼，對于該文本框應該怎 樣劃分等價類？
特殊字符，如 10 個*或￥；
英文字母，如 ABCDefghik；
小于十個字符，如 123；
大于十個字符，如 11111111111；
數字和其他混合，如 123AAAAAAA；
空字符；
保留字符
44.軟件測試項目從什么時候開始，？為什么？
軟件測試應該在需求分析階段就介入,因為測試的對象不僅僅是程序編碼,應該對軟件開發過程中產生的所有產品都測試,并且軟件缺陷存在放大趨勢.缺陷發現的越晚,修復它所花費的成本就越大.
45.什么是白盒測試？什么是黑盒測試? ? 什么是回歸測試? ?
- 白盒測試是測試人員要了解程序結構和處理過程,按照程序內部邏輯測試程序,檢查程序中的每條通路是否按照預定要求正確工作.它主要的針對被測程序的源代碼,測試者可以完全不考慮程序的功能.
白盒測試流程:詳細設計-->源程序-->分析程序內部邏輯結構-->流程圖-->制定測試用例-->被測程序-->執行路徑-->覆蓋情況分析 . - 黑盒測試:（Black-box Testing，又稱為功能測試或數據驅動測試）是把測試對象看作一個黑盒子。利用黑盒測試法進行動態測試時，需要測試軟件產品的功能，不需測試軟件產品的內部結構和處理過程。
- 回歸測試: (regression testing): 回歸測試有兩類：用例回歸和錯誤回歸；用例回歸是過一段時間以后再回頭對以前使用過的用例在重新進行測試，看看會重新發現問題。
錯誤回歸，就是在新版本中，對以前版本中出現并修復的缺陷進行再次驗證，并以缺陷為核心，對相關修改的部分進行測試的方法。
46.單元測試、集成測試、系統測試的側重點是什么？
- 單元測試針對的是軟件設計的最小單元--程序模塊（面向過程中是函數、過程；面向對象中是類。）,進行正確性檢驗的測試工作,在于發現每個程序模塊內部可能存在的差錯.一般有兩個步驟:人工靜態檢查\動態執行跟蹤
- 集成測試針對的是通過了單元測試的各個模塊所集成起來的組件進行檢驗,其主要內容是各個單元模塊之間的接口,以及各個模塊集成后所實現的功能.
- 系統測試針對的是集成好的軟件系統，作為整個計算機系統的一個元素,與計算機硬件\外設\某些支持軟件\數據和人員等其他系統元素結合在一起,要在實際的運行環境中,對計算機系統進行一系列的集成測試和確認測試.
47. 一個測試工程師應具備那些素質？
1、責任心
2、溝通能力
3、團隊合作精神
4、耐心、細心、信心
5、時時保持懷疑態度，并且有缺陷預防的意識
6、具備一定的編程經驗
48.你所了解的的軟件測試類型都有哪些，簡單介紹一下。
- 按測試 策略分類：
1、靜態與動態測試
2、黑盒與白盒測試
3、手工和自動測試
4、冒煙測試
5、回歸測試； - 按測試階段分類：單元測試、集成測試、系統測試；
- 其他常見測試方法：1、功能測試 2、性能測試 3、壓力測試 4、負載測試 5、易用性測試 6、安裝測試 7、界面測試 8、配置測試 9、文檔測試 10、兼容性測試 11、安全性測試 12、恢復測試
49.你認為做好測試計劃工作的關鍵是什么？
明確測試的目標，增強測試計劃的實用性
采用評審和更新機制，保證測試計劃滿足實際需求
分別創建測試計劃與測試詳細規格、測試用例
50.您認為做好測試用例設計工作的關鍵是什么？
白盒測試用例設計的關鍵是以較少的用例覆蓋盡可能多的內部程序邏輯結果
黑盒法用例設計的關鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可能做到完全測試，以最少的用例在合理的時間內發現最多的問題
51.您認為性能測試工作的目的是什么？做好性能測試工作的關鍵是什么？
- 性能測試的目的主要是發現在并發多用戶和大數據量操作時是否會出現與需求有差異的地方。
- 性能測試工作的關鍵是做好系統分析和功能分析，確定系統瓶頸所在
52.在您以往的測試工作中，最讓您感到不滿意或者不堪回首的事情是什么？您是如何來對待這些事情的？
53.你的測試職業發展目標是什么？
測試經驗越多，測試能力越高。所以我的職業發展是需要時間累積的，一步步向著高級測試工程師奔去。而且我也有初步的職業規劃，前 3 年累積測試經驗，不斷的更新自己改正自己，做好測試任務。
54.你對我們公司了解有多少？
建議從招聘廣告上多了解信息，同時到應聘公司的網站上去盡可能多的了解這個公司的情況，以便回答好這類問題。
55.測試結束的標準是什么？
從微觀上來說，在測試計劃中定義，比如系統在一定性能下平穩運行 72 小時，目前 BugTracking System 中，本版本中沒有一般嚴重的 BUG，普通 BUG 的數量在 3 以下，BUG 修復率 90%以上等等參數，然后由開發經理，測試經理，項目經理共同簽字認同版本 Release。
如果說宏觀的，則是當這個軟件徹底的消失以后，測試就結束了。
56. 軟件測試分為黑盒和白盒，分別適合什么情況？ ？
軟件測試方法一般分為兩種：白盒測試與黑盒測試。
- 白盒測試又稱為結構測試、邏輯驅動測試或基于程序本身的測試，它著重于程序的內部結構及算法，通常不關心功能與性能指標；
- 黑盒測試又被稱為功能測試、數據驅動測試或基于規格說明的測試，它實際上是站在最終用戶的立場，檢驗輸入輸出信息及系統性能指標是否符合規格說明書中有關功能需求及性能需求的規定。
57.一套完整的測試應該由哪些階段組成？
可行性分析、需求分析、概要設計、詳細設計、編碼、單元測試、集成測試、系統測試、驗收測試
58測試用例通常包括那些內容？
不同結構的用例包括的不一樣。
（版本、編號、項目、設計人員、設計日期、輸入、預期輸出??）
軟件測試用例的基本要素包括測試用例編號、測試標題、重要級別、測試輸入、操作步驟、預期結果。
- 用例編號： 測試用例的編號有一定的規則，比如系統測試用例的編號這樣定義規則：PROJECT1-ST-001 ，命名規則是項目名稱＋測試階段類型（系統測試階段）＋編號。定義測試用例編號，便于查找測試用例，便于測試用例的跟蹤。
- 測試標題： 對測試用例的描述，測試用例標題應該清楚表達測試用例的用途。比如 “ 測試用戶登錄時輸入錯誤密碼時，軟件的響應情況 ” 。
- 重要級別： 定義測試用例的優先級別，可以籠統的分為 “ 高 ” 和 “ 低 ” 兩個級別。
一般來說，如果軟件需求的優先級為 “ 高 ” ，那么針對該需求的測試用例優先級也為“ 高 ” ；反之亦然，一般而言，是 5 級劃分。 - 測試輸入： 提供測試執行中的各種輸入條件。根據需求中的輸入條件，確定測試用例的輸入。測試用例的輸入對軟件需求當中的輸入有很大的依賴性，如果軟件需求中沒有很好的定義需求的輸入，那么測試用例設計中會遇到很大的障礙。
- 操作步驟： 提供測試執行過程的步驟。對于復雜的測試用例，測試用例的輸入需要分為幾個步驟完成，這部分內容在操作步驟中詳細列出。
- 預期結果： 提供測試執行的預期結果，預期結果應該根據軟件需求中的輸出得出。如果在
實際測試過程中，得到的實際測試結果與預期結果不符，那么測試不通過；反之則測試通過。
59.您是否了解以往所工作的企業的軟件開發過程？如果了解，請試述一個完整的開發過程需要完成哪些工作？分別由哪些不同的角色來完成這些工作？您在以往的測試工作中都曾經具體從事過哪些工作？其中最擅長哪部分工作？
開發過程---需求調研（需求人員）、需求分析（需求人員）、概要設計（設計人員）、詳細設計(設計人員)、編碼（開發人員）
測試過程---需求評審、系統測試設計、概要設計評審、集成測試設計、詳細設計評審、單元測試設計、測試執行
測試工作的整個過程都做過，擅長做測試設計
過程決定質量，軟件的過程改進正是為了提高軟件的質量，將過往的種種經驗和教訓積累起來。
60.在您所經歷的測試活動中，參與人員有哪些？您所擔任的角色是什么？
有項目管理員、開發管理員、系統分析員、設計員、開發員、質量管理員、測試管理員、測試設計員、測試員
擔任過測試管理員、測試設計員、測試員
61.測試用例設計的原則是什么？目前主要的測試用例設計方法有哪些？
- 代表性：能夠代表并覆蓋各種合理的和不合理、合法的和非法的、邊界的和越界的、以及極限的輸入數據、操作和環境設置等.
- 可判定性：即測試執行結果的正確性是可判定的，每一個測試用例都應有相應的期望結果.
- 可再現性：即對同樣的測試用例，系統的執行結果應當是相同的。
- 方法有等價類、邊界值、因果圖、狀態圖、正交法、大綱法
61.LoadRunner 分為哪三個模塊？請簡述各模塊的主要功能。
Virtual User Generator：用于錄制腳步
Mercury LoadRunner Controller：用于創建、運行和監控場景
Mercury LoadRunner Analysis：用于分析測試結果
62.你對測試最大的興趣在哪里？為什么？
最大的興趣就是測試有難度，有挑戰性！做測試越久越能感覺到做好測試有多難。曾經在無憂測試網上看到一篇文章，是關于如何做好一名測試工程師。一共羅列了 11，12 點，有部分是和人的性格有關，有部分需要后天的努力。但除了性格有關的 1，2 點我沒有把握，其他點我都很有信心做好它。剛開始進入測試行業時，對測試的認識是從無憂測試網上了解到的一些資料，當時是沖著做測試需要很多技能才能做的好，雖然入門容易，但做好很難，比開發更難，雖然當時我很想做開發（學校專業課我基本上不缺席，因為我喜歡我的專業），但看到測試比開發更難更有
挑戰性，想做好測試的意志就更堅定了。
我覺得做測試整個過程中有 2 點讓我覺得很有難度（對我來說，有難度的東西我就非常感興趣），第一是測試用例的設計，因為測試的精華就在測試用例的設計上了，要在版本出來之前，把用例寫好，用什么測試方法寫？（也就是測試計劃或測試策略），如果你剛測試一個新任務時，你得花一定的時間去消化業務需求和技術基礎，業務需求很好理解（多和產品經理和開發人員溝通就能達到目的），而技術基礎可就沒那么簡單了，這需要你自覺的學習能力，比如說網站吧，最基本的技術知識你要知道網站內部是怎么運作的的，后臺是怎么響應用戶請求的？測試環境如何搭建？這些都需要最早的學好。至少在開始測試之前能做好基本的準備，可能會遇到什么難題？需求細節是不是沒有確定好？這些問題都能在設計用例的時候發現。
第二是發現 BUG 的時候了，這應該是測試人員最基本的任務了，一般按測試用例開始測試就能發現大部分的 bug，還有一部分 bug 需要測試的過程中更了解所測版本的情況獲得更多信息，補充測試用例，測試出 bug。還有如何發現 bug？這就需要在測試用例有效的情況下，通過細心和耐心去發現 bug 了，每個用例都有可能發現 bug，每個地方都有可能出錯，所以測試過程中思維要清晰（測試過程數據流及結果都得看仔細了，bug 都在里面發現的）。如何描述 bug 也很有講究，bug 在什么情況下會產生，如果條件變化一點點，就不會有這個 bug，以哪些最少的操作步驟就能重現這個bug，這個bug產生的規律是什么？如果你夠厲害的話，可以幫開發人員初步定位問題。
63.當開發人員說不是 G BUG 時，你如何應付？
開發人員說不是 bug，有 2 種情況，
- 一是需求沒有確定，所以我可以這么做，這個時候可以找來產品經理進行確認，需不需要改動，3 方商量確定好后再看要不要改。
- 二是這種情況不可能發生，所以不需要修改，這個時候，我可以先盡可能的說出是 BUG 的依據是什么？
如果被用戶發現或出了問題，會有什么不良結果？程序員可能會給你很多理由，你可以對他的解釋進行反駁。如果還是不行，那我可以給這個問題提出來,跟開發經理和測試經理進行確認,如果要修改就改,如果不要修改就不改。其實有些真的不是 bug，我也只是建議的方式寫進 TD 中，如果開發人員不修改也沒有大問題。如果確定是 bug 的話，一定要堅持自己的
立場，讓問題得到最后的確認。
64.為什么要在一個團隊中開展軟件測試工作？
因為沒有經過測試的軟件很難在發布之前知道該軟件的質量，就好比 ISO 質量認證一樣，測試同樣也需要質量的保證，這個時候就需要在團隊中開展軟件測試的工作。在測試的過程發現軟件中存在的問題，及時讓開發人員得知并修改問題，在即將發布時，從測試報告中得出軟件的質量情況。#####65.如果有機會轉成開發人員，你會去做開發工作嗎？
如果公司確實需要我可以從事開發，但我還是喜歡做測試，我認為我更適合做測試。
66.軟件測試分哪些階段？各階段的含義？
分為單元測試、集成測試、確認測試、系統測試、驗收測試。單元測試是最小單位的測試，測試獨立模塊；
集成測試主要測試模塊之間的接口是否正常，
確認測試類似于冒煙測試通常在大規模系統測試之前驗證版本主要功能是否實現，版本的穩定性是否可以進入系統測試，
系統測試是全面測試驗證系統是否滿足用戶需求包括功能、性能、兼容性等等。
驗收測試是用戶參與的測試。
67.一份測試計劃應該包括哪些內容？
背景、項目簡介、目的、測試范圍、測試策略、人員分工、資源要求、進度計劃、參考文檔、常用術語、提交文檔、風險分析。
68.什么是兼容性測試？請舉例說明如何利用兼容性測試列表進行測試。
主要驗證軟件產品在不同版本之間的兼容性。包括向下兼容和交錯兼容，向下兼容是測試軟件新版本保留它早期版本功能的情況，
交錯兼容是驗證共同存在的兩個相關但不相同的產品之間的兼容性。
69.對某軟件進行測試，發現在 8 WIN98 上運行得很慢，怎么判別是該軟件存在問題還是其軟硬件運行環境存在問題？
看軟件的運行環境要求。如果符合要求則是程序存在問題，若不符合要求則是硬件系統存在問題
70.需求測試的注意事項有哪些？
是否使用了公司的模板
文檔內容是否符合規范
所有的需求是分級是否清析適當？
所有的需求是否具有一致性
需求是否可行（即，該需求組合有解決方案）
需求可否用己知的約束來實現
需求是否足夠（即，可以把它送到一個規范的開發組織，并有一個生產出所需要產品的合理的可能性）
所有的其它需求是交叉引用是否正確
用戶描述是否清楚
是否用客戶的語言來描述需求
每個需求描述是否清楚沒有岐義，可以移交給一個獨立的組去實現時也能理解
是否所有的需求都是可驗證的
是否每條需求都具有獨立性，即使發生了變化也不會影響其它需求
性能指標是否明確
非功能性需求是否得到充分表現
是否完整列出適用的標準或協議
標準和協議之間是否存在沖突
71.請簡述一下缺陷的生命周期。
提交?分配?處理?返測?關閉（返測和處理為循環
本文參考：http://blog.csdn.net/mj813/article/details/52451355
