以下是軟體測驗相關的面試題及答案，歡迎大家參考!

　1、你的測驗職業發展是什么?

　測驗經驗越多，測驗能力越高，所以我的職業發展是需要時間積累的，一步步向著高級測驗工程師奔去，而且我也有初步的職業規劃，前3年積累測驗經驗，按如何做好測驗工程師的要點去要求自己，不斷更新自己改正自己，做好測驗任務，

　2、你認為測驗人員需要具備哪些素質

　做測驗應該要有一定的協調能力，因為測驗人員經常要與開發接觸處理一些問題，如果處理不好的話會引起一些沖突，這樣的話作業上就會不好做，還有測驗人員要有一定的耐心，有的時候做測驗很枯燥乏味，除了耐心，測驗人員不能放過每一個可能的錯誤，

　3、你為什么能夠做測驗這一行

　雖然我的測驗技識訓不是很成熟，但是我覺得我還是可以勝任軟體測驗這個作業的，因為做軟體測驗不僅是要求技術好，還有有一定的溝通能力，耐心、細心等外在因素，綜合起來看我認為我是勝任這個作業的，

　4、測驗的目的是什么?

　測驗的目的是找出軟體產品中的錯誤，是軟體盡可能的符合用戶的要求，當然軟體測驗是不可能找出全部錯誤的，

　5、測驗分為哪幾個階段?

　一般來說分為5個階段：單元測驗、集成測驗、確認測驗、系統測驗、驗收測驗

　6、單元測驗的測驗物件、目的、測驗依據、測驗方法?

　測驗物件是模塊內部的程式錯誤，目的是消除區域模塊邏輯和功能上的錯誤和缺陷，測驗依據是模塊的詳細設計，測驗方法是采用白盒測驗，

　7、怎樣看待加班問題

　加班的話我沒有太多意見，但是我還是覺得如果能夠合理安排時間的話，不會有太多時候加班的，

　8、結合你以前的學習和作業經驗，你認為如何做好測驗，

　根據我以前的作業和學習經驗，我認為做好作業首先要有一個良好的溝通，只有溝通無障礙了，才會有好的協作，才會有更好的效率，再一個就是技術一定要過關，做測驗要有足夠的耐心，和一個良好的作業習慣，不懂的就要問，實時與同事溝通這樣的話才能做好測驗作業，

　9、你為什么選擇軟體測驗行業

　因為之前了解軟體測驗這個行業，覺得他的發展前景很好，

　10、根據你以前的作業或學習經驗描述一下軟體開發、測驗程序，由哪些角色負責，你做什么

　要有架構師、開發經理、測驗經理、程式員、測驗員，我在里面主要是負責所分到的模塊執行測驗用例，

　11、根據你的經驗說說你對軟體測驗/質量保證的理解

　軟體質量保證與測驗是根據軟體開發階段的規格說明和程式的內部結構而精心設計的一批測驗用例(即輸入資料和預期的輸出結果)，并根據這些測驗用例去運行程式，以發現錯誤的程序，它是對應用程式的各個方面進行測驗以檢查其功能、語言有效性及其外觀排布，

　12、軟體測驗的流程是什么?

　需求調查：全面了解系統概況、應用領域、軟體開發周期、軟體開發環境、開發組織、時間安排、功能需求、性能需求、質量需求及測驗要求等，根據系統概況進行專案所需的人員、時間和作業量估計以及專案報價，

　制定初步的專案計劃，

　測驗準備：組織測驗團隊、培訓、建立測驗和管理環境等，

　測驗設計：按照測驗要求進行每個測驗項的測驗設計，包括測驗用例的設計和測驗腳本的開發等，

　測驗實施：按照測驗計劃實施測驗，

　測驗評估：根據測驗的結果，出具測驗評估報告，

　13、你對SQA的職責和作業活動(如軟體度量)的理解?

　SQA就是獨立于軟體開發的專案組，通過對軟體開發程序的監控，來保證軟體的開發流程按照指定的CMM規程(如果有相應的CMM規程),對于不符合項及時提出建議和改進方案，必要時可以向高層經理匯報以求問題的解決，通過這樣的途徑來預防缺陷的引入，從而減少后期軟體的維護成本，SQA主要的作業活動包括制定SQA作業計劃，參與階段產物的評審，進行程序質量、功能配置及物理配置的審計等;對專案開發程序中產生的資料進行度量等等，

　14、說說你對軟體配置管理的理解

　專案在開發程序中要用相應的配置管理工具對配置項(包括各個階段的產物)進行變更控制，配置管理的使用取決于專案規模和復雜性及風險的水平，軟體的規模越大，配置管理就越顯得重要，還有在配置管理中，有一個很重要的概念，那就是基線，是在一定階段各個配置項的組合，一個基線就提供了一個正式的標準，隨后的作業便基于此標準，并只有經過授權后才能變更這個標準，配置管理工具主要有CC，VSS,CVS,SVN等，我只用過SVN，對其他的工具不是很熟悉，

　15、怎樣寫測驗計劃和測驗用例

　簡單點，測驗計劃里應有詳細的測驗策略和測驗方法，合理詳盡的資源安排等，至于測驗用例，那是依賴于需求(包括功能與非功能需求)是否細化到功能點，是否可測驗等，

　16、說說主流的軟體工程思想(如CMM、CMMI、RUP,XP,PSP,TSP等)的大致情況及對他們的理解

　CMM:SW Capability Maturity Model軟體能力成熟度模型，其作用是軟體程序的改進、評估及軟體能力的評鑒，

　CMMI:Capability Maturity Model Integration能力成熟度模型集成 CMMI融入了大部分最新的軟體管理實踐，同時彌補了SW-CMM模型中的缺陷，

　RUP:rational unified process是軟體工程話程序，

　XP:extreme program，即極限編程的意思，適用于小型團隊的軟體開發，像上面第三個問題就可以結合原型法采用這樣的開發流程，要明白測驗對于xp開發的重要性，強調測驗(重點是單元測驗)先行的理念，編程可以明顯提高代碼的質量，持續集成對于快速定位問題有好處，

