知己知彼才能百戰不怠，每一次面試也是一場仗，這仗打的漂亮不漂亮和你面試回答有很大的關聯，這幾天一菲私下整理了很多軟體測驗面試題，今天就給大家梳理一下，不要太感動！
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、一個測驗工程師應該具備哪些素質和技能？
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、沒有產品說明書和需求檔案地情況下能夠進行黑盒測驗嗎？
這個問題是國內測驗工程師經常遇到的問題，根源就是國內軟體開發檔案管理不規范，對變更的管理方法就更不合理了，實際上沒有任何檔案的時候，測驗人員是能夠進行黑盒測驗的，這種測驗方式我們可以稱之為探索測驗，具體做法就是測驗工程師根據自己的專業技能、領域知識等不斷的深入了解測驗物件、理解軟體功能，進而發現缺陷，
在這種做法基本上把軟體當成了產品說明書，測驗程序中要和開發人員不斷的進行交流，尤其在作專案的時候，進度壓力比較大，可以作為加急測驗方案，最大的風險是不知道有些特性是否被遺漏，
36、測驗中的“殺蟲劑怪事”是指什么？
“殺蟲劑怪事”一詞由BorisBeizer在其編著的《軟體測驗技術》第二版中提出，用于描述測驗人員對同一測驗物件進行的測驗次數越多，發現的缺陷就會越來越少的現象，就像老用一種農藥，害蟲就會有免疫力，農藥發揮不了效力，這種現象的根本原因就是測驗人員對測驗軟體過于熟悉，形成思維定勢，
為了克服這種現象，測驗人員需要不斷撰寫新的測驗程式或者測驗用例，對程式的不同部分進行測驗，以發現更多的缺陷，也可以參考新人來測驗軟體，剛剛進來的新手往往能發現一些意想不到的問題，
37、在配置測驗中，如何判斷發現的缺陷是普通問題還是特定的配置問題？
在進行配置測驗時，測驗工程師仍然會發現一些普通的缺陷，也就是與配置環境無關的缺陷，因此判斷新發現的問題，需要在不同的配置中重新執行發現軟體缺陷的步驟，如果軟體缺陷不出現了，就可能是配置缺陷；如果在所有的配置中都出現，就可能是普通缺陷，
需要注意的是，配置問題可以在一大類配置中出現，例如，撥號程式可能在所有的外置Modem中都存在問題，而內置的Modem不會有任何問題，
38、為什么盡量不要讓時間有富裕的員工去做一些測驗？
表面上看這體現了管理的效率和靈活性，但實際上也體現了管理者對測驗的輕視，測驗和測驗的人有很大關系，測驗作業人員應該是勤奮并富有耐心，善于學習、思考和發現問題，細心有條理，總結問題，如果具備這樣的優點，做其它作業同樣也會很出色，因此這里還有一個要求，就是要喜歡測驗這項作業，如果他是專職的，那么肯定更有經驗和信心，國內的小伙子好象都喜歡做程式員，兩者作業性質不同，待遇不同，地位不同，對自我實作的價值的認識也不同，這是行業的一個需要改善的問題，如果只是為了完成任務而完成任務，或者發現了幾個問題就覺得滿意了，這在任何其它作業中都是不行的，
39、完全測驗程式是可能的嗎？
軟體測驗初學者可能認為拿到軟體后需要進行完全測驗，找到全部的軟體缺陷，使軟體“零缺陷”發布，實際上完全測驗是不可能的，主要有以下一個原因：
-完全測驗比較耗時，時間上不允許；
-完全測驗通常意味著較多資源投入，這在現實中往往是行不通的；
-輸入量太大，不能一一進行測驗；
-輸出結果太多，只能分類進行驗證；
-軟體實作途徑太多；
-軟體產品說明書沒有客觀標準，從不同的角度看，軟體缺陷的標準不同；
因此測驗的程度要根據實際情況確定，
40、軟體測驗的風險主要體現在哪里？
我們沒有對軟體進行完全測驗，實際就是選擇了風險，因為缺陷極有可能存在沒有進行測驗的部分，舉個例子，程式員為了方便，在除錯程式時會彈出一些提示資訊框，而這些提示只在某種條件下會彈出，碰巧程式發布前這些代碼中的一些沒有被注釋掉，在測驗時測驗工程師又沒有對其進行測驗，如果客戶碰到它，這將是代價昂貴的缺陷，因為交付后才被客戶發現，
因此，我們要盡可能的選擇最合適的測驗量，把風險降低到最小，
在這里推薦一個軟體測驗交流群，QQ：642830685，群中會不定期的分享軟體測驗資源和測驗面試題以及行業資訊，小伙伴們可以在群中積極交流相關問題，風里雨里我在群中等你，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/250491.html
標籤：其他