自動化面試題一（1 -- 40）

1、自我介紹

　　先向面試官問好，介紹公司名及部門、自己負責的職務或從的具體工作。態度要保持自然隨和，語速要正常，敢於直視面試官的眼睛。

2、說一說你所知道的 Python 數據類型有哪些？

整型      int      整數
布爾型     bool    true/false
字符串     str     "abcd"
元祖      tuple    (tuple)
列表      list     [list]
字典      dict     {dict}

 

3、Python 中列表和元組的區別是什么？元組是不是真的不可變？

• 列表和元組根本區別在於，元組內元素不可變，列表內元素可變。元組內套一個列表改變列表內的值就可以

 

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

1. 首先，將問題提交到缺陷管理庫進行備案。
2. 然后，要獲取判斷的依據和標准：
3. 根絕需求說明書，產品說明、設計文檔等，確認實際結果是否與計划有不一致的地方，提供缺陷是都確認的直接依據；
4. 如果沒有文檔依據，根據類似軟件的一般特性來說明是否存在不一致的地方，來確認是否是缺陷；
5. 根據用戶的一般使用習慣，來確認是否是缺陷；
6. 與設計人員，開發人員和客戶代表等相關人員探討，確認是否是缺陷；
7. 合理論述，客觀嚴謹的向測試經理說明自己的判斷理由；
8. 等待測試經理做出最終決定，如果仍然存在爭議，可以通過公司政策所提供的渠道，向上級反應，並由上級做出決定

 

5、給你一個網站，你如何測試？

首先，查找需求說明、網站設計等相關文檔，分析測試需求；

制定測試計划，確定測試范圍和測試策略，一般包括以下及部分，功能性測試、界面測試、性能測試、數據庫測試、安全性測試、兼容性測試；

設計測試用例：

功能測試（包括不限於）：

• 鏈接測試。
  • 鏈接是否正確跳轉，是否存在空頁面和無效頁面，是否有不正確的出錯信息返回　　
• 瀏覽器兼容：
  • 是否都可以打開 鏈接配置類型是否都可以支持　　
• 提交功能的測試
• 多媒體元素是否可以正確加載和顯示
• 多語言支持是否能夠正確顯示選擇的語言

界面測試（包括但不限於）：

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

性能測試：

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

數據庫測試：

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

安全性測試：

• 基本的登陸功能的檢查
• 是否存在溢出錯誤，導致系統崩潰或者權限泄露
• 相關開發語言的常見安全性問題檢查，例如：SQL注入
• 如果需要高級的安全性問題，確定獲得專業安全公司的幫助，外包測試，或者獲取支持

兼容性測試，根據需求說明的內容，確定支持的平台組合：

• 瀏覽器的兼容性
• 操作系統的兼容性
• 軟件平台的兼容性
• 數據庫的兼容性

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

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

 

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

1. 建立測試計划，確定測試標准和測試范圍
2. 設計典型場景的測試用例，都改常用業務流程和不常用的業務流程等
3. 根據測試用例，開發自動化測試腳本和場景
4. 錄制測試腳本：新建一個腳本（Web/HTML協議）；點擊錄制按鈕，在彈出的對話框的URL中輸入”about:blank”；在打開的瀏覽器中進行正常操作流程后，結束錄制；調試腳本並保存，可能要注意到字符集的關聯。
5. 設置測試場景：針對性能設置測試場景，主要判斷在正常情況下，系統的平均事務響應時間是否達標；針對壓力負載設置測試場景，主要判斷在長時間處於滿負荷或者超出系統承載能力的條件下，系統是否會崩潰；執行測試，獲取測試結果，分析測試結果

 

7、目前主要的測試用例方法是？

• 白盒測試：路徑覆蓋、代碼走查、靜態分析

• 黑盒測試：邊界值分析，等價類划分，錯誤推測法，場景法，因果圖，狀態圖法

 

8、軟件測試安全性從哪幾個方面測試？

　　軟件安全性測試包括：程序、數據庫安全測試

用戶認證安全的測試要考慮問題：

1. 明確區分系統中不同用戶權限 、
2. 系統中會不會出現用戶沖突 、
3. 系統會不會因用戶的權限的改變造成混亂 、
4. 用戶登陸密碼是否是可見、可復制 、是否可以通過絕對途徑登陸系統（拷貝用戶登陸后的鏈接直接進入系統）、
5. 用戶退出系統后是否刪除了所有鑒權標記，是否可以使用后退鍵而不通過輸入口令進入系統 、

