1、開發犯低級錯誤怎么辦？
開發首先要規范好編碼，出低級錯時不要指責，內心指出錯誤，讓他們自己進行測驗，反思找出錯誤，
2、你進行過哪些測驗，擅長什么?
我主要從事web測驗，搭建環境，對程式進行集成測驗、系統測驗、回歸測驗，還有撰寫測驗用例，使用手冊，功能測驗檔案，單元測驗：測驗的最早期階段，焦點在于被測軟體的最小的組成部分，
集成測驗：確保最小單元被（部分）整合后能正常操作的測驗執行階段
系統測驗：當應用作為整體運行時的測驗執行階段（測驗最終的應用）
回歸測驗：修改了舊代碼后，重新進行測驗以確認修改操作沒有引入新的錯誤或導致其他代碼產生錯誤，
驗收測驗：以用戶為主，由用戶參加設計測驗用例，對程式的功能、性能，以及可移植性、兼容性、可維護性、錯誤的恢復功能等進行確認，主要運用黑盒測驗的方法，對系統主要流程、重要功能進行有效性測驗，驗證所測驗的軟體是否滿足需求規格說明書列出的要求
3、開發說不是bug怎么辦？
將自己的見解告訴開發，不行就把見解和bug提交專案經理決定，
4、你的職業規劃?
鞏固基礎測驗知識，提高理解需求能力，學習自動化測驗，并且運用，技術到位后學習帶領測驗團隊，最后爭取達到測驗經理水平，
5、什么測驗用例才是合格?
能覆寫到所有測驗點
6、缺陷測驗報告組成？
缺陷編號、缺陷標題、缺陷描述、缺陷優先程度、缺陷所屬模塊、缺陷所屬版本、缺陷所屬開發人員、 輸入資料、輸出結果、缺陷分析等，
C/S模式，使用交替方法確認是client還是server端問題，
7、測驗用例包括哪些？
用例編號、測驗項描述、操作步驟、輸入、預期結果、實際結果、測驗人、測驗時間、備注
8、軟體評審的人員和目的
人員：客戶、專案經理、開發人員、測驗人員目的：查看軟體是否還存在問題，是否在不同平臺正常運行，是否有和客戶理解不一致的地方，是否有改進的地方
9、什么是軟體測驗？目的?
使用人工或自動化手段運行程式，為了發現軟體的錯誤而執行檢驗的一個程序目的：以最少的人力、物力、時間找到軟體中的缺陷并修改，從而回避風險，
10、兼容測驗
檢查軟體在不同軟體、硬體平臺是否可以正常運行，即軟體的可移植性，主要查看在不同作業系統、瀏覽器、資料庫、不同版本是否正常運行
11、為什么進行軟體測驗？
沒經過測驗的軟體無法保證質量，好比iso質量認證一樣，測驗中發現問題，即時提交開發改進，在軟體發布時保證軟體質量，
12、軟體測驗型別有哪些？區別與聯系？
常見：功能測驗、性能測驗、界面測驗，
功能測驗：占比最大，也叫黑盒測驗（不看代碼），進行動態測驗時，需要測驗軟體功能，不需要測驗軟體內部結構和處理程序，
技術方法有：等價類劃分法、邊界值分析、錯誤推測、因果圖和綜合策略，
性能測驗：通過自動化測驗工具模擬多種正常、例外、峰值條件，對系統各項性能指標測驗，
負載測驗、壓力測驗屬于此，負載測驗：確定各項作業負載下的系統性能，目標是負載主鍵增加時，系統各項性能指標變化；壓力測驗：通過系統的瓶頸，獲得系統能提供的最大服務級別，
界面測驗：界面好壞決定用戶對軟體第一印象，合理的界面帶來輕松愉悅感受，失敗界面有挫敗感，讓強大的功能付諸東流，
區別：功能測驗關注軟體功能，每個功能可能存在的問題，性能測驗軟體多用戶并發的穩定性和強壯性，界面測驗關注用戶體驗和易用性，
13、好的測驗用例關鍵？
白盒測驗：較少的用例覆寫盡可能多的內部程式邏輯結果，
黑盒測驗：較少的用例覆寫模塊輸出和輸入介面，用最少用例在合理時間內發現最多的問題，
對可行和不可行的都要考慮：（1）輸入 （2）詳細操作步驟 （3）預期輸出 （4）實際輸出
14、黑盒、白盒、單元、集成、系統、驗收測驗的區別與聯系？
黑盒：已知功能設計規格，測驗每個功能是否符合要求，白盒：已知內部作業程序，測驗每種內部運算子合設計規格，黑盒意味著測驗在軟體的介面處進行，把測驗物件看做一個黑盒子，不考慮程式內部邏輯結構和內部特性，僅看需求說明書檢查功能是否符合需求，黑盒-》功能測驗（或者 資料驅動測驗）
15、軟體開發程序與角色分工？
測驗配合開發等進行需求分析和討論，根據需求說明書制定《專案測驗計劃》，撰寫測驗用例，建立測驗環境，測驗負責新產品測驗，原有產品的升級測驗，負責軟體問題解決程序跟蹤，軟體開發檔案、開發作業的規范化，管理開發部門的產品檔案，制作用戶手冊、操作手冊，產品上限測驗，監督軟體開發程序執行，提高軟體質量，
16、軟體開發程序與角色分工？
開發與測驗開會討論需求，需求分析人員寫出需求分析說明，三部門討論可行性，給出詳細設計說明書，開發編碼，給出系統流程圖，測驗根據此，給出bug統計，
17、不同測驗型別的聯系與區別？
功能、性能、可靠性、安全性、負載測驗，壓力、安裝/卸載、啟動/停止、兼容、互聯測驗，檔案、回歸、可使用性、容量測驗
18、測驗計劃作業包括？
是對作業內容的有效組織和規劃，保證測驗作業有效展開，包括測驗目標，測驗范圍定義，測驗方法選擇，測驗進度里程碑，測驗資源管理和配置，測驗目標最重要，因為他是軟體測驗的最終達到結果
19、性能測驗工具，原理、實際應用LoadRunner
能夠錄制測驗的操作步驟，對其模擬出多個用戶播放出來，
-
（1）visural user genertor：創建腳本，選擇協議，錄制操作，編輯操作
-
（2）中央控制器 controller：調度虛擬用戶，創建場景，選擇腳本，建立虛擬用戶，設計shedual，設定ip spoofer
-
（3）運行腳本，分析shedual
-
（4）分析測驗結果
20、兼容性
平臺兼容、網路兼容、資料庫兼容、資料格式兼容，
缺陷等級分類
-
(1) 最高級–導致運行中斷(應用程式崩潰),預期的功能沒有得到實作,測驗作業無法繼續進行等
-
(2) 緊急—事件非常重要,并且需要馬上給予關注
-
(3) 高級—事件是重要的,并且應該在緊急的事件處理之后盡快得到解決
-
(4) 中級—事件是重要的,但是由于解決問題需要花費一定的時間,所以可以用較長的時間解決
-
(5) 低級—事件不重要,可以在時間和資源允許的情況下再解決
21、缺陷生命周期
新建bug–提交bug–確認bug–分配bug–修復bug–驗證bug–關閉bug
22、測驗結束標準
-
1）一二級缺陷數目達到專案質量管理目標要求，測驗暫停回傳開發
-
2）專案出現重大估算和進度偏差，需要暫停或者終止
-
3）新需求變更大，需修改測驗計劃和測驗用例再進行
-
4）開發暫停，測驗也暫停，備份暫停時的資料
-
5）所有功能、性能測驗用例100%進行
23、測驗生命周期
需求測驗計劃制定和評審–測驗用例撰寫–測驗用例執行–bug管理–測驗報告輸出
24、自我介紹
套路
-
1）很高興獲得面試機會……想證明我是合適的人選……想獲得您的認可……
-
2）反問面試官：您看我繼續介紹專案還是您提問關心的問題？
25、專案介紹
先整體再區域介紹，專案五大維度：
規模（代碼規模、需求規模、用例規模、作業量、進度、質量、成本），測驗流程，角色與職責，專案中自己角色，自己的特色（做得好的、遇到的困難、做得差的），最后是心得體會，
26、資料庫問題
資料庫增刪改查（insert、delete、update、select）；
表結構增刪改查（create、drop、alter、describe）；
存盤程序；觸發器等
27、Linux系統
常見50個命令（find、-name、type、perm、user、group、ctime、atime）
熟悉vi、熟悉linux搭建測驗環境，LAMP環境搭建，
28、缺陷相關
缺陷跟蹤流程（流程基本要素）、整體流程（會話）、缺陷單的20個屬性、屬性的意義、如何描述好缺陷單、缺陷單的5C原則、缺陷重現步驟，你認為最經典的bug
29、用例相關
用例格式要素、用例設計工程方法論、方法要求如何利用，如何評審用例，從那些維度評審，設計好用例需要那些只是結構
30、軟體測驗流程
熟悉產品/專案–需求評審–測驗需求–測驗計劃–測驗方案–測驗用例–預測驗，第一輪正式測驗–第二輪回歸測驗–第三輪測驗，測驗報告–總結–測驗指南
31、網路相關
基本網路知識（重點TCP/IP協議）網路通信模型，以及一整個網路傳輸協議家族，為互聯網的基礎通信架構，提供了點對點的鏈接機制，將資料應該如何封裝、定址、傳輸、路由以及在目的地如何接收，都加以標準化，
-
1、應用層：應用程式之間相互溝通的層
-
2、傳輸層：提供了資料傳輸，應用程式之間的通信服務
-
3、網路互聯層：負責提供基本的資料封包傳送功能，讓每一塊資料包都能夠到達目的主機
-
4、網路介面層：接收資料，并進行傳輸
32、測驗工具
性能測驗工具：LoadRunner，Jmeter
自動化測驗工具：Selenium
測驗管理工具：禪道或者Jira
如何去測驗指定軟體？
技巧：從質量模型、測驗工具、測驗方法、測驗流程、探索式測驗，宏觀解決，再微觀講解用例設計
33、你還有什么想要問的嗎？
滿意情況：先表示感謝，問如果有下一輪面試，什么時候，做什么準備；
一般般情況：感謝，對自己表現不太滿意，能否給我一些建議；
很糟糕：感謝，認識到不足，希望給建議
34、測驗用例撰寫結構
功能性、界面UI、易用性、安全性、兼容性
35、STAR法則
-
S（situation）：專案屬于什么型別，周期多長
-
T（task）：團隊分工，你的角色
-
A（action）：具體實施，自己做了什么
-
R（result）：最后成果，你的識訓
36、如何測驗紙杯
功能性：是否漏水；是否喝到水
安全性：有沒有細菌可靠性：摔下來的損壞程度
可移植性：不同地方、溫濕度使用
兼容性：容納果汁、啤酒、汽水、汽油等
易用性：是否燙手、防滑、方便飲用水
用戶檔案：使用手冊對用法、限制、使用條件描述
疲勞測驗：分別裝上水、汽油等24小時，泄露情況
壓力測驗：用物件不斷加壓，承受多大的壓強
37、軟體生命周期各個階段的測驗內容
-
（1）需求階段測驗：設計整個程序的進行、測驗計劃的安排、測驗用例的設計以及軟體的確認要達到那些要求等，
-
（2）設計階段測驗：包括概要設計和詳細設計，在概要設計階段，測驗人員應闡述測驗方法和測驗評估準則，撰寫測驗計劃，組織成立獨立的測驗小組，安排具有里程碑的測驗日程；在詳細設計階段，測驗人員要開發或獲取確認支持工具，生成功能測驗資料和測驗用例，以此來檢查設計中遺漏的情況、錯誤的邏輯、模塊介面的不匹配、資料結構不合理、錯誤的I/O假定、用戶界面的補充分等，
-
（3）編碼階段測驗：測驗需要解決的首要問題是編碼是否和設計的一致；其次是系統是否可維護，系統的規格說明是否正確地實作，編碼是否按照既有的標準進行，是否有充分的測驗計劃評價程式，程式是否提供足夠的檔案資料，程式內部是否有足夠的注釋等，在測驗完成后，要形成下列輸出物：編碼說明書、程式檔案、計算機程式串列、可執行的程式、程式流程圖、操作介紹和單元測驗結果，
-
（4）測驗階段：要進行第三方的正確測驗，檢驗所開發的系統是否能按照用戶提出要求運行，在測驗階段要使的用戶能成功地安裝新的應用系統來進行測驗，
-
（5）安裝階段測驗：首先要根據系統安裝手冊制定好安裝計劃，確定安裝流程圖，準備好安裝檔案和程式清單，給出安裝測驗的預期結果，并對安裝程序中的各項可能發生的結果進行說明準備，將程式運行的軟硬體要求放入產品說明中，同時要檢查時系統用戶手冊和操作手冊，看是否可用，
-
（6）驗收階段測驗 ：定義用戶角色，定義驗收標準，編制驗收計劃，執行驗收計劃和填寫驗收結論，
38、get和post的請求
-
1、url可見性：get，引數url可見；post，url引數不可見
-
2、資料傳輸上：get，通過拼接url進行傳遞引數；post，通過body體傳輸引數
-
3、快取性：get請求是可以快取的post請求不可以快取
-
4、后退頁面的反應get請求頁面后退時，不產生影響post請求頁面后退時，會重新提交請求
-
5、傳輸資料的大小get一般傳輸資料大小不超過2k-4k（根據瀏覽器不同，限制不一樣，但相差不大）post請求傳輸資料的大小根據php.ini 組態檔設定，也可以無限大，
-
6、安全性這個也是最不好分析的，原則上post肯定要比get安全，畢竟傳輸引數時url不可見，但也擋不住部分人閑的沒事在那抓包玩，安全性個人覺得是沒多大區別的，防君子不防小人就是這個道理，對傳遞的引數進行加密，其實都一樣，
39、alpha測驗和beta測驗的區別
alpha測驗是在用戶組織模擬軟體系統的運行環境下的一種驗收測驗，由用戶或第三方測驗公司進行的測驗，模擬各類用戶行為對即將面市的軟體產品進行測驗，試圖發現并修改錯誤beta測驗時用戶公司組織各方面的典型終端用戶在日常作業中實際使用Beta版本，并要求用戶報告例外情況，提出批評意見，
區別：主要是測驗場所不同，alpha是指把用戶請到開發方的場所來測驗，beta測驗是指在一個或多個用戶的場所進行測驗；alpha測驗的環境是受開發方控制的，用戶的數量相對少，時間比較集中，beta測驗環境不受開發方控制，用戶數量相對多，時間不集中
40、TCP/IP協議的模型和每層的主要協議
從下到上：
-
1、鏈路層（資料鏈路層/網路介面層）：包括作業系統中的設備驅動程式、計算機中對應的網路介面卡
-
2、網路層（互聯網層）：處理分組在網路中的活動，比如分組的選路；（IP、ICMP、IGMP）
-
3、運輸層：主要為兩臺主機上的應用提供端到端的通信（TCP和UDP）
-
4、應用層：負責處理特定的應用程式細節
下面還給大家準備了一份阿里面試題資源
詳情可以關注微信公眾號：程式員二黑，免費獲取
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/263237.html
標籤：其他