面試測試題

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

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

然後，要獲取判斷的依據和標準：

• 根據需求說明書、產品說明、設計文件等，確認實際結果是否與計劃有不一致的地方，提供缺陷是否確認的直接依據；
• 如果沒有文件依據，可以根據類似軟體的一般特性來說明是否存在不一致的地方，來確認是否是缺陷；
• 根據使用者的一般使用習慣，來確認是否是缺陷；
• 與設計人員、開發人員和客戶代表等相關人員探討，確認是否是缺陷；

合理的論述，向測試經理說明自己的判斷的理由，注意客觀、嚴謹，不參雜個人情緒。

等待測試經理做出最終決定，如果仍然存在爭議，可以通過公司政策所提供的渠道，向上級反映，並有上級做出決定。

2****、問：給你一個網站，你如何測試？

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

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

設計測試用例：

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

• 連結測試。連結是否正確跳轉，是否存在空頁面和無效頁面，是否有不正確的出錯資訊返回。
• 提交功能的測試。
• 多媒體元素是否可以正確載入和顯示。
• 多語言支援是否能夠正確顯示選擇的語言等。

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

• 頁面是否風格統一，美觀
• 頁面佈局是否合理，重點內容和熱點內容是否突出
• 控制元件是否正常使用
• 對於必須但未安裝的控制元件，是否提供自動下載並安裝的功能
• 文字檢查

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

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

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

安全性測試：

• 基本的登入功能的檢查
• 是否存在溢位錯誤，導致系統崩潰或者許可權洩露
• 相關開發語言的常見安全性問題檢查，例如SQL隱碼攻擊等
• 如果需要高階的安全性測試，確定獲得專業安全公司的幫助，外包測試，或者獲取支援

相容性測試，根據需求說明的內容，確定支援的平臺組合：

• 瀏覽器的相容性；
• 作業系統的相容性；
• 軟體平臺的相容性；
• 資料庫的相容性

開展測試，並記錄缺陷。合理的安排調整測試進度，提前獲取測試所需的資源，建立管理體系（例如，需求變更、風險、配置、測試文件、缺陷報告、人力資源等內容）。

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

3****、在搜尋引擎中輸入漢字就可以解析到對應的域名，請問如何用LoadRunner****進行測試。

• 建立測試計劃，確定測試標準和測試範圍
• 設計典型場景的測試用例，覆蓋常用業務流程和不常用的業務流程等
• 根據測試用例，開發自動測試指令碼和場景：

錄製測試指令碼：新建一個指令碼（Web/HTML協議）；點選錄製按鈕，在彈出的對話方塊的URL中輸入”about:blank”；在開啟的瀏覽器中進行正常操作流程後，結束錄製；除錯指令碼並儲存，可能要注意到字符集的關聯。

設定測試場景：針對效能設定測試場景，主要判斷在正常情況下，系統的平均事務響應時間是否達標；針對壓力負載設定測試場景，主要判斷在長時間處於滿負荷或者超出系統承載能力的條件下，系統是否會崩潰；執行測試，獲取測試結果，分析測試結果

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

• 300個使用者在一個客戶端上，會佔用客戶機更多的資源，而影響測試的結果。執行緒之間可能發生干擾，而產生一些異常。
• 300個使用者在一個客戶端上，需要更大的頻寬。
• IP地址的問題，可能需要使用IP Spoof來繞過伺服器對於單一IP地址最大連線數的限制。
• 所有使用者在一個客戶端上，不必考慮分散式管理的問題；而使用者分佈在不同的客戶端上，需要考慮使用控制器來整體調配不同客戶機上的使用者。同時，還需要給予相應的許可權配置和防火牆設定。

5****、試述軟體的概念和特點？軟體複用的含義？構件包括哪些？

軟體是計算機系統中與硬體相互依存的另一部分，與計算機系統操作有關的計算機程式、規程、規則，以及可能有的檔案、文件及資料。

軟體複用(SoftWare Reuse)是將已有軟體的各種有關知識用於建立新的軟體，以縮減軟體開發和維護的花費。軟體複用是提高軟體生產力和質量的一種重要技術。早期的軟體複用主要是程式碼級複用，被複用的知識專指程式，後來擴大到包括領域知識、開發經驗、設計決定、體系結構、需求、設計、程式碼和文件等一切有關方面。

可以被複用的軟體成分一般稱作可複用構件

6****、軟體生存週期及其模型是什麼？

軟體生存週期（Software life cycle）又稱為軟體生命期，生存期。是指從形成開發軟體概念起，所開發的軟體使用以後，知道失去使用價值消亡為止的整個過程。一般來說，整個生存週期包括計劃（定義）、開發、執行（維護）三個時期，每個時期又劃分為若干個階段。每個階段有明確的任務。

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

• 瀑布模型
• 快速原型模型：快速原型模型允許在需求分析階段對軟體的需求進行初步而非完全的分析和定義，快速設計開發出軟體系統的原型，該原型向使用者展示待開發軟體的全部或部分功能和效能；使用者對該原型進行測試評定，給出具體改進意見以豐富細化軟體需求；開發人員據此對軟體進行修改完善，直至使用者滿意認可之後，進行軟體的完整實現及測試、維護。
• 迭代模型：迭代包括產生產品釋出（穩定、可執行的產品版本）的全部開發活動和要使用該釋出必需的所有其他外圍元素。在某種程度上，開發迭代是一次 完整地經過所有工作流程的過程：需求分析、設計、實施和測試工作流程。實質上，它類似小型的瀑布式專案。RUP認為，所有的階段都可以細分為迭代。每一次 的迭代都會產生一個可以釋出的產品，這個產品是最終產品的一個子集。

生命週期階段：

• 軟體計劃與可行性分析
• 需求分析
• 軟體設計
• 編碼
• 軟體測試
• 執行與維護

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

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

軟體測試的目的：

• 測試是程式的執行過程，目的在於發現錯誤
• 一個成功的測試用例在於發現至今未發現的錯誤
• 一個成功的測試是發現了至今未發現的錯誤的測試
• 確保產品完成了它所承諾或公佈的功能，並且使用者可以訪問到的功能都有明確的書面說明。
• 確保產品滿足效能和效率的要求
• 確保產品是健壯的和適應使用者環境的

軟體測試的原則：

• 測試用例中一個必須部分是對預期輸出或接過進行定義
• 程式設計師應避免測試自己編寫的程式
• 編寫軟體的組織不應當測試自己編寫的軟體
• 應當徹底檢查每個測試的執行結果
• 測試用例的編寫不僅應當根據有效和預料到的輸入情況，而且也應當根據無效和未預料到的輸入情況
• 檢擦程式是否“未做其應該做的”僅是測試的一半，測試的另一半是檢查程式是否“做了其不應該做的”
• 應避免測試用例用後即棄，除非軟體本身就是個一次性的軟體
• 計劃測試工作時不應默許假定不會發現錯誤
• 程式某部分存在更多錯誤的可能性，與該部分已經發現錯誤的數量成正比
• 軟體測試是一項極富創造性，極具智力的挑戰性的工作

