上一個說軟體測試簡單的，已經被面試官問死了。。。

現在已經過了 」不會但我會學「 就能感動面試官的時代，隨著供需關係的變化，不論是對於面試官還是面試者，面試的成本越來越高。為了篩選到更優秀的程式設計師，面試官們可謂是絞盡了腦汁，」面試造火箭，工作擰螺絲「 的傳言也不是空穴來風。

那些面試官最喜歡的就是你在簡歷上寫「精通」或者「熟練掌握」幾個字。。。

我以前也以為自己學明白了，後來經歷的面試越多越覺得自己沒學明白。

哦不，不是沒學明白，是沒學清楚！

騰訊的面試官就賊喜歡問軟體測試基礎部分，字節的還好…所以在我以前通過校招上岸字節跳動後，將我自己的秋招找工作認真總結，並且開源在github上了。

這份筆記包括軟體測試基礎、Linux、Python、計算機網絡、常見軟體測試工具（LR、Jmeter）、資料庫（MySQL為主）、常見邏輯題、以及軟體測試面試中需要注意的問題。

後來我將這份筆記製作成了PDF，現在免費分享給學弟學妹們，趕快白嫖走起~

包括行業分析、薪資和技術匹配分析、職業規劃、基本工作流程、簡歷編寫、面試流程等。

不說了，進來學習！！！！

1.測試結束的標準是什麼？

1.用例全部執行。2.覆蓋率達到標準。3.缺陷率達到標準。4.其他指標達到質量標準

2.測試過程

1) 制定系統測試計劃

2) 編寫系統測試用例

3) 執行系統測試用例

4) 跟蹤管理缺陷

5) 總結測試

3.查看日誌常用什麼命令，主要查看什麼內容

1 查看日誌常用less命令或者view命令。

2 主要查看程序運行的記錄，比如支付失敗，後台就有報錯信息列印到.log日誌文件中，就可以通過分析日誌信息來初步定為問題。（補充：同時也去查詢資料庫，分析訂單數據，查看支付狀態等等）

PS:日誌就是.log的文本文件，和.txt一樣屬於文本文件。vi或者vim編輯器屬於記事本軟體，一般不會用來查看日誌。

4.Mysql 資料庫中怎麼實現分頁？

select * from table limit (start-1)*limit,limit;

其中 start 是頁碼，limit 是每頁顯示的條數。

5.Web 兼容性測試

l首先開展人工測試，測試工程師測試主流瀏覽器和常用作業系統測試主流程和主界面，看看主流程和主界面是否有問題，如果存在問題，那麼記錄下 bug 情況，以及瀏覽器型號和版本，以及作業系統，準確定位bug 產生的原因，提交 bug，告知開發人員修改。所有的主流設備都需要進行測試， 只關注主流程和主界面，畢竟每個系統主流程和主界面不是很多，所以這個工作量還是可以承受的。

其次藉助第三方測試工具，目前我覺得比較好用的第三方 Web 測試工具有 IEtester（離線）、SuperPreview（離線）和 Browsershots：browsershots.org（在線），一款可以測試 IE 的兼容， 一款可以測試主流瀏覽器的兼容，包括谷歌、火狐、Opera 等等。藉助第三方測試工具，找到 bug 產生的位置，分析測試結果，告知程式設計師調整。

6. 如何設計自動化測試用例:

l編寫測試腳本之前要編寫測試用例，而且測試用例不能直接使用手工測試的用例。

l自動化的測試用例是一個完整的場景。用戶登錄系統到用戶退出。

l用例之驗證一個功能點。不用試圖登陸後驗證所有的功能在退出

l測試用例儘量只做正向的邏輯驗證。

l用例之間不要產生關聯，相互獨立，也要高內聚，低耦合

l測試用例關注的是功能邏輯的實現，欄位無關

l測試用例的上下文必須有一定的順序性，前置條件清晰

l檢查點的設置要側重，全面，靈活

l測試用例對數據的操作要進行還原

l測試用例必須是可回歸的

l用例選擇遵循成本始終，構建場景，目的冒煙回歸，繁瑣功能，主體流程

l用例轉型遵循前置配置，拋異常，步驟驗證，高內聚，關門歸原

