軟件面試常見題目（轉帖）

 

一、什麼是兼容性測試？兼容性測試側重哪些方面？

參考答案：

兼容測試主要是檢查軟件在不一樣的硬件平臺、軟件平臺上是否能夠正常的運行，便是一般說的軟件的可移植性。

兼容的類型，若是細分的話，有平臺的兼容，網絡兼容，數據庫兼容，以及數據格式的兼容。

兼容測試的重點是，對兼容環境的分析。一般，是在運行軟件的環境不是很肯定的狀況下，才須要作兼容。根據軟件運行的須要，或者根據需求文檔，通常都可以得出用戶會在什麼環境下使用該軟件，把這些環境整理成表單，就得出作兼容測試的兼容環境了。

兼容和配置測試的區別在於，作配置測試一般不是Clean OS下作測試，而兼容測試可能是在Clean OS的環境下作的。

二、我如今有個程序，發如今Windows上運行得很慢，怎麼判別是程序存在問題仍是軟硬件系統存在問題？

參考答案：

1、檢查系統是否有中毒的特徵；

2、檢查軟件/硬件的配置是否符合軟件的推薦標準；

3、確認當前的系統是不是獨立，即沒有對外提供什麼消耗CPU資源的服務；

4、若是是C/S或者B/S結構的軟件，須要檢查是否是由於與服務器的鏈接有問題，或者訪問有問題形成的；

5、在系統沒有任何負載的狀況下，查看性能監視器，確認應用程序對CPU/內存的訪問狀況。

三、測試的策略有哪些？

參考答案：

黑盒/白盒，靜態/動態，手工/自動，冒煙測試，迴歸測試，公測（Beta測試的策略）

四、正交表測試用例設計方法的特色是什麼？

參考答案：

用最少的實驗覆蓋最多的操做，測試用例設計不多，效率高，可是很複雜；

對於基本的驗證功能，以及二次集成引發的缺陷，通常都能找出來；可是更深的缺陷，更復雜的缺陷，仍是無能爲力的；

具體的環境下，正交表通常都很難作的。大多數，只在系統測試的時候使用此方法。

五、描述使用bugzilla缺陷管理工具對軟件缺陷（BUG）跟蹤的管理的流程？

參考答案：

就是Bugzilla的狀態轉換圖。

六、你以爲bugzilla在使用的過程當中，有什麼問題？

參考答案：

界面不穩定；

根據須要配置它的不一樣的部分，過程很煩瑣。

流程控制上，安全性很差界定，很容易對他人的Bug進行誤操做；

沒有綜合的評分指標，很差確認修復的優先級別。

七、描述測試用例設計的完整過程？

參考答案：

需求分析 + 需求變動的維護工做；

根據需求 得出測試需求；

設計測試方案，評審測試方案；

方案評審經過後，設計測試用例，再對測試用例進行評審；

八、單元測試的策略有哪些？

參考答案：

邏輯覆蓋、循環覆蓋、同行評審、桌前檢查、代碼走查、代碼評審、景泰數據流分析

九、LoadRunner分哪三部分？

參考答案：

用戶動做設計；

場景設計；

測試數據分析；

十、LoadRunner進行測試的流程?

參考答案：

一、 測試測試

二、 建立虛擬用戶腳本

三、 建立運行場景

四、 運行測試腳本

五、 監視場景

六、 分析測試的結果

以上，最好是結合一個案例，根據以上流程來介紹。

什麼是併發？在lordrunner中，如何進行併發的測試？集合點失敗了會怎麼樣？

參考答案：

在同一時間點，支持多個不一樣的操做。

LoadRunner中提供IP假裝，集合點，配合虛擬用戶的設計，以及在多臺電腦上設置，能夠比較好的模擬真實的併發。

集合點，便是多個用戶在某個時刻，某個特定的環境下同時進行虛擬用戶的操做的。集合點失敗，則集合點的才操做就會取消，測試就不能進行。

十二、使用QTP作功能測試，錄製腳本的時候，要驗證多個用戶的登陸狀況/查詢狀況，如何操做？

參考答案：

分析用戶登陸的基本狀況，得出一組數據，經過性測試/失敗性測試的都有（根據TC來設計這些數據），而後錄製登陸的腳本，將關鍵的數據參數化，修改腳本，對代碼進行增強，調試腳本。

1三、QTP中的Action有什麼做用？有幾種？

參考答案：

Action的做用

n       用Action能夠對步驟集進行分組

n       步驟重組，而後被總體調用

n       擁有本身的sheet

n       組合有相同需求的步驟，總體操做

n       具備獨立的對象倉庫

Action的種類

n       可複用Action

n       不可複用Action

n       外部Action

1四、TestDirector有些什麼功能，如何對軟件測試過程進行管理？

參考答案：

 需求管理

n       定義測試範圍

n       定義需求樹

n       描述需求樹的功能點

測試計劃

n       定義測試目標和測試策略。

n       分解應用程序，創建測試計劃樹。

n       肯定每一個功能點的測試方法。

n       將每一個功能點鏈接到需求上，使測試計劃覆蓋所有的測試需求。

n       描述手工測試的測試步驟

n       指明須要進行自動測試的功能點

測試執行

n       定義測試集合。

n       爲每一個測試人員制定測試任務和測試日程安排。

n       運行自動測試。

缺陷跟蹤

n       記錄缺陷

n       查看新增缺陷，並肯定哪些是須要修正的

n       相關技術人員修改缺陷

n       迴歸測試

n       分析缺陷統計圖表，分析應用程序的開發質量。

1五、你所熟悉的軟件測試類型都有哪些？請試着分別比較這些不一樣的測試類型的區別與聯繫（如功能測試、性能測試……）？

參考答案：Compatibility Testing（兼容性測試），也稱「Configuration testing（配置測試）」，測試軟件是否和系統的其它與之交互的元素之間兼容，如：瀏覽器、操做系統、硬件等。驗證測試對象在不一樣的軟件和硬件配置中的運行狀況。

Functional testing (功能測試)，也稱爲behavioral testing（行爲測試），根據產品特徵、操做描述和用戶方案，測試一個產品的特性和可操做行爲以肯定它們知足設計需求。本地化軟件的功能測試，用於驗證應用程序或網站對目標用戶能正確工做。使用適當的平臺、瀏覽器和測試腳本，以保證目標用戶的體驗將足夠好，就像應用程序是專門爲該市場開發的同樣。
Performance testing（性能測試），評價一個產品或組件與性能需求是否符合的測試。包括負載測試、強度測試、數據庫容量測試、基準測試等類型。

1六、軟件缺陷（或者叫Bug）記錄都包含了哪些內容？如何提交高質量的軟件缺陷（Bug）記錄？

參考答案：5C標準

1七、Beta測試與Alpha測試有什麼區別？

參考答案：Beta testing(β測試),測試是軟件的多個用戶在一個或多個用戶的實際使用環境下進行的測試。開發者一般不在測試現場
Alpha testing (α測試),是由一個用戶在開發環境下進行的測試，也能夠是公司內部的用戶在模擬實際操做環境下進行的受控測試

1八、軟件的評審通常由哪些人蔘加？其目的是什麼？

參考答案：

在正式的會議上將軟件項目的成果（包括各階段的文檔、產生的代碼等）提交給用戶、客戶或有關部門人員對軟件產品進行評審和批准。其目的是找出可能影響軟件產品質量、開發過程、維護工做的適用性和環境方面的設計缺陷，並採起補救措施，以及找出在性能、安全性和經濟方面的可能的改進。

人員：用戶、客戶或有關部門開發人員，測試人員，需求分析師均可以，就看處於評審那個階段

1九、測試活動中，若是發現需求文檔不完善或者不許確，怎麼處理？

參考答案：

測試需求分析發現需求文檔不完善或者不許確，應該當即和相關人員進行協調交流。

20、階段評審與項目評審有什麼區別？

參考答案：

階段評審對項目各階段評審：對階段成果和工做

項目評審對項目整體評審：對工做和產品

2一、闡述工做版本的定義？

參考答案：

構造號： BUILD

2二、什麼是樁模塊？什麼是驅動模塊？

參考答案：

樁模塊：被測模塊調用模塊

驅動模塊調用被測模塊

2三、什麼是扇入？什麼是扇出？

參考答案：

扇入：被調次數，扇出：調其它模塊數目

2四、你認爲作好測試計劃工做的關鍵是什麼？

參考答案：

軟件測試計劃就是在軟件測試工做正式實施以前明確測試的對象，而且經過對資源、時間、風險、測試範圍和預算等方面的綜合分析和規劃，保證有效的實施軟件測試；

作好測試計劃工做的關鍵：目的，管理，規範

1. 明確測試的目標，加強測試計劃的實用性
編寫軟件測試計劃得重要目的就是使測試過程可以發現更多的軟件缺陷，所以軟件測試計劃的價值取決於它對幫助管理測試項目，而且找出軟件潛在的缺陷。所以，軟件測試計劃中的測試範圍必須高度覆蓋功能需求，測試方法必須切實可行，測試工具而且具備較高的實用性，便於使用，生成的測試結果直觀、準確
2．堅持「5W」規則，明確內容與過程
「5W」規則指的是「What（作什麼）」、「Why（爲何作）」、「When（什麼時候作）」、「Where（在哪裏）」、「How（如何作）」。利用「5W」規則建立軟件測試計劃，能夠幫助測試團隊理解測試的目的（Why），明確測試的範圍和內容（What），肯定測試的開始和結束日期（When），指出測試的方法和工具（How），給出測試文檔和軟件的存放位置（Where）。
3．採用評審和更新機制，保證測試計劃知足實際需求
測試計劃寫做完成後，若是沒有通過評審，直接發送給測試團隊，測試計劃內容的可能不許確或遺漏測試內容，或者軟件需求變動引發測試範圍的增減，而測試計劃的內容沒有及時更新，誤導測試執行人員。
4. 分別建立測試計劃與測試詳細規格、測試用例
應把詳細的測試技術指標包含到獨立建立的測試詳細規格文檔，把用於指導測試小組執行測試過程的測試用例放到獨立建立的測試用例文檔或測試用例管理數據庫中。測試計劃和測試詳細規格、測試用例之間是戰略和戰術的關係，測試計劃主要從宏觀上規劃測試活動的範圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。

2五、你認爲作好測試用例工做的關鍵是什麼？

參考答案：

 需求和設計文檔的理解程度，對系統的熟悉程度

2六、簡述一下缺陷的生命週期？

參考答案：提交->確認->分配->修復->驗證->關閉

2七、軟件的安全性應從哪幾個方面去測試？

參考答案：

(1)用戶認證機制：如數據證書、智能卡、雙重認證、安全電子交易協議

(2)加密機制

(3)安全防禦策略：如安全日誌、入侵檢測、隔離防禦、漏洞掃描

(4)數據備份與恢復手段：存儲設備、存儲優化、存儲保護、存儲管理

(5)防病毒系統

2八、軟件配置管理工做開展的狀況和認識？

參考答案：

軟件配置管理貫穿於軟件開發、測試活動的始終，覆蓋了開發、測試活動的各個環節，它的重要做用之一就是要全面的管理保存各個配置項，監控各配置項的狀態，並向項目經理及相關的人員報告，從而實現對軟件過程的控制。

軟件測試配置管理包括4個最基本的活動：

配置項標識

配置項控制

配置項狀態報告

配置審計

       軟件配置管理一般藉助工具來輔助，主要有MS SourceSafe、Rational ClearCase等

2九、你以爲軟件測試經過的標準應該是什麼樣的？

參考答案：

    缺陷密度值達到客戶的要求

30、引入測試管理的含義？

參考答案：風險分析，進度控制、角色分配、質量控制

3一、一套完整的測試應該由哪些階段組成？

參考答案：測試計劃、測試設計與開發、測試實施、測試評審與測試結論

3二、單元測試的主要內容？

參考答案：

　模塊接口測試、局部數據結構測試、路徑測試、錯誤處理測試、邊界測試

3三、集成測試也叫組裝測試或者聯合測試，請簡述集成測試的主要內容？

參考答案：

