大家好，我是小墨，今天我們來聊聊軟體測驗工程師的面試題有哪些，2021年的1月份馬上就過完了，金三銀四就業季，跳槽季馬上又要來了，畢竟在面試的戰場上，知己知彼方能百戰不殆，嗯嗯，不錯說的真好！
1、您所熟悉的測驗用例設計方法都有哪些？請分別以具體的例子來說明這些方法在測驗用例設計作業中的應用，
答：有黑盒和白盒兩種測驗種類，黑盒有等價類劃分法，邊界分析法，因果圖法和錯誤猜測法，白盒有邏輯覆寫法，回圈測驗路徑選擇，基本路徑測驗，
例子：在一次輸入多個條件的完整性查詢中，利用等價類劃分法則和邊界分析法則，首先利用等價劃分法，可以一個或多個結果是OK的測驗用例，然后確認多個NG的測驗用例，然后利用邊界值分析法，可以對結果分別是OK和NG的測驗用例進行擴展和補充，
2、您認為做好測驗用例設計作業的關鍵是什么？
答：測驗用例設計作業的關鍵是對可行的和不可行的都要考慮，
1，輸入2，詳細的操作步驟3，預期輸出4，實際輸出，
3、您在從事性能測驗作業時，是否使用過一些測驗工具？如果有，請試述該工具的作業原理，并以一個具體的作業中的例子描述該工具是如何在實際作業中應用的，
答：有使用過LoadRunner，該工具能夠錄制測驗人員的操作步驟，然后對這個操作步驟模擬出多個用戶來播放出來，
1、Visural User
Genertor創建腳本，選擇協議，錄制操作，編輯操作，
2、中央控制器（Controller）調度虛擬用戶，創建場景，選擇腳本，建立虛擬用戶，設計shedual，設定ip spoofer，
3、運行腳本，分析shedual，
4、分析測驗結果，
您認為性能測驗作業的目的是什么？做好性能測驗作業的關鍵是什么？
答：性能測驗作業的目的是檢查系統是否滿足在需求說明書中規定的性能，性能測驗常常需要和強度測驗結合起來，并常常要求同時進行軟體和硬體的檢測，
性能測驗主要的關注物件是回應時間，吞吐量，占用記憶體大小（輔助存盤區），處理精度等，
4、在您以往的作業中，一條軟體缺陷（或者叫Bug）記錄都包含了哪些內容？如何提交高質量的軟體缺陷（Bug）記錄？
答：檢測時間，系統環境，硬體環境，嚴重程度，程式版本，確認人，功能模板，問題描述，詳細操作步驟，是否會重現，
問題描述和詳細操作步驟要盡可能詳細，Bug應該盡量用書面語，對于嚴重程度比較高的缺陷要在相同環境下測驗一遍，
在C\S模式下，如果條件滿足可以使用替換法來確認是client端的問題還是server端的問題，
5、你對測驗最大的興趣在哪里？為什么？
答：最大的興趣就是具有挑戰性，
因為我并不知道哪里會出現bug，在找到一個bug后會很高興，并且測驗需要很強的耐心和細心，我可以很容易的找到一些細節問題，
6、測驗活動中，如果發現需要檔案不完善或者不準確，怎么處理？
答：要及時的與專案經理進行溝通協調，要在郵件中詳細的把不完善不準確的地方描述出來，并提出自己的意見，
7、你認為做好測驗計劃作業的關鍵是什么？
答：首先，要有一個明確的目標，詳細的閱讀需求檔案說明，
其次，要對整個測驗人員、測驗時間、測驗進度進行一個預估，并預先進行管理，
最后，要對整個測驗流程設定一個規范，所有測驗人員都按著規范做事，不能隨心所欲的測驗，
8、軟體配置管理作業開展的情況和認識？
拿到一臺裸機過后要安裝客戶需要的作業系統，并且安裝一些所必須的軟體，
9、你覺得軟體測驗通過的標準應該是什么樣的？
答：測驗用例完全執行，測驗用例覆寫到所有的測驗點，并且缺陷的密度達到客戶的需求，
10、軟體測驗的檔案測驗應當貫穿于軟體生命周期的全程序，其中用戶檔案是檔案測驗的重點，那么軟體系統的用戶檔案包括哪些？
答：用戶安裝檔案、用戶配置檔案、用戶使用手冊、聯機指導等，
11、簡述軟體系統中用戶檔案的測驗要點？
完整性：用戶檔案中功能的描述要完整的，不能讓用戶產生疑問，
一致性：用戶檔案中的功能描述要與實際軟體中的功能一致，不能描述過盛，
易使用性：用戶檔案描述的內容要方便用戶閱讀并且能夠讓用戶很清楚的知道如何操作，
圖表：有的時候用圖表描述會很明了，
12、什么是系統瓶頸？
系統瓶頸就是軟體在一定的并發量、訪問量下無法達到用戶的需求，
比如說用戶需要在10s內完成一個訪問，但是每一次都要12s才能完成，這個就是性能瓶頸，有可能是程式本身的問題，也有可能和作業系統、軟體相關，
13、沒有產品說明書和需求檔案地情況下能夠進行黑盒測驗嗎？
可以，
這個情況下我們就要進行探索性測驗，把軟體當成用戶需求，一步步進行測驗，憑借經驗判斷功能正確與否，有的時候還可以與專案經理、開發人員一起進行交流溝通，從而進行更好的測驗，
14、為什么盡量不要讓時間富裕的員工去做一些測驗？
首先，專業的測驗人員是有一定的技能和耐心對軟體一步一步進行測驗，如果讓時間充裕的員工去測驗的話，他可能心思并不在測驗上面，會很隨意的、沒有目標的進行測驗，這樣子的話測驗并不完整，有的時候甚至很重要的bug都沒法找出，所以還是需要專業的測驗人員來進行測驗的，
15、完全測驗程式是可能的嗎？
不可能
測驗人員對程式進行測驗，只能找出程式中的bug，但是并不能保證程式是沒有bug的，
完全的測驗要花費很多的人力財力，并且測驗的資料量過大，很浪費時間，測驗的結果還很多，有的都是類似的，沒有必要進行相同的測驗，所以完全測驗是不可能的，
16、軟體測驗的風險主要體現在哪里？
主要體現在沒法完全測驗，有些問題可能隱藏在沒有測到的地方，這樣子就被忽略了，客戶使用的時候并不熟悉軟體是如何操作的，可能有的時候會誤點點出問題，這樣子的話我們就要承擔很大的風險了，
17、發現的缺陷越多，說明軟體缺陷越多嗎？
是的，通常如果發現一個缺陷的話，有的時候會發現很多類似的缺陷，因為由于開發人員的習慣，可能一個地方有錯誤，另外一個地方就會有相同的錯誤，
18、所有的軟體缺陷都能修復嗎？所有的軟體缺陷都要修復嗎？
從理論上來說所有的缺陷都是可以修復的，但是并不是所有的缺陷都要修復，
一些對于軟體沒有影響的、不影響使用的缺陷我們可以不用修復，因為修復些細小的缺陷也是需要花費很多時間，專案上面可能會因為時間問題而先忽略這些小缺陷，
19、開發人員老是犯一些低級錯誤怎么解決？
要在開發的前期就制定好一些編碼規范，這樣子可以減少很多因為個人習慣引起的錯誤，同時，測驗人員在發現開發人員犯一些低級錯誤的時候不可以指責他們，要耐心的給他們指出錯誤所在，然后可以有開發人員自己進行測驗，找出一些一眼看得出來是錯誤的地方，
20、您在以往的測驗作業中都曾經具體從事過哪些作業？其中最擅長哪部分作業？
我一般都是做的Web測驗，搭建測驗環境，對于一個程式進行集成測驗，系統測驗，回歸測驗等，還要撰寫測驗用例以及一些檔案，用戶使用手冊，功能測驗檔案等等，最擅長的是功能測驗，
21、開發人員說不是bug時，你如何應付？
首先把自己的理由告訴開發人員，在同開發人員溝通到底是不是bug，但是如果開發人員還是認為不是bug的話，就把這個問題提到專案經理處，同時附上自己的理由，有專案經理決定是否為bug，
22、軟體測驗專案從什么時候開始為什么？
一般軟體測驗越早展開越好，一般是從需要階段就要進行軟體測驗，軟體測驗不僅是測驗功能，對于需求檔案一類的也要進行測驗，越早的找出bug，就會減少后續開發人員修改程式的次數，并且可以降低成本，如果等整個軟體開發的差不多了發現一個致命的錯誤的話，是需要花費很多時間和人力來重新修改的，如果在一開始就發現的話就不會出現這種情況了，
23、你能不能說下你的3-5年的職業規劃？
首先，要鞏固自己的測驗基礎知識，在基本知識扎實的情況下提高理解需求檔案地能力，
其次，學習自動化測驗工具，并將它運用到測驗中，
然后，在測驗技術達到一定程度后，要學會如何帶領一個測驗團隊，
最后，爭取在最快的時間內達到測驗經理的水平，
24、功能測驗用例需要詳細到什么程度才是合格的？
測驗用例覆寫到所有的測驗點，
25、一個缺陷測驗報告的組成？
缺陷編號、缺陷標題、缺陷描述、缺陷的優先級、缺陷的重要程度、缺陷所述的模塊、缺陷所屬的版本、缺陷所屬的開發人員、輸入資料、輸出結果、缺陷分析等，
26、測驗用例通常包括哪些內容？
用例編號、測驗環境、用例標題、輸入資料、預期結果等
27、你都用什么測驗方法？
根據不同的系統和模塊有不同的方法，主要是黑盒測驗和白盒測驗，
28、軟體的評審一般由哪些人員參加？其目的是什么？
參加人員：客戶、專案經理、開發人員、測驗人員
目的：查看軟體在未正式投入運行前是否還存在問題，對于不同軟硬體平臺能否正常運行，是否有與客戶理解不一致的地方，同時可以對一些可以改進的地方再多加改進，
29、什么是軟體測驗，軟體測驗的目的？
軟體測驗是通過人工或者自動化的操作進行還沒有商業化用途的程式，查看他們的功能是否滿足客戶需求，
目的：在最短時間內找出盡可能多的軟體缺陷，
30、什么是兼容性測驗？
兼容性測驗是檢查軟體在不同軟體平臺，硬體平臺上是否可以正常運行的測驗，主要查看軟體在不同作業系統、瀏覽器、資料庫中是否運行正常，
1、什么是軟體測驗？
答：為了發現程式中的錯誤而執行程式的程序
2、軟體測驗的物件有哪些？
答：軟體測驗并不等于程式測驗，軟體測驗應貫穿于軟體定義與開發的整個期間，
需求分析、概要設計、詳細設計以及程式編碼等各階段所得到的檔案，包括需求規格說明、概要設計規格說明、詳細設計規格說明以及源程式，都應成為軟體測驗的物件，
3、當測驗程序發生錯誤時，有哪幾種解決辦法？
答：1）跳轉到別的測驗程序
2）呼叫一個能夠清除錯誤的程序
3）退出程序，啟用另一個
退出程序和應用程式，重新啟動Windows，在失敗的地方重新開始測驗
4、怎么才能夠全面的測驗到每一個點？
答：測試的全面性主要需要在設計測驗計劃的時候考慮，從測驗策略，產品需求等等多個角度考慮從而定義全部的測驗點，
5、開發與測驗的關系？
答：開發和測驗是一個有機的整體，在產品發布之前，開發和測驗是回圈進行的，測出的缺陷要經開發人員修改后繼續測驗，在開發的同時測驗經理開始撰寫測驗用例，測驗檔案要參考開發檔案，所以開發和測驗是不可分割的，少了任何一個都不能開發出產品，
6、測驗活動中統計了哪些資料？
答：作業量bug數量
7、進行測驗時產生了哪些檔案或記錄？
答：測驗的整個程序有系統測驗計劃、系統測驗用例、系統測驗報告、缺陷報告、產品發布說明
在執行測驗的程序中只有缺陷報告，這個還是用在缺陷管理工具中進行的，最后在工具中匯出缺陷報告
8、怎樣做好測驗計劃？
答：
a.理解系統，從整個系統的高度了解被測系統必須滿足的功能和非功能性需求，利用涉及整個系統的檔案，形成對系統的整體了解，
b.及早介入，為了深入了解專案，測驗人員應該在系統的開始階段介入，可以增加對客戶需求，客戶問題，潛在風險以及最重要的功能方面的理解
c.測驗期望，程式員的期望是什么？客戶的期望是什么？銷售對測驗的期望又是什么？測驗目標必須是絕對的，以免說不清是否達到目標，
d.吸取教訓，把以前作業中學習到的經驗教訓運用過來，對確定測驗策略很有作用，
e.作業量太小，完成測驗需要多少作業量？需要多少人員？
f.技術選擇，系統會采取什么技術？系統會采用什么架構？這些資訊有助于確定測驗策略和測驗工具，
g.時間表，系統開發和測驗分配的時間有多長？截止日期是什么時候？
9、測驗用例如何設計的？
答：在測驗用例的設計之前首先要仔細閱讀開發的詳細設計檔案，充分了解產品的詳細功能，不清楚的地方與開發人員進行溝通，搞懂每個功能，盡量詳細到輸入框、按鈕等小功能，功能點清楚之后按照功能模塊分類進行用例撰寫，在具體的用例設計中會運用到等價類邊界值等黑盒測驗方法
10、簡單概述缺陷報告，并說明包括哪些項？
答：現在缺陷報告一般不再使用紙質檔檔案撰寫，而是專用測驗管理工具（如TestDirector），這樣便于缺陷管理，在這些工具中，每個缺陷作為一條記錄輸入指定的缺陷管理系統中，
缺陷報告包括：軟體名稱、版本號、功能模板、缺陷編號、對應的用例編號、撰寫時間、撰寫人、測驗員、預期結果、實際結果、缺陷描述、嚴重級別、優先級別
11、什么是bug？
答：軟體的bug指的是軟體中（包括程式和檔案）不符合用戶需求的問題，
常見的軟體bug分為以下三類：
沒有實作的功能
完成了用戶需求的功能，但是運行時會出現一些功能或性能上的問題
實作了用戶不需求的多余功能
12、開發人員修復缺陷后，如何保證不影響其他功能？
答：重新執行用例、看是否出現錯誤結果，并對周圍的一些相關功能點追加新的測驗用例，
13、什么時候功能測驗？
答：功能測驗是在規定的一段時間內運行軟體系統的所有功能，以驗證這個軟體系統有無嚴重錯誤，
14、請問功能測驗和性能測驗的區別是什么？
答：a.測驗目的：
功能測驗：檢測實際軟體的功能是否符合用戶需求，測功能是不是全部實作，某個實作是不是有BUG，主要為了發現以下幾類錯誤：A、是否有不正確或遺漏的功能？B、功能實作是否滿足用戶需求和系統設計的隱藏需求？C、能否正確接收輸入？能否正確輸出結果？
性能測驗：驗證軟體質量的三個質量特性，可靠性，正確性和效率，主要是測驗產品的健壯性
b.測驗方式：
功能測驗按照系用例，按照系統需求說明書和測驗用例，對產品的功能一步步進行測驗，找出產品功能是否全部實作
性能測驗：一般都使用性能工具對產品的健壯性進行評估，通過創建場景和虛擬用戶模擬真實環境，進行壓力測驗和負載測驗，
15、為什么選擇測驗這行？
答：它是一個新興的行業，有發展潛力，而且很鍛煉人，需要掌握更多的技能，比做開發要更全面
在這里推薦一個軟體測驗交流群，QQ：642830685，群中會不定期的分享軟體測驗資源，測驗面試題以及測驗行業資訊，大家可以在群中積極交流技術，還有技術老師為你答疑解惑，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/251985.html
標籤：其他