1.問：你在測試中發現了一個 bug ，但是開發經理認為這不是一個 bug ，你應該怎樣解決。 首先，將問題提交到缺陷管理庫，類似禪道，進行備案， 根據需求文件，產品說明，設計文件等，確認實際結果是否與計劃有不一致的地方， 如果沒有文件，可以根據類似軟體的一般特性來說明是否存在不一致的地方，來確認是否是缺陷； 根據一般使用者的使用習慣，來確認 與設計人員、開發人員和客戶代表等相關人員探討，確認是否是缺陷； 合理的論述，向測試經理說明自己的判斷的理由，注意客觀、嚴謹，不參雜個人情緒 等待測試經理做出最終決定，如果仍然存在爭議，可以通過公司政策所提供的渠道，向上級反映，並由上級做出決定。 2. 給你一個網站，你如何測試？ 首先，查詢需求說明、網站設計等相關文件，分析測試需求。

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

設計測試用例：

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

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

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

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

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

安全性測試：

基本的登入功能的檢查 是否存在溢位錯誤，導致系統崩潰或者許可權洩露 相關開發語言的常見安全性問題檢查，例如SQL注入等 如果需要高階的安全性測試，確定獲得專業安全公司的幫助，外包測試，或者獲取支援 相容性測試，根據需求說明的內容，確定支援的平臺組合：

瀏覽器的相容性； 作業系統的相容性； 軟體平臺的相容性； 資料庫的相容性 開展測試，並記錄缺陷。合理的安排調整測試進度，提前獲取測試所需的資源，建立管理體系（例如，需求變更、風險、配置、測試文件、缺陷報告、人力資源等內容）。

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

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

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

黑盒測試：邊界值分析法、等價類劃分、錯誤猜測法、因果圖法、狀態圖法、測試大綱法、隨機測試、場景法 4.軟體產品質量特性是什麼?

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

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

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

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

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

可移植性： 適應性、易安裝性、遵循性、易替換性 5.軟體測試分為幾個階段 各階段的測試策略和要求是什麼?

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

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

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

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

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

整合測試的測試策略：

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

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

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

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

系統測試的測試策略：

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

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

1、儘可能早的找出系統中的Bug； 2、避免軟體開發過程中缺陷的出現； 3、衡量軟體的品質，保證系統的質量； 4、關注使用者的需求，並保證系統符合使用者需求。 總的目標是：確保軟體的質量。 7.一條 Bug 記錄最基本應包含：編號、Bug 所屬模組、Bug 描述、Bug 級別、發現日期、發現人、修改日期、修改人、修改方法、迴歸結果等等； 要有效的發現 Bug 需參考需求以及詳細設計等前期文件設計出高效的測試用例，然後嚴格執行測試用例，對發現的問題要充分確認肯定，然後再向外發布如此才能提高提交 Bug 的質量。

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

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

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

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

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

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

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

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

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

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

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

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

壓力測試：用根針並在針上面不斷加重量，看壓強多大時會穿透 10.詳細的描述一個測試活動完整的過程。

專案經理通過和客戶的交流，完成需求文件 由開發人員和測試人員共同完成需求文件的評審，評審的內容包括：需求描述不清楚的地方和可能有明顯衝突或者無法實現的功能的地方。 專案經理通過綜合開發人員，測試人員以及客戶的意見，完成專案計劃。然後 SQA 進入專案，開始進行統計和跟蹤 開發人員根據需求文件完成需求分析文件，測試人員進行評審，評審的主要內容包括是否有遺漏或者雙方理解不同的地方。 測試人員完成測試計劃文件，測試計劃包括的內容上面有描述。 測試人員根據修改好的需求分析文件開始寫測試用例，同時開發人員完成概要設計文件，詳細設計文件。此兩份文件成為測試人員撰寫測試用例的補充材料。 測試用例完成後，測試和開發需要進行評審。 測試人員搭建環境 開發人員提交第一個版本，可能存在未完成功能，需要說明。測試人員進行測試，發現 BUG後提交給 BugZilla。 開發提交第二個版本，包括 Bug Fix 以及增加了部分功能，測試人員進行測試。 重複上面的工作，一般是 3-4 個版本後 BUG 數量減少，達到出貨的要求。 如果有客戶反饋的問題，需要測試人員協助重現並重新測試。 11.黑盒測試的測試用例常見設計方法都有哪些？請分別以具體的例子來說明這些方法在測試用例設計工作中的應用。