（1）在把各個模塊鏈接起來的時候，穿越模塊接口的數據是否會丟失；

　（2）一個模塊的功能是否會對另外一個模塊的功能產生不利的影響；

　（3）各個子功能組合起來，可否達到預期要求的父功能；

　（4）全局數據結構是否有問題；

　（5）單個模塊的偏差累積起來，是否會放大，從而達到不能接受的程度。

3四、簡述集成測試與系統測試關係？

參考答案：

　（1）集成測試的主要依據概要設計說明書，系統測試的主要依據是需求設計說明書；

　（2）集成測試是系統模塊的測試，系統測試是對整個系統的測試，包括相關的軟硬件平臺、網絡以及相關外設的測試。

3五、軟件測試的文檔測試應當貫穿於軟件生命週期的全過程，其中用戶文檔是文檔測試的重點。那麼軟件系統的用戶文檔包括哪些？

參考答案：

　　用戶手冊

　　安裝和設置指導

　　聯機幫助

　　指南、嚮導

　　樣例、示例和模板

　　受權/註冊登記表

最終用戶許可協議

3六、軟件系統中除用戶文檔以外，文檔測試還應該關注哪些文檔？

參考答案：

開發文檔

軟件需求說明書

　　　　數據庫設計說明書

　　　　概要設計說明書

　　　　詳細設計說明書

　　　　可行性研究報告

管理文檔

　　　　項目開發計劃

　　　　測試計劃

　　　　測試報告

　　　　開發進度月報

　　　　開發總結報告

3七、簡述軟件系統中用戶文檔的測試要點？

參考答案：

　（1）讀者羣。文檔面向的讀者定位要明確。對於初級用戶、中級用戶以及高級用戶應該有不一樣的定位

　（2）術語。文檔中用到的術語要適用與定位的讀者羣，用法一致，標準定義與業界規範相吻合。

　（3）正確性。測試中需檢查全部信息是否真實正確，查找因爲過時產品說明書和銷售人員誇大事實而致使的錯誤。檢查全部的目錄、索引和章節引用是否已更新，嘗試連接是否準確，產品支持電話、地址和郵政編碼是否正確。

　（4）完整性。對照軟件界面檢查是否有重要的分支沒有描述到，甚至是否有整個大模塊沒有描述到。

　（5）一致性。按照文檔描述的操做執行後，檢查軟件返回的結果是否與文檔描述的相同。

　（6）易用性。對關鍵步驟以粗體或背景色給用戶以提示，合理的頁面佈局、適量的圖表均可以給用戶更高的易用性。須要注意的是文檔要有助於用戶排除錯誤。不但描述正確操做，也要描述錯誤處理辦法。文檔對於用戶看到的錯誤信息應當有更詳細的文檔解釋。

　（7）圖表與界面截圖。檢查全部圖表與界面截圖是否與發行版本相同。

　（8）樣例與示例。像用戶同樣載入和使用樣例。若是是一段程序，就輸入數據並執行它。以每個模塊製做文件，確認它們的正確性。

　（9）語言。不出現錯別字，不要出現有二義性的說法。特別要注意的是屏幕截圖或繪製圖形中的文字。

　（10）印刷與包裝。檢查印刷質量；手冊厚度與開本是否合適；包裝盒的大小是否合適；有沒有零碎易丟失的小部件等等。

3八、單元測試主要內容是什麼？

參考答案：

單元測試大多數由開發人員來完成，測試人員技術背景較好或者開發系統軟件時可能會安排測試人員進行單元測試，大多數進行的單元測試都是開發人員調試程序或者開發組系統聯合調試的過程。討論這個問題主要是擴充一下讀者的視野。

單元測試通常包括五個方面的測試：

（1）模塊接口測試：模塊接口測試是單元測試的基礎。只有在數據能正確流入、流出模塊的前提下，其餘測試纔有意義。模塊接口測試也是集成測試的重點，這裏進行的測試主要是爲後面打好基礎。測試接口正確與否應該考慮下列因素：

-輸入的實際參數與形式參數的個數是否相同；

-輸入的實際參數與形式參數的屬性是否匹配；

-輸入的實際參數與形式參數的量綱是否一致；

-調用其餘模塊時所給實際參數的個數是否與被調模塊的形參個數相同；

-調用其餘模塊時所給實際參數的屬性是否與被調模塊的形參屬性匹配；

-調用其餘模塊時所給實際參數的量綱是否與被調模塊的形參量綱一致；

-調用預約義函數時所用參數的個數、屬性和次序是否正確；

-是否存在與當前入口點無關的參數引用；

-是否修改了只讀型參數；

-對全程變量的定義各模塊是否一致；

-是否把某些約束做爲參數傳遞。

若是模塊功能包括外部輸入輸出，還應該考慮下列因素：

-文件屬性是否正確；

-OPEN/CLOSE語句是否正確；

-格式說明與輸入輸出語句是否匹配；

-緩衝區大小與記錄長度是否匹配；

-文件使用前是否已經打開；

-是否處理了文件尾；

-是否處理了輸入/輸出錯誤；

-輸出信息中是否有文字性錯誤。

-局部數據結構測試；

-邊界條件測試；

-模塊中全部獨立執行通路測試；

（2）局部數據結構測試：檢查局部數據結構是爲了保證臨時存儲在模塊內的數據在程序執行過程當中完整、正確，局部功能是整個功能運行的基礎。重點是一些函數是否正確執行，內部是否運行正確。局部數據結構每每是錯誤的根源，應仔細設計測試用例，力求發現下面幾類錯誤：

-不合適或不相容的類型說明；

-變量無初值；

-變量初始化或省缺值有錯；

-不正確的變量名（拼錯或不正確地截斷）；

-出現上溢、下溢和地址異常。

（3）邊界條件測試：邊界條件測試是單元測試中最重要的一項任務。衆所周知，軟件常常在邊界上失效，採用邊界值分析技術，針對邊界值及其左、右設計測試用例，頗有可能發現新的錯誤。邊界條件測試是一項基礎測試，也是後面系統測試中的功能測試的重點，邊界測試執行的較好，能夠大大提升程序健壯性。

（4）模塊中全部獨立路徑測試：在模塊中應對每一條獨立執行路徑進行測試，單元測試的基本任務是保證模塊中每條語句至少執行一次。測試目的主要是爲了發現因錯誤計算、不正確的比較和不適當的控制流形成的錯誤。具體作法就是程序員逐條調試語句。常見的錯誤包括：

-誤解或用錯了算符優先級；

-混合類型運算；

-變量初值錯；

-精度不夠；

-表達式符號錯。

比較判斷與控制流經常緊密相關，測試時注意下列錯誤：

-不一樣數據類型的對象之間進行比較；

-錯誤地使用邏輯運算符或優先級；

-因計算機表示的侷限性，指望理論上相等而實際上不相等的兩個量相等；

-比較運算或變量出錯；

-循環終止條件或不可能出現；

-迭代發散時不能退出；

-錯誤地修改了循環變量。

模塊的各條錯誤處理通路測試：程序在遇到異常狀況時不該該退出，好的程序應能預見各類出錯條件，並預設各類出錯處理通路。若是用戶不按照正常操做，程序就退出或者中止工做，實際上也是一種缺陷，所以單元測試要測試各類錯誤處理路徑。通常這種測試着重檢查下列問題：

-輸出的出錯信息難以理解；

-記錄的錯誤與實際遇到的錯誤不相符；

-在程序自定義的出錯處理段運行以前，系統已介入；

-異常處理不當；

-錯誤陳述中未能提供足夠的定位出錯信息。

3九、如何理解強度測試？

參考答案：

強度測試是爲了肯定系統在最差工做環境的工做能力,也多是用於驗證在標準工做壓力下的各類資源的最下限指標。

它和壓力測試的目標是不一樣的,壓力測試是在標準工做環境下,不斷增長系統負荷,最終測試出該系統能力達到的最大負荷(穩定和峯值),而強度測試則是在非標準工做環境下,甚至不斷人爲下降系統工做環境所須要的資源,如網絡帶寬,系統內存,數據鎖等等,以測試系統在資源不足的狀況下的工做狀態,經過強度測試,能夠肯定本系統正常工做的最差環境.

強度測試和壓力測試的測試指標相近,大多都是與時間相關的指標,如併發量(吞吐量),延遲(最大\最小\平均)以及順序指標等

強度測試須要對系統的結構熟悉,針對系統的特徵設計強度測試的方法

40、如何理解壓力、負載、性能測試測試？

參考答案：

性能測試是一個較大的範圍，實際上性能測試自己包含了性能、強度、壓力、負載等多方面的測試內容。

壓力測試是對服務器的穩定性以及負載能力等方面的測試，是一種很日常的測試。增大訪問系統的用戶數量、或者幾個用戶進行大數據量操做都是壓力測試。而負載測試是壓力相對較大的測試，主要是測試系統在一種或者集中極限條件下的相應能力，是性能測試的重要部分。100個用戶對系統進行連續半個小時的訪問能夠看做壓力測試，那麼連續訪問8個小時就能夠認爲負載測試，1000個用戶連續訪問系統1個小時也能夠看做是負載測試。

實際上壓力測試和負載測試沒有明顯的區分。測試人員應該站在關注總體性能的高度上來對系統進行測試。

4一、什麼是系統瓶頸？

參考答案：

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

嚴格的從技術角度講，全部的系統都會有瓶頸，由於大多數系統的資源配置不是協調的，例如CPU使用率恰好達到100％時，內存也正好耗盡的系統不是不少見。所以咱們討論系統瓶頸要從應用的角度討論：關鍵是看系統可否知足用戶需求。在用戶極限使用系統的狀況下，系統的響應仍然正常，咱們能夠認爲改系統沒有瓶頸或者瓶頸不會影響用戶工做。

所以咱們測試系統瓶頸主要是實現下面兩個目的：

-發現「表面」的瓶頸。主要是模擬用戶的操做，找出用戶極限使用系統時的瓶頸，而後解決瓶頸，這是性能測試的基本目標。

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

4二、文檔測試主要包含什麼內容？

參考答案：

在國內軟件開發管理中，文檔管理幾乎是最弱的一項，於是在測試工做中特別容易忽略文檔測試也就不足爲奇了。要想給用戶提供完整的產品，文檔測試是必不可少的。文檔測試通常注重下面幾個方面：

文檔的完整性：主要是測試文檔內容的全面性與完整性，從整體上把握文檔的質量。例如用戶手冊應該包括軟件的全部功能模塊。

描述與軟件實際狀況的一致性：主要測試軟件文檔與軟件實際的一致程度。例如用戶手冊基本完整後，咱們還要注意用戶手冊與實際功能描述是否一致。由於文檔每每跟不上軟件版本的更新速度。

易理解性：主要是檢查文檔對關鍵、重要的操做有無圖文說明，文字、圖表是否易於理解。對於關鍵、重要的操做僅僅只有文字說明確定是不夠的，應該附有圖表使說明更爲直觀和明瞭。

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

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

4三、功能測試用例須要詳細到什麼程度纔是合格的？

參考答案：

這個問題也是測試工程師常常問的問題。有人主張測試用例詳細到每一個步驟執行什麼都要寫出來，目的是即便一個不瞭解系統的新手均可以按照測試用例來執行工做。主張這類寫法的人還能夠舉出例子：歐美、日本等軟件外包文檔都是這樣作的。

另一種觀點就是主張寫的粗些，相似於編寫測試大綱。主張這種觀點的人是由於軟件開發需求管理不規範，變更十分頻繁，於是不能按照歐美的高標準來編寫測試用例。這樣的測試用例容易維護，可讓測試執行人員有更大的發揮空間。

實際上，軟件測試用例的詳細程度首先要以覆蓋到測試點爲基本要求。舉個例子：「用戶登錄系統」的測試用例能夠不寫出具體的執行數據，可是至少要寫出五種以上狀況（），若是隻用一句話覆蓋了這個功能是不合格的測試用例。覆蓋功能點不是指列出功能點，而是要寫出功能點的各個方面（若是組合狀況較多時能夠採用等價劃分）。

