（純干貨）備戰“金3銀4”，拿下這101道面試題“10拿9穩””！

前言：

馬上就到了“金9銀10的”面試季，在這里作者給各位整理了一些大廠常用的面試題，希望能對各位有所幫助

正文：

1、問：你在測驗中發現了一個bug，但是開發經理認為這不是一個bug，你應該怎樣解決？

首先，將問題提交到缺陷管理庫里面進行備案，

然后，要獲取判斷的依據和標準：

根據需求說明書、產品說明、設計檔案等，確認實際結果是否與計劃有不一致的地方，提供缺陷是否確認的直接依據；
如果沒有檔案依據，可以根據類似軟體的一般特性來說明是否存在不一致的地方，來確認是否是缺陷；
根據用戶的一般使用習慣，來確認是否是缺陷；
與設計人員、開發人員和客戶代表等相關人員探討，確認是否是缺陷；
合理的論述，向測驗經理說明自己的判斷的理由，注意客觀、嚴謹，不參雜個人情緒，

等待測驗經理做出最終決定，如果仍然存在爭議，可以通過公司政策所提供的渠道，向上級反映，并有上級做出決定，

2、問：給你一個網站，你如何測驗？

首先，查找需求說明、網站設計等相關檔案，分析測驗需求，

制定測驗計劃，確定測驗范圍和測驗策略，一般包括以下幾個部分：功能性測驗；界面測驗；性能測驗；資料庫測驗；安全性測驗；兼容性測驗

設計測驗用例：

功能性測驗可以包括，但不限于以下幾個方面：

鏈接測驗，鏈接是否正確跳轉，是否存在空頁面和無效頁面，是否有不正確的出錯資訊回傳，
提交功能的測驗，
多媒體元素是否可以正確加載和顯示，
多語言支持是否能夠正確顯示選擇的語言等，
界面測驗可以包括但不限于一下幾個方面：

頁面是否風格統一，美觀
頁面布局是否合理，重點內容和熱點內容是否突出
控制元件是否正常使用
對于必須但未安裝的控制元件，是否提供自動下載并安裝的功能
文字檢查
性能測驗一般從以下兩個方面考慮：

壓力測驗；負載測驗；強度測驗

資料庫測驗要具體決定是否需要開展，資料庫一般需要考慮連結性，對資料的存取操作，資料內容的驗證等方面，

安全性測驗：

基本的登錄功能的檢查
是否存在溢位錯誤，導致系統崩潰或者權限泄露
相關開發語言的常見安全性問題檢查，例如SQL注入等
如果需要高級的安全性測驗，確定獲得專業安全公司的幫助，外包測驗，或者獲取支持
兼容性測驗，根據需求說明的內容，確定支持的平臺組合：

瀏覽器的兼容性；
作業系統的兼容性；
軟體平臺的兼容性；
資料庫的兼容性
開展測驗，并記錄缺陷，合理的安排調整測驗進度，提前獲取測驗所需的資源，建立管理體系（例如，需求變更、風險、配置、測驗檔案、缺陷報告、人力資源等內容），

定期評審，對測驗進行評估和總結，調整測驗的內容，

3、在搜索引擎中輸入漢字就可以決議到對應的域名，請問如何用LoadRunner進行測驗，

建立測驗計劃，確定測驗標準和測驗范圍
設計典型場景的測驗用例，覆寫常用業務流程和不常用的業務流程等
根據測驗用例，開發自動測驗腳本和場景：
錄制測驗腳本：新建一個腳本（Web/HTML協議）；點擊錄制按鈕，在彈出的對話框的URL中輸入”about:blank”；在打開的瀏覽器中進行正常操作流程后，結束錄制；除錯腳本并保存，可能要注意到字符集的關聯，

設定測驗場景：針對性能設定測驗場景，主要判斷在正常情況下，系統的平均事務回應時間是否達標；針對壓力負載設定測驗場景，主要判斷在長時間處于滿負荷或者超出系統承載能力的條件下，系統是否會崩潰；執行測驗，獲取測驗結果，分析測驗結果

