軟體測試理論基礎、質量保證常見面試題

• 全面掌握軟體測試理論基礎、文件編寫，測試流程
• • 1.測試分為哪幾個階段?
  • 2.談談你之前測試的專案流程，在每個階段的輸出有哪些?
  • 3.談談敏捷模式的認識?
  • 4.linux常見檢視日誌命令有哪些?
  • 5.線上質量BUG頻頻爆發怎麼辦?
  • 6.如何分析一個bug是前端還是後端的問題?

全面掌握軟體測試理論基礎、文件編寫，測試流程

大家好，我是一凡，很高興認識你！終於開通了全中國最大的程式設計師交流社群——CSDN的部落格。往後會給大家帶來更多的學習資源以及最新資訊，歡迎關注我的微信公眾號：程式設計師一凡

軟體測試技術交流群：1079636098軟體測試需要的安裝包免費獲取，最新一線大廠面試題免費領取。

不管你現在做軟體測試，在什麼級別。

軟體測試理論基礎和軟體質量保證問題，面試的時候絕對是離不開的。

軟體測試這一個行業離開了業務就失去了靈魂。

一切的自動化、一切的程式設計、一些軟體測試工具，都是輔助測試為主。

我們最終的目的是保證我們產品的質量。

所以不管什麼樣級別的軟體測試工程師，你得全面掌握軟體測試理論基礎、文件的編寫、測試流程。

如果說我是面試官，你現在來面試。

那我第一個肯定不會問你那些程式碼的問題，也不會問你自動化的問題，也不會問你測試開發的問題。

我首先看你做了幾年軟體測試，有沒有屬於自己的一些軟體測試思維，有沒有自己的心得。

比如說像軟體測試分為哪幾個階段？然後你之前測試過的專案流程，在每一個階段的輸出有哪些？是怎麼樣去執行的，你在軟體測試過程中充當的角色。

這一類軟體測試面試題，根據你的回答，就能知道你有沒有工作經驗。你對軟體測試的認知，你對自己崗位的職責，對自己的定位是否準確。

都是一些比較綜合性的問題。

現在都是一個敏捷開發的模式，很多公司都是用敏捷開發，那麼你能談一談這個敏捷開發嗎？

大家不要侷限於很傳統的問題，什麼是測試計劃啊，什麼是測試用例編寫等等。

敏捷開發現在也是屬於軟體測試基礎理論的一個理念。

然後Linux常見的檢視日誌命令有哪些？這也是比較基礎的一些東西了。你至少要會檢視開發的日誌，會資料庫。

然後我問你，線上質量BUG頻頻爆發怎麼辦？你做為一個測試你該怎麼去應對？像這些都是比較綜合性的問題，都是考驗你在工作中的經驗於心得。

你做過多少專案，你在遇到這些問題你是如何處理的。

這些問題你一定要能夠很全面的表述出來。

比如說我現在是面試官，我第一個肯定不會去問你哪些程式碼的問題，也不會問你自動化、測試開發的問題。

第一個考查的肯定是你做了幾年測試，有沒有自己的測試思維？有沒有自己的一些心得。

前三個問題就能夠知道你有沒有工作經驗，你在工作中承擔一個什麼樣的角色、你的職責你的輸出在哪裡。都是一些比較綜合性的問題。

1.測試分為哪幾個階段?

軟體測試是貫穿整個軟體生命週期的，軟體測試的物件包括軟體需求、概要設計、詳細設計、軟體執行環境、可執行程式和軟體原始碼等。

軟體測試包括質量、人員、資源、技術和流程五大要素，以及測試覆蓋率和測試效率兩個目標。

那麼軟體測試究竟又分為哪幾個階段呢?本文將圍繞這個問題詳細介紹。

軟體測試和開發過程相對應， 軟體測試一般分為4個階段:單元測試、整合測試、系統測試、驗收測試。

一、單元測試

單元測試:單元測試是針對軟體設計的最小單位–程式模組甚至程式碼段進行正確性檢驗的測試工作，通常由開發人員進行。

對於單元測試中單元的含義，一般來說，要根據實際情況去判定其具體含義，如C語言中單元指一個函式，Java裡單元指一個類，圖形化的軟體中可以指一個視窗或一個選單等。

總的來說，單元測試是對軟體中的最小可驗證單元進行檢查和驗證。

測試原則:

1、儘可能保證測試用例相互獨立(測試用例中不能直接呼叫其他類的方法，而應在測試用例中重寫模擬方法);

2、此階段一般由軟體的開發人員來實施，用以檢驗所開發的程式碼功能符合自己的設計要求。

單元測試的好處:

1、儘早的發現缺陷;