系統網絡安全的測試要考慮問題 ：

1. 測試采取的防護措施是否正確裝配好，
2. 有關系統的補丁是否打上 、
3. 模擬非授權攻擊，看防護系統是否堅固 、
4. 采用成熟的網絡漏洞檢查工具檢查系統相關漏洞（即用最專業的黑客攻擊工具攻擊試一下，現在最常用的是 NBSI 系列和 IPhacker IP ） 、
5. 采用各種木馬檢查工具檢查系統木馬情況 、
6. 采用各種防外掛工具檢查系統各組程序的外掛漏洞

數據庫安全考慮問題：

1. 系統數據是否機密、
2. 系統數據的完整性 、
3. 系統數據可管理性 、
4. 系統數據的獨立性 、
5. 系統數據可備份和恢復能力（數據備份是否完整，可否恢復，恢復是否可以完整）

 

9、什么是測試用例？什么是測試腳本？兩者關系？

• 測試用例：
  • 為實現測試而向被測試系統提供的輸入數據、操作或各種環境設置以及期望結果的一個特定的合集

• 測試腳本：
  • 為了進行自動化測試而編寫的腳本

• 關系：
  • 測試腳本的編寫必須對應相應的測試用例

 

10、簡述：靜態測試、動態測試、黑盒測試、白盒測試、α測試 、β測試

靜態測試：

• 不運行程序本身而尋找程序代碼中可能存在的錯誤或評估程序代碼的過程

動態測試：

• 實際運行被測程序，輸入相應的測試實例，檢查運行結果與預期結果的差異，判定執行結果是否符合要求，從而檢測程序的正確性、可靠性、有效性、並分析系統運行效率和健壯性等性能

黑盒測試：

• 一般用來確認軟件功能的正確性和可操作性，目的是檢測軟件的各個功能是否得以實現，把被測程序當作一個黑盒，不考慮其內部結構，在知道該程序的輸入和輸出之間的關系或程序功能的情況下，依靠軟件規格說明書來確定測試用例和推斷測試結果的正確性

白盒測試：

• 根據軟件內部的邏輯結構分析來進行測試，是基於代碼的測試，測試人員通過閱讀程序代碼或者通過使用開發工具中的單步調試來判斷軟件的質量，一般黑盒測試由項目經理在程序員開發中來實現。

α測試：

• 由一個用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操作環境下進行的受控測試，Alpha 測試不能由程序員或測試員完成

β測試：

• 軟件的多個用戶在一個或多個用戶的實際使用環境下進行的測試，開發者通常不在測試現場，Beta 測試不能由程序員或測試員完成

 

11、軟件測試分為幾個階段，各階段的測試策略和要求是什么？

和開發過程相對應，測試過程會依次經歷：

• 單元測試、集成測試、系統測試、驗收測試四個主要階段：

單元測試：

• 單元測試是針對軟件設計的最小單位––程序模塊甚至代碼段進行正確性檢驗的測試工作，通常由開發人員進行。

集成測試：

• 集成測試是將模塊按照設計要求組裝起來進行測試，主要目的是發現與接口有關的問題。由於在產品提交到測試部門前，產品開發小組都要進行聯合調試，因此在大部分企業中集成測試是由開發人員來完成的。

系統測試：

• 系統測試是在集成測試通過后進行的，目的是充分運行系統，驗證各子系統是否都能正常工作並完成設計的要求。它主要由測試部門進行，是測試部門最大最重要的一個測試，對產品的質量有重大的影響。

驗收測試：

• 驗收測試以需求階段的《需求規格說明書》為驗收標准，測試時要求模擬實際用戶的運行環境。對於實際項目可以和客戶共同進行，對於產品來說就是最后一次的系統測試。測試內容為對功能模塊的全面測試，尤其要進行文檔測試。

單元測試測試策略：

• 自頂向下的單元測試策略：比孤立單元測試的成本高很多，不是單元測試的一個好的選擇。
• 自底向上的單元測試策略：比較合理的單元測試策略，但測試周期較長。
• 孤立單元測試策略：最好的單元測試策略。