4、問：一臺客戶端有三百個客戶與三百個客戶端有三百個客戶對服務器施壓，有什么區別?

300個用戶在一個客戶端上，會占用客戶機更多的資源，而影響測驗的結果，執行緒之間可能發生干擾，而產生一些例外，
300個用戶在一個客戶端上，需要更大的帶寬，
IP地址的問題，可能需要使用IP Spoof來繞過服務器對于單一IP地址最大連接數的限制，
所有用戶在一個客戶端上，不必考慮分布式管理的問題；而用戶分布在不同的客戶端上，需要考慮使用控制器來整體調配不同客戶機上的用戶，同時，還需要給予相應的權限配置和防火墻設定，
5、試述軟體的概念和特點？軟體復用的含義？構件包括哪些？

軟體是計算機系統中與硬體相互依存的另一部分，與計算機系統操作有關的計算機程式、規程、規則，以及可能有的檔案、檔案及資料，

軟體復用(SoftWare Reuse)是將已有軟體的各種有關知識用于建立新的軟體，以縮減軟體開發和維護的花費，軟體復用是提高軟體生產力和質量的一種重要技術，早期的軟體復用主要是代碼級復用，被復用的知識專指程式，后來擴大到包括領域知識、開發經驗、設計決定、體系結構、需求、設計、代碼和檔案等一切有關方面，

可以被復用的軟體成分一般稱作可復用構件

6、軟體生存周期及其模型是什么？

軟體生存周期（Software life cycle）又稱為軟體生命期，生存期，是指從形成開發軟體概念起，所開發的軟體使用以后，知道失去使用價值消亡為止的整個程序，一般來說，整個生存周期包括計劃（定義）、開發、運行（維護）三個時期，每個時期又劃分為若干個階段，每個階段有明確的任務，

周期模型（典型的幾種）：

瀑布模型
快速原型模型：快速原型模型允許在需求分析階段對軟體的需求進行初步而非完全的分析和定義，快速設計開發出軟體系統的原型，該原型向用戶展示待開發軟體的全部或部分功能和性能；用戶對該原型進行測驗評定，給出具體改進意見以豐富細化軟體需求；開發人員據此對軟體進行修改完善，直至用戶滿意認可之后，進行軟體的完整實作及測驗、維護，
迭代模型：迭代包括產生產品發布（穩定、可執行的產品版本）的全部開發活動和要使用該發布必需的所有其他外圍元素，在某種程度上，開發迭代是一次 完整地經過所有作業流程的程序：需求分析、設計、實施和測驗作業流程，實質上，它類似小型的瀑布式專案，RUP認為，所有的階段都可以細分為迭代，每一次 的迭代都會產生一個可以發布的產品，這個產品是最終產品的一個子集，
生命周期階段：

軟體計劃與可行性分析
需求分析
軟體設計
編碼
軟體測驗
運行與維護
7、什么是軟體測驗？軟體測驗的目的與原則

在規定的條件下對程式進行操作，以發現程式錯誤，衡量軟體質量，并對其是否能滿足設計要求進行評估的程序，

軟體測驗的目的：

測驗是程式的執行程序，目的在于發現錯誤
一個成功的測驗用例在于發現至今未發現的錯誤
一個成功的測驗是發現了至今未發現的錯誤的測驗
確保產品完成了它所承諾或公布的功能，并且用戶可以訪問到的功能都有明確的書面說明，
確保產品滿足性能和效率的要求
確保產品是健壯的和適應用戶環境的
軟體測驗的原則：

