記錄一次測開面試題記錄

1.一次完整 http 請求需要經歷那些流程，描述一下請求過程？

1.瀏覽器輸入對應的 url
2.解析域名，找到主機 ip 地址
3.瀏覽器與主機建立 tcp 連線
4.瀏覽器定向發起定向請求
5.伺服器響應請求，返回 html 頁面

2.https 和 http 的區別？

1.https 協議需要到 CA 申請證書，一般免費證書較少，因而需要一定費用
2.http 是超文字傳輸協議，資訊是明文傳輸，https 則是具有安全性的 ssl/tls 加密傳輸協議。
3.http 和 https 使用的是完全不同的連線方式，用的埠也不一樣，前者是 80，後者是 443
4.http 的連線很簡單，是無狀態的；HTTPS 協議是由 SSL/TLS+HTTP 協議構建的可進行加密傳輸、身份認證的網路協議，比 http 協議安全。

3.cookie 和 session 的區別？

1.cookie 資料存放在客戶的瀏覽器上，session 資料放在伺服器上。
2.cookie 不是很安全，別人可以分析存放在本地的 COOKIE 並進行 COOKIE 欺騙考慮到安全應當使用 session。
3.設定 cookie 時間可以使 cookie 過期。但是使用 session-destory（），將會銷燬會話。
4.session 會在一定時間內儲存在伺服器上。當訪問增多，會比較佔用你伺服器的效能考慮到減輕伺服器效能方面，應當使用 cookie。
5.單個 cookie 儲存的資料不能超過 4K，很多瀏覽器都限制一個站點最多儲存 20 個 cookie。(Session 物件沒有對儲存的資料量的限制，其中可以儲存更為複雜的資料型別)

** 備註：**
兩者最大的區別在於生存週期，一個是瀏覽器啟動到瀏覽器關閉.(瀏覽器頁面一關 ,session 就消失了)，一個是預先設定的生存週期，或永久的儲存於本地的檔案。(cookie)

4.介面測試常用的幾種資料準備方式？

1.yaml 檔案方式
2.json 檔案 方式
3.csv 檔案方式
4..xlsx，excel 方式
5.讀取資料庫的方式
** 要是面試官問方法的話可以如下回答：**

1.如果是隻測試一次的介面，可以使用硬編碼的方式準備測試資料，在寫測試程式碼的時候，使用到什麼資料就寫什麼資料，為了避免資料重複，可能比較多的會用到隨機字元或隨機數
2.可以直接透過呼叫其他 API 的方式準備測試資料，這種情況在測試最上層服務的時候比較有用，比如測試團購購買服務，就需要準備要購買的團購資料，購買團購的使用者資料，這個時候，可以直接呼叫生產團購的 api 和生成使用者的 api 直接生成測試資料
3.使用 excel 或 xml 準備測試資料，這種準備測試資料的方式，主要針對物件資料的準備，比如可以將一條團購資料對應 excel 中的一條資料，因為一般開發都會使用 pojo 對映，而在準備測試資料的時候，這些 pojo 物件屬性的設定往往是重複和大工作量的，用 excel 或 XML 方式準備，則可以減少在程式碼當中重複去準備這些資料。
4.也可以使用工具方法的形式去準備測試資料，透過在程式碼中寫工具方法去實現資料生成，而在測試程式碼中呼叫工具方法去得到所需資料。

5.web 和 app 測試有什麼異同？

1.相同點

1.測試流程相同：都需要立項，反串講，用例設計，測試執行，缺陷管理，測試報告，上線，線上持續跟進
2.測試內容和測試方法相同：都需要功，性，安與 Gui 的等一系列的測試

2.不同點

1.效能測試：web 主要吞吐量和響應時間這兩個要素。App 需要考慮流量，耗電，幀率等
2.相容性：web 需要相容瀏覽器，App 需要相容的是裝置，前者是軟體相容，後者需要考慮硬體以及系統版本等
3.install：web 沒有客戶端，App 是存在使用者本地的，所以需要
3.App 是基於手機裝置的，所以需要部分專項測試，例如交叉事件測試，操作型別測試，網路測試
4.架構層面：web 只需要 跟新 service 端，客戶端就會同步跟新，可以保證每個 user 的客戶端都能保持一直（但是需要注意，個性化配置的客戶端），App 是不能保持一致的，除非客戶端跟新，如果客戶端下更改了 service 端，那麼所有的核心版本，都需要回歸測試一遍
5.升級測試：web 沒有，App 需要有提醒機制，升級是否會影響原有功能的使用，升級之後，本地資料是否被抹除了，以及快取的相容性

6.測試 App 登入場景

功能層面