2、利於重構;

3、簡化整合;

4、文件;

5、用於設計。

單元測試的不足:

1、不可能覆蓋所有的執行路徑，所以不可能保證捕捉到所有路徑的錯誤;

2、每行程式碼需要3~5行程式碼進行單元測試，存在投入與產出的平衡。

二、整合測試

整合測試是在單元測試的基礎上，把軟體單元按照軟體概要設計規格說明的規格要求，組裝成模組、子系統或系統的過程中各部分工作是否達到或實現相應技術指標及要求。

整合測試包括BigBang、自頂向下、自底向上、核心系統整合、高頻整合。

三、系統測試

系統測試:系統測試是在整合測試通過後進行的，目的是充分執行系統，驗證各子系統是否都能正常工作並完成設計的要求。它主要由測試部門進行，是測試部門最大最重要的一個測試，對產品的質量有重大的影響。

整合測試和系統測試之間的比較:

1、測試內容:整合測試是測試各個單元模組之間的介面，系統測試是測試整個系統的功能和效能;

2、測試角度:整合測試偏重於技術的角度進行測試，系統測試是偏重於業務的角度進行測試。

四、驗收測試

驗收測試也稱交付測試，以需求階段的《需求規格說明書》為驗收標準，測試時要求模擬實際使用者的執行環境。是針對使用者需求、業務流程進行的正式的測試，以確定系統是否滿足驗收標準，由使用者、客戶或其他授權機構決定是否接受系統。

驗收測試包括alpha測試和beta測試，alpha測試是由開發者進行的軟體測試，beta測試是由使用者在脫離開發環境下進行的軟體測試。

2.談談你之前測試的專案流程，在每個階段的輸出有哪些?

比如說敏捷開發每週他有新的需求來了，新功能推出來之後，是不是第一個專案流程需求分析會。

需求分析：（開發、產品、測試）探討需求功能點，資料庫表的設計，介面設計。現在大都是前後端分離的這樣一個專案對吧，你要從這些面去回覆，比較全面。

然後輸出的一個需求文件，包括已介面的、功能的。你不要只答到一個需求分析。

開完這個會之後，我們就按照這個需求分析去編寫測試用例。在編寫測試用例之前，你的主管會去編寫測試計劃（如果你是主管你就說我編寫測試計劃）然後任務分配。

用例的設計，整理測試要點，用例評審。

比如開發人員說他要開發幾個介面，那麼你的用例裡面，測試要點都要給開發人員進行評審。

用例評審完之後，就要整理形成最終的一個用例版本。

然後開發人員去開發程式碼，進行一個預測，開發進行一個自測，對主要一個功能進行冒煙測試，然後給我們提測。

測試過程中，Bug的提交，比如我們用的Jira，用什麼管理系統去提交的bug。

Bug的生命週期，怎麼去重新提交。這就是一個測試缺陷報告。

然後在什麼時候進行上線，產品釋出後再會有一個線上維護性的迴歸測試等等。

像這些內容，你按照這個思路去和麵試官交流。那麼你這個流程也是非常規範的！

所以大家在面試時候不要簡單的說，需求分析、編寫用例。這樣規範起來，就體現了你在網際網路公司對自己角色的定位很清晰，對工作內容也很明確。

不要小看這個問題。

3.談談敏捷模式的認識?

參考閱讀——敏捷軟體測試常見的七個誤區

4.linux常見檢視日誌命令有哪些?

• 全文檢視

  分頁檢視

  部分檢視

檔案檢視命令–cat

1．檢視檔案所有內容cat

cat是cancatenate的簡寫，用於將一個檔案的內容連續輸出到螢幕上。

語法: cat[-選項][目標檔案] 檢視檔案內容

引數: -n為檔案內容新增上行號

命令: cat -n /etc/passwd 檢視passwd時，給文件新增上行號

引數: -b為檔案內容新增上行號,但空行不算

命令: cat -b/etc/inittab 檢視inittab時，給文件新增上行號,空行不會新增行號

檔案檢視命令–more

2．分頁檢視檔案內容more

語法: more[目標檔案] 分頁檢視，按空格鍵往下翻

檔案檢視命令–less

3．分頁檢視檔案內容less

語法: less[檔名] 分頁檢視，按b往上翻，按空格往下翻，按q退出

總結：

全文檢視:cat

分頁檢視:more less

部分檢視: head tail

檔案檢視命令–head
4.檢視部分檔案內容 head

語法: head[-選項][檔名]

命令: head /etc/passwd 預設檢視檔案開頭的前10行

檔案檢視命令–tail

5.檢視部分檔案內容tail

語法: tail[-選項][檔名]