測驗用例中一個必須部分是對預期輸出或接過進行定義
程式員應避免測驗自己撰寫的程式
撰寫軟體的組織不應當測驗自己撰寫的軟體
應當徹底檢查每個測驗的執行結果
測驗用例的撰寫不僅應當根據有效和預料到的輸入情況，而且也應當根據無效和未預料到的輸入情況
檢擦程式是否“未做其應該做的”僅是測驗的一半，測驗的另一半是檢查程式是否“做了其不應該做的”
應避免測驗用例用后即棄，除非軟體本身就是個一次性的軟體
計劃測驗作業時不應默許假定不會發現錯誤
程式某部分存在更多錯誤的可能性，與該部分已經發現錯誤的數量成正比
軟體測驗是一項極富創造性，極具智力的挑戰性的作業
8、軟體配置管理的作用？軟體配置包括什么？

軟體配置管理（Software Configuration Management，SCM）是一種標識、組織和控制修改的技術，軟體配置管理應用于整個軟體工程程序，在軟體建立時變更是不可避免的，而變更加劇了專案中軟體開發者之間的混亂，SCM活動的目標就是為了標識變更、控制變更、確保變更正確實作并向其他有關人員報告變更，從某種角度講，SCM是一種標識、組織和控制修改的技術，目的是使錯誤降為最小并最有效地提高生產效率，

軟體配置包括如下內容：配置項識別、作業空間管理、版本控制、變更控制、狀態報告、配置審計

9、什么是軟體質量？

概括地說，軟體質量就是“軟體與明確的和隱含的定義的需求相一致的程度”，具體地說，軟體質量是軟體符合明確敘述的功能和性能需求、檔案中明確描述 的開發標準、以及所有專業開發的軟體都應具有的隱含特征的程度， 影響軟體質量的主要因素，這些因素是從管理角度對軟體質量的度量，可劃分為三組，分別反應用戶在使用軟體產品時的三種觀點，正確性、健壯性、效率、完整性、可用性、風險（產品運行）；可理解性、可維修性、靈活性、可測驗性（產品修改）；可移植性、可再用性、互運行性（產品轉移），

10、目前主要的測驗用例設計方法是什么？

白盒測驗：邏輯覆寫、回圈覆寫、基本路徑覆寫

黑盒測驗：邊界值分析法、等價類劃分、錯誤猜測法、因果圖法、狀態圖法、測驗大綱法、隨機測驗、場景法

11、軟體的安全性應從哪幾個方面去測驗？

軟體安全性測驗包括程式、資料庫安全性測驗，根據系統安全指標不同測驗策略也不同，

用戶認證安全的測驗要考慮問題： 明確區分系統中不同用戶權限 、系統中會不會出現用戶沖突 、系統會不會因用戶的權限的改變造成混亂 、用戶登陸密碼是否是可見、可復制 、是否可以通過絕對途徑登陸系統（拷貝用戶登陸后的鏈接直接進入系統）、用戶退出系統后是否洗掉了所有鑒權標記，是否可以使用后退鍵而不通過輸入口令進入 系統 、系統網路安全的測驗要考慮問題 、測驗采取的防護措施是否正確裝配好，有關系統的補丁是否打上 、模擬非授權攻擊，看防護系統是否堅固 、采用成熟的網路漏洞檢查工具檢查系統相關漏洞（即用最專業的黑客攻擊工具攻擊試一下，現在最常用的是 NBSI 系列和 IPhacker IP ） 、采用各種木馬檢查工具檢查系統木馬情況 、采用各種防外掛工具檢查系統各組程式的外掛漏洞
資料庫安全考慮問題： 系統資料是否機密（比如對銀行系統，這一點就特別重要，一般的網站就沒有太高要求）、系統資料的完整性（我剛剛結束的企業實名核查服務系統中就曾存在資料 的不完整，對于這個系統的功能實作有了障礙） 、系統資料可管理性 、系統資料的獨立性 、系統資料可備份和恢復能力（資料備份是否完整，可否恢復，恢復是否可以完整）
12、什么是測驗用例 什么是測驗腳本 兩者的關系是什么？

為實施測驗而向被測驗系統提供的輸入資料、操作或各種環境設定以及期望結果的一個特定的集合，