另外一個影響測試用例的就是組織的開發能力和測試對象特色。若是開發力量比較落後，編寫較詳細的測試用例是不現實的，由於根本沒有那麼大的資源投入，固然這種狀況很隨着團隊的發展而逐漸有所改善。測試對象特色重點是指測試對象在進度、成本等方面的要求，若是進度較緊張的狀況下，是根本沒有時間寫出高質量的測試用例的，甚至有些時候測試工做只是一種輔助工做，於是不編寫測試用例。

所以，測試用例的編寫要根據測試對象特色、團隊的執行能力等各個方面綜合起來決定編寫策略。最後要注意的是測試人員必定不能抱怨，力爭在不斷提升測試用例編寫水平的同時，不斷地提升自身能力。

4四、配置和兼容性測試的區別是什麼？

參考答案：

配置測試的目的是保證軟件在其相關的硬件上可以正常運行，而兼容性測試主要是測試軟件可否與不一樣的軟件正確協做。

配置測試的核心內容就是使用各類硬件來測試軟件的運行狀況，通常包括：

（1）軟件在不一樣的主機上的運行狀況，例如Dell和Apple；

（2）軟件在不一樣的組件上的運行狀況，例如開發的撥號程序要測試在不一樣廠商生產的Modem上的運行狀況；

（3）不一樣的外設；

（4）不一樣的接口；

（5）不一樣的可選項，例如不一樣的內存大小；

兼容性測試的核心內容：

（1）測試軟件是否能在不一樣的操做系統平臺上兼容；

（2）測試軟件是否能在同一操做系統平臺的不一樣版本上兼容；

（3）軟件自己可否向前或者向後兼容；

（4）測試軟件可否與其它相關的軟件兼容；

（5）數據兼容性測試，主要是指數據可否共享；

配置和兼容性測試通稱對開發系統類軟件比較重要，例如驅動程序、操做系統、數據庫管理系統等。具體進行時仍然按照測試用例來執行。

4五、軟件文檔測試主要包含什麼？

參考答案：

隨着軟件文檔系統日益龐大，文檔測試已經成爲軟件測試的重要內容。文檔測試對象主要以下：

-包裝文字和圖形；

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

-受權、註冊登記表；

-最終用戶許可協議；

-安裝和設置嚮導；

-用戶手冊；

-聯機幫助；

-樣例、示範例子和模板；

-……

文檔測試的目的是提升易用性和可靠性，下降支持費用，由於用戶經過文檔就能夠本身解決問題。因文檔測試的檢查內容主要以下：

-讀者對象——主要是文檔的內容是否能讓該級別的讀者理解；

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

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

-圖標和屏幕抓圖——檢查圖表的準確度和精確度；

-樣例和示例——是否與軟件功能一致；

-拼寫和語法；

-文檔的關聯性——是否與其它相關文檔的內容一致，例如與廣告信息是否一致；

文檔測試是至關重要的一項測試工做，不但要給予充分的重視，更要要認真的完成，象作功能測試同樣來對待文檔測試。

4六、沒有產品說明書和需求文檔地狀況下可以進行黑盒測試嗎？

參考答案：

這個問題是國內測試工程師常常遇到的問題，根源就是國內軟件開發文檔管理不規範，對變動的管理方法就更不合理了。實際上沒有任何文檔的時候，測試人員是可以進行黑盒測試的，這種測試方式咱們能夠稱之爲探索測試，具體作法就是測試工程師根據本身的專業技能、領域知識等不斷的深刻了解測試對象、理解軟件功能，進而發現缺陷。

在這種作法基本上把軟件當成了產品說明書，測試過程當中要和開發人員不斷的進行交流。尤爲在做項目的時候，進度壓力比較大，能夠做爲加急測試方案。最大的風險是不知道有些特性是否被遺漏。

4七、測試中的「殺蟲劑怪事」是指什麼？

參考答案：

「殺蟲劑怪事」一詞由BorisBeizer在其編著的《軟件測試技術》第二版中提出。用於描述測試人員對同一測試對象進行的測試次數越多，發現的缺陷就會愈來愈少的現象。就像老用一種農藥，害蟲就會有免疫力，農藥發揮不了效力。這種現象的根本緣由就是測試人員對測試軟件過於熟悉，造成思惟定勢。

爲了克服這種現象，測試人員須要不斷編寫新的測試程序或者測試用例，對程序的不一樣部分進行測試，以發現更多的缺陷。也能夠引用新人來測試軟件，剛剛進來的新手每每能發現一些意想不到的問題。

4八、在配置測試中，如何判斷髮現的缺陷是普通問題仍是特定的配置問題？

參考答案：

在進行配置測試時，測試工程師仍然會發現一些普通的缺陷，也就是與配置環境無關的缺陷。所以判斷新發現的問題，須要在不一樣的配置中從新執行發現軟件缺陷的步驟，若是軟件缺陷不出現了，就多是配置缺陷；若是在全部的配置中都出現，就多是普通缺陷。

須要注意的是，配置問題能夠在一大類配置中出現。例如，撥號程序可能在全部的外置Modem中都存在問題，而內置的Modem不會有任何問題。

4九、爲何儘可能不要讓時間有富裕的員工去作一些測試？

參考答案：

表面上看這體現了管理的效率和靈活性，但實際上也體現了管理者對測試的輕視。測試和測試的人有很大關係。測試工做人員應該是勤奮並富有耐心，善於學習、思考和發現問題，細心有條理，總結問題，若是具有這樣的優勢，作其它工做一樣也會很出色，所以這裏還有一個要求，就是要喜歡測試這項工做。若是他是專職的，那麼確定更有經驗和信心。國內的小夥子好象都喜歡作程序員，二者工做性質不一樣，待遇不一樣，地位不一樣，對自我實現的價值的認識也不一樣，這是行業的一個須要改善的問題。若是隻是爲了完成任務而完成任務，或者發現了幾個問題就以爲滿意了，這在任何其它工做中都是不行的。

50、徹底測試程序是可能的嗎？

參考答案：

軟件測試初學者可能認爲拿到軟件後須要進行徹底測試，找到所有的軟件缺陷，使軟件「零缺陷」發佈。實際上徹底測試是不可能的。主要有如下一個緣由：

-徹底測試比較耗時，時間上不容許；

-徹底測試一般意味着較多資源投入，這在現實中每每是行不通的；

-輸入量太大，不能一一進行測試；

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

-軟件實現途徑太多；

-軟件產品說明書沒有客觀標準，從不一樣的角度看，軟件缺陷的標準不一樣；

所以測試的程度要根據實際狀況肯定。

5一、軟件測試的風險主要體如今哪裏？

參考答案：

咱們沒有對軟件進行徹底測試，實際就是選擇了風險，由於缺陷極有可能存在沒有進行測試的部分。舉個例子，程序員爲了方便，在調試程序時會彈出一些提示信息框，而這些提示只在某種條件下會彈出，碰巧程序發佈前這些代碼中的一些沒有被註釋掉。在測試時測試工程師又沒有對其進行測試。若是客戶碰到它，這將是代價昂貴的缺陷，由於交付後才被客戶發現。

所以，咱們要儘量的選擇最合適的測試量，把風險下降到最小。

5二、發現的缺陷越多，說明軟件缺陷越多嗎？

參考答案：

這是一個比較常見的現象。測試工程師在沒有找到缺陷前會絞盡腦汁的思考，可是找到一個後，會連續不斷的發現不少缺陷，很有我的成就感。其中的緣由主要以下：

-代碼複用、拷貝代碼致使程序員容易犯相同的錯誤。類的繼承致使全部的子類會包含基類的錯誤，反覆拷貝同一代碼意味可能也複製了缺陷。

-程序員比較勞累是能夠致使某些連續編寫的功能缺陷較多。程序員加班是一種司空見慣的現象，所以體力不僅時容易編寫一些缺陷較多的程序。而這些連續潛伏缺陷偏偏時測試工程師大顯身手的地方。

「缺陷一個連着一個」不是一個客觀規律，只是一個常見的現象。若是軟件編寫的比較好，這種現象就不常見了。測試人員只要嚴肅認真的測試程序就能夠了。

5三、全部的軟件缺陷都能修復嗎？全部的軟件缺陷都要修復嗎？

參考答案：

從技術上講，全部的軟件缺陷都是可以修復的，可是沒有必要修復全部的軟件缺陷。測試人員要作的是可以正確判斷何時不能追求軟件的完美。對於整個項目團隊，要作的是對每個軟件缺陷進行取捨，根據風險決定那些缺陷要修復。發生這種現象的主要緣由以下：

-沒有足夠的時間資源。在任何一個項目中，一般狀況下開發人員和測試人員都是不夠用的，並且在項目中沒有預算足夠的迴歸測試時間，再加上修改缺陷可能引入新的缺陷，所以在交付期限的強大壓力下，必須放棄某些缺陷的修改。

-有些缺陷只是特殊狀況下出現，這種缺陷處於商業利益考慮，能夠在之後升級中進行修復。

-不是缺陷的缺陷。咱們常常會碰到某些功能方面的問題被當成缺陷來處理，這類問題能夠之後有時間時考慮再處理。

最後要說的是，缺陷是否修改要由軟件測試人員、項目經理、程序員共同討論來決定是否修復，不一樣角色的人員從不一樣的角度來思考，以作出正確的決定。

5四、軟件測試人員就是QA嗎？

參考答案：

軟件測試人員的職責是儘量早的找出軟件缺陷，確保得以修復。而質量保證人員（QA）主要職責是建立或者制定標準和方法，提升促進軟件開發能力和減小軟件缺陷。測試人員的主要工做是測試，質量保證人員平常工做重要內容是檢查與評審，測試工做也是測試保證人員的工做對象。

軟件測試和質量是相輔相成的關係，都是爲了提升軟件質量而工做。

5五、如何減小測試人員跳槽帶來的損失？

參考答案：

在IT行業裏跳槽已是一種司空見慣的現象，並且跳槽不管給公司仍是給我的都會帶來必定的損失。測試隊伍也無疑會面臨跳槽的威脅，做爲測試經理管理者，只有從平常工做中開始作起，最能最大限度的減小損失。建議咱們從如下兩個方面作起：

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

-一般狀況下，企業能爲員工提供足夠大的發展空間時，若是不是待遇特別低，員工都不會主動離開企業。所以咱們要想留住員工，管理者就應該把員工的我的成長和企業的發展聯繫起來，爲員工設定合理發展規劃並付諸實現。不過這項要求作起來比較，要有比較好的企業文化爲依託。

5六、測試產品與測試項目的區別是什麼？

參考答案：

習慣上把開發完成後進行商業化、幾乎不進行代碼修改就能夠售給用戶使用的軟件成爲軟件產品，也就是能夠買「賣拷貝」的軟件，例如Windows2000。而一般把針對一個或者幾個特定的用戶而開發的軟件成爲軟件項目，軟件項目是一種個性化的產品，能夠是按照用戶要求所有從新開發，也能夠修改已有的軟件產品來知足特定的用戶需求。項目和產品的不一樣特色，決定咱們測試產品和測試項目仍然會有不少不一樣的地方：

-質量要求不一樣。一般產品的質量要高一些，修復發佈後產品的缺陷成本較高，甚至會帶來不少負面的影響。而作項目一般面向某一用戶，雖然質量越高越好，可是通常只要知足用戶要求就能夠了。

-測試資源投入多少不一樣。作軟件產品一般是研發中心來開發，進度壓力要小些。同時因爲質量要求高，所以會投入較多的人力、物力資源。

-項目最後要和用戶共同驗收測試，這是產品測試不具備的特色。

此外，測試產品與測試項目在缺陷管理方面、測試策略制定都會有很大不一樣，測試管理者應該結合具體的環境，恰如其分的完成工做。

5七、和用戶共同測試（UAT測試）的注意點有哪些？

參考答案：

軟件產品在投產前，一般都會進行用戶驗收測試。若是用戶驗收測試沒有經過，直接結果就是那不到「Money」，間接影響是損害了公司的形象，然後者的影響每每更嚴重。根據做者的經驗，用戶驗收測試必定要讓用戶滿意。

