1 說一下你們的測試流程
沒有做過項目的直接介紹下v模型（老師上課肯定有講過），有經驗的直接從接到項目/單子後講自己如何一步步實施測試的。
例如你可以回答這樣的流程：
1.軟件開發完成以後，就會把需求規格說明書、軟件程序和軟件源代碼發過來；
2.項目經理出測試方案（要使用什麼樣的測試方法、測試策略）安排測試計劃（測試人員、資源、進度的安排，測試的範圍和完成的目標）；
3.測試人員編寫和執行測試用例；
4.提交缺陷並且進行跟蹤；
5.編寫測試報告。
2 在項目組中做過什麼樣的工作？
1、根據軟件設計需求制定測試計劃，設計測試數據和測試用例；
2、有效地執行測試用例，提交測試報告；
3、準確地定位並跟蹤問題，推動問題及時合理地解決；
4、完成對產品的集成測試與系統測試，對產品的軟件功能、性能及其它功能
3 你平時會寫測試用例嗎？
其實這是一個很經典的面試問題，留心的朋友會發現，基本上很多公司都有這樣的問題。遇到這種問題最關鍵的不要怕，說話的時候有條有理，闡述的時候面面俱到的就好了，最重要的一定要穩。
例如：給你一個杯子如何測試？
界面測試：查看杯子的外觀是否得體。（外形、圖案）、
易用性：杯子是否燙手、是否有防滑措施、是否方便飲水、是否易用手端着或手拿。
安全性：使用過程中杯口是否容易給身體造成傷害，，杯子有沒有毒和細菌。
可靠性：杯子從不同高度掉下的損壞程度。
穩定性：杯子一直盛着水，時間長了是否會漏水。
兼容性：是否可容納高溫度水、果汁、酒精、汽油等。
用戶文檔：用戶使用手冊上是否有對杯子的使用方法進行限制，是否出現使用過程中友好的提示、該注意的問題、使用環境等有詳細的描述。
4 你認爲是bug，而開發不認同時怎麼辦？
這個主要考察的是你與團隊的溝通能力，按照套路回答就好了。
1、簡單分析下需求可能對客戶的影響，通過影響和嚴重程度來說服開發來進行修改。
2、產品需求裏邊沒有明確要求的，需要先和需求人員討論一下，如果確認需要進行修改。在三方會議上進行提出。
5 如何判斷一個問題是bug？
根據軟件需求文檔裏邊的需求描述，對於需求描述裏邊沒有的就要根據自己的測試經驗了，這裏可以說說你平時的經驗，沒有經驗的就可以把老師課上教的一些方法說出來。
6 平時寫測試用例會用到的設計方法？
這個要充分準備，最好能舉出例子（非常考察課外積累和工作經驗！）
幾種常見的測試方法：錯誤推斷法、正交實驗法、因果圖法、場景分析法、判定表法，必須對這些測試方法都能說出一二，面試官很有可能根據你說的測試用例設計方法再追問你（隨便從你剛剛說過的話裏邊挑出來一個問你定義），所以一定不要說自己一知半解的東西，寧願少說。
7 有哪些不同的測試計劃活動？
確定測試的範圍和目標
定義測試的整體方法，定義進入和退出標準
決定測試什麼以及誰將測試應用程序的哪個部分
安排測試設計會話
爲不同的測試活動分配資源
確定用於測試的工具
報告測試進度
生成退出報告
8 哪些信息應包含在給開發的缺陷或錯誤報告中？
缺陷的簡要總結
完整描述缺陷，包括重現步驟
如果需要，可以截取附件
發現和提出缺陷的日期
誰報告了這個缺陷
缺陷的嚴重性和/或優先級
哪個組件是指定的缺陷
9 給你一個網站，你如何測試？
1、查找需求說明、網站設計 m 等相關文檔，分析測試需求。
2、制定測試計劃，確定測試範圍和測試策略，一般包括以下幾個部分：
功能性測試；界面測試；性能測試；數據庫測試；安全性測試；兼容性測試
3、設計測試用例：
功能性測試可以包括，但不限於以下幾個方面：
鏈接測試。鏈接是否正確跳轉，是否存在空頁面和無效頁面，是否有不正確的出錯信息返回等。提交功能的測試。
多媒體元素是否可以正確加載和顯示。多語言支持是否能夠正確顯示選擇的語言等。
界面測試可以包括但不限於一下幾個方面：
性能測試一般從以下三個方面考慮：
壓力測試； 負載測試； 強度測試
數據庫測試要具體決定是否需要開展。數據庫一般需要考慮連結性，對數據的存取操作，數據內容的驗證等方面。
安全性測試：
- SQL 注入等。
兼容性包括：瀏覽器的兼容性；操作系統的兼容性；軟件平臺的兼容性；數據庫的兼容性
10 軟件生存週期及其模型是什麼？
軟件生存週期是軟件開發全部過程、活動和任務的結構框架，是從可行性研究到需求分析、
軟件設計、編碼、測試、軟件發佈維護的過程。
在經歷需求、分析、設計、實現、部署後，軟件將被使用並進入維護階段，直到最後由於缺
少維護費用而逐漸消亡。這樣的一個過程，稱爲"生命週期模型"（Life Cycle Model）。
11 什麼是軟件測試？軟件測試的目的與原則
使用人工或自動手段，來運行或測試某個系統的過程。其目的在於檢驗它是否滿足規定的需
求或弄清預期結果與實際結果之間的差別。
軟件測試的目的：
測試是程序的執行過程，目的在於發現錯誤
一個成功的測試用例在於發現至今未發現的錯誤
一個成功的測試是發現了至今未發現的錯誤的測試
確保產品完成了它所承諾或公佈的功能，並且用戶可以訪問到的功能都有明確的書面說明。
確保產品滿足性能和效率的要求
確保產品是健壯的和適應用戶環境的
軟件測試的原則：
軟件測試應儘早執行，並貫穿於整個軟件生命週期
軟件測試應追溯需求
測試應由第三方來構造
窮舉測試是不可能的,要遵循 Good-enough 原則
必須確定預期輸出（或結果）
必須徹底檢查每個測試結果
充分注意測試中的羣集現象
缺陷的二八定理
嚴格執行測試計劃，排除測試的隨意性
注意合法合理的輸入，也要注意非法的非預期的輸入
檢查程序是否做了不該做的
測試應從“小規模”開始，逐步轉向“大規模”
反覆使用同樣的測試會使軟件具有抵抗力
關注缺陷的修復
12 目前主要的測試用例設計方法是什麼？
白盒測試：
邏輯覆蓋
循環覆蓋
基本路徑覆蓋
黑盒測試：
邊界值分析法
等價類劃分
錯誤猜測法
因果圖法
狀態圖法
測試大綱法
隨機測試
場景法
13 什麼是測試用例 什麼是測試腳本？
測試用例爲實施測試而向被測試系統提供的輸入數據、操作或各種環境設置以及期望結果的一個特定的集合。
測試腳本是爲了進行自動化測試而編寫的腳本
14 測試人員在軟件開發過程中的任務是什麼？
1、尋找 Bug；
2、避免軟件開發過程中的缺陷；
3、衡量軟件的品質；
4、關注用戶的需求。
總的目標是：確保軟件的質量。
15 在您以往的工作中，一條軟件缺陷（或者叫 Bug）記錄都包含了哪些內容？如何提交高質量的軟件缺陷（Bug）記錄？
一條 Bug 記錄最基本應包含：編號、Bug 所屬模塊、Bug 描述、Bug 級別、發現日期、發現人、修改日期、修改人、修改方法、迴歸結果等等；
要有效的發現 Bug 需參考需求以及詳細設計等前期文檔設計出高效的測試用例，然後嚴格執行測試用例，對發現的問題要充分確認
肯定，然後再向外發布如此才能提高提交 Bug 的質量。
黑盒測試和白盒測試是軟件測試的兩種基本方法，請分別說明各自的優點和缺點！
16 測試計劃工作的目的是什麼？測試計劃文檔的內容應該包括什麼？其中哪些是最重要的？
答案：軟件測試計劃是指導測試過程的綱領性文件。
包含了產品概述、測試策略、測試方法、測試區域、測試配置、測試周期、測試資源、測試
交流、風險分析等內容。藉助軟件測試計劃，參與測試的項目成員，尤其是測試管理人員，
可以明確測試任務和測試方法，保持測試實施過程的順暢溝通，跟蹤和控制測試進度，應對
測試過程中的各種變更。
測試計劃和測試詳細規格、測試用例之間是戰略和戰術的關係，測試計劃主要從宏觀上規劃
測試活動的範圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。
所以其中最重要的是測試測試策略和測試方法（最好是能先評審）。
17 BUG（缺陷）的生命週期
對於一個問題，其處理過程是一個週期，週期的不同階段，其所處的狀態也是不一樣的。不同狀態所對應的處理人也是不一樣的。
提交（打開） ： 表示問題被提交等待有人處理。
指派（轉交） ： 問題被重新指派給某人處理。
處理 ： 問題在處理中，尚未完成。
固定 ： 確認此問題存在，但暫時不進行處理。
迴歸 ： 對已經修復的問題進行迴歸確認。Reopened :
關閉 ： 問題的最後一個狀態
18 在團隊中建立測試人員與開發人員良好溝通中注意以下幾點：
一真誠
二是團隊精神
三是在專業上有共同語言
四是要對事不對人，工作至上
當然也可以通過直接指出一些小問題，而不是進入 BUG Tracking System 來增加對方的好感
19 你對測試最大的興趣在哪裏？爲什麼？
回答這個面試題，沒有固定統一的答案，但可能是許多企業都會問到的。提供以下答案供考：
最大的興趣，感覺這是一個有挑戰性的工作；
測試是一個經驗行業，工作越久越能感覺到做好測試的難度和樂趣
通過自己的工作，能使軟件產品越來越完善，從中體會到樂趣
回答此類問題注意以下幾個方面：
儘可能的切合招聘企業的技術路線來表達你的興趣，例如該企業是數據庫應用的企業，那麼
表示你的興趣在數據庫的測試，並且希望通過測試提升自己的數據庫掌握能力。
表明你做測試的目的是爲了提升能力，也是爲了更好的做好測試；提升能力不是爲了以後轉
開發或其他的，除非用人企業有這樣的安排。
不要過多的表達你的興趣在招聘企業的範疇這外。比如招聘企業是做財務軟件的，可是你表
現出來的是對遊戲軟件的興趣；或招聘是做 JAVA 開發的，而你的興趣是在 C 類語言程序的
開發。
20 你自認爲測試的優勢在哪裏？
該面試也沒有固定不變的答案，但可參考以下幾點，並結合自身特點：
有韌性
有耐心
做事有條理性
喜歡面對挑戰
有信心做好每一件事情
較強的溝通能力
從以前的經理處都得到了很好的評價表明我做的很好
21. 一個測試工程師應具備那些素質？
1、責任心
2、溝通能力
3、團隊合作精神
4、耐心、細心、信心
5、時時保持懷疑態度，並且有缺陷預防的意識
6、具備一定的編程經驗
22 你認爲做好測試計劃工作的關鍵是什麼？
明確測試的目標，增強測試計劃的實用性
編寫軟件測試計劃得重要目的就是使測試過程能夠發現更多的軟件缺陷，因此軟件測試計劃的價值取決於它對幫助管理測試項目，並且找出軟件潛在的缺陷。因此，軟件測試計劃中的測試範圍必須高度覆蓋功能需求，測試方法必須切實可行，測試工具並且具有較高的實用性，便於使用，生成的測試結果直觀、準確堅持“5W”規則，明確內容與過程“5W”規則指的是“What（做什麼）”、“Why（爲什麼做）”、“When（何時做）”、“Where（在哪裏）”、“How（如何做）”。利用“5W”規則創建軟件測試計劃，可以幫助測試團隊理解測試的目的（Why），明確測試的範圍和內容（What），確定測試的開始和結束日期（When），指出測試的方法和工具（How），給出測試文檔和軟件的存放位置（Where）。
採用評審和更新機制，保證測試計劃滿足實際需求測試計劃寫作完成後，如果沒有經過評審，直接發送給測試團隊，測試計劃內容的可能不準確或遺漏測試內容，或者軟件需求變更引起測試範圍的增減，而測試計劃的內容沒有及時更新，誤導測試執行人員。
分別創建測試計劃與測試詳細規格、測試用例應把詳細的測試技術指標包含到獨立創建的測試詳細規格文檔，把用於指導測試小組執行測試過程的測試用例放到獨立創建的測試用例文檔或測試用例管理數據庫中。
測試計劃和測試詳細規格、測試用例之間是戰略和戰術的關係，測試計劃主要從宏觀上規劃測試活動的範圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。
23你的測試職業發展目標是什麼？
測試經驗越多，測試能力越高。所以我的職業發展是需要時間累積的，一步步向着高級測試
工程師奔去。而且我也有初步的職業規劃，前 3 年累積測試經驗，不斷的更新自己改正自己
24 測試結束的標準是什麼？
從微觀上來說，在測試計劃中定義，比如系統在一定性 能下平穩運行 72 小時，目前 Bug
Tracking System 中，本版本中沒有一般嚴重的 BUG，普通 BUG 的數量在 3 以下，BUG 修復
率 90%以上等等參數，然後由開發經理，測試經理，項目經理共同簽字認同版本 Release。
如果說宏觀的，則是當這個軟件徹底的消失以後，測試就結束了
25 一套完整的測試應該由哪些階段組成？
可行性分析、需求分析、概要設計、詳細設計、編碼、單元測試、集成測試、系統測試、驗
收測試
26 、測試用例通常包括那些內容？
不同結構的用例包括的不一樣。（版本、編號、項目、設計人員、設計日期、輸入、預期輸出„„）
軟件測試用例的基本要素包括測試用例編號、測試標題、重要級別、測試輸入、操作步驟、預期結果。
用例編號： 測試用例的編號有一定的規則，比如系統測試用例的編號這樣定義規則：
PROJECT1-ST-001 ，命名規則是項目名稱＋測試階段類型（系統測試階段）＋編號。定義測試用例編號，便於查找測試用例，便於測試用例的跟蹤。
測試標題： 對測試用例的描述，測試用例標題應該清楚表達測試用例的用途。比如 “ 測試用戶登錄時輸入錯誤密碼時，軟件的響應情況 ” 。
重要級別： 定義測試用例的優先級別，可以籠統的分爲 “ 高 ” 和 “ 低 ” 兩個級別。一般來說，如果軟件需求的優先級爲 “ 高 ” ，那麼針對該需求的測試用例優先級也爲“ 高 ” ；反之亦然，一般而言，是 5 級劃分。
測試輸入： 提供測試執行中的各種輸入條件。根據需求中的輸入條件，確定測試用例的輸入。測試用例的輸入對軟件需求當中的輸入有很大的依賴性，如果軟件需求中沒有很好的定義需求的輸入，那麼測試用例設計中會遇到很大的障礙。
操作步驟： 提供測試執行過程的步驟。對於複雜的測試用例，測試用例的輸入需要分爲幾個步驟完成，這部分內容在操作步驟中詳細列出。
預期結果： 提供測試執行的預期結果，預期結果應該根據軟件需求中的輸出得出。如果在
實際測試過程中，得到的實際測試結果與預期結果不符，那麼測試不通過；反之則測試通過。
27 在您所經歷的測試活動中，參與人員有哪些？您所擔任的角色是什麼？
有項目管理員、開發管理員、系統分析員、設計員、開發員、質量管理員、測試管理員、測
試設計員、測試員
擔任過測試管理員、測試設計員、測試員
28 請試着比較一下黑盒測試、白盒測試、單元測試、集成測試、系統測試、驗收 測試的區別與聯繫。
黑盒測試：已知產品的功能設計規格，可以進行測試證明每個實現了的功能是否符合要
求。
白盒測試：已知產品的內部工作過程，可以通過測試證明每種內部操作是否符合設計規
格要求，所有內部成分是否以經過檢查。
軟件的黑盒測試意味着測試要在軟件的接口處進行。這種方法是把測試對象看做一個黑
盒子，測試人員完全不考慮程序內部的邏輯結構和內部特性，只依據程序的需求規格說明書，
檢查程序的功能是否符合它的功能說明。因此黑盒測試又叫功能測試或數據驅動測試。黑盒
測試主要是爲了發現以下幾類錯誤：
1、是否有不正確或遺漏的功能？
2、在接口上，輸入是否能正確的接受？能否輸出正確的結果？
3、是否有數據結構錯誤或外部信息（例如數據文件）訪問錯誤？
4、性能上是否能夠滿足要求？
5、是否有初始化或終止性錯誤？
軟件的白盒測試是對軟件的過程性細節做細緻的檢查。這種方法是把測試對象看做一個
打開的盒子，它允許測試人員利用程序內部的邏輯結構及有關信息，設計或選擇測試用例，
對程序所有邏輯路徑進行測試。通過在不同點檢查程序狀態，確定實際狀態是否與預期的狀
態一致。因此白盒測試又稱爲結構測試或邏輯驅動測試。白盒測試主要是想對程序模塊進行
如下檢查：
1、對程序模塊的所有獨立的執行路徑至少測試一遍。
2、對所有的邏輯判定，取“真”與取“假”的兩種情況都能至少測一遍。
3、在循環的邊界和運行的界限內執行循環體。
4、測試內部數據結構的有效性，等等。
單元測試（模塊測試）是開發者編寫的一小段代碼，用於檢驗被測代碼的一個很小的、
很明確的功能是否正確。通常而言，一個單元測試是用於判斷某個特定條件（或者場景）下
某個特定函數的行爲。
單元測試是由程序員自己來完成，最終受益的也是程序員自己。可以這麼說，程序員有
責任編寫功能代碼，同時也就有責任爲自己的代碼編寫單元測試。執行單元測試，就是爲了
證明這段代碼的行爲和我們期望的一致。
集成測試（也叫組裝測試，聯合測試）是單元測試的邏輯擴展。它的最簡單的形式是：
兩個已經測試過的單元組合成一個組件，並且測試它們之間的接口。從這一層意義上講，組
件是指多個單元的集成聚合。在現實方案中，許多單元組合成組件，而這些組件又聚合成程
序的更大部分。方法是測試片段的組合，並最終擴展進程，將您的模塊與其他組的模塊一起
測試。最後，將構成進程的所有模塊一起測試。
系統測試是將經過測試的子系統裝配成一個完整系統來測試。它是檢驗系統是否確實能
提供系統方案說明書中指定功能的有效方法。（常見的聯調測試）
系統測試的目的是對最終軟件系統進行全面的測試，確保最終軟件系統滿足產品需求並
且遵循系統設計。
驗收測試是部署軟件之前的最後一個測試操作。驗收測試的目的是確保軟件準備就緒，
並且可以讓最終用戶將其用於執行軟件的既定功能和任務。
驗收測試是向未來的用戶表明系統能夠像預定要求那樣工作。經集成測試後，已經按照設計
把所有的模塊組裝成一個完整的軟件系統，接口錯誤也已經基本排除了，接着就應該進一步
驗證軟件的有效性，這就是驗收測試的任務，即軟件的功能和性能如同用戶所合理期待的那樣。
29 針對於軟件的行業背景，你如何理解軟件的業務？
閱讀用戶手冊瞭解軟件的功能和操作流程；
看一些業務的專業書籍補充業務知識；
如果有用戶實際的數據，可以拿實際的數據進行參考；
參考以前的用例和 BUG 報告；
在使用軟件的過程中多思考；
多與產品經理交流。
30 什麼是版本控制，常用的版本控制系統有哪些？
版本控制（Revision control）是一種軟體工程技巧，籍以在開發的過程中，確保由不同人所編輯的同一檔案都
得到更新。
Git(讀音爲/gɪt/。)是一個開源的分佈式版本控制系統，可以有效、高速的處理從很小到非常大的項目版本管理。
Git 是 Linus Torvalds 爲 了 幫 助 管 理 Linux 內 核 開 發 而 開 發 的 一 個 開 放 源 碼 的 版 本 控 制 軟 件 。
https://git-scm.com/doc
SVN 是 Subversion 的簡稱，是一個開放源代碼的版本控制系統，相較於 RCS、CVS，它採用了分支管理系統，
它 的 設 計 目 標 就 是 取 代 CVS 。 互 聯 網 上 很 多 版 本 控 制 服 務 已 從 CVS 遷 移 到 Subversion 。
https://tortoisesvn.net/support.html
31 一個有廣告的紙杯子，請設計測試用例？
測試項目：杯子
需求測試：查看杯子使用說明書
界面測試：查看杯子外觀
功能度：用水杯裝水看漏不漏；水能不能被喝到
安全性：杯子有沒有毒或細菌
可靠性：杯子從不同高度落下的損壞程度
可移植性：杯子再不同的地方、溫度等環境下是否都可以正常使用
兼容性：杯子是否能夠容納果汁、白水、酒精、汽油等
易用性：杯子是否燙手、是否有防滑措施、是否方便飲用
用戶文檔：使用手冊是否對杯子的用法、限制、使用條件等有詳細描述
疲勞測試：將杯子盛上水（案例一）放 24 小時檢查泄漏時間和情況；盛上汽油（案例二）放 24 小時泄漏
時間和情檢查況等
壓力測試：用根針並在針上面不斷加重量，看壓強多大時會穿透
跌落測試: 杯子加包裝(有填充物),在多高的情況摔下不破損
震動測試: 杯子加包裝(有填充物),六面震動,檢查產品是否能應對惡劣的鐵路\公路\航空運輸
基本功能測試（邏輯功能測試）。
（1）硬度：是否達到設計標準。
裝載能力：在杯子內分別裝入少量的、半杯的、滿杯的，看其裝載量是否達到設計標準。
裝載種類：開水（是否產生異味）、溫水、冷水、冰水、咖啡。。。
（2）界面測試（UI 測試）。
看其形狀、大小設計是否適合人方便拿起。
外觀是否吸引人（廣告嘛），賞心悅目。
帶廣告的圖案沾水受是否掉色、模糊。
（3）易用性測試。
看其形狀、大小設計是否適合人方便拿起。
殘疾人士用此杯去喝水的容程度。
杯子設計是否上大下小，在運輸過程中可以套在一起有效利用空間，在使用時也容易拿開。
（4）穩定性測試（24 X 7 測試）。裝入液體後記錄其多少以後漏水。
（5）安全性測試。杯子所用的材料（包括紙基、塗層和廣告顏料）是否符合食品衛生標準，在內外溫度等環境
因素下是否會與所盛各種飲料相反應，而產生對人體有害的物質。
（6）本地化測試。爲國際化和本地化的需要，廣告圖案和文字是否在政治、宗教和文化方面具有廣泛的適用性。
（7）對設計的改進建議。“如果是一次性杯子，能否標示已使用（比如變色）”和“杯子是否有使用者標貼（多人
使用時防止混淆）”。
32 .一個身份證號碼輸入框，怎麼設計用例？
校驗身份證號規則的有效性（包括地址碼、生日期碼、順序碼和校驗碼
校驗 15 位身份證號和 18 位身份正好都是可用的
校驗末位是 X 的情況
校驗不足 15 位、16-17 位和大於 18 位的情況
如果是必輸項，校驗不輸入的時候會不會有正確的提示
如果不是必輸項，則要校驗不輸入的時候流程能否正常進行
校驗輸入非數字的情況，是否會有正確提示信息（包括大小寫字母、漢字、特殊字符和標點符號）
校驗輸入全角的數字的時候，系統是否會識別（這個得根據需求確定是否可以使用全角的數字）