測驗腳本是為了進行自動化測驗而撰寫的腳本，

測驗腳本的撰寫必須對應相應的測驗用例

13、簡述什么是靜態測驗、動態測驗、黑盒測驗、白盒測驗、α測驗 β測驗

靜態測驗是不運行程式本身而尋找程式代碼中可能存在的錯誤或評估程式代碼的程序，
動態測驗是實際運行被測程式，輸入相應的測驗實體，檢查運行結果與預期結果的差異，判定執行結果是否符合要求，從而檢驗程式的正確性、可靠性和有效性，并分析系統運行效率和健壯性等性能，
黑盒測驗一般用來確認軟體功能的正確性和可操作性,目的是檢測軟體的各個功能是否能得以實作,把被測驗的程式當作一個黑盒,不考慮其內部結構,在知道該程式的輸入和輸出之間的關系或程式功能的情況下,依靠軟體規格說明書來確定測驗用例和推斷測驗結果的正確性，
白盒測驗根據軟體內部的邏輯結構分析來進行測驗,是基于代碼的測驗，測驗人員通過閱讀程式代碼或者通過使用開發工具中的單步除錯來判斷軟體的質量，一般黑盒測驗由專案經理在程式員開發中來實作，
α測驗是由一個用戶在開發環境下進行的測驗，也可以是公司內部的用戶在模擬實際操作環境下進行的受控測驗，Alpha測驗不能由程式員或測驗員完成，
β測驗是軟體的多個用戶在一個或多個用戶的實際使用環境下進行的測驗，開發者通常不在測驗現場，Beta測驗不能由程式員或測驗員完成，
14、軟體質量保證體系是什么 國家標準中與質量保證管理相關的幾個標準是什么?他們的編號和全稱是什么?

SQA由一套軟體工程程序和方法組成，以保證（軟體的）質量，SQA貫穿整個軟體開發程序，(它)應包括需求檔案評審、代碼控制、代碼評審、變更管理、配置管理、版本管理和軟體測驗，

軟體質量保證（SQA-Software Quality Assurance）是建立一套有計劃，有系統的方法，來向管理層保證擬定出的標準、步驟、實踐和方法能夠正確地被所有專案所采用，軟體質量保證的目的是使軟體程序對于管理人員來說是可見的，它通過對軟體產品和活動進行評審和審計來驗證軟體是合乎標準的，軟體質量保證組在專案開始時就一起參與建立計劃、標準和程序，這些將使軟體專案滿足機構方針的要求，

15、軟體產品質量特性是什么?

功能性：適應性、準確性、互操作性、依從性、安全性，

可靠性：成熟性、容錯性、易恢復性，

可使用性：易理解性、易學習性、易操作性，

效率：時間特性、資源特性，

可維護性：易分析性、易變更性、穩定性、易測驗性，

可移植性： 適應性、易安裝性、遵循性、易替換性

16、軟體測驗的策略是什么?

軟體測驗策略：在一定的軟體測驗標準、測驗規范的指導下，依據測驗專案的特定環境約束而規定的軟體測驗的原則、方式、方法的集合，

17、軟體測驗分為幾個階段 各階段的測驗策略和要求是什么?

和開發程序相對應，測驗程序會依次經歷單元測驗、集成測驗、系統測驗、驗收測驗四個主要階段：

單元測驗：單元測驗是針對軟體設計的最小單位––程式模塊甚至代碼段進行正確性檢驗的測驗作業，通常由開發人員進行，
集成測驗：集成測驗是將模塊按照設計要求組裝起來進行測驗，主要目的是發現與介面有關的問題，由于在產品提交到測驗部門前，產品開發小組都要進行聯合除錯，因此在大部分企業中集成測驗是由開發人員來完成的，
系統測驗：系統測驗是在集成測驗通過后進行的，目的是充分運行系統，驗證各子系統是否都能正常作業并完成設計的要求，它主要由測驗部門進行，是測驗部門最大最重要的一個測驗，對產品的質量有重大的影響，
驗收測驗：驗收測驗以需求階段的《需求規格說明書》為驗收標準，測驗時要求模擬實際用戶的運行環境，對于實際專案可以和客戶共同進行，對于產品來說就是最后一次的系統測驗，測驗內容為對功能模塊的全面測驗，尤其要進行檔案測驗，
單元測驗測驗策略：

