知識永遠學不完，但多懂一點知識就會讓生活更輕鬆一點！
測試遇到問題解決思路
測試中發現實際結果與預期結果不一致時，不要急著找開發，時間久了開發會煩，確保提交到開發手裡的問題確實是問題，這樣他們就沒有理由反駁，而且自己解決問題的能力也會提公升，同時減少與開發不必要的舌戰，自己也輕鬆很多，那麼解決問題的思路如下
首先檢查資料來源是否正確，為什麼說要去檢查資料來源呢，因為有時候是因為配置的資料不正確，不符合要求之類的，所以自己要先確保資料來源是正確的
最後，定位問題，截圖給開發
首先，針對**訪問慢，怎麼去排查？
先確定是使用者端還是服務端的問題。當接到使用者反饋訪問慢，自己先訪問**看看，如果自己這邊訪問快，基本斷定是使用者端問題，就需要耐心跟客戶解釋，協助客戶解決問題。不要上來就看服務端的問題。一定要從源頭開始，逐步逐步往下。
如果自己這邊訪問也慢，那麼可以利用瀏覽器的除錯功能，看看載入那一項資料消耗時間過多，是載入慢，還是某些資料載入慢。
針對伺服器負載情況。檢視伺服器硬體(網路、cpu、記憶體)的消耗情況。如果是購買的雲主機，比如阿里雲，可以登入阿里雲平台提供各方面的監控，比如 cpu、記憶體、頻寬的使用情況。
如果發現硬體資源消耗都不高，那麼就需要通過查日誌，比如看看 mysql慢查詢的日誌，看看是不是某條 sql 語句查詢慢，導致**訪問慢。
其次，考慮有哪些方面的因素會導致****訪問慢？
伺服器出口頻寬不夠用
伺服器負載過大
導致響應不過來
資料庫瓶頸
**開發**沒有優化好，慢載入過多
redis占用過高cpu【key*】大量呼叫key命令
最後，考慮怎麼去解決問題？
如果是出口頻寬問題，那麼久申**大出口頻寬。
如果慢查詢比較多，那麼就要開發人員或 dba 協助進行 sql 語句的優化。
如果資料庫響應慢，考慮可以加乙個資料庫快取，如 redis 等等。然後也可以搭建mysql 主從，一台 mysql 伺服器負責寫，其他幾台從資料庫負責讀。
申請購買 cdn 服務，載入使用者的訪問。
如果訪問還比較慢，那就需要從整體架構上進行優化咯。做到專角色專用，多台伺服器提供同乙個服務
問題2：頁面跳轉空白頁面，怎麼定位問題？
檢視日誌，讓開發把入參出參都列印在日誌中
android還可以用adb匯出日誌
用android studio自己看錯誤日誌
問題3：簡訊驗證碼怎麼校驗：
驗證碼長度【一般4-6位數字】
簡訊驗證碼輸入錯誤次數限制【一般限制輸錯三次即失效】
驗證碼傳送次數限制【一般當天大於3次後需要進行圖形驗證碼校驗/5分鐘內只能傳送3次/60分鐘內只能傳送10次】
簡訊驗證碼有效時間限制【一般5-10分鐘失效】
簡訊驗證碼輸入成功後即刻失效
c/s架構
client/server 客戶端/伺服器架構
基於客戶端/伺服器的三層架構
基於客戶端/伺服器的分布式架構
b/s機構
基於瀏覽器/web伺服器的三層架構
基於中介軟體應用伺服器的三層架構l
基於web伺服器和中介軟體的多層架構
問題4：介面報404的原因有哪些
介面請求位址錯誤
安全漏掃人員使用sql注入***，請求引數中包含敏感字，導致請求失敗
遇到的面試題 「測試杯子」
測試專案 杯子。需求測試 檢視杯子使用說明書，是否有遺漏。介面測試 檢視杯子外觀，是否變形。是否與設計一致。圖案，顏色是否完好無損。功能性 用水杯裝水看漏不漏 水能不能被喝到。安全性 杯子有沒有毒或細菌。可靠性 杯子從不同高度落下的損壞程度。可移植性 杯子在不同的地方 溫度等環境下是否都可以正常使用...
介面測試面試題整理
1 什麼是dns dns，網域名稱解析系統，其實是網域名稱及ip對映關係的乙個庫，使用者輸入網域名稱後，需要通過該系統解析出對應的ip位址 2 http協議 超文字傳輸協議，應用層協議，在tcp之上，指定了客戶端可能向服務端傳送什麼形式的訊息及收到什麼樣的響應 典型的http事務處理有如下的過程 1...
軟體測試面試題整理2
2.tcp udp有哪些區別？tcp 是有連線的，握手過程會消耗資源，過程為可靠連線，不會丟失資料，適合大資料量交換 udp是非可靠連線，會丟包，沒有校驗，速度快，無需握手過程 3.簡述一下c s模式 和b s模式？c s模式 客戶端 服務端模式。工作原理 client向server提交乙個請求 s...