　PSP，TSP分別是個體軟體程序和群體軟體程序，大家都知道，CMM只是告訴你做什么但并沒有告訴你如何做，所以PSP/TSP就是告訴你企業在實施CMM的程序中如何做，PSP強調建立個人技能(如何制定計劃、控制質量及如何與其他人相互協作等等)，而TSP著重于生產并交付高質量的軟體產品(如何有效的規劃和管理所面臨的專案開發任務等等)，總之，實施CMM，永遠不能真正做到能力成熟度的提升，只有將實施CMM與實施PSP和TSP有機結合起來，才能發揮最大的效力，因此，軟體程序框架應該是CMM/PSP/TSP的有機集成，

　17、你是怎樣保證軟體質量的，也就是說你覺得怎樣才能最大限度的保證軟體的質量?

　測驗并不能夠最大限度的保證軟體的質量，軟體的高質量是開發和設計出來的，而不是測驗出來的，它不僅要通過對軟體開發流程的監控，使得軟體開發的各個階段都要按照指定的規程進行，通過對各個階段產物的評審，QA對流程的監控，對功能及配置的審計來達到開發的最優化，當然測驗也是保證軟體質量的一個重要方式，是軟體質量保證工程的一個重要組成部分，

　18、基于目前中國的國情，大多數公司的專案進度緊張、人員較少、需求檔案根本沒有或者很不規范，你認為在這種情況下怎樣保證軟體的質量?(大多數公司最想知道的就是在這種困難面前你該怎么保證軟體的質量，因為這些公司一般就是這種情況--既不想投入過多又想保證質量)

　出現以上的情況，如果僅僅想通過測驗來提高軟體質量，那幾乎是不可能的，原因是沒有足夠的時間讓你去測驗，少而不規范的檔案導致測驗需求無法細化到足夠且有針對行的測驗，所以，作為公司質量保證的因該和專案經理確定符合專案本身是和的軟體生命周期模型(比如RUP的建材，原型法)，明確專案的開發流程并督促專案組按照此流程開展作業，所有專案組成員(專案經理更加重要)都要制定出合理的作業計劃，加強代碼的單元測驗，在客戶既定的產品交付日期范圍內，進行產品的持續集成等等，如果時間允許可以再配合客戶進行必要的系統功能測驗，

　19、一個測驗工程師應該具備哪些素質和技能?（1079636098）推薦軟體測驗技術交流Q群，

　1-掌味訓本的測驗基礎理論

　2-本著找出軟體存在的問題的態度進行測驗，不要以挑刺的形象出現

　3-可熟練閱讀需求規格說明書等檔案

　4-以用戶的觀點看問題

　5-有強烈的質量意識

　6-細心和責任心

　7-良好的有效的溝通方式(與開發人員及客戶)

　8-具有以往的測驗經驗能夠及時準確的判斷出高危險區在何處

　20、做好軟體測驗的一些關鍵點

　1-測驗人員必須經過測驗基礎知識和理論的相關培訓

　2-測驗人員必須熟悉系統功能和業務

　3-測驗要有計劃，而且測驗方案要和整個專案計劃協調好

　4-必須實作撰寫測驗用例，測驗執行階段必須根據測驗用例進行

　5-易用性，功能，分支，邊界，性能等功能行和非功能性需求都要進行測驗

　6-對于復雜的流程一定要進行流程分支，組合條件分析，再進行等價類劃分準備相關測驗資料

　7-測驗設計的一個重要內容是要準備好具體的測驗資料，清楚這個測驗資料是測驗那個場景或分支的，

　8-個人任務平均每三個測驗用例至少應該發現一個BUG，否則只能說明測驗用例質量不好

　9-除了每天構建的重復測驗可以考慮測驗自動化外，其他暫時都不要考慮去自動話

　21、軟體測驗員自身素質培養

　1-首先，應對軟體測驗感興趣和對自己有自信，如果具備了這兩點，那么在開發程序中不管遇到什么樣的困難，相信一定能克服

　2-善于懷疑，實際上沒有絕對正確的，總有錯誤的地方，具有叛逆心理，別人認為不可能發生的事情，我卻認為可能發生，別人認為是對的，我卻認為不是對的，

　3-打破沙鍋問到底的精神，對于只出現過一次的BUG一定要找出原因，不解決誓不罷休，

　4-保持一個良好的心情，否則可能無法把測驗做好，不要把生活中的不愉快的情緒帶到作業中來，

　5-做測驗時要細心，不是所有的BUG都能很容易找出，一定要細心才能找到這些BUG，

　6-靈活一些，聰明一點，多造一些容易產生BUG的例子，

　7-在有條件的情況下，多和客戶溝通，他們身上有你所需要的，

　8-設身處地為客戶著想，從他們的角度去測驗系統，

　9-不要讓程式員，以“這種情況不可能發生”這句話說服你，相反，你應該去說服他，告訴他在客戶心理，并不是這樣的

　10-考慮問題要全面，結合客戶的需求，業務流程和系統的架構等多方面考慮問題，

　11-提出問題不要復雜化，這點和前面矛盾，如果你是一個新手，暫時不要管這點，因為最終將有你的小組成員討論解決，

　12-追求完美，對于新測驗員來說，努力追求完美，這對你很好，盡管有些事情無法做到，但你應該嘗試，

　13-幽默感，能和開發小組很好的溝通是關鍵，試著給你的開發小組找一個BUG殺手，或對他們說“我簡直不敢相信，你寫的程式居然到現在沒有找到BUG”，

　22、為什要在一個團隊中開展測驗作業?

　因為沒有經過測驗的軟體很難在發布之前知道該軟體的質量，就好比ISO質量認證一樣，測驗同樣也需要質量認證，這個時候就需要在團隊中開展軟體測驗的作業，在測驗的程序中發現軟體中存在的問題，及時讓開發人員得知并修改問題，在即將發布時，從測驗報告中得出軟體的質量情況，

　23、你所熟悉的軟體測驗型別有哪些?

