- 面試題及決議答案來自牛客網https://www.nowcoder.com/exam/interview/
-
5 了解什么測驗方法？
- 測驗的方法？
- 寫測驗用例的方法？
- 分析測驗點的方法？
- 測驗是個大工程，很多環節，具體是指什么方法？
- 一些分析測驗點的方法：邊界值、等價類、流程圖、場景法、因果圖
- 答案：
- 等價類劃分
- 邊界值分析
- 錯誤推測法
- 因果圖法
- 邏輯覆寫法
- *程式插樁技術？
- 基本路徑法
- *符號測驗？
- *錯誤驅動測驗
-
6 專案中壓力測驗怎么做？
- 明確對哪個部分做壓力測驗，以秒殺活動為例，
- 確定性能需求，明確壓力的性能指標，確定測驗點，對這些測驗點施壓，
- 可以通過寫腳本產生壓力機器人，對服務器進行發包和收包的操作，
- 也可以借助Jemeter、LR工具，模擬多用戶同時操作，
- 明確對測驗點設計的壓力指標，需要明確壓力測驗限制的數量，即用戶并發量，
- 測驗結束后，通過資料定位性能問題，通過測驗可以得到吞吐量、平均回應時間等資料，
- 這個資料是整個后臺處理邏輯綜合作用的結果，此時關注系統的CPU、記憶體，然后對比吞吐量、平均回應時間達到瓶頸時，這些資料的情況，
- 然后就能確認性能問題是系統的哪一塊造成的，
-
7 設計一個朋友圈點贊的測驗用例
-
功能測驗
- 點贊一條朋友圈，驗證是否成功，
- 用例名稱：like-01
- 所屬模塊：點贊模塊
- 優先級：p1
- 標題：朋友圈點贊成功
- 前置條件：賬號已登錄；好友串列不為空；朋友圈串列不為空；聯網，
- 測驗資料：無
- 測驗步驟：點擊“朋友圈”，查看朋友圈資訊，點擊點贊按鈕，
- 預期結果：點贊按鈕由灰色變為紅色，并在點贊串列中顯示當前用戶的頭像，
- 實際結果：執行后添加，
- 測驗版本：
- 測驗人員：
- 備注：
-
介面測驗
- 點贊朋友圈，驗證朋友能否收到提示資訊，
-
性能測驗
- 點贊朋友圈，是否在規定時間顯示結果，是否在規定時間在朋友手機上進行提示，
-
兼容性測驗
- 在不同的終端進行測驗，驗證是否成功，比如iPad、電腦、手機，
-
8 HTTP的報文段是什么樣的？
- 請求格式：起始行-請求頭-空行-請求體（get\delete 無請求體，post\put有請求體）
- 回應格式：起始行-回應頭-空行-回應體
-
內容：
- 起始行：基本資訊 請求——（方法 URL 版本資訊）；回應——（版本 狀態碼 原因）
- header: 報文詳細說明（key:value結構）
- 空行
- [body]：實際傳輸的資料，比如：文本、圖片、視頻......
-
請求——header特有欄位，
- Host: 請求特有欄位， 告訴服務器此請求該由哪個主機負責處理并回應，通常服務器端托管多個虛擬主機，
- User-Agent: 請求特有欄位，描述發起請求的客戶端，讓服務器依據此欄位值來回傳合適此瀏覽器顯示的頁面，
-
回應——header特有欄位
- Server: 服務端向客戶端展示當前正在提供web服務的軟體名稱和版本號，
-
通用欄位
- date：HTTP報文的創建時間，通常顯示在回應頭中，快取策略
- Content-Type: body的長度，
-
補充：狀態碼
- 100~199表示請求已收到繼續處理，
- 200~299表示成功，
- 300~399表示資源重定向，
- 400~499表示客戶端請求出錯，
- 500~599表示服務器端出錯
- 200：回應成功
- 302：跳轉，重定向
- 400：客戶端有語法錯誤
- 403：服務器拒絕提供服務
- 404：請求資源不存在
- 500：服務器內部錯誤
-
9 說一說HTTP請求報文
-
請求報文包含哪幾部分？
- 請求行 包括請求方法，統一資源定位（路徑）， 協議版本，
- 請求頭 包括一系列的欄位名和欄位值，比如Host，告訴服務器指定哪個主機處理請求；User-Agent, 告訴服務器客戶端的瀏覽器描述型別，服務端以此回傳適合在該瀏覽器顯示的頁面，
- 空行 區分請求頭和請求體，
- 請求體 請求的資料，POST和PUT有請求體，GET和DELETE沒有請求體，
-
請求方法都有哪些？
- GET：請求獲取URL標識的資源，
- POST： 在URL所標識的資源后附加資源
- PUT：請求服務器存盤一個資源，由URL作為其標識
- DELETE：請求服務器洗掉由URL所標識的資源
- HEAD：請求獲取由URL標識的資源的回應訊息報頭
- TRACE：用于測驗和診斷，請求服務器回送收到的請求資訊
- CONNECT：保留
- OPTION：請求查詢服務器性能
-
10 說一下TCP三次握手，以及為什么不是兩次，
- TCP：Transmission Control Protocol，面向連接的、可靠的、基于位元組流的傳輸層通訊協議，
- 第一次握手，A向服B發送一個請求，嘗試建立連接；
- 第二次握手，B向A發送請求確認，并發送可建立連接的請求；
- 第三次握手，A向B發送確認建立連接回應，
- 兩次握手，雙方不能都確認可以發送和接收資料，
-
答案：
- 第一次握手：建立連接時，客戶端發送syn包（syn=j）到服務器，并進入SYN_SENT狀態，等待服務器確認；SYN：同步序列編號（Synchronize Sequence Numbers），
- 第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也發送一個SYN包（syn=k），即SYN+ACK包，此時服務器進入SYN_RECV狀態；
- 第三次握手：客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK(ack=k+1），此包發送完畢，客戶端和服務器進入ESTABLISHED（TCP連接成功）狀態，完成三次握手，
- 為什么不是兩次： 在服務端對客戶端的請求進行回應(第二次握手)后，就會理所當然的認為連接已建立，而如果客戶端并沒有收到服務端的回應呢？此時，客戶端仍認為連接未建立，服務端會對已建立的連接保存必要的資源，如果大量的這種情況，服務端會崩潰，
-
自己的理解：
- 第一次握手，客戶端發送請求syn=j；
- 如果服務端可以回應，會發送一個回應ack=j+1，
- 第二次握手，服務端發送回應ack=j+1，并發送新的請求syn=k；
- 如果客戶端可以回應，就需要告訴服務端，
- 第三次握手，客戶端發送回應ack=k+1，
- 三次握手包含兩次請求和回應，且是互相的，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/509037.html
標籤：其他
上一篇：MFC繪圖——金剛石