8****、軟體配置管理的作用？軟體配置包括什麼？

軟體配置管理（Software Configuration Management，SCM）是一種標識、組織和控制修改的技術。軟體配置管理應用於整個軟體工程過程。在軟體建立時變更是不可避免的，而變更加劇了專案中軟體開發者之間的混亂。SCM活動的目標就是為了標識變更、控制變更、確保變更正確實現並向其他有關人員報告變更。從某種角度講，SCM是一種標識、組織和控制修改的技術，目的是使錯誤降為最小並最有效地提高生產效率。

軟體配置包括如下內容：配置項識別、工作空間管理、版本控制、變更控制、狀態報告、配置審計

9****、什麼是軟體質量？

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

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

白盒測試：邏輯覆蓋、迴圈覆蓋、基本路徑覆蓋

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

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

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

• 使用者認證安全的測試要考慮問題： 明確區分系統中不同使用者許可權 、系統中會不會出現使用者衝突 、系統會不會因使用者的許可權的改變造成混亂 、使用者登陸密碼是否是可見、可複製 、是否可以通過絕對途徑登陸系統（拷貝使用者登陸後的連結直接進入系統）、使用者退出系統後是否刪除了所有鑑權標記，是否可以使用後退鍵而不通過輸入口令進入 系統 、系統網路安全的測試要考慮問題 、測試採取的防護措施是否正確裝配好，有關係統的補丁是否打上 、模擬非授權攻擊，看防護系統是否堅固 、採用成熟的網路漏洞檢查工具檢查系統相關漏洞（即用最專業的黑客攻擊工具攻擊試一下，現在最常用的是 NBSI 系列和 IPhacker IP ） 、採用各種木馬檢查工具檢查系統木馬情況 、採用各種防外掛工具檢查系統各組程式的外掛漏洞
• 資料庫安全考慮問題： 系統資料是否機密（比如對銀行系統，這一點就特別重要，一般的網站就沒有太高要求）、系統資料的完整性（我剛剛結束的企業實名核查服務系統中就曾存在資料 的不完整，對於這個系統的功能實現有了障礙） 、系統資料可管理性 、系統資料的獨立性 、系統資料可備份和恢復能力（資料備份是否完整，可否恢復，恢復是否可以完整）

12****、什麼是測試用例 ****什麼是測試指令碼 ****兩者的關係是什麼？

為實施測試而向被測試系統提供的輸入資料、操作或各種環境設定以及期望結果的一個特定的集合。

測試指令碼是為了進行自動化測試而編寫的指令碼。

測試指令碼的編寫必須對應相應的測試用例

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

• 靜態測試是不執行程式本身而尋找程式程式碼中可能存在的錯誤或評估程式程式碼的過程。
• 動態測試是實際執行被測程式，輸入相應的測試例項，檢查執行結果與預期結果的差異，判定執行結果是否符合要求，從而檢驗程式的正確性、可靠性和有效性，並分析系統執行效率和健壯性等效能。
• 黑盒測試一般用來確認軟體功能的正確性和可操作性,目的是檢測軟體的各個功能是否能得以實現,把被測試的程式當作一個黑盒,不考慮其內部結構,在知道該程式的輸入和輸出之間的關係或程式功能的情況下,依靠軟體規格說明書來確定測試用例和推斷測試結果的正確性。
• 白盒測試根據軟體內部的邏輯結構分析來進行測試,是基於程式碼的測試，測試人員通過閱讀程式程式碼或者通過使用開發工具中的單步除錯來判斷軟體的質量，一般黑盒測試由專案經理在程式設計師開發中來實現。
• α測試是由一個使用者在開發環境下進行的測試，也可以是公司內部的使用者在模擬實際操作環境下進行的受控測試，Alpha測試不能由程式設計師或測試員完成。
• β測試是軟體的多個使用者在一個或多個使用者的實際使用環境下進行的測試。開發者通常不在測試現場，Beta測試不能由程式設計師或測試員完成。

14****、軟體質量保證體系是什麼 ****國家標準中與質量保證管理相關的幾個標準是什麼?****他們的編號和全稱是什麼?

SQA由一套軟體工程過程和方法組成，以保證（軟體的）質量。SQA貫穿整個軟體開發過程，(它)應包括需求文件評審、程式碼控制、程式碼評審、變更管理、配置管理、版本管理和軟體測試。

軟體質量保證（SQA-Software Quality Assurance）是建立一套有計劃，有系統的方法，來向管理層保證擬定出的標準、步驟、實踐和方法能夠正確地被所有專案所採用。軟體質量保證的目的是使軟體過程對於管理人員來說是可見的。它通過對軟體產品和活動進行評審和審計來驗證軟體是合乎標準的。軟體質量保證組在專案開始時就一起參與建立計劃、標準和過程。這些將使軟體專案滿足機構方針的要求。

15****、軟體產品質量特性是什麼?

功能性：適應性、準確性、互操作性、依從性、安全性。

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

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

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

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

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

16****、軟體測試的策略是什麼?

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

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

和開發過程相對應，測試過程會依次經歷單元測試、整合測試、系統測試、驗收測試四個主要階段：

• 單元測試：單元測試是針對軟體設計的最小單位––程式模組甚至程式碼段進行正確性檢驗的測試工作，通常由開發人員進行。
• 整合測試：整合測試是將模組按照設計要求組裝起來進行測試，主要目的是發現與介面有關的問題。由於在產品提交到測試部門前，產品開發小組都要進行聯合除錯，因此在大部分企業中整合測試是由開發人員來完成的。
• 系統測試：系統測試是在整合測試通過後進行的，目的是充分執行系統，驗證各子系統是否都能正常工作並完成設計的要求。它主要由測試部門進行，是測試部門最大最重要的一個測試，對產品的質量有重大的影響。
• 驗收測試：驗收測試以需求階段的《需求規格說明書》為驗收標準，測試時要求模擬實際使用者的執行環境。對於實際專案可以和客戶共同進行，對於產品來說就是最後一次的系統測試。測試內容為對功能模組的全面測試，尤其要進行文件測試。

單元測試測試策略：

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

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

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

整合測試的測試策略：

大爆炸整合：適應於一個維護型專案或被測試系統較小

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

自底向上整合：適應於底層介面比較穩定；高層介面變化比較頻繁；底層元件較早被完成。

基於進度的整合
優點：具有較高的並行度；能夠有效縮短專案的開發進度。
缺點：樁和驅動工作量較大；有些介面測試不充分；有些測試重複和浪費。

系統測試的測試策略：