等價類劃分 劃分等價類: 等價類是指某個輸入域的子集合.在該子集合中,各個輸入資料對於揭露程式中的錯誤都是等效的.併合理地假定:測試某等價類的代表值就等於對這一類其它值的測試. 因此,可以把全部輸入資料合理劃分為若干等價類,在每一個等價類中取一個數據作為測試的輸入條件,就可以用少量代表性的測試資料.取得較好的測試結果.等價類劃分可有兩種不同的情況:有效等價類和無效等價類. 邊界值分析法 邊界值分析方法是對等價類劃分方法的補充。測試工作經驗告訴我,大量的錯誤是發生在輸入或輸出範圍的邊界上,而不是發生在輸入輸出範圍的內部.因此針對各種邊界情況設計測試用例,可以查出更多的錯誤. 使用邊界值分析方法設計測試用例,首先應確定邊界情況.通常輸入和輸出等價類的邊界,就是應著重測試的邊界情況.應當選取正好等於,剛剛大於或剛剛小於邊界的值作為測試資料,而不是選取等價類中的典型值或任意值作為測試資料. 錯誤猜測法 基於經驗和直覺推測程式中所有可能存在的各種錯誤, 從而有針對性的設計測試用例的方法. 錯誤推測方法的基本思想: 列舉出程式中所有可能有的錯誤和容易發生錯誤的特殊情況,根據他們選擇測試用例. 例如, 在單元測試時曾列出的許多在模組中常見的錯誤. 以前產品測試中曾經發現的錯誤等, 這些就是經驗的總結. 還有, 輸入資料和輸出資料為 0 的情況.輸入表格為空格或輸入表格只有一行. 這些都是容易發生錯誤的情況. 可選擇這些情況下的例子作為測試用例. 因果圖方法 前面介紹的等價類劃分方法和邊界值分析方法,都是著重考慮輸入條件,但未考慮輸入條件之間的聯絡, 相互組合等. 考慮輸入條件之間的相互組合,可能會產生一些新的情況. 但要檢查輸入條件的組合不是一件容易的事情, 即使把所有輸入條件劃分成等價類,他們之間的組合情況也相當多. 因此必須考慮採用一種適合於描述對於多種條件的組合,相應產生多個動作的形式來考慮設計測試用例. 這就需要利用因果圖（邏輯模型）. 因果圖方法最終生成的就是判定表. 它適合於檢查程式輸入條件的各種組合情況. 正交表分析法 有時候，可能因為大量的引數的組合而引起測試用例數量上的激增，同時，這些測試用例並沒有明顯的優先順序上的差距，而測試人員又無法完成這麼多數量的測試，就可以通過正交表來進行縮減一些用例，從而達到儘量少的用例覆蓋儘量大的範圍的可能性。 場景分析方法 指根據使用者場景來模擬使用者的操作步驟，這個比較類似因果圖，但是可能執行的深度和可行性更好。 狀態圖法 通過輸入條件和系統需求說明得到被測系統的所有狀態，通過輸入條件和狀態得出輸出條件；通過輸入條件、輸出條件和狀態得出被測系統的測試用例。

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

儘量面對面的溝通，其次是能直接通過電話溝通，如果只能通過 Email 等非及時溝通工具的話，強調必須對特性的理解深刻以及能表達清楚。 運用一些測試管理工具如 禪道 進行管理也是較有效的方法，同時要注意在禪道中對 BUG 有準確的描述。 在團隊中建立測試人員與開發人員良好溝通中注意以下幾點： 一真誠 二是團隊精神 三是在專業上有共同語言 四是要對事不對人，工作至上 當然也可以通過直接指出一些小問題，

13.你對測試最大的興趣在哪裡？為什麼？

回答這個面試題，沒有固定統一的答案，但可能是許多企業都會問到的。提供以下答案供考： 最大的興趣，感覺這是一個有挑戰性的工作； 測試是一個經驗行業，工作越久越能感覺到做好測試的難度和樂趣 通過自己的工作，能使軟體產品越來越完善，從中體會到樂趣 回答此類問題注意以下幾個方面： 儘可能的切合招聘企業的技術路線來表達你的興趣，例如該企業是資料庫應用的企業，那麼表示你的興趣在資料庫的測試，並且希望通過測試提升自己的資料庫掌握能力。 表明你做測試的目的是為了提升能力，也是為了更好的做好測試；提升能力不是為了以後轉開發或其他的，除非用人企業有這樣的安排。 不要過多的表達你的興趣在招聘企業的範疇這外。