集成測試的測試策略：

• 大爆炸集成：適應於一個維護型項目或被測試系統較小
• 自頂向下集成：適應於產品控制結構比較清晰和穩定；高層接口變化較小；底層接口未定義或經常可能被修改；產口控制組件具有較大的技術風險，需要盡早被驗證；希望盡早能看到產品的系統功能行為。
• 自底向集成：適應於底層接口比較穩定；高層接口變化比較頻繁；底層組件較早被完成。
• 基於進度的集成
• 優點：具有較高的並行度；能夠有效縮短項目的開發進度。
• 缺點：樁和驅動工作量較大；有些接口測試不充分；有些測試重復和浪費。

系統測試的測試策略：

• 數據和數據庫完整性測試；功能測試；用戶界面測試；性能評測；負載測試；強度測試；容量測試；安全性和訪問控制測試；故障轉移和恢復測試；配置測試；安裝測試；加密測試；可用性測試；版本驗證測試；文檔測試

 

12、測試人員在軟件開發過程中的任務是什么？

1、盡可能早的找出系統中的Bug；

2、避免軟件開發過程中缺陷的出現；

3、衡量軟件的品質，保證系統的質量；

4、關注用戶的需求，並保證系統符合用戶需求。

總的目標是：確保軟件的質量。

 

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

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

1. bug編號；
2. bug嚴重級別，優先級；
3. bug產生的模塊；
4. 首先要有bug摘要，闡述bug大體的內容；
5. bug對應的版本；
6. bug詳細現象描述，包括一些截圖、錄像....等等；
7. bug出現時的測試環境，產生的條件即對應操作步驟；

高質量的Bug記錄：

1) 通用UI要統一、准確

• 缺陷報告的UI要與測試的軟件UI保持一致，便於查找定位。

2) 盡量使用業界慣用的表達術語和表達方法

• 使用業界慣用的表達術語和表達方法，保證表達准確，體現專業化。

3) 每條缺陷報告只包括一個缺陷

• 每條缺陷報告只包括一個缺陷，可以使缺陷修正者迅速定位一個缺陷，集中精力每次只修正一個缺陷。校驗者每次只校驗一個缺陷是否已經正確修正。

4) 不可重現的缺陷也要報告

• 首先缺陷報告必須展示重現缺陷的能力。不可重現的缺陷要盡力重現，若盡力之后仍不能重現，仍然要報告此缺陷，但在報告中要注明無法再現，缺陷出現的頻率。

5) 明確指明缺陷類型

• 根據缺陷的現象，總結判斷缺陷的類型。例如，即功能缺陷、界面缺陷、數據缺陷，合理化建議這是最常見的缺陷或缺陷類型，其他形式的缺陷或缺陷也從屬於其中某種形式。

6) 明確指明缺陷嚴重等級和優先等級

• 時刻明確嚴重等級和優先等級之間的差別。高嚴重問題可能不值得解決，小裝飾性問題可能被當作高優先級。

7) 描述 (Description) ，簡潔、准確，完整，揭示缺陷實質，記錄缺陷或缺陷出現的位置

• 描述要准確反映缺陷的本質內容，簡短明了。為了便於在軟件缺陷管理數據庫中尋找制定的測試缺陷，包含缺陷發生時的用戶界面（UI）是個良好的習慣。例如記錄對話框的標題、菜單、按鈕等控件的名稱。

8) 短行之間使用自動數字序號，使用相同的字體、字號、行間距

• 短行之間使用自動數字序號，使用相同的字體、字號、行間距，可以保證各條記錄格式一致，做到規范專業。

9) 每一個步驟盡量只記錄一個操作

• 保證簡潔、條理井然，容易重復操作步驟。

10) 確認步驟完整，准確，簡短

• 保證快速准確的重復缺陷，“完整”即沒有缺漏，“准確”即步驟正確，“簡短”即沒有多余的步驟。

11) 根據缺陷，可選擇是否進行圖象捕捉