資料和資料庫完整性測試；功能測試；使用者介面測試；效能評測；負載測試；強度測試；容量測試；安全性和訪問控制測試；故障轉移和恢復測試；配置測試；安裝測試；加密測試；可用性測試；版本驗證測試；文件測試

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

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

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

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

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

1、儘可能早的找出系統中的Bug；
2、避免軟體開發過程中缺陷的出現；
3、衡量軟體的品質，保證系統的質量；
4、關注使用者的需求，並保證系統符合使用者需求。
總的目標是：確保軟體的質量。

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

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

<pre class="recommend-text mb-10" style="margin: 0px; padding: 0px; white-space: pre-wrap; word-wrap: break-word; color: rgb(51, 51, 51); font-size: 14px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-style: initial; text-decoration-color: initial;">bug編號；
bug嚴重級別，優先順序；
bug產生的模組；
首先要有bug摘要，闡述bug大體的內容；
bug對應的版本；
bug詳細現象描述，包括一些截圖、錄影....等等；
bug出現時的測試環境，產生的條件即對應操作步驟；

高質量的Bug記錄：</pre>

<pre class="recommend-text mb-10" style="margin: 0px; padding: 0px; white-space: pre-wrap; word-wrap: break-word; color: rgb(51, 51, 51); font-size: 14px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-style: initial; text-decoration-color: initial;">1) 通用UI要統一、準確
缺陷報告的UI要與測試的軟體UI保持一致，便於查詢定位。

2. 儘量使用業界慣用的表達術語和表達方法
   使用業界慣用的表達術語和表達方法，保證表達準確，體現專業化。
3. 每條缺陷報告只包括一個缺陷
   每條缺陷報告只包括一個缺陷，可以使缺陷修正者迅速定位一個缺陷，集中精力每次只修正一個缺陷。校驗者每次只校驗一個缺陷是否已經正確修正。
4. 不可重現的缺陷也要報告
   首先缺陷報告必須展示重現缺陷的能力。不可重現的缺陷要盡力重現，若盡力之後仍不能重現，仍然要報告此缺陷，但在報告中要註明無法再現，缺陷出現的頻率。
5. 明確指明缺陷型別
   根據缺陷的現象，總結判斷缺陷的型別。例如，即功能缺陷、介面缺陷、資料缺陷，合理化建議這是最常見的缺陷或缺陷型別，其他形式的缺陷或缺陷也從屬於其中某種形式。
6. 明確指明缺陷嚴重等級和優先等級
   時刻明確嚴重等級和優先等級之間的差別。高嚴重問題可能不值得解決，小裝飾性問題可能被當作高優先順序。
7. 描述 (Description) ，簡潔、準確，完整，揭示缺陷實質，記錄缺陷或缺陷出現的位置
   描述要準確反映缺陷的本質內容，簡短明瞭。為了便於在軟體缺陷管理資料庫中尋找制定的測試缺陷，包含缺陷發生時的使用者介面（UI）是個良好的習慣。例如記錄對話方塊的標題、選單、按鈕等控制元件的名稱。
8. 短行之間使用自動數字序號，使用相同的字型、字號、行間距
   短行之間使用自動數字序號，使用相同的字型、字號、行間距，可以保證各條記錄格式一致，做到規範專業。
9. 每一個步驟儘量只記錄一個操作
   保證簡潔、條理井然，容易重複操作步驟。
10. 確認步驟完整，準確，簡短
    保證快速準確的重複缺陷，“完整”即沒有缺漏，“準確”即步驟正確，“簡短”即沒有多餘的步驟。
11. 根據缺陷，可選擇是否進行圖象捕捉
    為了直觀的觀察缺陷或缺陷現象，通常需要附加缺陷或缺陷出現的介面，以圖片的形式作為附件附著在記錄的“附件”部分。為了節省空間，又能真實反映缺陷或缺陷本質，可以捕捉缺陷或缺陷產生時的全螢幕，活動視窗和區域性區域。為了迅速定位、修正缺陷或缺陷位置，通常要求附加中文對照圖。
     附加必要的特殊文件和個人建議和註解
    如果開啟某個特殊的文件而產生的缺陷或缺陷，則必須附加該文件，從而可以迅速再現缺陷或缺陷。有時，為了使缺陷或缺陷修正者進一步明確缺陷或缺陷的表現，可以附加個人的修改建議或註解。
12. 檢查拼寫和語法缺陷
    在提交每條缺陷或缺陷之前，檢查拼寫和語法，確保內容正確，正確的描述缺陷。
13. 儘量使用短語和短句，避免複雜句型句式
    軟體缺陷管理資料庫的目的是便於定位缺陷，因此，要求客觀的描述操作步驟，不需要修飾性的詞彙和複雜的句型，增強可讀性。
    以上概括了報告測試缺陷的規範要求，隨著軟體的測試要求不同，測試者經過長期測試，積累了相應的測試經驗，將會逐漸養成良好的專業習慣，不斷補充新的規範書寫要求。此外，經常閱讀、學習其他測試工程師的測試缺陷報告，結合自己以前的測試缺陷報告進行對比和思考，可以不斷提高技巧。
14. 缺陷描述內容
    缺陷描述的內容可以包含缺陷操作步驟，實際結果和期望結果。操作步驟可以方便開發人員再現缺陷進行修正，有些開發的再現缺陷能力很差，雖然他明白你所指的缺陷，但就是無法再現特別是對系統不熟悉的新加入開發人員，介紹步驟可以方便他們再現。實際結果可以讓開發明白錯誤是什麼，期望結果可以讓開發瞭解正確的結果應該是如何。</pre>

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

黑盒測試的優點有：比較簡單，不需要了解程式內部的程式碼及實現；與軟體的內部實現無關； 從使用者角度出發，能很容易的知道使用者會用到哪些功能，會遇到哪些問題；基於軟體開發文件，所以也能知道軟體實現了文件中的哪些功能；在做軟體自動化測試時較為方便。

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

白盒測試的優點有：幫助軟體測試人員增大程式碼的覆蓋率，提高程式碼的質量，發現程式碼中隱 藏的問題。

白盒測試的缺點有：程式執行會有很多不同的路徑，不可能測試所有的執行路徑；測試基於程式碼，只能測試開發人員做的對不對，而不能知道設計的正確與否，可能會漏掉一些功能需求；系統龐大時，測試開銷會非常大。

22****、如何測試一個紙杯？

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

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

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

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

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

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

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

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

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

22****、測試計劃工作的目的是什麼？測試計劃文件的內容應該包括什麼？其中哪些是最重要的？

軟體測試計劃是指導測試過程的綱領性檔案：

• 領導能夠根據測試計劃進行巨集觀調控，進行相應資源配置等
• 測試人員能夠了解整個專案測試情況以及專案測試不同階段的所要進行的工作等
• 便於其他人員瞭解測試人員的工作內容，進行有關配合工作

