測驗技術面試題
1、什么是兼容性測驗？兼容性測驗側重哪些方面？
參考答案：
兼容測驗主要是檢查軟體在不同的硬體平臺、軟體平臺上是否可以正常的運行，即是通常說的軟體的可移植性，
兼容的型別，如果細分的話，有平臺的兼容，網路兼容，資料庫兼容，以及資料格式的兼容，
兼容測驗的重點是，對兼容環境的分析，通常，是在運行軟體的環境不是很確定的情況下，才需要做兼容，根據軟體運行的需要，或者根據需求檔案，一般都能夠得出用戶會在什么環境下使用該軟體，把這些環境整理成表單，就得出做兼容測驗的兼容環境了，
兼容和配置測驗的區別在于，做配置測驗通常不是Clean OS下做測驗，而兼容測驗多是在Clean OS的環境下做的，
2、我現在有個程式，發現在Windows上運行得很慢，怎么判別是程式存在問題還是軟硬體系統存在問題？
參考答案：
1、檢查系統是否有中毒的特征；
2、檢查軟體/硬體的配置是否符合軟體的推薦標準；
3、確認當前的系統是否是獨立，即沒有對外提供什么消耗CPU資源的服務；
4、如果是C/S或者B/S結構的軟體，需要檢查是不是因為與服務器的連接有問題，或者訪問有問題造成的；
5、在系統沒有任何負載的情況下，查看性能監視器，確認應用程式對CPU/記憶體的訪問情況，
3、測驗的策略有哪些？
參考答案：
黑盒/白盒，靜態/動態，手工/自動，冒煙測驗，回歸測驗，公測（Beta測驗的策略）
4、正交表測驗用例設計方法的特點是什么？
參考答案：
用最少的實驗覆寫最多的操作，測驗用例設計很少，效率高，但是很復雜；
對于基本的驗證功能，以及二次集成引起的缺陷，一般都能找出來；但是更深的缺陷，更復雜的缺陷，還是無能為力的；
具體的環境下，正交表一般都很難做的，大多數，只在系統測驗的時候使用此方法，
5、描述使用bugzilla缺陷管理工具對軟體缺陷（BUG）跟蹤的管理的流程？
參考答案：
就是Bugzilla的狀態轉換圖，
6、描述測驗用例設計的完整程序？
參考答案：
需求分析 + 需求變更的維護作業；
根據需求 得出測驗需求；
設計測驗方案，評審測驗方案；
方案評審通過后，設計測驗用例，再對測驗用例進行評審；
7、單元測驗的策略有哪些？
參考答案：
邏輯覆寫、回圈覆寫、同行評審、桌前檢查、代碼走查、代碼評審、景泰資料流分析
8、什么是并發？在lordrunner中，如何進行并發的測驗？集合點失敗了會怎么樣？
參考答案：
在同一時間點，支持多個不同的操作，
LoadRunner中提供IP偽裝，集合點，配合虛擬用戶的設計，以及在多臺電腦上設定，可以比較好的模擬真實的并發，
集合點，即是多個用戶在某個時刻，某個特定的環境下同時進行虛擬用戶的操作的，集合點失敗，則集合點的才操作就會取消，測驗就不能進行，
9、QTP中的Action有什么作用？有幾種？
參考答案：
Action的作用
n 用Action可以對步驟集進行分組
n 步驟重組，然后被整體呼叫
n 擁有自己的sheet
n 組合有相同需求的步驟，整體操作
n 具有獨立的物件倉庫
Action的種類
n 可復用Action
n 不可復用Action
n 外部Action
10、你所熟悉的軟體測驗型別都有哪些？請試著分別比較這些不同的測驗型別的區別與聯系（如功能測驗、性能測驗……）？
參考答案：
Compatibility Testing（兼容性測驗），也稱“Configuration testing（配置測驗）”，兼容性測驗是將驗證軟體與其所依賴的環境的依賴程度，包括對硬體的依賴程度，對平臺軟體，其它軟體的依賴程度，來檢查程式能正常的運行的測驗
Functional testing (功能測驗)，也稱為behavioral testing（行為測驗）或黑盒測驗，根據產品特征、操作描述和用戶方案，測驗一個產品的特性和可操作行為以確定它們滿足設計需求，本地化軟體的功能測驗，用于驗證應用程式或網站對目標用戶能正確作業，使用適當的平臺、瀏覽器和測驗腳本，以保證目標用戶的體驗將足夠好，就像應用程式是專門為該市場開發的一樣，
Performance testing（性能測驗），性能測驗是指通過自動化的測驗工具模擬多種正常、峰值以及例外負載條件來對系統的各項性能指標進行測驗
主要包括以下三個方面：應用在客戶端性能的測驗，應用在網路上性能的測驗和應用在服務器端性能的測驗
11、Beta測驗與Alpha測驗有什么區別？
參考答案：
Beta testing(β測驗),測驗是軟體的多個用戶在一個或多個用戶的實際使用環境下進行的測驗，開發者通常不在測驗現場
Alpha testing (α測驗),是由一個用戶在開發環境下進行的測驗，也可以是公司內部的用戶在模擬實際操作環境下進行的受控測驗
12、測驗活動中，如果發現需求檔案不完善或者不準確，怎么處理？
參考答案：
應該立即和相關人員進行協調交流，
13、你認為做好測驗計劃作業的關鍵是什么？
參考答案：
軟體測驗計劃就是在軟體測驗作業正式實施之前明確測驗的物件，并且通過對資源、時間、風險、測驗范圍和預算等方面的綜合分析和規劃，保證有效的實施軟體測驗；
做好測驗計劃作業的關鍵 ：目的，管理，規范
14、一套完整的測驗應該由哪些階段組成？
參考答案：
測驗計劃、測驗設計與開發、測驗實施、測驗評審與測驗結論
15、單元測驗的主要內容？
模塊介面測驗、區域資料結構測驗、路徑測驗、錯誤處理測驗、邊界測驗
16、簡述集成測驗與系統測驗關系？
（1）集成測驗的主要依據概要設計說明書，系統測驗的主要依據是需求設計說明書；
（2）集成測驗是系統模塊的測驗，系統測驗是對整個系統的測驗，包括相關的軟硬體平臺、網路以及相關外設的測驗，
17、軟體系統中除用戶檔案之外，檔案測驗還應該關注哪些檔案？
參考答案：
開發檔案
軟體需求說明書
資料庫設計說明書
概要設計說明書
詳細設計說明書
可行性研究報告
管理檔案
專案開發計劃
測驗計劃
測驗報告
開發進度月報
開發總結報告
18、如何理解壓力、負載、性能測驗測驗？
參考答案：
性能測驗是一個較大的范圍，實際上性能測驗本身包含了性能、強度、壓力、負載等多方面的測驗內容，
壓力測驗是對服務器的穩定性以及負載能力等方面的測驗，是一種很平常的測驗，增大訪問系統的用戶數量、或者幾個用戶進行大資料量操作都是壓力測驗，而負載測驗是壓力相對較大的測驗，主要是測驗系統在一種或者集中極限條件下的相應能力，是性能測驗的重要部分，100個用戶對系統進行連續半個小時的訪問可以看作壓力測驗，那么連續訪問8個小時就可以認為負載測驗，1000個用戶連續訪問系統1個小時也可以看作是負載測驗，
實際上壓力測驗和負載測驗沒有明顯的區分，測驗人員應該站在關注整體性能的高度上來對系統進行測驗，
19、什么是系統瓶頸？
參考答案：
瓶頸主要是指整個軟硬體構成的軟體系統某一方面或者幾個方面能力不能滿足用戶的特定業務要求，“特定”是指瓶頸會在某些條件下會出現，因為畢竟大多數系統在投入前，
嚴格的從技術角度講，所有的系統都會有瓶頸，因為大多數系統的資源配置不是協調的，例如CPU使用率剛好達到100％時，記憶體也正好耗盡的系統不是很多見，因此我們討論系統瓶頸要從應用的角度討論：關鍵是看系統能否滿足用戶需求，在用戶極限使用系統的情況下，系統的回應仍然正常，我們可以認為改系統沒有瓶頸或者瓶頸不會影響用戶作業，
因此我們測驗系統瓶頸主要是實作下面兩個目的：
-發現“表面”的瓶頸，主要是模擬用戶的操作，找出用戶極限使用系統時的瓶頸，然后解決瓶頸，這是性能測驗的基本目標，
-發現潛在的瓶頸并解決，保證系統的長期穩定性，主要是考慮用戶在將來擴展系統或者業務發生變化時，系統能夠適應變化，滿足用戶目前需求的系統不是最好的，我們設計系統的目標是在保證系統整個軟體生命周期能夠不斷適應用戶的變化，或者通過簡單擴展系統就可以適應新的變化，
20、檔案測驗主要包含什么內容？
參考答案：
在國內軟體開發管理中，檔案管理幾乎是最弱的一項，因而在測驗作業中特別容易忽略檔案測驗也就不足為奇了，要想給用戶提供完整的產品，檔案測驗是必不可少的，檔案測驗一般注重下面幾個方面：
檔案的完整性：主要是測驗檔案內容的全面性與完整性，從總體上把握檔案的質量，例如用戶手冊應該包括軟體的所有功能模塊，
描述與軟體實際情況的一致性：主要測驗軟體檔案與軟體實際的一致程度，例如用戶手冊基本完整后，我們還要注意用戶手冊與實際功能描述是否一致，因為檔案往往跟不上軟體版本的更新速度，
易理解性：主要是檢查檔案對關鍵、重要的操作有無圖文說明，文字、圖表是否易于理解，對于關鍵、重要的操作僅僅只有文字說明肯定是不夠的，應該附有圖表使說明更為直觀和明了，
檔案中提供操作的實體：這項檢查內容主要針對用戶手冊，對主要功能和關鍵操作提供的應用實體是否豐富，提供的實體描述是否詳細，只有簡單的圖文說明，而無實體的用戶手冊看起來就像是軟體界面的簡單拷貝，對于用戶來說，實際上沒有什么幫助，
印刷與包裝質量：主要是檢查軟體檔案的商品化程度，有些用戶手冊是簡單列印、裝訂而成，過于粗糙，不易于用戶保存，優秀的檔案例如用戶手冊和技術白皮書，應提供商品化包裝，并且印刷精美，
21、功能測驗用例需要詳細到什么程度才是合格的？
參考答案：
這個問題也是測驗工程師經常問的問題，有人主張測驗用例詳細到每個步驟執行什么都要寫出來，目的是即使一個不了解系統的新手都可以按照測驗用例來執行作業，主張這類寫法的人還可以舉出例子：歐美、日本等軟體外包檔案都是這樣做的，
另外一種觀點就是主張寫的粗些，類似于撰寫測驗大綱，主張這種觀點的人是因為軟體開發需求管理不規范，變動十分頻繁，因而不能按照歐美的高標準來撰寫測驗用例，這樣的測驗用例容易維護，可以讓測驗執行人員有更大的發揮空間，
實際上，軟體測驗用例的詳細程度首先要以覆寫到測驗點為基本要求，舉個例子：“用戶登陸系統”的測驗用例可以不寫出具體的執行資料，但是至少要寫出五種以上情況（），如果只用一句話覆寫了這個功能是不合格的測驗用例，覆寫功能點不是指列出功能點，而是要寫出功能點的各個方面（如果組合情況較多時可以采用等價劃分），
另一個影響測驗用例的就是組織的開發能力和測驗物件特點，如果開發力量比較落后，撰寫較詳細的測驗用例是不現實的，因為根本沒有那么大的資源投入，當然這種情況很隨著團隊的發展而逐漸有所改善，測驗物件特點重點是指測驗物件在進度、成本等方面的要求，如果進度較緊張的情況下，是根本沒有時間寫出高質量的測驗用例的，甚至有些時候測驗作業只是一種輔助作業，因而不撰寫測驗用例，
因此，測驗用例的撰寫要根據測驗物件特點、團隊的執行能力等各個方面綜合起來決定撰寫策略，最后要注意的是測驗人員一定不能抱怨，力爭在不斷提高測驗用例撰寫水平的同時，不斷地提高自身能力，
22、配置和兼容性測驗的區別是什么？
參考答案：
配置測驗的目的是保證軟體在其相關的硬體上能夠正常運行，而兼容性測驗主要是測驗軟體能否與不同的軟體正確協作，
配置測驗的核心內容就是使用各種硬體來測驗軟體的運行情況，一般包括：
（1）軟體在不同的主機上的運行情況，例如Dell和Apple；
（2）軟體在不同的組件上的運行情況，例如開發的撥號程式要測驗在不同廠商生產的Modem上的運行情況；
（3）不同的外設；
（4）不同的介面；
（5）不同的可選項，例如不同的記憶體大小；
兼容性測驗的核心內容：
（1）測驗軟體是否能在不同的作業系統平臺上兼容；
（2）測驗軟體是否能在同一作業系統平臺的不同版本上兼容；
（3）軟體本身能否向前或者向后兼容；
（4）測驗軟體能否與其它相關的軟體兼容；
（5）資料兼容性測驗，主要是指資料能否共享；
配置和兼容性測驗通稱對開發系統類軟體比較重要，例如驅動程式、作業系統、資料庫管理系統等，具體進行時仍然按照測驗用例來執行，
23、軟體檔案測驗主要包含什么？
參考答案：
隨著軟體檔案系統日益龐大，檔案測驗已經成為軟體測驗的重要內容，檔案測驗物件主要如下：
-包裝文字和圖形；
-市場宣傳材料、廣告以及其它插頁；
-授權、注冊登記表；
-最終用戶許可協議；
-安裝和設定向導；
-用戶手冊；
-聯機幫助；
-樣例、示范例子和模板；
-……
檔案測驗的目的是提高易用性和可靠性，降低支持費用，因為用戶通過檔案就可以自己解決問題，因檔案測驗的檢查內容主要如下：
-讀者物件——主要是檔案的內容是否能讓該級別的讀者理解；
-術語——主要是檢查術語是否適合讀者；
-內容和主題——檢查主題是否合適、是否丟失、格式是否規范等；
-圖示和螢屏抓圖——檢查圖表的準確度和精確度；
-樣例和示例——是否與軟體功能一致；
-拼寫和語法；
-檔案的關聯性——是否與其它相關檔案的內容一致，例如與廣告資訊是否一致；
檔案測驗是相當重要的一項測驗作業，不但要給予充分的重視，更要要認真的完成，象做功能測驗一樣來對待檔案測驗，
24、沒有產品說明書和需求檔案地情況下能夠進行黑盒測驗嗎？
參考答案：
這個問題是國內測驗工程師經常遇到的問題，根源就是國內軟體開發檔案管理不規范，對變更的管理方法就更不合理了，實際上沒有任何檔案的時候，測驗人員是能夠進行黑盒測驗的，這種測驗方式我們可以稱之為探索測驗，具體做法就是測驗工程師根據自己的專業技能、領域知識等不斷的深入了解測驗物件、理解軟體功能，進而發現缺陷，
在這種做法基本上把軟體當成了產品說明書，測驗程序中要和開發人員不斷的進行交流，尤其在作專案的時候，進度壓力比較大，可以作為加急測驗方案，最大的風險是不知道有些特性是否被遺漏，
25、測驗中的“殺蟲劑怪事”是指什么？
參考答案：
“殺蟲劑怪事”一詞由BorisBeizer在其編著的《軟體測驗技術》第二版中提出，用于描述測驗人員對同一測驗物件進行的測驗次數越多，發現的缺陷就會越來越少的現象，就像老用一種農藥，害蟲就會有免疫力，農藥發揮不了效力，這種現象的根本原因就是測驗人員對測驗軟體過于熟悉，形成思維定勢，
為了克服這種現象，測驗人員需要不斷撰寫新的測驗程式或者測驗用例，對程式的不同部分進行測驗，以發現更多的缺陷，也可以參考新人來測驗軟體，剛剛進來的新手往往能發現一些意想不到的問題，
26、在配置測驗中，如何判斷發現的缺陷是普通問題還是特定的配置問題？
參考答案：
在進行配置測驗時，測驗工程師仍然會發現一些普通的缺陷，也就是與配置環境無關的缺陷，因此判斷新發現的問題，需要在不同的配置中重新執行發現軟體缺陷的步驟，如果軟體缺陷不出現了，就可能是配置缺陷；如果在所有的配置中都出現，就可能是普通缺陷，
需要注意的是，配置問題可以在一大類配置中出現，例如，撥號程式可能在所有的外置Modem中都存在問題，而內置的Modem不會有任何問題，
27、為什么盡量不要讓時間有富裕的員工去做一些測驗？
參考答案：
表面上看這體現了管理的效率和靈活性，但實際上也體現了管理者對測驗的輕視，測驗和測驗的人有很大關系，測驗作業人員應該是勤奮并富有耐心，善于學習、思考和發現問題，細心有條理，總結問題，如果具備這樣的優點，做其它作業同樣也會很出色，因此這里還有一個要求，就是要喜歡測驗這項作業，如果他是專職的，那么肯定更有經驗和信心，國內的小伙子好象都喜歡做程式員，兩者作業性質不同，待遇不同，地位不同，對自我實作的價值的認識也不同，這是行業的一個需要改善的問題，如果只是為了完成任務而完成任務，或者發現了幾個問題就覺得滿意了，這在任何其它作業中都是不行的，
28、完全測驗程式是可能的嗎？
參考答案：
軟體測驗初學者可能認為拿到軟體后需要進行完全測驗，找到全部的軟體缺陷，使軟體“零缺陷”發布，實際上完全測驗是不可能的，主要有以下一個原因：
-完全測驗比較耗時，時間上不允許；
-完全測驗通常意味著較多資源投入，這在現實中往往是行不通的；
-輸入量太大，不能一一進行測驗；
-輸出結果太多，只能分類進行驗證；
-軟體實作途徑太多；
-軟體產品說明書沒有客觀標準，從不同的角度看，軟體缺陷的標準不同；
因此測驗的程度要根據實際情況確定，
29、軟體測驗的風險主要體現在哪里？
參考答案：
我們沒有對軟體進行完全測驗，實際就是選擇了風險，因為缺陷極有可能存在沒有進行測驗的部分，舉個例子，程式員為了方便，在除錯程式時會彈出一些提示資訊框，而這些提示只在某種條件下會彈出，碰巧程式發布前這些代碼中的一些沒有被注釋掉，在測驗時測驗工程師又沒有對其進行測驗，如果客戶碰到它，這將是代價昂貴的缺陷，因為交付后才被客戶發現，
因此，我們要盡可能的選擇最合適的測驗量，把風險降低到最小，
30、發現的缺陷越多，說明軟體缺陷越多嗎？
參考答案：
這是一個比較常見的現象，測驗工程師在沒有找到缺陷前會絞盡腦汁的思考，但是找到一個后，會接二連三的發現很多缺陷，頗有個人成就感，其中的原因主要如下：
-代碼復用、拷貝代碼導致程式員容易犯相同的錯誤，類的繼承導致所有的子類會包含基類的錯誤，反復拷貝同一代碼意味可能也復制了缺陷，
-程式員比較勞累是可以導致某些連續撰寫的功能缺陷較多，程式員加班是一種司空見慣的現象，因此體力不只時容易撰寫一些缺陷較多的程式，而這些連續潛伏缺陷恰恰時測驗工程師大顯身手的地方，
“缺陷一個連著一個”不是一個客觀規律，只是一個常見的現象，如果軟體撰寫的比較好，這種現象就不常見了，測驗人員只要嚴肅認真的測驗程式就可以了，
31、所有的軟體缺陷都能修復嗎？所有的軟體缺陷都要修復嗎？
參考答案：
從技術上講，所有的軟體缺陷都是能夠修復的，但是沒有必要修復所有的軟體缺陷，測驗人員要做的是能夠正確判斷什么時候不能追求軟體的完美，對于整個專案團隊，要做的是對每一個軟體缺陷進行取舍，根據風險決定那些缺陷要修復，發生這種現象的主要原因如下：
-沒有足夠的時間資源，在任何一個專案中，通常情況下開發人員和測驗人員都是不夠用的，而且在專案中沒有預算足夠的回歸測驗時間，再加上修改缺陷可能引入新的缺陷，因此在交付期限的強大壓力下，必須放棄某些缺陷的修改，
-有些缺陷只是特殊情況下出現，這種缺陷處于商業利益考慮，可以在以后升級中進行修復，
-不是缺陷的缺陷，我們經常會碰到某些功能方面的問題被當成缺陷來處理，這類問題可以以后有時間時考慮再處理，
最后要說的是，缺陷是否修改要由軟體測驗人員、專案經理、程式員共同討論來決定是否修復，不同角色的人員從不同的角度來思考，以做出正確的決定，
32、軟體測驗人員就是QA嗎？
參考答案：
軟體測驗人員的職責是盡可能早的找出軟體缺陷，確保得以修復，而質量保證人員（QA）主要職責是創建或者制定標準和方法，提高促進軟體開發能力和減少軟體缺陷，測驗人員的主要作業是測驗，質量保證人員日常作業重要內容是檢查與評審，測驗作業也是測驗保證人員的作業物件，
軟體測驗和質量是相輔相成的關系，都是為了提高軟體質量而作業，
33、如何減少測驗人員跳槽帶來的損失？
參考答案：
在IT行業里跳槽已經是一種司空見慣的現象，而且跳槽無論給公司還是給個人都會帶來一定的損失，測驗隊伍也無疑會面臨跳槽的威脅，作為測驗經理管理者，只有從日常作業中開始做起，最能最大限度的減少損失，建議我們從以下兩個方面做起：
-加強部門內員工之間的互相學習，互相學習是建立學習型組織的基本要求，是知識互相轉移的程序，在此基礎上，可以把個人擁有的技術以知識的形式沉積下來，也就完成了隱性知識到顯性知識的轉化，
-通常情況下，企業能為員工提供足夠大的發展空間時，如果不是待遇特別低，員工都不會主動離開企業，因此我們要想留住員工，管理者就應該把員工的個人成長和企業的發展聯系起來，為員工設定合理發展規劃并付諸實作，不過這項要求做起來比較，要有比較好的企業文化為依托，
34、測驗產品與測驗專案的區別是什么？
參考答案：
習慣上把開發完成后進行商業化、幾乎不進行代碼修改就可以售給用戶使用的軟體成為軟體產品，也就是可以買“賣拷貝”的軟體，例如Windows2000，而通常把針對一個或者幾個特定的用戶而開發的軟體成為軟體專案，軟體專案是一種個性化的產品，可以是按照用戶要求全部重新開發，也可以修改已有的軟體產品來滿足特定的用戶需求，專案和產品的不同特點，決定我們測驗產品和測驗專案仍然會有很多不同的地方：
-質量要求不同，通常產品的質量要高一些，修復發布后產品的缺陷成本較高，甚至會帶來很多負面的影響，而做專案通常面向某一用戶，雖然質量越高越好，但是一般只要滿足用戶要求就可以了，
-測驗資源投入多少不同，做軟體產品通常是研發中心來開發，進度壓力要小些，同時由于質量要求高，因此會投入較多的人力、物力資源，
-專案最后要和用戶共同驗收測驗，這是產品測驗不具有的特點，
此外，測驗產品與測驗專案在缺陷管理方面、測驗策略制定都會有很大不同，測驗管理者應該結合具體的環境，恰如其分的完成作業，
35、和用戶共同測驗（UAT測驗）的注意點有哪些？
參考答案：
軟體產品在投產前，通常都會進行用戶驗收測驗，如果用戶驗收測驗沒有通過，直接結果就是那不到“Money”，間接影響是損害了公司的形象，而后者的影響往往更嚴重，根據作者的經驗，用戶驗收測驗一定要讓用戶滿意，
實際上用戶現場測驗更趨于是一種演示，在不欺騙用戶的前提下，我們向用戶展示我們軟體的優點，最后讓“上帝”滿意并欣然掏出“銀子”才是我們的目標，因此用戶測驗要注意下面的事項：
（1）用戶現場測驗不可能測驗全部功能，因此要測驗核心功能，這需要提前做好準備，這些核心功能一定要預先經過測驗，證明沒有問題才可以和用戶共同進行測驗，測驗核心模塊的目的是建立用戶對軟體的信心，當然如果這些模塊如果問題較多，不應該進行演示，
（2）如果某些模塊確實有問題，我們可以演示其它重要的業務功能模塊，必要時要向用戶做成合理的解釋，爭得時間后，及時修改缺陷來彌補，
（3）永遠不能欺騙用戶，蒙混過關，道理很簡單，因為軟體是要給用戶用的，問題早晚會暴露出來，除非你可以馬上修改，
和用戶進行測驗還要注意各種交流技巧，爭取不但短期利益得到了滿足，還要為后面得合作打好基礎，
36、如何撰寫提交給用戶的測驗報告？
參考答案：
隨著測驗作業越來越受重視，開發團隊向客戶提供測驗檔案是不可避免的事情，很多人會問：“我們可以把作業中的測驗報告提供給客戶嗎？”答案是否定的，因為提供內部測驗報告，可能會讓客戶失去信心，甚至否定專案，
測驗報告一般分為內部測驗報告和外部測驗報告，內部報告是我們在測驗作業中的專案檔案，反映了測驗作業的實施情況，這里不過多討論，讀者可以參考相關教材，這里主要討論一下外部測驗報告的寫法，一般外部測驗報告要滿足下面幾個要求：
-根據內部測驗報告進行撰寫，一般可以摘錄；
-不可以向客戶報告嚴重缺陷，即使是已經修改的缺陷，開發中的缺陷也沒有必要讓客戶知道；
-報告上可以列出一些缺陷，但必須是中級的缺陷，而且這些缺陷必須是修復的；
-報告上面的內容盡量要真實可靠；
-整個測驗報告要仔細審閱，力爭不給專案帶來負面作用，尤其是性能測驗報告，
總之，外部測驗報告要小心謹慎的撰寫，
37、測驗工具在測驗作業中是什么地位？
參考答案：
國內的很多測驗工程師對測驗工具相當迷戀，尤其是一些新手，甚至期望測驗工具可以取代手工測驗，測驗工具在測驗作業中起的是輔助作用，一般用來提高測驗效率，自動化測驗彌補了手工測驗的不足，減輕一定的作業量，實際上測驗工具是無法替代大多數手工測驗的，而一些諸如性能測驗等自動化測驗也是手工所不能完成的，
對于自動測驗技術，應當依據軟體的不同情況來分別對待，一般自動技識訓應用在引起大量重復性作業的地方、系統的壓力點、以及任何適合使用程式解決大批量輸入資料的地方，然后再尋找合適的自動測驗工具，或者自己開發測驗程式，一定不要為了使用測驗工具而使用，
38、什么是軟體測驗，軟體測驗的目的？
參考答案：
39、簡述負載測驗與壓力測驗的區別，
參考答案：
壓力測驗（Stress Testing）
壓力測驗的主要任務就是獲取系統正確運行的極限，檢查系統在瞬間峰值負荷下正確執行的能力，例如，對服務器做壓力測驗時就可以增加并發操作的用戶數量；或者不停地向服務器發送請求；或一次性向服務器發送特別大的資料等，看看服務器保持正常運行所能達到的最大狀態，人們通常使用測驗工具來完成壓力測驗，如模擬上萬個用戶從終端同時登錄，這是壓力測驗中常常使用的方法，
負載測驗（Volume Testing）
用于檢查系統在使用大量資料的時候正確作業的能力，即檢驗系統的能力最高能達到什么程度，例如，對于資訊檢索系統，讓它使用頻率達到最大；對于多個終端的分時系統，讓它所有的終端都開動，在使整個系統的全部資源達到“滿負荷”的情形下，測驗系統的承受能力，
40、寫出bug報告流轉的步驟，每步的責任人及主要完成的作業，
參考答案：
（要結合自己實際的作業經驗進行回答，不同公司略有區別）
測驗人員提交新的Bug入庫，錯誤狀態為New，
高級測驗員/測驗經理驗證錯誤，如果確認是錯誤，分配給開發組，設定狀態為Open，如果不是錯誤，則拒絕，設定為Declined狀態，
開發經理分配bug至對應的模塊開發人員，
開發人員查詢狀態為Open的Bug，如果不是錯誤，則置狀態為Declined；如果是Bug則修復并置狀態為Fixed，不能解決的Bug，要留下文字說明及保持Bug為Open狀態，
對于不能解決和延期解決的Bug，不能由開發人員自己決定，一般要通過某種會議（評審會）通過才能認可，
測驗人員查詢狀態為Fixed的Bug，然后驗證Bug是否已解決，如解決，置Bug的狀態為Closed，如沒有解決,置bug狀態為Reopen，
41、寫出bug報告當中一些必備的內容，
參考答案：
硬體平臺和作業系統
測驗應用的硬體平臺（Platform），通常選擇“PC”，
測驗應用的作業系統平臺（OS），
a) 版本
提交缺陷報告時通過該欄位標識此缺陷存在于被測驗軟體的哪個版本，
b) Bug報告優先級
c) Bug狀態
d) Bug的編號
e) 發現人
f) 提交人
g) 指定處理人
h) 概述
i) 從屬關系
j) 詳細描述
k) 嚴重程度
l) 所屬模塊
m) 附件
n) 提交日期
42、開發人員老是犯一些低級錯誤怎么解決？
參考答案：
這種現象在開發流程不規范的團隊里特別常見，尤其是一些“作坊式”的團隊里，解決這種問題一般從兩個方面入手：
一方面從開發管理入手，也就是從根源來解決問題，可以制定規范的開發流程，甚至可以制定懲罰制度，還有就是軟體開發前做好規劃設計，
另一方面就是加強測驗，具體做法就是加強開發人員的自己測驗，把這些問題“消滅”在開發階段，這是比較好的做法，讀者可以參考第13章試案例分析的“13.1.2缺陷反復出現，誰的責任”小節，13.1.2專門討論了這類問題的方法，
此外，還可以通過規范的缺陷管理來對開發人員進行控制，比如測驗部門整理出常見的缺陷，讓開發人員自己對照進行檢查，以減少這類低級錯誤的發生，
開發人員犯錯誤是正常的現象，作為測驗人員一定不能抱怨，要認認真真的解決問題才是上策，
43、畫出軟體測驗的V模型圖，
參考答案：
44、為什么要在一個團隊中開展軟體測驗作業？
參考答案：
因為沒有經過測驗的軟體很難在發布之前知道該軟體的質量，就好比ISO質量認證一樣，測驗同樣也需要質量的保證，這個時候就需要在團隊中開展軟體測驗的作業，在測驗的程序發現軟體中存在的問題，及時讓開發人員得知并修改問題，在即將發布時，從測驗報告中得出軟體的質量情況，
45、您在以往的測驗作業中都曾經具體從事過哪些作業？其中最擅長哪部分作業？
參考答案：
（根據專案經驗不同，靈活回答即可）
我曾經做過web測驗，后臺測驗，客戶端軟體，其中包括功能測驗，性能測驗，用戶體驗測驗，最擅長的是功能測驗
46、您所熟悉的軟體測驗型別都有哪些？請試著分別比較這些不同的測驗型別的區別與聯系（如功能測驗、性能測驗……）
參考答案：
測驗型別有：功能測驗，性能測驗，界面測驗，
功能測驗在測驗作業中占的比例最大，功能測驗也叫黑盒測驗，是把測驗物件看作一個黑盒子，利用黑盒測驗法進行動態測驗時，需要測驗軟體產品的功能，不需測驗軟體產品的內部結構和處理程序，采用黑盒技術設計測驗用例的方法有：等價類劃分、邊界值分析、錯誤推測、因果圖和綜合策略，
性能測驗是通過自動化的測驗工具模擬多種正常、峰值以及例外負載條件來對系統的各項性能指標進行測驗，負載測驗和壓力測驗都屬于性能測驗，兩者可以結合進行，通過負載測驗，確定在各種作業負載下系統的性能，目標是測驗當負載逐漸增加時，系統各項性能指標的變化情況，壓力測驗是通過確定一個系統的瓶頸或者不能接收的性能點，來獲得系統能提供的最大服務級別的測驗，
界面測驗，界面是軟體與用戶互動的最直接的層，界面的好壞決定用戶對軟體的第一印象，而且設計良好的界面能夠引導用戶自己完成相應的操作，起到向導的作用，同時界面如同人的面孔，具有吸參考戶的直接優勢，設計合理的界面能給用戶帶來輕松愉悅的感受和成功的感覺，相反由于界面設計的失敗，讓用戶有挫敗感，再實用強大的功能都可能在用戶的畏懼與放棄中付諸東流，
區別在于，功能測驗關注產品的所有功能上，要考慮到每個細節功能，每個可能存在的功能問題，性能測驗主要關注于產品整體的多用戶并發下的穩定性和健壯性，界面測驗更關注于用戶體驗上，用戶使用該產品的時候是否易用，是否易懂，是否規范（快捷鍵之類的），是否美觀（能否吸參考戶的注意力），是否安全（盡量在前臺避免用戶無意輸入無效的資料，當然考慮到體驗性，不能太粗魯的彈出警告）？做某個性能測驗的時候，首先它可能是個功能點，首先要保證它的功能是沒問題的，然后再考慮該功能點的性能測驗
47、您認為做好測驗用例設計作業的關鍵是什么？
參考答案：
白盒測驗用例設計的關鍵是以較少的用例覆寫盡可能多的內部程式邏輯結果
黑盒法用例設計的關鍵同樣也是以較少的用例覆寫模塊輸出和輸入介面，不可能做到完全測驗，以最少的用例在合理的時間內發現最多的問題
48、請試著比較一下黑盒測驗、白盒測驗、單元測驗、集成測驗、系統測驗、驗收測驗的區別與聯系，
參考答案：
黑盒測驗：已知產品的功能設計規格，可以進行測驗證明每個實作了的功能是否符合要求，
白盒測驗：已知產品的內部作業程序，可以通過測驗證明每種內部操作是否符合設計規格要求，所有內部成分是否以經過檢查，
軟體的黑盒測驗意味著測驗要在軟體的介面處進行，這種方法是把測驗物件看做一個黑盒子，測驗人員完全不考慮程式內部的邏輯結構和內部特性，只依據程式的需求規格說明書，檢查程式的功能是否符合它的功能說明，因此黑盒測驗又叫功能測驗或資料驅動測驗，黑盒測驗主要是為了發現以下幾類錯誤：
1、是否有不正確或遺漏的功能？
2、在介面上，輸入是否能正確的接受？能否輸出正確的結果？
3、是否有資料結構錯誤或外部資訊（例如資料檔案）訪問錯誤？
4、性能上是否能夠滿足要求？
5、是否有初始化或終止性錯誤？
軟體的白盒測驗是對軟體的程序性細節做細致的檢查，這種方法是把測驗物件看做一個打開的盒子，它允許測驗人員利用程式內部的邏輯結構及有關資訊，設計或選擇測驗用例，對程式所有邏輯路徑進行測驗，通過在不同點檢查程式狀態，確定實際狀態是否與預期的狀態一致，因此白盒測驗又稱為結構測驗或邏輯驅動測驗，白盒測驗主要是想對程式模塊進行如下檢查：
1、對程式模塊的所有獨立的執行路徑至少測驗一遍，
2、對所有的邏輯判定，取“真”與取“假”的兩種情況都能至少測一遍，
3、在回圈的邊界和運行的界限內執行回圈體，
4、測驗內部資料結構的有效性，等等，
單元測驗（模塊測驗）是開發者撰寫的一小段代碼，用于檢驗被測代碼的一個很小的、很明確的功能是否正確，通常而言，一個單元測驗是用于判斷某個特定條件（或者場景）下某個特定函式的行為，
單元測驗是由程式員自己來完成，最終受益的也是程式員自己，可以這么說，程式員有責任撰寫功能代碼，同時也就有責任為自己的代碼撰寫單元測驗，執行單元測驗，就是為了證明這段代碼的行為和我們期望的一致，
集成測驗（也叫組裝測驗，聯合測驗）是單元測驗的邏輯擴展，它的最簡單的形式是：兩個已經測驗過的單元組合成一個組件，并且測驗它們之間的介面，從這一層意義上講，組件是指多個單元的集成聚合，在現實方案中，許多單元組合成組件，而這些組件又聚合成程式的更大部分，方法是測驗片段的組合，并最終擴展行程，將您的模塊與其他組的模塊一起測驗，最后，將構成行程的所有模塊一起測驗，
系統測驗是將經過測驗的子系統裝配成一個完整系統來測驗，它是檢驗系統是否確實能提供系統方案說明書中指定功能的有效方法，（常見的聯調測驗）
系統測驗的目的是對最終軟體系統進行全面的測驗，確保最終軟體系統滿足產品需求并且遵循系統設計，
驗收測驗是部署軟體之前的最后一個測驗操作，驗收測驗的目的是確保軟體準備就緒，并且可以讓最終用戶將其用于執行軟體的既定功能和任務，
驗收測驗是向未來的用戶表明系統能夠像預定要求那樣作業，經集成測驗后，已經按照設計把所有的模塊組裝成一個完整的軟體系統，介面錯誤也已經基本排除了，接著就應該進一步驗證軟體的有效性，這就是驗收測驗的任務，即軟體的功能和性能如同用戶所合理期待的那樣，
49、測驗計劃作業的目的是什么？測驗計劃作業的內容都包括什么？其中哪些是最重要的？
參考答案：
軟體測驗計劃是指導測驗程序的綱領性檔案，包含了產品概述、測驗策略、測驗方法、測驗區域、測驗配置、測驗周期、測驗資源、測驗交流、風險分析等內容，借助軟體測驗計劃，參與測驗的專案成員，尤其是測驗管理人員，可以明確測驗任務和測驗方法，保持測驗實施程序的順暢溝通，跟蹤和控制測驗進度，應對測驗程序中的各種變更，
測驗計劃和測驗詳細規格、測驗用例之間是戰略和戰術的關系，測驗計劃主要從宏觀上規劃測驗活動的范圍、方法和資源配置，而測驗詳細規格、測驗用例是完成測驗任務的具體戰術，所以其中最重要的是測驗測驗策略和測驗方法（最好是能先評審）
50、您所熟悉的測驗用例設計方法都有哪些？請分別以具體的例子來說明這些方法在測驗用例設計作業中的應用，
參考答案：
1．等價類劃分
劃分等價類: 等價類是指某個輸入域的子集合.在該子集合中,各個輸入資料對于揭露程式中的錯誤都是等效的.并合理地假定:測驗某等價類的代表值就等于對這一類其它值的測驗.因此,可以把全部輸入資料合理劃分為若干等價類,在每一個等價類中取一個資料作為測驗的輸入條件,就可以用少量代表性的測驗資料.取得較好的測驗結果.等價類劃分可有兩種不同的情況:有效等價類和無效等價類.
2．邊界值分析法
邊界值分析方法是對等價類劃分方法的補充，測驗作業經驗告訴我,大量的錯誤是發生在輸入或輸出范圍的邊界上,而不是發生在輸入輸出范圍的內部.因此針對各種邊界情況設計測驗用例,可以查出更多的錯誤.
使用邊界值分析方法設計測驗用例,首先應確定邊界情況.通常輸入和輸出等價類的邊界,就是應著重測驗的邊界情況.應當選取正好等于,剛剛大于或剛剛小于邊界的值作為測驗資料,而不是選取等價類中的典型值或任意值作為測驗資料.
3．錯誤推測法
基于經驗和直覺推測程式中所有可能存在的各種錯誤, 從而有針對性的設計測驗用例的方法.
錯誤推測方法的基本思想: 列舉出程式中所有可能有的錯誤和容易發生錯誤的特殊情況,根據他們選擇測驗用例. 例如, 在單元測驗時曾列出的許多在模塊中常見的錯誤. 以前產品測驗中曾經發現的錯誤等, 這些就是經驗的總結. 還有, 輸入資料和輸出資料為0的情況. 輸入表格為空格或輸入表格只有一行. 這些都是容易發生錯誤的情況. 可選擇這些情況下的例子作為測驗用例.
4．因果圖方法
前面介紹的等價類劃分方法和邊界值分析方法,都是著重考慮輸入條件,但未考慮輸入條件之間的聯系, 相互組合等. 考慮輸入條件之間的相互組合,可能會產生一些新的情況. 但要檢查輸入條件的組合不是一件容易的事情, 即使把所有輸入條件劃分成等價類,他們之間的組合情況也相當多. 因此必須考慮采用一種適合于描述對于多種條件的組合,相應產生多個動作的形式來考慮設計測驗用例. 這就需要利用因果圖（邏輯模型）. 因果圖方法最終生成的就是判定表. 它適合于檢查程式輸入條件的各種組合情況.
51、請以您以往的實際作業為例，詳細的描述一次測驗用例設計的完整的程序，
參考答案：
就說最近的這次網站功能的測驗吧
首先： 得到相關檔案（需求檔案和設計檔案），理解需求和設計設計思想后，想好測驗策略（測驗計劃簡單點就OK了），考慮到測驗環境，測驗用例，測驗時間等問題，
第二步： 設計測驗用例，測驗策略是：把網站部分的功能點測驗完，然后在進行系統測驗（另外個模塊呢有另一個測驗人員負責，可以進行聯調測驗），網站模塊的測驗基本是功能測驗和界面測驗（用戶并發的可能性很小，所以不考慮）：這次的網站的輸入資料呢是使用資料庫中的某張表記錄，如果表中某一資料記錄中新加進來的（還沒有被處理的，有個標志位），網站啟動后會立刻去刷那張表，得到多條資料，然后在進行處理，處理程序中，會經歷3個步驟，網站才算完成了它的任務，有3個步驟呢，就可以分別對 這3個步驟進行測驗用例的設計,盡量覆寫到各種輸入情況（包括資料庫中的資料，用戶的輸入等），得出了差不多50個用例，界面測驗，也就是用戶看的到的地方，包括發送的郵件和用戶填寫資料的頁面展示，
第三步： 搭建測驗環境（為什么這個時候考慮測驗環境呢？因為我對網站環境已經很熟了，只有有機器能空于下來做該功能測驗就可以做了），因為網站本身的環境搭建和其他的系統有點不同，它需要的測驗環境比較麻煩，需要web服務器（Apache,tomcat），不過這次需求呢，網站部分只用到了tomcat，所以只要有tomcat即可
第四步： 執行測驗
52、您以往是否曾經從事過性能測驗作業？如果有，請盡可能的詳細描述您以往的性能測驗作業的完整程序，
參考答案：（以自己最熟悉的性能測驗專案為例）
是的，曾經做過網站方面的性能測驗，雖然做的時間并不久（2個月吧），當時呢，是有位網站性能測驗經驗非常豐富的前輩帶著我一起做，
性能測驗型別包括負載測驗，強度測驗，容量測驗等
負載測驗：負載測驗是一種性能測驗指資料在超負荷環境中運行，程式是否能夠承擔，
強度測驗： 強度測驗是一種性能測驗，他在系統資源特別低的情況下軟體系統運行情況
容量測驗：確定系統可處理同時在線的最大用戶數
在網站流量逐漸加大的情況下，開始考慮做性能測驗了，首先要寫好性能測驗計劃，根據運營資料得出流量最大的頁面（如果是第一次的話，一般是首頁，下載頁，個人帳戶頁流量最大，而且以某種百分比），
Web服務器指標指標：
- Avg Rps: 平均每秒鐘回應次數＝總請求時間 / 秒數；
- Successful Rounds：成功的請求；
- Failed Rounds ：失敗的請求；
- Successful Hits ：成功的點擊次數；
- Failed Hits ：失敗的點擊次數；
- Hits Per Second ：每秒點擊次數；
- Successful Hits Per Second ：每秒成功的點擊次數；
- Failed Hits Per Second ：每秒失敗的點擊次數；
- Attempted Connections ：嘗試鏈接數；
53、你對測驗最大的興趣在哪里？為什么？
參考答案：
最大的興趣就是測驗有難度，有挑戰性！做測驗越久越能感覺到做好測驗有多難，曾經在無憂測驗網上看到一篇文章，是關于如何做好一名測驗工程師，一共羅列了11，12點，有部分是和人的性格有關，有部分需要后天的努力，但除了性格有關的1，2點我沒有把握，其他點我都很有信心做好它，
剛開始進入測驗行業時，對測驗的認識是從無憂測驗網上了解到的一些資料，當時是沖著做測驗需要很多技能才能做的好，雖然入門容易，但做好很難，比開發更難，雖然當時我很想做開發（學校專業課我基本上不缺席，因為我喜歡我的專業），但看到測驗比開發更難更有挑戰性，想做好測驗的意志就更堅定了，
不到一年半的測驗作業中，當時的感動和熱情沒有減退一點（即使環境問題以及自身經驗，技術的不足，做測驗的你一定也能理解），
我覺得做測驗整個程序中有2點讓我覺得很有難度（對我來說，有難度的東西我就非常感興趣），第一是測驗用例的設計，因為測驗的精華就在測驗用例的設計上了，要在版本出來之前，把用例寫好，用什么測驗方法寫？（也就是測驗計劃或測驗策略），如果你剛測驗一個新任務時，你得花一定的時間去消化業務需求和技識訓礎，業務需求很好理解（多和產品經理和開發人員溝通就能達到目的），而技識訓礎可就沒那么簡單了，這需要你自覺的學習能力，比如說網站吧，最基本的技術知識你要知道網站內部是怎么運作的的，后臺是怎么回應用戶請求的？測驗環境如何搭建？這些都需要最早的學好，至少在開始測驗之前能做好基本的準備，可能會遇到什么難題？需求細節是不是沒有確定好？這些問題都能在設計用例的時候發現，
第二是發現BUG的時候了，這應該是測驗人員最基本的任務了，一般按測驗用例開始測驗就能發現大部分的bug，還有一部分bug需要測驗的程序中更了解所測版本的情況獲得更多資訊，補充測驗用例，測驗出bug，還有如何發現bug？這就需要在測驗用例有效的情況下，通過細心和耐心去發現bug了，每個用例都有可能發現bug，每個地方都有可能出錯，所以測驗程序中思維要清晰（測驗程序資料流及結果都得看仔細了，bug都在里面發現的），如何描述bug也很有講究，bug在什么情況下會產生，如果條件變化一點點，就不會有這個bug，以哪些最少的操作步驟就能重現這個bug，這個bug產生的規律是什么？如果你夠厲害的話，可以幫開發人員初步定位問題，
54、你以前作業時的測驗流程是什么？
參考答案：
（靈活回答）
公司對測驗流程沒有規定如何做，但每個測驗人員都有自己的一套測驗流程，我說下我1年來不斷改正（自己總結，吸取同行的方法）后的流程吧，需求評審（有開發人員，產品經理，測驗人員，專案經理）－>需求確定(出一份確定的需求檔案)－>開發設計檔案（開發人員在開始寫代碼前就能輸出設計檔案）－>想好測驗策略，寫出測驗用例－>發給開發人員和測驗經理看看（非正式的評審用例）－>接到測驗版本－>執行測驗用例（中間可能會補充用例）－>提交bug（有些bug需要開發人員的確定（嚴重級別的，或突然發現的在測驗用例范圍之外的，難以重現的），有些可以直接錄制進TD）－>開發人員修改（可以在測驗程序中快速的修改）－>回歸測驗（可能又會發現新問題，再按流程開始跑），
55、當開發人員說不是BUG時，你如何應付？
參考答案：
開發人員說不是bug，有2種情況，一是需求沒有確定，所以我可以這么做，這個時候可以找來產品經理進行確認，需不需要改動，3方商量確定好后再看要不要改，二是這種情況不可能發生，所以不需要修改，這個時候，我可以先盡可能的說出是BUG的依據是什么？如果被用戶發現或出了問題，會有什么不良結果？程式員可能會給你很多理由，你可以對他的解釋進行反駁，如果還是不行，那我可以給這個問題提出來,跟開發經理和測驗經理進行確認,如果要修改就改,如果不要修改就不改，其實有些真的不是bug，我也只是建議的方式寫進TD中，如果開發人員不修改也沒有大問題，如果確定是bug的話，一定要堅持自己的立場，讓問題得到最后的確認，
56、軟體的構造號與版本號之間的區別？BVT(BuildVerificationTest)
參考答案：版本控制命名格式: 主版本號.子版本號[.修正版本號[.編譯版本號 ]]
Major.Minor [.Revision[.Build]]
應根據下面的約定使用這些部分：
Major ：具有相同名稱但不同主版本號的程式集不可互換，例如，這適用于對產品的大量重寫，這些重寫使得無法實作向后兼容性，
Minor ：如果兩個程式集的名稱和主版本號相同，而次版本號不同，這指示顯著增強，但照顧到了向后兼容性，例如，這適用于產品的修正版或完全向后兼容的新版本，
Build ：內部版本號的不同表示對相同源所作的重新編譯，這適合于更改處理器、平臺或編譯器的情況，
Revision ：名稱、主版本號和次版本號都相同但修訂號不同的程式集應是完全可互換的，這適用于修復以前發布的程式集中的安全漏洞，
BVT(BuildVerificationTest)：
作為Build的一部分，主要是通過對基本功能、特別是關鍵功能的測驗，保證新增代碼沒有導致功能失效，保證版本的持續穩定，實作BVT方式是有以下幾種：1、測驗人員手工驗證關鍵功能實作的正確性，特點：這是傳統開發方法中，通常采用的方式，無需維護測驗腳本的成本，在測驗人力資源充足，測驗人員熟悉業務、并對系統操作熟練情況下效率很高，比較靈活快速，缺點：人力成本較高；對測驗人員能力有一定要求；測驗人員面對重復的作業，容易產生疲倦懈怠，從而影響測驗質量，2、借助基于GUI的自動化功能測驗工具來完成，將各基本功能操作錄制成測驗腳本，每次回放測驗腳本驗證功能實作的正確性，特點：能夠模擬用戶操作完成自動的測驗，從UI入口到業務實作，每一層的代碼實作都經過驗證；節約人力成本；降低測驗人員重復勞動的作業量，機器不會疲倦；缺點：對于UI變動比較頻繁的系統來說，這種方式的維護成本很高，實施起來非常困難，另外，在專案周期較短且后續無延續性或繼承的情況下，也不推薦使用此方式，3、由開發人員通過自動化測驗工具完成業務層的BVT測驗，特點：通過對業務層關鍵功能的持續集成測驗，保證系統功能的持續穩定，可以結合DailyBuild，做為Build的一部分，自動實作并輸入BVT報告，缺點：僅對業務規則實作的正確性進行了測驗，對表現層無法測驗到，對于諸如：前臺頁面控制元件各種事件回應、頁面元素變化等方面的問題無法保證，
57、您以往的作業中，一條軟體缺陷（或者叫Bug）記錄都包含了哪些內容？如何提交高質量的軟體缺陷（Bug）記錄？
參考答案：
58、您以往所從事的軟體測驗作業中，是否使用了一些工具來進行軟體缺陷（Bug）的管理？如果有，請結合該工具描述軟體缺陷（Bug）跟蹤管理的流程，
參考答案：
59、您認為性能測驗作業的目的是什么？做好性能測驗作業的關鍵是什么？
參考答案：
60、單元測驗、集成測驗、系統測驗的側重點是什么？
參考答案：
61、集成測驗通常都有那些策略？
參考答案：
62、一個缺陷測驗報告的組成
參考答案：
63、基于WEB資訊管理系統測驗時應考慮的因素有哪些？
參考答案：
64、軟體測驗專案從什么時候開始，？為什么？
參考答案：
65、需求測驗注意事項有哪些？
參考答案：
66、簡述一下缺陷的生命周期
參考答案：
67、你在你所在的公司是怎么開展測驗作業的？是如何組織的？
參考答案：
68、你認為理想的測驗流程是什么樣子？
參考答案：
69、您在從事性能測驗作業時，是否使用過一些測驗工具？如果有，請試述該工具的作業原理，并以一個具體的作業中的例子描述該工具是如何在實際作業中應用的，
參考答案：
70、軟體測驗活動的生命周期是什么？
參考答案：
71、請畫出軟體測驗活動的流程圖？
參考答案：
72、針對缺陷采取怎樣管理措施？
參考答案：
73、什么是測驗評估？測驗評估的范圍是什么？
參考答案：
74、如果能夠執行完美的黑盒測驗，還需要進行白盒測驗嗎？為什么？
參考答案：
75、測驗結束的標準是什么？
參考答案：
76、軟體驗收測驗除了alpha ,beta測驗以外,還有哪一種?
參考答案：
77、做測驗多久了？以前做過哪些專案？你們以前測驗的流程是怎樣的？用過哪些測驗工具？
參考答案：
78、請就如何在開發中進行軟體質量控制說說你的看法
參考答案：
79、一套完整的測驗應該由哪些階段組成？分別闡述一下各個階段，
80、軟體測驗的型別有那些？分別比較這些不同的測驗型別的區別與聯系，
81、測驗用例通常包括那些內容？著重闡述編制測驗用例的具體做法
82、在分別測驗winform的C/S結構與測驗WEB結構的軟體是，應該采取什么樣的方法分別測驗？他們存在什么樣的區別與聯系？
83、在測驗winform的C/S結構軟體時，發現這個軟體的運行速度很慢，您會認為是什么原因？您會采取哪些方法去檢查這個原因？
84、描述使用bugzilla缺陷管理工具對軟體缺陷（BUG）跟蹤的管理的流程
85、你都用什么測驗方法
針對不同的產品或者系統或者模塊，有不同的測驗方法，總體而言有白盒測驗和黑盒測驗，
86、怎么撰寫案例
案例的撰寫與測驗階段的定義有很大的關系，系統測驗和unit測驗的案例可能不同，總體而言測驗案例根據系統的需求而定，
87、怎么才能夠全面的測驗到每一個點
測驗的全面性主要需要在設計測驗計劃的時候考慮，從測驗策略，產品需求等等多個角度考慮從而定義全部的測驗點，
88、談談軟體測驗技術，以及如何提高
89、談談軟體測驗職業發展，以及個人的打算
90、談談軟體測驗在企業的地位，也可以結合軟體生命周期來談
91、一般公司里實際的軟體測驗流程是什么樣的？你們公司又是怎樣的？
92、軟體工程師要具有那些素質？
93、你會哪些測驗工具？怎么操作？
94、你能不能說下你的3到5年的職業計劃（規劃）
95、你覺得你來應聘有那些優勢？
96、你怎樣做出自己的職業選擇？
參考答案：
分析 面試人提出這個問題是為了了解求職者的動機，看看他（她）應聘這份作業是否有什么歷史淵源，是否有職業規劃，是不是僅僅在漫無目的地申請很多作業， 錯誤回答 我一直都想在企業界作業，自孩提時代起，我就夢想自己至少也要成為大企業的副總裁， 評論 除了難以令人相信之外，這種回答還存在一個問題：它表明求職者會對副總裁以下的職位不感興趣， 正確回答 在上大學四年級前的那個夏天，我決定集中精力在某一領域謀求發展，盡管我是學商業的，但是我不知道自己最侄訓從事哪一行業的作業，我花了一定的時間考慮自己的目標，想清楚了自己擅長做的事情以及想從作業中得到的東西，最后我得出了一個堅定的結論，那就是這個行業是最適合我的， 評論 這種回答表明，求職者認真地做過一些計劃，縮小了自己的關注點，而且也認準了前進的方向，這種回答還表明，求職者理解個人職業規劃的重要性，并且有能力做出認真的個人決策，
更多其他問題：（有可能清晰的思路比確切的答案更重要）關注我，分享更多技術、面試資料，群里還有同行一起交流技術，（目前免費）
如果你
①從事功能測驗，想進階自動化測驗
②在測驗界混了1、2年，依然不會敲代碼
③面試大廠卻屢屢碰壁
我邀你進群吧！來吧~~測驗員，313782132（Q群里有技術大牛一起交流分享，學習資源的價值取決于你的行動，莫做“收藏家”）獲取更多大廠技術、面試資料
如果對python自動化測驗、web自動化、介面自動化、移動端自動化、面試經驗交流等等感興趣的測驗人，可以關注微信公眾號：【傷心的辣條】，獲取軟體測驗工程師大廠面試資料！
最后：
凡事要趁早，特別是技術行業，一定要提升技術功底，豐富自動化專案實戰經驗，這對于你未來幾年職業規劃，以及測驗技術掌握的深度非常有幫助，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/233814.html
標籤：其他
上一篇：服務端回呼各個硬體的事件