實際上用戶現場測試更趨因而一種演示。在不欺騙用戶的前提下，咱們向用戶展現咱們軟件的優勢，最後讓「上帝」滿意並欣然掏出「銀子」纔是咱們的目標。所以用戶測試要注意下面的事項：

（1）用戶現場測試不可能測試所有功能，所以要測試核心功能。這須要提早作好準備，這些核心功能必定要預先通過測試，證實沒有問題才能夠和用戶共同進行測試。測試核心模塊的目的是創建用戶對軟件的信心。固然若是這些模塊若是問題較多，不該該進行演示。

（2）若是某些模塊確實有問題，咱們能夠演示其它重要的業務功能模塊，必要時要向用戶作成合理的解釋。爭得時間後，及時修改缺陷來彌補。

（3）永遠不能欺騙用戶，矇混過關。道理很簡單，由於軟件是要給用戶用的，問題遲早會暴露出來，除非你能夠立刻修改。

和用戶進行測試還要注意各類交流技巧，爭取不但短時間利益獲得了知足，還要爲後面得合做打好基礎。

5八、如何編寫提交給用戶的測試報告？

參考答案：

隨着測試工做愈來愈受重視，開發團隊向客戶提供測試文檔是不可避免的事情。不少人會問：「咱們能夠把工做中的測試報告提供給客戶嗎？」答案是否認的。由於提供內部測試報告，可能會讓客戶失去信心，甚至否認項目。

測試報告通常分爲內部測試報告和外部測試報告。內部報告是咱們在測試工做中的項目文檔，反映了測試工做的實施狀況，這裏不過多討論，讀者能夠參考相關教材。這裏主要討論一下外部測試報告的寫法，通常外部測試報告要知足下面幾個要求：

-根據內部測試報告進行編寫，通常能夠摘錄；

-不能夠向客戶報告嚴重缺陷，即便是已經修改的缺陷，開發中的缺陷也沒有必要讓客戶知道；

-報告上能夠列出一些缺陷，但必須是中級的缺陷，並且這些缺陷必須是修復的；

-報告上面的內容儘可能要真實可靠；

-整個測試報告要仔細審閱，力爭不給項目帶來負面做用，尤爲是性能測試報告。

總之，外部測試報告要當心謹慎的編寫。

5九、測試工具在測試工做中是什麼地位？

參考答案：

國內的不少測試工程師對測試工具至關迷戀，尤爲是一些新手，甚至指望測試工具能夠取代手工測試。測試工具在測試工做中起的是輔助做用，通常用來提升測試效率。自動化測試彌補了手工測試的不足，減輕必定的工做量。實際上測試工具是沒法替代大多數手工測試的，而一些諸如性能測試等自動化測試也是手工所不能完成的。

對於自動測試技術，應當依據軟件的不一樣狀況來分別對待，通常自動技術會應用在引發大量重複性工做的地方、系統的壓力點、以及任何適合使用程序解決大批量輸入數據的地方。而後再尋找合適的自動測試工具，或者本身開發測試程序。必定不要爲了使用測試工具而使用。

60、什麼是軟件測試，軟件測試的目的？

參考答案：

6一、簡述負載測試與壓力測試的區別。

參考答案：

    壓力測試（Stress Testing）

壓力測試的主要任務就是獲取系統正確運行的極限，檢查系統在瞬間峯值負荷下正確執行的能力。例如，對服務器作壓力測試時就能夠增長併發操做的用戶數量；或者不停地向服務器發送請求；或一次性向服務器發送特別大的數據等。看看服務器保持正常運行所能達到的最大狀態。人們一般使用測試工具來完成壓力測試，如模擬上萬個用戶從終端同時登陸，這是壓力測試中經常使用的方法。

負載測試（Volume Testing）

用於檢查系統在使用大量數據的時候正確工做的能力，即檢驗系統的能力最高能達到什麼程度。例如，對於信息檢索系統，讓它使用頻率達到最大；對於多個終端的分時系統，讓它全部的終端都開動。在使整個系統的所有資源達到「滿負荷」的情形下，測試系統的承受能力。

6二、寫出bug報告流轉的步驟，每步的責任人及主要完成的工做。

參考答案：（要結合本身實際的工做經驗進行回答，不一樣公司略有區別）

    測試人員提交新的Bug入庫，錯誤狀態爲New。

高級測試員/測試經理驗證錯誤，若是確認是錯誤，分配給開發組。設置狀態爲Open。若是不是錯誤，則拒絕，設置爲Declined狀態。

開發經理分配bug至對應的模塊開發人員。

開發人員查詢狀態爲Open的Bug，若是不是錯誤，則置狀態爲Declined；若是是Bug則修復並置狀態爲Fixed。不能解決的Bug，要留下文字說明及保持Bug爲Open狀態。

對於不能解決和延期解決的Bug，不能由開發人員本身決定，通常要經過某種會議（評審會）經過才能承認。

測試人員查詢狀態爲Fixed的Bug，而後驗證Bug是否已解決，如解決，置Bug的狀態爲Closed，如沒有解決,置bug狀態爲Reopen。

6三、寫出bug報告當中一些必備的內容。

參考答案：

       硬件平臺和操做系統

       測試應用的硬件平臺（Platform），一般選擇「PC」。

       測試應用的操做系統平臺（OS）。

a)        版本

       提交缺陷報告時經過該字段標識此缺陷存在於被測試軟件的哪一個版本。

b)        Bug報告優先級

c)         Bug狀態

d)        Bug的編號

e)        發現人

f)         提交人

g)        指定處理人

h)        概述

i)          從屬關係

j)          詳細描述

k)       嚴重程度

l)          所屬模塊

m)      附件

n)        提交日期

6四、開發人員總是犯一些低級錯誤怎麼解決？

參考答案：

這種現象在開發流程不規範的團隊裏特別常見，尤爲是一些「做坊式」的團隊裏。解決這種問題通常從兩個方面入手：

一方面從開發管理入手，也就是從根源來解決問題。能夠制定規範的開發流程，甚至能夠制定懲罰制度，還有就是軟件開發前作好規劃設計。

另外一方面就是增強測試，具體作法就是增強開發人員的本身測試，把這些問題「消滅」在開發階段，這是比較好的作法，讀者能夠參考第13章試案例分析的「13.1.2缺陷反覆出現，誰的責任」小節，13.1.2專門討論了這類問題的方法。

此外，還能夠經過規範的缺陷管理來對開發人員進行控制，好比測試部門整理出常見的缺陷，讓開發人員本身對照進行檢查，以減小這類低級錯誤的發生。

開發人員犯錯誤是正常的現象，做爲測試人員必定不能抱怨，要認認真真的解決問題纔是上策。

6五、畫出軟件測試的V模型圖。

  參考答案：

        

6六、爲何要在一個團隊中開展軟件測試工做？

參考答案：

由於沒有通過測試的軟件很難在發佈以前知道該軟件的質量，就比如ISO質量認證同樣，測試一樣也須要質量的保證，這個時候就須要在團隊中開展軟件測試的工做。在測試的過程發現軟件中存在的問題，及時讓開發人員得知並修改問題，在即將發佈時，從測試報告中得出軟件的質量狀況。

6七、您在以往的測試工做中都曾經具體從事過哪些工做？其中最擅長哪部分工做？

參考答案：（根據項目經驗不一樣，靈活回答便可）

我曾經作過web測試，後臺測試，客戶端軟件，其中包括功能測試，性能測試，用戶體驗測試。最擅長的是功能測試

6八、您所熟悉的軟件測試類型都有哪些？請試着分別比較這些不一樣的測試類型的區別與聯繫（如功能測試、性能測試……）

參考答案：

測試類型有：功能測試，性能測試，界面測試。
　　功能測試在測試工做中佔的比例最大，功能測試也叫黑盒測試。是把測試對象看做一個黑盒子。利用黑盒測試法進行動態測試時，須要測試軟件產品的功能，不需測試軟件產品的內部結構和處理過程。採用黑盒技術設計測試用例的方法有：等價類劃分、邊界值分析、錯誤推測、因果圖和綜合策略。 
　　性能測試是經過自動化的測試工具模擬多種正常、峯值以及異常負載條件來對系統的各項性能指標進行測試。負載測試和壓力測試都屬於性能測試，二者能夠結合進行。經過負載測試，肯定在各類工做負載下系統的性能，目標是測試當負載逐漸增長時，系統各項性能指標的變化狀況。壓力測試是經過肯定一個系統的瓶頸或者不能接收的性能點，來得到系統能提供的最大服務級別的測試。
　　界面測試，界面是軟件與用戶交互的最直接的層，界面的好壞決定用戶對軟件的第一印象。並且設計良好的界面可以引導用戶本身完成相應的操做，起到嚮導的做用。同時界面如同人的面孔，具備吸引用戶的直接優點。設計合理的界面能給用戶帶來輕鬆愉悅的感覺和成功的感受，相反因爲界面設計的失敗，讓用戶有挫敗感，再實用強大的功能均可能在用戶的畏懼與放棄中付諸東流。
　　區別在於，功能測試關注產品的全部功能上，要考慮到每一個細節功能，每一個可能存在的功能問題。性能測試主要關注於產品總體的多用戶併發下的穩定性和健壯性。界面測試更關注於用戶體驗上，用戶使用該產品的時候是否易用，是否易懂，是否規範（快捷鍵之類的），是否美觀（可否吸引用戶的注意力），是否安全（儘可能在前臺避免用戶無心輸入無效的數據，固然考慮到體驗性，不能太粗魯的彈出警告）？作某個性能測試的時候，首先它多是個功能點，首先要保證它的功能是沒問題的，而後再考慮該功能點的性能測試

6九、您認爲作好測試用例設計工做的關鍵是什麼？

參考答案：

       白盒測試用例設計的關鍵是以較少的用例覆蓋儘量多的內部程序邏輯結果
黑盒法用例設計的關鍵一樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可能作到徹底測試，以最少的用例在合理的時間內發現最多的問題

70、請試着比較一下黑盒測試、白盒測試、單元測試、集成測試、系統測試、驗收測試的區別與聯繫。

參考答案：

       黑盒測試：已知產品的功能設計規格，能夠進行測試證實每一個實現了的功能是否符合要求。
　　白盒測試：已知產品的內部工做過程，能夠經過測試證實每種內部操做是否符合設計規格要求，全部內部成分是否以通過檢查。
　　軟件的黑盒測試意味着測試要在軟件的接口處進行。這種方法是把測試對象看作一個黑盒子，測試人員徹底不考慮程序內部的邏輯結構和內部特性，只依據程序的需求規格說明書，檢查程序的功能是否符合它的功能說明。所以黑盒測試又叫功能測試或數據驅動測試。黑盒測試主要是爲了發現如下幾類錯誤：
　　1、是否有不正確或遺漏的功能？
　　2、在接口上，輸入是否能正確的接受？可否輸出正確的結果？
　　3、是否有數據結構錯誤或外部信息（例如數據文件）訪問錯誤？
　　4、性能上是否可以知足要求？
　　5、是否有初始化或終止性錯誤？
　　軟件的白盒測試是對軟件的過程性細節作細緻的檢查。這種方法是把測試對象看作一個打開的盒子，它容許測試人員利用程序內部的邏輯結構及有關信息，設計或選擇測試用例，對程序全部邏輯路徑進行測試。經過在不一樣點檢查程序狀態，肯定實際狀態是否與預期的狀態一致。所以白盒測試又稱爲結構測試或邏輯驅動測試。白盒測試主要是想對程序模塊進行以下檢查：
　　1、對程序模塊的全部獨立的執行路徑至少測試一遍。
　　2、對全部的邏輯斷定，取「真」與取「假」的兩種狀況都能至少測一遍。
　　3、在循環的邊界和運行的界限內執行循環體。
　　4、測試內部數據結構的有效性，等等。
　　單元測試（模塊測試）是開發者編寫的一小段代碼，用於檢驗被測代碼的一個很小的、很明確的功能是否正確。一般而言，一個單元測試是用於判斷某個特定條件（或者場景）下某個特定函數的行爲。
　　單元測試是由程序員本身來完成，最終受益的也是程序員本身。能夠這麼說，程序員有責任編寫功能代碼，同時也就有責任爲本身的代碼編寫單元測試。執行單元測試，就是爲了證實這段代碼的行爲和咱們指望的一致。
　　集成測試（也叫組裝測試，聯合測試）是單元測試的邏輯擴展。它的最簡單的形式是：兩個已經測試過的單元組合成一個組件，而且測試它們之間的接口。從這一層意義上講，組件是指多個單元的集成聚合。在現實方案中，許多單元組合成組件，而這些組件又聚合成程序的更大部分。方法是測試片斷的組合，並最終擴展進程，將您的模塊與其餘組的模塊一塊兒測試。最後，將構成進程的全部模塊一塊兒測試。
　　系統測試是將通過測試的子系統裝配成一個完整系統來測試。它是檢驗系統是否確實能提供系統方案說明書中指定功能的有效方法。（常見的聯調測試）
　　系統測試的目的是對最終軟件系統進行全面的測試，確保最終軟件系統知足產品需求而且遵循系統設計。
　　驗收測試是部署軟件以前的最後一個測試操做。驗收測試的目的是確保軟件準備就緒，而且可讓最終用戶將其用於執行軟件的既定功能和任務。
驗收測試是向將來的用戶代表系統可以像預約要求那樣工做。經集成測試後，已經按照設計把全部的模塊組裝成一個完整的軟件系統，接口錯誤也已經基本排除了，接着就應該進一步驗證軟件的有效性，這就是驗收測試的任務，即軟件的功能和性能如同用戶所合理期待的那樣。

