軟件測試（英語：Software Testing），描述一種用來促進鑒定軟件的正確性、完整性、安全性和質(zhì)量的過程。換句話說，軟件測試是一種實際輸出與預期輸出之間的審核或者比較的過程。

通俗的來講，“軟件測試”就是通過軟件測試人員驗證軟件是否滿足用戶的需求。最終交付的產(chǎn)品是否和用戶本來的需求一致，如果不一致，需要找出不一樣的點提交給開發(fā)員進行修復改善，測試人員在測試過程中找出的問題統(tǒng)稱為“Bug”。

軟件測試的經(jīng)典定義是：在規(guī)定的條件下對程序進行操作，以發(fā)現(xiàn)程序錯誤，衡量軟件質(zhì)量，并對其是否能滿足設計要求進行評估的過程。

2、什么是Bug（軟件錯誤）？

所謂“（Bug）”，是指電腦系統(tǒng)的硬件、系統(tǒng)軟件（如操作系統(tǒng)）或應用軟件（如文字處理軟件）出錯。硬件的出錯有兩個原因，一是設計錯誤，一是硬件部件老化失效等。

軟件的Bug：狹義概念是指軟件程序的漏洞或缺陷，廣義概念除此之外還包括測試工程師或用戶所發(fā)現(xiàn)和提出的軟件可改進的細節(jié)、或與需求文檔存在差異的功能實現(xiàn)等。僅就狹義概念而言，軟件出現(xiàn)Bug的原因有：

• 對各種流程分支考慮不全面；對邊界情況的處理不到位；編碼時的手誤。

任何軟件在發(fā)布時都不可能是絕對的零Bug。在軟件過程管理中通行的CMM（能力成熟度模型）中規(guī)定的軟件質(zhì)量標準是（Bug個數(shù)/千行源碼）：

• CMM1級 11.95、CMM2級 5.52、CMM3級 2.39、CMM4級 0.92、CMM5級 0.32

當且僅當，程序規(guī)格說明書(軟件需求)存在并且合理，如果軟件功能和軟件規(guī)格說明書不相符合，我們就說是軟件錯誤。當軟件需求不存在，用戶需求存在并且合理，軟件功能和用戶功能不相符合，就說明是軟件錯誤；軟件測試的階段：整個軟件開發(fā)的生命周期，需求階段介入 驗證需求的合理性和正確性。

3、軟件測試與軟件開發(fā)的區(qū)別？

①技能要求專業(yè)度：

軟件研發(fā)：技能的要求專業(yè)度高,技能要求不廣泛,需要極強的代碼基礎

• 編程語言：Java、C、JavaScript、C++、Go、R、HTML 以及 C# 和 SQL

軟件測試：技能要求比較廣泛，但是專業(yè)度不高,無硬性代碼基礎

• 接口測試：soupUl, postman , jmeter
• 性能測試：loadrunner jmeter
• 自動化測試腳本：Python java unittest TestNg Charles fiddler appium

②軟件測試和軟件調(diào)試

目的：軟件測試就是驗證軟件是否實現(xiàn)了它應該實現(xiàn)的功能(需求)軟件調(diào)試的目的是軟件開發(fā)人員驗證軟件是否實現(xiàn)了“開發(fā)”想讓軟件實現(xiàn)的功能。

角色：測試是由開發(fā)人員(白盒測試)和測試人員共同完成，調(diào)試是由開發(fā)人員完成。

階段：測試現(xiàn)在貫穿了整個軟件開發(fā)的生命周期：

• 需求一>計劃一> 設計一>編碼一>測試一>運維調(diào)試是在開發(fā)階段

4、開發(fā)與測試中的需求是什么？

用戶的期望和滿足合同（文檔，規(guī)則，標準）的規(guī)定所需要的條件和權限。軟件需求是用戶需求轉換而來的，它是用戶需求的細化，是用戶需求的具體實現(xiàn)細節(jié)和規(guī)范。

用戶需求比較粗略，直接實現(xiàn)會有困難，因為沒有細節(jié)，所以需要軟件需求把用戶需求細節(jié)實現(xiàn)和規(guī)范，把用戶需求變成一個具體的可實現(xiàn)的過程文檔。

5、需求是軟件測試的依據(jù)

驗證需求，保證需求正確可實現(xiàn)，細化需求，從需求中提煉出一個一個的測試項。以用戶登陸為例，闡述下整個過程：

軟件測試人員如何深入了解需求? 答:從用戶需求分析階段就開始介入了解需求，站在用戶的角度。

6、如何編寫完整的測試用例

測試用例就是向被測試系統(tǒng)發(fā)起的一組集合，包含測試環(huán)境，測試數(shù)據(jù)，測試步驟，預期結果，（重要性、優(yōu)先級、操作方式、標題等）

如圖：測試點：用正確（已經(jīng)注冊）的賬號和密碼登陸知乎界面，登陸成功

測試用例：所測試的項目標題

測試環(huán)境：Chrome版本99.0.4844.51 PC端 Windows系統(tǒng)