• 為了直觀的觀察缺陷或缺陷現象，通常需要附加缺陷或缺陷出現的界面，以圖片的形式作為附件附着在記錄的“附件”部分。為了節省空間，又能真實反映缺陷或缺陷本質，可以捕捉缺陷或缺陷產生時的全屏幕，活動窗口和局部區域。為了迅速定位、修正缺陷或缺陷位置，通常要求附加中文對照圖。
• ? 附加必要的特殊文檔和個人建議和注解
  • 如果打開某個特殊的文檔而產生的缺陷或缺陷，則必須附加該文檔，從而可以迅速再現缺陷或缺陷。有時，為了使缺陷或缺陷修正者進一步明確缺陷或缺陷的表現，可以附加個人的修改建議或注解。

12) 檢查拼寫和語法缺陷

• 在提交每條缺陷或缺陷之前，檢查拼寫和語法，確保內容正確，正確的描述缺陷。

13) 盡量使用短語和短句，避免復雜句型句式

• 軟件缺陷管理數據庫的目的是便於定位缺陷，因此，要求客觀的描述操作步驟，不需要修飾性的詞匯和復雜的句型，增強可讀性。

14) 缺陷描述內容

• 缺陷描述的內容可以包含缺陷操作步驟，實際結果和期望結果。操作步驟可以方便開發人員再現缺陷進行修正，有些開發的再現缺陷能力很差，雖然他明白你所指的缺陷，但就是無法再現特別是對系統不熟悉的新加入開發人員，介紹步驟可以方便他們再現。實際結果可以讓開發明白錯誤是什么，期望結果可以讓開發了解正確的結果應該是如何。

　　以上概括了報告測試缺陷的規范要求，隨着軟件的測試要求不同，測試者經過長期測試，積累了相應的測試經驗，將會逐漸養成良好的專業習慣，不斷補充新的規范書寫要求。此外，經常閱讀、學習其他測試工程師的測試缺陷報告，結合自己以前的測試缺陷報告進行對比和思考，可以不斷提高技巧。

 

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

黑盒測試

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

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

白盒測試

• 優點：幫助軟件測試人員增大代碼的覆蓋率，提高代碼的質量，發現代碼中隱 藏的問題。

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

 

15、如何測試一個紙杯？

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

功能性：

• • 用水杯裝水看漏不漏；水能不能被喝到　　

• 安全性：
  • 杯子有沒有毒或細菌　　
• 可靠性：
  • 杯子從不同高度落下的損壞程度　　
• 可移植性：
  • 杯子在不同的地方、溫度等環境下是否都可以正常使用　　
• 兼容性：
  • 杯子是否能夠容納果汁、白水、酒精、汽油等　　
• 易用性：
  • 杯子是否燙手、是否有防滑措施、是否方便飲用　　
• 疲勞測試：
  • 將杯子盛上水（案例一）放24小時檢查泄漏時間和情況；盛上汽油（案例二）放24小時檢查泄漏時間和情況等　　
• 壓力測試：
  • 用根針並在針上面不斷加重量，看壓強多大時會穿透　　

 

16、測試計划工作的目的是什么？測試計划文檔的內容應該包括什么？其中哪些是最重要的？

目的：

1. 軟件測試計划是指導測試過程的綱領性文件：
2. 領導能夠根據測試計划進行宏觀調控，進行相應資源配置等
3. 測試人員能夠了解整個項目測試情況以及項目測試不同階段的所要進行的工作等
4. 便於其他人員了解測試人員的工作內容，進行有關配合工作

包含：

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

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

• why——為什么要進行這些測試；
• what—測試哪些方面，不同階段的工作內容；
• when—測試不同階段的起止時間；
• where—相應文檔，缺陷的存放位置，測試環境等；
• who—項目有關人員組哪些測試人員進行測試；
• how—如何去做，使用哪些測試工具以及測試方法進行測試

重要：

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

 

17、詳細的描述一個測試活動完整的過程

　　（以瀑布模型為例）

