軟體測試工程師之——軟體測試工程師 面試100題 【基礎篇】持續更新中.....
1 軟體的含義 程式、資料及相關檔案的完整集合。
2 測試與偵錯的區別是什麼？
測試是由測試人員來進行，主要目標是發現、報告和跟蹤缺陷。 偵錯是由開發人員進行，主要目標是定位缺陷位置，分析缺陷原因，修復缺陷。
3 IEEE 是什麼意思？
國際電氣電子工程師協會
4 GB 是什麼意思？
國家標準
5 軟體測試的含義 簡單講，軟體測試是發現缺陷的過程；
IEEE 中的定義是，軟體測試是使用人工或自動手 段來執行或測定某個系統的過程，目的在於檢驗它是否滿足規定的需求或弄清預期結果與實 際結果之間的差別。
6 軟體測試的目的
（1）驗證軟體是否滿足各類檔案說明書等規定的軟體品質要求
（2）找出軟體缺陷
（3）為軟體產品的品質測量和評價提供依據
（4）幫助開發改進開發流程
7 什麼是功能、效能、相容性 功能代表一個軟體能做什麼；
效能反映軟體執行的速度或效率、佔用資源的多少等指標； 相容性表示一個軟體與其所在執行環境的依賴程度，包括與硬體、操作平臺、其他軟體的依 賴。
8 測試分為哪幾個階段？每個階段的測試目的是什麼？
測試分為單元測試、整合測試、系統測試、驗收測試四個階段。前三個階段的目的是盡 可能多的發現缺陷，而驗收測試是要驗證軟體滿足了使用者需求，幫助使用者建立系統可以正常 使用的信心，發現缺陷不是此階段的目標。
9 解釋 QA 及其職責 QA 的含義是軟體品質保證（人員）。
主要職責是制定和加強促進軟體開發並防止軟體缺陷的標準和方法，並監督標準和過程 被正確的遵循。
10 測試工程師與軟體品質保證的區別 測試工程師的主要任務是在最短的時間內發現儘可能多的缺陷，並確保這些缺陷得以修 復。軟體品質保證的主要職責是制定和加強促進軟體開發並防止軟體缺陷的標準和方法，並 監督標準和過程被正確的遵循。
11 測試應該由什麼人來進行？
測試應該由獨立的第三方來進行，第三方表示測試人員不參與程式的開發。
12 pareto 法則、帕累托法則、28 原則、82 原則 一般情況下 80%的缺陷聚集在 20%的關鍵核心業務模組中，這個原則至少告訴我們在做 測試時，應該重點分析和測試 20%的核心業務，具體說要做好需求分析。
13 殺蟲劑怪事 殺蟲劑怪事用於描述軟體測試越多，其對測試的免疫力越強的現象。這個現象告訴我們， 測試時，應嘗試新方法、不同的測試程式，對程式進行測試，以找出更多軟體缺陷。
14 木桶原理 木桶原理在軟體方面的主要含義是全面品質管理，另外還告訴我們測試時要關注團隊中 較弱的人。
15 Good-enough 原則 Good-enough 原則告訴我們做測試的時候既不要做過多測試，也不做不充分的測試。至 於多少測試合適，需要我們不斷積累經驗，在專案中可以指定最低測試通過標準和測試內容， 然後具體問題具體分析。
16 群集效應 群集效應的含義是發現的缺陷越多，證明軟體存在的缺陷越多。群集效應指導我們在找 到軟體缺陷的地方要繼續找找。
17 什麼是確認測試？迴歸測試？
確認測試也稱再測試：缺陷修復以後，驗證缺陷是否真正修復 迴歸測試：缺陷修復以後，確保對程式的修改沒有給軟體其他未改變部分帶來新的缺陷。
18 測試人員應該具備哪些素質？
要有責任心，要有破壞的態度，對事不對人，三心二意（細心、信心、耐心、缺陷預防 意識、溝通意識），具有一定的開發技能，善於思考。
19 如果測試提交的缺陷開發人員不認可，該怎麼辦？
首先分析或與開發溝通開發不認可的原因。 如果拒絕原因是提交的不是缺陷，而且自己分析後，的確不是缺陷，則應該注意以後再 做測試時要做好復現，認真研讀需求，提高自己找缺陷的能力。 如果拒絕原因是提交的不是缺陷 但自己分析時認為缺陷應該是存在的，則再次研讀需 求並做好復現，拿出確實是缺陷的證據，然後與開發溝通。 如果拒絕原因是認可缺陷，但不予修復，如果自己覺得必須修復，則拿出充分理由和證 據和不修復的不利影響和影響範圍，再與開發溝通。 注意溝通技巧，合理的論述，向開發說明自己的判斷的理由，注意客觀、嚴謹，不摻雜 個人情緒。 把問題交給測試經理，等待測試經理做出最終決定，如果仍然存在爭議，可以通過公司 政策所提供的渠道，向上級反映，並由上級做出決定。
20 如何解決開發和測試的矛盾？
（1）以溝通和合作的方式開展工作
（2）提高開發技能
（3）換位思考
（4）進行有效溝通
21 測試團隊中都有哪些角色？各負責什麼任務？各有多少人？
測試負責人：制定測試計劃，監督安排任務，進行測試總結，1 測試工程師：進行測試需求分析、設計用例、搭建環境、執行用例、提交併跟蹤缺陷 ， 3 技術支援：負責環境維護，1 設定管理員：維護版本架構，維護版本庫，檔案設定，1 品質保證人員：負責軟體品質方面的工作，1
22 什麼是軟體開發生命週期？
從軟體最初構思到公開發行的過程。瀑布模型的過程是計劃、需求、設計、編碼、測試、 執行、維護迴圈。瀑布模型有嚴格的開發步驟，每個階段是按順序進行的，每個階段都必須編寫完整的文 檔，每個階段完成後必須經過審查才能進入下一步。 瀑布模型不能迭代、不能反覆；測試在編碼之後，測試太晚；測試的只是程式。
23 軟體開發有什麼模型？
軟體測試主要有哪些模型？ 軟體開發模型：大爆炸模型、邊寫邊改模型、瀑布模型、螺旋模型、敏捷開發模型 軟體測試模型：V 模型、W 模型、H 模型、X 模型、前置測試模型、敏捷測試模型
24 簡述 V 模型。
V 模型的過程：使用者需求→需求分析→概要設計→詳細設計→編碼→單元測試→整合測 試→系統測試→驗收測試。
優點：
（1）V 的左端表示傳統的瀑布開發模型，V 的右端明確地將測試分為不同的級別或階 段，測試過程更為具體；
（2）測試各個階段和開發的各個階段相對應；
（3）V 模型的測試策略包括低層測試和高層測試，低層測試是為了原始碼的正確性， 高層測試是為了整個系統滿足使用者的需求。
缺點：
（1）測試的物件就是程式本身。忽視了測試活動對需求分析，系統設計等活動的驗證 和確認的功能，直到後期的驗收測試才被發現。
（2）測試是開發之後的一個階段。實際應用中容易導致需求階段的錯誤一直到最後系 統測試階段才被發現。
25 簡述 W 模型。
W 模型的過程：左邊 V 是需求分析→概要設計→詳細設計→編碼實現→模組整合→系 統構建→系統安裝；右邊 V 是需求測試→概要設計測試→詳細設計測試→單元測試→整合 測試→系統測試→驗收測試。
優點：
（1）W 模型體現了儘早和不斷測試的原則，既強調測試方案設計，也強調測試執行。
（2）左側 V 是開發，右側 V 是與開發並行的測試，相對於 V 模型，W 模型增加了軟體 各開發階段中應同步進行的驗證和確認活動，W 明確表示出了測試與開發的並行關係。測 試與開發是同步進行的，有利於儘早地全面的發現問題。
（3）測試伴隨整個軟體開發週期，且測試的物件不僅僅是程式，需求、設計等同樣要 測試。
缺點：
在 W 模型中，需求、設計、編碼等活動被視為序列的，測試和開發活動也保持著一種 線性的前後關係，上一階段完全結束，才可正式開始下一個階段工作。這樣就無法支援迭代 的開發模型，不利於當前軟體開發複雜多變的情況。
26 簡述 H 模型。
H 模型將測試活動完全獨立出來，形成一個完全獨立的流程，將測試準備活動和測試執 行活動清晰地體現出來。H 模型的測試流程是隻要測試準備工作完成，達到測試就緒點，測 試就可以執行了。
優點：
（1）軟體測試不僅僅指測試的執行，還包括很多其他的活動。
（2）軟體測試是一個獨立的流程，貫穿產品整個生命週期，與其他流程並行地進行。 當某個測試時間點就緒時，軟體測試即從測試準備階段進入測試執行階段。
（3）H 模型反映出軟體測試要儘早準備，儘早執行。
（4）軟體測試可以進行迭代、反覆進行。
27 敏捷開發 敏捷開發的核心思想是：以人為本，適應變化。 具體講：
（1）認為個體和互動重於過程和工具，強調通過過程和工具理解個人和交流的作用；
（2）認為可用軟體重於完備檔案，強調通過全面的檔案理解執行的軟體；
（3）認為客戶共同作業重於合同談判，強調通過合同和談判得到客戶的共同作業；
（4）認為響應變化重於遵循計劃，強調在計劃的執行中做出對變更的響應。
特點：
（1）敏捷開發提倡迭代式和增量式的開發模式，並強調測試在其中的重要作用。
（2）敏捷開發是以使用者為中心、以客戶需求為導向的開發過程，在此過程中隨時做好 「迎接變化」的準備，客戶是敏捷的關鍵環節。
（3）敏捷開發沒有單一固定的開發方法或過程，敏捷開發有三個共同點：依賴客戶的 參與、測試驅動以及緊湊的迭代開發週期。
28 敏捷測試
（1）敏捷測試是協同測試的一種形式，程式設計師結對程式設計，程式設計師分飾測試員角色，敏 捷測試是連續測試。
（2） 敏捷測試側重單元測試和驗收測試。單元測試的過程是先設計單元測試用例，然 後進行編碼，之後執行測試。
（3）敏捷測試強調客戶參與，單元測試通過之後程式碼整合到程式碼庫中，再由客戶進行 驗收測試，驗收測試的結論反饋給開發人員，缺陷得以迅速修復。
29 軟體品質要求有哪些？
功能要求和非功能要求。
30 軟體非功能要求有哪些？
效能要求（負載測試、壓力測試、容量測試、可靠性測試）、介面測試、相容性測試、 易用性測試、檔案測試、可用性測試、安裝測試、安全測試、災難恢復測試等。
31 簡述測試的基本過程
（1）測試人員進行測試需求分析。
（2）測試負責人編寫測試計劃。
（3）測試人員根據測試需求分析設計和編寫測試用例。
（4）測試人員搭建測試環境、建立測試資料、執行測試用例、提交缺陷報告並進行跟 蹤、記錄測試事件。
（5）進行測試評估和總結。 每一分步工作完成後都進行評審。
32 拿到一個軟體後，應該怎樣開始工作？
編寫需求分析並評審→編寫測試計劃並評審→設計測試用例並評審→搭建測試環境、執 行測試用例、提交缺陷報告→進行評估和總結
33 怎麼做測試？
編寫需求分析並評審→編寫測試計劃並評審→設計測試用例並評審→搭建測試環境、執 行測試用例、提交缺陷報告→進行評估和總結
34 簡介測試流程 編寫需求分析並評審→編寫測試計劃並評審→設計測試用例並評審→搭建測試環境、執 行測試用例、提交缺陷報告→進行評估和總結。
35 怎麼進行測試需求分析？
（1）收集各類檔案，仔細閱讀檔案，提出問題，分析問題或溝通解決，整理需求資訊。
（2）編寫測試需求分析說明書：功能分解，編寫檢查點和測試點。
（3）需求評審。
36 拿到專案後，需要分析或諮詢軟體哪些方面的問題？
軟體主要的功能、流程、開發環境（開發語言<含資料型別>、資料庫、中介軟體）、執行 環境（硬體、軟體、網路、軟體架構）、使用者群、測試範圍、測試優先順序。
37 什麼時候提交發現的缺陷？
測試執行發現缺陷時立即提交缺陷。
38 什麼是入口準則、出口準則？
入口準則是進行一項測試工作前需要準備好的前提條件。 出口準則是一項測試工作可以結束的前提條件。
39 需求評審都有哪些人蔘與？
專案經理、開發經理、測試經理、測試人員、開發人員、市場經理、客戶等。
40 怎麼做需求評審或者說需求評審需要評審哪些方面？
編寫或設計需求評審檢查單，比如可以檢查有無錯別字、病句，標點符號使用是否正確， 格式是否一致，是否還有多餘需求，是否有錯誤需求，是否有遺漏需求等。
41 測試資源需求有哪些方面？
人力資源、硬體資源、軟體資源。
42 什麼是測試策略？什麼是測試範圍？
測試策略主要指如何進行某種測試（如功能測試、效能測試、相容性測試、可用性測試、 易用性測試等），用於說明測試方法以及如何使用測試方法。測試範圍有時候等價於測試策 略，有時候可以表示要進行測試的某個軟體部位。
43 什麼是 BVT？冒煙測試？版本驗證測試？怎麼測？
也稱冒煙測試、版本驗證測試、小版本驗證測試、版本構建測試。冒煙測試用例是一組 想先執行以確定這個給出的小版本是否可以測試的測試用例。冒煙測試主要測試軟體的基本 功能，以判斷整個軟體值不值得進行大規模測試。通常由一個人進行 1-2 小時的測試，一般 不測試次要功能和各種錯誤。
44 測試計劃的內容和目的是什麼？
包含了產品概述、測試區域/測試策略/測試範圍/測試目標（測試項、被測特徵）、測試 設定/測試資源、測試周期、進度安排（測試任務、人員安排）、測試方法/途徑、測試交流、 風險分析等內容。目的是指導測試過程，規定測試活動的範圍、方法、資源和進度；明確正 在測試的專案、要測試的特性、要執行的測試任務、每個任務的責任人以及與計劃相關的風 險。
45 怎麼判斷是不是軟體缺陷？
（1）軟體未達到產品說明書標明的功能；
（2）軟體出現了產品說明書指明不會出現的錯誤；
（3）軟體功能超出產品說明書指明範圍；
（4）軟體未達到產品說明書雖未指出但應達到的目標；
（5）軟體測試員具體問題具體分析，認為軟體難以理解、不易使用、執行速度緩慢， 或者終端使用者認為不好。
46 缺陷的產生主要有哪些原因？最主要的原因是什麼？
需求頻繁變更、溝通不良、不瞭解客戶的需求、實現新功能或很酷的功能、追求新技術、 專案期限的壓力、需求分析或設計投入的時間和精力不夠、產品的複雜度、開發人員疲勞、 壓力過大或受到干擾、缺乏足夠的知識、技能和經驗、缺乏動力等。 最主要的原因：需求方面的原因
47 當你發現一個缺陷時，應該怎麼確認的確是一個缺陷？
根據缺陷的判斷原則來甄別發現的問題是不是一個缺陷，發現缺陷後，應該做好分離和 再現（3 次），然後才能提交。
48 在正式提交一個缺陷前，你應該做些什麼？
分離缺陷、再現缺陷（3 次），然後才能提交。
49 怎麼處理無法再現的缺陷？ 首先，應當對這樣的缺陷進行詳細的記錄，並儘快提交給開發人員。 其次，對於尋找難以再現的缺陷要合理地安排時間，對一時難以再現的缺陷可以暫時擱 置，以保證專案的正常進度。 最後，在測試過程中對未再現缺陷予以關注。
50 什麼是重複缺陷？怎麼避免重複缺陷？
提交了一個缺陷庫中存在或者開發人員已經知道的缺陷。
1、如果缺陷是跟同事提交的重複，任務分工解決，也可以在提交之前查詢下庫缺陷是 否存在。
2、如果缺陷是與自己提交的缺陷重複，則需要提高發現缺陷的能力，通過提高開發能 力來理解兩個缺陷本質上是一個缺陷。
51 什麼是無效缺陷？怎麼避免無效缺陷？
提交的缺陷不是真正的缺陷。 充分了解需求、提高自己識別缺陷的能力、提高缺陷寫作能力 52 缺陷報告的寫作準則是什麼？ Correct（準確）：每個組成部分的描述準確，不會引起誤解； Clear（清晰）：每個組成部分的描述清晰，易於理解； Concise（簡潔）：只包含必不可少的資訊，不包括任何多餘的內容； Complete（完整）：包含復現該缺陷的完整步驟和其他本質資訊； Consistent（一致）：按照一致的格式書寫全部缺陷報告。
53 缺陷報告的內容有哪些？
缺陷標題（或者說缺陷摘要、缺陷概述、缺陷基本資訊） 預處理 復現步驟 預期結果 實際結果 嚴重程度 優先順序 測試環境 測試版本 測試執行人 註釋
54 缺陷報告的組織結構是什麼？
缺陷標題（或者說缺陷摘要、缺陷概述、缺陷基本資訊） 預處理 復現步驟 預期結果 實際結果 嚴重程度 優先順序 測試環境 測試版本 測試執行人 註釋
55 缺陷報告的寫作需要注意什麼問題？
不要使用我、你、他等字眼，不要使用情緒化的語言和強調符號、不要使用「似乎」、 看上去可能等不確定性內容、不要使用認為比較幽默的內容、不要使用不確定的測試問題(不 確定是否是缺陷)、不要人身攻擊。
56 簡述缺陷報告的處理流程 軟體測試人員提交缺陷報告；
測試負責人稽核後將缺陷報告分配給相關的開發人員修改； 缺陷被修改後由測試人員根據缺陷報告中的修改記錄進行返測 返測通過的缺陷報告由負責人關閉； 返測未通過的缺陷報告直接返回開發人員重新修改，然後再由測試人員返測，直到測試 和開發達成一致處理意見。
57 簡述缺陷的生命週期 軟體測試人員提交缺陷報告；
測試負責人稽核後將缺陷報告分配給相關的開發人員修改； 缺陷被修改後由測試人員根據缺陷報告中的修改記錄進行返測 返測通過的缺陷報告由負責人關閉； 返測未通過的缺陷報告直接返回開發人員重新修改，然後再由測試人員返測，直到測試 和開發達成一致處理意見。
58 簡述重複缺陷的處理流程
提交缺陷→分配缺陷→是重複缺陷→置為無效缺陷。
59 缺陷按照嚴重程度可以分為哪些型別？
致命缺陷、嚴重缺陷、一般缺陷、較小錯誤、意見建議等
60 缺陷按照優先順序可以分為哪些型別？ 缺陷必須立即解決； 缺陷需要正常排隊等待修復或列入軟體釋出清單； 缺陷可以在方便時被糾正； 下一個版本修復； 不修復。
61 缺陷的狀態有哪些？
新建/已提交 開啟已拒絕 已解決/已修復 已驗證 已關閉
62 測試有哪些級別？
單元測試、整合測試、系統測試、驗收測試
63 測試有哪些階段？
單元測試、整合測試、系統測試、驗收測試
64 什麼是單元測試？
單元測試誰來做？ 針對一個軟體單元的測試。開發人員或懂開發的測試人員
65 什麼是樁模組、驅動模組？
樁模組：被被測模組呼叫的模組。 驅動模組：呼叫被測模組的模組。
66 什麼時候可以進行元件測試？
完成編譯的測試物件，測試環境，開發工具，測試物件的規範說明書。
67 單元測試使用技術？測試重點是什麼？測試條件是什麼？
單元測試的技術：黑盒白盒技術，但是白盒居多，黑盒居少，一般先做黑盒再做白盒。 單元測試重點：功能性測試，健壯性（逆向測試：無效值），效能。 單元測試前提條件：完成編譯的測試物件，測試環境，開發工具，測試物件的規範說明 書。
68 什麼是整合測試？
元件間的介面與互動的測試。
69 整合測試的測試重點是什麼？測試條件是什麼？使用什麼技術？
介面和系統內不同部分的相互作用（互動）。 測試條件是完成整合的被測系統，測試臺，有關元件間互動的檔案。 測試技術包括白盒技術、黑盒技術，白盒居多，黑盒居少，對比單元測試，白盒下降， 一般先做黑盒再做白盒。
70 整合測試有哪些策略？
自頂向下整合 自底向上整合
71 什麼是系統測試？
對整個系統能不能滿足使用者需求的測試。
72 系統測試的目的是什麼？
檢查軟體是否滿足需求。
73 系統測試能夠發現哪些缺陷？會遺留哪些缺陷？ 發現：非功能性缺陷、涉及整個系統的問題。 遺漏：對使用者的需求的錯誤理解、沒有實現或者沒有完全實現使用者的隱性需求。
74 什麼是驗收測試？ 一般由使用者/客戶進行的確認是否可以接受一個系統的驗證性測試。驗收測試根據使用者 需求，業務流程進行的正式測試以確保系統符合所有驗收的準則。
75 驗收測試有哪些人進行？ 客戶或使用者，測試人員可以介入。
76 驗收測試的目標是什麼？
對系統或子系統建立信心、對系統非功能性的特性贏得信任。
77 什麼是 alpha、beta 測試？有何區別？
Alpha 測試：潛在的客戶/使用者在開發場地進行的測試。 Beta 測試：由潛在客戶/使用者在自己的環境下測試軟體系統。
78 什麼是維護測試？ 軟體正常使用後，對軟體的變更、更新進行測試
79 什麼是效能測試？負載測試？壓力測試？有什麼區別？
效能表現處理速度、響應時間、CPU 使用、記憶體使用、硬碟使用等。 負載測試：通過不斷增加負載來測試一個系統的效能。 壓力測試：通過增加負載超過系統正常工作能力來考察系統能否在異常情況下正常工作
80 什麼是功能測試？
測試一個軟體能做什麼，是不是做了應該做的工作，沒做不該做的工作。
81 什麼是結構測試？
白盒測試也稱結構測試、邏輯驅動測試、基於程式本身的測試，是對程式結構進行的測 試。
82 什麼是與變更相關的測試？
有哪些具體型別？ 與變更相關的測試是對修改過的程式進行的測試。 確認測試（再測試）和迴歸測試。
83 什麼是靜態測試？動態測試？如何區分二者？
靜態測試：不執行程式的測試。針對檔案和不需執行的程式碼。動態測試需要執行程式，方法一般採用黑箱測試方法和白盒測試方法。
84 圈複雜度怎麼計算？
不重疊的閉合環數+1
85 什麼是黑箱測試？白盒測試？
黑箱測試也稱功能測試，基於規格說明書的測試，關注輸入資料到程式中，輸出結果是 否正確，側重於測試軟體能做什麼 白盒測試也稱結構測試、邏輯驅動測試，是對程式內部邏輯結構進行的測試
86 白盒測試有哪些方法？具體解釋每種方法？
白盒測試主要使用邏輯覆蓋測試方法，包括語句覆蓋、判定覆蓋、條件覆蓋、判定-條 件覆蓋、條件組合覆蓋、路徑覆蓋等。 語句覆蓋：程式中的每個可執行語句至少被執行一次。能發現語句錯誤，但不能發現邏 輯錯誤。判定覆蓋：也稱分支覆蓋，程式中的每個判定的取真分支和取假分支至少執行一次。能 發現邏輯錯誤，但不能發現組合判斷中的條件錯誤。 條件覆蓋：程式每個判定中每個條件的可能取值至少滿足一次。能發現條件錯誤，但不 能發現邏輯錯誤。 判定-條件覆蓋：每個條件中的所有可能取值至少執行一次，同時，每個判定的可能結 果至少執行一次。 條件組合覆蓋：每個判定中的所有的條件取值組合至少執行一次。 路徑覆蓋：用例覆蓋程式中的所有可能的執行路徑。如果路徑數很多，會變得不切實際。
87 什麼是設定測試？
不同設定環境下進行測試。
88 什麼是檔案測試？
不僅包括測試檔案校對，還有檔案和軟體不一致
89 什麼是國際化測試？在地化測試？
國際性的軟體 翻譯成本國語言的，測試是否符合本國的語言習慣，是否符合本國法律，是否符合本國 的國情。
90 測試用例的內容是什麼？
用例編號，測試概述或用例標題、測試步驟，預期結果，輸入資料，優先順序，前置條件 等
91 測試用例有哪些元素？
用例編號，測試概述或用例標題、測試步驟，預期結果，輸入資料，優先順序，前置條件 等 或者說測試目標 Why、測試物件 What、測試環境要求 Where、測試前提 When，輸入 資料
92 什麼是 UI、GUI？UI 測試什麼意思？
介面圖形介面 介面測試
93 測試用例的優先順序如何？
冒煙測試 高中低
94 解釋測試目標、測試環境、測試物件、前置條件、測試策略、測 試範圍的含義？
測試目標：功能測試、效能測試、介面測試、易用性測試、相容性測試、安全性測試 測試策略：某類別測試的過程、方法以及方法如何應用，測試的注意事項等 測試環境：硬體環境、軟體環境、網路環境 前置條件：進行某些測試工作需要做好的準備條件 測試範圍：軟體需要測試的某個部位
95 用例評審一般使用什麼方式？
哪些人蔘與評審？ 檢查單。一般由測試人員進行
96 測試計劃由誰編寫？測試需求說明書由誰編寫？測試用例誰編 寫？測試總結誰編寫？
測試負責人。測試人員（測試需求分析人員）。測試人員（測試設計工程師）。測試負責 人
97 軟體投入執行後還需要測試嗎？需要哪些測試？
需要測試。維護測試（含升級測試）、資料遷移測試、備份恢復測試、災難恢復測試等
98 SP2 什麼意思？
第 2 個版本的服務包或修補程式包
99 給你一個網站，你如何測試？
首先，查詢需求說明、網站設計等相關檔案，分析測試需求。 制定測試計劃，確定測試範圍和測試策略，一般包括以下幾個部分：功能性測試、界 面測試、效能測試、資料庫測試、安全性測試、相容性測試。
設計測試用例：
功能性測試可以包括，但不限於以下幾個方面：
連結測試。連結是否正確跳轉，是否存在空頁面和無效頁面，是否有不正確 的出錯資訊返回。
提交功能的測試。
多媒體元素是否可以正確載入和顯示。
多語言支援是否能夠正確顯示選擇的語言等。 介面測試可以包括但不限於一下幾個方面：
頁面是否風格統一，美觀
頁面佈局是否合理，重點內容和熱點內容是否突出
控制元件是否正常使用
對於必須但未安裝的控制元件，是否提供自動下載並安裝的功能
文字檢查
效能測試一般從以下兩個方面考慮：
壓力測試、負載測試
資料庫測試要具體決定是否需要開展。
資料庫一般需要考慮連結性，對資料的存取操作，資料內容的驗證等方面。
安全性測試：
基本的登入功能的檢查
是否存在溢位錯誤，導致系統崩潰或者許可權洩露
相關開發語言的常見安全性問題檢查，例如 SQL 注入等
相容性測試，根據需求說明的內容，確定支援的平臺組合：
瀏覽器的相容性；
作業系統的相容性；
軟體平臺的相容性；
資料庫的相容性
開展測試，並記錄缺陷。
合理的安排調整測試進度，提前獲取測試所需的資源，建立管理體系（例如，需 求變更、風險、設定、測試檔案、缺陷報告、人力資源等內容）。
定期評審，對測試進行評估和總結，調整測試的內容。
100 一臺使用者端有三百個客戶與三百個使用者端有三百個客戶對服務 器施壓，有什麼區別?
300 個使用者在一個使用者端上
會佔用客戶機更多的資源，而影響測試的結果。執行緒之間可能發生干擾，而產生 一些異常。
需要更大的頻寬。
IP 地址的問題，可能需要使用 IP 欺騙來繞過伺服器對於單一 IP 地址最大連線 數的限制。
不必考慮分散式管理的問題。
使用者分佈在不同的使用者端上
需要考慮使用控制器來整體調配不同客戶機上的使用者。
需要給予相應的許可權設定和防火牆設定。
最後：
一線網際網路 軟體測試 的高階進階路線思維圖
看完這篇內容後，相信以下兩件事，也會對你的個人提升有所幫助：
1、 點贊，讓更多人能看到這篇文章，同時你的認可也會鼓勵我創作更多優質內容。
2、 讓自己變得更強：想一想，如果你想在測試這個行業一直做下去，你的經驗和測試技術是遠遠不夠的，你需要進階，你需要豐富你的技術棧！還等什麼！
最後:【可能給予你助力的教學】
這些資料，對於做【軟體測試】的朋友來說應該是最全面最完整的備戰倉庫，這個倉庫也陪伴我走過了最艱難的路程，希望也能幫助到你！凡事要趁早，特別是技術行業，一定要提升技術功底。
關注我的微信公眾號：【傷心的辣條】免費獲取~
如果我的部落格對你有幫助、如果你喜歡我的部落格內容，請 「點贊」 「評論」 「收藏」 一鍵三連哦！
好文推薦：
我TM謝謝你！給我100塊羞辱離職，原來是激勵我「臥薪嚐膽」！