　測驗型別有：功能測驗、性能測驗、界面測驗

　功能測驗在測驗作業中占有比例最大，功能測驗也叫黑盒測驗，

　性能測驗是通過自動化的測驗工具模擬多種正常、峰值以及例外負載條件來對系統的各項性能指標進行測驗，負載測驗和壓力測驗都屬于性能測驗，兩者可以結合進行，

　界面測驗，界面是軟體與用戶互動的最直接的層，界面的好壞決定用戶對軟體的第一印象，

　區別在于，功能測驗關注產品的所有功能，要考慮到每個細節功能，每個可能存在的功能問題，性能測驗主要關注產品整體的多用戶并發下的穩定性和健壯性，界面測驗則關注與用戶體驗相關內容，用戶使用該產品的時候是否已用，是否易懂，是否規范(用戶無意輸入無效的資料，當然考慮到體驗性，不能太粗魯的彈出警告)，做某個性能測驗的時候，首先它可能是個功能點，首先要保證她的功能是沒有問題的，然后再考慮性能的問題，

　24、你認為做好測驗用例設計作業的關鍵是什么

　白盒測驗用例設計的關鍵是以較少的用例覆寫盡可能多的內部程式邏輯結構，黑盒測驗用例設計的關鍵同樣也是以較少的用例覆寫模塊輸出和輸入介面，不可能做到完全測驗，以最少的用例在合理的時間內發現最多的問題，軟體的黑盒測驗意味著測驗要在軟體的介面處進行，這種方法是把測驗物件看作是一個黑盒子，測驗人員完全不考慮程式內部的邏輯結構和內部特性，只依據程式的需求規格說明書，檢查程式的功能是否符合它的功能說明，因此黑盒測驗又叫功能測驗或者資料驅動測驗，黑盒測驗主要是為了發現以下幾類錯誤：、

　1-是否有不正確或遺漏的功能

　2-在介面上，輸入是否能正確的接受?能否輸出正確的結果，

　3-是否有資料結構錯誤或外部資訊(例如資料檔案)訪問錯誤

　4-性能上是否能夠滿足要求

　5-是否有初始化或終止性錯誤

　軟體的白盒測驗是對軟體的程序性細節做細致的檢查，這種方法是把測驗物件看作一個打開的盒子，它允許測驗人員利用程式內部的邏輯結構和有關資訊，設計或者選擇測驗用例，對程式所有邏輯路徑進行測驗，通過在不同點檢查程式狀態，確定實際狀態是否與預期的狀態一直，因此白盒測驗又稱為結合測驗或邏輯驅動測驗，白盒測驗主要是想對程式模塊進行如下檢查：

　1-對程式模塊的所有獨立的執行路徑至少測驗一遍，

　2-對所有的邏輯判定，取“真”與取“假”的兩種情況都能至少測一遍，

　3-在回圈的邊界和運行的界限內執行回圈體，

　4-測驗內部資料結構的有效性，等等，

　25、請詳細介紹一下各種測驗型別的含義

　1-單元測驗(模塊測驗)是開發者撰寫的一小段代碼，用于檢驗被測驗代碼的一個很小的、很明確的功能是否正確，通常而言，一個單元測驗是用于判斷某個特定條件(或者場景)下某個特定函式的行為，單元測驗是由程式員自己來完成，最終受益的也是程式員自己，可以這么說，程式員有責任撰寫功能代碼，同時也就有責任為自己的代碼撰寫單元測驗，執行單元測驗，就是為了證明這段代碼的行為和我們期望的一致，

　2-集成測驗(也叫組裝測驗、聯合測驗)是單元測驗的邏輯擴展，它最簡單的形式是：兩個已經經過測驗的單元組合成一個組件，并且測驗它們之間的介面，從這一層上講，組件是指多個單元的集成聚合，在現實方案中，許多單元組合成組件，而這些組件又聚合成程式的更大部分，方法是測驗片段的組合，并最終擴展行程，將您的模塊與其他組的模塊一起測驗，最后，將構成行程的所有模塊一起測驗，

　3-系統測驗是將經過測驗的子系統裝配成一個完整系統來測驗，它是檢驗系統是否確實能提供系統方案說明書中制定功能的有效方法，(常見的聯調測驗)，系統測驗的目的是對最終軟體系統進行全面的測驗，確保最終軟體系統滿足產品需求而遵循系統設計，

　4-驗收測驗是部署軟體之前的最后一個測驗操作，驗收測驗的目的是確保軟體準備就緒，并且可以讓用戶將其執行軟體的既定功能和任務，驗收測驗是向未來的用戶表明系統能夠像預訂要求那樣作業，經集成測驗后，已經按照設計把所有的模塊組裝成一個完整的軟體系統，介面錯誤也已經基本排除了，接著就應該進一步驗證軟體的有效性，這就是驗收測驗的任務，即軟體的功能和性能如同用戶所合理期待的那樣，

　26、測驗計劃作業的目的是什么?測驗計劃作業的內容都包括什么?其中哪些是最重要的?

　軟體測驗計劃是知道測驗程序的綱領性檔案，包含了產品概述、測驗策略、測驗方法、測驗區域、測驗配置、測驗周期、測驗資源、測驗交流、風險分析等內容，借助軟體測驗計劃，參與測驗的專案成員，尤其是測驗管理人員，可以明確測驗任務和測驗方法，保持測驗實施程序的順暢溝通，跟蹤和控制測驗進度，應對測驗程序中的各種變更，

　測驗計劃和測驗詳細規格、測驗用例之間是戰略和戰術的關系，測驗計劃主要從宏觀上規劃測驗活動的范圍、方法和資源配置，而測驗詳細規格、測驗用例是完成測驗任務的具體戰術，所以其中最重要的是測驗策略和測驗方法(最好能先評審)，

　27、您認為做好測驗計劃作業的關鍵是什么?

　1-明確測驗的目標，增強測驗計劃的實用性