包含了產品概述、測試策略、測試方法、測試區域、測試配置、測試周期、測試資源、測試交流、風險分析等內容。藉助軟體測試計劃，參與測試的專案成員，尤其是測試管理人員，可以明確測試任務和測試方法，保持測試實施過程的順暢溝通，跟蹤和控制測試進度，應對測試過程中的各種變更。

測試計劃編寫6要素（5W1H）：

• why——為什麼要進行這些測試；

• what—測試哪些方面，不同階段的工作內容；

• when—測試不同階段的起止時間；

• where—相應文件，缺陷的存放位置，測試環境等；

• who—專案有關人員組成，安排哪些測試人員進行測試；

• how—如何去做，使用哪些測試工具以及測試方法進行測試

測試計劃和測試詳細規格、測試用例之間是戰略和戰術的關係，測試計劃主要從巨集觀上規劃測試活動的範圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。所以其中最重要的是測試測試策略和測試方法（最好是能先評審）。

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

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

2）邊界值分析法：是對等價類劃分方法的補充。測試工作經驗告訴我,大量的錯誤是發生在輸入或輸出範圍的邊界上,而不是發生在輸入輸出範圍的內部.因此針對各種邊界情況設計測試用例,可以查出更多的錯誤.

使用邊界值分析方法設計測試用例,首先應確定邊界情況.通常輸入和輸出等價類的邊界,就是應著重測試的邊界情況.應當選取正好等於,剛剛大於或剛剛小於邊界的值作為測試資料,而不是選取等價類中的典型值或任意值作為測試資料.

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

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

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

5）正交表分析法：可能因為大量的引數的組合而引起測試用例數量上的激增，同時，這些測試用例並沒有明顯的優先順序上的差距，而測試人員又無法完成這麼多數量的測試，就可以通過正交表來進行縮減一些用例，從而達到儘量少的用例覆蓋儘量大的範圍的可能性。

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

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

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

24****、詳細的描述一個測試活動完整的過程。（供參考，本答案主要是瀑布模型的做法）

專案經理通過和客戶的交流，完成需求文件，由開發人員和測試人員共同完成需求文件的評審，評審的內容包括：需求描述不清楚的地方和可能有明顯衝突或者無法實現的功能的地方。專案經理通過綜合開發人員，測試人員以及客戶的意見，完成專案計劃。然後SQA進入專案，開始進行統計和跟蹤

開發人員根據需求文件完成需求分析文件，測試人員進行評審，評審的主要內容包括是否有遺漏或雙方理解不同的地方。測試人員完成測試計劃文件，測試計劃包括的內容上面有描述。

測試人員根據修改好的需求分析文件開始寫測試用例，同時開發人員完成概要設計文件，詳細設計文件。此兩份文件成為測試人員撰寫測試用例的補充材料。

測試用例完成後，測試和開發需要進行評審。

測試人員搭建環境

開發人員提交第一個版本，可能存在未完成功能，需要說明。測試人員進行測試，發現BUG後提交給BugZilla。

開發提交第二個版本，包括Bug Fix以及增加了部分功能，測試人員進行測試。

重複上面的工作，一般是3-4個版本後BUG數量減少，達到出貨的要求。

如果有客戶反饋的問題，需要測試人員協助重現並重新測試。

26****、BUG****管理工具的跟蹤過程（用BugZilla為例子）

測試人員發現了BUG，提交到Bugzilla中，狀態為new，BUG的接受者為開發介面人員

開發介面將BUG分配給相關的模組的開發人員，狀態修改為已分配，開發人員和測試確認BUG，如果是本人的BUG，則設定為接收；如果是別的開發人員的問題，則轉發出去，由下一個開發人員來進行此行為；如果認為不是問題，則需要大家討論並確認後，拒絕這個BUG，然後測試人員關閉此問題。

如果開發人員接受了BUG，並修改好以後，將BUG狀態修改為已修復，並告知測試在哪個版本中可以測試。

測試人員在新版本中測試，如果發現問題依然存在，則拒絕驗證；如果已經修復，則關閉BUG。

27****、您認為在測試人員同開發人員的溝通過程中，如何提高溝通的效率和改善溝通的效果？維持測試人員同開發團隊中其他成員良好的人際關係的關鍵是什麼？

儘量面對面的溝通，其次是能直接通過電話溝通，如果只能通過Email等非及時溝通工具的話，強調必須對特性的理解深刻以及能表達清楚。

運用一些測試管理工具如TestDirector進行管理也是較有效的方法，同時要注意在TestDirector中對BUG有準確的描述。

在團隊中建立測試人員與開發人員良好溝通中注意以下幾點：

一真誠、二是團隊精神、三是在專業上有共同語言、四是要對事不對人，工作至上

當然也可以通過直接指出一些小問題，而不是進入BUG Tracking System來增加對方的好感。

28****、你對測試最大的興趣在哪裡？為什麼？

回答這個面試題，沒有固定統一的答案，但可能是許多企業都會問到的。提供以下答案供考：

最大的興趣，感覺這是一個有挑戰性的工作；

測試是一個經驗行業，工作越久越能感覺到做好測試的難度和樂趣

通過自己的工作，能使軟體產品越來越完善，從中體會到樂趣

回答此類問題注意以下幾個方面：

儘可能的切合招聘企業的技術路線來表達你的興趣，例如該企業是資料庫應用的企業，那麼表示你的興趣在資料庫的測試，並且希望通過測試提升自己的資料庫掌握能力。

表明你做測試的目的是為了提升能力，也是為了更好的做好測試；提升能力不是為了以後轉開發或其他的，除非用人企業有這樣的安排。

不要過多的表達你的興趣在招聘企業的範疇這外。比如招聘企業是做財務軟體的，可是你表現出來的是對遊戲軟體的興趣；或招聘是做JAVA開發的，而你的興趣是在C類語言程式的開發。

29****、你自認為測試的優勢在哪裡？

該面試也沒有固定不變的答案，但可參考以下幾點，並結合自身特點：

有韌性、有耐心、做事有條理性、喜歡面對挑戰、有信心做好每一件事情、較強的溝通能力、從以前的經理處都得到了很好的評價表明我做的很好

33****、簡述你在以前的工作中做過哪些事情，比較熟悉什麼。參考答案如下。

我過去的主要工作是系統測試和自動化測試。在系統測試中，主要是對BOSS系統的業務邏輯功能，以及軟交換系統的Class 5特性進行測試。效能測試中，主要是進行的壓力測試，在各個不同數量請求的情況下，獲取系統響應時間以及系統資源消耗情況。自動化測試主要是通過自己寫指令碼以及一些第三方工具的結合來測試軟交換的特性測試。

在測試中，我感覺對使用者需求的完全準確的理解非常重要。另外，就是對BUG的管理，要以需求為依據，並不是所有BUG均需要修改。