測試數(shù)據(jù)：用戶名：QingshengRuanjianCeshi 密碼: *******

測試步驟：

• 1.在瀏覽器打開知乎URL：https://www.zhihu.com/signin?next=%2F
• 2.輸入用戶名和密碼
• 3.點擊登陸

預期結果：(操作完測試步驟后的結果)登陸成功

測試用例告訴我們測什么，怎么測，該測哪些

優(yōu)點：衡量需求的覆蓋率(測試用例和需求對比)：復用性，借鑒意義; 可以用于回歸測試; 防止遺漏測試需求。

7、軟件開發(fā)的常見5個模型

軟件開發(fā)的生命周期 ： 需求分析一計劃一 設計一 開發(fā)一 測試一 運行維護

（1）瀑布模型

瀑布模型在軟件測試工程中占有重要地位，是所有其他模型的基礎框架。瀑布模型的每一個階段都只執(zhí)行一次，因此是線性順序的軟件開發(fā)模式。

特點：階段性強（強調(diào)開發(fā)的階段性、強調(diào)早期計劃及需求調(diào)查、強調(diào)產(chǎn)品測試），每一個階段比較獨立; 看重前期的需求分析和后期的測試

缺點：易串行有去無回，測試介入晚，導致項目前期的問題到后面才發(fā)現(xiàn)，失去了錯誤及時修正的機會、不支持項目頻繁變動

（2）螺旋模型

適合于項目龐大，風險大，不是很明確項目，一個項目分多層小迭代。

特點：強調(diào)每一個迭代的測試質(zhì)量和風險分析。適合風險比較大并且整個項目也比較龐大，每一個迭代做風險分析，討論項目是否有價值繼續(xù)。

缺點：風險管控人力物力投入很多，風險分析要求很高，需要投入專業(yè)人員，導致時間，項目支出成本費用比較高。風險對比對測試人員和開發(fā)人員要求比較高。

（3、4）迭代、增量模型

前置：4周時間開發(fā) 系統(tǒng)的A模塊，B模塊，C模塊，D模塊的功能

增量：

• 第一周完成A模塊；
• 第二周完成B模塊：
• 三周完成C模塊：
• 第四周完成D模塊：

迭代：

• 第一周完成A B C D四個模塊的基礎框架部分，
• 第二周完成基礎功能的開發(fā)和測試，
• 第三周進一步開發(fā)復雜的功能，
• 第四周完善細節(jié)；

特點是抗擊風險能力強

（5）敏捷模型（常用）

注重和客戶的溝通，整個研發(fā)團隊有效溝通，注重產(chǎn)品的質(zhì)量，注重產(chǎn)品規(guī)定的交付日期；（擁抱變化，客戶可以在項目開發(fā)過程中改變需求）

敏捷開發(fā)周期很短（1~4周時間），團隊研發(fā)人員少；

特點：重目標、重產(chǎn)出、輕文檔、輕流程；

舉例說明：Scrum流程：

角色解析：

• PO（product Owner）產(chǎn)品經(jīng)理：負責整理用戶需求，形成userstory；
• SM（scurm Master）項目經(jīng)理：負責保證整個敏捷開發(fā)流程的順利實施，開發(fā)和各種協(xié)調(diào)等；
• ST（scrum team）研發(fā)團隊：負責整個項目的研發(fā)，各種技能的人組成，測試、開發(fā)、UI設計等；
• 發(fā)布計劃會：產(chǎn)品經(jīng)理需求整理成userstory，形成product backlog，會議上討論userstory的重要性排版，決定本期迭代要開發(fā)的userstory；
• 迭代計劃會議：研發(fā)團隊確認迭代任務，分解userstory，將userstory分解成為一個個的任務，確定任務完成的時間，具體的人員等；
• 每日站會：（重點在于總結和解決出現(xiàn)的問題，以及了解整個研發(fā)的進展）解決三個問題：昨天完成了什么？解決了什么問題？今天的計劃；
• 產(chǎn)品展示會議：給客戶和Boss演示產(chǎn)品研發(fā)的成果，PO整理后形成新的userstory，放到下一次的迭代中；
• 項目總結：總結這個迭代的優(yōu)缺點，不足的改進，優(yōu)化這個敏捷開發(fā)流程；

8、軟件測試人常用的測試模型

軟件測試V模型：

特點： 每一個階段獨立性強；左邊每一個階段都是右邊測試階段的依據(jù)；和右邊階段每一個測試階段一一對應。

缺點：編碼后才進行測試；串行的過程，測試是在編碼后有的，測試的介入比較晚導致前期的錯誤后期才發(fā)現(xiàn)，后期測試發(fā)現(xiàn)時，已經(jīng)失去了錯誤及時糾正的最好時機。

軟件測試W模型：又稱雙V模型

特點： 每一階段獨立性強；測試一開始就介入；可以保證前期的問題及時發(fā)現(xiàn)和糾正；測試和開發(fā)并行。