7 服務端性能分析都從哪些角度來進行？

從維度上劃分，性能指標主要分為兩大類，分別是業務性能指標和系統資源性能指標。業務性能指標可以直觀地反映被測系統的實際性能狀況，常用的指標項有：

1.並發用戶數

2.事務吞吐率（TPS/RPS）

3.事務平均響應時間

4.事務成功率

系統資源性能指標，主要是反映整個系統環境的硬體資源使用情況，常用的指標包括：

1.伺服器：CPU 利用率、處理器隊列長度、內存利用率、內存交換頁面數、磁碟 IO 狀態、網卡帶寬使用情況等；

2.資料庫：資料庫連接數、資料庫讀寫響應時長、資料庫讀寫吞吐量等；

3.網絡：網絡吞吐量、網絡帶寬、網絡緩衝池大小；

4.緩存（Redis）：靜態資源緩存命中率、動態數據緩存命中率、緩存吞吐量等；

5.測試設備（壓力發生器）：CPU 利用率、處理器隊列長度、內存利用率、內存交換頁面數、磁碟 IO 狀態、網卡帶寬使用情況等。

8 如何理解壓力測試，負載測試以及性能測試？

性能測試（Performance Test）：通常收集所有和測試有關的所有性能，被不同人在不同場合下進行使用。

壓力測試 stress test：是在一定的『負荷條件』下，長時間連續運行系統給系統性能造成的影響。負載測試 Load test：在一定的『工作負荷』下，給系統造成的負荷及系統響應的時間。

9.編寫一個http 接口性能測試方案，測試過程的關注點有哪些，流程等？

一、準備工作

1、系統基礎功能驗證

性能測試在什麼階段適合實施？切入點很重要！一般而言，只有在系統基礎功能測試驗證完成、系統趨於穩定的情況下，才會進行性能測試，否則性能測試是無意義的。

2、測試團隊組建

根據該項目的具體情況，組建一個幾人的性能測試 team，其中 DBA 是必不可少的，然後需要一至幾名系統開發人員（對應前端、後台等），還有性能測試設計和分析人員、腳本開發和執行人員；在正式開始工作之前，應該對腳本開發和執行人員進行一些培訓，或者應該由具有相關經驗的人員擔任。

3、工具的選擇

綜合系統設計、工具成本、測試團隊的技能來考慮，選擇合適的測試工具，最起碼應該滿足一下幾點： 支持對 web（這裡以 web 系統為例）系統的性能測試，支持 http 和 https 協議；工具運行在 Windows 平台上； 支持對 webserver、前端、資料庫的性能計數器進行監控；

4、預先的業務場景分析

為了對系統性能建立直觀上的認識和分析，應對系統較重要和常用的業務場景模塊進行分析，針對性的進行分析，以對接下來的測試計劃設計進行準備。

二、測試計劃

測試計劃階段最重要的是分析用戶場景，確定系統性能目標。

1、性能測試領域分析

根據對項目背景，業務的了解，確定本次性能測試要解決的問題點；是測試系統能否滿足實際運行時的需要，還是目前的系統在哪些方面制約系統性能的表現，或者，哪些系統因素導致系統無法跟上業務發展？

確定測試領域，然後具體問題具體分析。

2、用戶場景剖析和業務建模

根據對系統業務、用戶活躍時間、訪問頻率、場景交互等各方面的分析，整理一個業務場景表，當然其中最好對用戶操作場景、步驟進行詳細的描述，為測試腳本開發提供依據。

3、確定性能目標

前面已經確定了本次性能測試的應用領域，接下來就是針對具體的領域關注點，確定性能目標（指標）； 其中需要和其他業務部門進行溝通協商，以及結合當前系統的響應時間等數據，確定最終我們需要達到的響應時間和系統資源使用率等目標；比如：

登錄請求到登錄成功的頁面響應時間不能超過 2 秒；報表審核提交的頁面響應時間不能超過 5 秒；文件的上傳、下載頁面響應時間不超過 8 秒；伺服器的 CPU 平均使用率小於70%，內存使用率小於 75%；各個業務系統的響應時間和伺服器資源使用情況在不同測試環境下，各指標隨負載變化的情況等；