　撰寫軟體測驗計劃的重要目的就是使測驗程序能夠發現更多的軟體缺陷，因此軟體測驗計劃的價值取決于它對幫助管理測驗專案，并且找出軟體潛在的缺陷，因此，軟體測驗計劃中的測驗范圍必須高度覆寫功能需求，測驗方法必須切實可行，測驗工具并且具有較高的實用性，便于使用，生成的測驗結果準確

　2-堅持“5W”規則，明確內容與程序

　“5W”規則指的是“WHAT(做什么)”、“WHY(為什么做)”、"WHEN(何時做)"、"WHERE(在哪里)"、"HOW(如何做)"，利用“5W"規則創建軟體測驗計劃，可以幫助測驗團隊理解測驗的目的(WHY)，明確測驗的范圍和內容(WHAT)，確定測驗的開始和結束日期(WHEN)，指出測驗的方法和工具(HOW)，給出測驗檔案和軟體存放的位置(WHERE)，

　3-采用評審和更新機制，保證測驗計劃滿足實際需求

　測驗計劃完成后，如果沒有經過評審，直接發送給測驗團隊，測驗計劃內容的可能不準確或遺漏測驗內容，或者軟體需求變更引起測驗范圍的增減，而測驗計劃的內容沒有及時更新，誤導測驗執行人員，

　4-分別創建測驗計劃與測驗詳細規格、測驗用例

　應把詳細的測驗技術指標包含到獨立創建的測驗詳細規格檔案，把用于指導測驗小組執行程序的測驗用例放到獨立創建的測驗用例檔案或測驗用例管理資料庫中，測驗計劃和測驗詳細規格、測驗用例之間是戰略和戰術的關系，測驗計劃主要從宏觀上規劃測驗活動的范圍、方法和資源配置，而測驗詳細規格、測驗用例是完成測驗任務的具體戰術，

　28、當開發人員說不是BUG時，你如何應付?

　開發人員說不是BUG，有2種情況，一是需求沒有確定，所以我可以這么做，這個時候可以找來產品經理進行確認，需不需要改動，3方商量確定好后再看要不要改，二是這種情況不可能發生，所以不需要修改，這個時候，我可以先盡可能的說出是BUG的一句是什么?如果被用戶發現或出了問題，會有什么不良結果?程式員可能會給你很多理由，你可以對他的解釋進行反駁，如果還是不行，那我可以給這個問題提出來，跟開發經理和測驗經理進行確認，如果要修改就改，如果不要修改就不改，其實有些真的不是BUG，我也只是建議的方式寫進測驗檔案中，如果開發人員不修改也沒有大問題，如果不是BUG的話，一定要堅持自己的立場，讓問題得到最后的確認，

　29、你自認為測驗的優勢在哪里?

　優勢在于我對測驗堅定不移的信心和熱情，雖然經驗還不足，但測驗需要的基本技能我有信心在作業中得以發揮，

　30、什么是系統瓶頸?

　瓶頸主要是指整個軟硬體構成的軟體系統某一方面或者幾個方面能力不能滿足用戶的特定業務要求，“特定”是指瓶頸會在某些條件下會出現，因為畢竟大多數系統在投入前，

　嚴格的從技術角度講，所有的系統都會有瓶頸，因為大多數系統的資源配置不是協調的，例如CPU使用率剛好達到100%時，記憶體也正好耗盡的系統不是很多見，因此我們討論系統瓶頸要從應用的角度討論：關鍵是看系統能否滿足用戶需求，在用戶極限使用系統的情況下，系統的回應仍然正常，我們可以認為改系統沒有瓶頸或者瓶頸不會影響用戶作業，

　因此我們測驗系統瓶頸主要是實作下面兩個目的：

　-發現“表面”的瓶頸，主要是模擬用戶的操作，找出用戶極限使用系統時的瓶頸，然后解決瓶頸，這是性能測驗的基本目標，

　-發現潛在的瓶頸并解決，保證系統的長期穩定性，主要是考慮用戶在將來擴展系統或者業務發生變化時，系統能夠適應變化，滿足用戶目前需求的系統不是最好的，我們設計系統的目標是在保證系統整個軟體生命周期能夠不斷適應用戶的變化，或者通過簡單擴展系統就可以適應新的變化，

　31、檔案測驗主要包含什么內容?

　在國內軟體開發管理中，檔案管理幾乎是最弱的一項，因而在測驗作業中特別容易忽略檔案測驗也就不足為奇了，要想給用戶提供完整的產品，檔案測驗是必不可少的，檔案測驗一般注重下面幾個方面：

　檔案的完整性：主要是測驗檔案內容的全面性與完整性，從總體上把握檔案的質量，例如用戶手冊應該包括軟體的所有功能模塊，

　描述與軟體實際情況的一致性：主要測驗軟體檔案與軟體實際的一致程度，例如用戶手冊基本完整后，我們還要注意用戶手冊與實際功能描述是否一致，因為檔案往往跟不上軟體版本的更新速度，

　易理解性：主要是檢查檔案對關鍵、重要的操作有無圖文說明，文字、圖表是否易于理解，對于關鍵、重要的操作僅僅只有文字說明肯定是不夠的，應該附有圖表使說明更為直觀和明了，

　檔案中提供操作的實體：這項檢查內容主要針對用戶手冊，對主要功能和關鍵操作提供的應用實體是否豐富，提供的實體描述是否詳細，只有簡單的圖文說明，而無實體的用戶手冊看起來就像是軟體界面的簡單拷貝，對于用戶來說，實際上沒有什么幫助，

　印刷與包裝質量：主要是檢查軟體檔案的商品化程度，有些用戶手冊是簡單列印、裝訂而成，過于粗糙，不易于用戶保存，優秀的檔案例如用戶手冊和技術白皮書，應提供商品化包裝，并且印刷精美，

　32、功能測驗用例需要詳細到什么程度才是合格的?

　這個問題也是測驗工程師經常問的問題，有人主張測驗用例詳細到每個步驟執行什么都要寫出來，目的是即使一個不了解系統的新手都可以按照測驗用例來執行作業，主張這類寫法的人還可以舉出例子：歐美、日本等軟體外包檔案都是這樣做的，

