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、關注用戶的需求，并保證系統符合用戶需求，
總的目標是：確保軟體的質量，
21、黑盒測驗和白盒測驗是軟體測驗的兩種基本方法，請分別說明各自的優點和缺點！ **
黑盒測驗的優點有：比較簡單，不需要了解程式內部的代碼及實作；與軟體的內部實作無關； 從用戶角度出發，能很容易的知道用戶會用到哪些功能，會遇到哪些問題；基于軟體開發檔案，所以也能知道軟體實作了檔案中的哪些功能；在做軟體自動化測驗時較為方便，
黑盒測驗的缺點有：不可能覆寫所有的代碼，覆寫率較低，大概只能達到總代碼量的30%；自動化測驗的復用性較低，
白盒測驗的優點有：幫助軟體測驗人員增大代碼的覆寫率，提高代碼的質量，發現代碼中隱 藏的問題，
白盒測驗的缺點有：程式運行會有很多不同的路徑，不可能測驗所有的運行路徑；測驗基于代碼，只能測驗開發人員做的對不對，而不能知道設計的正確與否，可能會漏掉一些功能需求；系統龐大時，測驗開銷會非常大，
22、如何測驗一個紙杯？
功能度：用水杯裝水看漏不漏；水能不能被喝到
安全性：杯子有沒有毒或細菌
可靠性：杯子從不同高度落下的損壞程度
可移植性：杯子在不同的地方、溫度等環境下是否都可以正常使用
兼容性：杯子是否能夠容納果汁、白水、酒精、汽油等
易用性：杯子是否燙手、是否有防滑措施、是否方便飲用
用戶檔案：使用手冊是否對杯子的用法、限制、使用條件等有詳細描述
疲勞測驗：將杯子盛上水（案例一）放24小時檢查泄漏時間和情況；盛上汽油（案例二）放24小時檢查泄漏時間和情況等
壓力測驗：用根針并在針上面不斷加重量，看壓強多大時會穿透
22、測驗計劃作業的目的是什么？測驗計劃檔案的內容應該包括什么？其中哪些是最重要的？
軟體測驗計劃是指導測驗程序的綱領性檔案：
領導能夠根據測驗計劃進行宏觀調控，進行相應資源配置等
測驗人員能夠了解整個專案測驗情況以及專案測驗不同階段的所要進行的作業等
便于其他人員了解測驗人員的作業內容，進行有關配合作業
包含了產品概述、測驗策略、測驗方法、測驗區域、測驗配置、測驗周期、測驗資源、測驗交流、風險分析等內容，借助軟體測驗計劃，參與測驗的專案成員，尤其是測驗管理人員，可以明確測驗任務和測驗方法，保持測驗實施程序的順暢溝通，跟蹤和控制測驗進度，應對測驗程序中的各種變更，
測驗計劃撰寫6要素（5W1H）：
why——為什么要進行這些測驗；
what—測驗哪些方面，不同階段的作業內容；
when—測驗不同階段的起止時間；
where—相應檔案，缺陷的存放位置，測驗環境等；
who—專案有關人員組成，安排哪些測驗人員進行測驗；
how—如何去做，使用哪些測驗工具以及測驗方法進行測驗
測驗計劃和測驗詳細規格、測驗用例之間是戰略和戰術的關系，測驗計劃主要從宏觀上規劃測驗活動的范圍、方法和資源配置，而測驗詳細規格、測驗用例是完成測驗任務的具體戰術，所以其中最重要的是測驗測驗策略和測驗方法（最好是能先評審），
23、黑盒測驗的測驗用例常見設計方法都有哪些？請分別以具體的例子來說明這些方法在測驗用例設計作業中的應用，
1）等價類劃分： 等價類是指某個輸入域的子集合.在該子集合中,各個輸入資料對于揭露程式中的錯誤都是等效的.并合理地假定:測驗某等價類的代表值就等于對這一類其它值的測驗.因此,可以把全部輸入資料合理劃分為若干等價類,在每一個等價類中取一個資料作為測驗的輸入條件,就可以用少量代表性的測驗資料.取得較好的測驗結果.等價類劃分可有兩種不同的情況:有效等價類和無效等價類.
2）邊界值分析法：是對等價類劃分方法的補充，測驗作業經驗告訴我,大量的錯誤是發生在輸入或輸出范圍的邊界上,而不是發生在輸入輸出范圍的內部.因此針對各種邊界情況設計測驗用例,可以查出更多的錯誤.
使用邊界值分析方法設計測驗用例,首先應確定邊界情況.通常輸入和輸出等價類的邊界,就是應著重測驗的邊界情況.應當選取正好等于,剛剛大于或剛剛小于邊界的值作為測驗資料,而不是選取等價類中的典型值或任意值作為測驗資料.
3）錯誤猜測法：基于經驗和直覺推測程式中所有可能存在的各種錯誤, 從而有針對性的設計測驗用例的方法.
錯誤推測方法的基本思想: 列舉出程式中所有可能有的錯誤和容易發生錯誤的特殊情況,根據他們選擇測驗用例. 例如, 在單元測驗時曾列出的許多在模塊中常見的錯誤. 以前產品測驗中曾經發現的錯誤等, 這些就是經驗的總結. 還有, 輸入資料和輸出資料為0的情況. 輸入表格為空格或輸入表格只有一行. 這些都是容易發生錯誤的情況. 可選擇這些情況下的例子作為測驗用例.
4）因果圖方法：前面介紹的等價類劃分方法和邊界值分析方法,都是著重考慮輸入條件,但未考慮輸入條件之間的聯系, 相互組合等. 考慮輸入條件之間的相互組合,可能會產生一些新的情況. 但要檢查輸入條件的組合不是一件容易的事情, 即使把所有輸入條件劃分成等價類,他們之間的組合情況也相當多. 因此必須考慮采用一種適合于描述對于多種條件的組合,相應產生多個動作的形式來考慮設計測驗用例. 這就需要利用因果圖（邏輯模型）. 因果圖方法最終生成的就是判定表. 它適合于檢查程式輸入條件的各種組合情況.
5）正交表分析法：可能因為大量的引數的組合而引起測驗用例數量上的激增，同時，這些測驗用例并沒有明顯的優先級上的差距，而測驗人員又無法完成這么多數量的測驗，就可以通過正交表來進行縮減一些用例，從而達到盡量少的用例覆寫盡量大的范圍的可能性，
6）場景分析方法：指根據用戶場景來模擬用戶的操作步驟，這個比較類似因果圖，但是可能執行的深度和可行性更好，
7）狀態圖法：通過輸入條件和系統需求說明得到被測系統的所有狀態，通過輸入條件和狀態得出輸出條件；通過輸入條件、輸出條件和狀態得出被測系統的測驗用例，
8）大綱法：大綱法是一種著眼于需求的方法，為了列出各種測驗條件，就將需求轉換為大綱的形式，大綱表示為樹狀結構，在根和每個葉子結點之間存在唯一的路徑，大綱中的每條路徑定義了一個特定的輸入條件集合，用于定義測驗用例，樹中葉子的數目或大綱中的路徑給出了測驗所有功能所需測驗用例的大致數量，
24、詳細的描述一個測驗活動完整的程序，（供參考，本答案主要是瀑布模型的做法）
專案經理通過和客戶的交流，完成需求檔案，由開發人員和測驗人員共同完成需求檔案的評審，評審的內容包括：需求描述不清楚的地方和可能有明顯沖突或者無法實作的功能的地方，專案經理通過綜合開發人員，測驗人員以及客戶的意見，完成專案計劃，然后SQA進入專案，開始進行統計和跟蹤
開發人員根據需求檔案完成需求分析檔案，測驗人員進行評審，評審的主要內容包括是否有遺漏或雙方理解不同的地方，測驗人員完成測驗計劃檔案，測驗計劃包括的內容上面有描述，
測驗人員根據修改好的需求分析檔案開始寫測驗用例，同時開發人員完成概要設計檔案，詳細設計檔案，此兩份檔案成為測驗人員撰寫測驗用例的補充材料，
測驗用例完成后，測驗和開發需要進行評審，
測驗人員搭建環境
開發人員提交第一個版本，可能存在未完成功能，需要說明，測驗人員進行測驗，發現BUG后提交給BugZilla，
開發提交第二個版本，包括Bug Fix以及增加了部分功能，測驗人員進行測驗，
重復上面的作業，一般是3-4個版本后BUG數量減少，達到出貨的要求，
如果有客戶反饋的問題，需要測驗人員協助重現并重新測驗，
26、BUG****管理工具的跟蹤程序（用BugZilla為例子）
測驗人員發現了BUG，提交到Bugzilla中，狀態為new，BUG的接受者為開發介面人員
開發介面將BUG分配給相關的模塊的開發人員，狀態修改為已分配，開發人員和測驗確認BUG，如果是本人的BUG，則設定為接收；如果是別的開發人員的問題，則轉發出去，由下一個開發人員來進行此行為；如果認為不是問題，則需要大家討論并確認后，拒絕這個BUG，然后測驗人員關閉此問題，
如果開發人員接受了BUG，并修改好以后，將BUG狀態修改為已修復，并告知測驗在哪個版本中可以測驗，
測驗人員在新版本中測驗，如果發現問題依然存在，則拒絕驗證；如果已經修復，則關閉BUG，
27、您認為在測驗人員同開發人員的溝通程序中，如何提高溝通的效率和改善溝通的效果？維持測驗人員同開發團隊中其他成員良好的人際關系的關鍵是什么？
盡量面對面的溝通，其次是能直接通過電話溝通，如果只能通過Email等非及時溝通工具的話，強調必須對特性的理解深刻以及能表達清楚，
運用一些測驗管理工具如TestDirector進行管理也是較有效的方法，同時要注意在TestDirector中對BUG有準確的描述，
在團隊中建立測驗人員與開發人員良好溝通中注意以下幾點：
一真誠、二是團隊精神、三是在專業上有共同語言、四是要對事不對人，作業至上
當然也可以通過直接指出一些小問題，而不是進入BUG Tracking System來增加對方的好感，
28、你對測驗最大的興趣在哪里？為什么？
回答這個面試題，沒有固定統一的答案，但可能是許多企業都會問到的，提供以下答案供考：
最大的興趣，感覺這是一個有挑戰性的作業；
測驗是一個經驗行業，作業越久越能感覺到做好測驗的難度和樂趣
通過自己的作業，能使軟體產品越來越完善，從中體會到樂趣
回答此類問題注意以下幾個方面：
盡可能的切合招聘企業的技術路線來表達你的興趣，例如該企業是資料庫應用的企業，那么表示你的興趣在資料庫的測驗，并且希望通過測驗提升自己的資料庫掌握能力，
表明你做測驗的目的是為了提升能力，也是為了更好的做好測驗；提升能力不是為了以后轉開發或其他的，除非用人企業有這樣的安排，
不要過多的表達你的興趣在招聘企業的范疇這外，比如招聘企業是做財務軟體的，可是你表現出來的是對游戲軟體的興趣；或招聘是做JAVA開發的，而你的興趣是在C類語言程式的開發，
29****、你自認為測驗的優勢在哪里？
該面試也沒有固定不變的答案，但可參考以下幾點，并結合自身特點：
有韌性、有耐心、做事有條理性、喜歡面對挑戰、有信心做好每一件事情、較強的溝通能力、從以前的經理處都得到了很好的評價表明我做的很好
33、簡述你在以前的作業中做過哪些事情，比較熟悉什么，參考答案如下，
我過去的主要作業是系統測驗和自動化測驗，在系統測驗中，主要是對BOSS系統的業務邏輯功能，以及軟交換系統的Class 5特性進行測驗，性能測驗中，主要是進行的壓力測驗，在各個不同數量請求的情況下，獲取系統回應時間以及系統資源消耗情況，自動化測驗主要是通過自己寫腳本以及一些第三方工具的結合來測驗軟交換的特性測驗，
在測驗中，我感覺對用戶需求的完全準確的理解非常重要，另外，就是對BUG的管理，要以需求為依據，并不是所有BUG均需要修改，
測驗作業需要耐心和細致，因為在新版本中，雖然多數原來發現的BUG得到了修復，但原來正確的功能也可能變得不正確，因此要注重迭代測驗和回歸測驗，
34、在C/C++中static有什么用途？（請至少說明兩種）
1)在函式體，一個被宣告為靜態的變數在這一函式被呼叫程序中維持其值不變，
在模塊內（但在函式體外），一個被宣告為靜態的變數可以被模塊內所用函式訪問，但不能被模塊外其它函式訪問，它是一個本地的全域變數，
在模塊內，一個被宣告為靜態的函式只可被這一模塊內的其它函式呼叫，那就是，這個函式被限制在宣告它的模塊的本地范圍內使用
35、參考與指標有什么區別？
- 參考必須被初始化，指標不必，
- 參考初始化以后不能被改變，指標可以改變所指的物件，
- 不存在指向空值的參考，但是存在指向空值的指標，
36、Internet采用哪種網路協議？該協議的主要層次結構？Internet物理地址和IP****地址轉換采用什么協議？
TCP/IP協議主要層次結構為： 應用層/傳輸層/網路層/數鏈路層，
ARP (Address Resolution Protocol)（地據址決議協議）
37、說說你對集成測驗中自頂向下集成和自底向上集成兩個策略的理解，要談出它們各自的優缺點和主要適應于哪種型別測驗；
自頂向下集成
優點：較早地驗證了主要控制和判斷點；按深度優先可以首先實作和驗證一個完整的軟體功能；功能較早證實，帶來信心；只需一個驅動，減少驅動器開發的費用；支持故障隔離，
缺點：柱的開發量大；底層驗證被推遲；底層組件測驗不充分，
適應于產品控制結構比較清晰和穩定；高層介面變化較小；底層介面未定義或經常可能被修改；產口控制組件具有較大的技術風險，需要盡早被驗證；希望盡早能看到產品的系統功能行為，
2、自底向上集成
優點：對底層組件行為較早驗證；作業最初可以并行集成，比自頂向下效率高；減少了樁的作業量；支持故障隔離，
缺點：驅動的開發作業量大；對高層的驗證被推遲，設計上的錯誤不能被及時發現，
適應于底層介面比較穩定；高層介面變化比較頻繁；底層組件較早被完成，
38、軟體驗收測驗包括正式驗收測驗、alpha測驗、beta測驗三種測驗，
39、系統測驗的策略有很多種的，有性能測驗、負載測驗、強度測驗、易用性測驗、安全測驗、配置測驗、安裝測驗、檔案測驗、故障恢復測驗、用戶界面測驗、恢復測驗、分布測驗、可用性測驗，
40、設計系統測驗計劃需要參考的專案檔案有軟體測驗計劃、軟體需求工件、和迭代計劃
41****．通過畫因果圖來寫測驗用例的步驟為****、、、****及把因果圖轉換為狀態圖共五個步驟， ****利用因果圖生成測驗用例的基本步驟是：
§ 分析軟體規格說明描述中，哪些是原因（即輸入條件或輸入條件的等價類），哪些是結果（即輸出條件），并給每個原因和結果賦予一個識別符號，
§ 分析軟體規格說明描述中的語意，找出原因與結果之間，原因與原因之間對應的是什么關系? 根據這些關系，畫出因果圖，
§ 由于語法或環境限制，有些原因與原因之間，原因與結果之間的組合情況不可能出現，為表明這些特殊情況，在因果圖上用一些記號標明約束或限制條件， § 把因果圖轉換成判定表，
§ 把判定表的每一列拿出來作為依據，設計測驗用例，
43、請說出這些測驗最好由那些人員完成，測驗的是什么？
代碼、函式級測驗一般由白盒測驗人員完成，他們針對每段代碼或函式進行正確性檢驗，檢查其是否正確的實作了規定的功能，
模塊、組件級測驗主要依據是程式結構設計測驗模塊間的集成和呼叫關系，一般由測驗人員完成，
系統測驗在于模塊測驗與單元測驗的基礎上進行測驗，了解系統功能與性能，根據測驗用例進行全面的測驗，
44、 ****設計測驗用例時應該考慮哪些方面，即不同的測驗用例針對那些方面進行測驗？
設計測驗用例時需要注意的是，除了對整體流程及功能注意外，還要注意強度測驗、性能測驗、壓力測驗、邊界值測驗、穩定性測驗、安全性測驗等多方面，（測驗用例需要考慮的四個基本要素是輸入、輸出、操作和測驗環境；另外，測驗用例需要考慮的是測驗型別（功能、性能、安全……），這部分可以參照TP做答，此外，還需要考慮用例的重要性和優先級）
45、 在windows****下保存一個文本檔案時會彈出保存對話框，如果為檔案名建立測驗用例，等價類應該怎樣劃分？
單位元組，如A；雙位元組， AA、我我；特殊字符 /‘，‘；、=-等；保留字，如com；檔案格式為8.3格式的；檔案名格式為非8.3格式的；/,*等九個特殊字符，
46、假設有一個文本框要求輸入10****個字符的郵政編碼，對于該文本框應該怎樣劃分等價類？
特殊字符，如10個*或￥；英文字母，如ABCDefghik；小于十個字符，如123；大于十個字符，如11111111111；數字和其他混合，如123AAAAAAA；空字符；保留字符
47.軟體測驗專案從什么時候開始，？為什么？ 軟體測驗應該在需求分析階段就介入,因為測驗的物件不僅僅是程式編碼,應該對軟體開發程序中產生的所有產品都測驗,并且軟體缺陷存在放大趨勢.缺陷發現的越晚,修復它所花費的成本就越大.
48.什么是回歸測驗?
回歸測驗: (regression testing): 回歸測驗有兩類：用例回歸和錯誤回歸；用例回歸是過一段時間以后再回頭對以前使用過的用例在重新進行測驗，看看會重新發現問題，錯誤回歸，就是在新版本中，對以前版本中出現并修復的缺陷進行再次驗證，并以缺陷為核心，對相關修改的部分進行測驗的方法，
**49.****單元測驗、集成測驗、系統測驗的側重點是什么？ **
單元測驗針對的是軟體設計的最小單元–程式模塊（面向程序中是函式、程序；面向物件中是類，）,進行正確性檢驗的測驗作業,在于發現每個程式模塊內部可能存在的差錯.一般有兩個步驟:人工靜態檢查\動態執行跟蹤
集成測驗針對的是通過了單元測驗的各個模塊所集成起來的組件進行檢驗,其主要內容是各個單元模塊之間的介面,以及各個模塊集成后所實作的功能.
系統測驗針對的是集成好的軟體系統，作為整個計算機系統的一個元素,與計算機硬體\外設\某些支持軟體\資料和人員等其他系統元素結合在一起,要在實際的運行環境中,對計算機系統進行一系列的集成測驗和確認測驗.
51.一個測驗工程師應具備那些素質？ 1、責任心2、溝通能力3、團隊合作精神4、耐心、細心、信心5、時時保持懷疑態度，并且有缺陷預防的意識6、具備一定的編程經驗
53.你所了解的的軟體測驗型別都有哪些，簡單介紹一下，
按測驗策略分類：1、靜態與動態測驗2、黑盒與白盒測驗 3、手工和自動測驗 4、冒煙測驗 5、回歸測驗；
按測驗階段分類：單元測驗、集成測驗、系統測驗；
其他常見測驗方法：1、功能測驗 2、性能測驗 3、壓力測驗 4、負載測驗 5、易用性測驗 6、安裝測驗 7、界面測驗 8、配置測驗 9、檔案測驗 10、兼容性測驗 11、安全性測驗 12、恢復測驗
54.你認為做好測驗計劃作業的關鍵是什么？
明確測驗的目標，增強測驗計劃的實用性
撰寫軟體測驗計劃得重要目的就是使測驗程序能夠發現更多的軟體缺陷，因此軟體測驗計劃的價值取決于它對幫助管理測驗專案，并且找出軟體潛在的缺陷，因此，軟體測驗計劃中的測驗范圍必須高度覆寫功能需求，測驗方法必須切實可行，測驗工具并且具有較高的實用性，便于使用，生成的測驗結果直觀、準確
堅持“5W”規則，明確內容與程序
“5W”規則指的是“What（做什么）”、“Why（為什么做）”、“When（何時做）”、“Where（在哪里）”、“How（如何做）”，利用“5W”規則創建軟體測驗計劃，可以幫助測驗團隊理解測驗的目的（Why），明確測驗的范圍和內容（What），確定測驗的開始和結束日期（When），指出測驗的方法和工具（How），給出測驗檔案和軟體的存放位置（Where），
采用評審和更新機制，保證測驗計劃滿足實際需求
測驗計劃寫作完成后，如果沒有經過評審，直接發送給測驗團隊，測驗計劃內容的可能不準確或遺漏測驗內容，或者軟體需求變更引起測驗范圍的增減，而測驗計劃的內容沒有及時更新，誤導測驗執行人員，
分別創建測驗計劃與測驗詳細規格、測驗用例
應把詳細的測驗技術指標包含到獨立創建的測驗詳細規格檔案，把用于指導測驗小組執行測驗程序的測驗用例放到獨立創建的測驗用例檔案或測驗用例管理資料庫中，測驗計劃和測驗詳細規格、測驗用例之間是戰略和戰術的關系，測驗計劃主要從宏觀上規劃測驗活動的范圍、方法和資源配置，而測驗詳細規格、測驗用例是完成測驗任務的具體戰術，
55.您認為做好測驗用例設計作業的關鍵是什么？
白盒測驗用例設計的關鍵是以較少的用例覆寫盡可能多的內部程式邏輯結果
黑盒法用例設計的關鍵同樣也是以較少的用例覆寫模塊輸出和輸入介面，不可能做到完全測驗，以最少的用例在合理的時間內發現最多的問題
56.你的測驗職業發展目標是什么？
測驗經驗越多，測驗能力越高，所以我的職業發展是需要時間累積的，一步步向著高級測驗工程師奔去，而且我也有初步的職業規劃，前3年累積測驗經驗，不斷的更新自己改正自己，做好測驗任務，
57.測驗結束的標準是什么？
從微觀上來說，在測驗計劃中定義，比如系統在一定性能下平穩運行72小時，目前Bug Tracking System中，本版本中沒有一般嚴重的BUG，普通BUG的數量在3以下，BUG修復率90%以上等等引數，然后由開發經理，測驗經理，專案經理共同簽字認同版本Release，
如果說宏觀的，則是當這個軟體徹底的消失以后，測驗就結束了，
59.一套完整的測驗應該由哪些階段組成？
可行性分析、需求分析、概要設計、詳細設計、編碼、單元測驗、集成測驗、系統測驗、驗收測驗
61.您是否了解以往所作業的企業的軟體開發程序？如果了解，請試述一個完整的開發程序需要完成哪些作業？分別由哪些不同的角色來完成這些作業？您在以往的測驗作業中都曾經具體從事過哪些作業？其中最擅長哪部分作業？
開發程序—需求調研（需求人員）、需求分析（需求人員）、概要設計（設計人員）、詳細設計(設計人員)、編碼（開發人員）
測驗程序—需求評審、系統測驗設計、概要設計評審、集成測驗設計、詳細設計評審、單元測驗設計、測驗執行
測驗作業的整個程序都做過，擅長做測驗設計
程序決定質量，軟體的程序改進正是為了提高軟體的質量，將過往的種種經驗教訓積累起來，
62.測驗用例設計的原則是什么？目前主要的測驗用例設計方法有哪些？
代表性：能夠代表并覆寫各種合理的和不合理、合法的和非法的、邊界的和越界的、以及極限的輸入資料、操作和環境設定等.
可判定性：即測驗執行結果的正確性是可判定的，每一個測驗用例都應有相應的期望結果.
可再現性：即對同樣的測驗用例，系統的執行結果應當是相同的，
方法有等價類、邊界值、因果圖、狀態圖、正交法、大綱法
63.面向物件的測驗用例設計有幾種方法？如何實作？
給類中的每個建構式設計一組測驗用例
組合類中的類變數、實體變數
組合類中的各種方法
根據前置條件和后置條件設計測驗用例
根據代碼設計測驗用例
64.LoadRunner****分為哪三個模塊？請簡述各模塊的主要功能，
Virtual User Generator：用于錄制腳步
Mercury LoadRunner Controller：用于創建、運行和監控場景
Mercury LoadRunner Analysis：用于分析測驗結果
65、你對測驗最大的興趣在哪里？為什么？
最大的興趣就是測驗有難度，有挑戰性！做測驗越久越能感覺到做好測驗有多難，曾經在無憂測驗網上看到一篇文章，是關于如何做好一名測驗工程師，一共羅列了11，12點，有部分是和人的性格有關，有部分需要后天的努力，但除了性格有關的1，2點我沒有把握，其他點我都很有信心做好它，
剛開始進入測驗行業時，對測驗的認識是從無憂測驗網上了解到的一些資料，當時是沖著做測驗需要很多技能才能做的好，雖然入門容易，但做好很難，比開發更難，雖然當時我很想做開發（學校專業課我基本上不缺席，因為我喜歡我的專業），但看到測驗比開發更難更有挑戰性，想做好測驗的意志就更堅定了，
我覺得做測驗整個程序中有2點讓我覺得很有難度（對我來說，有難度的東西我就非常感興趣），第一是測驗用例的設計，因為測驗的精華就在測驗用例的設計上了，要在版本出來之前，把用例寫好，用什么測驗方法寫？（也就是測驗計劃或測驗策略），如果你剛測驗一個新任務時，你得花一定的時間去消化業務需求和技識訓礎，業務需求很好理解（多和產品經理和開發人員溝通就能達到目的），而技識訓礎可就沒那么簡單了，這需要你自覺的學習能力，比如說網站吧，最基本的技術知識你要知道網站內部是怎么運作的的，后臺是怎么回應用戶請求的？測驗環境如何搭建？這些都需要最早的學好，至少在開始測驗之前能做好基本的準備，可能會遇到什么難題？需求細節是不是沒有確定好？這些問題都能在設計用例的時候發現，
第二是發現BUG的時候了，這應該是測驗人員最基本的任務了，一般按測驗用例開始測驗就能發現大部分的bug，還有一部分bug需要測驗的程序中更了解所測版本的情況獲得更多資訊，補充測驗用例，測驗出bug，還有如何發現bug？這就需要在測驗用例有效的情況下，通過細心和耐心去發現bug了，每個用例都有可能發現bug，每個地方都有可能出錯，所以測驗程序中思維要清晰（測驗程序資料流及結果都得看仔細了，bug都在里面發現的），如何描述bug也很有講究，bug在什么情況下會產生，如果條件變化一點點，就不會有這個bug，以哪些最少的操作步驟就能重現這個bug，這個bug產生的規律是什么？如果你夠厲害的話，可以幫開發人員初步定位問題，
66、您所熟悉的軟體測驗型別都有哪些？請試著分別比較這些不同的測驗型別的區別與聯系（如功能測驗、性能測驗……） 測驗型別有：功能測驗，性能測驗，界面測驗，
功能測驗在測驗作業中占的比例最大，功能測驗也叫黑盒測驗，是把測驗物件看作一個黑盒子，利用黑盒測驗法進行動態測驗時，需要測驗軟體產品的功能，不需測驗軟體產品的內部結構和處理程序，采用黑盒技術設計測驗用例的方法有：等價類劃分、邊界值分析、錯誤推測、因果圖和綜合策略，
性能測驗是通過自動化的測驗工具模擬多種正常、峰值以及例外負載條件來對系統的各項性能指標進行測驗，負載測驗和壓力測驗都屬于性能測驗，兩者可以結合進行，通過負載測驗，確定在各種作業負載下系統的性能，目標是測驗當負載逐漸增加時，系統各項性能指標的變化情況，壓力測驗是通過確定一個系統的瓶頸或者不能接收的性能點，來獲得系統能提供的最大服務級別的測驗，
界面測驗，界面是軟體與用戶互動的最直接的層，界面的好壞決定用戶對軟體的第一印象，而且設計良好的界面能夠引導用戶自己完成相應的操作，起到向導的作用，同時界面如同人的面孔，具有吸參考戶的直接優勢，設計合理的界面能給用戶帶來輕松愉悅的感受和成功的感覺，相反由于界面設計的失敗，讓用戶有挫敗感，再實用強大的功能都可能在用戶的畏懼與放棄中付諸東流，
區別在于，功能測驗關注產品的所有功能上，要考慮到每個細節功能，每個可能存在的功能問題，性能測驗主要關注于產品整體的多用戶并發下的穩定性和健壯性，界面測驗更關注于用戶體驗上，用戶使用該產品的時候是否易用，是否易懂，是否規范（快捷鍵之類的），是否美觀（能否吸參考戶的注意力），是否安全（盡量在前臺避免用戶無意輸入無效的資料，當然考慮到體驗性，不能太粗魯的彈出警告）？做某個性能測驗的時候，首先它可能是個功能點，首先要保證它的功能是沒問題的，然后再考慮該功能點的性能測驗
67、請試著比較一下黑盒測驗、白盒測驗、單元測驗、集成測驗、系統測驗、驗收測驗的區別與聯系， 黑盒測驗：已知產品的功能設計規格，可以進行測驗證明每個實作了的功能是否符合要求，
白盒測驗：已知產品的內部作業程序，可以通過測驗證明每種內部操作是否符合設計規格要求，所有內部成分是否以經過檢查，
軟體的黑盒測驗意味著測驗要在軟體的介面處進行，這種方法是把測驗物件看做一個黑盒子，測驗人員完全不考慮程式內部的邏輯結構和內部特性，只依據程式的需求規格說明書，檢查程式的功能是否符合它的功能說明，因此黑盒測驗又叫功能測驗或資料驅動測驗，黑盒測驗主要是為了發現以下幾類錯誤：
1、是否有不正確或遺漏的功能？2、在介面上，輸入是否能正確的接受？能否輸出正確的結果？3、是否有資料結構錯誤或外部資訊（例如資料檔案）訪問錯誤？4、性能上是否能夠滿足要求？5、是否有初始化或終止性錯誤？
軟體的白盒測驗是對軟體的程序性細節做細致的檢查，這種方法是把測驗物件看做一個打開的盒子，它允許測驗人員利用程式內部的邏輯結構及有關資訊，設計或選擇測驗用例，對程式所有邏輯路徑進行測驗，通過在不同點檢查程式狀態，確定實際狀態是否與預期的狀態一致，因此白盒測驗又稱為結構測驗或邏輯驅動測驗，白盒測驗主要是想對程式模塊進行如下檢查：
1、對程式模塊的所有獨立的執行路徑至少測驗一遍，
2、對所有的邏輯判定，取“真”與取“假”的兩種情況都能至少測一遍，
3、在回圈的邊界和運行的界限內執行回圈體，
4、測驗內部資料結構的有效性，等等，
單元測驗（模塊測驗）是開發者撰寫的一小段代碼，用于檢驗被測代碼的一個很小的、很明確的功能是否正確，通常而言，一個單元測驗是用于判斷某個特定條件（或者場景）下某個特定函式的行為，
單元測驗是由程式員自己來完成，最終受益的也是程式員自己，可以這么說，程式員有責任撰寫功能代碼，同時也就有責任為自己的代碼撰寫單元測驗，執行單元測驗，就是為了證明這段代碼的行為和我們期望的一致，
集成測驗（也叫組裝測驗，聯合測驗）是單元測驗的邏輯擴展，它的最簡單的形式是：兩個已經測驗過的單元組合成一個組件，并且測驗它們之間的介面，從這一層意義上講，組件是指多個單元的集成聚合，在現實方案中，許多單元組合成組件，而這些組件又聚合成程式的更大部分，方法是測驗片段的組合，并最終擴展行程，將您的模塊與其他組的模塊一起測驗，最后，將構成行程的所有模塊一起測驗，
系統測驗是將經過測驗的子系統裝配成一個完整系統來測驗，它是檢驗系統是否確實能提供系統方案說明書中指定功能的有效方法，（常見的聯調測驗）
系統測驗的目的是對最終軟體系統進行全面的測驗，確保最終軟體系統滿足產品需求并且遵循系統設計，
驗收測驗是部署軟體之前的最后一個測驗操作，驗收測驗的目的是確保軟體準備就緒，并且可以讓最終用戶將其用于執行軟體的既定功能和任務，
驗收測驗是向未來的用戶表明系統能夠像預定要求那樣作業，經集成測驗后，已經按照設計把所有的模塊組裝成一個完整的軟體系統，介面錯誤也已經基本排除了，接著就應該進一步驗證軟體的有效性，這就是驗收測驗的任務，即軟體的功能性能如同用戶所合理期待的那樣，
68、當開發人員說不是BUG****時，你如何應付？ 開發人員說不是bug，有2種情況，一是需求沒有確定，所以我可以這么做，這個時候可以找來產品經理進行確認，需不需要改動，3方商量確定好后再看要不要改，二是這種情況不可能發生，所以不需要修改，這個時候，我可以先盡可能的說出是BUG的依據是什么？如果被用戶發現或出了問題，會有什么不良結果？程式員可能會給你很多理由，你可以對他的解釋進行反駁，如果還是不行，那我可以給這個問題提出來,跟開發經理和測驗經理進行確認,如果要修改就改,如果不要修改就不改，其實有些真的不是bug，我也只是建議的方式寫進TD中，如果開發人員不修改也沒有大問題，如果確定是bug的話，一定要堅持自己的立場，讓問題得到最后的確認，
69、為什么要在一個團隊中開展軟體測驗作業？
因為沒有經過測驗的軟體很難在發布之前知道該軟體的質量，就好比ISO質量認證一樣，測驗同樣也需要質量的保證，這個時候就需要在團隊中開展軟體測驗的作業，在測驗的程序發現軟體中存在的問題，及時讓開發人員得知并修改問題，在即將發布時，從測驗報告中得出軟體的質量情況，
70、一份測驗計劃應該包括哪些內容？
背景、專案簡介、目的、測驗范圍、測驗策略、人員分工、資源要求、進度計劃、參考檔案、常用術語、提交檔案、風險分析，
在這里推薦一個軟體測驗交流群，QQ：642830685，會不定期的分享軟體測驗資源，測驗面試題以及測驗行業資訊，大家可以在群中積極交流，還有大佬為你答疑解惑，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/252498.html
標籤：其他
上一篇：資料庫詳解