一、測試理論
3.1 你們原來專案的測試流程是怎麼樣的?
我們的測試流程主要有三個階段：需求瞭解分析、測試準備、測試執行。
1、需求瞭解分析階段 我們的 SE 會把需求文件給我們自己先去了解一到兩天這樣，之後我們會有一個需求澄清會議， 我們會把不明白不理解的需求在會議上說出來，包含需求的合理性還有需求的可測性等， 產品這邊解答，目的是讓我們測試這邊和開發對需求的理解達到一致。
2、測試準備階段 會議結束之後我們開始準備測試工作，我們測試這邊會寫一個測試計劃，分配每個人負責的模組， 然後我們就根據自己負責的模組用 xmind(思維導圖)進行測試需求分析，分析測試點， 以及編寫測試用例，之後我們會在自己的組內先進行評審，評審修改之後還會在我們的專案組評審， 評審完後進行修改測試用例。
3、測試執行階段 開發人員編寫好程式碼之後，我們會把程式碼包透過 Jelkins 部署到測試環境提測，進行 SIT 測試， 在正式測試之前我們會先做一個冒煙測試，冒煙測試透過之後我們才轉測，在執行測試的過程中， 我們如果發現 bug 就會用 tapd(或者禪道)記錄並且提交 bug，也會進行 bug 複測，以及迴歸測試， 每一輪測試結束之後我們都會寫一個測試報告，一般情況下，測試 4-5 輪之後會達到上線要求， 當達到上線的標準後，測試報告會認為測試透過，上線前我們會做預釋出測試，預釋出透過後， 由專案組與產品決定時間上線，上線完成，一週左右我們會寫一個專案總結測試報告， 總結我們在上一個版本中遇到的問題以及今後有哪些地方需要改進，在產品選代過程中， 我們會跑自動化用例來進行迴歸測試。
3.2 如果需求不明確的話你怎麼辦?
需求不明確的話我會在需求澄清會議上面提出來，問清楚這個需求只有明確需求， 才能更好的完成工作，後續工作中還是不清楚，可以找產品再去確認這個需求。
3.3 有哪些需要評審，哪些人在
1、 xmind 思維導圖評審，主要是測試人員 2、測試用例需要評審，測試人員，開發人員，產品人員 3、需求文件，專案組所有的人員，都會到場
3.4 有沒有寫過測試計劃，具體包括哪些內容?
參考答案 1： 測試計劃內容： (1)目的和範圍 (2)規程 (3)測試方案和方法 (4)測試的准入和準出 (5)測試計劃(流程、時間安排、對應人員) (6)測試的環境配置和人員安排 (7)交付件 華測教育專屬 華測教育專屬 華測教育專屬 華測教育專屬 華測教育專屬 華測教育專屬 華測教育專屬 華測教育專屬 華測教育專屬 15 參考答案 2 我們公司之前按照考核要求寫過測試計劃，不過後面老大覺得太耽誤工作進度， 後面一般都不再寫測試計劃，而是寫版本計劃，這個在版本計劃，每個人的任務列出來， 負責人列出來，自己根據自己的情況分配時間，然後彙總，大家一起開個小會評審就可以了。
3.5 用例包含哪些部分，哪些用例設計方法，你一般常用哪些方法?
原來我們用例包含 測試專案，用例編號、測試標題、優先順序、預置條件、操作步驟、測試資料、預期結果 黑盒測試用例設計方法：主要是等價類、邊界值、錯誤推測法、判定表、因果圖、正交表、 流程分析法、狀態遷移法、異常分析法。 常用的：等價類、邊界值、判定表、流程分析法、錯誤推測法。 等價類是指某個輸入域的子集合，在該子集合中， 各個輸入資料對於揭露程式中的錯誤都是等效的， 併合理地假定：測試某等價類的代表值就等於對這一類其它值的測試，因此，可以把全部 輸入資料合理劃分為若干等價類，在每一個等價類中取一個資料作為測試的輸入條件， 就可以用少量代表性的測試資料取得較好的測試結果， 等價類劃分可有兩種不同的情況有效等價類和無效等價類。 邊界值的話就是對等價類劃分方法的補充。測試工作經驗告訴我，大量的錯誤往往是發生在輸入或輸 出範圍的邊界上而不是發生在輸入輸出範圍的內部，因此的話針對各種邊界情況來設計測試用例，可 以查出更多的錯誤，使用邊界值分析方法設計測試用例的話，首先應該確定邊界情況，通常輸入和輸 出等價類的邊界，就是應著重測試的邊界情況應當選取正好等於，剛剛大於或剛剛小於邊界的值作為 測試資料，而不是選取等價類中的典型值或任意值作為測試資料。 對於錯誤推斷法，這個是基於經驗和直覺推測程式中所有可能存在的各種錯誤， 從而有針對性的去設計測試用例的方法的，主要就是列舉出程式中所有可能有的錯誤和容易發生錯誤 的特殊情況去根據這些情況來選擇測試用例，例如，在單元測試時曾列出的許多在模組中常見的錯誤 以前產品測試中曾經發現的錯誤等，這些就是經驗的總結。還有，輸入資料和輸出資料為 0 的情況。 輸入表格為空格或輸入表格只有一行。這些都是容易發生錯誤的情況，可選擇這些情況下的例子作為 測試用例。 前面介紹的等價類劃分方法和邊界值分析方法都是著重考慮輸入條件但都沒有考慮輸入條件之間的 聯絡，相互組合等等的情況。考慮輸入條件之間的相互組合，可能會產生一些新的情況， 但是要檢查輸入條件的組合並不是一件容易的事情，即使把所有輸入條件劃分成等價類， 他們之間的組合情況也相當多，因此的話可以考慮採用一種適合於描述對於多種條件的組合，相應產生多個動作的形式來考慮設計測試用例，這就需要用到因果圖(邏輯模型)。 因果圖方法最終生成的就是判定表它適合檢查程式輸入條件的各種組合情況。
3.6 TestLink 工具使用?
(1)建立使用者，並給新建立的使用者指定許可權。 (2)建立測試用例，對測試用例進行增、刪、改、查 (3)把測試用例關聯到對應的測試計劃中。 (4)把測試用例指派給對應的測試人員。 (5)對應的測試人員，檢視被指派的測試用例，並執行測試用例。
3.7 如何提交一個好的 BUG
對 BUG 有一個清晰明瞭的描述； 詳細描述 BUG 重現的步驟 對於產生 BUG 的環境進行描述； 提交 BUG 相關的圖片和日誌; 定位好 BUG 的等級； 將預期結果與實際結果進行對比。
3.8 提 bug 需要注意哪些問題?
1) 不要急著提交，先跟開發說明 bug 的情況，定位分析下 bug。 是前端問題還是後端問題再去提交 bug。 2) 簡單明瞭的概括 bug 標題，清晰的描述 bug 重現步驟，分析 bug 和預期正確結果，附加 bug 的截 圖或者日誌。描述 bug 的時候。 3) 在不能確認該情況是否為 bug 的時候，可以請教其他人。 4) 提交完 bug 以後，後面還要跟蹤 bug 修復情況。
3.9 bug 怎麼管理的，bug 的生命週期或者是 bug 的狀態
原來 bug 是用禪道來管理的 原來我們公司 bug，提交 bug 直接給對應的開發人員，對應開發人員修復完成，交給測試複測， 複測透過關閉 bug，不透過打回給對應開發。 提交-開發人員(已啟用未確認)-開發進行確認，狀態變成已啟用，已確認，開發修復完成， 標註狀態是已修復，測試人員複測透過，已關閉，打回給對應開發，已經啟用。
3.10 提交 bug 包含哪些內容
所屬產品、所屬模組、所屬專案、影響版本、指派人員 截止日期、嚴重程度、優先順序、bug 型別、bug 環境 Bug 標題、重現步驟、附件
3.11 你提交的 bug，開發不認可怎麼辦?
首先我會再看需求文件，是不是我的理解有誤，如果是我對需求理解錯的話我就去關閉 bug。 如果是 bug 再去讓其他測試人員看看聽下他們的意見，然後自己先再三去複測，並目儲存好截圖和日 志，確定這是一個 bug 之後我就去跟開發說明白，並且給他看 bug 重現的截圖以及日誌，如果開發還 是不認可的話我就跟產品或專案經理說明白情況。
3.12 對應無法重現 bug，應該怎麼處理?
首先，我會多測幾次，測了好多次都無法重現的話我就先把 bug 掛起，並且留意一下，看看往後的測 試中，如果在後面的測試中重現 bug 就啟用，如果經過幾個版本都還沒發現的話就關閉 bug。
3.13 介面中的亂碼可以是哪裡導致的?
(1)資料庫中的編碼設定 (2)前端頁面編碼 (3)後臺程式碼也會編碼
3.14 bug 的級別有哪些，級別如何判斷
1、致命：對業務有至關重要的影響，業務系統完全喪失業務功能，無法再繼續進行， 或業務系統丟失了業務資料且無法恢復，影響公司運營的重要業務資料出錯。 2、嚴重：對業務有嚴重的影響，業務系統已經喪失可部分的重要的業務功能，或業務系統 丟失了業務資料且可以恢復，一般業務資料出錯。 3、一般：對業務有較小的影響，業務系統喪失了較少的業務功能， 例如：介面錯誤，列印或顯示格式錯誤。 4、提示：對業務沒有影響，不影響業務過程正常進行， 例如：輔助說明描述不清楚，提示不明確的錯誤提示。
3.15 測試中，如何判斷是前端的 bug 還是後端的 bug 呢?
通常可以利用抓包工具來進行分析。可以從三個方面進行分析：請求介面、傳引數、響應。 1）請求介面 un 是否正確如果請求的介面 ur 錯誤，為前端的 bug 2）傳參是否正確如果傳參不正確，為前端的 bug 3）請求介面 u 和傳參都正確，檢視響應是否正確如果響應內容不正確，為後端 bug 4）也可以在瀏覽器控制檯輸入 js 程式碼除錯進行分析
3.16 專案上線後發現 bug，測試人員應該怎麼辦
看嚴重級別：嚴重還是不嚴重 嚴重的：緊急變更上線 不嚴重：修復好後跟下個版本一起上線 使用者會透過運維反饋到專案組這邊，專案經理會根據功能模組的負責人，分給對應的開發與測試。 測試人員：編寫對應的測試用例、測試環境中重現 bug、提交 bug、 交給開發進行修復、修復完成 bug、進行 bug 的複測。 如果測試環境無法重現，可以匯入生產環境的包到測試環境中測試， 還是不能復現，檢視生產環境的日誌去定位問題。
3.17 如何保證質量
(1)需求要吃透，多問，多去了解。 (2)嚴格按照測試流程去執行：多考慮使用者測試場景，使用測試用例設計方法，多評審。 (3)要有良好的測試執行：要求用例執行率達到 100%，多輪測試，進行探索性測試， 需要測試之間交叉測試，用工具來管理我們的測試工作(禪道， testlink， excel，tapd) (4)不斷的反思與提升。
3.18 產品是怎麼上線的?
一般我們會選擇晚上上線，開發測試還有產品全部到場，進行上線測試。 首先，開發將程式碼打包到生產環境的伺服器中，如果資料表有變化，就會執行 sql 檔案， 對錶的一些操作，接著，我們測試就開始先測試主體業務功能以及新增的功能模組; 測試透過之後，我們會在介面上把上線測試的資料刪除，正常上線。 如果發現 bug，開發人員當場修復 bug，修復成功之後我們測試再複測，透過就可以正常上線 如果發現了 bug 開發人員在上線規定時間之前都還沒有修復好的話，就看問題的嚴重性， 如果嚴重就延期上線，如果我們是迭代版本的話我們還需要版本回滾。 如果不嚴重，產品跟客戶覺得可以上線，就正常上線。
二、介面測試
9.1 介面測試怎麼測
（jmeter 版本） 首先開發會給我們一個介面文件，我們根據開發給的介面文件，進行測試點的分析，主要是考慮正常 場景與異常場景，正常場景，條件的組合，引數的格式校驗等價邊界值;異常場景，多一個引數，少 個必填引數，引數為空;接著編寫測試用例，用的 Jmeter 工具去執行，建立執行緒組，建立 http 請求， 輸入測試用例，請求引數，建立察看結果樹，執行，看返回的結果，是否跟介面文件裡面要求的返回 結果一致，其他用例，值需要修改裡面的引數，請求地址這些資訊。 舉例說明：(不要登入跟註冊) 比如說原來我們做一個申請借款的介面，對介面進行測試分析，考慮正常場景與異常場景，正常場景， 考慮不同引數組合，比如說，不同借款方式，還款期限，還款曰期，借款的利率等引數組合;也要測 試每個引數格式校驗，異常場景，：多一個引數，少一個必填引數，比如沒有借款的利率，引數為空 的，比如借款標題為空，編寫測試用例 在 jmeter 中執行，填寫引數，更地址就 ok，傳送請求 （python + request） 原來我們介面主要是用的 python + requests 去執行的 首先，開發會給我們一個介面文件，拿到介面文件後，我們就進行測試點的分析， 考慮正確場景，條件的組合， 異常場景，多一個引數，少一個引數，引數為空的情況 比如原來我們做一個生成訂單的介面，考慮正常場景，異常場景 正常場景就是不同的訂單型別，訂單金額，能不能申請訂單，每個引數的格式型別的校驗， 異常場景，多一個引數，少一個必填引數的時候，還有引數為空的情況 原來我們是用 python + request 去做的介面 首先，匯入 request 包 建立一個 headers，儲存請求頭的資訊，因為訂單請求方式是 post 型別，資料格式是 form 表單格式， 我們把資料儲存到 data 的字典裡面 這個時候我們還需求登入的 cookie 值跟登入後產生的 token 值 我們會去透過動態關聯去獲取登入的 token 跟 cookies， cookies 值的話，我們是直接呼叫登入返回的 cookies、token 值的時候，我能是透過匯入 re 模組， 透過正規表示式去提取 當引數， headers、cookies 輸入完成以後，我們就傳送請求，列印返回結果，檢返回結果是否跟我 們測試用例一致 當執行其他測試用例時，我們去修改 data 裡面的引數就行，在傳送請求 有的請求時 htps 協議的時候，我們傳送請求的時候還會 very= false 去忽略掉證書驗 證對應多個介面呼叫 cookies 我們會用到 session 去儲存介面發現比較多的問題，就是格式校驗這 塊 比如說我們提交訂單，訂單資料沒有顯示，訂單格式也沒有顯示，輸入字母，漢字都可以 訂單型別為空，也會生成訂單成功 我覺得介面可以發現介面更多的 bug，還可以提早進行測試，提高測試的質量
9.2 兩個介面有關聯， jmeter 具體怎麼做
另外兩種問法：上個介面的返回值是下個介面的請求引數，這種如何處理?動態關聯有沒有了解過? 這個涉及到動態關聯，首先要搞清楚後一個介面需要用到上一個介面的什麼資料，例外要看資料是在 哪裡取的，是在 head 還是在 body 裡，然後如果要取的資料是 json 格式我會在發請求用 json 提取器 去取這個資料，如果是其他格式的就用邊界提取器或正規表示式去取資料 就拿我當時做的那個下單介面來說吧，因為下單介面需要先登入，需要用到登入介面的 cookies 來做鑑權，首先就是把登入介面除錯透過，然後在登入介面的 http 請求中新增一 個邊界值提取器或者也可以用正則表示式提取器去提取登入介面的響應頭中的 cookies 值 然後在下單介面中需要新增一個 http cookies 管理器，在 http cookies 管理器中引用登入 介面提取出來的 cookies，這樣就可以了 如果是不同的執行緒組的話，那在登入介面中還得新增一個 Beanshell 取樣器，在 Beanshell 取樣器中，利用函式助手中的 SetProperty()函式把提取出來的 cookies 設定為全域性變數， 然後在下單介面的 http cookies 管理器中利用函式助手中的 Property()函式引用登入介面中設定的 全域性變數，這樣就可以了。
9.3 介面測試主要目的是什麼?
例外兩種問法：介面測試的價值，意義?為什麼要做介面測試? 主要就是驗證後臺服務端的業務邏有沒有問題，提高測試的效率 ①越底層發現 bug，它的修復成本是越低的 ②前端頁面修改頻繁情況下，介面測試不受頁面元素改變而影響 ③檢查系統的安全性，前端傳參不可信，比如京東購物，前端價格不可能傳入-1 元，但是 透過介面可以傳入-1 元 ④如今的系統複雜度不斷上升，傳統的測試方法成本急劇增加且測試效率大幅下降，介面自動化測試 可以提高測試效率 ⑤介面測試相對容易實現自動化持續整合，且相對 U 自動化也比較穩定，可以減少人工，迴歸測試人 力成本與時間，縮短測試周期
9.4 介面測試的流程
1，首先分析開發給到的介面文件 2，介面文件分析完成，編寫測試用例 3，然後藉助介面測試工具去測試執行測試用例 4，發現 bug 提交 bug，並跟進 bug 修復
9.5 介面測試和平常的 Ul 測試有什麼區別?
其實這兩者測試的側重點是不同的，介面因為沒有介面，更多考慮後臺伺服器對請求的，處理邏輯問 題，業務互動，檢測的是後臺“容錯機制”是否完整； 而 ui 更多會去關注頁面展示，資料轉換，介面排序這些功能，當然也會後臺資料處理的問題，ui 測 試其實已經包含了介面測試。系統功能的用例更全面，不僅有介面的，也有業務功能用例，還有其他 使用者場景的用例功能入口用例，流程用例，而介面測試主要根據各種入參場景來設定用例。
9.6 給你一個新的介面，你怎麼去設計用例?
首先要對於每個要測的介面都要先搞清楚這個介面的功能，它的作用是什麼，熟悉這個業務功能需要 用到什麼協議，請求方式是什麼，介面有哪些引數。對於每個引數的作用都要搞清楚，像數的型別， 是否有約束限制，是否為必填的，長度，其他的限制等等，如果兩個引數之間有關聯我們還要考慮參 數的組合場景，對於引數不理解的，一般都會跟開發溝通下，然後考慮返回資料的型別，返回資料中 的返回碼和返回資訊是什麼，透過以上幾個點去提煉測試點，設計用例。 引數約束——長度、必選項、格式、資料型別 業務場最——正確的業務場景;錯誤的業務場景；異常場景：伺服器空間不足 組合場景——相互依賴：手機和驗證碼、使用者名稱和驗證碼； 相互排斥：二選一當然還有邊界值等價類等等 Jmeter 測試流程，步驟如下： 建立 jmeter 執行緒組一新增 HPPT 請求-輸入協議-域-埠-路徑-編碼-請求方式-請求引數-啟動 Jmeter 測試流程： 先需求，再根據需求寫測試點轉換成測試用例，根據測試用例編寫測試指令碼；執行測試指令碼； 提交 BUG，跟蹤 BUG
9.7 介面文件主要包含哪些內容?
介面文件一般兩種形式的，要不就是 word 版本的要不就是 htm 的形式，具體內容 1．URL(介面地址) 2．介面功能 3．請求方式：post 4．請求引數，以及介面中每個引數的詳細說明，型別，是否為必填，約束條件等等 5．響應資料及格式，返回碼，返回碼解釋等等
9.8 你們什麼時候測試介面
一般有需求就會做，後臺的介面開發好，就可以開始測。例外，如果增加了新需求，也要做介面測試， 還有就是開發對後臺的介面做了修改，互動邏輯發生變化，我們也要重新對介面進行測試。
9.9 你怎麼去檢查，分析
我們主要是根據入參情況，去看介面的返回值，對於返回值，我主要關注的幾個點：1.狀態碼 2.提示資訊 3.返回資料的具體內容。根據介面文件的說明去檢查這個 3 個點是否滿足介面需求文件， 4.有些如果要檢查資料庫的，就連線資料庫獲取資料與返回的資料做對比。 如果不滿足就是有問題，如果滿足則透過，如果有 Bug 我們會先大概分析下，是什麼原因， 並進行復測，如果還是有問題，提交 Bug 給開發，讓開發修復，之後再回歸測試
9.10 什麼是 api 介面測試
介面測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的互動點測試的重點， 是要檢查資料的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關係等
9.11 什麼情況下開展介面測試?
1、專案處於開發階段 2、有介面需求文件，開發已完成聯調，功能測試展開之前 3、專項測試：引數約束測試，業務場景測試，測試介面請求響應時間（效能） 4、版本上線前，進行整體迴歸測試，檢視介面是否有異常(如 404 等)
9.12 依賴於第三方的介面如何測試
1，需要第三方介面的，介面文件 2，傳送請求到第三方介面，檢查第三方介面返回的資料是否正確 3，不正確的時候，要跟第三方介面聯調，看是請求問題，還是第三方介面返回資料有誤， 這個我們公司的第三方介面，我們都是打通的，比如電商，我們透過呼叫微信介面等等，都是打通的， 比如要測試下單第三支付，我們自己開店，收款設定我們自己的賬號，然後透過商品設計 1 分錢，去 測試的。 如果不打通的話，基本也只能抓包，主要保證我們傳送出去的資料符合需求文件就行，然後真正的上 線之前，我們會在預生產環境做一個聯調測試，把各自系統連在一起，做一個聯調測試沒有問題了 我們就可以上線，基本就這麼做的 聯調測試怎麼做的： 其實聯調測試就是資料拉通測試，兩個子系統，連在一起，形成一個完整的系統，然後從上游下資料，下游接到資料看傳過來的資料是否符合下游的系統要求然後下游做了操作，把資料返回給上游，通知 上游說資料返回了，上游看返回的資料是否符合要求，如果沒有問題，就這個資料就拉通成功這個都 是按照用例來執行，上游和下游一起出一份用例，兩邊都評審透過，然後按照測試用例執行，每條用 例測試透過那麼聯調測就完成了。
9.13 你們介面怎麼鑑權的?
(1)透過使用者和密碼，auth 鑑權 (2)透過 cookie 和 session (3)透過 token (4)透過 sign 簽名 現在 app 一般是透過 token 鑑權，有些是透過把 token 放在請求頭裡面，有些是透過 singn 簽名這 個欄位放在 body 裡面去鑑權的，一般的 web 是透過 session 去鑑權的
9.14 介面傳輸格式有哪些
常見的媒體格式型別如下： text/html：HTML 格式 text/plain：純文字格式 text/xm：XML 格式 Image/gif：gif 圖片格式 mage/jpeg：jpg 圖片格式 Image/ng：png 圖片格式 以 application 開頭的媒體格式型別 application/xhtm + xml： XHTML 格式 application/ml：XML 資料格式 application/atom + xml： Atom XML 聚合格式 application/json：JsoN 資料格式 application/pdf：pdf 格式 application/msword：Word 文件格式 application/octet-stream：二進位制流資料(如常見的檔案下載) application/x-www-form-urlencoded：encoded：
中預設的 encType,form 表單資料被編碼為 key/value 格式傳送到伺服器(表單預設的提交資料的格式) 另外一種常見的媒體格式是上傳檔案之時使用的： multipart/form-data：需要在表單中進行檔案上傳時，就需要使用該格式
9.15 cookie、session、token 的區別
它們都是用來做鑑權的，區別的話，大概是這樣的 1、現在 cookie、session 一般是配合使用的使用者第一次登陸時，伺服器會建立一個 session 生成一個 sessionID，sessionID 儲存在 cookie 中，然後返回到客戶端，儲存在瀏覽器中。 客戶端每次發請求都會把這個值帶到伺服器，做一個鑑權和會話的跟蹤，或者時效的驗證 2、token 和 cookie、session 差不多，透過演算法，每次驗陸，會產生一串很長的隨機字串，一般 是在放在返回的 body 裡面，或者返回的頭裡面，他們都是伺服器產生，帶過來是要做驗證和時效的 驗證的。一般在 app 中使用 token 比較多一點，Web 端使用 cookie、session 的鑑權方式會多一點。
9.16 介面測試的工具有哪些?
Fiddler 抓包工具，也可以做介面測試 Postman 介面測試工具，支援介面自動化測試 wireshark 支援電腦上各種協議的抓包工具，主要常見有 http 和 tcp 抓包 Soapui 功能強大的介面測試工具，效能測試，介面自動化測試 java+httpclient.jar java 程式碼實現介面自動化測試，一般需要藉助單元測試框架 junit 和 TestNG 介面自動化測試框架設計：java+httpclient+TestNG Python + requests python 程式碼實現介面與介面自動化測試，測試框架： unittest，pytest， 介面測試框架設計： python+ requests+ unittest+ htmlTestRunner 或者 python +requests+ pytest Loadrunner 介面自動化測試，介面效能測試(主要) jmeter 介面測試，介面自動化測試，介面效能測試(主要) Swagger 編寫線上介面文件，線上介面測試
行動吧，在路上總比一直觀望的要好，未來的你肯定會感 謝現在拼搏的自己！如果想學習提升找不到資料，沒人答疑解惑時，請及時加入扣群：731789136，裡面有各種軟體測試+開發資料和技術可以一起交流學習哦。
最後感謝每一個認真閱讀我文章的人，禮尚往來總是要有的，這些資料，對於【軟體測試】的朋友來說應該是最全面最完整的備戰倉庫，雖然不是什麼很值錢的東西，如果你用得到的話可以直接拿走：