7一、測試計劃工做的目的是什麼？測試計劃工做的內容都包括什麼？其中哪些是最重要的？

參考答案：

       軟件測試計劃是指導測試過程的綱領性文件，包含了產品概述、測試策略、測試方法、測試區域、測試配置、測試周期、測試資源、測試交流、風險分析等內容。藉助軟件測試計劃，參與測試的項目成員，尤爲是測試管理人員，能夠明確測試任務和測試方法，保持測試實施過程的順暢溝通，跟蹤和控制測試進度，應對測試過程當中的各類變動。
測試計劃和測試詳細規格、測試用例之間是戰略和戰術的關係，測試計劃主要從宏觀上規劃測試活動的範圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。因此其中最重要的是測試測試策略和測試方法（最好是能先評審）

7二、您所熟悉的測試用例設計方法都有哪些？請分別以具體的例子來講明這些方法在測試用例設計工做中的應用。

參考答案：

       1．等價類劃分
　　劃分等價類: 等價類是指某個輸入域的子集合.在該子集合中,各個輸入數據對於揭露程序中的錯誤都是等效的.併合理地假定:測試某等價類的表明值就等於對這一類其它值的測試.所以,能夠把所有輸入數據合理劃分爲若干等價類,在每個等價類中取一個數據做爲測試的輸入條件,就能夠用少許表明性的測試數據.取得較好的測試結果.等價類劃分可有兩種不一樣的狀況:有效等價類和無效等價類.
　　2．邊界值分析法
　　邊界值分析方法是對等價類劃分方法的補充。測試工做經驗告訴我,大量的錯誤是發生在輸入或輸出範圍的邊界上,而不是發生在輸入輸出範圍的內部.所以針對各類邊界狀況設計測試用例,能夠查出更多的錯誤.
　　使用邊界值分析方法設計測試用例,首先應肯定邊界狀況.一般輸入和輸出等價類的邊界,就是應着重測試的邊界狀況.應當選取正好等於,剛剛大於或剛剛小於邊界的值做爲測試數據,而不是選取等價類中的典型值或任意值做爲測試數據.
    3．錯誤推測法
　　基於經驗和直覺推測程序中全部可能存在的各類錯誤, 從而有針對性的設計測試用例的方法.
　　錯誤推測方法的基本思想: 列舉出程序中全部可能有的錯誤和容易發生錯誤的特殊狀況,根據他們選擇測試用例. 例如, 在單元測試時曾列出的許多在模塊中常見的錯誤. 之前產品測試中曾經發現的錯誤等, 這些就是經驗的總結. 還有, 輸入數據和輸出數據爲0的狀況. 輸入表格爲空格或輸入表格只有一行. 這些都是容易發生錯誤的狀況. 可選擇這些狀況下的例子做爲測試用例.
    4．因果圖方法
　　前面介紹的等價類劃分方法和邊界值分析方法,都是着重考慮輸入條件,但未考慮輸入條件之間的聯繫, 相互組合等. 考慮輸入條件之間的相互組合,可能會產生一些新的狀況. 但要檢查輸入條件的組合不是一件容易的事情, 即便把全部輸入條件劃分紅等價類,他們之間的組合狀況也至關多. 所以必須考慮採用一種適合於描述對於多種條件的組合,相應產生多個動做的形式來考慮設計測試用例. 這就須要利用因果圖（邏輯模型）. 因果圖方法最終生成的就是斷定表. 它適合於檢查程序輸入條件的各類組合狀況.

7三、請以您以往的實際工做爲例，詳細的描述一次測試用例設計的完整的過程。

參考答案：

       就說最近的此次網站功能的測試吧
　　首先：獲得相關文檔（需求文檔和設計文檔），理解需求和設計設計思想後，想好測試策略（測試計劃簡單點就OK了），考慮到測試環境，測試用例，測試時間等問題。
　　第二步：設計測試用例，測試策略是：把網站部分的功能點測試完，而後在進行系統測試（另外個模塊呢有另外一個測試人員負責，能夠進行聯調測試），網站模塊的測試基本是功能測試和界面測試（用戶併發的可能性很小，因此不考慮）：此次的網站的輸入數據呢是使用數據庫中的某張表記錄，若是表中某一數據記錄中新加進來的（尚未被處理的，有個標誌位），網站啓動後會馬上去刷那張表，獲得多條數據，而後在進行處理。處理過程當中，會經歷3個步驟，網站纔算完成了它的任務。有3個步驟呢，就能夠分別對　　這3個步驟進行測試用例的設計,儘可能覆蓋到各類輸入狀況（包括數據庫中的數據，用戶的輸入等），得出了差很少50個用例。界面測試，也就是用戶看的到的地方，包括髮送的郵件和用戶填寫資料的頁面展現。
　　第三步：搭建測試環境（爲何這個時候考慮測試環境呢？由於我對網站環境已經很熟了，只有有機器能空於下來作該功能測試就能夠作了），由於網站自己的環境搭建和其餘的系統有點不一樣，它須要的測試環境比較麻煩，須要web服務器（Apache,tomcat），不過此次需求呢，網站部分只用到了tomcat，因此只要有tomcat便可
　　第四步：執行測試

7四、您以往是否曾經從事過性能測試工做？若是有，請儘量的詳細描述您以往的性能測試工做的完整過程。

參考答案：（以本身最熟悉的性能測試項目爲例）

       是的，曾經作過網站方面的性能測試，雖然作的時間並不久（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 ：嘗試連接數；　

7五、你對測試最大的興趣在哪裏？爲何？

參考答案：

       最大的興趣就是測試有難度，有挑戰性！作測試越久越能感受到作好測試有多難。曾經在無憂測試網上看到一篇文章，是關於如何作好一名測試工程師。一共羅列了11，12點，有部分是和人的性格有關，有部分須要後天的努力。但除了性格有關的1，2點我沒有把握，其餘點我都頗有信心作好它。
　　剛開始進入測試行業時，對測試的認識是從無憂測試網上了解到的一些資料，當時是衝着作測試須要不少技能才能作的好，雖然入門容易，但作好很難，比開發更難，雖然當時我很想作開發（學校專業課我基本上不缺席，由於我喜歡個人專業），但看到測試比開發更難更有挑戰性，想作好測試的意志就更堅決了。
　　不到一年半的測試工做中，當時的感動和熱情沒有減退一點（即便環境問題以及自身經驗，技術的不足，作測試的你必定也能理解）。
　　我以爲作測試整個過程當中有2點讓我以爲頗有難度（對我來講，有難度的東西我就很是感興趣），第一是測試用例的設計，由於測試的精華就在測試用例的設計上了，要在版本出來以前，把用例寫好，用什麼測試方法寫？（也就是測試計劃或測試策略），若是你剛測試一個新任務時，你得花必定的時間去消化業務需求和技術基礎，業務需求很好理解（多和產品經理和開發人員溝通就能達到目的），而技術基礎可就沒那麼簡單了，這須要你自覺的學習能力，好比說網站吧，最基本的技術知識你要知道網站內部是怎麼運做的的，後臺是怎麼響應用戶請求的？測試環境如何搭建？這些都須要最先的學好。至少在開始測試以前能作好基本的準備，可能會遇到什麼難題？需求細節是否是沒有肯定好？這些問題都能在設計用例的時候發現。
　　第二是發現BUG的時候了，這應該是測試人員最基本的任務了，通常按測試用例開始測試就能發現大部分的bug，還有一部分bug須要測試的過程當中更瞭解所測版本的狀況得到更多信息，補充測試用例，測試出bug。還有如何發現bug？這就須要在測試用例有效的狀況下，經過細心和耐心去發現bug了，每一個用例都有可能發現bug，每一個地方都有可能出錯，因此測試過程當中思惟要清晰（測試過程數據流及結果都得看仔細了，bug都在裏面發現的）。如何描述bug也頗有講究，bug在什麼狀況下會產生，若是條件變化一點點，就不會有這個bug，以哪些最少的操做步驟就能重現這個bug，這個bug產生的規律是什麼？若是你夠厲害的話，能夠幫開發人員初步定位問題。

7六、你之前工做時的測試流程是什麼？

參考答案：（靈活回答）

公司對測試流程沒有規定如何作，但每一個測試人員都有本身的一套測試流程。我說下我1年來不斷改正（本身總結，吸收同行的方法）後的流程吧。需求評審（有開發人員，產品經理，測試人員，項目經理）－>需求肯定(出一份肯定的需求文檔)－>開發設計文檔（開發人員在開始寫代碼前就能輸出設計文檔）－>想好測試策略，寫出測試用例－>發給開發人員和測試經理看看（非正式的評審用例）－>接到測試版本－>執行測試用例（中間可能會補充用例）－>提交bug（有些bug須要開發人員的肯定（嚴重級別的，或忽然發現的在測試用例範圍以外的，難以重現的），有些能夠直接錄製進TD）－>開發人員修改（能夠在測試過程當中快速的修改）－>迴歸測試（可能又會發現新問題，再按流程開始跑）。

7七、當開發人員說不是BUG時，你如何應付？

參考答案：
　　開發人員說不是bug，有2種狀況，一是需求沒有肯定，因此我能夠這麼作，這個時候能夠找來產品經理進行確認，需不須要改動，3方商量肯定好後再看要不要改。二是這種狀況不可能發生，因此不須要修改，這個時候，我能夠先儘量的說出是BUG的依據是什麼？若是被用戶發現或出了問題，會有什麼不良結果？程序員可能會給你不少理由，你能夠對他的解釋進行反駁。若是仍是不行，那我能夠給這個問題提出來,跟開發經理和測試經理進行確認,若是要修改就改,若是不要修改就不改。其實有些真的不是bug，我也只是建議的方式寫進TD中，若是開發人員不修改也沒有大問題。若是肯定是bug的話，必定要堅持本身的立場，讓問題獲得最後的確認。

7八、軟件的構造號與版本號之間的區別？BVT(BuildVerificationTest)

參考答案：版本控制命名格式: 主版本號.子版本號[.修正版本號[.編譯版本號 ]]

Major.Minor [.Revision[.Build]]

      應根據下面的約定使用這些部分：

Major ：具備相同名稱但不一樣主版本號的程序集不可互換。例如，這適用於對產品的大量重寫，這些重寫使得沒法實現向後兼容性。

Minor ：若是兩個程序集的名稱和主版本號相同，而次版本號不一樣，這指示顯著加強，但照顧到了向後兼容性。例如，這適用於產品的修正版或徹底向後兼容的新版本。

Build ：內部版本號的不一樣表示對相同源所做的從新編譯。這適合於更改處理器、平臺或編譯器的狀況。

