一、測試理論
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 開發人員在上線規定時間之前都還沒有修復好的話，就看問題的嚴重性， 如果嚴重就延期上線，如果我們是迭代版本的話我們還需要版本回滾。 如果不嚴重，產品跟客戶覺得可以上線，就正常上線。
二、資料庫
7.1 你們資料庫怎麼用
[原來我們資料庫用的比較多的，就是資料結果檢查，測試一些資料準備，效能測試造大量資料。] [測試執行到的結果，我們需要透過 sql 語句 select 來查詢資料庫對應的表，看看資料庫資訊跟我 們執行的結果是否一致，比如：生成申請借款後，我們會去資料庫裡面去檢查下,資料庫中資料是否 跟申請訂單資料一致。] [我們在測試執行時需要做一些測試資料準備，我們就用 insert into 輸入資料或(者 update set 修 改資料)，我們需要到資料庫檢視有沒有相關記錄儲存，儲存的資料跟我們輸入或者修改的記錄是否 一致;比如：原來我們一個初審功能裡面有個分頁功能，測試分頁功能，需要 100 條資料，我們就通 過資料庫操作新增 100，可以用 insert into。也可以用指令碼實現，或者儲存過程] [還有在做效能測試時，模擬使用者場景時需要用到大量的資料，這時就需要我們到資料庫中製造大量 的資料出來。比如說，測試充值，需要大量使用者資料，充值表中大量資料，比如 10W 條資料，我們就 用儲存過程去造。]
7.2 儲存過程是怎麼編寫的
delimiter∥ create procedure 儲存過程名(n int) BEGIN declare i int default 0; while i <= n do Insert into 表名 values(值 1，值 2...) set i=i+1; end while; end∥ delimiter; cal 儲存過程名(資料量(n));
7.3 常見的關係型資料庫有哪些
mysql、SQL Server、Oracle、Sybase、DB2 等 MySQL 是開源免費的; SQL Server 是由微軟公司開發的關係型資料庫管理系統，一般用於 Web 上儲存資料; Oracle 資料的大量性資料的儲存的永續性;
7.4 你們用的什麼資料庫連線工具
Navicat，資料庫版本 mysql 5.6，埠預設是 3306
7.5 左連線與右連線有什麼區別
左連線：以左邊的表(employ)為主，顯示左邊表列的全部資料，如果右邊表沒有對應的資料， 則為 NULL 右連線：以右邊的表(student)為主，顯示右邊表列的全部資料，如果左邊表沒有對應的資料， 則為 NULL
7.6 索引有哪些，如何建立索引，素引的優缺點
MySQL 索引的建立對手 MySQL 的高效行是很重要的，索引可以大大提高 MySQL 的檢素速度 缺點：雖然索引大大提高了查詢速度，同時卻會降低更新表的速度，如對錶進行 INSERT、 UPDATE 和 DELETE，因為更新表時，MySQL 不僅要儲存資料，還要儲存一下索引檔案，建立索引會佔 用磁碟空間的索引檔案。 索引份分單列索引和組合索引，單列索引，即一個索引只包含單個列，一個表可以有多個單列素引， 但這不是組合素引，組合索引，即一個索引包含多個列。 主鍵索引 PRIMARY KEY，唯一索引 UNIQUE，普通素引 INDEX 組合索引 INDEX，全文索引 FULLTEXT
最後感謝每一個認真閱讀我文章的人，禮尚往來總是要有的，這些資料，對於【軟體測試】的朋友來說應該是最全面最完整的備戰倉庫，雖然不是什麼很值錢的東西，如果你用得到的話可以直接拿走：