　另外一種觀點就是主張寫的粗些，類似于撰寫測驗大綱，主張這種觀點的人是因為軟體開發需求管理不規范，變動十分頻繁，因而不能按照歐美的高標準來撰寫測驗用例，這樣的測驗用例容易維護，可以讓測驗執行人員有更大的發揮空間，

　實際上，軟體測驗用例的詳細程度首先要以覆寫到測驗點為基本要求，舉個例子：“用戶登陸系統”的測驗用例可以不寫出具體的執行資料，但是至少要寫出五種以上情況()，如果只用一句話覆寫了這個功能是不合格的測驗用例，覆寫功能點不是指列出功能點，而是要寫出功能點的各個方面(如果組合情況較多時可以采用等價劃分)，

　另一個影響測驗用例的就是組織的開發能力和測驗物件特點，如果開發力量比較落后，撰寫較詳細的測驗用例是不現實的，因為根本沒有那么大的資源投入，當然這種情況很隨著團隊的發展而逐漸有所改善，測驗物件特點重點是指測驗物件在進度、成本等方面的要求，如果進度較緊張的情況下，是根本沒有時間寫出高質量的測驗用例的，甚至有些時候測驗作業只是一種輔助作業，因而不撰寫測驗用例，

　因此，測驗用例的撰寫要根據測驗物件特點、團隊的執行能力等各個方面綜合起來決定撰寫策略，最后要注意的是測驗人員一定不能抱怨，力爭在不斷提高測驗用例撰寫水平的同時，不斷地提高自身能力，

　33、配置和兼容性測驗的區別是什么?

　配置測驗的目的是保證軟體在其相關的硬體上能夠正常運行，而兼容性測驗主要是測驗軟體能否與不同的軟體正確協作，

　配置測驗的核心內容就是使用各種硬體來測驗軟體的運行情況，一般包括：

　(1)軟體在不同的主機上的運行情況，例如Dell和Apple;

　(2)軟體在不同的組件上的運行情況，例如開發的撥號程式要測驗在不同廠商生產的Modem上的運行情況;

　(3)不同的外設;

　(4)不同的介面;

　(5)不同的可選項，例如不同的記憶體大小;

　兼容性測驗的核心內容：

　(1)測驗軟體是否能在不同的作業系統平臺上兼容;

　(2)測驗軟體是否能在同一作業系統平臺的不同版本上兼容;

　(3)軟體本身能否向前或者向后兼容;

　(4)測驗軟體能否與其它相關的軟體兼容;

　(5)資料兼容性測驗，主要是指資料能否共享;

　配置和兼容性測驗通稱對開發系統類軟體比較重要，例如驅動程式、作業系統、資料庫管理系統等，具體進行時仍然按照測驗用例來執行，

　34、軟體檔案測驗主要包含什么?

　隨著軟體檔案系統日益龐大，檔案測驗已經成為軟體測驗的重要內容，檔案測驗物件主要如下：

　-包裝文字和圖形;

　-市場宣傳材料、廣告以及其它插頁;

　-授權、注冊登記表;

　-最終用戶許可協議;

　-安裝和設定向導;

　-用戶手冊;

　-聯機幫助;

　-樣例、示范例子和模板;

　-……

　檔案測驗的目的是提高易用性和可靠性，降低支持費用，因為用戶通過檔案就可以自己解決問題，因檔案測驗的檢查內容主要如下：

　-讀者物件——主要是檔案的內容是否能讓該級別的讀者理解;

　-術語——主要是檢查術語是否適合讀者;

　-內容和主題——檢查主題是否合適、是否丟失、格式是否規范等;

　-圖示和螢屏抓圖——檢查圖表的準確度和精確度;

　-樣例和示例——是否與軟體功能一致;

　-拼寫和語法;

　-檔案的關聯性——是否與其它相關檔案的內容一致，例如與廣告資訊是否一致;

　檔案測驗是相當重要的一項測驗作業，不但要給予充分的重視，更要要認真的完成，象做功能測驗一樣來對待檔案測驗，

　35、沒有產品說明書和需求檔案地情況下能夠進行黑盒測驗嗎?（1079636098）推薦軟體測驗技術交流Q群，

　這個問題是國內測驗工程師經常遇到的問題，根源就是國內軟體開發檔案管理不規范，對變更的管理方法就更不合理了，實際上沒有任何檔案的時候，測驗人員是能夠進行黑盒測驗的，這種測驗方式我們可以稱之為探索測驗，具體做法就是測驗工程師根據自己的專業技能、領域知識等不斷的深入了解測驗物件、理解軟體功能，進而發現缺陷，

　在這種做法基本上把軟體當成了產品說明書，測驗程序中要和開發人員不斷的進行交流，尤其在作專案的時候，進度壓力比較大，可以作為加急測驗方案，最大的風險是不知道有些特性是否被遺漏，

　36、測驗中的“殺蟲劑怪事”是指什么?

　“殺蟲劑怪事”一詞由BorisBeizer在其編著的《軟體測驗技術》第二版中提出，用于描述測驗人員對同一測驗物件進行的測驗次數越多，發現的缺陷就會越來越少的現象，就像老用一種農藥，害蟲就會有免疫力，農藥發揮不了效力，這種現象的根本原因就是測驗人員對測驗軟體過于熟悉，形成思維定勢，

　為了克服這種現象，測驗人員需要不斷撰寫新的測驗程式或者測驗用例，對程式的不同部分進行測驗，以發現更多的缺陷，也可以參考新人來測驗軟體，剛剛進來的新手往往能發現一些意想不到的問題，

　37、在配置測驗中，如何判斷發現的缺陷是普通問題還是特定的配置問題?

　在進行配置測驗時，測驗工程師仍然會發現一些普通的缺陷，也就是與配置環境無關的缺陷，因此判斷新發現的問題，需要在不同的配置中重新執行發現軟體缺陷的步驟，如果軟體缺陷不出現了，就可能是配置缺陷;如果在所有的配置中都出現，就可能是普通缺陷，

