一、測試理論
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 開發人員在上線規定時間之前都還沒有修復好的話，就看問題的嚴重性， 如果嚴重就延期上線，如果我們是迭代版本的話我們還需要版本回滾。 如果不嚴重，產品跟客戶覺得可以上線，就正常上線。
二、抓包與網路協議
8.1 抓包工具怎麼用
我原來的公司對於抓包這塊，在 App 的測試用得比較多。我們會使用 fiddler 抓取資料檢查結果，定 位問題，測試安全，製造弱網環境; 如：抓取資料透過檢視請求資料，請求行，請求報頭，請求正文，資訊是否正確去檢查結果, 如果是以 4 開頭的話就有可能是前端問題一般我會到前端排查，以 5 開頭就有可能是後端 問題我就會到後端排查;如果是 200 的話，就需要檢查請求行，請求報頭，請求正文是否正確， 如果請求錯誤就是前端問題，如果請求沒有問題，那就是後端問題，看後端問題伺服器執行日誌， 是否包含 exception，error 或根據時間點去看日誌。 測試安全，抓取資料檢視使用者的感敏資訊有沒有進行加密顯示，還有就是把傳送請求的資料篡改是否 成功。 弱網環境，誦過 fiddler 工具選擇 Customize Ruels...(Ctr+R)調出定義指令碼編輯器找到 “if (m_SimulateModem)”設定上行下行網速，然後把 Rules-> Performance-> Simulate Modem Speeds 選中生效 常用抓包工具有：瀏覽器中 F12， fiddler， Charles(青花瓷)， wireshark
8.2 如何抓取 https 的包
1、設定 Tools=> Option=>勾選 Decrypt Https traffic=>勾選 lgnore server certificate errors(unsafe) 2、開啟 https 網頁就可以成功抓取了 3、還可以 Fiddler 新增過濾器(Filters)：只抓取指定 iP 的資料
8.3 如何抓取手機的包
1、開啟 Fiddler 的遠端連線 Fiddler 主選單 Toos- Options-> Connections>勾選 Allow remote computers to 2、重啟 Fiddler，更新剛開啟的遠端配置 3、然後手機和電腦需要在同一個區域網，抓取 http 手機設定代理就可以，要抓取 https 包，手機需 要安裝一個 fiddler 證書 1、fder 工具生成一個證書，傳送手機上面安裝 2、透過手機瀏覽器開啟安裝證書介面 192.168.3.197：8888 ip 地址是用 fiddler 工具的電腦的 ip 地址，fiddler 工具埠號的 8888 3、點選下載證書，會提示，輸入手機鎖屏密碼 4、給證書命名，名字隨意，其他預設就 ok 5、點選確定，安裝成功，然後就可以抓取 https 的包了
8.4 網路協議瞭解多少?
原來我們用得比較多的協議是 http 和 https 以及 tcp 協議 http 和 https 都是超文字協議，瀏覽器傳送資料請求基本用的都是他們，不同的是 https 在 http 的基礎上增加了 ssl 加密協議,http 的預設埠是 80，http：的預設埠是 443， https 收費，http 免費。 tcp 協議的話，作用在傳輸層，在傳送請求前會有三次握手，是面向連線的協議，傳輸過程比較可靠 udp 協議的話，作用在傳輸層，面向非連線協議，傳輸過程相對 tcp 不可靠，傳輸大量資料
8.5 請求方式有哪些?
常用：get、post 不常用：delete、put、head、option
8.6 get 跟 post 請求的區別
1)get 請求的引數有長度限制，post 沒有 2)get 請求引數在 url 上傳輸，post 的引數在請求正文中傳輸。post 比 get 傳輸更安全 3)get 只能接收 ascall 碼引數，而 post 沒有限制 4)get 請求的時候，只請求一次，而 post 請求兩次，第一傳送請求頭相關資訊，第二次 再傳送請求正文，(只有部分瀏覽器 2 次請求)
8.7 http 跟 https 的區別
1.https 協議需要到 ca 申請證書，一般免費證書較少，因而需要一定費用 2.http 是超文字傳輸協議，資訊是明文傳輸 https 則是具有安全性的 ssl 加密傳輸協議 3.http 和 https 使用的是完全不同的連線方式，用的埠也不一樣，前者是 80，後者是 443 4.http 的連線很簡單，是無狀態的;Https 協議是由 SSL + HTTP 協議構建的可進行加密傳輸、身份認 證的網路協議，比 http 協議安全。
8.8 為什麼要使用 cookie 和 session：http 是無狀態協議
第一次登入，傳送使用者資訊給到伺服器，伺服器把使用者資訊儲存在 session 中伺服器響應資料給客戶 端，響應資料中有包含 session 的先關使用者資訊 客戶端接收到伺服器 session 資訊，把 session 中相關的使用者資訊儲存在 cookie 中 第二次登入，客戶端傳送請求，並攜帶 cookie，服務端可以直接驗證 cookie 值，如果使用者已經登入 過，可以免登入
8.9 cookie 跟 session 的區別
在網站中 http 請求是無狀態的，也就是說即使第一次和伺服器連線後並且登入成功後， 第二次請求伺服器依然不能知道當前請求是哪個使用者，cookie 的出現就是為了解決這個問題， 第一次登入後伺服器返回一些資料(cookie)給瀏覽器，然後瀏覽器儲存在本地，當該使用者傳送第二次 請求的時候，就會自動的把上次請求儲存的 cookie 資料自動的攜帶給伺服器，伺服器透過瀏覽器攜 帶的資料就能判斷當前使用者是哪個了。cookie 儲存的資料量有限，不同的瀏覽器有不同的儲存大小， 但一般不超過 4KB，因此使用 cookie 只能儲存一些小量的資料。 session 和 cookie 的作用有點類似，都是為了儲存使用者相關的資訊，不同的是，cookie 是儲存在本 地瀏覽器，而 session 儲存在伺服器.儲存在伺服器的資料會更加的安全，不容易被竊取。但儲存在 伺服器也有一定的弊端，就是會佔用伺服器的資源，但現在伺服器已經發展至今，一些 session 資訊 還是綽綽有餘的
8.10 post 申請方式，用 get 會報什麼錯誤。
404 Not Found 請求失敗，請求所希望得到的資源未被在伺服器上發現，沒有資訊能夠告訴使用者這個狀況到底是暫時 的還是永久的，假如伺服器知道情況的話，應當使用 410 狀態碼來告知舊資源因為某些內部的配置機 制問題，已經永久的不可用，而且沒有任何可以跳轉的地址，404 這個狀態碼被廣泛應用於當伺服器 不想揭示到底為何請求被拒絕或者沒有其他適合的響應可用的情況下，出現這個錯誤的最有可能的原 因是伺服器端沒有這個頁面。
8.11 http 協議提交請求頭內容
Accept-Charset：瀏覽器能夠顯示的字符集 Accept- Encoding：瀏覽器能夠處理的壓縮編碼 Accept-Language：瀏覽器當前設定的語言 Connection：瀏覽器與伺服器之間連線的型別 Cookie：當前頁面設定的任何 Cookie Host：發出請求的頁面所在的域 Referer：發出請求的頁面的 URL User-Agent：瀏覽器的使用者代理字串 Content-Type：請求資料的格式或者是型別
行動吧，在路上總比一直觀望的要好，未來的你肯定會感 謝現在拼搏的自己！如果想學習提升找不到資料，沒人答疑解惑時，請及時加入扣群：731789136，裡面有各種軟體測試+開發資料和技術可以一起交流學習哦。
最後感謝每一個認真閱讀我文章的人，禮尚往來總是要有的，這些資料，對於【軟體測試】的朋友來說應該是最全面最完整的備戰倉庫，雖然不是什麼很值錢的東西，如果你用得到的話可以直接拿走：
