1、發現的缺陷越多，說明軟件缺陷越多嗎？程序員
一、這是一個比較常見的現象。測試工程師在沒有找到缺陷前會絞盡腦汁的思考，可是找到一個後，會連續不斷的發現不少缺陷，很有我的成就感。其中的緣由主要以下：
-代碼複用、拷貝代碼致使程序員容易犯相同的錯誤。類的繼承致使全部的子類會包含基類的錯誤，反覆拷貝同一代碼意味可能也複製了缺陷。
-程序員比較勞累是能夠致使某些連續編寫的功能缺陷較多。程序員加班是一種司空見慣的現象，所以體力不僅時容易編寫一些缺陷較多的程序。而這些連續潛伏缺陷偏偏時測試工程師大顯身手的地方。
二、「缺陷一個連着一個」不是一個客觀規律，只是一個常見的現象。若是軟件編寫的比較好，這種現象就不常見了。測試人員只要嚴肅認真的測試程序就能夠了。數據庫
2、什麼是樁模塊？什麼是驅動模塊？安全
一、樁模塊：被測模塊調用模塊。
二、驅動模塊 調用被測模塊。服務器
3、沒有產品說明書和需求文檔地狀況下可以進行黑盒測試嗎？網絡
一、這個問題是國內測試工程師常常遇到的問題，根源就是國內軟件開發文檔管理不規範，對變動的管理方法就更不合理了。實際上沒有任何文檔的時候，測試人員是可以進行黑盒測試的，這種測試方式咱們能夠稱之爲探索測試，具體作法就是測試工程師根據本身的專業技能、領域知識等不斷的深刻了解測試對象、理解軟件功能，進而發現缺陷。
二、在這種作法基本上把軟件當成了產品說明書，測試過程當中要和開發人員不斷的進行交流。尤爲在做項目的時候，進度壓力比較大，能夠做爲加急測試方案。最大的風險是不知道有些特性是否被遺漏。併發
4、你之前工做時的測試流程是什麼？性能
請結合工做靈活回答，參考以下：
需求評審（有開發人員，產品經理，測試人員，項目經理）－>需求肯定(出一份肯定的需求文檔)－>開發設計文檔（開發人員在開始寫代碼前就能輸出設計文檔）－>想好測試策略，寫出測試用例－>發給開發人員和測試經理看看（非正式的評審用例）－>接到測試版本－>執行測試用例（中間可能會補充用例）－>提交bug（有些bug須要開發人員的肯定（嚴重級別的，或忽然發現的在測試用例範圍以外的，難以重現的），有些能夠直接錄製進TD）－>開發人員修改（能夠在測試過程當中快速的修改）－>迴歸測試（可能又會發現新問題，再按流程開始跑）測試
5、軟件測試的風險主要體如今哪裏？大數據
咱們沒有對軟件進行徹底測試，實際就是選擇了風險，由於缺陷極有可能存在沒有進行測試的部分。舉個例子，程序員爲了方便，在調試程序時會彈出一些提示信息框，而這些提示只在某種條件下會彈出，碰巧程序發佈前這些代碼中的一些沒有被註釋掉。在測試時測試工程師又沒有對其進行測試。若是客戶碰到它，這將是代價昂貴的缺陷，由於交付後才被客戶發現。
所以，咱們要儘量的選擇最合適的測試量，把風險下降到最小。設計
6、全部的軟件缺陷都能修復嗎？全部的軟件缺陷都要修復嗎？
一、從技術上講，全部的軟件缺陷都是可以修復的，可是沒有必要修復全部的軟件缺陷。測試人員要作的是可以正確判斷何時不能追求軟件的完美。對於整個項目團隊，要作的是對每個軟件缺陷進行取捨，根據風險決定那些缺陷要修復。
二、發生這種現象的主要緣由以下：
-沒有足夠的時間資源。在任何一個項目中，一般狀況下開發人員和測試人員都是不夠用的，並且在項目中沒有預算足夠的迴歸測試時間，再加上修改缺陷可能引入新的缺陷，所以在交付期限的強大壓力下，必須放棄某些缺陷的修改。
-有些缺陷只是特殊狀況下出現，這種缺陷處於商業利益考慮，能夠在之後升級中進行修復。
-不是缺陷的缺陷。咱們常常會碰到某些功能方面的問題被當成缺陷來處理，這類問題能夠之後有時間時考慮再處理。
三、最後要說的是，缺陷是否修改要由軟件測試人員、項目經理、程序員共同討論來決定是否修復，不一樣角色的人員從不一樣的角度來思考，以作出正確的決定。
7、什麼是兼容性測試？兼容性測試側重哪些方面？
一、兼容測試主要是檢查軟件在不一樣的硬件平臺、軟件平臺上是否能夠正常的運行，便是一般說的軟件的可移植性。
二、兼容的類型，若是細分的話，有平臺的兼容，網絡兼容，數據庫兼容，以及數據格式的兼容。
三、兼容測試的重點是，對兼容環境的分析。一般，是在運行軟件的環境不是很肯定的狀況下，才須要作兼容。根據軟件運行的須要，或者根據需求文檔，通常都可以得出用戶會在什麼環境下使用該軟件，把這些環境整理成表單，就得出作兼容測試的兼容環境了。
四、兼容和配置測試的區別在於，作配置測試一般不是乾淨的環境下下作測試，而兼容測試可能是在乾淨的環境下作的。
8、LoadRunner進行測試的流程?
一、建立虛擬用戶腳本；二、建立運行場景；三、運行測試腳本；四、監視場景；五、分析測試的結果；以上，最好是結合一個案例，根據以上流程來介紹。
9、軟件的評審通常由哪些人蔘加？其目的是什麼？
一、在正式的會議上將軟件項目的成果（包括各階段的文檔、產生的代碼等）提交給用戶、客戶或有關部門人員對軟件產品進行評審和批准。其目的是找出可能影響軟件產品質量、開發過程、維護工做的適用性和環境方面的設計缺陷，並採起補救措施，以及找出在性能、安全性和經濟方面的可能的改進。
二、人員：用戶、客戶或有關部門開發人員，測試人員，需求分析師均可以，就看處於評審那個階段 。
10、測試中的「殺蟲劑怪事」是指什麼？
一、「殺蟲劑怪事」一詞由BorisBeizer在其編著的《軟件測試技術》第二版中提出。用於描述測試人員對同一測試對象進行的測試次數越多，發現的缺陷就會愈來愈少的現象。就像老用一種農藥，害蟲就會有免疫力，農藥發揮不了效力。這種現象的根本緣由就是測試人員對測試軟件過於熟悉，造成思惟定勢。
二、爲了克服這種現象，測試人員須要不斷編寫新的測試程序或者測試用例，對程序的不一樣部分進行測試，以發現更多的缺陷。也能夠引用新人來測試軟件，剛剛進來的新手每每能發現一些意想不到的問題。
11、QTP中的Action有什麼做用？有幾種？
一、Action的做用
a.用Action能夠對步驟集進行分組
b.步驟重組，而後被總體調用
c.擁有本身的sheet
d.組合有相同需求的步驟，總體操做
e.具備獨立的對象倉庫
二、Action的種類
a.可複用Action
b.不可複用Action
c.外部Action
12、測試的策略有哪些？
黑盒/白盒，靜態/動態，手工/自動，冒煙測試，迴歸測試，驗收測試。
十3、什麼是系統瓶頸？
一、瓶頸主要是指整個軟硬件構成的軟件系統某一方面或者幾個方面能力不能知足用戶的特定業務要求，「特定」是指瓶頸會在某些條件下會出現，由於畢竟大多數系統在投入前。
二、嚴格的從技術角度講，全部的系統都會有瓶頸，由於大多數系統的資源配置不是協調的，例如CPU使用率恰好達到100％時，內存也正好耗盡的系統不是不少見。所以咱們討論系統瓶頸要從應用的角度討論：關鍵是看系統可否知足用戶需求。在用戶極限使用系統的狀況下，系統的響應仍然正常，咱們能夠認爲改系統沒有瓶頸或者瓶頸不會影響用戶工做。
所以咱們測試系統瓶頸主要是實現下面兩個目的：
-發現「表面」的瓶頸。主要是模擬用戶的操做，找出用戶極限使用系統時的瓶頸，而後解決瓶頸，這是性能測試的基本目標。
-發現潛在的瓶頸並解決，保證系統的長期穩定性。主要是考慮用戶在未來擴展系統或者業務發生變化時，系統可以適應變化。知足用戶目前需求的系統不是最好的，咱們設計系統的目標是在保證系統整個軟件生命週期可以不斷適應用戶的變化，或者經過簡單擴展系統就能夠適應新的變化。
十4、功能測試用例須要詳細到什麼程度纔是合格的？
一、這個問題也是測試工程師常常問的問題。有人主張測試用例詳細到每一個步驟執行什麼都要寫出來，目的是即便一個不瞭解系統的新手均可以按照測試用例來執行工做。主張這類寫法的人還能夠舉出例子：歐美、日本等軟件外包文檔都是這樣作的。
二、另一種觀點就是主張寫的粗些，相似於編寫測試大綱。主張這種觀點的人是由於軟件開發需求管理不規範，變更十分頻繁，於是不能按照歐美的高標準來編寫測試用例。這樣的測試用例容易維護，可讓測試執行人員有更大的發揮空間。
實際上，軟件測試用例的詳細程度首先要以覆蓋到測試點爲基本要求。舉個例子：「用戶登錄系統」的測試用例能夠不寫出具體的執行數據，可是至少要寫出五種以上狀況（），若是隻用一句話覆蓋了這個功能是不合格的測試用例。覆蓋功能點不是指列出功能點，而是要寫出功能點的各個方面（若是組合狀況較多時能夠採用等價劃分）。
另外一個影響測試用例的就是組織的開發能力和測試對象特色。若是開發力量比較落後，編寫較詳細的測試用例是不現實的，由於根本沒有那麼大的資源投入，固然這種狀況很隨着團隊的發展而逐漸有所改善。測試對象特色重點是指測試對象在進度、成本等方面的要求，若是進度較緊張的狀況下，是根本沒有時間寫出高質量的測試用例的，甚至有些時候測試工做只是一種輔助工做，於是不編寫測試用例。
所以，測試用例的編寫要根據測試對象特色、團隊的執行能力等各個方面綜合起來決定編寫策略。最後要注意的是測試人員必定不能抱怨，力爭在不斷提升測試用例編寫水平的同時，不斷地提升自身能力。
十5、簡述一下缺陷的生命週期？
測試人員提交缺陷->相關負責人確認缺陷->負責人分配缺陷->開發人員修復缺陷->測試人員驗證缺陷->測試人員關閉缺陷。
十6、如何理解壓力、負載、性能測試測試？
一、性能測試是一個較大的範圍，實際上性能測試自己包含了性能、強度、壓力、負載等多方面的測試內容。
二、壓力測試是對服務器的穩定性以及負載能力等方面的測試，是一種很日常的測試。增大訪問系統的用戶數量、或者幾個用戶進行大數據量操做都是壓力測試。而負載測試是壓力相對較大的測試，主要是測試系統在一種或者集中極限條件下的相應能力，是性能測試的重要部分。100個用戶對系統進行連續半個小時的訪問能夠看做壓力測試，那麼連續訪問8個小時就能夠認爲負載測試，1000個用戶連續訪問系統1個小時也能夠看做是負載測試。
三、實際上壓力測試和負載測試沒有明顯的區分。測試人員應該站在關注總體性能的高度上來對系統進行測試。
十7、什麼是併發？在lordrunner中，如何進行併發的測試？集合點失敗了會怎麼樣？
一、併發指的是在同一時間點，支持多個不一樣的操做。
二、LoadRunner中提供IP假裝，集合點，配合虛擬用戶的設計，以及在多臺電腦上設置，能夠比較好的模擬真實的併發。
三、集合點，便是多個用戶在某個時刻，某個特定的環境下同時進行虛擬用戶的操做的。集合點失敗，則集合點的才操做就會取消，測試就不能進行。
十8、Beta測試與Alpha測試有什麼區別？
一、Beta testing(β測試),測試是軟件的多個用戶在一個或多個用戶的實際使用環境下進行的測試。開發者一般不在測試現場。
二、Alpha testing (α測試),是由一個用戶在開發環境下進行的測試，也能夠是公司內部的用戶在模擬實際操做環境下進行的受控測試。
十9、使用QTP作功能測試，錄製腳本的時候，要驗證多個用戶的登陸狀況/查詢狀況，如何操做？
分析用戶登陸的基本狀況，得出一組數據，經過性測試/失敗性測試的都有（根據TC來設計這些數據），而後錄製登陸的腳本，將關鍵的數據參數化，修改腳本，對代碼進行增強，調試腳本。
二10、經過畫因果圖來寫測試用例的步驟爲 ?
（1）分析軟件規格說明描述中，哪些是緣由（即輸入條件或輸入條件的等價類），哪些是結果（即輸出條件），並給每一個緣由和結果賦予一個標識符。
（2）分析軟件規格說明描述中的語義，找出緣由與結果之間，緣由與緣由之間對應的是什麼關係? 根據這些關係，畫出因果圖。
（3）因爲語法或環境限制，有些緣由與緣由之間，緣由與結果之間的組合狀況不可能出現。爲代表這些特殊狀況，在因果圖上用一些記號標明約束或限制條件。
（4）把因果圖轉換成斷定表。
（5）把斷定表的每一列拿出來做爲依據，設計測試用例。