自頂向下的單元測驗策略：比孤立單元測驗的成本高很多，不是單元測驗的一個好的選擇，

自底向上的單元測驗策略：比較合理的單元測驗策略，但測驗周期較長，

孤立單元測驗策略：最好的單元測驗策略，

集成測驗的測驗策略：

大爆炸集成：適應于一個維護型專案或被測驗系統較小

自頂向下集成：適應于產品控制結構比較清晰和穩定；高層介面變化較小；底層介面未定義或經常可能被修改；產口控制組件具有較大的技術風險，需要盡早被驗證；希望盡早能看到產品的系統功能行為，

自底向上集成：適應于底層介面比較穩定；高層介面變化比較頻繁；底層組件較早被完成，

基于進度的集成 優點：具有較高的并行度；能夠有效縮短專案的開發進度， 缺點：樁和驅動作業量較大；有些介面測驗不充分；有些測驗重復和浪費，

系統測驗的測驗策略：

資料和資料庫完整性測驗；功能測驗；用戶界面測驗；性能評測；負載測驗；強度測驗；容量測驗；安全性和訪問控制測驗；故障轉移和恢復測驗；配置測驗；安裝測驗；加密測驗；可用性測驗；版本驗證測驗；檔案測驗

18、軟體測驗各個階段通常完成什么作業？各個階段的結果檔案是什么？包括什么內容？

單元測驗階段：各獨立單元模塊在與系統地其他部分相隔離的情況下進行測驗，單元測驗針對每一個程式模塊進行正確性校驗，檢查各個程式模塊是否正確地實作了規定的功能，生成單元測驗報告，提交缺陷報告，

集成測驗階段：集成測驗是在單元測驗的基礎上，測驗在將所有的軟體單元按照概要設計規格說明的要求組裝成模塊、子系統或系統的程序中各部分作業是否達到或實作相應技術指標及要求的活動，該階段生成集成測驗報告，提交缺陷報告，

系統測驗階段：將通過確認測驗的軟體，作為整個給予計算機系統的一個元素，與計算機硬體、外設、某些支持軟體、資料和人員等其他系統元素結合在一起，在實際運行環境下，對計算機系統進行全面的功能覆寫，該階段需要提交測驗總結和缺陷報告，

19、測驗人員在軟體開發程序中的任務是什么？

1、盡可能早的找出系統中的Bug；
2、避免軟體開發程序中缺陷的出現；
3、衡量軟體的品質，保證系統的質量；
4、關注用戶的需求，并保證系統符合用戶需求，
總的目標是：確保軟體的質量，

20、在您以往的作業中，一條軟體缺陷（或者叫Bug）記錄都包含了哪些內容？如何提交高質量的軟體缺陷（Bug）記錄？

一條Bug記錄最基本應包含：

• bug編號；
• bug嚴重級別，優先級；
• bug產生的模塊；
• 首先要有bug摘要，闡述bug大體的內容；
• bug對應的版本；
• bug詳細現象描述，包括一些截圖、錄像…等等；
• bug出現時的測驗環境，產生的條件即對應操作步驟；

高質量的Bug記錄：

1. 通用UI要統一、準確
   缺陷報告的UI要與測驗的軟體UI保持一致，便于查找定位，
2. 盡量使用業界慣用的表達術語和表達方法
   使用業界慣用的表達術語和表達方法，保證表達準確，體現專業化，