測試工作需要耐心和細緻，因為在新版本中，雖然多數原來發現的BUG得到了修復，但原來正確的功能也可能變得不正確。因此要注重迭代測試和迴歸測試。

34****、在C/C++****中static****有什麼用途？（請至少說明兩種）
1)在函式體，一個被宣告為靜態的變數在這一函式被呼叫過程中維持其值不變。

2. 在模組內（但在函式體外），一個被宣告為靜態的變數可以被模組內所用函式訪問，但不能被模組外其它函式訪問。它是一個本地的全域性變數。
3. 在模組內，一個被宣告為靜態的函式只可被這一模組內的其它函式呼叫。那就是，這個函式被限制在宣告它的模組的本地範圍內使用

35****、引用與指標有什麼區別？
1) 引用必須被初始化，指標不必。
2) 引用初始化以後不能被改變，指標可以改變所指的物件。
3) 不存在指向空值的引用，但是存在指向空值的指標。

36****、Internet****採用哪種網路協議？該協議的主要層次結構？Internet****實體地址和IP****地址轉換採用什麼協議？

TCP/IP協議主要層次結構為： 應用層/傳輸層/網路層/數鏈路層。

ARP (Address Resolution Protocol)（地據址解析協議）

37****、說說你對整合測試中自頂向下整合和自底向上整合兩個策略的理解，要談出它們各自的優缺點和主要適應於哪種型別測試；

自頂向下整合

優點：較早地驗證了主要控制和判斷點；按深度優先可以首先實現和驗證一個完整的軟體功能；功能較早證實，帶來信心；只需一個驅動，減少驅動器開發的費用；支援故障隔離。

缺點：柱的開發量大；底層驗證被推遲；底層元件測試不充分。

適應於產品控制結構比較清晰和穩定；高層介面變化較小；底層介面未定義或經常可能被修改；產口控制元件具有較大的技術風險，需要儘早被驗證；希望儘早能看到產品的系統功能行為。

2、自底向上整合

優點：對底層元件行為較早驗證；工作最初可以並行整合，比自頂向下效率高；減少了樁的工作量；支援故障隔離。

缺點：驅動的開發工作量大；對高層的驗證被推遲，設計上的錯誤不能被及時發現。
適應於底層介面比較穩定；高層介面變化比較頻繁；底層元件較早被完成。

38****、軟體驗收測試包括正式驗收測試、alpha測試、beta測試三種測試。

39****、系統測試的策略有很多種的，有效能測試、負載測試、強度測試、易用性測試、安全測試、配置測試、安裝測試、文件測試、故障恢復測試、使用者介面測試、恢復測試、分佈測試、可用性測試。

40****、設計系統測試計劃需要參考的專案文件有軟體測試計劃、軟體需求工件、和迭代計劃

41****．通過畫因果圖來寫測試用例的步驟為****、****、****、****及把因果圖轉換為狀態圖共五個步驟。 ****利用因果圖生成測試用例的基本步驟是：

§ 分析軟體規格說明描述中，哪些是原因（即輸入條件或輸入條件的等價類），哪些是結果（即輸出條件），並給每個原因和結果賦予一個識別符號。

§ 分析軟體規格說明描述中的語義，找出原因與結果之間，原因與原因之間對應的是什麼關係? 根據這些關係，畫出因果圖。

§ 由於語法或環境限制，有些原因與原因之間，原因與結果之間的組合情況不可能出現。為表明這些特殊情況，在因果圖上用一些記號標明約束或限制條件。 § 把因果圖轉換成判定表。

§ 把判定表的每一列拿出來作為依據，設計測試用例。

43****、請說出這些測試最好由那些人員完成，測試的是什麼？

程式碼、函式級測試一般由白盒測試人員完成，他們針對每段程式碼或函式進行正確性檢驗，檢查其是否正確的實現了規定的功能。

模組、元件級測試主要依據是程式結構設計測試模組間的整合和呼叫關係，一般由測試人員完成。

系統測試在於模組測試與單元測試的基礎上進行測試。瞭解系統功能與效能，根據測試用例進行全面的測試。

44****、 ****設計測試用例時應該考慮哪些方面，即不同的測試用例針對那些方面進行測試？

設計測試用例時需要注意的是，除了對整體流程及功能注意外，還要注意強度測試、效能測試、壓力測試、邊界值測試、穩定性測試、安全性測試等多方面。（測試用例需要考慮的四個基本要素是輸入、輸出、操作和測試環境；另外，測試用例需要考慮的是測試型別（功能、效能、安全……），這部分可以參照TP做答。此外，還需要考慮用例的重要性和優先順序）

45****、 ****在windows****下儲存一個文字檔案時會彈出儲存對話方塊，如果為檔名建立測試用例，等價類應該怎樣劃分？

單位元組，如A；雙位元組， AA、我我；特殊字元 /‘。‘；、=-等；保留字，如com；檔案格式為8.3格式的；檔名格式為非8.3格式的；/,,*等九個特殊字元。

46****、假設有一個文字框要求輸入10****個字元的郵政編碼，對於該文字框應該怎樣劃分等價類？

特殊字元，如10個*或￥；英文字母，如ABCDefghik；小於十個字元，如123；大於十個字元，如11111111111；數字和其他混合，如123AAAAAAA；空字元；保留字元

47.****軟體測試專案從什麼時候開始，？為什麼？ 軟體測試應該在需求分析階段就介入,因為測試的物件不僅僅是程式編碼,應該對軟體開發過程中產生的所有產品都測試,並且軟體缺陷存在放大趨勢.缺陷發現的越晚,修復它所花費的成本就越大.

48****、什麼是迴歸測試?

迴歸測試: (regression testing): 迴歸測試有兩類：用例迴歸和錯誤迴歸；用例迴歸是過一段時間以後再回頭對以前使用過的用例在重新進行測試，看看會重新發現問題。錯誤迴歸，就是在新版本中，對以前版本中出現並修復的缺陷進行再次驗證，並以缺陷為核心，對相關修改的部分進行測試的方法。

**49.****單元測試、整合測試、系統測試的側重點是什麼？ **
單元測試針對的是軟體設計的最小單元--程式模組（程式導向中是函式、過程；物件導向中是類。）,進行正確性檢驗的測試工作,在於發現每個程式模組內部可能存在的差錯.一般有兩個步驟:人工靜態檢查\動態執行跟蹤
整合測試針對的是通過了單元測試的各個模組所整合起來的元件進行檢驗,其主要內容是各個單元模組之間的介面,以及各個模組整合後所實現的功能.
系統測試針對的是整合好的軟體系統，作為整個計算機系統的一個元素,與計算機硬體\外設\某些支援軟體\資料和人員等其他系統元素結合在一起,要在實際的執行環境中,對計算機系統進行一系列的整合測試和確認測試.