1. 項目經理通過和客戶的交流，完成需求文檔，由開發人員和測試人員共同完成需求文檔的評審，評審的內容包括：需求描述不清楚的地方和可能有明顯沖突或者無法實現的功能的地方。項目經理通過綜合開發人員，測試人員以及客戶的意見，完成項目計划。然后SQA進入項目，開始進行統計和跟蹤
2. 開發人員根據需求文檔完成需求分析文檔，測試人員進行評審，評審的主要內容包括是否有遺漏或雙方理解不同的地方。測試人員完成測試計划文檔，測試計划包括的內容 在 16 題有描述。
3. 測試人員根據修改好的需求分析文檔開始寫測試用例，同時開發人員完成概要設計文檔，詳細設計文檔。此兩份文檔成為測試人員撰寫測試用例的補充材料。
4. 測試用例完成后，測試和開發需要進行評審。
5. 測試人員搭建環境
6. 開發人員提交第一個版本，可能存在未完成功能，需要說明。測試人員進行測試，發現BUG后提交給BugZilla或 禪道。
7. 開發提交第二個版本，包括Bug 已修復功能 以及 增加的部分功能，測試人員進行測試。
8. 重復上面的工作，一般是3-4個版本后BUG數量減少，達到要求。
9. 如果有客戶反饋的問題，需要測試人員協助重現並重新測試。

 

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

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

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

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

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

 

19、軟件產品質量特性是什么?

• 功能性：適應性、准確性、互操作性、依從性、安全性。
• 可靠性：成熟性、容錯性、易恢復性。
• 可使用性：易理解性、易學習性、易操作性。
• 效率：時間特性、資源特性。
• 可維護性：易分析性、易變更性、穩定性、易測試性。
• 可移植性：適應性、易安裝性、遵循性、易替換性

 

20、試述軟件的概念和特點？軟件復用的含義？構件包括哪些？

1. 軟件 是計算機系統中與硬件相互依存的另一部分，與計算機系統操作有關的計算機程序、規程、規則，以及可能有的文件、文檔及數據。
2. 軟件復用(SoftWare Reuse)  是將已有軟件的各種有關知識用於建立新的軟件，以縮減軟件開發和維護的花費。軟件復用是提高軟件生產力和質量的一種重要技術。早期的軟件復用主要是代碼級復用，被復用的知識專指程序，后來擴大到包括領域知識、開發經驗、設計決定、體系結構、需求、設計、代碼和文檔等一切有關方面。
3. 可以被復用的軟件成分一般稱作可復用構件

 

21、什么是軟件測試？軟件測試的 目的 和 原則？

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

軟件測試的目的：

1. 測試是程序的執行過程，目的在於發現錯誤
2. 一個成功的測試用例在於發現至今未發現的錯誤
3. 一個成功測試是發現了至今未發現的錯誤的測試
4. 確保產品完成了她所承受或公布的功能，並且用戶可以訪問到的功能都有明確的書面說明
5. 確保產品滿足性能和效率的要求
6. 確保產品是健壯的和適應用戶環境的

軟件測試的原則：

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

 

22、軟件質量保證體系是什么？國家標准中與質量保證管理相關的幾個標准是什么?他們的編號和全稱是什么?

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

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

 

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

1. 盡量面對面的溝通，其次是能直接通過電話溝通，如果只能通過 Email 等非及時溝通工具的話，強調必須對特性的理解深刻以及能表達清楚。
2. 運用一些測試管理工具如 TestDirector 進行管理也是較有效的方法，同時要注意在 TestDirector 中對 BUG 有准確的描述。

• 在團隊中建立測試人員與開發人員良好溝通中注意以下幾點：
  • 一真誠、二是團隊精神、三是在專業上有共同語言、四是要對事不對人，工作至上；
  • 當然也可以通過直接指出一些小問題，而不是進入BUG 跟蹤系統來增加對方的好感；

 

24、你對測試最大的興趣在哪里？為什么？

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

• 最大的興趣，感覺這是一個有挑戰性的工作；
• 測試是一個經驗行業，工作越久越能感覺到做好測試的難度和樂趣
• 通過自己的工作，能使軟件產品越來越完善，從中體會到樂趣

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

1. 盡可能的切合招聘企業的技術路線來表達你的興趣，例如該企業是數據庫應用的企業，那么表示你的興趣在數據庫的測試，並且希望通過測試提升自己的數據庫掌握能力。
2. 表明你做測試的目的是為了提升能力，也是為了更好的做好測試；提升能力不是為了以后轉開發或其他的，除非用人企業有這樣的安排。
3. 不要過多的表達你的興趣在招聘企業的范疇這外。比如招聘企業是做財務軟件的，可是你表現出來的是對游戲軟件的興趣；或招聘是做JAVA開發的，而你的興趣是在C類語言程序的開發。

 

