騰訊軟件測試崗二面：web 測試問題被虐哭了，直到學長給了我這些知識點.....

web 測試一直是大廠軟件測試問到的一個重點，下面給大家展示下大廠關於web 測試經常會問到的一些問題，以及解析。看當面試官問到你這些問題的時候，你是否也能夠對答如流。

web 測試面試真題及解析：

一，描述用瀏覽器訪問 www.baidu.com 的過程

1，先要解析出 baidu.com 對應的 ip 地址：

• 要先使用 arp 獲取默認網關的 mac 地址
• 組織數據發送給默認網關(ip 還是 dns 服務器的 ip，但是 mac 地址是默認網關的 mac 地址)
• 默認網關擁有轉發數據的能力，把數據轉發給路由器
• 路由器根據自己的路由協議，來選擇一個合適的較快的路徑轉發數據給目的網關
• 目的網關(dns 服務器所在的網關)，把數據轉發給 dns 服務
• dns 服務器查詢解析出 baidu.com 對應的 ip 地址，並原路返回請求這個域名的 client 得到了
• baidu.com 對應的 ip 地址之后，會發送 tcp 的 3 次握手，進行連接
• 使用 http 協議發送請求數據給 web 服務器
• web 服務器收到數據請求之后，通過查詢自己的服務器得到相應的結果，原路返回給瀏覽器
• 瀏覽器接收到數據之后通過瀏覽器自己的渲染功能來顯示這個網頁
• 瀏覽器關閉 tcp 連接，即 4 次揮手結束，完成整個訪問過程

2，了解的常用瀏覽器有哪些？

IE，Chrome，Safari，Firefox，Opera

二，以京東首頁為例 ，設計用例框架 。 （注意框架設計邏輯，區域划分 ，專看項測試等，不需要詳細用例，需要查看 PC 可直接和辨識管提要求）

三，如何測試購買下單和退貨流程

產品經理設計了單品優惠，組合優惠，訂單優惠，優惠券優惠（優惠券優惠包含通用券，定向券，滿減券，折扣券）和禮品卡，其中禮品卡上需要單獨購買的。請問如何測試購買下單和退貨流程，需要注意什么？（包含數據存儲）

四，什么是 sql 注入，什么是跨站腳本，什么是跨站請求偽造？

SQL 注入攻擊是注入攻擊最常見的形式（此外還有 OS 注入攻擊（Struts 2 的高危漏洞就是通過OGNL 實施 OS 注入攻擊導致的）），當服務器使用請求參數構造 SQL 語句時，惡意的 SQL 被嵌入到 SQL 中交給數據庫執行。SQL 注入攻擊需要攻擊者對數據庫結構有所了解才能進行，攻擊者想要獲得表結構有多種方式：

（1）如果使用開源系統搭建網站，數據庫結構也是公開的（目前有很多現成的系統可以直接搭建論壇 ，電商網站，雖然方便快捷但是風險是必須要認真評估的）；

（2）錯誤回顯（如果將服務器的錯誤信息直接顯示在頁面上，攻擊者可以通過非法參數引發頁面錯誤從而通過錯誤信息了解數據庫結構，Web 應用應當設置友好的錯誤頁，一方面符合最小驚訝原則，一方面屏蔽掉可能給系統帶來危險的錯誤回顯信息）；

（3）盲注。防范 SQL 注入攻擊也可以采用消毒的方式，通過正則表達式對請求參數進行驗證，此外， 參數綁定也是很好的手段，這樣惡意的 SQL 會被當做 SQL 的參數而不是命令被執行，JDBC 中的 PreparedStatement 就是支持參數綁定的語句對象，從性能和安全性上都明顯優於 Statement。

XSS（Cross Site Script，跨站腳本攻擊）是向網頁中注入惡意腳本在用戶瀏覽網頁時在用戶瀏覽器中執行惡意腳本的攻擊方式。跨站腳本攻擊分有兩種形式：反射型攻擊（誘使用戶點擊一個嵌入惡意腳本的鏈接以達到攻擊的目標，目前有很多攻擊者利用論壇、微博發布含有惡意腳本的 URL 就屬於這種方式）持久型攻擊（將惡意腳本提交到被攻擊網站的數據庫中，用戶瀏覽網頁時，惡意腳本從數據庫中被加載到頁面執行，QQ 郵箱的早期版本就曾經被利用作為持久型跨站腳本攻擊的平台）。

CSRF 攻擊（Cross Site Request Forgery，跨站請求偽造）是攻擊者通過跨站請求，以合法的用戶身份進行非法操作（如轉賬或發帖等）。CSRF 的原理是利用瀏覽器的 Cookie 或服務器的 Session，盜取用戶身份，其原理如下圖所示。防范 CSRF 的主要手段是識別請求者的身份，主要有以下幾種方式：

（1）在表單中添加令牌（token）；