　需要注意的是，配置問題可以在一大類配置中出現，例如，撥號程式可能在所有的外置Modem中都存在問題，而內置的Modem不會有任何問題，

　38、為什么盡量不要讓時間有富裕的員工去做一些測驗?

　表面上看這體現了管理的效率和靈活性，但實際上也體現了管理者對測驗的輕視，測驗和測驗的人有很大關系，測驗作業人員應該是勤奮并富有耐心，善于學習、思考和發現問題，細心有條理，總結問題，如果具備這樣的優點，做其它作業同樣也會很出色，因此這里還有一個要求，就是要喜歡測驗這項作業，如果他是專職的，那么肯定更有經驗和信心，國內的小伙子好象都喜歡做程式員，兩者作業性質不同，待遇不同，地位不同，對自我實作的價值的認識也不同，這是行業的一個需要改善的問題，如果只是為了完成任務而完成任務，或者發現了幾個問題就覺得滿意了，這在任何其它作業中都是不行的，

　39、完全測驗程式是可能的嗎?

　軟體測驗初學者可能認為拿到軟體后需要進行完全測驗，找到全部的軟體缺陷，使軟體“零缺陷”發布，實際上完全測驗是不可能的，主要有以下一個原因：

　-完全測驗比較耗時，時間上不允許;

　-完全測驗通常意味著較多資源投入，這在現實中往往是行不通的;

　-輸入量太大，不能一一進行測驗;

　-輸出結果太多，只能分類進行驗證;

　-軟體實作途徑太多;

　-軟體產品說明書沒有客觀標準，從不同的角度看，軟體缺陷的標準不同;

　因此測驗的程度要根據實際情況確定，

　40、軟體測驗的風險主要體現在哪里?

　我們沒有對軟體進行完全測驗，實際就是選擇了風險，因為缺陷極有可能存在沒有進行測驗的部分，舉個例子，程式員為了方便，在除錯程式時會彈出一些提示資訊框，而這些提示只在某種條件下會彈出，碰巧程式發布前這些代碼中的一些沒有被注釋掉，在測驗時測驗工程師又沒有對其進行測驗，如果客戶碰到它，這將是代價昂貴的缺陷，因為交付后才被客戶發現，

　因此，我們要盡可能的選擇最合適的測驗量，把風險降低到最小，

　41、發現的缺陷越多，說明軟體缺陷越多嗎?

　這是一個比較常見的現象，測驗工程師在沒有找到缺陷前會絞盡腦汁的思考，但是找到一個后，會接二連三的發現很多缺陷，頗有個人成就感，其中的原因主要如下：

　-代碼復用、拷貝代碼導致程式員容易犯相同的錯誤，類的繼承導致所有的子類會包含基類的錯誤，反復拷貝同一代碼意味可能也復制了缺陷，

　-程式員比較勞累是可以導致某些連續撰寫的功能缺陷較多，程式員加班是一種司空見慣的現象，因此體力不只時容易撰寫一些缺陷較多的程式，而這些連續潛伏缺陷恰恰時測驗工程師大顯身手的地方，

　“缺陷一個連著一個”不是一個客觀規律，只是一個常見的現象，如果軟體撰寫的比較好，這種現象就不常見了，測驗人員只要嚴肅認真的測驗程式就可以了，

　42、所有的軟體缺陷都能修復嗎?所有的軟體缺陷都要修復嗎?

　從技術上講，所有的軟體缺陷都是能夠修復的，但是沒有必要修復所有的軟體缺陷，測驗人員要做的是能夠正確判斷什么時候不能追求軟體的完美，對于整個專案團隊，要做的是對每一個軟體缺陷進行取舍，根據風險決定那些缺陷要修復，發生這種現象的主要原因如下：

　-沒有足夠的時間資源，在任何一個專案中，通常情況下開發人員和測驗人員都是不夠用的，而且在專案中沒有預算足夠的回歸測驗時間，再加上修改缺陷可能引入新的缺陷，因此在交付期限的強大壓力下，必須放棄某些缺陷的修改，

　-有些缺陷只是特殊情況下出現，這種缺陷處于商業利益考慮，可以在以后升級中進行修復，

　-不是缺陷的缺陷，我們經常會碰到某些功能方面的問題被當成缺陷來處理，這類問題可以以后有時間時考慮再處理，

　最后要說的是，缺陷是否修改要由軟體測驗人員、專案經理、程式員共同討論來決定是否修復，不同角色的人員從不同的角度來思考，以做出正確的決定，

　43、軟體測驗人員就是QA嗎?

　軟體測驗人員的職責是盡可能早的找出軟體缺陷，確保得以修復，而質量保證人員(QA)主要職責是創建或者制定標準和方法，提高促進軟體開發能力和減少軟體缺陷，測驗人員的主要作業是測驗，質量保證人員日常作業重要內容是檢查與評審，測驗作業也是測驗保證人員的作業物件，

　軟體測驗和質量是相輔相成的關系，都是為了提高軟體質量而作業，

　44、如何減少測驗人員跳槽帶來的損失?

　在IT行業里跳槽已經是一種司空見慣的現象，而且跳槽無論給公司還是給個人都會帶來一定的損失，測驗隊伍也無疑會面臨跳槽的威脅，作為測驗經理管理者，只有從日常作業中開始做起，最能最大限度的減少損失，建議我們從以下兩個方面做起：

　-加強部門內員工之間的互相學習，互相學習是建立學習型組織的基本要求，是知識互相轉移的程序，在此基礎上，可以把個人擁有的技術以知識的形式沉積下來，也就完成了隱性知識到顯性知識的轉化，

　-通常情況下，企業能為員工提供足夠大的發展空間時，如果不是待遇特別低，員工都不會主動離開企業，因此我們要想留住員工，管理者就應該把員工的個人成長和企業的發展聯系起來，為員工設定合理發展規劃并付諸實作，不過這項要求做起來比較，要有比較好的企業文化為依托，

　45、測驗產品與測驗專案的區別是什么?