命令: tail /etc/passwd預設檢視檔案末尾的10行

……

5.線上質量BUG頻頻爆發怎麼辦?

真的勇士， 敢於直面慘淡的 warning 、 敢於正視淋漓的 error !

有人喜歡創造世界，他們做了開發者；有的人喜歡開發者，他們做了測試員。
什麼是軟體測試？軟體測試就是一場本該在使用者面前發生的災難提前在自己面前發生了，這會讓他們生出一種救世主的感覺，拯救了使用者，也就拯救者這個軟體，避免了他們被解除安裝的命運。

願你我相遇皆有所獲！

如果你覺得此文對你有幫助，如果你對軟體測試、介面測試、自動化測試、面試經驗交流感興趣歡迎加入：

軟體測試技術群：1079636098，

群裡發放的免費資料都是筆者十多年測試生涯的精華，還有同行大神一起交流技術。
作者：來自公眾號：程式設計師一凡

原創不易，歡迎轉載，但未經作者同意請保留此段宣告，並在文章頁面明顯位置給出原文連結。

6.如何分析一個bug是前端還是後端的問題?

像這個問題，這是一個軟體測試工程師初、中級會問你的面試題。

像最前面圖上的問題，你一定要能夠全面的詮釋。大家一般能答出多少個？歡迎在評論區留言探討。

在回答這一類問題的時候，我們要根據自己的工作經驗，去總結。

回答的時候不能簡單的說“是否對錯”，我們要根據面試官問的問題去擴充套件，我們就拿第6個問題來說吧！

然後你如何分析一個Bug是前端還是後端的問題？

這個就看大家做軟體測試的心得了，像這類問題，你去百度去網上也不好找。歡迎在評論區談一下大家自己的經驗。（抓包？看介面返回？）

通過一些介面請求資訊，抓介面請求資訊。（通過瀏覽器的一些開發者工具）

就是說檢查介面，檢查介面首先你得了解BUG它用到了哪些介面，然後檢查請求的資料，傳送的資料是否正確，後臺反饋的資料是什麼？

如果前端沒有請求介面，或者請求的時候引數與需求不符，那麼肯定就是前端的問題。

劃重點：請求引數，返回的響應值

那麼我們可以來看一個簡單的案例。

我這裡有一個平臺，是前後端分離的，只有前後端分離的系統才會出現這個問題。

假設這個是我們被測的系統，我們在系統管理-使用者管理這裡是不是有很多使用者，這個是最簡單的使用者管理系統了。就是有哪些人，有admin有知一，有木子，有當當等等很多。

我們先來刪除其中任意一個，頁面沒有任何的反應。

我第二次再去刪除同一個，它就報Userld不存在了對吧？

那麼如果是這種情況，是前端的問題還是後端的問題？一看就是前端的問題對吧。

判斷這個問題，是不是前端的問題，我們就開啟netkwork

我們來新增一個使用者，它就會呼叫一個add介面，顯示使用者新增成功。

當我新增一個使用者的時候，bug可能會偶爾重現。所以大家在看介面請求的時候，你要看它本來你去刪除的時候它只調用了一個介面，那麼它不僅要刪除這個人，它其實還要去重新整理這個頁面，它需要重新去呼叫這個使用者介面的介面。這個時候你就需要知道當它做這個刪除功能的時候需要呼叫幾個介面。

可能有些介面，開發人員沒有去呼叫，那麼就是前端的問題，這個時候需要我們主動重新整理一下，主動重新整理的時候，整個頁面它會重新整個去獲取一遍。這個時候刪除在頁面上才會生效。所以說這是前端少呼叫了一個介面。

這就是前端的一個問題。

用了一個介面。

以後去回答這個面試題，你就可以完美的去回答了，如果還是沒有完全理解可以公眾號程式設計師一凡獲取視訊精講教程。

## 相信夢想會如期而至。

迷失的時候，選擇更艱辛的那條路。

當你內心有目標和夢想的時候，別害怕，勇敢的嘗試一次吧，放棄很輕鬆，要磨滅內心的熱情也很容易，但是堅持下，也許就能看到不一樣的自己，人生是一次不會返程的路途，給自己一次機會有何不可。

每一個成功的人，在前進的路上都會收到很多的鼓勵，也會願意鼓勵他人，我深深感受到鼓勵帶給我的幫助，你們的每一次點贊，就是對我最大的支援，讓我一直堅持的做出更好的內容。

願你我相遇，皆有所獲！ 歡迎關注微信公眾號：程式設計師一凡

1.免費領取一份216頁軟體測試工程師面試寶典文件資料。

2.軟體測試學習路線以及相對應的視訊學習教程免費分享！