（2）驗證碼；

（3）檢查請求頭中的 Referer（前面提到防圖片盜鏈接也是用的這種方式）。

令牌和驗證都具有一次消費性的特征，因此在原理上一致的，但是驗證碼是一種糟糕的用戶體驗，不是必要的情況下不要輕易使用驗證碼，目前很多網站的做法是如果在短時間內多次提交一個表單未獲得成功后才要求提供驗證碼，這樣會獲得較好的用戶體驗。

五，給你一個網站怎么開展測試？

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

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

3、設計測試用例：

• （1）功能性測試可以包括，但不限於以下幾個方面：鏈接測試；鏈接是否正確跳轉，是否存在空頁面和無效頁面，是否有不正確的出錯信息返回等；提交功能的測試；多媒體元素是否可以正確加載和顯示；多語言支持是否能夠正確顯示選擇的語言等

• （2）界面測試可以包括但不限於以下幾個方面：頁面是否風格統一，美觀。頁面布局是否合理，重點內容和熱點內容是否突出。控件是否正常使用。對於必須但為安裝的空間，是否提供自動下載並安裝的功能。文字檢查。

• （3）性能測試一般從以下兩個方面考慮：壓力測試，負載測試，強度測試

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

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

• （6）兼容性測試，根據需求說明的內容，確定支持的平台組合：瀏覽器的兼容性；操作系統的兼容性； 軟件平台的兼容性；數據庫的兼容性。

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

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

六，電商支付模塊的測試如何展開？

支付流程里面就涉及到了第三方支付接口：

• 下單接口
  商戶提交下單請求到第三方支付接口，第三方支付收單成功后返回下單成功結果給到商戶系統。（下單接口的最終處理結果分為下單成功和下單失敗，若未收到明確結果可調用單筆訂單查詢接口查詢結果。）

• 支付接口
  調用該接口時指定支付參數，完成買家賬戶向商戶賬戶的支付，采用頁面跳轉交互模式和后台通知交互模式。（結果分為兩路返回：一路為前台在 return_url 頁面跳轉顯示支付結果；一路為后台在notify_url 收到支付結果通知后進行響應。）

• 退款接口
  調用第三方支付的支付請求接口返回付款成功后，在需要做退款處理時調用退款請求接口發起退款處理。（退款接口的最終處理結果分為退款成功和退款失敗，若未收到明確結果可調用退款查詢接口查詢結果。）

• 單筆訂單查詢接口

• 根據訂單號查詢單筆訂單信息和狀態。退款訂單查詢接口：調用第三方支付的退款接口返回后，在需要查詢退款請求狀態可調用退款訂單查詢接口查詢退款訂單的狀態和訂單信息。

• 測試過程中需要注意的主要測試點及異常場景：

• 首先要保證接口都能正常調用；

• 生成一筆訂單，支付完成后，同步或異步重復回調，只有一次有效；

• 生成一筆訂單，復制訂單號和金額，再次生成一筆訂單，用 fiddler 設置斷點，用第一筆已完成的訂單號和訂單金額去替換現有的訂單號和金額，無法完成支付；

• 生成一筆訂單，跳轉到第三方時修改金額，無法到賬，或者如果是游戲充值游戲幣的話，到賬為篡改后的金額對應的游戲幣；

• 異步通知屏蔽，同步有效，進行支付，同步能夠正常到賬；

• 同步設置無效，異步有效，進行支付，異步能夠正常到賬；

• 同步異步都設置無效，在第三方支付完成后，在重發機制時間范圍內，設置異步有效，到下次通知時間點時，能夠正常通知到賬（補單機制的驗證，如果商戶收到第三方支付成功的通知后，要告知第三方支付收到了成功的通知，如果第三方支付收到商戶應答不是 ok 或超時，第三方支付就會認為通知失敗，會在規定的時間內持續調用 notify_url，一般有時間或次數的限制）；

• 針對支付訂單在數據庫中存儲是否完整和正確進行校驗（比如：第三方訂單號–方便與第三方對賬和問題排查、訂單金額、訂單狀態等）；

• 如果是用戶購買實物商品，用戶發起退貨，要保證退貨流程正常，資金能正常返還，要考慮下並發情況的驗證以確保安全性；

• 如果是用戶購買虛擬商品，比如話費、油卡之類的商品，只有在發貨失敗的時候才能發起退貨，注意驗證：

總結：

由於文檔的數目有點多，我就不在這里一一展示給大家，我把所有的面試真題，和核心知識點都整理到一個文檔里面了，資料還有關於測試理論 ，Linux 基礎，MySQL基礎，Web 測試，接口測試，App 測試，性能測試等等。300頁的PDF，包含內容很是齊全，每個知識點的解析也分析得透徹。需要資料的朋友可以關注我的微信公眾號：程序員二黑，獲取！