1.輸入已註冊的使用者名稱和正確的密碼，驗證是否登入成功；
2.輸入已註冊的使用者名稱和不正確的密碼，驗證是否登入失敗，並且提示資訊正確；
3.輸入未註冊的使用者名稱和任意密碼，驗證是否登入失敗，並且提示資訊正確；
4.使用者名稱和密碼兩者都為空，驗證是否登入失敗，並且提示資訊正確；
5.使用者名稱和密碼兩者之一為空，驗證是否登入失敗，並且提示資訊正確；
6.如果登入功能啟用了驗證碼功能，在使用者名稱和密碼正確的前提下，輸入正確的驗證碼，驗證是否登入成功；
7.如果登入功能啟用了驗證碼功能，在使用者名稱和密碼正確的前提下，輸入錯誤的驗證碼，驗證是否登入失敗，並且提示資訊正確。
8.使用者名稱和密碼是否大小寫敏感；
9.頁面上的密碼框是否加密顯示；
10.後臺系統建立的使用者第一次登入成功時，是否提示修改密碼；
11.忘記使用者名稱和忘記密碼的功能是否可用；
12.前端頁面是否根據設計要求限制使用者名稱和密碼長度；
13.如果登入功能需要驗證碼，點選驗證碼圖片是否可以更換驗證碼，更換後的驗證碼是否可用；
14.重新整理頁面是否會重新整理驗證碼；
15.如果驗證碼具有時效性，需要分別驗證時效內和時效外驗證碼的有效性；
16 使用者登入成功但是會話超時後，繼續操作是否會重定向到使用者登入介面；
17 不同級別的使用者，比如管理員使用者和普通使用者，登入系統後的許可權是否正確；
18.頁面預設焦點是否定位在使用者名稱的輸入框中；
19.快捷鍵 Tab 和 Enter 等，是否可以正常使用。

安全層面

1. 使用者密碼後臺儲存是否加密；
2. 使用者密碼在網路傳輸過程中是否加密；
3. 密碼是否具有有效期，密碼有效期到期後，是否提示需要修改密碼；
4. 不登入的情況下，在瀏覽器中直接輸入登入後的 URL 地址，驗證是否會重新定向到使用者登入介面；
5. 密碼輸入框是否不支援複製和貼上；
6. 密碼輸入框內輸入的密碼是否都可以在頁面原始碼模式下被檢視；
7. 使用者名稱和密碼的輸入框中分別輸入典型的 “SQL 注入攻擊” 字串，驗證系統的返回頁面；
8. 使用者名稱和密碼的輸入框中分別輸入典型的 “XSS 跨站指令碼攻擊” 字串，驗證系統行為是否被篡改；
9. 連續多次登入失敗情況下，系統是否會阻止後續的嘗試以應對暴力破解；
10. 同一使用者在同一終端的多種瀏覽器上登入，驗證登入功能的互斥性是否符合設計預期；
11. 同一使用者先後在多臺終端的瀏覽器上登入，驗證登入是否具有互斥性。

效能層面

1. 單使用者登入的響應時間是否小於 3 秒；
2. 單使用者登入時，後臺請求數量是否過多；
3. 高併發場景下使用者登入的響應時間是否小於 5 秒；
4. 高併發場景下服務端的監控指標是否符合預期；
5. 高集合點併發場景下，是否存在資源死鎖和不合理的資源等待；
6. 長時間大量使用者連續登入和登出，伺服器端是否存在記憶體洩漏。

相容層面

1. 不同瀏覽器下，驗證登入頁面的顯示以及功能正確性；
2. 相同瀏覽器的不同版本下，驗證登入頁面的顯示以及功能正確性；
3. 不同移動裝置終端的不同瀏覽器下，驗證登入頁面的顯示以及功能正確性；
4. 不同解析度的介面下，驗證登入頁面的顯示以及功能正確性。
其他的還有很多方面的，暫時腦子就儲存這些了。。。。。
c

student 表（id，name，age）查詢 student 中重複的名稱？

select * from student a where (a.name) in  (select name from student group by name  having count(*) > 1)

使用你熟悉的語言寫一個氣泡排序，陣列 A 排序，int[]={11，2，5，82，7，0，4，89，72，42}

** 偷懶寫法 **
使用內建排序函式

A = [11, 2, 5, 82, 7, 0, 4, 89, 72, 42]
A.sort()
print(A)

結果如下（雖然完成了，但是沒有冒泡）

[0, 2, 4, 5, 7, 11, 42, 72, 82, 89]

** 冒泡寫法 **

def bubble_sort(lists):
    # 氣泡排序
    count = len(lists)
    for i in range(0, count):
        for j in range(i + 1, count):
            if lists[i] > lists[j]:
                lists[i], lists[j] = lists[j], lists[i]
    return lists

linux 命令，在 a.log 中查詢 abc

cat -n a.log | grep abc 

查詢 80 埠占用情況

lsof -i:80

效能測試報告需要關注那欄位？

1. 併發使用者數
2. 資源性質
3. 使用者平均請求等待時間 和 伺服器處理請求的平均時間