引言：
大家好，我是 一菲，今天我們來通過問答的方式來聊聊測驗基礎知識有哪些？我總結了下面的68道問答題，自我感覺是比較全面的，不全的話，也歡迎小伙伴們私信我把它再補充一下，爭取成為最全的武功秘籍，因為這篇文章是滿滿的干貨，篇幅略長，大概要花15到20分鐘的時間才能看完，大家準備好了，誰堅持到最后誰就是王者，
正文：
1你在測驗中發現了一個 bug ，但是開發經理認為這不是一個 bug ，你應該怎樣解決，
首先，將問題提交到缺陷管理庫里面進行備案，
然后，要獲取判斷的依據和標準：
根據需求說明書、產品說明、設計檔案等，確認實際結果是否與計劃有不一致的地方，提供缺陷是否確認的直接依據；
如果沒有檔案依據，可以根據類似軟體的一般特性來說明是否存在不一致的地方，來確認是否是缺陷；
根據用戶的一般使用習慣，來確認是否是缺陷；
與設計人員、開發人員和客戶代表等相關人員探討，確認是否是缺陷；
合理的論述，向測驗經理說明自己的判斷的理由，注意客觀、嚴謹，不參雜個人情緒，
等待測驗經理做出最終決定，如果仍然存在爭議，可以通過公司政策所提供的渠道，向上級反映，并由上級做出決定，
2.給你一個網站，你如何測驗？
首先，查找需求說明、網站設計 m 等相關檔案，分析測驗需求，
制定測驗計劃，確定測驗范圍和測驗策略，一般包括以下幾個部分：
功能性測驗；界面測驗；性能測驗；資料庫測驗；安全性測驗；兼容性測驗
設計測驗用例：
功能性測驗可以包括，但不限于以下幾個方面：
鏈接測驗，鏈接是否正確跳轉，是否存在空頁面和無效頁面，是否有不正確的出錯資訊回傳等，
提交功能的測驗，
多媒體元素是否可以正確加載和顯示，
多語言支持是否能夠正確顯示選擇的語言等，
界面測驗可以包括但不限于一下幾個方面：
頁面是否風格統一，美觀
頁面布局是否合理，重點內容和熱點內容是否突出
控制元件是否正常使用
對于必須但為安裝的空間，是否提供自動下載并安裝的功能
文字檢查
性能測驗一般從以下兩個方面考慮：
壓力測驗；負載測驗；強度測驗
資料庫測驗要具體決定是否需要開展，資料庫一般需要考慮連結性，對資料的存取操作，資料內容的驗證等方面，
安全性測驗：
1 基本的登錄功能的檢查
2 是否存在溢位錯誤，導致系統崩潰或者權限泄露
3 相關開發語言的常見安全性問題檢查，例如 SQL 注入等，
4 如果需要高級的安全性測驗，確定獲得專業安全公司的幫助，外包測驗，或者獲取支持
兼容性測驗，根據需求說明的內容，確定支持的平臺組合：
瀏覽器的兼容性；作業系統的兼容性；軟體平臺的兼容性；資料庫的兼容性
開展測驗，并記錄缺陷，合理的安排調整測驗進度，提前獲取測驗所需的資源，建立管理體系（例如，需求變更、風險、配置、測驗檔案、缺陷報告、人力資源等內容），
定期評審，對測驗進行評估和總結，調整測驗的內容，
3.在搜索引擎中輸入漢字就可以決議 到對應的域名，請問如何用 LoadRunner 進行測驗，
建立測驗計劃，確定測驗標準和測驗范圍
設計典型場景的測驗用例，覆寫常用業務流程和不常用的業務流程等
根據測驗用例，開發自動測驗腳本和場景：
錄制測驗腳本
新建一個腳本（Web/HTML 協議）
點擊錄制按鈕，在彈出的對話框的 URL 中輸入”about:blank”，
在打開的瀏覽器中進行正常操作流程后，結束錄制，
除錯腳本并保存，可能要注意到字符集的關聯，
設定測驗場景
針對性能設定測驗場景，主要判斷在正常情況下，系統的平均事務回應時間是否達標
針對壓力負載設定測驗場景，主要判斷在長時間處于滿負荷或者超出系統承載能力的條件下，系統是否會崩潰，
執行測驗，獲取測驗結果，分析測驗結果
4.一臺客戶端有三百個客戶與三百個客戶端有三百個客戶對服務器施壓，有什么區別? ?
300 個用戶在一個客戶端上，會占用客戶機更多的資源，而影響測驗的結果，
執行緒之間可能發生干擾，而產生一些例外，
300 個用戶在一個客戶端上，需要更大的帶寬，
IP 地址的問題，可能需要使用 IP Spoof 來繞過服務器對于單一 IP 地址最大連接數的限制，
所有用戶在一個客戶端上，不必考慮分布式管理的問題；而用戶分布在不同的客戶端上，需要考慮使用控制器來整體調配不同客戶機上的用戶，同時，還需要給予相應的權限配置和防火墻設定，
5.試述軟體的概念和特點？軟體復用的含義？構件包括哪些？
軟體是計算機系統中與硬體相互依存的另一部分，它是包括程式、檔案的完整集合，
軟體復用(Software Reuse)是將已有軟體的各種有關知識用于建立新的軟體,以縮減軟體開發和維護的花費，軟體復用是提高軟體生產力和質量的一種重要技術，早期的軟體復用主要是代碼級復用，被復用的知識專指程式，后來擴大到包括領域知識、開發經驗、設計決定、體系結構、需求、設計、代碼和檔案等一切有關方面，
可以被復用的軟體成分一般稱作可復用構件
6.軟體生存周期及其模型是什么？
軟體生存周期是軟體開發全部程序、活動和任務的結構框架，是從可行性研究到需求分析、軟體設計、編碼、測驗、軟體發布維護的程序，
在經歷需求、分析、設計、實作、部署后，軟體將被使用并進入維護階段，直到最后由于缺少維護費用而逐漸消亡，這樣的一個程序，稱為"生命周期模型"（Life Cycle Model），
7.什么是軟體測驗？軟體測驗的目的與原則
使用人工或自動手段，來運行或測驗某個系統的程序，其目的在于檢驗它是否滿足規定的需求或弄清預期結果與實際結果之間的差別，
軟體測驗的目的：
測驗是程式的執行程序，目的在于發現錯誤
確保產品滿足用戶需求（功能，性能，兼容性等）
確保產品是健壯的和適應用戶環境的
軟體測驗的原則：
教材的說法：
軟體測驗應盡早執行，并貫穿于整個軟體生命周期
軟體測驗應追溯需求
測驗應由第三方來構造
窮舉測驗是不可能的,要遵循 Good-enough 原則
必須確定預期輸出（或結果）
必須徹底檢查每個測驗結果
關注缺陷的修復
8.軟體配置管理的作用？軟體配置包括什么？
軟體配置管理作為軟體開發程序的必要環節和軟體開發管理的基礎，貫穿整個軟體生命周期，同時對軟體開發程序的宏觀管理即專案管理也有重要的支持作用，一個軟體開發組織真正有效的實施軟體配置管理，將會使軟體開發程序有更好的可預測性，使系統具有可重復性，大大提高軟體組織的競爭力，
軟體配置包括如下內容：
配置項識別
作業空間管理
版本控制
變更控制
狀態報告
配置審計
9.什么是軟體質量？
軟體質量：軟體產品的特性可以滿足用戶的功能、性能需求的能力，
10.目前主要的測驗用例設計方法是什么？
白盒測驗：
邏輯覆寫
回圈覆寫
基本路徑覆寫
黑盒測驗：
邊界值分析法
等價類劃分
錯誤猜測法
因果圖法
狀態圖法
隨機測驗
場景法
11.軟體的安全性應從哪幾個方面 去測驗？
軟體安全性測驗包括程式、資料庫安全性測驗，根據系統安全指標不同測驗策略也不同，
用戶認證安全的測驗要考慮問題：
明確區分系統中不同用戶權限
系統中會不會出現用戶沖突
系統會不會因用戶的權限的改變造成混亂
用戶登陸密碼是否是可見、可復制
是否可以通過絕對途徑登陸系統（拷貝用戶登陸后的鏈接直接進入系統）
用戶退出系統后是否洗掉了所有鑒權標記，是否可以使用后退鍵而不通過輸入口令進入系統
系統網路安全的測驗要考慮問題
測驗采取的防護措施是否正確裝配好，有關系統的補丁是否打上
模擬非授權攻擊，看防護系統是否堅固
采用成熟的網路漏洞檢查工具檢查系統相關漏洞（即用最專業的黑客攻擊工具攻擊試一下，現在最常用的是 NBSI 系列和 IPhacker IP ）
采用各種木馬檢查工具檢查系統木馬情況
采用各種防外掛工具檢查系統各組程式的外掛漏洞
資料庫安全考慮問題：
系統資料是否機密（比如對銀行系統，這一點就特別重要，一般的網站就沒有太高要求）
系統資料的完整性
系統資料可管理性
系統資料的獨立性
系統資料可備份和恢復能力（資料備份是否完整，可否恢復，恢復是否可以完整）
12.什么是測驗用例 什么是測驗腳本 兩者的關系是什么？
為實施測驗而向被測驗系統提供的輸入資料、操作或各種環境設定以及期望結果的一個特定的集合，
測驗腳本是為了進行自動化測驗而撰寫的腳本，
測驗腳本的撰寫必須對應相應的測驗用例，
13.簡述什么是靜態測驗、動態測驗、黑盒測驗、白盒測驗、α測驗 β測驗
靜態測驗是不運行程式本身而尋找程式代碼中可能存在的錯誤或評估程式代碼的程序，
動態測驗是實際運行被測程式，輸入相應的測驗實體，檢查運行結果與預期結果的差異，判定執行結果是否符合要求，從而檢驗程式的正確性、可靠性和有效性，并分析系統運行效率和健壯性等性能，
黑盒測驗一般用來確認軟體功能的正確性和可操作性,目的是檢測軟體的各個功能是否能得以實作,把被測驗的程式當作一個黑盒,不考慮其內部結構,在知道該程式的輸入和輸出之間的關系或程式功能的情況下,依靠軟體規格說明書來確定測驗用例和推斷測驗結果的正確性，
白盒測驗根據軟體內部的邏輯結構分析來進行測驗,是基于代碼的測驗，測驗人員通過閱讀程式代碼或者通過使用開發工具中的單步除錯來判斷軟體的質量，一般黑盒測驗由專案經理在程式員開發中來實作，
α測驗是由一個用戶在開發環境下進行的測驗，也可以是公司內部的用戶在模擬實際操作環境下進行的受控測驗，Alpha 測驗不能由程式員或測驗員完成，
β測驗是軟體的多個用戶在一個或多個用戶的實際使用環境下進行的測驗，開發者通常不在測驗現場，Beta 測驗不能由程式員或測驗員完成，
14.軟體質量保證體系是什么 國家標準中與質量保證管理相關的幾個標準是什么? ? 他們的編號和全稱是什么? ?
SQA 由一套軟體工程程序和方法組成，以保證（軟體的）質量，SQA 貫穿整個軟體開發程序，(它)應包括需求檔案評審、代碼控制、代碼評審、變更管理、配置管理、版本管理和軟體測驗，
15.軟體產品質量特性是什么? ?
功能性：適應性、準確性、互操作性、依從性、安全性，
可靠性：成熟性、容錯性、以恢復性，
可使用性：易理解性、易學習性、易操作性，
效率：時間特性、資源特性，
可維護性：易分析性、易變更性、穩定性、易測驗性，
可移植性： 適應性、易安裝性、遵循性、易替換性，
16.軟體測驗的策略是什么? ?
軟體測驗策略：在一定的軟體測驗標準、測驗規范的指導下，依據測驗專案的特定環境約束而規定的軟體測驗的原則、方式、方法的集合，
17.軟體測驗分為幾個 階段 各階段的測驗策略和要求是什么? ?
軟體測驗按階段劃分可以分為單元測驗、集成測驗、系統測驗和<驗收測驗>（不一定有）幾個階段
單元測驗測驗策略：
自頂向下的單元測驗策略
總結：比孤立單元測驗的成本高很多，不是單元測驗的一個好的選擇，
自底向上的單元測驗策略
總結：比較合理的單元測驗策略，但測驗周期較長，
孤立單元測驗策略
總結：最好的單元測驗策略，
集成測驗的測驗策略：
大爆炸集成
適應于一個維護型專案或被測驗系統較小
自頂向下集成
適應于產品控制結構比較清晰和穩定；高層介面變化較小；底層介面未定義或經常可能被修改；產口控制組件具有較大的技術風險，需要盡早被驗證；希望盡早能看到產品的系統功能行為，
自底向上集成
適應于底層介面比較穩定；高層介面變化比較頻繁；底層組件較早被完成，
基于進度的集成
優點：具有較高的并行度；能夠有效縮短專案的開發進度，
缺點：樁和驅動作業量較大；有些介面測驗不充分；有些測驗重復和浪費，
系統測驗的測驗策略
資料和資料庫完整性測驗；功能測驗；用戶界面測驗；性能評測；負載測驗；強度測驗；容量測驗；安全性和訪問控制測驗；故障轉移和恢復測驗；配置測驗；安裝測驗；加密測驗；可用性測驗；版本驗證測驗；檔案測驗
18.在軟體測驗各個階段通常完成什么作業？各個階段的結果檔案是什么？包括什么內容？
單元測驗階段，各獨立單元模塊在與系統地其他部分相隔離的情況下進行測驗，單元測驗針對每一個程式模塊進行正確性校驗，檢查各個程式模塊是否正確地實作了規定的功能，
生成單元測驗報告，提交缺陷報告，
集成測驗階段，集成測驗是在單元測驗的基礎上，測驗在將所有的軟體單元按照概要設計規格說明的要求組裝成模塊、子系統或系統的程序中各部分作業是否達到或實作相應技術指標及要求的活動，
該階段生成集成測驗報告，提交缺陷報告，
系統測驗階段，將通過確認測驗的軟體，作為整個給予計算機系統的一個元素，與計算機硬體、外設、某些支持軟體、資料和人員等其他系統元素結合在一起，在實際運行環境下，對計算機系統進行全面的功能覆寫，該階段需要提交測驗總結和缺陷報告，
19.測驗人員在軟體開發程序中的任務是什么？
1、尋找 Bug；
2、避免軟體開發程序中的缺陷；
3、衡量軟體的品質；
4、關注用戶的需求，
總的目標是：確保軟體的質量，
20.在您以往的作業中，一條軟體缺陷（或者叫 Bug）記錄都包含了哪些內容？如何提交高質量的軟體缺陷（Bug）記錄？
一條 Bug 記錄最基本應包含：編號、Bug 所屬模塊、Bug 描述、Bug 級別、發現日期、發現人、修改日期、修改人、修改方法、回歸結果等等；
要有效的發現 Bug 需參考需求以及詳細設計等前期檔案設計出高效的測驗用例，然后嚴格執行測驗用例，對發現的問題要充分確認肯定，然后再向外發布如此才能提高提交 Bug 的質量，
21.黑盒測驗和白盒測驗是軟體測驗的兩種基本方法，請分別說明各自的優點和缺點！
黑盒測驗的優點有：
比較簡單，不需要了解程式內部的代碼及實作；
與軟體的內部實作無關；
從用戶角度出發，能很容易的知道用戶會用到哪些功能，會遇到哪些問題；
基于軟體開發檔案，所以也能知道軟體實作了檔案中的哪些功能；
在做軟體自動化測驗時較為方便，
黑盒測驗的缺點有：
不可能覆寫所有的代碼，覆寫率較低，大概只能達到總代碼量的 30%；
自動化測驗的復用性較低，
白盒測驗的優點有：
幫助軟體測驗人員增大代碼的覆寫率，提高代碼的質量，發現代碼中隱藏的問題，
白盒測驗的缺點有：
程式運行會有很多不同的路徑，不可能測驗所有的運行路徑；
測驗基于代碼，只能知道測驗開發人員做的對不對，而不能知道設計的正確與否，可能會漏掉一些功能需求；
系統龐大時，測驗開銷會非常大，
21.測驗計劃作業的目的是什么？測驗計劃檔案的內容應該包括什么？其中哪些是最重要的？
答案：軟體測驗計劃是指導測驗程序的綱領性檔案，
包含了產品概述、測驗策略、測驗方法、測驗區域、測驗配置、測驗周期、測驗資源、測驗交流、風險分析等內容，借助軟體測驗計劃，參與測驗的專案成員，尤其是測驗管理人員，可以明確測驗任務和測驗方法，保持測驗實施程序的順暢溝通，跟蹤和控制測驗進度，應對測驗程序中的各種變更，
測驗計劃和測驗詳細規格、測驗用例之間是戰略和戰術的關系，測驗計劃主要從宏觀上規劃測驗活動的范圍、方法和資源配置，而測驗詳細規格、測驗用例是完成測驗任務的具體戰術，
所以其中最重要的是測驗測驗策略和測驗方法（最好是能先評審），
22.黑盒測驗的測驗用例常見設計方法都有哪些？請分別以具體的例子來說明這些方法在測驗用例設計作業中的應用，
等價類劃分
劃分等價類: 等價類是指某個輸入域的子集合.在該子集合中,各個輸入資料對于揭露程式中的錯誤都是等效的.并合理地假定:測驗某等價類的代表值就等于對這一類其它值的測驗.
因此,可以把全部輸入資料合理劃分為若干等價類,在每一個等價類中取一個資料作為測驗的輸入條件,就可以用少量代表性的測驗資料.取得較好的測驗結果.等價類劃分可有兩種不同的情況:有效等價類和無效等價類.
邊界值分析法
邊界值分析方法是對等價類劃分方法的補充，測驗作業經驗告訴我,大量的錯誤是發生在輸入或輸出范圍的邊界上,而不是發生在輸入輸出范圍的內部.因此針對各種邊界情況設計測驗用例,可以查出更多的錯誤.
使用邊界值分析方法設計測驗用例,首先應確定邊界情況.通常輸入和輸出等價類的邊界,就是應著重測驗的邊界情況.應當選取正好等于,剛剛大于或剛剛小于邊界的值作為測驗資料,而不是選取等價類中的典型值或任意值作為測驗資料.
錯誤猜測法
基于經驗和直覺推測程式中所有可能存在的各種錯誤, 從而有針對性的設計測驗用例的方法.
錯誤推測方法的基本思想: 列舉出程式中所有可能有的錯誤和容易發生錯誤的特殊情況,根據他們選擇測驗用例. 例如, 在單元測驗時曾列出的許多在模塊中常見的錯誤. 以前產品測驗中曾經發現的錯誤等, 這些就是經驗的總結. 還有, 輸入資料和輸出資料為 0 的情況.輸入表格為空格或輸入表格只有一行. 這些都是容易發生錯誤的情況. 可選擇這些情況下的例子作為測驗用例.
因果圖方法
前面介紹的等價類劃分方法和邊界值分析方法,都是著重考慮輸入條件,但未考慮輸入條件之間的聯系, 相互組合等. 考慮輸入條件之間的相互組合,可能會產生一些新的情況. 但要檢查輸入條件的組合不是一件容易的事情, 即使把所有輸入條件劃分成等價類,他們之間的組合情況也相當多. 因此必須考慮采用一種適合于描述對于多種條件的組合,相應產生多個動作的形式來考慮設計測驗用例. 這就需要利用因果圖（邏輯模型）. 因果圖方法最終生成的就是判定表. 它適合于檢查程式輸入條件的各種組合情況.
正交表分析法
有時候，可能因為大量的引數的組合而引起測驗用例數量上的激增，同時，這些測驗用例并沒有明顯的優先級上的差距，而測驗人員又無法完成這么多數量的測驗，就可以通過正交表來進行縮減一些用例，從而達到盡量少的用例覆寫盡量大的范圍的可能性，
場景分析方法
指根據用戶場景來模擬用戶的操作步驟，這個比較類似因果圖，但是可能執行的深度和可行性更好，
狀態圖法
通過輸入條件和系統需求說明得到被測系統的所有狀態，通過輸入條件和狀態得出輸出條件；通過輸入條件、輸出條件和狀態得出被測系統的測驗用例，
23.詳細的描述一個測驗活動完整的程序，
專案經理通過和客戶的交流，完成需求檔案
由開發人員和測驗人員共同完成需求檔案的評審，評審的內容包括：需求描述不清楚的地方和可能有明顯沖突或者無法實作的功能的地方，
專案經理通過綜合開發人員，測驗人員以及客戶的意見，完成專案計劃，然后 SQA 進入專案，開始進行統計和跟蹤
開發人員根據需求檔案完成需求分析檔案，測驗人員進行評審，評審的主要內容包括是否有遺漏或者雙方理解不同的地方，
測驗人員完成測驗計劃檔案，測驗計劃包括的內容上面有描述，
測驗人員根據修改好的需求分析檔案開始寫測驗用例，同時開發人員完成概要設計檔案，詳細設計檔案，此兩份檔案成為測驗人員撰寫測驗用例的補充材料，
測驗用例完成后，測驗和開發需要進行評審，
測驗人員搭建環境
開發人員提交第一個版本，可能存在未完成功能，需要說明，測驗人員進行測驗，發現 BUG后提交給 BugZilla，
開發提交第二個版本，包括 Bug Fix 以及增加了部分功能，測驗人員進行測驗，
重復上面的作業，一般是 3-4 個版本后 BUG 數量減少，達到出貨的要求，
如果有客戶反饋的問題，需要測驗人員協助重現并重新測驗，
24.BUG 管理工具的跟蹤程序
用 BugZilla 為例子
測驗人員發現了 BUG，提交到 Bugzilla 中，狀態為 new，BUG 的接受者為開發介面人員
開發介面將 BUG 分配給相關的模塊的開發人員，狀態修改為已分配，開發人員和測驗確認BUG，如果是本人的 BUG，則設定為接收；如果是別的開發人員的問題，則轉發出去，由下一個開發人員來進行此行為；如果認為不是問題，則需要大家討論并確認后，拒絕這個 BUG，
然后測驗人員關閉此問題，
如果開發人員接受了 BUG，并修改好以后，將 BUG 狀態修改為已修復，并告知測驗在哪個版本中可以測驗，
測驗人員在新版本中測驗，如果發現問題依然存在，則拒絕驗證；如果已經修復，則關閉BUG，
25.您認為在測驗人員同開發人員的溝通程序中，如何提高溝通的效率和改善溝通的效果？維持測驗人員同開發團隊中其他成員 良好的人際關系的關鍵是什么？
盡量面對面的溝通，其次是能直接通過電話溝通，如果只能通過 Email 等非及時溝通工具的話，強調必須對特性的理解深刻以及能表達清楚，
運用一些測驗管理工具如 TestDirector 進行管理也是較有效的方法，同時要注意在TestDirector 中對 BUG 有準確的描述，
在團隊中建立測驗人員與開發人員良好溝通中注意以下幾點：
一真誠
二是團隊精神
三是在專業上有共同語言
四是要對事不對人，作業至上
當然也可以通過直接指出一些小問題，而不是進入 BUG Tracking System 來增加對方的好感，
26.你對測驗最大的興趣在哪里？為什么？
回答這個面試題，沒有固定統一的答案，但可能是許多企業都會問到的，提供以下答案供考：
最大的興趣，感覺這是一個有挑戰性的作業；
測驗是一個經驗行業，作業越久越能感覺到做好測驗的難度和樂趣
通過自己的作業，能使軟體產品越來越完善，從中體會到樂趣
回答此類問題注意以下幾個方面：
盡可能的切合招聘企業的技術路線來表達你的興趣，例如該企業是資料庫應用的企業，那么表示你的興趣在資料庫的測驗，并且希望通過測驗提升自己的資料庫掌握能力，
表明你做測驗的目的是為了提升能力，也是為了更好的做好測驗；提升能力不是為了以后轉開發或其他的，除非用人企業有這樣的安排，
不要過多的表達你的興趣在招聘企業的范疇這外，
27.你自認為測驗的優勢在哪里？
該面試也沒有固定不變的答案，但可參考以下幾點，并結合自身特點：
有韌性
有耐心
做事有條理性
喜歡面對挑戰
有信心做好每一件事情
較強的溝通能力
從以前的經理處都得到了很好的評價表明我做的很好
28.集成測驗通常都有那些策略？
1、大爆炸集成
2、自頂向下集成
3、自底向上集成
4、三明治集成適應于大部分軟體開發專案
5、基干集成
6、分層集成
7、基于功能的集成
8、基于訊息的集成
9、基于風險的集成
10、基于進度的集成
29.請你分別畫出 I OSI 的七層網路結構圖和 P TCP/IP 的四層結構圖，
OSI 七層網路結構圖，由上至下：
應用層 ；表示層 ;會話層 ;傳輸層 ;網路層 ;資料鏈路層;物理層
TCP/IP 的四層結構圖
應用層;傳輸層;互聯層;鏈路層
30.一個 e byte 幾個單位，( ( 計算機基礎) )
答：8bit，
31.常用 X UNIX 命令x (Linux 的常用命令) ) （至少 0 10 個）； (Unix)
答：ls pwd mkdir rmdir rm cp mv cd ps ping tail more echo adduser passwd logout exit，
32.簡述你在以前的作業中做過哪些事情，比較熟悉什么，
此問題每個人都不一樣，參考答案如下，
我過去的主要作業是系統測驗和自動化測驗，在系統測驗中，主要是對 BOSS 系統的業務邏輯功能，以及軟交換系統的 Class 5 特性進行測驗，性能測驗中，主要是進行的壓力測驗，在各個不同數量請求的情況下，獲取系統回應時間以及系統資源消耗情況，
自動化測驗主要是通過自己寫腳本以及一些第三方工具的結合來測驗軟交換的特性測驗，
在測驗中，我感覺對用戶需求的完全準確的理解非常重要，另外，就是對 BUG 的管理，要以需求為依據，并不是所有 BUG 均需要修改，
測驗作業需要耐心和細致，因為在新版本中，雖然多數原來發現的 BUG 得到了修復，但原來正確的功能也可能變得不正確，因此要注重迭代測驗和回歸測驗，
33.在 C/C++中 中 c static 有什么用途？（請至少說明兩種）
在函式體，一個被宣告為靜態的變數在這一函式被呼叫程序中維持其值不變，
在模塊內（但在函式體外），一個被宣告為靜態的變數可以被模塊內所用函式訪問，但不能被模塊外其它函式訪問，它是一個本地的全域變數，
在模塊內，一個被宣告為靜態的函式只可被這一模塊內的其它函式呼叫，那就是，這個函式被限制在宣告它的模塊的本地范圍內使用
34.參考與指標有什么區別？
參考必須被初始化，指標不必，
參考初始化以后不能被改變，指標可以改變所指的物件，
不存在指向空值的參考，但是存在指向空值的指標，
35.Internet 采用哪種網路協議？該協議的主要層次結構？t Internet 物理地址和 P IP 地址轉換采用什么協議？
TCP/IP 協議
主要層次結構為： 應用層/傳輸層/網路層/數鏈路層，
ARP (Address Resolution Protocol)（地址決議協議）
36.說說你對集成測驗中自頂向下集成和自底向上集成兩個策略的理解，要談出它們各自的優缺點和主要適應于哪種型別測驗；
自頂向下集成
優點：較早地驗證了主要控制和判斷點；按深度優先可以首先實作和驗證一個完整的軟體功能；功能較早證實，帶來信心；只需一個驅動，減少驅動器開發的費用；支持故障隔離，
缺點：柱的開發量大；底層驗證被推遲；底層組件測驗不充分，
適應于產品控制結構比較清晰和穩定；高層介面變化較小；底層介面未定義或經常可能被修改；產口控制組件具有較大的技術風險，需要盡早被驗證；希望盡早能看到產品的系統功能行為，
自底向上集成
優點：對底層組件行為較早驗證；作業最初可以并行集成，比自頂向下效率高；減少了樁的作業量；支持故障隔離，
缺點：驅動的開發作業量大；對高層的驗證被推遲，設計上的錯誤不能被及時發現，
適應于底層介面比較穩定；高層介面變化比較頻繁；底層組件較早被完成，
37.軟體驗收測驗包括正式驗收測驗、alpha 測驗、beta 測驗三種測驗，
38.系統測驗的策略有很多種的，有性能測驗、負載測驗、強度測驗、易用性測驗、安全測驗、配置測驗、安裝測驗、檔案測驗、故障恢復測驗、用戶界面測驗、恢復測驗、分布測驗、可用性測驗，
39.設計系統測驗計劃需要參考的專案檔案有軟體測驗計劃、軟體需求工件、和迭代計劃，
40.利用因果圖生成測驗用例的基本步驟是：
§ 分析軟體規格說明描述中，哪些是原因（即輸入條件或輸入條件的等價類），哪些是結果（即輸出條件），并給每個原因和結果賦予一個識別符號，
§ 分析軟體規格說明描述中的語意，找出原因與結果之間，原因與原因之間對應的是什么關系? 根據這些關系，畫出因果圖，
§ 由于語法或環境限制，有些原因與原因之間，原因與結果之間的組合情況不可能出現，為表明這些特殊情況，在因果圖上用一些記號標明約束或限制條件，
§ 把因果圖轉換成判定表，
§ 把判定表的每一列拿出來作為依據，設計測驗用例，
一、 測驗的種類很多，比如：
代碼、函式級測驗
模塊、組件級測驗
系統測驗
請說出這些測驗最好由那些人員完成，測驗的是什么？
代碼、函式級測驗一般由白盒測驗人員完成，他們針對每段代碼或函式進行正確性檢驗，檢查其是否正確的實作了規定的功能，
模塊、組件級測驗主要依據是程式結構設計測驗模塊間的集成和呼叫關系，一般由測驗人員完成，
系統測驗在于模塊測驗與單元測驗的基礎上進行測驗，了解系統功能與性能，根據測驗用例進行全面的測驗，
#看到這里眼睛有點酸痛的朋友們，可以去眨幾下眼睛，然后，接著看哈哈哈哈哈，你以為的結束只是剛剛開始罷了，
在這里推薦一個一菲自己創建的軟體測驗交流群，QQ：642830685，群中會不定期的分享軟體測驗資源，測驗面試題以及行業資訊等等，
41.設計測驗用例時應該考慮哪些方面，即不同的測驗用例針對那些方面進行測驗？
設計測驗用例時需要注意的是，除了對整體流程及功能注意外，還要注意強度測驗、性能測驗、壓力測驗、邊界值測驗、穩定性測驗、安全性測驗等多方面，（測驗用例需要考慮的四個基本要素是輸入、輸出、操作和測驗環境；另外，測驗用例需要考慮的是測驗型別（功能、性能、安全??），這部分可以參照 TP 做答，此外，還需要考慮用例的重要性和優先級）
42.在 windows 下保存一個文本檔案時會彈出保存對話框，如果為檔案名建立測驗用例，等價類應該怎樣劃分？
單位元組，如 A；
雙位元組， AA、我我；
特殊字符 /‘，‘；、=-等；
保留字，如 com；
檔案格式為 8.3 格式的；
檔案名格式為非 8.3 格式的；
/,*等九個特殊字符，
43.假設有一個文本框要求輸入 0 10 個字符的郵政編碼，對于該文本框應該怎 樣劃分等價類？
特殊字符，如 10 個*或￥；
英文字母，如 ABCDefghik；
小于十個字符，如 123；
大于十個字符，如 11111111111；
數字和其他混合，如 123AAAAAAA；
空字符；
保留字符
44.軟體測驗專案從什么時候開始，？為什么？
軟體測驗應該在需求分析階段就介入,因為測驗的物件不僅僅是程式編碼,應該對軟體開發程序中產生的所有產品都測驗,并且軟體缺陷存在放大趨勢.缺陷發現的越晚,修復它所花費的成本就越大.
45.什么是白盒測驗？什么是黑盒測驗? ? 什么是回歸測驗? ?
白盒測驗是測驗人員要了解程式結構和處理程序,按照程式內部邏輯測驗程式,檢查程式中的每條通路是否按照預定要求正確作業.它主要的針對被測程式的源代碼,測驗者可以完全不考慮程式的功能.
白盒測驗流程:詳細設計–>源程式–>分析程式內部邏輯結構–>流程圖–>制定測驗用例–>被測程式–>執行路徑–>覆寫情況分析 .
黑盒測驗:（Black-box Testing，又稱為功能測驗或資料驅動測驗）是把測驗物件看作一個黑盒子，利用黑盒測驗法進行動態測驗時，需要測驗軟體產品的功能，不需測驗軟體產品的內部結構和處理程序，
回歸測驗: (regression testing): 回歸測驗有兩類：用例回歸和錯誤回歸；用例回歸是過一段時間以后再回頭對以前使用過的用例在重新進行測驗，看看會重新發現問題，
錯誤回歸，就是在新版本中，對以前版本中出現并修復的缺陷進行再次驗證，并以缺陷為核心，對相關修改的部分進行測驗的方法，
46.單元測驗、集成測驗、系統測驗的側重點是什么？
單元測驗針對的是軟體設計的最小單元–程式模塊（面向程序中是函式、程序；面向物件中是類，）,進行正確性檢驗的測驗作業,在于發現每個程式模塊內部可能存在的差錯.一般有兩個步驟:人工靜態檢查\動態執行跟蹤
集成測驗針對的是通過了單元測驗的各個模塊所集成起來的組件進行檢驗,其主要內容是各個單元模塊之間的介面,以及各個模塊集成后所實作的功能.
系統測驗針對的是集成好的軟體系統，作為整個計算機系統的一個元素,與計算機硬體\外設\某些支持軟體\資料和人員等其他系統元素結合在一起,要在實際的運行環境中,對計算機系統進行一系列的集成測驗和確認測驗.
- 一個測驗工程師應具備那些素質？
1、責任心
2、溝通能力
3、團隊合作精神
4、耐心、細心、信心
5、時時保持懷疑態度，并且有缺陷預防的意識
6、具備一定的編程經驗
48.你所了解的的軟體測驗型別都有哪些，簡單介紹一下，
按測驗 策略分類：
1、靜態與動態測驗
2、黑盒與白盒測驗
3、手工和自動測驗
4、冒煙測驗
5、回歸測驗；
按測驗階段分類：單元測驗、集成測驗、系統測驗；
其他常見測驗方法：1、功能測驗 2、性能測驗 3、壓力測驗 4、負載測驗 5、易用性測驗 6、安裝測驗 7、界面測驗 8、配置測驗 9、檔案測驗 10、兼容性測驗 11、安全性測驗 12、恢復測驗
49.你認為做好測驗計劃作業的關鍵是什么？
明確測驗的目標，增強測驗計劃的實用性
采用評審和更新機制，保證測驗計劃滿足實際需求
分別創建測驗計劃與測驗詳細規格、測驗用例
50.您認為做好測驗用例設計作業的關鍵是什么？
白盒測驗用例設計的關鍵是以較少的用例覆寫盡可能多的內部程式邏輯結果
黑盒法用例設計的關鍵同樣也是以較少的用例覆寫模塊輸出和輸入介面，不可能做到完全測驗，以最少的用例在合理的時間內發現最多的問題
51.您認為性能測驗作業的目的是什么？做好性能測驗作業的關鍵是什么？
性能測驗的目的主要是發現在并發多用戶和大資料量操作時是否會出現與需求有差異的地方，
性能測驗作業的關鍵是做好系統分析和功能分析，確定系統瓶頸所在
52.在您以往的測驗作業中，最讓您感到不滿意或者不堪回首的事情是什么？您是如何來對待這些事情的？
53.你的測驗職業發展目標是什么？
測驗經驗越多，測驗能力越高，所以我的職業發展是需要時間累積的，一步步向著高級測驗工程師奔去，而且我也有初步的職業規劃，前 3 年累積測驗經驗，不斷的更新自己改正自己，做好測驗任務，
54.你對我們公司了解有多少？
建議從招聘廣告上多了解資訊，同時到應聘公司的網站上去盡可能多的了解這個公司的情況，以便回答好這類問題，
55.測驗結束的標準是什么？
從微觀上來說，在測驗計劃中定義，比如系統在一定性能下平穩運行 72 小時，目前 BugTracking System 中，本版本中沒有一般嚴重的 BUG，普通 BUG 的數量在 3 以下，BUG 修復率 90%以上等等引數，然后由開發經理，測驗經理，專案經理共同簽字認同版本 Release，
如果說宏觀的，則是當這個軟體徹底的消失以后，測驗就結束了，
- 軟體測驗分為黑盒和白盒，分別適合什么情況？ ？
軟體測驗方法一般分為兩種：白盒測驗與黑盒測驗，
白盒測驗又稱為結構測驗、邏輯驅動測驗或基于程式本身的測驗，它著重于程式的內部結構及演算法，通常不關心功能與性能指標；
黑盒測驗又被稱為功能測驗、資料驅動測驗或基于規格說明的測驗，它實際上是站在最終用戶的立場，檢驗輸入輸出資訊及系統性能指標是否符合規格說明書中有關功能需求及性能需求的規定，
57.一套完整的測驗應該由哪些階段組成？
可行性分析、需求分析、概要設計、詳細設計、編碼、單元測驗、集成測驗、系統測驗、驗收測驗
58.測驗用例通常包括那些內容？
不同結構的用例包括的不一樣，
（版本、編號、專案、設計人員、設計日期、輸入、預期輸出??）
軟體測驗用例的基本要素包括測驗用例編號、測驗標題、重要級別、測驗輸入、操作步驟、預期結果，
用例編號： 測驗用例的編號有一定的規則，比如系統測驗用例的編號這樣定義規則：PROJECT1-ST-001 ，命名規則是專案名稱＋測驗階段型別（系統測驗階段）＋編號，定義測驗用例編號，便于查找測驗用例，便于測驗用例的跟蹤，
測驗標題： 對測驗用例的描述，測驗用例標題應該清楚表達測驗用例的用途，比如 “ 測驗用戶登錄時輸入錯誤密碼時，軟體的回應情況 ” ，
重要級別： 定義測驗用例的優先級別，可以籠統的分為 “ 高 ” 和 “ 低 ” 兩個級別，
一般來說，如果軟體需求的優先級為 “ 高 ” ，那么針對該需求的測驗用例優先級也為“ 高 ” ；反之亦然，一般而言，是 5 級劃分，
測驗輸入： 提供測驗執行中的各種輸入條件，根據需求中的輸入條件，確定測驗用例的輸入，測驗用例的輸入對軟體需求當中的輸入有很大的依賴性，如果軟體需求中沒有很好的定義需求的輸入，那么測驗用例設計中會遇到很大的障礙，
操作步驟： 提供測驗執行程序的步驟，對于復雜的測驗用例，測驗用例的輸入需要分為幾個步驟完成，這部分內容在操作步驟中詳細列出，
預期結果： 提供測驗執行的預期結果，預期結果應該根據軟體需求中的輸出得出，如果在實際測驗程序中，得到的實際測驗結果與預期結果不符，那么測驗不通過；反之則測驗通過，
59.您是否了解以往所作業的企業的軟體開發程序？如果了解，請試述一個完整的開發程序需要完成哪些作業？分別由哪些不同的角色來完成這些作業？您在以往的測驗作業中都曾經具體從事過哪些作業？其中最擅長哪部分作業？
開發程序—需求調研（需求人員）、需求分析（需求人員）、概要設計（設計人員）、詳細設計(設計人員)、編碼（開發人員）
測驗程序—需求評審、系統測驗設計、概要設計評審、集成測驗設計、詳細設計評審、單元測驗設計、測驗執行
測驗作業的整個程序都做過，擅長做測驗設計
程序決定質量，軟體的程序改進正是為了提高軟體的質量，將過往的種種經驗和教訓積累起來，
60.在您所經歷的測驗活動中，參與人員有哪些？您所擔任的角色是什么？
有專案管理員、開發管理員、系統分析員、設計員、開發員、質量管理員、測驗管理員、測驗設計員、測驗員
擔任過測驗管理員、測驗設計員、測驗員
61.測驗用例設計的原則是什么？目前主要的測驗用例設計方法有哪些？
代表性：能夠代表并覆寫各種合理的和不合理、合法的和非法的、邊界的和越界的、以及極限的輸入資料、操作和環境設定等.
可判定性：即測驗執行結果的正確性是可判定的，每一個測驗用例都應有相應的期望結果.
可再現性：即對同樣的測驗用例，系統的執行結果應當是相同的，
方法有等價類、邊界值、因果圖、狀態圖、正交法、大綱法
61.LoadRunner 分為哪三個模塊？請簡述各模塊的主要功能，
Virtual User Generator：用于錄制腳步
Mercury LoadRunner Controller：用于創建、運行和監控場景
Mercury LoadRunner Analysis：用于分析測驗結果
62.你對測驗最大的興趣在哪里？為什么？
最大的興趣就是測驗有難度，有挑戰性！做測驗越久越能感覺到做好測驗有多難，曾經在無憂測驗網上看到一篇文章，是關于如何做好一名測驗工程師，一共羅列了 11，12 點，有部分是和人的性格有關，有部分需要后天的努力，但除了性格有關的 1，2 點我沒有把握，其他點我都很有信心做好它，剛開始進入測驗行業時，對測驗的認識是從無憂測驗網上了解到的一些資料，當時是沖著做測驗需要很多技能才能做的好，雖然入門容易，但做好很難，比開發更難，雖然當時我很想做開發（學校專業課我基本上不缺席，因為我喜歡我的專業），但看到測驗比開發更難更有挑戰性，想做好測驗的意志就更堅定了，
我覺得做測驗整個程序中有 2 點讓我覺得很有難度（對我來說，有難度的東西我就非常感興趣），第一是測驗用例的設計，因為測驗的精華就在測驗用例的設計上了，要在版本出來之前，把用例寫好，用什么測驗方法寫？（也就是測驗計劃或測驗策略），如果你剛測驗一個新任務時，你得花一定的時間去消化業務需求和技識訓礎，業務需求很好理解（多和產品經理和開發人員溝通就能達到目的），而技識訓礎可就沒那么簡單了，這需要你自覺的學習能力，比如說網站吧，最基本的技術知識你要知道網站內部是怎么運作的的，后臺是怎么回應用戶請求的？測驗環境如何搭建？這些都需要最早的學好，至少在開始測驗之前能做好基本的準備，可能會遇到什么難題？需求細節是不是沒有確定好？這些問題都能在設計用例的時候發現，
第二是發現 BUG 的時候了，這應該是測驗人員最基本的任務了，一般按測驗用例開始測驗就能發現大部分的 bug，還有一部分 bug 需要測驗的程序中更了解所測版本的情況獲得更多資訊，補充測驗用例，測驗出 bug，還有如何發現 bug？這就需要在測驗用例有效的情況下，通過細心和耐心去發現 bug 了，每個用例都有可能發現 bug，每個地方都有可能出錯，所以測驗程序中思維要清晰（測驗程序資料流及結果都得看仔細了，bug 都在里面發現的），如何描述 bug 也很有講究，bug 在什么情況下會產生，如果條件變化一點點，就不會有這個 bug，以哪些最少的操作步驟就能重現這個bug，這個bug產生的規律是什么？如果你夠厲害的話，可以幫開發人員初步定位問題，
63.當開發人員說不是 G BUG 時，你如何應付？
開發人員說不是 bug，有 2 種情況，
一是需求沒有確定，所以我可以這么做，這個時候可以找來產品經理進行確認，需不需要改動，3 方商量確定好后再看要不要改，
二是這種情況不可能發生，所以不需要修改，這個時候，我可以先盡可能的說出是 BUG 的依據是什么？
如果被用戶發現或出了問題，會有什么不良結果？程式員可能會給你很多理由，你可以對他的解釋進行反駁，如果還是不行，那我可以給這個問題提出來,跟開發經理和測驗經理進行確認,如果要修改就改,如果不要修改就不改，其實有些真的不是 bug，我也只是建議的方式寫進 TD 中，如果開發人員不修改也沒有大問題，如果確定是 bug 的話，一定要堅持自己的
立場，讓問題得到最后的確認，
64.為什么要在一個團隊中開展軟體測驗作業？
因為沒有經過測驗的軟體很難在發布之前知道該軟體的質量，就好比 ISO 質量認證一樣，測驗同樣也需要質量的保證，這個時候就需要在團隊中開展軟體測驗的作業，在測驗的程序發現軟體中存在的問題，及時讓開發人員得知并修改問題，在即將發布時，從測驗報告中得出軟體的質量情況，#####65.如果有機會轉成開發人員，你會去做開發作業嗎？
如果公司確實需要我可以從事開發，但我還是喜歡做測驗，我認為我更適合做測驗，
65.軟體測驗分哪些階段？各階段的含義？
分為單元測驗、集成測驗、確認測驗、系統測驗、驗收測驗，單元測驗是最小單位的測驗，測驗獨立模塊；
集成測驗主要測驗模塊之間的介面是否正常，
確認測驗類似于冒煙測驗通常在大規模系統測驗之前驗證版本主要功能是否實作，版本的穩定性是否可以進入系統測驗，
系統測驗是全面測驗驗證系統是否滿足用戶需求包括功能、性能、兼容性等等，
驗收測驗是用戶參與的測驗，
66.一份測驗計劃應該包括哪些內容？
背景、專案簡介、目的、測驗范圍、測驗策略、人員分工、資源要求、進度計劃、參考檔案、常用術語、提交檔案、風險分析，
67.什么是兼容性測驗？請舉例說明如何利用兼容性測驗串列進行測驗，
主要驗證軟體產品在不同版本之間的兼容性，包括向下兼容和交錯兼容，向下兼容是測驗軟體新版本保留它早期版本功能的情況，
交錯兼容是驗證共同存在的兩個相關但不相同的產品之間的兼容性，
68.對某軟體進行測驗，發現在 8 WIN98 上運行得很慢，怎么判別是該軟體存在問題還是其軟硬體運行環境存在問題？
看軟體的運行環境要求，如果符合要求則是程式存在問題，若不符合要求則是硬體系統存在問題
在這里推薦一個軟體測驗交流群，QQ：642830685，群中會不定期的分享軟體測驗資源，測驗面試題以及測驗行業資訊，大家可以在群中積極交流技術，還有大佬為你答疑解惑，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/251992.html
標籤：其他