3. 每條缺陷報告只包括一個缺陷
   每條缺陷報告只包括一個缺陷，可以使缺陷修正者迅速定位一個缺陷，集中精力每次只修正一個缺陷，校驗者每次只校驗一個缺陷是否已經正確修正，
4. 不可重現的缺陷也要報告
   首先缺陷報告必須展示重現缺陷的能力，不可重現的缺陷要盡力重現，若盡力之后仍不能重現，仍然要報告此缺陷，但在報告中要注明無法再現，缺陷出現的頻率，
5. 明確指明缺陷型別
   根據缺陷的現象，總結判斷缺陷的型別，例如，即功能缺陷、界面缺陷、資料缺陷，合理化建議這是最常見的缺陷或缺陷型別，其他形式的缺陷或缺陷也從屬于其中某種形式，
6. 明確指明缺陷嚴重等級和優先等級
   時刻明確嚴重等級和優先等級之間的差別，高嚴重問題可能不值得解決，小裝飾性問題可能被當作高優先級，
7. 描述 (Description) ，簡潔、準確，完整，揭示缺陷實質，記錄缺陷或缺陷出現的位置
   描述要準確反映缺陷的本質內容，簡短明了，為了便于在軟體缺陷管理資料庫中尋找制定的測驗缺陷，包含缺陷發生時的用戶界面（UI）是個良好的習慣，例如記錄對話框的標題、選單、按鈕等控制元件的名稱，
8. 短行之間使用自動數字序號，使用相同的字體、字號、行間距
   短行之間使用自動數字序號，使用相同的字體、字號、行間距，可以保證各條記錄格式一致，做到規范專業，
9. 每一個步驟盡量只記錄一個操作
   保證簡潔、條理井然，容易重復操作步驟，
10. 確認步驟完整，準確，簡短
    保證快速準確的重復缺陷，“完整”即沒有缺漏，“準確”即步驟正確，“簡短”即沒有多余的步驟，
11. 根據缺陷，可選擇是否進行圖象捕捉
    為了直觀的觀察缺陷或缺陷現象，通常需要附加缺陷或缺陷出現的界面，以圖片的形式作為附件附著在記錄的“附件”部分，為了節省空間，又能真實反映缺陷或缺陷本質，可以捕捉缺陷或缺陷產生時的全螢屏，活動視窗和區域區域，為了迅速定位、修正缺陷或缺陷位置，通常要求附加中文對照圖，
    ? 附加必要的特殊檔案和個人建議和注解
    如果打開某個特殊的檔案而產生的缺陷或缺陷，則必須附加該檔案，從而可以迅速再現缺陷或缺陷，有時，為了使缺陷或缺陷修正者進一步明確缺陷或缺陷的表現，可以附加個人的修改建議或注解，
12. 檢查拼寫和語法缺陷
    在提交每條缺陷或缺陷之前，檢查拼寫和語法，確保內容正確，正確的描述缺陷，
13. 盡量使用短語和短句，避免復雜句型句式
    軟體缺陷管理資料庫的目的是便于定位缺陷，因此，要求客觀的描述操作步驟，不需要修飾性的詞匯和復雜的句型，增強可讀性，
    以上概括了報告測驗缺陷的規范要求，隨著軟體的測驗要求不同，測驗者經過長期測驗，積累了相應的測驗經驗，將會逐漸養成良好的專業習慣，不斷補充新的規范書寫要求，此外，經常閱讀、學習其他測驗工程師的測驗缺陷報告，結合自己以前的測驗缺陷報告進行對比和思考，可以不斷提高技巧，
14. 缺陷描述內容
    缺陷描述的內容可以包含缺陷操作步驟，實際結果和期望結果，操作步驟可以方便開發人員再現缺陷進行修正，有些開發的再現缺陷能力很差，雖然他明白你所指的缺陷，但就是無法再現特別是對系統不熟悉的新加入開發人員，介紹步驟可以方便他們再現，實際結果可以讓開發明白錯誤是什么，期望結果可以讓開發了解正確的結果應該是如何，