14.你自認為測試的優勢在哪裡？

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

15.請你分別畫出 I OSI 的七層網路結構圖和 P TCP/IP 的四層結構圖。

答：OSI 七層網路結構圖，由上至下： 應用層 ；表示層 ;會話層 ;傳輸層 ;網路層 ;資料鏈路層;物理層 TCP/IP 的四層結構圖 應用層;傳輸層;互聯層;鏈路層

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

自頂向下整合 優點：較早地驗證了主要控制和判斷點；按深度優先可以首先實現和驗證一個完整的軟體功能；功能較早證實，帶來信心；只需一個驅動，減少驅動器開發的費用；支援故障隔離。 缺點：柱的開發量大；底層驗證被推遲；底層元件測試不充分。 適應於產品控制結構比較清晰和穩定；高層介面變化較小；底層介面未定義或經常可能被修改；產口控制組件具有較大的技術風險，需要儘早被驗證；希望儘早能看到產品的系統功能行為。 自底向上整合 優點：對底層元件行為較早驗證；工作最初可以並行整合，比自頂向下效率高；減少了樁的工作量；支援故障隔離。 缺點：驅動的開發工作量大；對高層的驗證被推遲，設計上的錯誤不能被及時發現。 適應於底層介面比較穩定；高層介面變化比較頻繁；底層元件較早被完成。

17.什麼是白盒測試？什麼是黑盒測試? ? 什麼是迴歸測試? ?

白盒測試是測試人員要了解程式結構和處理過程,按照程式內部邏輯測試程式,檢查程式中的每條通路是否按照預定要求正確工作.它主要的針對被測程式的原始碼,測試者可以完全不考慮程式的功能. 白盒測試流程:詳細設計-->源程式-->分析程式內部邏輯結構-->流程圖-->制定測試用例-->被測程式-->執行路徑-->覆蓋情況分析 . 黑盒測試:（Black-box Testing，又稱為功能測試或資料驅動測試）是把測試物件看作一個黑盒子。利用黑盒測試法進行動態測試時，需要測試軟體產品的功能，不需測試軟體產品的內部結構和處理過程。 迴歸測試: (regression testing): 迴歸測試有兩類：用例迴歸和錯誤迴歸；用例迴歸是過一段時間以後再回頭對以前使用過的用例在重新進行測試，看看會重新發現問題。 錯誤迴歸，就是在新版本中，對以前版本中出現並修復的缺陷進行再次驗證，並以缺陷為核心，對相關修改的部分進行測試的方法。

18.單元測試、整合測試、系統測試的側重點是什麼？

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

19.一個測試工程師應具備那些素質？

1、責任心 2、溝通能力 3、團隊合作精神 4、耐心、細心、信心 5、時時保持懷疑態度，並且有缺陷預防的意識 6、具備一定的程式設計經驗 20.你所瞭解的的軟體測試型別都有哪些，簡單介紹一下。

按測試 策略分類： 1、靜態與動態測試 2、黑盒與白盒測試 3、手工和自動測試 4、冒煙測試 5、迴歸測試； 按測試階段分類：單元測試、整合測試、系統測試； 其他常見測試方法：1、功能測試 2、效能測試 3、壓力測試 4、負載測試 5、易用性測試 6、安裝測試 7、介面測試 8、配置測試 9、文件測試 10、相容性測試 11、安全性測試 12、恢復測試

21.你認為做好測試計劃工作的關鍵是什麼？

明確測試的目標，增強測試計劃的實用性 採用評審和更新機制，保證測試計劃滿足實際需求 分別建立測試計劃與測試詳細規格、測試用例

22.軟體測試分哪些階段？各階段的含義？

分為單元測試、整合測試、確認測試、系統測試、驗收測試。單元測試是最小單位的測試，測試獨立模組； 整合測試主要測試模組之間的介面是否正常， 確認測試類似於冒煙測試通常在大規模系統測試之前驗證版本主要功能是否實現，版本的穩定性是否可以進入系統測試， 系統測試是全面測試驗證系統是否滿足使用者需求包括功能、效能、相容性等等。 驗收測試是使用者參與的測試。

23.一份測試計劃應該包括哪些內容？

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

24.需求測試的注意事項有哪些？

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