25、你自認為測試的優勢在哪里？

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

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

 

26、簡述你在以前的工作中做過哪些事情，比較熟悉什么？

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

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

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

 

27、在 C/C++中 static 有什么用途？（請至少說明兩種）

• 1)在函數體，一個被聲明為靜態的變量在這一函數被調用過程中維持其值不變。
• 2) 在模塊內（但在函數體外），一個被聲明為靜態的變量可以被模塊內所用函數訪問，但不能被模塊外其它函數訪問。它是一個本地的全局變量。
• 3) 在模塊內，一個被聲明為靜態的函數只可被這一模塊內的其它函數調用。那就是，這個函數被限制在聲明它的模塊的本地范圍內使用

 

28、引用與指針有什么區別？

• 1) 引用必須被初始化，指針不必。
• 2) 引用初始化以后不能被改變，指針可以改變所指的對象。
• 3) 不存在指向空值的引用，但是存在指向空值的指針。

 

29、Internet 采用哪種網絡協議？該協議的主要層次結構？Internet 物理地址和 IP地址 轉換采用什么協議？

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

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

 

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

1、自頂向下集成

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

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

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

2、自底向上集成

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

• 缺點：驅動的開發工作量大；對高層的驗證被推遲，設計上的錯誤不能被及時發現。

• 適應於底層接口比較穩定；高層接口變化比較頻繁；底層組件較早被完成。

 

31、軟件驗收測試包括:

• 正式驗收測試、alpha測試、beta測試三種測試。

 

32、系統測試的策略有都有什么:

• 有性能測試、負載測試、強度測試、易用性測試、安全測試、配置測試、安裝測試、
• 文檔測試、故障恢復測試、用戶界面測試、恢復測試、分布測試、可用性測試；

 

33、設計系統測試計划需要參考的項目文檔有:

• 軟件測試計划、軟件需求計划、和迭代計划

 

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

1. 分析軟件規格說明描述中，哪些是原因（即輸入條件或輸入條件的等價類），哪些是結果（即輸出條件），並給每個原因和結果賦予一個標識符。
2. 分析軟件規格說明描述中的語義，找出原因與結果之間，原因與原因之間對應的是什么關系? 根據這些關系，畫出因果圖。
3. 由於語法或環境限制，有些原因與原因之間，原因與結果之間的組合情況不可能出現。為表明這些特殊情況，在因果圖上用一些記號標明約束或限制條件。 § 把因果圖轉換成判定表。
4. 把判定表的每一列拿出來作為依據，設計測試用例。

 

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

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

• 模塊、組件級測試：主要依據是程序結構設計測試模塊間的集成和調用關系，一般由測試人員完成。

• 系統測試：在於模塊測試與單元測試的基礎上進行測試。了解系統功能與性能，根據測試用例進行全面的測試。　　

 

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

• 設計測試用例時需要注意的是，除了對整體流程及功能注意外，還要注意強度測試、性能測試、壓力測試、邊界值測試、穩定性測試、安全性測試等多方面。
  • 測試用例需要考慮的四個基本要素是：輸入、輸出、操作和測試環境；
  • 另外，測試用例需要考慮的是測試類型：功能、性能、安全……；
  • 此外，還需要考慮用例的重要性和優先級；

 

37、在windows下保存一個文本文件時會彈出保存對話框，如果為文件名建立測試用例，等價類應該怎樣划分？

• 單字節，如A；
• 雙字節， AA、我我；
• 特殊字符 /‘。‘；、= - 等；
• 保留字，如com；
• 文件格式為8.3格式的；
• 文件名格式為非8.3格式的；/,\,*等九個特殊字符。

 

38、假設有一個文本框要求輸入10個字符的郵政編碼，對於該文本框應該怎樣划分等價類？

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

 

39、軟件測試項目從什么時候開始？為什么？

• 軟件測試應該在需求分析階段就介入，因為測試的對象不僅僅是程序編碼，應該對軟件開發過程中產生的所有產品都測試，
• 並且軟件缺陷存在放大趨勢，缺陷發現的越晚，修復它所花費的成本就越大

 

40、什么是回歸測試?

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

 

 

*******請大家尊重原創，如要轉載，請注明出處：轉載自：https://www.cnblogs.com/shouhu/，謝謝！！*******