Revision ：名稱、主版本號和次版本號都相同但修訂號不一樣的程序集應是徹底可互換的。這適用於修復之前發佈的程序集中的安全漏洞。

BVT(BuildVerificationTest)：

做爲Build的一部分，主要是經過對基本功能、特別是關鍵功能的測試，保證新增代碼沒有致使功能失效，保證版本的持續穩定。實現BVT方式是有如下幾種：1、測試人員手工驗證關鍵功能實現的正確性。特色：這是傳統開發方法中，一般採用的方式。無需維護測試腳本的成本，在測試人力資源充足，測試人員熟悉業務、並對系統操做熟練狀況下效率很高，比較靈活快速。缺點：人力成本較高；對測試人員能力有必定要求；測試人員面對重複的工做，容易產生疲倦懈怠，從而影響測試質量。2、藉助基於GUI的自動化功能測試工具來完成，將各基本功能操做錄製成測試腳本，每次回放測試腳本驗證功能實現的正確性。特色：可以模擬用戶操做完成自動的測試，從UI入口到業務實現，每一層的代碼實現都通過驗證；節約人力成本；下降測試人員重複勞動的工做量，機器不會疲倦；缺點：對於UI變更比較頻繁的系統來講，這種方式的維護成本很高，實施起來很是困難。另外，在項目週期較短且後續無延續性或繼承的狀況下，也不推薦使用此方式。3、由開發人員經過自動化測試工具完成業務層的BVT測試。特色：經過對業務層關鍵功能的持續集成測試，保證系統功能的持續穩定。能夠結合DailyBuild，作爲Build的一部分，自動實現並輸入BVT報告。缺點：僅對業務規則實現的正確性進行了測試，對錶現層沒法測試到，對於諸如：前臺頁面控件各類事件響應、頁面元素變化等方面的問題沒法保證。

7九、您以往的工做中，一條軟件缺陷（或者叫Bug）記錄都包含了哪些內容？如何提交高質量的軟件缺陷（Bug）記錄？

參考答案：

80、您以往所從事的軟件測試工做中，是否使用了一些工具來進行軟件缺陷（Bug）的管理？若是有，請結合該工具描述軟件缺陷（Bug）跟蹤管理的流程。

參考答案：

8一、您認爲性能測試工做的目的是什麼？作好性能測試工做的關鍵是什麼？

參考答案：

8二、單元測試、集成測試、系統測試的側重點是什麼？

       參考答案：

8三、集成測試一般都有那些策略？

參考答案：

8四、一個缺陷測試報告的組成

參考答案：

8五、基於WEB信息管理系統測試時應考慮的因素有哪些？

參考答案：

8六、軟件測試項目從何時開始，？爲何？

參考答案：

8七、需求測試注意事項有哪些？

參考答案：

8八、簡述一下缺陷的生命週期

參考答案：

8九、你在你所在的公司是怎麼開展測試工做的？是如何組織的？

參考答案：

90、你認爲理想的測試流程是什麼樣子？

參考答案：

9一、您在從事性能測試工做時，是否使用過一些測試工具？若是有，請試述該工具的工做原理，並以一個具體的工做中的例子描述該工具是如何在實際工做中應用的。

參考答案：        

9二、軟件測試活動的生命週期是什麼？

參考答案：

9三、請畫出軟件測試活動的流程圖？

參考答案：

9四、針對缺陷採起怎樣管理措施？

參考答案：

9五、什麼是測試評估？測試評估的範圍是什麼？

參考答案：

9六、若是可以執行完美的黑盒測試，還須要進行白盒測試嗎？爲何？

參考答案：

9七、測試結束的標準是什麼？

參考答案：

9八、軟件驗收測試除了alpha ,beta測試之外,還有哪種?

參考答案：

9九、作測試多久了？之前作過哪些項目？大家之前測試的流程是怎樣的？用過哪些測試工具？

參考答案：

100、請就如何在開發中進行軟件質量控制說說你的見解

參考答案：

10一、一套完整的測試應該由哪些階段組成？分別闡述一下各個階段。

10二、軟件測試的類型有那些？分別比較這些不一樣的測試類型的區別與聯繫。

10三、測試用例一般包括那些內容？着重闡述編制測試用例的具體作法

10四、在分別測試winform的C/S結構與測試WEB結構的軟件是，應該採起什麼樣的方法分別測試？他們存在什麼樣的區別與聯繫？

10五、在測試winform的C/S結構軟件時，發現這個軟件的運行速度很慢，您會認爲是什麼緣由？您會採起哪些方法去檢查這個緣由？

10六、描述使用bugzilla缺陷管理工具對軟件缺陷（BUG）跟蹤的管理的流程

10七、你都用什麼測試方法
針對不一樣的產品或者系統或者模塊，有不一樣的測試方法。整體而言有白盒測試和黑盒測試。

10八、怎麼編寫案例
案例的編寫與測試階段的定義有很大的關係。系統測試和unit測試的案例可能不一樣。整體而言測試案例根據系統的需求而定。

10九、怎麼纔可以全面的測試到每個點
測試的全面性主要須要在設計測試計劃的時候考慮，從測試策略，產品需求等等多個角度考慮從而定義所有的測試點。

1十、談談軟件測試技術，以及如何提升

1十一、談談軟件測試職業發展，以及我的的打算

1十二、談談軟件測試在企業的地位，也能夠結合軟件生命週期來談

11三、通常公司裏實際的軟件測試流程是什麼樣的？大家公司又是怎樣的？

11四、軟件工程師要具備那些素質？

11五、你會哪些測試工具？怎麼操做？

11六、你能不能說下你的3到5年的職業計劃（規劃）

11七、你以爲你來應聘有那些優點？

其餘問題：（有可能清晰的思路比確切的答案更重要）

對測試的理解——考查點：基本的測試知識，對測試是否定可
談一談過去本身的工做——考查點：瞭解經歷、提供進一步提問的素材，表達能力、測試技能 
測試設計的方法並舉例說明——考查點：測試技術的使用 
測試工具——考查點：熟悉程度，可否與當前工做匹配？
如何作計劃？如何跟蹤計劃？——考查點：平常工做能力 
若是開發人員提供的版本不知足測試的條件，如何作？——考查點：與開發人員協做的能力 
熟悉unix系統、oracle數據庫嗎？——考查點：是否具有系統知識 
作過開發嗎？寫過哪些代碼？——考查點：開發技能 
閱讀英語文章，給出理解說明？——考查點：部分英語能力 
文檔的意義——考查點：是否善於思考？（最簡單的概念，不一樣層次的理解） 
假如進入咱們公司，對咱們哪些方面會有幫助？——考查點：講講本身的特長

隨便找一件物品，讓其測試——考查點：測試的實際操做能力
有一個新的軟件，假如你是測試工程師，該如何作——考查點：實際項目經驗、是否有帶領測試團隊的經驗和潛力

開發及環境搭建類面試題

一、描述軟件產生內存泄露的緣由以及檢查方式。（能夠結合一種開發語言進行描述）

參考答案：

內存泄露的緣由，主要是因爲開發過程中申請了計算機資源（例如對象、內存等），可是使用資源完成之後沒有及時釋放資源致使的。例如在C語言當中使用了malloc申請了內存，可是未使用free來釋放內存。

二、簡述什麼是值傳遞，什麼是地址傳遞，二者區別是什麼？

參考答案：

值傳遞主調函數傳遞給被調函數的是值的拷貝，不是原值；地址傳遞主調函數傳遞給被調函數的是值的地址。區別是值傳遞被調函數中的操做不改變主調函數的值，而地址傳遞則不一樣。

三、結構化程序設計和麪向對象程序設計各自的特色及優缺點是什麼？

參考答案：（不須要回答如此複雜）

結構化程序設計思想採用了模塊分解與功能抽象和自頂向下、分而治之的方法，從而有效地將一個較複雜的程序系統設計任務分解成許多易於控制和處理的子程序，便於開發和維護。它的重點在於把功能進行分解。可是因爲在實際開發過程中需求會常常發生變化，所以，它不能很好的適應需求變化的開發過程。結構化程序設計是面向過程的。

面向對象程序設計以需求當中的數據做爲中心，來進行設計，具備良好的代碼重用性。

封裝性：也叫數據隱藏，用戶無需知道內部工做流程，只要知道接口和操做就能夠的，C++中通常用類來實現封裝。

繼承性：一種支持重用的思想，在現有的類型派生出新的子類，例如新型電視機在原有型號的電視機上增長若干中功能而獲得，新型電視機是原有電視機的派生，繼承了原有電視機的屬性，並增長了新的功能。

多態性：指在通常類中定義的屬性或行爲，被特殊類繼承以後，能夠具備不一樣的數據類型或表現出不一樣的行爲。

動態聯編：指一個計算機程序自身彼此關聯的過程，按照聯編所進行的階段不一樣，可分爲兩種不一樣的聯編方法：靜態聯編和動態聯編。

四、簡述什麼是存儲過程和觸發器？

參考答案：

存儲過程：是數據庫中的一個對象，Transact-SQL 語句的預編譯集合，這些語句在一個名稱下存儲並做爲一個單元進行處理。（能夠理解爲C語言中的函數，有參數、返回值等函數特性）

觸發器是一種特殊類型的存儲過程，當使用下面的一種或多種數據修改操做在指定表中對數據進行修改時，觸發器會生效：UPDATE、INSERT 或 DELETE。

五、使用C語言編寫一個函數，用於交換兩個變量的值（地址傳遞）。

       參考答案：

       void Swap(int *a,int *b)

{

              int temp;

              int temp=*a;

              int *a=*b;

              int *b=temp;

}

六、請簡述DNS、活動目錄、域的概念。

參考答案：

DNS：域名服務，做用是將網絡域名解析成IP地址；

活動目錄：微軟提供的目錄服務的一種，它存儲有關網絡上的對象信息，並使管理員和用戶更方便的查找和使用這類信息；

域：網絡系統的一個安全邊界，在一個域當中，計算機和用戶共享一些列的安全信息。

七、描述TCP/IP協議的層次結構，以及每一層中重要協議。

參考答案：（能夠回答五層結構）

TCP/IP	協議
應用層/Application	HTTP、SMTP、FTP
傳輸層/Transport	TCP、UDP
網絡層/Network	IP
鏈路層/Link	ARP、RARP

      

 

 

 

 

 

八、簡述子網掩碼的用途。

參考答案：

    子網掩碼主要用來判斷兩個IP地址是否處在同一個局域網當中；子網掩碼是由連續的2進制1組成的。子網掩碼和IP地址進行按位與運算後，結果一致，表示處於一個局域網當中，若是不一致，表示再也不一個局域網當中，須要尋找路由。

九、說出4種以上經常使用的操做系統及其主要的應用範圍（微軟的操做系統除外）。

參考答案：

Linux（Red Hat、SUSE、Debian、Trubo Linux）：主要用於搭建各種服務器

MAC OS：蘋果機的操做系統，用於圖像處理

Unix（AIX：IBM服務器的專用操做系統；

Solaris：Sun操做系統；FreeBSD、NetBSD）

十、在Linux系統中，一個文件的訪問權限是755，其含義是什麼？

參考答案：

       755表示該文件全部者對該文件具備讀、寫、執行權限，該文件全部者所在組用戶及其餘用戶對該文件具備讀和執行權限。

十一、Windows操做系統中PATH環境變量的做用是什麼？

參考答案：

       PATH是Windows操做系統環境變量，PATH做用是用戶在命令行窗口執行一個命令，則在PATH變量設置的目錄下依次尋找該命令或對應的執行文件，若找到，則執行，若沒有找到，則命令行窗口返回無效命令。

十二、Ghost的主要用途和經常使用方法？

參考答案：

Ghost是一個很是著名的硬盤克隆工具。該工具的主要做用是能夠將一個硬盤或硬盤中的某個分區原封不動的複製到另外一個硬盤或其餘的分區中。若是你須要備份啓動分區或者是須要在多臺機器上安裝相應的系統和應用程序，均可以經過Ghost來實現，相信經過這個工具有份，恢復速度和硬盤安裝速度會成倍的提升。