　習慣上把開發完成后進行商業化、幾乎不進行代碼修改就可以售給用戶使用的軟體成為軟體產品，也就是可以買“賣拷貝”的軟體，例如Windows2000，而通常把針對一個或者幾個特定的用戶而開發的軟體成為軟體專案，軟體專案是一種個性化的產品，可以是按照用戶要求全部重新開發，也可以修改已有的軟體產品來滿足特定的用戶需求，專案和產品的不同特點，決定我們測驗產品和測驗專案仍然會有很多不同的地方：

　-質量要求不同，通常產品的質量要高一些，修復發布后產品的缺陷成本較高，甚至會帶來很多負面的影響，而做專案通常面向某一用戶，雖然質量越高越好，但是一般只要滿足用戶要求就可以了，

　-測驗資源投入多少不同，做軟體產品通常是研發中心來開發，進度壓力要小些，同時由于質量要求高，因此會投入較多的人力、物力資源，

　-專案最后要和用戶共同驗收測驗，這是產品測驗不具有的特點，

　此外，測驗產品與測驗專案在缺陷管理方面、測驗策略制定都會有很大不同，測驗管理者應該結合具體的環境，恰如其分的完成作業，

　46、和用戶共同測驗(UAT測驗)的注意點有哪些?

　軟體產品在投產前，通常都會進行用戶驗收測驗，如果用戶驗收測驗沒有通過，直接結果就是那不到“Money”，間接影響是損害了公司的形象，而后者的影響往往更嚴重，根據作者的經驗，用戶驗收測驗一定要讓用戶滿意，

　實際上用戶現場測驗更趨于是一種演示，在不欺騙用戶的前提下，我們向用戶展示我們軟體的優點，最后讓“上帝”滿意并欣然掏出“銀子”才是我們的目標，因此用戶測驗要注意下面的事項：

　(1)用戶現場測驗不可能測驗全部功能，因此要測驗核心功能，這需要提前做好準備，這些核心功能一定要預先經過測驗，證明沒有問題才可以和用戶共同進行測驗，測驗核心模塊的目的是建立用戶對軟體的信心，當然如果這些模塊如果問題較多，不應該進行演示，

　(2)如果某些模塊確實有問題，我們可以演示其它重要的業務功能模塊，必要時要向用戶做成合理的解釋，爭得時間后，及時修改缺陷來彌補，

　(3)永遠不能欺騙用戶，蒙混過關，道理很簡單，因為軟體是要給用戶用的，問題早晚會暴露出來，除非你可以馬上修改，

　和用戶進行測驗還要注意各種交流技巧，爭取不但短期利益得到了滿足，還要為后面得合作打好基礎，

　47、如何撰寫提交給用戶的測驗報告?（1079636098）推薦軟體測驗技術交流Q群，

　隨著測驗作業越來越受重視，開發團隊向客戶提供測驗檔案是不可避免的事情，很多人會問：“我們可以把作業中的測驗報告提供給客戶嗎?”答案是否定的，因為提供內部測驗報告，可能會讓客戶失去信心，甚至否定專案，

　測驗報告一般分為內部測驗報告和外部測驗報告，內部報告是我們在測驗作業中的專案檔案，反映了測驗作業的實施情況，這里不過多討論，讀者可以參考相關教材，這里主要討論一下外部測驗報告的寫法，一般外部測驗報告要滿足下面幾個要求：

　-根據內部測驗報告進行撰寫，一般可以摘錄;

　-不可以向客戶報告嚴重缺陷，即使是已經修改的缺陷，開發中的缺陷也沒有必要讓客戶知道;

　-報告上可以列出一些缺陷，但必須是中級的缺陷，而且這些缺陷必須是修復的;

　-報告上面的內容盡量要真實可靠;

　-整個測驗報告要仔細審閱，力爭不給專案帶來負面作用，尤其是性能測驗報告，

　總之，外部測驗報告要小心謹慎的撰寫，

　48、測驗工具在測驗作業中是什么地位?

　國內的很多測驗工程師對測驗工具相當迷戀，尤其是一些新手，甚至期望測驗工具可以取代手工測驗，測驗工具在測驗作業中起的是輔助作用，一般用來提高測驗效率，自動化測驗彌補了手工測驗的不足，減輕一定的作業量，實際上測驗工具是無法替代大多數手工測驗的，而一些諸如性能測驗等自動化測驗也是手工所不能完成的，

　對于自動測驗技術，應當依據軟體的不同情況來分別對待，一般自動技識訓應用在引起大量重復性作業的地方、系統的壓力點、以及任何適合使用程式解決大批量輸入資料的地方，然后再尋找合適的自動測驗工具，或者自己開發測驗程式，一定不要為了使用測驗工具而使用，

　49、常見的測驗用例設計方法都有哪些?請分別以具體的例子來說明這些方法在測驗用例設計作業中的應用，

　1-等價類劃分

　常見的軟體測驗面試題劃分等價類: 等價類是指某個輸入域的子集合.在該子集合中,各個輸入資料對于揭露程式中的錯誤都是等效的.并合理地假定:測驗某等價類的代表值就等于對這一類其它值的測驗.因此,可以把全部輸入資料合理劃分為若干等價類,在每一個等價類中取一個資料作為測驗的輸入條件,就可以用少量代表性的測驗資料.取得較好的測驗結果.等價類劃分可有兩種不同的情況:有效等價類和無效等價類.

　2-邊界值分析法

　邊界值分析方法是對等價類劃分方法的補充，測驗作業經驗告訴我,大量的錯誤是發生在輸入或輸出范圍的邊界上,而不是發生在輸入輸出范圍的內部.因此針對各種邊界情況設計測驗用例,可以查出更多的錯誤.

　使用邊界值分析方法設計測驗用例,首先應確定邊界情況.通常輸入和輸出等價類的邊界,就是應著重測驗的邊界情況.應當選取正好等于,剛剛大于或剛剛小于邊界的值作為測驗資料,而不是選取等價類中的典型值或任意值作為測驗資料.