缺點：每一階段都是串行的過程；一個階段完了之后就進行下一個階段。不適合需求頻繁變更的項目，不支持敏捷(擁抱變化)開發(fā)。

9、軟件測試的生命周期（軟件測試流程）

需求分析——測試計劃——測試設計/開發(fā)——測試執(zhí)行——測試報告

• 去求分析：分析需求，驗證需求的正確性、合理性；細化需求，根據(jù)需求去提煉測試點
• 測試計劃：確定測試范圍、目的、目標、測試人員、測試工具、時間、測試環(huán)境
• 測試設計/開發(fā)：開發(fā)測試用例
• 測試執(zhí)行：開發(fā)人員已經(jīng)提交了代碼，執(zhí)行測試，提交BUG
• 測試報告：
• 對本次迭代的測試情況進行分析和總結；
• 寫了多少測試用例執(zhí)行了多少；
• 發(fā)現(xiàn)了多少BUG，修改了多少，剩余多少BUG沒有解決；
• 方案；測試的覆蓋率；上線風險評估

10、如何正確的描述一個BUG

舉例場景：注冊功能，密碼長度是8~18個字符，但輸入1個字符時，也能注冊成功

標題：注冊時密碼輸入1位字符，提示注冊成功

測試版本（代碼提交版本號）：代碼版本號Qs1001

測試環(huán)境：Chrome瀏覽器 版本號96.0.4664.45（因為在不同測試環(huán)境問題出現(xiàn)的情況也不一樣）

操作系統(tǒng)：Windows10，電腦品牌型號聯(lián)想xx型號

測試數(shù)據(jù)：賬號；qingshengceshi666@163.com、密碼；1

測試步驟：測試數(shù)據(jù)和執(zhí)行測試的詳細步驟，方便為開發(fā)人員復現(xiàn)問題

（打開注冊頁面?輸入郵箱賬戶?填寫密碼?點擊同意條款?點擊注冊）

實際結果：注冊成功

預期結果（需求期望的結果）：注冊成功注冊失敗，提示“密碼長度不符合規(guī)則”BUG的級別，附件（截圖，錯誤日志）BUG產(chǎn)生時的log日志，錯誤截圖等附件：

描述BUG 的要素：測試環(huán)境，測試數(shù)據(jù)，測試步驟，預期結果，實際結果，附件（錯誤，錯誤日志），等級，標題

11、Bug的級別的劃分與解析

• 致命錯誤：系統(tǒng)崩潰，不能運行，死循環(huán)，數(shù)據(jù)庫死鎖，資源分配不均，黑屏，閃退，阻塞。線上（用戶使用的環(huán)境）出現(xiàn)崩潰級別的BUG：回到上一個可穩(wěn)定運行的歷史版本即可

• 嚴重錯誤：服務器可以用，但是不穩(wěn)定，繼續(xù)使用會產(chǎn)生嚴重的錯誤；一級菜單錯誤，數(shù)據(jù)庫插入數(shù)據(jù)錯誤，威脅到用戶的安全等
• 一般錯誤：系統(tǒng)可以穩(wěn)定的運行，次要的功能沒有實現(xiàn)，提示語不完整，彈出框沒有關閉按鈕，不影響用戶的使用
• 次要（建議）：建議性的，提示信息重疊（看不清楚），界面排版不符合用戶使用習慣，顏色不符合軟件使用場景

12、Bug的生命周期（附管理流程）

提問：當測試員發(fā)現(xiàn)一個Bug提交給開發(fā)員后修改，開發(fā)員通知測試員驗證，但是測試員又復現(xiàn)了這個Bug，是哪些可能的原因引起的？

回答：測試環(huán)境不一樣；開發(fā)人員理解不到位，沒有修改成功；代碼在開發(fā)人員修改之后未進行遠程提交代碼，測試人員用舊版本（有問題的代碼）進行測試

13、測試員因為一個Bug和開發(fā)人員發(fā)生爭執(zhí)時該怎么處理？

• 檢查自己的BUG描述，是否描述清楚
• 可以從用戶的角度考慮，說服開發(fā)人員
• BUG定級要有理有據(jù)，符合公司規(guī)范
• 測試人員要不斷提升自己的專業(yè)技能和業(yè)務水平（權威性）
• 找產(chǎn)品經(jīng)理去討論問題的解決方案

14、面試最喜歡問的問題：為什么選擇軟件測試這個崗位？

答：一名優(yōu)秀的軟件測試人員應具備良好的溝通能力，編程能力，學習能力，自動化開發(fā)能力，編寫測試用例的能力。首先對于軟件測試，我非常感興趣，我認為做一個十分優(yōu)秀的測試人員也是非常不容易的；我學了點關于開發(fā)的技能， 能在以后作為一個專業(yè)的測試人員與開發(fā)人員溝通過程中會更容易點。其次現(xiàn)在一個軟件產(chǎn)品的問世，也離不開軟件測試，在平常的工作學習生涯中，我具有強烈的責任感和壓力并且善于發(fā)現(xiàn)探索新事物，對日后的職業(yè)生涯肯定會有很大的促進作用。