51.****一個測試工程師應具備那些素質？ 1、責任心2、溝通能力3、團隊合作精神4、耐心、細心、信心5、時時保持懷疑態度，並且有缺陷預防的意識6、具備一定的程式設計經驗

53****：你所瞭解的的軟體測試型別都有哪些，簡單介紹一下。

按測試策略分類：1、靜態與動態測試2、黑盒與白盒測試 3、手工和自動測試 4、冒煙測試 5、迴歸測試；

按測試階段分類：單元測試、整合測試、系統測試；

其他常見測試方法：1、功能測試 2、效能測試 3、壓力測試 4、負載測試 5、易用性測試 6、安裝測試 7、介面測試 8、配置測試 9、文件測試 10、相容性測試 11、安全性測試 12、恢復測試

54****：你認為做好測試計劃工作的關鍵是什麼？

明確測試的目標，增強測試計劃的實用性

編寫軟體測試計劃得重要目的就是使測試過程能夠發現更多的軟體缺陷，因此軟體測試計劃的價值取決於它對幫助管理測試專案，並且找出軟體潛在的缺陷。因此，軟體測試計劃中的測試範圍必須高度覆蓋功能需求，測試方法必須切實可行，測試工具並且具有較高的實用性，便於使用，生成的測試結果直觀、準確

堅持“5W”規則，明確內容與過程

“5W”規則指的是“What（做什麼）”、“Why（為什麼做）”、“When（何時做）”、“Where（在哪裡）”、“How（如何做）”。利用“5W”規則建立軟體測試計劃，可以幫助測試團隊理解測試的目的（Why），明確測試的範圍和內容（What），確定測試的開始和結束日期（When），指出測試的方法和工具（How），給出測試文件和軟體的存放位置（Where）。

採用評審和更新機制，保證測試計劃滿足實際需求

測試計劃寫作完成後，如果沒有經過評審，直接傳送給測試團隊，測試計劃內容的可能不準確或遺漏測試內容，或者軟體需求變更引起測試範圍的增減，而測試計劃的內容沒有及時更新，誤導測試執行人員。

分別建立測試計劃與測試詳細規格、測試用例

應把詳細的測試技術指標包含到獨立建立的測試詳細規格文件，把用於指導測試小組執行測試過程的測試用例放到獨立建立的測試用例文件或測試用例管理資料庫中。測試計劃和測試詳細規格、測試用例之間是戰略和戰術的關係，測試計劃主要從巨集觀上規劃測試活動的範圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。

55****：您認為做好測試用例設計工作的關鍵是什麼？

白盒測試用例設計的關鍵是以較少的用例覆蓋儘可能多的內部程式邏輯結果

黑盒法用例設計的關鍵同樣也是以較少的用例覆蓋模組輸出和輸入介面。不可能做到完全測試，以最少的用例在合理的時間內發現最多的問題

56****：你的測試職業發展目標是什麼？

測試經驗越多，測試能力越高。所以我的職業發展是需要時間累積的，一步步向著高階測試工程師奔去。而且我也有初步的職業規劃，前3年累積測試經驗，不斷的更新自己改正自己，做好測試任務。

57****：測試結束的標準是什麼？

從微觀上來說，在測試計劃中定義，比如系統在一定效能下平穩執行72小時，目前Bug Tracking System中，本版本中沒有一般嚴重的BUG，普通BUG的數量在3以下，BUG修復率90%以上等等引數，然後由開發經理，測試經理，專案經理共同簽字認同版本Release。

如果說巨集觀的，則是當這個軟體徹底的消失以後，測試就結束了。

59****、一套完整的測試應該由哪些階段組成？
可行性分析、需求分析、概要設計、詳細設計、編碼、單元測試、整合測試、系統測試、驗收測試

61****、您是否瞭解以往所工作的企業的軟體開發過程？如果瞭解，請試述一個完整的開發過程需要完成哪些工作？分別由哪些不同的角色來完成這些工作？您在以往的測試工作中都曾經具體從事過哪些工作？其中最擅長哪部分工作？

開發過程---需求調研（需求人員）、需求分析（需求人員）、概要設計（設計人員）、詳細設計(設計人員)、編碼（開發人員）

測試過程---需求評審、系統測試設計、概要設計評審、整合測試設計、詳細設計評審、單元測試設計、測試執行

測試工作的整個過程都做過，擅長做測試設計

過程決定質量，軟體的過程改進正是為了提高軟體的質量，將過往的種種經驗教訓積累起來。

62****、測試用例設計的原則是什麼？目前主要的測試用例設計方法有哪些？

代表性：能夠代表並覆蓋各種合理的和不合理、合法的和非法的、邊界的和越界的、以及極限的輸入資料、操作和環境設定等.

可判定性：即測試執行結果的正確性是可判定的，每一個測試用例都應有相應的期望結果.

可再現性：即對同樣的測試用例，系統的執行結果應當是相同的。

方法有等價類、邊界值、因果圖、狀態圖、正交法、大綱法

63****、物件導向的測試用例設計有幾種方法？如何實現？

給類中的每個建構函式設計一組測試用例

組合類中的類變數、例項變數

組合類中的各種方法

根據前置條件和後置條件設計測試用例

根據程式碼設計測試用例

64****、LoadRunner****分為哪三個模組？請簡述各模組的主要功能。

Virtual User Generator：用於錄製腳步

Mercury LoadRunner Controller：用於建立、執行和監控場景

Mercury LoadRunner Analysis：用於分析測試結果

65****、你對測試最大的興趣在哪裡？為什麼？

最大的興趣就是測試有難度，有挑戰性！做測試越久越能感覺到做好測試有多難。曾經在無憂測試網上看到一篇文章，是關於如何做好一名測試工程師。一共羅列了11，12點，有部分是和人的性格有關，有部分需要後天的努力。但除了性格有關的1，2點我沒有把握，其他點我都很有信心做好它。

剛開始進入測試行業時，對測試的認識是從無憂測試網上了解到的一些資料，當時是衝著做測試需要很多技能才能做的好，雖然入門容易，但做好很難，比開發更難，雖然當時我很想做開發（學校專業課我基本上不缺席，因為我喜歡我的專業），但看到測試比開發更難更有挑戰性，想做好測試的意志就更堅定了。

我覺得做測試整個過程中有2點讓我覺得很有難度（對我來說，有難度的東西我就非常感興趣），第一是測試用例的設計，因為測試的精華就在測試用例的設計上了，要在版本出來之前，把用例寫好，用什麼測試方法寫？（也就是測試計劃或測試策略），如果你剛測試一個新任務時，你得花一定的時間去消化業務需求和技術基礎，業務需求很好理解（多和產品經理和開發人員溝通就能達到目的），而技術基礎可就沒那麼簡單了，這需要你自覺的學習能力，比如說網站吧，最基本的技術知識你要知道網站內部是怎麼運作的的，後臺是怎麼響應使用者請求的？測試環境如何搭建？這些都需要最早的學好。至少在開始測試之前能做好基本的準備，可能會遇到什麼難題？需求細節是不是沒有確定好？這些問題都能在設計用例的時候發現。