4、制定測試計劃的實施時間

預設本次性能測試各子模塊的起止時間，產出，參與人員等等。

三、測試腳本設計與開發

性能測試中，測試腳本設計與開發占據了很大的時間比重。

1、測試環境設計

本次性能測試的目標是需要驗證系統在實際運行環境中的性能外，還需要考慮到不同的硬體配置是否會是制約系統性能的重要因素！因此在測試環境中，需要部署多個不同的測試環境，在不同的硬體配置上檢查應用系統的性能，並對不同配置下系統的測試結果進行分析，得出最優結果（最適合當前系統的配置）。

這裡所說的配置大概是如下幾類：資料庫伺服器;應用伺服器;負載模擬器;軟體運行環境，平台。

測試環境測試數據，可以根據系統的運行預期來確定，比如需要測試的業務場景，數據多久執行一次備份轉移，該業務場景涉及哪些表，每次操作數據怎樣寫入，寫入幾條，需要多少的測試數據來使得測試環境的數據保持一致性等等。可以在首次測試數據生成時，將其導出到本地保存，在每次測試開始前導入數據， 保持一致性。

2、測試場景設計

通過和業務部門溝通以及以往用戶操作習慣，確定用戶操作習慣模式，以及不同的場景用戶數量，操作次數，確定測試指標，以及性能監控等。

3、測試用例設計

確認測試場景後，在系統已有的操作描述上，進一步完善為可映射為腳本的測試用例描述，用例大概內容如下：

用例編號：查詢表單_xxx_x1（命名以業務操作場景為主，簡潔易懂即可） 用例條件：用戶已登錄、具有對應權限等

操作步驟：系統業務場景描述

4、腳本和輔助工具的開發及使用

按照用例描述，可利用工具進行錄製，然後在錄製的腳本中進行修改；比如參數化、關聯、檢查點等等， 最後的結果使得測試腳本可用，能達到測試要求即可；建議儘量自己寫腳本來實現業務操作場景，這樣對個人技能提升較大；一句話：能寫就絕不錄製！！！

四、測試執行與管理

在這個階段，只需要按照之前已經設計好的業務場景、環境和測試用例腳本，部署環境，執行測試並記錄結果即可。

1、建立測試環境

按照之前已經設計好的測試環境，部署對應的環境，由運維或開發人員進行部署，檢查，並仔細調整， 同時保持測試環境的乾淨和穩定，不受外來因素影響。

2、執行測試腳本

這一點比較簡單，在已部署好的測試環境中，按照業務場景和編號，按順序執行我們已經設計好的測試腳本。

3、測試結果記錄

根據測試採用的工具不同，結果的記錄也有不同的形式；現在大多的性能測試工具都提供比較完整的界面圖形化的測試結果，當然，對於伺服器的資源使用等情況，可以利用一些計數器或第三方監控工具來對其進行記錄，執行完測試後，對結果進行整理分析。

五、測試分析

1、測試環境的系統性能分析

根據我們之前記錄得到的測試結果（圖表、曲線等），經過計算，與預定的性能指標進行對比，確定是否達到了我們需要的結果；如未達到，查看具體的瓶頸點，然後根據瓶頸點的具體數據，進行具體情況具體分析（影響性能的因素很多，這一點，可以根據經驗和數據表現來判斷分析）。

2、硬體設備對系統性能表現的影響分析

由於之前設計了幾個不同的測試環境，故可以根據不同測試環境的硬體資源使用狀況圖進行分析，確定瓶頸是在資料庫伺服器、應用伺服器抑或其他方面，然後針對性的進行優化等操作。

3、其他影響因素分析

影響系統性能的因素很多，可以從用戶能感受到的場景分析，哪裡比較慢，哪裡速度尚可，這裡可以根據 2\5\8 原則對其進行分析；至於其他諸如網絡帶寬、操作動作、存儲池、線程實現、伺服器處理機制等一系列的影響因素，具體問題具體分析，這裡就不一一表述了。

4、測試中發現的問題

在性能測試執行過程中，可能會發現某些功能上的不足或存在的缺陷，以及需要優化的地方，這也是執行多次測試的優點。

​