1.問：你在測試中發現了一個 bug ，可是開發經理認爲這不是一個 bug ，你應該怎樣解決。
首先，將問題提交到缺陷管理庫，相似禪道，進行備案，
根據需求文檔，產品說明，設計文檔等，確認實際結果是否與計劃有不一致的地方，
若是沒有文檔，能夠根據相似軟件的通常特性來講明是否存在不一致的地方，來確認是不是缺陷；
根據通常用戶的使用習慣，來確認
與設計人員、開發人員和客戶表明等相關人員探討，確認是不是缺陷；
合理的論述，向測試經理說明本身的判斷的理由，注意客觀、嚴謹，不參雜我的情緒
等待測試經理作出最終決定，若是仍然存在爭議，能夠經過公司政策所提供的渠道，向上級反映，並由上級作出決定。
2. 給你一個網站，你如何測試？
首先，查找需求說明、網站設計等相關文檔，分析測試需求。面試
制定測試計劃，肯定測試範圍和測試策略，通常包括如下幾個部分：功能性測試；界面測試；性能測試；數據庫測試；安全性測試；兼容性測試數據庫
設計測試用例：編程
功能性測試能夠包括，但不限於如下幾個方面：瀏覽器
連接測試。連接是否正確跳轉，是否存在空頁面和無效頁面，是否有不正確的出錯信息返回。
提交功能的測試。
多媒體元素是否能夠正確加載和顯示。
多語言支持是否可以正確顯示選擇的語言等。
界面測試能夠包括但不限於一下幾個方面：安全
頁面是否風格統一，美觀
頁面佈局是否合理，重點內容和熱點內容是否突出
控件是否正常使用
對於必須但未安裝的控件，是否提供自動下載並安裝的功能
文字檢查
性能測試通常從如下兩個方面考慮：網絡
壓力測試；負載測試；強度測試函數
數據庫測試要具體決定是否須要開展。數據庫通常須要考慮連結性，對數據的存取操做，數據內容的驗證等方面。工具
安全性測試：佈局
基本的登陸功能的檢查
是否存在溢出錯誤，致使系統崩潰或者權限泄露
相關開發語言的常見安全性問題檢查，例如SQL注入等
若是須要高級的安全性測試，肯定得到專業安全公司的幫助，外包測試，或者獲取支持
兼容性測試，根據需求說明的內容，肯定支持的平臺組合：性能
瀏覽器的兼容性；
操做系統的兼容性；
軟件平臺的兼容性；
數據庫的兼容性
開展測試，並記錄缺陷。合理的安排調整測試進度，提早獲取測試所需的資源，創建管理體系（例如，需求變動、風險、配置、測試文檔、缺陷報告、人力資源等內容）。
按期評審，對測試進行評估和總結，調整測試的內容
3.目前主要的測試用例設計方法是什麼？
白盒測試：邏輯覆蓋、循環覆蓋、基本路徑覆蓋
黑盒測試：邊界值分析法、等價類劃分、錯誤猜想法、因果圖法、狀態圖法、測試大綱法、隨機測試、場景法
4.軟件產品質量特性是什麼?
功能性：適應性、準確性、互操做性、依從性、安全性。
可靠性：成熟性、容錯性、易恢復性。
可以使用性：易理解性、易學習性、易操做性。
效率：時間特性、資源特性。
可維護性：易分析性、易變動性、穩定性、易測試性。
可移植性： 適應性、易安裝性、遵循性、易替換性
5.軟件測試分爲幾個階段 各階段的測試策略和要求是什麼?
和開發過程相對應，測試過程會依次經歷單元測試、集成測試、系統測試、驗收測試四個主要階段：
單元測試：單元測試是針對軟件設計的最小單位––程序模塊甚至代碼段進行正確性檢驗的測試工做，一般由開發人員進行。
集成測試：集成測試是將模塊按照設計要求組裝起來進行測試，主要目的是發現與接口有關的問題。因爲在產品提交到測試部門前，產品開發小組都要進行聯合調試，所以在大部分企業中集成測試是由開發人員來完成的。
系統測試：系統測試是在集成測試經過後進行的，目的是充分運行系統，驗證各子系統是否都能正常工做並完成設計的要求。它主要由測試部門進行，是測試部門最大最重要的一個測試，對產品的質量有重大的影響。
驗收測試：驗收測試以需求階段的《需求規格說明書》爲驗收標準，測試時要求模擬實際用戶的運行環境。對於實際項目能夠和客戶共同進行，對於產品來講就是最後一次的系統測試。測試內容爲對功能模塊的全面測試，尤爲要進行文檔測試。
單元測試測試策略：
自頂向下的單元測試策略：比孤立單元測試的成本高不少，不是單元測試的一個好的選擇。
自底向上的單元測試策略：比較合理的單元測試策略，但測試周期較長。
孤立單元測試策略：最好的單元測試策略。
集成測試的測試策略：
大爆炸集成：適應於一個維護型項目或被測試系統較小
自頂向下集成：適應於產品控制結構比較清晰和穩定；高層接口變化較小；底層接口未定義或常常可能被修改；產口控制組件具備較大的技術風險，須要儘早被驗證；但願儘早能看到產品的系統功能行爲。
自底向上集成：適應於底層接口比較穩定；高層接口變化比較頻繁；底層組件較早被完成。
基於進度的集成
優勢：具備較高的並行度；可以有效縮短項目的開發進度。
缺點：樁和驅動工做量較大；有些接口測試不充分；有些測試重複和浪費。
系統測試的測試策略：
數據和數據庫完整性測試；功能測試；用戶界面測試；性能評測；負載測試；強度測試；容量測試；安全性和訪問控制測試；故障轉移和恢復測試；配置測試；安裝測試；加密測試；可用性測試；版本驗證測試；文檔測試
6.測試人員在軟件開發過程當中的任務是什麼？
一、儘量早的找出系統中的Bug；
二、避免軟件開發過程當中缺陷的出現；
三、衡量軟件的品質，保證系統的質量；
四、關注用戶的需求，並保證系統符合用戶需求。
總的目標是：確保軟件的質量。
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.一個測試工程師應具有那些素質？
一、責任心
二、溝通能力
三、團隊合做精神
四、耐心、細心、信心
五、時時保持懷疑態度，而且有缺陷預防的意識
六、具有必定的編程經驗
20.你所瞭解的的軟件測試類型都有哪些，簡單介紹一下。
按測試 策略分類：
一、靜態與動態測試
二、黑盒與白盒測試
三、手工和自動測試
四、冒煙測試
五、迴歸測試；
按測試階段分類：單元測試、集成測試、系統測試；
其餘常見測試方法：一、功能測試 二、性能測試 三、壓力測試 四、負載測試 五、易用性測試 六、安裝測試 七、界面測試 八、配置測試 九、文檔測試 十、兼容性測試 十一、安全性測試 十二、恢復測試
21.你認爲作好測試計劃工做的關鍵是什麼？
明確測試的目標，加強測試計劃的實用性
採用評審和更新機制，保證測試計劃知足實際需求
分別建立測試計劃與測試詳細規格、測試用例
22.軟件測試分哪些階段？各階段的含義？
分爲單元測試、集成測試、確認測試、系統測試、驗收測試。單元測試是最小單位的測試，測試獨立模塊；
集成測試主要測試模塊之間的接口是否正常，
確認測試相似於冒煙測試一般在大規模系統測試以前驗證版本主要功能是否實現，版本的穩定性是否能夠進入系統測試，
系統測試是全面測試驗證系統是否知足用戶需求包括功能、性能、兼容性等等。
驗收測試是用戶參與的測試。
23.一份測試計劃應該包括哪些內容？
背景、項目簡介、目的、測試範圍、測試策略、人員分工、資源要求、進度計劃、參考文檔、經常使用術語、提交文檔、風險分析。
24.需求測試的注意事項有哪些？
是否使用了公司的模板 文檔內容是否符合規範 全部的需求是分級是否清析適當？ 全部的需求是否具備一致性 需求是否可行（即，該需求組合有解決方案） 需求能否用己知的約束來實現 需求是否足夠（即，能夠把它送到一個規範的開發組織，並有一個生產出所須要產品的合理的可能性） 全部的其它需求是交叉引用是否正確 用戶描述是否清楚 是否用客戶的語言來描述需求 每一個需求描述是否清楚沒有岐義，能夠移交給一個獨立的組去實現時也能理解 是否全部的需求都是可驗證的 是否每條需求都具備獨立性，即便發生了變化也不會影響其它需求 性能指標是否明確 非功能性需求是否獲得充分表現 是否完整列出適用的標準或協議 標準和協議之間是否存在衝突