Norton Ghost有一個很大的特色，就是在克隆硬盤時不會改變任何文件信息，程序能夠很好的支持FAT16、FAT32以及NTFS格式的文件分配結構（其中包括Windows 2000的文件分配格式），雖然是DOS環境下運行的程序，但工具可支持Win 9x的長文件名特性。

經常使用方法包括：硬盤克隆、分區克隆、硬盤或分區克隆成鏡像文件等。

1三、在RedHat中，從root用戶切到userl用戶，通常用什麼命令？

參考答案：su

su user1  切換到user1，但切換後的當前目錄仍是root訪問的目錄

su – user1 切換到user1，而且當前目錄切換到user1的根目錄下（/home/user1/）

1四、Linux中，通常怎麼隱藏文件？

參考答案：文件名以一個.開頭

1五、如何將本身的本地磁盤（D）作成FTP供遠端主機使用？

參考答案：Windows下安裝FTP服務，並將FTP的根目錄指向D盤便可。

1六、對RUP.CMM,CMMI,XP,PSP.TSP的認識？

參考答案：軟件過程標準：CMMI、PSP、TSP、RUP、軟件工程規範國家標準；（AP、XP、ASD等開發過程思想好像還不能稱其爲標準）

RUP（Rational Unified Process）是Rational公司提出的一套開發過程模型，它是一個面向對象軟件工程的通用業務流程。它描述了一系列相關的軟件工程流程，它們具備相同的結構，即相同的流程構架。RUP 爲在開發組織中分配任務和職責提供了一種規範方法，其目標是確保在可預計的時間安排和預算內開發出知足最終用戶需求的高品質的軟件。RUP具備兩個軸，一個軸是時間軸，這是動態的。另外一個軸是工做流軸，這是靜態的。在時間軸上，RUP劃分了四個階段：初始階段、細化階段、構造階段和發佈階段。每一個階段都使用了迭代的概念。在工做流軸上，RUP設計了六個核心工做流程和三個核心支撐工做流程，核心工做流軸包括：業務建模工做流、需求工做流、分析設計工做流、實現工做流、測試工做流和發佈工做流。核心支撐工做流包括：環境工做流、項目管理工做流和配置與變動管理工做流。RUP 聚集現代軟件開發中多方面的最佳經驗，併爲適應各類項目及組織的須要提供了靈活的形式。做爲一個商業模型，它具備很是詳細的過程指導和模板。可是一樣因爲該模型比較複雜，所以在模型的掌握上須要花費比較大的成本。尤爲對項目管理者提出了比較高的要求。

CMM(Capability Maturity Model能力成熟度模型) 由美國卡內基-梅隆大學的軟件工程研究所（簡稱SEI）受美國國防部委託，於1991年研究制定，初始的主要目的是爲了評價美國國防部的軟件合同承包組織的能力，後由於在軟件企業應用CMM模型實施過程改進取得較大的成功，因此在全世界範圍內被普遍使用，SEI同時創建了主任評估師評估制度，CMM的評估方法爲CBA－IPI。CMM的本質是軟件管理工程的一個部分。它是對於軟件組織在定義，實現，度量，控制和改善其軟件過程的進程中各個發展階段的描述。他經過5個不斷進化的層次來評定軟件生產的歷史與現狀：初始層是混沌的過程；可重複層是通過訓練的軟件過程；定義層是標準一致的軟件過程；管理層是可預測的軟件過程；優化層是能持續改善的軟件過程。

CMM/PSP/TSP即軟件能力成熟度模型/ 個體軟件過程/羣組軟件過程，是1987年美國 Carnegie Mellon 大學軟件工程研究所(CMU/SEI)以W.S.Humphrey爲首的研究組發表的研究成果"承製方軟件工程能力的評估方法"。

CMMI是SEI於2000年發佈的CMM的新版本。CMMI不但包括了軟件開發過程改進，還包含系統集成、軟硬件採購等方面的過程改進內容。

CMMI糾正了CMM存在的一些缺點，使其更加適用企業的過程改進實施。CMMI適用SCAMPI評估方法。須要注意的是，SEI沒有廢除CMM模型，只是中止了CMM評估方法：CBA－IPI。如今如要進行CMM評估，需使用SCAMPI方法。但CMMI模型最終代替CMM模型的趨勢不可避免。

XP （極限編程）規定了一組核心價值和方法，可讓軟件開發人員發揮他們的專長：編寫代碼。XP 消除了大多數重量型過程的沒必要要產物，經過減慢開發速度、耗費開發人員的精力（例如干特圖、狀態報告，以及多卷需求文檔）從目標偏離。

XP 的核心價值：交流、簡單、反饋、勇氣。

1七、DNS是什麼,它是如何工做的?

參考答案：域名解析服務。用於將域名解析爲IP，或反和將IP解析爲域名。

客戶機可指定DNS服務器來解析，或用本機hosts文件進行解析。

Windows下配置DNS服務器在《搭建Windows測試環境》中有。

1八、防火牆如何保證安全的？主要有哪些？

參考答案：防火牆分類1

從防火牆的軟、硬件形式來分的話，防火牆能夠分爲軟件防火牆和硬件防火牆以及芯片級防火牆。

第一種：軟件防火牆

軟件防火牆運行於特定的計算機上，它須要客戶預先安裝好的計算機操做系統的支持，通常來講這臺計算機就是整個網絡的網關。俗稱「我的防火牆」。軟件防火牆就像其它的軟件產品同樣須要先在計算機上安裝並作好配置才能夠使用。防火牆廠商中作網絡版軟件防火牆最出名的莫過於Checkpoint。使用這類防火牆，須要網管對所工做的操做系統平臺比較熟悉。

第二種：硬件防火牆

這裏說的硬件防火牆是指「所謂的硬件防火牆」。之因此加上"所謂"二字是針對芯片級防火牆說的了。它們最大的差異在因而否基於專用的硬件平臺。目前市場上大多數防火牆都是這種所謂的硬件防火牆，他們都基於PC架構，就是說，它們和普通的家庭用的PC沒有太大區別。在這些PC架構計算機上運行一些通過裁剪和簡化的操做系統，最經常使用的有老版本的Unix、Linux和FreeBSD系統。值得注意的是，因爲此類防火牆採用的依然是別人的內核，所以依然會受到OS（操做系統）自己的安全性影響。

傳統硬件防火牆通常至少應具有三個端口，分別接內網，外網和DMZ區（非軍事化區），如今一些新的硬件防火牆每每擴展了端口，常見四端口防火牆通常將第四個端口作爲配置口、管理端口。不少防火牆還能夠進一步擴展端口數目。

第三種：芯片級防火牆

芯片級防火牆基於專門的硬件平臺，沒有操做系統。專有的ASIC芯片促使它們比其餘種類的防火牆速度更快，處理能力更強，性能更高。作這類防火牆最出名的廠商有NetScreen、FortiNet、Cisco等。這類防火牆因爲是專用OS（操做系統）,所以防火牆自己的漏洞比較少，不過價格相對比較高昂。

防火牆技術雖然出現了許多，但整體來說可分爲「包過濾型」和「應用代理型」兩大類。前者以以色列的Checkpoint防火牆和美國Cisco公司的PIX防火牆爲表明，後者以美國NAI公司的Gauntlet防火牆爲表明。

(1). 包過濾(Packet filtering)型

包過濾型防火牆工做在OSI網絡參考模型的網絡層和傳輸層，它根據數據包頭源地址，目的地址、端口號和協議類型等標誌肯定是否容許經過。只有知足過濾條件的數據包才被轉發到相應的目的地，其他數據包則被從數據流中丟棄。

包過濾方式是一種通用、廉價和有效的安全手段。之因此通用，是由於它不是針對各個具體的網絡服務採起特殊的處理方式，適用於全部網絡服務；之因此廉價，是由於大多數路由器都提供數據包過濾功能，因此這類防火牆多數是由路由器集成的；之因此有效，是由於它能很大程度上知足了絕大多數企業安全要求。

在整個防火牆技術的發展過程當中，包過濾技術出現了兩種不一樣版本，稱爲「第一代靜態包過濾」和「第二代動態包過濾」。

●第一代靜態包過濾類型防火牆

這類防火牆幾乎是與路由器同時產生的，它是根據定義好的過濾規則審查每一個數據包，以便肯定其是否與某一條包過濾規則匹配。過濾規則基於數據包的報頭信息進行制訂。報頭信息中包括IP源地址、IP目標地址、傳輸協議(TCP、UDP、ICMP等等)、TCP/UDP目標端口、ICMP消息類型等。

●第二代動態包過濾類型防火牆

這類防火牆採用動態設置包過濾規則的方法，避免了靜態包過濾所具備的問題。這種技術後來發展成爲包狀態監測(Stateful Inspection)技術。採用這種技術的防火牆對經過其創建的每個鏈接都進行跟蹤，而且根據須要可動態地在過濾規則中增長或更新條目。

包過濾方式的優勢是不用改動客戶機和主機上的應用程序，由於它工做在網絡層和傳輸層，與應用層無關。但其弱點也是明顯的：過濾判別的依據只是網絡層和傳輸層的有限信息，於是各類安全要求不可能充分知足；在許多過濾器中，過濾規則的數目是有限制的，且隨着規則數目的增長，性能會受到很大地影響；因爲缺乏上下文關聯信息，不能有效地過濾如UDP、RPC（遠程過程調用）一類的協議；另外，大多數過濾器中缺乏審計和報警機制，它只能依據包頭信息，而不能對用戶身份進行驗證，很容易受到「地址欺騙型」攻擊。對安全管理人員素質要求高，創建安全規則時，必須對協議自己及其在不一樣應用程序中的做用有較深刻的理解。所以，過濾器一般是和應用網關配合使用，共同組成防火牆系統。

 (2). 應用代理(Application Proxy)型

應用代理型防火牆是工做在OSI的最高層，即應用層。其特色是徹底"阻隔"了網絡通訊流，經過對每種應用服務編制專門的代理程序，實現監視和控制應用層通訊流的做用。其典型網絡結構如圖所示。

在代理型防火牆技術的發展過程當中，它也經歷了兩個不一樣的版本，即：第一代應用網關型代理防火和第二代自適應代理防火牆。

第一代應用網關(Application Gateway)型防火牆

這類防火牆是經過一種代理(Proxy)技術參與到一個TCP鏈接的全過程。從內部發出的數據包通過這樣的防火牆處理後，就好像是源於防火牆外部網卡同樣，從而能夠達到隱藏內部網結構的做用。這種類型的防火牆被網絡安全專家和媒體公認爲是最安全的防火牆。它的核心技術就是代理服務器技術。

第二代自適應代理(Adaptive proxy)型防火牆

它是近幾年才獲得普遍應用的一種新防火牆類型。它能夠結合代理類型防火牆的安全性和包過濾防火牆的高速度等優勢，在絕不損失安全性的基礎之上將代理型防火牆的性能提升10倍以上。組成這種類型防火牆的基本要素有兩個：自適應代理服務器(Adaptive Proxy Server)與動態包過濾器(Dynamic Packet filter)。

在「自適應代理服務器」與「動態包過濾器」之間存在一個控制通道。在對防火牆進行配置時，用戶僅僅將所須要的服務類型、安全級別等信息經過相應Proxy的管理界面進行設置就能夠了。而後，自適應代理就能夠根據用戶的配置信息，決定是使用代理服務從應用層代理請求仍是從網絡層轉發包。若是是後者，它將動態地通知包過濾器增減過濾規則，知足用戶對速度和安全性的雙重要求。

代理類型防火牆的最突出的優勢就是安全。因爲它工做於最高層，因此它能夠對網絡中任何一層數據通訊進行篩選保護，而不是像包過濾那樣，只是對網絡層的數據進行過濾。

另外代理型防火牆採起是一種代理機制，它能夠爲每一種應用服務創建一個專門的代理，因此內外部網絡之間的通訊不是直接的，而都需先通過代理服務器審覈，經過後再由代理服務器代爲鏈接，根本沒有給內、外部網絡計算機任何直接會話的機會，從而避免了入侵者使用數據驅動類型的攻擊方式入侵內部網。