第二是發現BUG的時候了，這應該是測試人員最基本的任務了，一般按測試用例開始測試就能發現大部分的bug，還有一部分bug需要測試的過程中更瞭解所測版本的情況獲得更多資訊，補充測試用例，測試出bug。還有如何發現bug？這就需要在測試用例有效的情況下，通過細心和耐心去發現bug了，每個用例都有可能發現bug，每個地方都有可能出錯，所以測試過程中思維要清晰（測試過程資料流及結果都得看仔細了，bug都在裡面發現的）。如何描述bug也很有講究，bug在什麼情況下會產生，如果條件變化一點點，就不會有這個bug，以哪些最少的操作步驟就能重現這個bug，這個bug產生的規律是什麼？如果你夠厲害的話，可以幫開發人員初步定位問題。

66****、您所熟悉的軟體測試型別都有哪些？請試著分別比較這些不同的測試型別的區別與聯絡（如功能測試、效能測試……） 　　測試型別有：功能測試，效能測試，介面測試。
　　功能測試在測試工作中佔的比例最大，功能測試也叫黑盒測試。是把測試物件看作一個黑盒子。利用黑盒測試法進行動態測試時，需要測試軟體產品的功能，不需測試軟體產品的內部結構和處理過程。採用黑盒技術設計測試用例的方法有：等價類劃分、邊界值分析、錯誤推測、因果圖和綜合策略。
　　效能測試是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項效能指標進行測試。負載測試和壓力測試都屬於效能測試，兩者可以結合進行。通過負載測試，確定在各種工作負載下系統的效能，目標是測試當負載逐漸增加時，系統各項效能指標的變化情況。壓力測試是通過確定一個系統的瓶頸或者不能接收的效能點，來獲得系統能提供的最大服務級別的測試。
　　介面測試，介面是軟體與使用者互動的最直接的層，介面的好壞決定使用者對軟體的第一印象。而且設計良好的介面能夠引導使用者自己完成相應的操作，起到嚮導的作用。同時介面如同人的面孔，具有吸引使用者的直接優勢。設計合理的介面能給使用者帶來輕鬆愉悅的感受和成功的感覺，相反由於介面設計的失敗，讓使用者有挫敗感，再實用強大的功能都可能在使用者的畏懼與放棄中付諸東流。
　　區別在於，功能測試關注產品的所有功能上，要考慮到每個細節功能，每個可能存在的功能問題。效能測試主要關注於產品整體的多使用者併發下的穩定性和健壯性。介面測試更關注於使用者體驗上，使用者使用該產品的時候是否易用，是否易懂，是否規範（快捷鍵之類的），是否美觀（能否吸引使用者的注意力），是否安全（儘量在前臺避免使用者無意輸入無效的資料，當然考慮到體驗性，不能太粗魯的彈出警告）？做某個效能測試的時候，首先它可能是個功能點，首先要保證它的功能是沒問題的，然後再考慮該功能點的效能測試

67****、請試著比較一下黑盒測試、白盒測試、單元測試、整合測試、系統測試、驗收測試的區別與聯絡。 　　黑盒測試：已知產品的功能設計規格，可以進行測試證明每個實現了的功能是否符合要求。
　　白盒測試：已知產品的內部工作過程，可以通過測試證明每種內部操作是否符合設計規格要求，所有內部成分是否以經過檢查。
　　軟體的黑盒測試意味著測試要在軟體的介面處進行。這種方法是把測試物件看做一個黑盒子，測試人員完全不考慮程式內部的邏輯結構和內部特性，只依據程式的需求規格說明書，檢查程式的功能是否符合它的功能說明。因此黑盒測試又叫功能測試或資料驅動測試。黑盒測試主要是為了發現以下幾類錯誤：
　　1、是否有不正確或遺漏的功能？2、在介面上，輸入是否能正確的接受？能否輸出正確的結果？3、是否有資料結構錯誤或外部資訊（例如資料檔案）訪問錯誤？4、效能上是否能夠滿足要求？5、是否有初始化或終止性錯誤？
　　軟體的白盒測試是對軟體的過程性細節做細緻的檢查。這種方法是把測試物件看做一個開啟的盒子，它允許測試人員利用程式內部的邏輯結構及有關資訊，設計或選擇測試用例，對程式所有邏輯路徑進行測試。通過在不同點檢查程式狀態，確定實際狀態是否與預期的狀態一致。因此白盒測試又稱為結構測試或邏輯驅動測試。白盒測試主要是想對程式模組進行如下檢查：
　　1、對程式模組的所有獨立的執行路徑至少測試一遍。
　　2、對所有的邏輯判定，取“真”與取“假”的兩種情況都能至少測一遍。
　　3、在迴圈的邊界和執行的界限內執行迴圈體。
　　4、測試內部資料結構的有效性，等等。
　　單元測試（模組測試）是開發者編寫的一小段程式碼，用於檢驗被測程式碼的一個很小的、很明確的功能是否正確。通常而言，一個單元測試是用於判斷某個特定條件（或者場景）下某個特定函式的行為。
　　單元測試是由程式設計師自己來完成，最終受益的也是程式設計師自己。可以這麼說，程式設計師有責任編寫功能程式碼，同時也就有責任為自己的程式碼編寫單元測試。執行單元測試，就是為了證明這段程式碼的行為和我們期望的一致。
　　整合測試（也叫組裝測試，聯合測試）是單元測試的邏輯擴充套件。它的最簡單的形式是：兩個已經測試過的單元組合成一個元件，並且測試它們之間的介面。從這一層意義上講，元件是指多個單元的整合聚合。在現實方案中，許多單元組合成元件，而這些元件又聚合成程式的更大部分。方法是測試片段的組合，並最終擴充套件程式，將您的模組與其他組的模組一起測試。最後，將構成程式的所有模組一起測試。
　　系統測試是將經過測試的子系統裝配成一個完整系統來測試。它是檢驗系統是否確實能提供系統方案說明書中指定功能的有效方法。（常見的聯調測試）
　　系統測試的目的是對最終軟體系統進行全面的測試，確保最終軟體系統滿足產品需求並且遵循系統設計。
　　驗收測試是部署軟體之前的最後一個測試操作。驗收測試的目的是確保軟體準備就緒，並且可以讓終端使用者將其用於執行軟體的既定功能和任務。
驗收測試是向未來的使用者表明系統能夠像預定要求那樣工作。經整合測試後，已經按照設計把所有的模組組裝成一個完整的軟體系統，介面錯誤也已經基本排除了，接著就應該進一步驗證軟體的有效性，這就是驗收測試的任務，即軟體的功能效能如同使用者所合理期待的那樣。