　3-錯誤推測法

　基于經驗和直覺推測程式中所有可能存在的各種錯誤, 從而有針對性的設計測驗用例的方法.

　錯誤推測方法的基本思想: 列舉出程式中所有可能有的錯誤和容易發生錯誤的特殊情況,根據他們選擇測驗用例-例如, 在單元測驗時曾列出的許多在模塊中常見的錯誤-以前產品測驗中曾經發現的錯誤等, 這些就是經驗的總結，還有, 輸入資料和輸出資料為0的情況，輸入表格為空格或輸入表格只有一行-這些都是容易發生錯誤的情況，可選擇這些情況下的例子作為測驗用例.

　4-因果圖方法

　前面介紹的等價類劃分方法和邊界值分析方法,都是著重考慮輸入條件,但未考慮輸入條件之間的聯系, 相互組合等-考慮輸入條件之間的相互組合,可能會產生一些新的情況-但要檢查輸入條件的組合不是一件容易的事情, 即使把所有輸入條件劃分成等價類,他們之間的組合情況也相當多-因此必須考慮采用一種適合于描述對于多種條件的組合,相應產生多個動作的形式來考慮設計測驗用例-這就需要利用因果圖(邏輯模型)-因果圖方法最終生成的就是判定表-它適合于檢查程式輸入條件的各種組合情況.

　5-正交表分析法

　有時候，可能因為大量的引數的組合而引起測驗用例數量上的激增，同時，這些測驗用例并沒有明顯的優先級上的差距，而測驗人員又無法完成這么多數量的測驗，就可以通過正交表來進行縮減一些用例，從而達到盡量少的用例覆寫盡量大的范圍的可能性，

　6-場景分析方法

　指根據用戶場景來模擬用戶的操作步驟，這個比較類似因果圖，但是可能執行的深度和可行性更好，

　50、您認為做好測驗用例設計作業的關鍵是什么?

　白盒測驗用例設計的關鍵是以較少的用例覆寫盡可能多的內部程式邏輯結果

　黑盒法用例設計的關鍵同樣也是以較少的用例覆寫模塊輸出和輸入介面，不可能做到完全測驗，以最少的用例在合理的時間內發現最多的問題

　51、詳細的描述一個測驗活動完整的程序，（1079636098）推薦軟體測驗技術交流Q群，

　1-專案經理通過和客戶的交流，完成需求檔案，由開發人員和測驗人員共同完成需求檔案的評審，評審的內容包括：需求描述不清楚的地方和可能有明顯沖突或者無法實作的功能的地方，專案經理通過綜合開發人員，測驗人員以及客戶的意見，完成專案計劃，然后sqa進入專案，開始進行統計和跟蹤

　2-開發人員根據需求檔案完成需求分析檔案，測驗人員進行評審，評審的主要內容包括是否有遺漏或者雙方理解不同的地方，測驗人員完成測驗計劃檔案，測驗計劃包括的內容上面有描述，

　3-測驗人員根據修改好的需求分析檔案開始寫測驗用例，同時開發人員完成概要設計檔案，詳細設計檔案，此兩份檔案成為測驗人員撰寫測驗用例的補充材料，

　4-測驗用例完成后，測驗和開發需要進行評審，

　5-測驗人員搭建環境

　6-開發人員提交第一個版本，可能存在未完成功能，需要說明，測驗人員進行測驗，發現bug后提交給bugzilla，

　7-開發提交第二個版本，包括bug fix以及增加了部分功能，測驗人員進行測驗，

　8-重復上面的作業，一般是3-4個版本后bug數量減少，達到出貨的要求，

　9-如果有客戶反饋的問題，需要測驗人員協助重現以及回歸測驗，

　52、以往是否曾經從事過性能測驗作業?請盡可能的詳細描述您以往的性能測驗作業的完整程序，

　曾經做過一套網管系統的性能測驗，主要測驗該軟體在同時管理大量終端的情況下，在回應時間，cpu/磁盤/記憶體等引數是否滿足要求，

　也曾經做過軟交換系統的呼叫性能測驗，主要是測驗軟交換系統在有大量呼叫的情況下，回應時間，呼叫成功率，cpu/磁盤/記憶體等引數是否滿足設計要求，

　53、在您以往的作業中，一條軟體缺陷(或者叫bug)記錄都包含了哪些內容?如何提交高質量的軟體缺陷(bug)記錄?

　1-在傳統的bugzilla中，bug描述應該包括以下的資訊

　2-和bug產生對應的軟體版本

　3-開發的介面人員

　4-bug的優先級

　5-bug的嚴重程度

　6-bug可能屬于的模塊，如果不能確認，可以用開發人員來判斷

　7-bug標題，需要清晰的描述現象

　8-bug描述，需要盡量給出重新bug的步驟

　9-bug附件中能給出相關的日志和截圖，

　高質量的bug記錄就是指很容易理解的bug記錄，所以，對于描述的要求高，能提供的資訊多且準確，很好的幫助開發人員定位，

　54、您在從事性能測驗作業時，是否使用過一些測驗工具?如果有，請試述該工具的作業原理，并以一個具體的作業中的例子描述該工具是如何在實際作業中應用的，

　測驗網管系統中，使用的mimic來模擬終端，能夠大量的節省成本，

　測驗軟交換系統的時候，使用的prolab來模擬終端并發送呼叫軟交換，他完成了同時數百人才能完成的摘機撥號作業，主要作業原理是產生一些符合要求的ip包并發送給軟交換系統，同時對軟交換系統的回應進行處理，決定下一步動作，

　55、您認為性能測驗作業的目的是什么?做好性能測驗作業的關鍵是什么?

　主要是保障在大量用戶的情況下，服務能正常使用，

最后：

歡迎大家關注我的公眾號程式員一凡獲取更多軟體測驗大廠面試、技術進階資料，如果對你有幫助，我也會很開心，軟體測驗，與你同行！

標籤：其他

上一篇：回溯問題Python框架總結——排列組合問題

下一篇：我在面試中常問的資料庫問題