21、黑盒測驗和白盒測驗是軟體測驗的兩種基本方法，請分別說明各自的優點和缺點！

• 黑盒測驗的優點有：比較簡單，不需要了解程式內部的代碼及實作；與軟體的內部實作無關； 從用戶角度出發，能很容易的知道用戶會用到哪些功能，會遇到哪些問題；基于軟體開發檔案，所以也能知道軟體實作了檔案中的哪些功能；在做軟體自動化測驗時較為方便，

• 黑盒測驗的缺點有：不可能覆寫所有的代碼，覆寫率較低，大概只能達到總代碼量的30%；自動化測驗的復用性較低，

• 白盒測驗的優點有：幫助軟體測驗人員增大代碼的覆寫率，提高代碼的質量，發現代碼中隱 藏的問題，

• 白盒測驗的缺點有：程式運行會有很多不同的路徑，不可能測驗所有的運行路徑；測驗基于代碼，只能測驗開發人員做的對不對，而不能知道設計的正確與否，可能會漏掉一些功能需求；系統龐大時，測驗開銷會非常大，

22、如何測驗一個紙杯？

• 功能度：用水杯裝水看漏不漏；水能不能被喝到

• 安全性：杯子有沒有毒或細菌

• 可靠性：杯子從不同高度落下的損壞程度

• 可移植性：杯子在不同的地方、溫度等環境下是否都可以正常使用

• 兼容性：杯子是否能夠容納果汁、白水、酒精、汽油等

• 易用性：杯子是否燙手、是否有防滑措施、是否方便飲用

• 用戶檔案：使用手冊是否對杯子的用法、限制、使用條件等有詳細描述

• 疲勞測驗：將杯子盛上水（案例一）放24小時檢查泄漏時間和情況；盛上汽油（案例二）放24小時檢查泄漏時間和情況等

• 壓力測驗：用根針并在針上面不斷加重量，看壓強多大時會穿透

22、測驗計劃作業的目的是什么？測驗計劃檔案的內容應該包括什么？其中哪些是最重要的？

軟體測驗計劃是指導測驗程序的綱領性檔案：

領導能夠根據測驗計劃進行宏觀調控，進行相應資源配置等
測驗人員能夠了解整個專案測驗情況以及專案測驗不同階段的所要進行的作業等
便于其他人員了解測驗人員的作業內容，進行有關配合作業
包含了產品概述、測驗策略、測驗方法、測驗區域、測驗配置、測驗周期、測驗資源、測驗交流、風險分析等內容，借助軟體測驗計劃，參與測驗的專案成員，尤其是測驗管理人員，可以明確測驗任務和測驗方法，保持測驗實施程序的順暢溝通，跟蹤和控制測驗進度，應對測驗程序中的各種變更，

測驗計劃撰寫6要素（5W1H）：

• why——為什么要進行這些測驗；
• what—測驗哪些方面，不同階段的作業內容；
• when—測驗不同階段的起止時間；
• where—相應檔案，缺陷的存放位置，測驗環境等；
• who—專案有關人員組成，安排哪些測驗人員進行測驗；
• how—如何去做，使用哪些測驗工具以及測驗方法進行測驗
• 測驗計劃和測驗詳細規格、測驗用例之間是戰略和戰術的關系，測驗計劃主要從宏觀上規劃測驗活動的范圍、方法和資源配置，而測驗詳細規格、測驗用例是完成測驗任務的具體戰術，所以其中最重要的是測驗測驗策略和測驗方法（最好是能先評審），

由于資料太多限于篇幅只放出22道題目

插一句

由于資料太多限于篇幅只放出22道題目，有需要全集的朋友可以加群領取
本人還整理了一些各大廠商的面試題和今年(2020)最新資料的收集，以下是部分資料截圖（所有資料均已整合成檔案，pdf壓縮打包處理），
如有有需要的朋友可以點擊這里來獲取資料，暗號：qf