68****、當開發人員說不是BUG****時，你如何應付？ 　　開發人員說不是bug，有2種情況，一是需求沒有確定，所以我可以這麼做，這個時候可以找來產品經理進行確認，需不需要改動，3方商量確定好後再看要不要改。二是這種情況不可能發生，所以不需要修改，這個時候，我可以先儘可能的說出是BUG的依據是什麼？如果被使用者發現或出了問題，會有什麼不良結果？程式設計師可能會給你很多理由，你可以對他的解釋進行反駁。如果還是不行，那我可以給這個問題提出來,跟開發經理和測試經理進行確認,如果要修改就改,如果不要修改就不改。其實有些真的不是bug，我也只是建議的方式寫進TD中，如果開發人員不修改也沒有大問題。如果確定是bug的話，一定要堅持自己的立場，讓問題得到最後的確認。

69****、為什麼要在一個團隊中開展軟體測試工作？

因為沒有經過測試的軟體很難在釋出之前知道該軟體的質量，就好比ISO質量認證一樣，測試同樣也需要質量的保證，這個時候就需要在團隊中開展軟體測試的工作。在測試的過程發現軟體中存在的問題，及時讓開發人員得知並修改問題，在即將釋出時，從測試報告中得出軟體的質量情況。

71****、一份測試計劃應該包括哪些內容？

背景、專案簡介、目的、測試範圍、測試策略、人員分工、資源要求、進度計劃、參考文件、常用術語、提交文件、風險分析。

72****、針對於軟體的行業背景，你如何理解軟體的業務？

閱讀使用者手冊瞭解軟體的功能和操作流程；看一些業務的專業書籍補充業務知識；如果有使用者實際的資料，可以拿實際的資料進行參考；參考以前的用例和BUG報告；在使用軟體的過程中多思考；多與產品經理交流。

74****、如何定位測試用例的作用？

組織性：編寫、組織性、功能覆蓋、重複性、跟蹤、測試確認

76****、什麼是相容性測試？請舉例說明如何利用相容性測試列表進行測試。

主要驗證軟體產品在不同版本之間的相容性。包括向下相容和交錯相容，向下相容是測試軟體新版本保留它早期版本功能的情況，交錯相容是驗證共同存在的兩個相關但不相同的產品之間的相容性。

77****、對某軟體進行測試，發現在WIN98****上執行得很慢，怎麼判別是該軟體存在問題還是其軟硬體執行環境存在問題？

看軟體的執行環境要求。如果符合要求則是程式存在問題，若不符合要求則是硬體系統存在問題

78****、需求測試的注意事項有哪些？

是否使用了公司的模板、文件內容是否符合規範、所有的需求是分級是否清析適當、所有的需求是否具有一致性、需求是否可行（即，該需求組合有解決方案）、需求可否用己知的約束來實現、需求是否足夠（即，可以把它送到一個規範的開發組織，並有一個生產出所需要產品的合理的可能性）、所有的其它需求是交叉引用是否正確、使用者描述是否清楚、是否用客戶的語言來描述需求、每個需求描述是否清楚沒有岐義，可以移交給一個獨立的組去實現時也能理解、是否所有的需求都是可驗證的、是否每條需求都具有獨立性，即使發生了變化也不會影響其它需求、效能指標是否明確、非功能性需求是否得到充分表現、是否完整列出適用的標準或協議、標準和協議之間是否存在衝突

81****、主鍵、外來鍵的作用，索引的優點與不足?

答：主鍵：是表中的唯一標示鍵。作用：保證實體的完整性;加快資料庫的操作速度;增加新的表記錄時，資料庫會自動檢索新記錄的主鍵值，不允許該值與其他表中記錄的主鍵重複;資料庫會按主鍵值的順序顯示記錄，如果沒有設定主鍵，則按輸入的順序顯示記錄。

外來鍵：是主鍵的從屬，表示了兩個表之間的聯絡。作用：使用外來鍵可以避免冗餘。

索引的優點： 1、通過建立唯一性的索引，可以保證表中資料的唯一性; 2、加速資料的檢索速度; 3、加快表與表之間的連線; 4、在使用分組與排序資料檢索時，可以顯著檢索分組與排序的時間; 5、在查詢的過程中使用優化隱藏器，提供系統效能。

缺點： 1、建立索引需要時間，且隨著資料量的增加而增加; 2、索引需要佔用物理空間;

    3、當對錶中資料進行修改時，索引也要動態維護，降低了資料的維護速度。

84****、效能測試的流程?

1.測試需求分析2.測試計劃制定與評審3.測試用例設計與開發4.測試執行與監控5.分析測試結果6.編寫效能測試報告7.測試經驗總結

88****、簡述bug****的生命週期?

1， 有效地記錄BUG 2， 使用BUG模板 3， 評價BUG優先順序和嚴重性 4， BUG的生命 5， 維護BUG資料庫

89****、缺陷記錄應包含的內容?

缺陷標識、缺陷型別、缺陷嚴重程度、缺陷產生可能性、缺陷優先順序、缺陷狀態、缺陷起源、缺陷來源、缺陷原因;

91 ****您所熟悉的軟體測試型別都有哪些?****請試著分別比較這些不同的測試型別的區別與聯絡(****如功能測試、效能測試……)

易用性測試-介面的友好性，操作方便性等。

功能測試-系統中功能性需求的滿足

安全性測試-系統是否存在安全隱患和漏洞

效能測試-系統在大併發下的響應速度和健壯性

93****、您認為做好測試計劃工作的關鍵是什麼?

瞭解專案或系統的業務需求

和專案經理協調好，瞭解專案的進度計劃安排情況

95****您認為做好測試用例設計工作的關鍵是什麼?

對業務和軟體需求非常清楚，可以根據需求不同選擇不同的測試用例設計

96****、.****您以往的工作中是否曾開展過測試用例的評審工作?****如果有，請描述測試用例評審的過程和評審的內容。

評審計劃->預審->評審;

評審內容主要是測試用例對軟體需求的覆蓋程度，對於相關邊界是否考慮，是否針對複雜流程準備多套測試資料，是否有專門針對非功能性需求的測試。

98.您認為效能測試工作的目的是什麼?做好效能測試工作的關鍵是什麼?

關鍵是測試指令碼的錄製，測試時候測試環境的乾淨。

100、.您以往所從事的軟體測試工作中，是否使用了一些工具來進行軟體缺陷(Bug)的管理?如果有，請結合該工具描述軟體缺陷(Bug)跟蹤管理的流程。

CQ，也可以使用BugFree等免費工具。

101、.您如何看待軟體過程改進?在您曾經工作過的企業中，是否有一些需要改進的東西呢?您期望的理想的測試人員的工作環境是怎樣的?

將先進的經驗或思想固化到過程中，通過過程改進和能力提高來改進軟體質量。