代理防火牆的最大缺點就是速度相對比較慢，當用戶對內外部網絡網關的吞吐量要求比較高時，代理防火牆就會成爲內外部網絡之間的瓶頸。那由於防火牆須要爲不一樣的網絡服務創建專門的代理服務，在本身的代理程序爲內、外部網絡用戶創建鏈接時須要時間，因此給系統性能帶來了一些負面影響，但一般不會很明顯。

防火牆分類3

從防火牆結構上分，防火牆主要有：單一主機防火牆、路由器集成式防火牆和分佈式防火牆三種。

單一主機防火牆是最爲傳統的防火牆，獨立於其它網絡設備，它位於網絡邊界。

這種防火牆其實與一臺計算機結構差很少（以下圖），一樣包括CPU、內存、硬盤等基本組件，固然主板更是不能少了，且主板上也有南、北橋芯片。它與通常計算機最主要的區別就是通常防火牆都集成了兩個以上的以太網卡，由於它須要鏈接一個以上的內、外部網絡。其中的硬盤就是用來存儲防火牆所用的基本程序，如包過濾程序和代理服務器程序等，有的防火牆還把日誌記錄也記錄在此硬盤上。雖然如此，但咱們不能說它就與咱們日常的PC機同樣，由於它的工做性質，決定了它要具有很是高的穩定性、實用性，具有很是高的系統吞吐性能。正因如此，看似與PC機差很少的配置，價格甚遠。

隨着防火牆技術的發展及應用需求的提升，原來做爲單一主機的防火牆如今已發生了許多變化。最明顯的變化就是如今許多中、高檔的路由器中已集成了防火牆功能，還有的防火牆已再也不是一個獨立的硬件實體，而是由多個軟、硬件組成的系統，這種防火牆，俗稱「分佈式防火牆」。

原來單一主機的防火牆因爲價格很是昂貴，僅有少數大型企業才能承受得起，爲了下降企業網絡投資，如今許多中、高檔路由器中集成了防火牆功能。如Cisco IOS防火牆系列。但這種防火牆一般是較低級的包過濾型。這樣企業就不用再同時購買路由器和防火牆，大大下降了網絡設備購買成本。

分佈式防火牆不再是隻是位於網絡邊界，而是滲透於網絡的每一臺主機，對整個內部網絡的主機實施保護。在網絡服務器中，一般會安裝一個用於防火牆系統管理軟件，在服務器及各主機上安裝有集成網卡功能的PCI防火牆卡，這樣一塊防火牆卡同時兼有網卡和防火牆的雙重功能。這樣一個防火牆系統就能夠完全保護內部網絡。各主機把任何其它主機發送的通訊鏈接都視爲「不可信」的，都須要嚴格過濾。而不是傳統邊界防火牆那樣，僅對外部網絡發出的通訊請求「不信任」。

防火牆分類4

若是按防火牆的應用部署位置分，能夠分爲邊界防火牆、我的防火牆和混合防火牆三大類。

邊界防火牆是最爲傳統的那種，它們於內、外部網絡的邊界，所起的做用的對內、外部網絡實施隔離，保護邊界內部網絡。這類防火牆通常都是硬件類型的，價格較貴，性能較好。

我的防火牆安裝於單臺主機中，防禦的也只是單臺主機。這類防火牆應用於廣大的我的用戶，一般爲軟件防火牆，價格最便宜，性能也最差。

混合式防火牆能夠說就是「分佈式防火牆」或者「嵌入式防火牆」，它是一整套防火牆系統，由若干個軟、硬件組件組成，分佈於內、外部網絡邊界和內部各主機之間，既對內、外部網絡之間通訊進行過濾，又對網絡內部各主機間的通訊進行過濾。它屬於最新的防火牆技術之一，性能最好，價格也最貴。

防火牆分類5

若是按防火牆的性能來分能夠分爲百兆級防火牆和千兆級防火牆兩類。

由於防火牆一般位於網絡邊界，因此不可能只是十兆級的。這主要是指防火的通道帶寬(Bandwidth)，或者說是吞吐率。固然通道帶寬越寬，性能越高，這樣的防火牆因包過濾或應用代理所產生的延時也越小，對整個網絡通訊性能的影響也就越小。

1九、目前流行的操做的系統有哪些？請舉例說明安裝操做系統的注意事項？

參考答案：MS Windows系列：win 98、windows 2000系列、win XP、win 2003 Server、win Vista等等。

UNIX類：SVRx、FreeBSD、OpenBSD、NetBSD、Solaris、各類Linux等等。Mac OS……

多重引導時，通常先安裝win操做系統，從低版本到高，再安裝Linux

20、簡述一下c/s模式或者b/s模式？

參考答案：C/S模式：客戶端/服務器模式。工做原理：Client向Server提交一個請求；Server則使用一些方法處理這個請求，並將效果返回給Client。

B/S結構，即Browser/Server(瀏覽器/服務器)結構，是隨着Internet技術的興起，對C/S結構的一種變化或者改進的結構。在這種結構下，用戶界面徹底經過WWW瀏覽器實現，一部分事務邏輯在前端實現，可是主要事務邏輯在服務器端實現，造成所謂3-tier結構。B/S結構，主要是利用了不斷成熟的WWW瀏覽器技術，結合瀏覽器的多種Script語言(VBScript、JavaScript…)和ActiveX技術，用通用瀏覽器就實現了原來須要複雜專用軟件才能實現的強大功能，並節約了開發成本，是一種全新的軟件系統構造技術。

2一、TCP/UDP有哪些區別？

參考答案：TCP-有鏈接,因此握手過程會消耗資源,過程爲可靠鏈接,不會丟失數據,適合大數據量交換

UDP-非可靠鏈接,會丟包,沒有校驗,速度快,無須握手過程

	TCP	UDP
是否鏈接	面向鏈接	面向非鏈接
傳輸可靠性	可靠的	不可靠的
應用場合	傳輸大量數據	少許數據
速度	慢	快

2二、ISO模型？HUB、tch、Router是ISO的第幾層設備？

參考答案：從底向上：物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層和應用層

HUB：1層（物理層）；Switch：2層（數據鏈路層）；Router：3層（網絡層）

2三、內存有哪幾種存儲組織結構.請分別加以說明？

參考答案：

人力資源面試題

一、你的測試職業發展是什麼？你自認爲作測試的優點在哪裏？

參考答案：

       測試經驗越多，測試能力越高。因此個人職業發展是須要時間累積的，一步步向着高級測試工程師奔去。並且我也有初步的職業規劃，前3年累積測試經驗，按如何作好測試工程師的要求本身，不斷的更新本身改正本身，作好測試任務。
　　優點在於我對測試堅決不移的信心和熱情，雖然經驗還不夠，但測試須要的基本技能我有信心在工做中得以發揮。

二、你爲何想離開目前的職務？

參考答案：

三、你對咱們公司瞭解有多少？

參考答案：

四、你找工做時，最重要的考慮因素爲什麼？

參考答案：工做的性質和內容是否能讓我發揮所長，並不斷成長。

五、爲何咱們應該錄取你？

參考答案：您能夠由我過去的工做表現所呈現的客觀數據，明顯地看出我盡心盡力的工做態度。

六、請談談你我的的最大特點。

參考答案：個人堅持度很高，事情沒有作到一個使人滿意的結果，毫不罷手。

七、一個測試工程師應具有那些素質和技能？

參考答案：

八、您認爲在測試人員同開發人員的溝經過程中，如何提升溝通的效率和改善溝通的效果？維持測試人員同開發團隊中其餘成員良好的人際關係的關鍵是什麼？

參考答案：

九、在您以往的測試工做中，最讓您感到不滿意或者不堪回首的事情是什麼？您是如何來對待這些事情的？

參考答案：

十、在即將完成此次筆試前，您是否願意談一些本身在以往的學習和工做中得到的工做經驗和心得體會？（能夠包括軟件測試、過程改進、軟件開發或者與此無關的其餘方面）

參考答案：

十一、爲何選擇測試這行？

參考答案：
　　它是一個新興的行業，有發展潛力，並且很鍛鍊人，須要掌握更多的技能，比作開發要更難

　　爲何值得他們公司僱用？若是我僱用你，你能給部門帶來什麼貢獻？
　　　　若是明知這樣作不對，你還會依主管的指過去作嗎

　　若是你接到一個客戶抱怨的電話，你確知沒法解決他的問題，你會怎麼處理

　　你以爲什麼樣的人最難相處

　　爲何值得他們公司僱用？

　　　　幫助公司提升軟件質量和測試部門的技術水平

　　若是我僱用你，你能給部門帶來什麼貢獻？

　　　　分享個人測試經驗和測試技能，提升測試部門技術水平
　　如何從工做中看出你是個自動自覺的人 
　　　     自動自覺範圍太廣
　    1. 工做成果
    　2. 工做質量  

十二、你的工做一般能在時限內完成嗎.（我想問一下就是她問這個問題的動機是什麼）

參考答案：
    在有足夠的資源和合理的工做量的狀況下，徹底能夠按時完成，並能比通常人作的更好

1三、一般你對於別人批評你會有什麼樣的反應

參考答案：有錯即改，無錯勉之

1四、若是明知這樣作不對，你還會依主管的指過去作嗎？

       參考答案：

1五、若是你接到一個客戶抱怨的電話，你確知沒法解決他的問題，你會怎麼處理？

參考答案：
    弄清楚客戶爲何抱怨？是怎麼樣的問題？
　　若是是客服問題，提交客服部門解決
　　若是是質量問題，分析緣由，下一版本改進

1六、請就軟件測試人員應該具有什麼樣的基本素質說說你的見解。

參考答案：

1七、你在五年內的我的目標和職業目標分別是什麼？

參考答案：

分析這個問題是用來了解你的計劃能力的，經過這個問題，面試人同時還能夠知道你的目標是否符合企業對你的安排。
　　錯誤回答我想在未來的某個時候考慮這個問題。現在企業的領導者更換頻繁，我認爲作太多的我的計劃是荒謬好笑的，不是嗎？
　　評論這種回答屬於使人反感的一類。首先，當有人想了解你的目標時，"未來的某個時候"這種通俗說法並不奏效。其次，認爲企業很脆弱，領導者更換頻繁，這種說法毫無疑問會使人反感，並且也是不合理的。最後，認爲作計劃好笑，看不起這個問題，並且反問面試人，這些都註定了這樣的求職者最終會失敗。
　　正確回答從如今起的五年以內，我但願可以在一個很好的職位上待幾年，並且最好有一次晉升，而後就期待着下一步。無論是向上提高，仍是在企業內橫向調動，對我我的來講，我但願找到一家企業——一家願意作相互投入的企業——待上一段時間。
　　評論這個問題沒有回答得過度具體（那樣可能會產生漏洞），並且它代表你有雄心，而且思考過在企業中的成長方式。經過表達橫向調動和向上提高的願望，代表你是一個有靈活性的人。

1八、你怎樣作出本身的職業選擇？

參考答案：

       分析 面試人提出這個問題是爲了瞭解求職者的動機，看看他（她）應聘這份工做是否有什麼歷史淵源，是否有職業規劃，是否是僅僅在漫無目的地申請不少工做。
　　錯誤回答 我一直都想在企業界工做。自孩提時代起，我就夢想本身至少也要成爲大企業的副總裁。
　　評論 除了難以使人相信以外，這種回答還存在一個問題：它代表求職者會對副總裁如下的職位不感興趣。
　　正確回答 在上大學四年級前的那個夏天，我決定集中精力在某一領域謀求發展。儘管我是學商業的，可是我不知道本身最終會從事哪一行業的工做。我花了必定的時間考慮本身的目標，想清楚了本身擅長作的事情以及想從工做中獲得的東西，最後我得出了一個堅決的結論，那就是這個行業是最適合個人。
　　評論 這種回答代表，求職者認真地作過一些計劃，縮小了本身的關注點，並且也認準了前進的方向。這種回答還代表，求職者理解我的職業規劃的重要性，而且有能力作出認真的我的決策。