本題庫均來自海量真實校招面試題目大資料進行的整理，后續也會不斷更新，
需要嚴肅說明的是：面試題庫作為幫助同學準備面試的輔助資料，但是絕對不能作為備考唯一途徑，因為面試是一個考察真實水平的，不是背會了答案就可以的，需要你透徹理解的，否則追問問題答不出來反而減分，畢竟技術面試中面試官最痛恨的就是背答案這個事情了，
面試技巧
面試一般分為技術面和hr面，形式的話很少有群面，少部分企業可能會有一個交叉面，不過總的來說，技術面基本就是考察你的專業技術水平的，hr面的話主要是看這個人的綜合素質以及家庭情況符不符合公司要求，一般來講，技術的話只要通過了技術面hr面基本上是沒有問題（也有少數企業hr面會刷很多人）
那我們主要來說技術面，技術面的話主要是考察專業技術知識和水平，我們是可以有一定的技巧的，但是一定是基于有一定的能力水平的，
所以也慎重的告訴大家，技巧不是投機取巧，是起到輔助效果的，技術面最主要的還是要有實力，這里是基于實力水平之上的技巧，
這里告訴大家面試中的幾個技巧：
1、簡歷上做一個引導：
在詞匯上做好區分，比如熟悉Java，了解python，精通c語言
這樣的話對自己的掌握程度有個區分，也好讓面試官有個著重去問，python本來寫的也只是了解，自然就不會多問你深入的一些東西了，
2、在面試程序中做一個引導：
面試程序中盡量引導到自己熟知的一個領域，比如問到你說一下DNS尋址，然后你簡單回答（甚至這步也可以省略）之后，可以說一句，自己對這塊可能不是特別熟悉，對計算機網路中的運輸層比較熟悉，如果有具體的，甚至可以再加一句，比如TCP和UDP
這樣的話你可以把整個面試程序往你熟知的地方引導，也能更傾向于體現出你的優勢而不是劣勢，但是此方法僅限于掌握合適的度，比如有的知識點是必會的而你想往別處引就有點說不過去了，比如讓你說幾個Java的關鍵字，你一個也說不上來，那可能就真的沒轍了，
3、在自我介紹中做一個引導：
一般面試的開頭都會有一個自我介紹，在這個位置你也可以盡情的為自己的優勢方面去引導，
4、面試程序中展示出自信：
面試程序中的態度也要掌握好，不要自卑，也不要傲嬌，自信的回答出每個問題，尤其遇到不會的問題，要么做一些引導，實在不能引導也可以先打打擦邊球，和面試官交流一下問題，看起來像是沒聽懂題意，這個程序也可以再自己思考一下，如果覺得這個程序可以免了的話也直接表明一下這個地方不太熟悉或者還沒有掌握好，千萬不要強行回答，
面試前的準備：
最重要的肯定是系統的學習了，有一個知識的框架，基礎知識的牢靠程度等，
其中演算法尤其重要，越來越多公司還會讓你現場或者視頻面試中手寫代碼；
另一大重要的和加分項就是專案，在面試前，一定要練習回答自己專案的三個問題：
這是一個怎樣的專案
用到了什么技術，為什么用這項技術（以及每項技術很細的點以及擴展）
程序中遇到了什么問題，怎么解決的，
面試后需要做的：
面試完了的話就不用太在意結果了，有限的時間就應該做事半功倍的事情，當然，要保持電話郵箱暢通，不然別給你發offer你都不知道，
拋開這些，我們需要做的是及時將面試中的問題記錄下來，尤其是自己回答的不夠好的問題，一定要花時間去研究，并解決這些問題，下次面試再遇到相同的問題就能很好的解決，當然，即使不遇到，你這個習慣堅持住，后面也可以作為一個經歷去跟面試官說，能表現出你對技術的喜愛和鉆研的一個態度，同時，每次面試后你會發現自己的不足，查缺補漏的好機會，及時調整，在不斷的調整和查缺補漏的程序中，你會越來越好，
● 請說一說黑盒與白盒的測驗方法
參考回答：
黑盒測驗：
黑盒測驗也稱功能測驗或資料驅動測驗，它是在已知產品所應具有的功能，通過測驗來檢測每個功能是否都能正常使用，在測驗時，把程式看作一個不能打開的黑盆子，在完全不考慮程式內部結構和內部特性的情況下，測驗者在程式介面進行測驗，它只檢查程式功能是否按照需求規格說明書的規定正常使用，程式是否能適當地接收輸入數鋸而產生正確的輸出資訊，并且保持外部資訊（如資料庫或檔案）的完整性，
“黑盒”法著眼于程式外部結構、不考慮內部邏輯結構、針對軟體界面和軟體功能進行測驗，“黑盒”法是窮舉輸入測驗，只有把所有可能的輸入都作為測驗情況使用，才能以這種方法查出程式中所有的錯誤，實際上測驗情況有無窮多個，因此不僅要測驗所有合法的輸入，而且還要對那些不合法但是可能的輸入進行測驗，
常用的黑盒測驗方法有：等價類劃分法；邊界值分析法；因果圖法；場景法；正交實驗設計法；判定表驅動分析法；錯誤推測法；功能圖分析法，
白盒測驗：
白盒測驗也稱為結構測驗或邏輯驅動測驗，是針對被測單元內部是如何進行作業的測驗，它根據程式的控制結構設計測驗用例，主要用于軟體或程式驗證，白盒測驗法檢查程式內部邏輯結構，對所有的邏輯路徑進行測驗，是一種窮舉路徑的測驗方法，但即使每條路徑都測驗過了，但仍然有可能存在錯誤，因為：窮舉路徑測驗無法檢查出程式本身是否違反了設計規范，即程式是否是一個錯誤的程式；窮舉路徑測驗不可能檢查出程式因為遺漏路徑而出錯；窮舉路徑測驗發現不了一些與資料相關的錯誤，
白盒測驗需要遵循的原則有：1. 保證一個模塊中的所有獨立路徑至少被測驗一次；2. 所有邏輯值均需要測驗真（true）和假（false）；兩種情況；3. 檢查程式的內部資料結構，保證其結構的有效性；4. 在上下邊界及可操作范圍內運行所有回圈，
常用白盒測驗方法：
靜態測驗：不用運行程式的測驗，包括代碼檢查、靜態結構分析、代碼質量度量、檔案測驗等等，它可以由人工進行，充分發揮人的邏輯思維優勢，也可以借助軟體工具（Fxcop）自動進行，
動態測驗：需要執行代碼，通過運行程式找到問題，包括功能確認與介面測驗、覆寫率分析、性能分析、記憶體分析等，
白盒測驗中的邏輯覆寫包括陳述句覆寫、判定覆寫、條件覆寫、判定/條件覆寫、條件組合覆寫和路徑覆寫，六種覆寫標準發現錯誤的能力呈由弱到強的變化：
1.陳述句覆寫每條陳述句至少執行一次，
2.判定覆寫每個判定的每個分支至少執行一次，
3.條件覆寫每個判定的每個條件應取到各種可能的值，
4.判定/條件覆寫同時滿足判定覆寫條件覆寫，
5.條件組合覆寫每個判定中各條件的每一種組合至少出現一次，
6.路徑覆寫使程式中每一條可能的路徑至少執行一次，
● 請你分別介紹一下單元測驗、集成測驗、系統測驗、驗收測驗、回歸測驗
參考回答：
1、單元測驗：完成最小的軟體設計單元（模塊）的驗證作業，目標是確保模塊被正確的編碼，使用程序設計描述作為指南，對重要的控制路徑進行測驗以發現模塊內的錯誤，通常情況下是白盒的，對代碼風格和規則、程式設計和結構、業務邏輯等進行靜態測驗，及早的發現和解決不易顯現的錯誤，
2、集成測驗：通過測驗發現與模塊介面有關的問題，目標是把通過了單元測驗的模塊拿來，構造一個在設計中所描述的程式結構，應當避免一次性的集成（除非軟體規模很小），而采用增量集成，
自頂向下集成：模塊集成的順序是首先集成主模塊，然后按照控制層次結構向下進行集成，隸屬于主模塊的模塊按照深度優先或廣度優先的方式集成到整個結構中去，
自底向上集成：從原子模塊開始來進行構造和測驗，因為模塊是自底向上集成的，進行時要求所有隸屬于某個給頂層次的模塊總是存在的，也不再有使用穩定測驗樁的必要，
3、系統測驗：是基于系統整體需求說明書的黑盒類測驗，應覆寫系統所有聯合的部件，系統測驗是針對整個產品系統進行的測驗，目的是驗證系統是否滿足了需求規格的定義，找出與需求規格不相符合或與之矛盾的地方，系統測驗的物件不僅僅包括需要測驗的產品系統的軟體，還要包含軟體所依賴的硬體、外設甚至包括某些資料、某些支持軟體及其介面等，因此，必須將系統中的軟體與各種依賴的資源結合起來，在系統實際運行環境下來進行測驗，
4、回歸測驗：回歸測驗是指在發生修改之后重新測驗先前的測驗用例以保證修改的正確性，理論上，軟體產生新版本，都需要進行回歸測驗，驗證以前發現和修復的錯誤是否在新軟體版本上再次出現，根據修復好了的缺陷再重新進行測驗，回歸測驗的目的在于驗證以前出現過但已經修復好的缺陷不再重新出現，一般指對某已知修正的缺陷再次圍繞它原來出現時的步驟重新測驗，
5、驗收測驗：驗收測驗是指系統開發生命周期方法論的一個階段，這時相關的用戶或獨立測驗人員根據測驗計劃和結果對系統進行測驗和接收，它讓系統用戶決定是否接收系統，它是一項確定產品是否能夠滿足合同或用戶所規定需求的測驗，驗收測驗包括Alpha測驗和Beta測驗，
Alpha測驗：是由用戶在開發者的場所來進行的，在一個受控的環境中進行，
Beta測驗：由軟體的最終用戶在一個或多個用戶場所來進行的，開發者通常不在現場，用戶記錄測驗中遇到的問題并報告給開發者，開發者對系統進行最后的修改，并開始準備發布最終的軟體，
● 請你回答一下單元測驗、集成測驗、系統測驗、驗收測驗、回歸測驗這幾步中最重要的是哪一步
參考回答：
這些測驗步驟分別在軟體開發的不同階段對軟體進行測驗，我認為對軟體完整功能進行測驗的系統測驗很重要，因為此時單元測驗和集成測驗已完成，能夠對軟體所有功能進行功能測驗，能夠覆寫系統所有聯合的部件，是針對整個產品系統進行的測驗，能夠驗證系統是否滿足了需求規格的定義，因此我認為系統測驗很重要，
● 請回答集成測驗和系統測驗的區別，以及它們的應用場景主要是什么？
參考回答：
區別：
1、計劃和用例編制的先后順序：從V模型來講，在需求階段就要制定系統測驗計劃和用例，HLD的時候做集成測驗計劃和用例，有些公司的具體實踐不一樣，但是順序肯定是先做系統測驗計劃用例，再做集成，
2、用例的粒度：系統測驗用例相對很接近用戶接受測驗用例，集成測驗用例比系統測驗用例更詳細，而且對于介面部分要重點寫，畢竟要集成各個模塊或者子系統，
3、執行測驗的順序：先執行集成測驗，待集成測驗出的問題修復之后，再做系統測驗，
應用場景：
集成測驗：完成單元測驗后，各模塊聯調測驗；集中在各模塊的介面是否一致、各模塊間的資料流和控制流是否按照設計實作其功能、以及結果的正確性驗證等等；可以是整個產品的集成測驗，也可以是大模塊的集成測驗；集成測驗主要是針對程式內部結構進行測驗，特別是對程式之間的介面進行測驗，集成測驗對測驗人員的撰寫腳本能力要求比較高，測驗方法一般選用黑盒測驗和白盒測驗相結合，
系統測驗：針對整個產品的全面測驗，既包含各模塊的驗證性測驗（驗證前兩個階段測驗的正確性）和功能性（產品提交個用戶的功能）測驗，又包括對整個產品的健壯性、安全性、可維護性及各種性能引數的測驗，系統測驗測驗軟體《需求規格說明書》中提到的功能是否有遺漏，是否正確的實作，做系統測驗要嚴格按照《需求規格說明書》，以它為標準，測驗方法一般都使用黑盒測驗法，
● 請問測驗開發需要哪些知識？需要具備什么能力？
參考回答：
需要的知識：
軟體測驗基礎理論知識，如黑盒測驗、白盒測驗等；
考編程語言基礎，如C/C++、java、python等；
自動化測驗工具，如Selenium、Appium、Robotium等；
計算機基礎知識，如資料庫、Linux、計算機網路等；
測驗框架，如JUnit等，
需要具備的能力：
業務分析能力，分析整體業務流程、分析被測業務資料、分析被測系統架構、分析被測業務模塊、分析測驗所需資源、分析測驗完成目標；
缺陷洞察能力，一般缺陷的發現能力、隱性問題的發現能力、發現連帶問題的能力、發現問題隱患的能力、盡早發現問題的能力、發現問題根源的能力；
團隊協作能力，合理進行人員分工、協助組員解決問題、配合完成測驗任務、配合開發重現缺陷、督促專案整體進度、出現問題勇于承擔；
專業技術能力，掌握測驗基礎知識、掌握計算機知識、熟練運用測驗工具；
邏輯思考能力，判斷邏輯的正確性、對可行性邏輯分析、站在客觀角度思考；
問題解決能力，技術上的問題、作業中的問題、溝通問題；
溝通表達能力，和技術人員、產品人員、上下級的溝通；
宏觀把控能力，有效控制測驗時間、有效控制測驗成本、有效制定測驗計劃、有效進行風險評估、有效控制測驗方向，
● 請說一下手動測驗與自動化測驗的優缺點
參考回答：
手工測驗缺點：
1、重復的手工回歸測驗，代價昂貴、容易出錯，
2、依賴于軟體測驗人員的能力，
手工測驗優點：
1、測驗人員具有經驗和對錯誤的猜測能力，
2、測驗人員具有審美能力和心理體驗，
3、測驗人員具有是非判斷和邏輯推理能力，
自動化測驗的優點：
1、對程式的回歸測驗更方便，這可能是自動化測驗最主要的任務，特別是在程式修改比較頻繁時，效果是非常明顯的，由于回歸測驗的動作和用例是完全設計好的，測驗期望的結果也是完全可以預料的，將回歸測驗自動運行，可以極大提高測驗效率，縮短回歸測驗時間，
2、可以運行更多更繁瑣的測驗，自動化的一個明顯的好處是可以在較少的時間內運行更多的測驗，
3、可以執行一些手工測驗困難或不可能進行的測驗，比如，對于大量用戶的測驗，不可能同時讓足夠多的測驗人員同時進行測驗，但是卻可以通過自動化測驗模擬同時有許多用戶，從而達到測驗的目的，
4、更好地利用資源，將繁瑣的任務自動化，可以提高準確性和測驗人員的積極性，將測驗技術人員解脫出來投入更多精力設計更好的測驗用例，有些測驗不適合于自動測驗，僅適合于手工測驗，將可自動測驗的測驗自動化后，可以讓測驗人員專注于手工測驗部分，提高手工測驗的效率，
5、測驗具有一致性和可重復性，由于測驗是自動執行的，每次測驗的結果和執行的內容的一致性是可以得到保障的，從而達到測驗的可重復的效果，
6、測驗的復用性，由于自動測驗通常采用腳本技術，這樣就有可能只需要做少量的甚至不做修改，實作在不同的測驗程序中使用相同的用例，
7、增加軟體信任度，由于測驗是自動執行的，所以不存在執行程序中的疏忽和錯誤，完全取決于測驗的設計質量，一旦軟體通過了強有力的自動測驗后，軟體的信任度自然會增加，
自動化測驗的缺點：
1、不能取代手工測驗
2、手工測驗比自動測驗發現的缺陷更多
3、對測驗質量的依賴性極大
4、測驗自動化不能提高有效性
5、測驗自動化可能會制約軟體開發，由于自動測驗比手動測驗更脆弱，所以維護會受到限制，從而制約軟體的開發，
6、工具本身并無想像力
● 請問你怎么看待軟體測驗的潛力和挑戰
參考回答：
軟體測驗是正在快速發展，充滿挑戰的領域，盡管現在許多自動化測驗軟體的出現使得傳統手工測驗的方式被代替，但自動化測驗工具的開發、安全測驗、測驗建模、精準測驗、性能測驗、可靠性測驗等專項測驗中仍然需要大量具有專業技能與專業素養的測驗人員，并且隨著云計算、物聯網、大資料的發展，傳統的測驗技術可能不再適用，測驗人員也因此面臨著挑戰，需要深入了解新場景并針對不同場景嘗試新的測驗方法，同時敏捷測驗、Devops的出現也顯示了軟體測驗的潛力，
● 你覺得軟體測驗的核心競爭力是什么
參考回答：
測驗人員的核心競爭力在于提早發現問題，并能夠發現別人無法發現的問題，
1、早發現問題：問題發現的越早，解決的成本越低，如果一個需求在還未實作的時候就能發現需求的漏洞，那么這種問題的價值是最高的，
2、發現別人無法發現的問題：所有人都能發現的問題，你發現了，那就證明你是可以被替代的，別人發現不了，而你可以發現，那么你就是無法被替代，
● 你覺得測驗和開發需要怎么結合才能使軟體的質量得到更好的保障
參考回答：
測驗和開發應該按照W模型的方式進行結合，測驗和開發同步進行，能夠盡早發現軟體缺陷，降低軟體開發的成本，
在V模型中，測驗程序被加在開發程序的后半部分，單元測驗所檢測代碼的開發是否符合詳細設計的要求，集成測驗所檢測此前測驗過的各組成部分是否能完好地結合到一起，系統測驗所檢測已集成在一起的產品是否符合系統規格說明書的要求，而驗收測驗則檢測產品是否符合最終用戶的需求，V模型的缺陷在于僅僅把測驗程序作為在需求分析、系統設計及編碼之后的一個階段，忽視了測驗對需求分析、系統設計的驗證，因此需求階段的缺陷很可能一直到后期的驗收測驗才被發現，此時進行彌補將耗費大量人力物力資源，
相對于V模型，W模型增加了軟體各開發階段中應同步進行的驗證和確認活動，W模型由兩個V字型模型組成，分別代表測驗與開發程序，圖中明確表示出了測驗與開發的并行關系，
W模型強調：測驗伴隨著整個軟體開發周期，而且測驗的物件不僅僅是程式，需求、設計等同樣要測驗，也就是說，測驗與開發是同步進行的，W模型有利于盡早地全面的發現問題，例如，需求分析完成后，測驗人員就應該參與到對需求的驗證和確認活動中，以盡早地找出缺陷所在，同時，對需求的測驗也有利于及時了解專案難度和測驗風險，及早制定應對措施，這將顯著減少總體測驗時間，加快專案進度，
W模型中測驗的活動與軟體開發同步進行，測驗的物件不僅僅是程式，還包括需求和設計，因此能夠盡早發現軟體缺陷，降低軟體開發的成本，
● 你覺得單元測驗可行嗎
參考回答：
可行，單元測驗可以有效地測驗某個程式模塊的行為，是未來重構代碼的信心保證，事前可以保證質量，事后可以快速復現問題，并在修改代碼后做回歸自測，可行性考慮的是要用一些可行的方法做到關鍵的代碼可測驗，如通過邊界條件、等價類劃分、錯誤、因果，設計測驗用例要覆寫常用的輸入組合、邊界條件和例外，
● 你覺得自動化測驗有什么意義，都需要做些什么
參考回答：
自動化測驗的意義在于
1、可以對程式的新版本自動執行回歸測驗
2、可以執行手工測驗困難或者不可能實作的測驗，如壓力測驗，并發測驗，
3、能夠更好的利用資源，節省時間和人力
執行自動化測驗之前首先判斷這個專案是不是和推廣自動化測驗，然后對專案做需求分析，指定測驗計劃，搭建自動化測驗框架，設計測驗用例，執行測驗，評估
● 請你回答一下測驗的相關流程是什么？
參考回答：
測驗最規范的程序如下
需求測驗->概要設計測驗->詳細設計測驗->單元測驗->集成測驗->系統測驗->驗收測驗
來自W模型
● 請你說一下如何寫測驗用例
參考回答：
1、測驗人員盡早介入，徹底理解清楚需求，這個是寫好測驗用例的基礎
2、如果以前有類似的需求，可以參考類似需求的測驗用例，然后還需要看類似需求的bug情況
3、清楚輸入、輸出的各種可能性，以及各種輸入的之間的關聯關系，理解清楚需求的執行邏輯，通過等價類、邊界值、判定表等方法找出大部分用例
4、找到需求相關的一些特性，補充測驗用例
5、根據自己的經驗分析遺漏的測驗場景
6、多總結類似功能點的測驗點，才能夠寫出質量越來越高的測驗用例
7、書寫格式一定要清晰
● 請問你覺得測驗專案具體作業是什么？
參考回答：
搭建測驗環境
撰寫測驗用例
執行測驗用例
寫測驗計劃，測驗報告
測驗，并提交BUG表單
跟蹤bug修改情況
執行自動化測驗，撰寫腳本，執行，分析，報告
進行性能測驗，壓力測驗等其他測驗，執行，分析，調優，報告
● 請問如果想進行bug的測評，怎么去評測bug？
參考回答：
Bug的priority（）和severity（）是兩個重要屬性，通常人員在提交bug的時候，只定義severity，而將priority交給leader定義，通常bug管理中，severity分為四個等級blocker、critical、major、minor/trivial，而priority分為五個等級immediate、urgent、high、normal、low，
Severity：
1、blocker：即系統無法執行，崩潰，或嚴重資源不足，應用模塊無法啟動或例外退出，無法測驗，造成系統不穩定，常見的有嚴重花屏、記憶體泄漏、用戶資料丟失或破壞、系統崩潰/死機/凍結、模塊無法啟動或例外退出、嚴重的數值計算錯誤、功能設計與需求嚴重不符、其它導致無法測驗的錯誤， 如服務器500錯誤，
2、critical：即映像系統功能或操作，主要功能存在嚴重缺陷，但不會映像到系統穩定性，常見的有：功能未實作，功能錯誤、系統重繪錯誤、資料通訊錯誤、輕微的數值計算錯誤、影響功能及界面的錯誤字或拼寫錯誤，
3、major：即界面、性能缺陷、兼容性，常見的有：操作界面錯誤，邊界條件錯誤，提示資訊錯誤，長時間操作無進度提示，系統未優化，兼容性問題，
4、minor/trivial：即易用性及建議性問題，
Priority
1、immediate：即馬上解決，
2、urgent：急需解決
3、high：高度重視，有時間要馬上解決
4、low：在系統發布前解決，或確認可以不用解決，
● 請你說一說測驗用例的邊界
參考回答：
邊界值分析法就是對輸入或輸出的邊界值進行測驗的一種黑盒測驗方法，通常邊界值分析法是作為對等價類劃分法的補充，這種情況下，其測驗用例來自等價類的邊界，
常見的邊界值
1)對16-bit 的整數而言 32767 和 -32768 是邊界
2)螢屏上游標在最左上、最右下位置
3)報表的第一行和最后一行
4)陣列元素的第一個和最后一個
5)回圈的第 0 次、第 1 次和倒數第 2 次、最后一次
● 請你說一下軟體質量的六個特征
參考回答：
按照軟體質量國家標準GB-T8566–2001G，軟體質量可以用下列特征來評價：
a.功能特征：與一組功能及其指定性質有關的一組屬性，這里的功能是滿足明確或隱含的需求的那些功能，
b.可靠特征：在規定的一段時間和條件下，與軟體維持其性能水平的能力有關的一組屬性，
c.易用特征：由一組規定或潛在的用戶為使用軟體所需作的努力和所作的評價有關的一組屬性，
d.效率特征：與在規定條件下軟體的性能水平與所使用資源量之間關系有關的一組屬性，
e.可維護特征：與進行指定的修改所需的努力有關的一組屬性，
f.可移植特征：與軟體從一個環境轉移到另一個環境的能力有關的一組屬性，
● 請你說一下設計測驗用例的方法
參考回答：
黑盒測驗：
1.等價類劃分
等價類劃分是將系統的輸入域劃分為若干部分，然后從每個部分選取少量代表性資料進行測驗，等價類可以劃分為有效等價類和無效等價類，設計測驗用例的時候要考慮這兩種等價類，
2.邊界值分析法
邊界值分析法是對等價類劃分的一種補充，因為大多數錯誤都在輸入輸出的邊界上，邊界值分析就是假定大多數錯誤出現在輸入條件的邊界上，如果邊界附件取值不會導致程式出錯，那么其他取值出錯的可能性也就很小，
邊界值分析法是通過優先選擇不同等價類間的邊界值覆寫有效等價類和無效等價類來更有效的進行測驗，因此該方法要和等價類劃分法結合使用，
3.正交試驗法
正交是從大量的試驗點中挑選出適量的、有代表性的點，正交試驗設計是研究多因素多水平的一種設計方法，他是一種基于正交表的高效率、快速、經濟的試驗設計方法，
4.狀態遷移法
狀態遷移法是對一個狀態在給定的條件內能夠產生需要的狀態變化，有沒有出現不可達的狀態和非法的狀態，狀態遷移法是設計足夠的用例達到對系統狀態的覆寫、狀態、條件組合、狀態遷移路徑的覆寫，
5.流程分析法
流程分析法主要針對測驗場景型別屬于流程測驗場景的測驗項下的測驗子項進行設計，這是從白盒測驗中路徑覆寫分析法借鑒過來的一種很重要的方法，
6.輸入域測驗法
輸入域測驗法是針對輸入會有各種各樣的輸入值的一個測驗，他主要考慮 極端測驗、中間范圍測驗，特殊值測驗 ，
7.輸出域分析法
輸出域分析法是對輸出域進行等價類和邊界值分析，確定是要覆寫的輸出域樣點，反推得到應該輸入的輸入值，從而構造出測驗用例，他的目的是為了達到輸出域的等價類和邊界值覆寫，
8.判定表分析法
判定表是分析和表達多種輸入條件下系統執行不同動作的工具，他可以把復雜的邏輯關系和多種條件組合的情況表達的即具體又明確；
9.因果圖法
因果圖是用于描述系統輸入輸出之間的因果關系、約束關系，因果圖的繪制程序是對被測系統的外部特征的建模程序，根據輸入輸出間的因果圖可以得到判定表，從而規劃出測驗用例，
10.錯誤猜測法
錯誤猜測法主要是針對系統對于錯誤操作時對于操作的處理法的猜測法，從而設計測驗用例
11.例外分析法
例外分析法是針對系統有可能存在的例外操作，軟硬體缺陷引起的故障進行分析，分析發生錯誤時系統對于錯誤的處理能力和恢復能力依此設計測驗用例，
白盒測驗：
白盒測驗也稱為結構測驗或邏輯驅動測驗，是針對被測單元內部是如何進行作業的測驗，它根據程式的控制結構設計測驗用例，主要用于軟體或程式驗證，白盒測驗法檢查程式內部邏輯結構，對所有的邏輯路徑進行測驗，是一種窮舉路徑的測驗方法，但即使每條路徑都測驗過了，但仍然有可能存在錯誤，因為：窮舉路徑測驗無法檢查出程式本身是否違反了設計規范，即程式是否是一個錯誤的程式；窮舉路徑測驗不可能檢查出程式因為遺漏路徑而出錯；窮舉路徑測驗發現不了一些與資料相關的錯誤，
白盒測驗需要遵循的原則有：1. 保證一個模塊中的所有獨立路徑至少被測驗一次；2. 所有邏輯值均需要測驗真（true）和假（false）；兩種情況；3. 檢查程式的內部資料結構，保證其結構的有效性；4. 在上下邊界及可操作范圍內運行所有回圈，
常用白盒測驗方法：
靜態測驗：不用運行程式的測驗，包括代碼檢查、靜態結構分析、代碼質量度量、檔案測驗等等，它可以由人工進行，充分發揮人的邏輯思維優勢，也可以借助軟體工具（Fxcop）自動進行，
動態測驗：需要執行代碼，通過運行程式找到問題，包括功能確認與介面測驗、覆寫率分析、性能分析、記憶體分析等，
白盒測驗中的邏輯覆寫包括陳述句覆寫、判定覆寫、條件覆寫、判定/條件覆寫、條件組合覆寫和路徑覆寫，六種覆寫標準發現錯誤的能力呈由弱到強的變化：
1.陳述句覆寫每條陳述句至少執行一次，
2.判定覆寫每個判定的每個分支至少執行一次，
3.條件覆寫每個判定的每個條件應取到各種可能的值，
4.判定/條件覆寫同時滿足判定覆寫條件覆寫，
5.條件組合覆寫每個判定中各條件的每一種組合至少出現一次，
6.路徑覆寫使程式中每一條可能的路徑至少執行一次，
● 請你說一說測驗工程師的必備技能
參考回答：
需要的知識：
? 軟體測驗基礎理論知識，如黑盒測驗、白盒測驗等；
? 編程語言基礎，如C/C++、java、python等；
? 自動化測驗工具，如Selenium、Appium、Robotium等；
? 計算機基礎知識，如資料庫、Linux、計算機網路等；
? 測驗框架，如JUnit等，
需要具備的能力：
? 業務分析能力，分析整體業務流程、分析被測業務資料、分析被測系統架構、分析被測業務模塊、分析測驗所需資源、分析測驗完成目標；
? 缺陷洞察能力，一般缺陷的發現能力、隱性問題的發現能力、發現連帶問題的能力、發現問題隱患的能力、盡早發現問題的能力、發現問題根源的能力；
? 團隊協作能力，合理進行人員分工、協助組員解決問題、配合完成測驗任務、配合開發重現缺陷、督促專案整體進度、出現問題勇于承擔；
? 專業技術能力，掌握測驗基礎知識、掌握計算機知識、熟練運用測驗工具；
? 邏輯思考能力，判斷邏輯的正確性、對可行性邏輯分析、站在客觀角度思考；
? 問題解決能力，技術上的問題、作業中的問題、溝通問題；
? 溝通表達能力，和技術人員、產品人員、上下級的溝通；
? 宏觀把控能力，有效控制測驗時間、有效控制測驗成本、有效制定測驗計劃、有效進行風險評估、有效控制測驗方向，
● 請你說一下app性能測驗的指標
參考回答：
1、記憶體：記憶體消耗測驗節點的設計目標是為了讓應用不占用過多的系統資源，且及時釋放記憶體，保障整個系統的穩定性，當然關于記憶體測驗，在這里我們需要引入幾個概念：空閑狀態、中等規格、滿規格，
空閑狀態指打開應用后，點擊home鍵讓應用后臺運行，此時應用處于的狀態叫做空閑；中等規格和滿規格指的是對應用的操作時間的間隔長短不一，中等規格時間較長，滿規格時間較短，
記憶體測驗中存在很多測驗子項，清單如下：
●空閑狀態下的應用記憶體消耗；
●中等規格狀態下的應用記憶體消耗；
●滿規格狀態下的應用記憶體消耗；
●應用記憶體峰值；
●應用記憶體泄露；
●應用是否常駐記憶體；
●壓力測驗后的記憶體使用，
2、CPU：
使用Android提供的view plaincopy在CODE上查看代碼片派生到我的代碼片
adbshell dumpsys CPUinfo |grep packagename >/address/CPU.txt來獲取；
使用top命令view plaincopy在CODE上查看代碼片派生到我的代碼片
adbshell top |grep packagename>/address/CPU.txt來獲取，
3、流量：
網路流量測驗是針對大部分應用而言的，可能還有部分應用會關注網速、弱網之類的測驗，
流量測驗包括以下測驗項：
應用首次啟動流量提示；
應用后臺連續運行2小時的流量值；
應用高負荷運行的流量峰值，
4、電量：
●測驗手機安裝目標APK前后待機功耗無明顯差異；
●常見使用場景中能夠正常進入待機，待機電流在正常范圍內；
●長時間連續使用應用無例外耗電現象，
5、啟動速度：
第一類：首次啟動–應用首次啟動所花費的時間；
第二類：非首次啟動–應用非首次啟動所花費的時間；
第三類：應用界面切換–應用界面內切換所花費的時間，
6、滑動速度、界面切換速度
7、與服務器互動的網路速度
● 請你說一說app測驗的工具
參考回答：
功能測驗自動化
a) 輕量介面自動化測驗
jmeter，
b) APP UI層面的自動化
android：UI Automator Viewer，Android Junit，Instrumentation，UIAutomator，
iOS:基于Instrument的iOS UI自動化，
性能測驗
a) Web前端性能測驗
網路抓包工具：Wireshark
網頁檔案大小
webpagetest
pagespeed insight
chrome adb
b) APP端性能測驗
Android記憶體占用分析：MAT
iOS記憶體問題分析：ARC模式
Android WebView性能分析：
iOS WebView性能分析
c) 后臺服務性能測驗
負載，壓力，耐久性
可拓展性，基準
工具：apacheAB，Jmeter，LoadRunner，
專項測驗
a) 兼容性測驗
手工測驗：作業系統，解析度，rom，網路型別
云平臺：testin，腳本撰寫，Android，
b) 流量測驗
Android自帶的流量管理，
iOS自帶的Network
tcpdump抓包
WiFi代理抓包：Fiddler
流量節省方法：壓縮資料，json優于xml；WebP優于傳統的JPG，PNG；控制訪問的頻次；只獲取必要的資料；快取；
c) 電量測驗
基于測驗設備的方法，購買電量表進行測驗，
GSam Battery Monitoe Pro
iOS基于Instrument Energy工具
d) 弱網路測驗
手機自帶的網路狀況模擬工具
基于代理的弱網路的模擬:
工具：windows：Network Delay Simulator
Mac：Network Link Conditioner
● 請你說一說bug的周期，以及描述一下不同類別的bug
參考回答：
1、New:（新的）
當某個“bug”被第一次發現的時候，測驗人員需要與專案負責人溝通以確認發現的的確是一個bug，如果被確認是一個bug，就將其記錄下來，并將bug的狀態設為New
2、Assigned（已指派的）
當一個bug被指認為New之后，將其反饋給開發人員，開發人員將確認這是否是一個bug，如果是，開發組的負責人就將這個bug指定給某位開發人員處理，并將bug的狀態設定為“Assigned”
3、Open（打開的）
一旦開發人員開始處理bug的時候，他（她）就將這個bug的狀態設定為“Open”，這表示開發人員正在處理這個“bug”
4、Fixed（已修復的）
當開發人員進行處理（并認為已經解決）之后，他就可以將這個bug的狀態設定為“Fixed”并將其提交給開發組的負責人，然后開發組的負責人將這個bug返還給測驗組
5、Pending Reset（待在測驗的）
當bug被返還到測驗組后，我們將bug的狀態設定為Pending Reset”
6、Reset(再測驗)
測驗組的負責人將bug指定給某位測驗人員進行再測驗，并將bug的狀態設定為“Reset”
7、Closed（已關閉的）
如果測驗人員經過再次測驗之后確認bug 已經被解決之后，就將bug的狀態設定為“Closed”
8、Reopen（再次打開的）
如果經過再次測驗發現bug（指bug本身而不是包括因修復而引發的新bug）仍然存在的話，測驗人員將bug再次傳遞給開發組，并將bug的狀態設定為“Reopen”
9、Pending Reject（拒絕中）
如果測驗人員傳遞到開發組的bug被開發人員認為是正常行為而不是bug時，這種情況下開發人員可以拒絕，并將bug的狀態設定為“Pending Reject”
10、Rejected(被拒絕的)
測驗組的負責人接到上述bug的時候，如果他（她）發現這是產品說明書中定義的正常行為或者經過與開發人員的討論之后認為這并不能算作bug的時候，開發組負責人就將這個bug的狀態設定為“Rejected”
11、Postponed（延期）
有些時候，對于一些特殊的bug的測驗需要擱置一段時間，事實上有很多原因可能導致這種情況的發生，比如無效的測驗資料，一些特殊的無效的功能等等，在這種情況下，bug的狀態就被設定為“Postponed“
不同類別的bug：
Bug型別
? 代碼錯誤
? 界面優化
? 設計缺陷
? 配置相關
? 安裝部署
? 安全相關
? 性能問題
? 標準規范
? 測驗腳本
? 其他
● 請你說一說PC網路故障，以及如何排除障礙
參考回答：
(1)首先是排除接觸故障，即確保你的網線是可以正常使用的，然后禁用網卡后再啟用，排除偶然故障，打開網路和共享中心視窗，單擊視窗左上側“更改配接器設定”右擊其中的“本地連接“或”無線網路連接”，單擊快捷選單中的“禁用”命令，即可禁用所選網路，接下來重啟網路，只需右擊后單擊啟用即可，
(2)使用ipconfig查看計算機的上網引數
1、單擊“開始|所有程式|附件|命令提示符“，打開命令提示符視窗
2、輸入ipconfig，按Enter確認，可以看到機器的配置資訊，輸入ipconfig/all,可以看到IP地址和網卡物理地址等相關網路詳細資訊，
(3)使用ping命令測驗網路的連通性，定位故障范圍
在命令提示符視窗中輸入”ping 127.0.0.1“，資料顯示本機分別發送和接受了4個資料包，丟包率為零，可以判斷本機網路協議作業正常，如顯示”請求超時“，則表明本機網卡的安裝或TCP/IP協議有問題，接下來就應該檢查網卡和TCP/IP協議，卸載后重裝即可，
(4)ping本機IP
在確認127.0.0.1地址能被ping通的情況下，繼續使用ping命令測驗本機的IP地址能否被ping通，如不能，說明本機的網卡驅動程式不正確，或者網卡與網線之間連接有故障，也有可能是本地的路由表面收到了破壞，此時應檢查本機網卡的狀態是否為已連接，網路引數是否設定正確，如果正確可是不能ping通，就應該重新安裝網卡驅動程式，丟失率為零，可以判斷網卡安裝配置沒有問題，作業正常，
(5)ping網關
網關地址能被ping通的話，表明本機網路連接以及正常，如果命令不成功，可能是網關設備自身存在問題，也可能是本機上網引數設定有誤，檢查網路引數，
● 請你說一說測驗的常用方法
參考回答：
黑盒測驗：
黑盒測驗也稱功能測驗或資料驅動測驗，它是在已知產品所應具有的功能，通過測驗來檢測每個功能是否都能正常使用，在測驗時，把程式看作一個不能打開的黑盆子，在完全不考慮程式內部結構和內部特性的情況下，測驗者在程式介面進行測驗，它只檢查程式功能是否按照需求規格說明書的規定正常使用，程式是否能適當地接收輸入數鋸而產生正確的輸出資訊，并且保持外部資訊（如資料庫或檔案）的完整性，
“黑盒”法著眼于程式外部結構、不考慮內部邏輯結構、針對軟體界面和軟體功能進行測驗，“黑盒”法是窮舉輸入測驗，只有把所有可能的輸入都作為測驗情況使用，才能以這種方法查出程式中所有的錯誤，實際上測驗情況有無窮多個，因此不僅要測驗所有合法的輸入，而且還要對那些不合法但是可能的輸入進行測驗，
常用的黑盒測驗方法有：等價類劃分法；邊界值分析法；因果圖法；場景法；正交實驗設計法；判定表驅動分析法；錯誤推測法；功能圖分析法，
白盒測驗：
白盒測驗也稱為結構測驗或邏輯驅動測驗，是針對被測單元內部是如何進行作業的測驗，它根據程式的控制結構設計測驗用例，主要用于軟體或程式驗證，白盒測驗法檢查程式內部邏輯結構，對所有的邏輯路徑進行測驗，是一種窮舉路徑的測驗方法，但即使每條路徑都測驗過了，但仍然有可能存在錯誤，因為：窮舉路徑測驗無法檢查出程式本身是否違反了設計規范，即程式是否是一個錯誤的程式；窮舉路徑測驗不可能檢查出程式因為遺漏路徑而出錯；窮舉路徑測驗發現不了一些與資料相關的錯誤，
白盒測驗需要遵循的原則有：1. 保證一個模塊中的所有獨立路徑至少被測驗一次；2. 所有邏輯值均需要測驗真（true）和假（false）；兩種情況；3. 檢查程式的內部資料結構，保證其結構的有效性；4. 在上下邊界及可操作范圍內運行所有回圈，
常用白盒測驗方法：
靜態測驗：不用運行程式的測驗，包括代碼檢查、靜態結構分析、代碼質量度量、檔案測驗等等，它可以由人工進行，充分發揮人的邏輯思維優勢，也可以借助軟體工具（Fxcop）自動進行，
動態測驗：需要執行代碼，通過運行程式找到問題，包括功能確認與介面測驗、覆寫率分析、性能分析、記憶體分析等，
白盒測驗中的邏輯覆寫包括陳述句覆寫、判定覆寫、條件覆寫、判定/條件覆寫、條件組合覆寫和路徑覆寫，六種覆寫標準發現錯誤的能力呈由弱到強的變化：
1.陳述句覆寫每條陳述句至少執行一次，
2.判定覆寫每個判定的每個分支至少執行一次，
3.條件覆寫每個判定的每個條件應取到各種可能的值，
4.判定/條件覆寫同時滿足判定覆寫條件覆寫，
5.條件組合覆寫每個判定中各條件的每一種組合至少出現一次，
6.路徑覆寫使程式中每一條可能的路徑至少執行一次，
● 請你說一下黑盒白盒
參考回答：
黑盒測驗：
黑盒測驗也稱功能測驗或資料驅動測驗，它是在已知產品所應具有的功能，通過測驗來檢測每個功能是否都能正常使用，在測驗時，把程式看作一個不能打開的黑盆子，在完全不考慮程式內部結構和內部特性的情況下，測驗者在程式介面進行測驗，它只檢查程式功能是否按照需求規格說明書的規定正常使用，程式是否能適當地接收輸入數鋸而產生正確的輸出資訊，并且保持外部資訊（如資料庫或檔案）的完整性，
“黑盒”法著眼于程式外部結構、不考慮內部邏輯結構、針對軟體界面和軟體功能進行測驗，“黑盒”法是窮舉輸入測驗，只有把所有可能的輸入都作為測驗情況使用，才能以這種方法查出程式中所有的錯誤，實際上測驗情況有無窮多個，因此不僅要測驗所有合法的輸入，而且還要對那些不合法但是可能的輸入進行測驗，
常用的黑盒測驗方法有：等價類劃分法；邊界值分析法；因果圖法；場景法；正交實驗設計法；判定表驅動分析法；錯誤推測法；功能圖分析法，
白盒測驗：
白盒測驗也稱為結構測驗或邏輯驅動測驗，是針對被測單元內部是如何進行作業的測驗，它根據程式的控制結構設計測驗用例，主要用于軟體或程式驗證，白盒測驗法檢查程式內部邏輯結構，對所有的邏輯路徑進行測驗，是一種窮舉路徑的測驗方法，但即使每條路徑都測驗過了，但仍然有可能存在錯誤，因為：窮舉路徑測驗無法檢查出程式本身是否違反了設計規范，即程式是否是一個錯誤的程式；窮舉路徑測驗不可能檢查出程式因為遺漏路徑而出錯；窮舉路徑測驗發現不了一些與資料相關的錯誤，
白盒測驗需要遵循的原則有：1. 保證一個模塊中的所有獨立路徑至少被測驗一次；2. 所有邏輯值均需要測驗真（true）和假（false）；兩種情況；3. 檢查程式的內部資料結構，保證其結構的有效性；4. 在上下邊界及可操作范圍內運行所有回圈，
常用白盒測驗方法：
靜態測驗：不用運行程式的測驗，包括代碼檢查、靜態結構分析、代碼質量度量、檔案測驗等等，它可以由人工進行，充分發揮人的邏輯思維優勢，也可以借助軟體工具（Fxcop）自動進行，
動態測驗：需要執行代碼，通過運行程式找到問題，包括功能確認與介面測驗、覆寫率分析、性能分析、記憶體分析等，
白盒測驗中的邏輯覆寫包括陳述句覆寫、判定覆寫、條件覆寫、判定/條件覆寫、條件組合覆寫和路徑覆寫，六種覆寫標準發現錯誤的能力呈由弱到強的變化：
1.陳述句覆寫每條陳述句至少執行一次，
2.判定覆寫每個判定的每個分支至少執行一次，
3.條件覆寫每個判定的每個條件應取到各種可能的值，
4.判定/條件覆寫同時滿足判定覆寫條件覆寫，
5.條件組合覆寫每個判定中各條件的每一種組合至少出現一次，
6.路徑覆寫使程式中每一條可能的路徑至少執行一次，
● 請你說一說你知道的自動化測驗框架
參考回答：
1、模塊化測驗框架
模塊化測驗腳本框架（TEST MODulARITY FRAMEWORK）需要創建小而獨立的可以描述的模塊、片斷以及待測應用程式的腳本，這些樹狀結構的小腳本組合起來，就能組成能用于特定的測驗用例的腳本，在五種框架中，模塊化框架是最容易掌握和使用的，在一個組件上方建立一個抽象層使其在余下的應用中隱藏起來，這是眾所周知的編程技巧，這樣應用同組件中的修改隔離開來，提供了程式設計的模塊化特性，模塊化測驗腳本框架使用這一抽象或者封裝的原理來提高自動測驗組合的可維護性和可升級性，
2、測驗庫框架
測驗庫框架（Test Library Architecture）與模塊化測驗腳本框架很類似，并且具有同樣的優點，不同的是測驗庫框架把待測應用程式分解為程序和函式而不是腳本，這個框架需要創建描述模塊、片斷以及待測應用程式的功能庫檔案，
3、關鍵字驅動或表驅動的測驗框架
對于一個獨立于應用的自動化框架，關鍵字驅動（KEYWORD DRIVEN）I9LJJ試和表驅動（TABLE DRIVEN）測驗是可以互換的術語，這個框架需要開發資料表和關鍵字，這些資料表和關鍵字獨立于執行它們的測驗自動化工具，并可以用來“驅動＂待測應用程式和資料的測驗腳本代碼，關鍵宇驅動測驗看上去與手工測驗用例很類似，在一個關鍵字驅動測驗中，把待測應用程式的功能和每個測驗的執行步驟一起寫到一個表中，這個測驗框架可以通過很少的代碼來產生大量的測驗用例，同樣的代碼在用資料表來產生各個測驗用例的同時被復用，
4、資料驅動測驗框架
資料驅動（DATA DRIVEN），LJ試是一個框架，在這里測驗的輸入和輸出資料是從資料檔案中讀取（資料池，ODBC源，CSV檔案，EXCEL檔案，ADO物件等）并且通過捕獲工具生成或者手工生成的代碼腳本被載入到變數中，在這個框架中，變數不僅被用來存放輸入值還被用來存放輸出的驗證值，整個程式中，測驗腳本來讀取數值檔案，記載測驗狀態和資訊，這類似于表驅動測驗，在表驅動測 試中，它的測驗用例是包含在資料檔案而不是在腳本中，對于資料而言，腳本僅僅是一個“驅動器”，或者是一個傳送機構，然而，資料驅動測驗不同于表驅動測驗，盡管導航資料并不包含在表結構中，在資料驅動測驗中，資料檔案中只包含測驗資料，這個框架意圖減少需要執行所有測驗用例所需要的總的測驗腳本數，資料驅動需要很少的代碼來產生大量的測驗用例，這與表驅動極其類似，
5、混合測驗自動化（Hybrid Test Automation）框架
最普遍的執行框架是上面介紹的所有技術的一個結合，取其長處，彌補其不足，這個混合測驗框架是由大部分框架隨著時間并經過若干專案演化而來的
● 請你說一說web測驗和app測驗的不同點
參考回答：
系統架構方面：
web專案，一般都是b/s架構，基于瀏覽器的
app專案，則是c/s的，必須要有客戶端，用戶需要安裝客戶端，
web測驗只要更新了服務器端，客戶端就會同步會更新，App專案則需要客戶端和服務器都更新，
性能方面:
web頁面主要會關注回應時間
而app則還需要關心流量、電量、CPU、GPU、Memory這些，
它們服務端的性能沒區別，都是一臺服務器，
兼容方面：
web是基于瀏覽器的，所以更傾向于瀏覽器和電腦硬體，電腦系統的方向的兼容
app測驗則要看解析度，螢屏尺寸，還要看設備系統，
web測驗是基于瀏覽器的所以不必考慮安裝卸載，
而app是客戶端的，則必須測驗安裝、更新、卸載，除了常規的安裝、更新、卸載還要考慮到例外場景，包括安裝時的中斷、弱網、安裝后洗掉安裝檔案 ，
此外APP還有一些專項測驗：如網路、適配性，
● 請問你了解什么測驗方法
參考回答：
等價類劃分，邊界值分析，錯誤推測，因果圖法，邏輯覆寫法，程式插樁技術，基本路徑法，符號測驗，錯誤驅動測驗
● 請問黑盒測驗和白盒測驗有哪些方法
參考回答：
黑盒測驗方法有等價類劃分，邊界值分析，錯誤推測，因果圖法
白盒測驗方法有邏輯覆寫法，程式插樁技術，基本路徑法，符號測驗，錯誤驅動測驗
● 請問你怎么看待測驗，知道哪些測驗的型別，有用過哪些測驗方法？
參考回答：
測驗是軟體開發中不可或缺的一環，測驗通過經濟，高效的方法，捕捉軟體中的錯誤，從而達到保重軟體內在質量的目的，
測驗分為功能測驗和非功能測驗，非功能測驗又可以分為性能測驗、壓力測驗、容量測驗、健壯性測驗、安全性測驗、可靠性測驗、恢復性測驗、備份測驗、協議測驗、兼容性測驗、可用性測驗、配置測驗、GUI測驗，
測驗方法用過等價劃分法、邊值分析法、錯誤推測法、因果圖法，
● 請問你怎么測驗網路協議
參考回答：
協議測驗包括四種型別的測驗
1、一致性測驗：檢測協議實作本身與協議規范的符合程度
2、互操作性測驗：基于某一協議檢測不同協議實作間互操作互通信的能力
3、性能測驗：檢測協議實作的性能指標，比如資料傳輸速度，連接時間，執行速度，吞吐量，并發度，
4、健壯性測驗：檢測協議是現在各種惡劣環境下運行的能力，比如注入干擾報文，通信故障，信道被切斷
● 請你回答一下什么是α測驗和β測驗，以及什么時候用到他們
參考回答：
α測驗：在受控的環境中進行，由用戶在開發者的場所進行，并且在開發者對用戶的指導下進行測驗，開發者負責記錄發現的錯誤和使用中遇到的問題
β測驗：在開發者不能控制的環境中的真實應用，由軟體的最終用戶們在一個或多個客戶場所下進行，由用戶記錄在測驗中遇到的一系列問題，并定期報給開發者，
最后：
愿你我相遇，皆有所獲！ 歡迎關注 微信公眾號：程式員一凡
1.免費領取一份216頁軟體測驗工程師面試寶典檔案資料，
2.軟體測驗學習路線以及相對應的視頻學習教程免費分享！
3.軟體測驗技術交流群：1079636098 群友福利免費領取
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/263236.html
標籤：其他