軟件測試面試題+測試基礎(chǔ)知識

1、軟件測試面試題1、測試的定義軟件測試是軟件工程過程的一個重要階段，是在軟件升級發(fā)布之前對軟件開發(fā)各階段產(chǎn)品的最終檢查，是為了保證軟件開發(fā)產(chǎn)品的正確性、完全性和一致性而檢測軟件錯誤、修正軟件錯誤的過程。   軟件測試是：1) 程序測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程2) 測試是為了證明程序有錯，而不是證明程序無錯誤；3) 一個好的測試用例是在于它能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤；4) 一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試。軟件開發(fā)的目的：是開發(fā)出實現(xiàn)用戶需求的高質(zhì)量、高性能的軟件產(chǎn)品，而軟件測試是以檢查軟件功能和其他非功能特性為核心，是軟件質(zhì)量保證的關(guān)鍵，也是成功實現(xiàn)軟件開發(fā)目標(biāo)的重要保障

2、。2、測試的種類2.1從測試方法角度分為：2.1.1黑盒測試：是功能測試、數(shù)據(jù)驅(qū)動測試或基于規(guī)格說明的測試。在不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，測試者依據(jù)該程序功能上的輸入輸出關(guān)系，或是程序的外部特性來設(shè)計和選擇測試用例，推斷程序編碼的正確性。黑盒測試也稱功能測試，它是通過測試來檢測每個功能是否都能正常使用。在測試中，把程序看作一個不能打開的黑盒子，在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，在程序接口進(jìn)行測試，它只檢查程序功能是否按照需求規(guī)格說明書的規(guī)定正常使用，程序是否能適當(dāng)?shù)亟邮蛰斎霐?shù)據(jù)而產(chǎn)生正確的輸出信息。黑盒測試著眼于程序外部結(jié)構(gòu)，不考慮內(nèi)部邏輯結(jié)構(gòu)，主要針對軟件界面和軟件功能進(jìn)

3、行測試。1.等價類劃分 (1)劃分等價類。 如果某個輸入條件規(guī)定了取值范圍或值的個數(shù)。則可確定一個合理的等價類(輸入值或數(shù)在此范圍內(nèi))和兩個不合理等價類(輸入值或個數(shù)小于這個范圍的最小值或大于這個范圍的最大值)。 如果規(guī)定了輸入數(shù)據(jù)的一組值，而且程序?qū)Σ煌妮斎胫底霾煌奶幚?，則每個允許輸入值是一個合理等價類，此處還有一個不合理等價類(任何一個不允許的輸入值)。 如果規(guī)定了輸入數(shù)據(jù)必須遵循的規(guī)則，可確定一個合理等價類(符合規(guī)則)和若干個不合理等價類(從各種不同角度違反規(guī)則)。 如果已劃分的等價類中各元素在程序中的處理方式不同，則應(yīng)將此等價類進(jìn)一步劃分為更小的等價類。 (2)確定測試用例。 為每

4、一個等價類編號。 設(shè)計一個測試用例，使其盡可能多地覆蓋尚未被覆蓋過的合理等價類。重復(fù)這步，直到所有合理等價類被測試用例覆蓋。 設(shè)計一個測試用例，使其只覆蓋一個不合理等價類。 2.邊界值分析 使用邊界值分析方法設(shè)計測試用例時一般與等價類劃分結(jié)合起來。但它不是從一個等價類中任選一個例子作為代表，而是將測試邊界情況作為重點目標(biāo)，選取正好等于、剛剛大于或剛剛小于邊界值的測試數(shù)據(jù)。 (1)如果輸入條件規(guī)定了值的范圍，可以選擇正好等于邊界值的數(shù)據(jù)作為合理的測試用例，同時還要選擇剛好越過邊界值的數(shù)據(jù)作為不合理的測試用例。如輸入值的范圍是1，100，可取0，1，100，101等值作為測試數(shù)據(jù)。 (2)如果輸入

5、條件指出了輸入數(shù)據(jù)的個數(shù)，則按最大個數(shù)、最小個數(shù)、比最小個數(shù)少1、比最大個數(shù)多1等情況分別設(shè)計測試用例。如，一個輸入文件可包括1-255個記錄，則分別設(shè)計有1個記錄、255個記錄，以及0個記錄的輸入文件的測試用例。 (3)對每個輸出條件分別按照以上原則(1)或(2)確定輸出值的邊界情況。如，一個學(xué)生成績管理系統(tǒng)規(guī)定，只能查詢95-98級大學(xué)生的各科成績，可以設(shè)計測試用例，使得查詢范圍內(nèi)的某一屆或四屆學(xué)生的學(xué)生成績，還需設(shè)計查詢94級、99級學(xué)生成績的測試用例(不合理輸出等價類)。 由于輸出值的邊界不與輸入值的邊界相對應(yīng)，所以要檢查輸出值的邊界不一定可能，要產(chǎn)生超出輸出值之外的結(jié)果也不一定能做到

6、，但必要時還需試一試。 (4)如果程序的規(guī)格說明給出的輸入或輸出域是個有序集合(如順序文件、線形表、鏈表等)，則應(yīng)選取集合的第一個元素和最后一個元素作為測試用例。 3.錯誤推測法在測試程序時，人們可能根據(jù)經(jīng)驗或直覺推測程序中可能存在的各種錯誤，從而有針對性地編寫檢查這些錯誤的測試用例，這就是錯誤推測法。 4.因果圖法等價類劃分和邊界值方法分析方法都只是孤立地考慮各個輸入數(shù)據(jù)的測試功能，而沒有考慮多個輸入數(shù)據(jù)的組合引起的錯誤。 5.判斷表驅(qū)動法6正交試驗設(shè)計法7.功能圖法 2.1.2白盒測試：是結(jié)構(gòu)測試、邏輯驅(qū)動測試或基于程序的測試。測試者熟悉程序的內(nèi)部結(jié)構(gòu)，依據(jù)程序模塊的內(nèi)部結(jié)構(gòu)來設(shè)計測試用例

7、，檢測程序代碼的正確性白盒測試是結(jié)構(gòu)測試，所以被測對象基本上是源程序，以程序的內(nèi)部邏輯為基礎(chǔ)設(shè)計測試用例。 白盒測試方法：總體上分為 靜態(tài)方法和動態(tài)方法兩大類。靜態(tài)測試方法：不要求在計算機(jī)上實際執(zhí)行所測程序，主要以一些人工的模擬技術(shù)對軟件進(jìn)行分析和測試，關(guān)鍵功能是檢查軟件的表示和描述是否一致,沒有沖突或者沒有歧義。動態(tài)測試方法：是通過輸入一組預(yù)先按照一定的測試準(zhǔn)則構(gòu)造的實例數(shù)據(jù)來動態(tài)運(yùn)行程序，而達(dá)到發(fā)現(xiàn)程序錯誤的過程。動態(tài)測試方法分為以下幾種：1、邏輯覆蓋 程序內(nèi)部的邏輯覆蓋程度，當(dāng)程序中有循環(huán)時，覆蓋每條路徑是不可能的，要設(shè)計使覆蓋程度較高的或覆蓋最有代表性的路徑的測試用例。(1)語句覆蓋。

8、 為了個提高發(fā)現(xiàn)錯誤的可能性，在測試時應(yīng)該執(zhí)行到程序中的每一個語句。語句覆蓋是指設(shè)計足夠的測試用例，使被測試程序中每個語句至少執(zhí)行一次。 (2)判定覆蓋。 判定覆蓋指設(shè)計足夠的測試用例，使得被測程序中每個判定表達(dá)式至少獲得一次“真”值和“假”值，從而使程序的每一個分支至少都通過一次，因此判定覆蓋也稱分支覆蓋。 (3)條件覆蓋。 條件覆蓋是指設(shè)計足夠的測試用例，使得判定表達(dá)式中每個條件的各種可能的值至少出現(xiàn)一次。 (4)判定/條件測試。 該覆蓋標(biāo)準(zhǔn)指設(shè)計足夠的測試用例，使得判定表達(dá)式的每個條件的所有可能取值至少出現(xiàn)一次，并使每個判定表達(dá)式所有可能的結(jié)果也至少出現(xiàn)一次。 (5)條件組合覆蓋。 條件

9、組合覆蓋是比較強(qiáng)的覆蓋標(biāo)準(zhǔn)，它是指設(shè)計足夠的測試用例，使得每個判定表達(dá)式中條件的各種可能的值的組合都至少出現(xiàn)一次。 (6)路徑覆蓋。 路徑覆蓋是指設(shè)計足夠的測試用例，覆蓋被測程序中所有可能的路徑。 在實際的邏輯覆蓋測試中，一般以條件組合覆蓋為主設(shè)計測試用例，然后再補(bǔ)充部分用例，以達(dá)到路徑覆蓋測試標(biāo)準(zhǔn)。 2.循環(huán)覆蓋 3.基本路徑測試 其中運(yùn)用最為廣泛的是 基本路徑測試法。基本路徑測試法是在程序控制流圖的基礎(chǔ)上，通過分析控制構(gòu)造的環(huán)路復(fù)雜性，導(dǎo)出基本可執(zhí)行路徑集合，從而設(shè)計測試用例的方法。2.1.3灰盒測試：是介于白盒測試與黑盒測試之間的，可以這樣理解，灰盒測試關(guān)注輸出對于輸入的正確性，同時也關(guān)

10、注內(nèi)部表現(xiàn)，但這種關(guān)注不象白盒那樣詳細(xì)、完整，只是通過一些表征性的現(xiàn)象、事件、標(biāo)志來判斷內(nèi)部的運(yùn)行狀態(tài)，有時候輸出是正確的，但內(nèi)部其實已經(jīng)錯誤了，這種情況非常多，如果每次都通過白盒測試來操作，效率會很低，因此需要采取這樣的一種灰盒的方法。 2.2從測試發(fā)生的時間順序分為：2.2.1單元測試：是對軟件基本單元的測試單元測試（模塊測試）是：開發(fā)者編寫的一小段代碼，用于檢驗被測代碼的一個很小的、很明確的功能是否正確。通常而言，一個單元測試是用于判斷某個特定條件（或者場景）下某個特定函數(shù)的行為。單元測試是由程序員自己來完成，最終受益的也是程序員自己?？梢赃@么說，程序員有責(zé)任編寫功能代碼，同時

11、也就有責(zé)任為自己的代碼編寫單元測試。執(zhí)行單元測試，就是為了證明這段代碼的行為和我們期望的一致。單元測試的主要目的：是針對編碼過程中可能存在的各種錯誤，例如用戶輸入驗證過程中的邊界值的錯誤。2.2.2集成測試對由個模塊組裝而成的系統(tǒng)進(jìn)行測試，檢查各模塊間的接口和通信集成測試（也叫組裝測試，聯(lián)合測試）是單元測試的邏輯擴(kuò)展。它的最簡單的形式是：兩個已經(jīng)測試過的單元組合成一個組件，并且測試它們之間的接口。從這一層意義上講，組件是指多個單元的集成聚合。在現(xiàn)實方案中，許多單元組合成組件，而這些組件又聚合成程序的更大部分。方法是測試片段的組合，并最終擴(kuò)展進(jìn)程，將您的模塊與其他組的模塊一起測試。最后，將構(gòu)成進(jìn)

12、程的所有模塊一起測試。集成測試主要目的：是針對詳細(xì)設(shè)計中可能存在的問題，尤其是檢查各單元與其它程序部分之間的接口上可能存在的錯誤。 2.2.3系統(tǒng)測試系統(tǒng)測試是將經(jīng)過測試的子系統(tǒng)裝配成一個完整系統(tǒng)來測試。它是檢驗系統(tǒng)是否確實能提供系統(tǒng)方案說明書中指定功能的有效方法。（常見的聯(lián)調(diào)測試）系統(tǒng)測試的目的是對最終軟件系統(tǒng)進(jìn)行全面的測試，確保最終軟件系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設(shè)計。系統(tǒng)測試主要針對b概要設(shè)計/b，檢查了系統(tǒng)作為一個整體是否有效地得到運(yùn)行，例如在產(chǎn)品設(shè)置中是否達(dá)到了預(yù)期的高性能 2.2.4驗收測試驗證軟件的功能和性能及其它特性是否與用戶的要求一致。驗收測試是部署軟件之

13、前的最后一個測試操作。驗收測試的目的是確保軟件準(zhǔn)備就緒，并且可以讓最終用戶將其用于執(zhí)行軟件的既定功能和任務(wù)。驗收測試是向未來的用戶表明系統(tǒng)能夠像預(yù)定要求那樣工作。經(jīng)集成測試后，已經(jīng)按照設(shè)計把所有的模塊組裝成一個完整的軟件系統(tǒng)，接口錯誤也已經(jīng)基本排除了，接著就應(yīng)該進(jìn)一步驗證軟件的有效性，這就是驗收測試的任務(wù)，即軟件的功能和性能如同用戶所合理期待的那樣。驗收測試通常由業(yè)務(wù)專家或用戶進(jìn)行，以確認(rèn)產(chǎn)品能真正符合用戶業(yè)務(wù)上的需要(需求)。驗收測試分為非正式驗收測試和正式驗收測試兩大類。其中非正式驗收測試包括alpha測試和beta測試。  在MSF中，測試分為2大類：（其中MSF 是什么？）1

14、 覆蓋測試：找出程序中的缺陷，即是否該找的地方都找了。 2使用測試：找出程序中的失敗，即為什么使用不成功。覆蓋測試使用測試單元測試配置測試功能測試兼容性測試檢入測試強(qiáng)度測試構(gòu)造驗證測試性能測試回歸測試文檔和幫助文件測試 /測試3、測試的執(zhí)行過程     測試主要由下面6個相互關(guān)聯(lián)、相互作用的過程組成：3.1測試計劃    確定各測試階段的目標(biāo)和策略。這個過程將輸出測試計劃，明確要完成的測試活動，評估完成活動所需要的時間和資源，設(shè)計測試組織和崗位職權(quán)，進(jìn)行活動安排和資源分配，安排跟蹤和控制測試過程的活動。3.2測試設(shè)計根據(jù)測試

15、計劃設(shè)計測試方案。測試設(shè)計過程輸出的是各測試階段使用的測試用例。測試設(shè)計也與軟件開發(fā)活動同步進(jìn)行，其結(jié)果可以作為各階段測試計劃的附件提交評審。測試設(shè)計的另一項內(nèi)容是回歸測試設(shè)計，即確定回歸測試的用例集。對于測試用例的修訂部分，也要求進(jìn)行重新評審。測試用例（Test Case）是為某個特殊目標(biāo)而編制的一組測試輸入、執(zhí)行條件以及預(yù)期結(jié)果，以便測試某個程序路徑或核實是否滿足某個特定需求。指對一項特定的軟件產(chǎn)品進(jìn)行測試任務(wù)的描述，體現(xiàn)測試方案、方法、技術(shù)和策略。內(nèi)容包括測試目標(biāo)、測試環(huán)境、輸入數(shù)據(jù)、測試步驟、預(yù)期結(jié)果、測試腳本等，并形成文檔。測試用例構(gòu)成了設(shè)計和制定測試過程的基礎(chǔ)。編制測試用例的具體做

16、法：1) 測試用例文檔2) 測試用例的設(shè)置3) 設(shè)計測試用例測試用例在軟件測試中的作用：1) 指導(dǎo)測試的實施。測試用例主要適用于集成測試、系統(tǒng)測試和回歸測試。2) 規(guī)劃測試數(shù)據(jù)的準(zhǔn)備3) 編寫測試腳本的"設(shè)計規(guī)格說明書"4) 評估測試結(jié)果的度量基準(zhǔn)。完成測試實施后需要對測試結(jié)果進(jìn)行評估，并且編制測試報告。判斷軟件測試是否完成、衡量測試質(zhì)量需要一些量化的結(jié)果。例：測試覆蓋率是多少、測試合格率是多少、重要測試合格率是多少，等等。5) 分析缺陷的標(biāo)準(zhǔn)3.3測試實施    使用測試用例運(yùn)行程序，將獲得的運(yùn)行結(jié)果與預(yù)期結(jié)果進(jìn)行比較和分析，記錄、跟蹤和管理

17、軟件缺陷，最終得到測試報告3.4測試配置管理    測試配置管理是軟件配置管理的子集，作用于測試的各個階段。其管理對象包括測試計劃、測試方案（用例）、測試版本、測試工具及環(huán)境、測試結(jié)果等。一般會得到一個基線測試用例庫。3.5資源管理    包括對人力資源和工作場所，以及相關(guān)設(shè)施和技術(shù)支持的管理。如果建立了測試實驗室，還存在其他的管理問題。3.6測試管理采用適宜的方法對上述過程及結(jié)果進(jìn)行監(jiān)視，并在適用時進(jìn)行測量，以保證上述過程的有效性。如果沒有實現(xiàn)預(yù)定的結(jié)果，則應(yīng)進(jìn)行適當(dāng)?shù)恼{(diào)整或糾正。4、幾種測試類型的介紹 4.1單元測試4.1.1定義

18、     單元測試是對最小的可測試軟件元素（單元）實施的測試，它所測試的內(nèi)容包括內(nèi)部結(jié)構(gòu)（如邏輯和數(shù)據(jù)流）以及單元的功能和可觀測的行為。側(cè)重于單元內(nèi)部結(jié)構(gòu)的測試設(shè)計和實施依賴于對單元實施情況的了解（白盒方法）。為核實單元的可觀測行為和功能而進(jìn)行的測試設(shè)計和實施并不依賴于對實施情況的了解，因而被稱為黑盒方法。    單元測試是一種非常高效的測試方法，并且是軟件測試周期中第一個進(jìn)行的測試。加強(qiáng)單元測試力度有利于降低缺陷定位和修復(fù)難度，從而降低缺陷解決成本，同時加強(qiáng)單元測試也減輕了后續(xù)集成測試和系統(tǒng)測試的負(fù)擔(dān)。單元測試一般是由開發(fā)工程師執(zhí)行的。4.1

19、.2方法    單元測試一般要做以下三項工作        a.設(shè)計測試用例        b.編寫測試代碼        c.執(zhí)行待測程序    其中測試用例的設(shè)計是很重要的一步，好的測試用例的原則是：        a.能夠發(fā)現(xiàn)至今沒有

20、發(fā)現(xiàn)的錯誤        b.測試用例應(yīng)由測試輸入數(shù)據(jù)和與之對應(yīng)的預(yù)期輸出結(jié)果這兩部分組成        c.應(yīng)當(dāng)包含合理的輸入條件和不合理的輸入條件。    可以依照以下方法來設(shè)計測試用例：       1、程序中每一條可執(zhí)行語句至少被執(zhí)行一次。      2、程序中每一個分支判斷的每一種可能結(jié)果(主要指s

21、witch-case情況)都至少被執(zhí)行一次。       3、程序中每一個分支判斷中的每一個條件的可能結(jié)果都至少被執(zhí)行一次。       4、程序中每一個分支判斷中的每一個條件的每一種可能組合結(jié)果都至少被執(zhí)行一次。       5、程序中所有的可能路徑都至少被執(zhí)行一次。4.1.3常用的工具 常用的單元測試工具有 NUnit 和 NUnitAsp 。4.2回歸測試 4.2.1定義  回歸測試是指根據(jù)修復(fù)好了的

22、缺陷再重新進(jìn)行的測試。     回歸測試作為軟件生命周期的一個組成部分，在整個軟件測試過程中占有很大的工作量比重，軟件開發(fā)的各個階段都會進(jìn)行多次回歸測試。    回歸測試的目的在于驗證以前出現(xiàn)過但已經(jīng)修復(fù)好的缺陷不再重新出現(xiàn)。一般指對某已知修正的缺陷再次圍繞它原來出現(xiàn)時的步驟重新測試。   當(dāng)軟件中所含錯誤被發(fā)現(xiàn)時，如果錯誤跟蹤與管理系統(tǒng)不夠完善，就可能會遺漏對這些錯誤的修改；而開發(fā)者對錯誤理解的不夠透徹，也可能導(dǎo)致所做的修改只修正了錯誤的外在表現(xiàn)，而沒有修復(fù)錯誤本身，從而造成修改失敗；修改還有可能產(chǎn)生副作用從而導(dǎo)

23、致軟件未被修改的部分產(chǎn)生新的問題，使本來工作正常的功能產(chǎn)生錯誤。同樣，在有新代碼加入軟件的時候，除了新加入的代碼中有可能含有錯誤外，新代碼還有可能對原有的代碼帶來影響。因此，每當(dāng)軟件發(fā)生變化時，我們就必須重新測試現(xiàn)有的功能，以便確定修改是否達(dá)到了預(yù)期的目的，檢查修改是否損害了原有的正常功能。    回歸測試一般是由測試工程師執(zhí)行的。4.2.2方法     一般進(jìn)行回歸測試的步驟如下：         1.建立測試基線,這是回歸測試的前提。具體方式是將所有的

24、測試用例放到配置庫中，打上版本標(biāo)記。        2.從基線測試用例庫中提取合適的測試用例組成回歸測試包，必要時進(jìn)行開發(fā)和重新設(shè)計整理。        3.在后續(xù)開發(fā)過程中，每次測試之前先運(yùn)行回歸測試包。保存在基線測試用例庫中的測試用例可能是自動測試腳本，也有可能是測試用例的手工實現(xiàn)過程。4.2.3常用的工具 在實際工作中，回歸測試需要反復(fù)進(jìn)行，當(dāng)測試者一次又一次地完成相同的測試時，這些回歸測試將變得非常令人厭煩，為了提高回歸測試的效率，我們可以使用些自

25、動化回歸測試工具。常用的工具有WinRunner等，具體的用法見相關(guān)的文檔。4.3性能測試 4.3.1目的     性能測試的目的是驗證軟件系統(tǒng)是否能夠達(dá)到用戶提出的性能指標(biāo)，同時發(fā)現(xiàn)軟件系統(tǒng)中存在的性能瓶頸，優(yōu)化軟件，最后起到優(yōu)化系統(tǒng)的目的。    包括以下幾個方面：    一評估系統(tǒng)的能力，測試中得到的負(fù)荷和響應(yīng)時間數(shù)據(jù)可以被用于驗證所計劃的模型的能力，并幫助作出決策。    二識別體系中的弱點：受控的負(fù)荷可以被增加到一個極端的水平，并突破它，從而修復(fù)體系的瓶頸或薄弱的環(huán)

26、節(jié)。    三系統(tǒng)調(diào)優(yōu)：重復(fù)運(yùn)行測試，驗證調(diào)整系統(tǒng)的活動得到了預(yù)期的結(jié)果，從而改進(jìn)性能。檢測軟件中的問題：長時間的測試執(zhí)行可導(dǎo)致程序發(fā)生由于內(nèi)存泄露引起的失敗，揭示程序中的隱含的問題或沖突。    四驗證穩(wěn)定性（resilience）可靠性（reliability）：在一個生產(chǎn)負(fù)荷下執(zhí)行測試一定的時間是評估系統(tǒng)穩(wěn)定性和可靠性是否滿足要求的唯一方法。4.3.2定義 性能測試是通過自動化的測試工具模擬多種正常、峰值以及異常負(fù)載條件來對系統(tǒng)的各項性能指標(biāo)進(jìn)行測試性能測試主要測試軟件的性能，包括負(fù)載測試，強(qiáng)度測試，數(shù)據(jù)庫容量測試，基準(zhǔn)測試以及

27、競爭測試。    負(fù)載測試：負(fù)載測試是一種性能測試,指當(dāng)數(shù)據(jù)在超負(fù)荷環(huán)境中運(yùn)行時程序是否能夠承擔(dān)。在這種測試中，將使測試對象承擔(dān)不同的工作量，以評測和評估測試對象在不同工作量條件下的性能行為，以及持續(xù)正常運(yùn)行的能力。負(fù)載測試的目標(biāo)是確定并確保系統(tǒng)在超出最大預(yù)期工作量的情況下仍能正常運(yùn)行。此外，負(fù)載測試還要評估性能特征，例如，響應(yīng)時間、事務(wù)處理速率和其他與時間相關(guān)的方面。    強(qiáng)度測試：強(qiáng)度測試是一種性能測試，它在系統(tǒng)資源特別低的情況下測試軟件系統(tǒng)運(yùn)行情況。實施和執(zhí)行此類測試的目的是找出因資源不足或資源爭用而導(dǎo)致的錯誤。如果內(nèi)存或磁盤

28、空間不足，測試對象就可能會表現(xiàn)出一些在正常條件下并不明顯的缺陷。而其他缺陷則可能由于爭用共享資源（如數(shù)據(jù)庫鎖或網(wǎng)絡(luò)帶寬）而造成的。強(qiáng)度測試還可用于確定測試對象能夠處理的最大工作量。    數(shù)據(jù)庫容量測試：數(shù)據(jù)庫容量測試指通過存儲過程往數(shù)據(jù)庫表中插入一定數(shù)量的數(shù)據(jù)，看看相關(guān)頁面是否能夠及時顯示數(shù)據(jù)。數(shù)據(jù)庫容量測試使測試對象處理大量的數(shù)據(jù)，以確定是否達(dá)到了將使軟件發(fā)生故障的極限。容量測試還將確定測試對象在給定時間內(nèi)能夠持續(xù)處理的最大負(fù)載或工作量。    基準(zhǔn)測試：基準(zhǔn)測試是一種與已知現(xiàn)有的系統(tǒng)進(jìn)行比較，主要檢驗是否與類似的產(chǎn)品具有競爭性的

29、一種測試。    競爭測試：軟件競爭使用各種資源（數(shù)據(jù)紀(jì)錄，內(nèi)存等），看他與其他相關(guān)系統(tǒng)對資源的爭奪能力。比如：一臺機(jī)器上既安裝您的財務(wù)系統(tǒng)，又安裝用友財務(wù)系統(tǒng)。當(dāng)CPU占有率下降后，看看是否能夠強(qiáng)過用友財務(wù)系統(tǒng)，而是自己的系統(tǒng)能夠正常運(yùn)行？4.3.3 方法     做性能測試一般可以通過一些三方的工具來實現(xiàn)4.3.3常用的工具     性能測試一般都是通過工具來完成的，常用的工具有 Microsoft Application Center Test(ACT)。5、測試計劃的制定 5.1、制定的階段 &#

30、160;   測試計劃是與軟件開發(fā)活動同步進(jìn)行的。 在MSF的構(gòu)想(Envisioning)階段,要制定測試策略和測試的驗收標(biāo)準(zhǔn)。在計劃(Planning)階段),要完成和評審測試計劃及所用到的資源。在開發(fā)(Developing)階段,要完成和評審單元測試計劃。對于測試計劃的修訂部分，需要進(jìn)行重新評審。 5.2、制定過程中要考慮的因素 1.應(yīng)明確的在測試計劃中確立好測試管理機(jī)制的關(guān)鍵事件,如。    a.匯報機(jī)制。確定好用周報制度還是日報制度，日報的反饋速度越快，定位解決問題越快，但信息處理工作量大。    b.例

31、會制度。每周舉行一次例會，根據(jù)實際情況，考慮測試計劃的調(diào)整或滾動。    c.實施怎樣的實驗室管理制度，以做到責(zé)任明確。    d.在日報中的工作匯報。不僅要包括發(fā)現(xiàn)的問題，還應(yīng)包括在測試時新創(chuàng)造的測試點，這些測試點應(yīng)該補(bǔ)充到測試計劃中作為一個測試項；e.人員情緒如何調(diào)整。在測試周期過長時，影響測試效率的一個重要因素是測試人員的情緒，一個人反復(fù)測試一個模塊，總是會出現(xiàn)厭倦情緒的。2.應(yīng)明確的在測試計劃中確立數(shù)據(jù)的管理和分析體系的辦法,如：專人對提交的過程文檔,周報報告中的數(shù)據(jù)予以整理和管理，以便后期在系統(tǒng)測試評審時作為數(shù)據(jù)來

32、分析。現(xiàn)在往往是在系統(tǒng)測試結(jié)束后才來收集數(shù)據(jù)，可能會造成數(shù)據(jù)的不同程度失真或滯后。收集的數(shù)據(jù)可以按不同種類來劃分。這可以依賴我們系統(tǒng)的CHECKLIST。有一種工具叫 SRES (軟件可靠性專家系統(tǒng)) 是很有用的，我們可以按照它的輸入數(shù)據(jù)來收集。3.應(yīng)明確的在測試計劃中確立風(fēng)險估計的引入,如：    制定測試計劃時,就應(yīng)該考慮好對系統(tǒng)測試工作量的估計，測試成本的估計,版本市場定位的估計等等,并且必要時可根據(jù)實際情況進(jìn)行裁剪或補(bǔ)充。5.3、計劃的內(nèi)容  1.概述 2.測試的目的 3.測試方案和假設(shè) 4.主要測試職責(zé)：參與測試過

33、程的人 5.測試的特征和功能：要測試的功能和特殊 6.測試期望的結(jié)果 7.交付物：實施測試要用材料（文檔和數(shù)據(jù)） 8.測試的規(guī)程和評審方法:為了確保測試的質(zhì)量需要經(jīng)過的測試步驟 9.跟蹤和狀態(tài)報告：定義在測試過程中，測試小組成員溝通的方式 10.測試資源需求：測試要用到的資源（人，軟件工具，硬件環(huán)境） 11.Bug報告工具和方法：描述如何記錄測試過程中發(fā)現(xiàn)的BUG 12.進(jìn)度表：描述測試的周期，任務(wù)，里程碑和交付物 13.風(fēng)險和依賴：描述測試的假設(shè)，風(fēng)險和依賴性6、負(fù)載測試，容量測試，強(qiáng)度測試和兼容測試的

34、區(qū)別負(fù)載測試：在一定的工作負(fù)荷下，系統(tǒng)的負(fù)荷及響應(yīng)時間。強(qiáng)度測試：在一定的負(fù)荷條件下，在較長時間跨度內(nèi)的系統(tǒng)連續(xù)運(yùn)行給系統(tǒng)性能所造成的影響。容量測試：容量測試目的是通過測試預(yù)先分 析出反映軟件 系統(tǒng)應(yīng)用特征的某項指標(biāo)的極限值（如最大并發(fā)用戶數(shù)、數(shù)據(jù)庫記錄數(shù)等），系統(tǒng)在其極限值狀  態(tài)下沒有出現(xiàn)任何軟件故障或還能保持主要功能正常運(yùn)行。容量測試 還將確定測試對象在給定時間內(nèi)能夠持續(xù)處理的最大負(fù)載或工作量。容量測試的目的是使系統(tǒng)承受超額的數(shù)據(jù)容量來發(fā)現(xiàn)它是否能夠正確處理。容量測試是面向數(shù)據(jù)的，并且它的目的是顯示系統(tǒng)可以處理目標(biāo)內(nèi)確定的數(shù)據(jù)容量。兼容測試：主要是檢查軟件在不同的硬件

35、平臺、軟件平臺上是否可以正常的運(yùn)行，即是通常說的軟件的可移植性。兼容的類型，如果細(xì)分的話，有平臺的兼容，網(wǎng)絡(luò)兼容，數(shù)據(jù)庫兼容，以及數(shù)據(jù)格式的兼容。兼容測試的重點是，對兼容環(huán)境的分析。通常，是在運(yùn)行軟件的環(huán)境不是很確定的情況下，才需要做兼容。根據(jù)軟件運(yùn)行的需要，或者根據(jù)需求文檔，一般都能夠得出用戶會在什么環(huán)境下使用該軟件，把這些環(huán)境整理成表單，就得出做兼容測試的兼容環(huán)境了。兼容和配置測試的區(qū)別在于，做配置測試通常不是Clean OS下做測試，而兼容測試多是在Clean OS的環(huán)境下做的。7、alpha測試、beta測試 和gamma測試 測試有三個傳統(tǒng)的稱呼，alpha、beta、gamma，用

36、來標(biāo)識測試的階段和范圍。alpha 是指內(nèi)測，即現(xiàn)在說的 CB，指開發(fā)團(tuán)隊內(nèi)部測試的版本或者有限用戶體驗測試版本。beta 是指公測，即針對所有用戶公開的測試版本。然后做過一些修改，成為正式發(fā)布的候選版本時（現(xiàn)在叫做 RC - Release Candidate），叫做 gamma。7.1 Alpha測試Alpha 測試是由一個用戶在開發(fā)者的場所來進(jìn)行的，軟件在開發(fā)者對用戶的“指導(dǎo)”下進(jìn)行測試，開發(fā)者負(fù)責(zé)記錄錯誤和使用中出現(xiàn)的問題，Alpha測試是在一個受控的環(huán)境中進(jìn)行的。Alpha測試是由一個用戶在開發(fā)環(huán)境下進(jìn)行的測試，也可以是公司內(nèi)部用戶在模擬實際操作環(huán)境進(jìn)行的受控測試，Alpha測試不能

37、由程序員或測試員完成。Alpha測試發(fā)現(xiàn)的錯誤，可以在測試現(xiàn)場立刻反饋給開發(fā)人員，由開發(fā)人員進(jìn)行分析和處理。目的是評論軟件產(chǎn)品的功能、可使用性、可靠性、性能和支持。尤其注重產(chǎn)品的界面和特色。Alpha可以從軟件產(chǎn)品編碼結(jié)束之后開始，或在模塊（子系統(tǒng)）測試完成之后開始，也可以在確認(rèn)測試過程中產(chǎn)品達(dá)到一定的可靠和穩(wěn)定性之后開始，有關(guān)的手冊（草稿）應(yīng)該在Alpha測試之前準(zhǔn)備好。Alpha測試的關(guān)鍵在于盡可能逼真地模擬實際運(yùn)行環(huán)境和用戶對軟件產(chǎn)品的操作并盡最大努力涵蓋所有可能的用戶操作方式。7.2 Beta測試經(jīng)過測試調(diào)整的軟件產(chǎn)品稱為版本。緊隨其后的測試是指軟件開發(fā)公司組織各方面的典型用戶在日常工

38、作中實際使用版本，并要求用戶報告異常情況、提出批評意見。然后軟件開發(fā)公司再對版本進(jìn)行改錯和完善。 一般包括功能度、安全可靠性、易用性、可擴(kuò)充性、兼容性、效率、資源占用率、用戶文檔八個方面。 Beta測試是由軟件的多個用戶在一個或多個實際使用環(huán)境下進(jìn)行的測試，開發(fā)者通常不在現(xiàn)場，Beta測試不能由程序員和測試員完成。因此，Beta測試是在開發(fā)者無法控制的環(huán)境下進(jìn)行的軟件現(xiàn)場應(yīng)用。在Beta測試中，由用戶記下遇到的問題，包括真實的和主管確認(rèn)的，定期向開發(fā)者報告，開發(fā)者在綜合用戶的報告后，做出修改，最后將軟件產(chǎn)品交付給全體用戶使用。Beat測試注重于產(chǎn)品的支持性，包括文檔、客戶培訓(xùn)和支持產(chǎn)品的生產(chǎn)能

39、力，只有當(dāng)Alpha測試達(dá)到一定的可靠程序后才能進(jìn)行Beta測試。由于Beta測試的主要目標(biāo)是測試產(chǎn)品的可支持性，所以beta測試應(yīng)盡可能由主持產(chǎn)品發(fā)行的人員來管理。我們認(rèn)為Beta測試就是由一部分受控制的客戶進(jìn)行的黑盒測試。由于Alpha測試和Beta測試的組織難度大，測試費(fèi)用高，測試的隨機(jī)性強(qiáng)，測試周期跨度較長，測試質(zhì)量和效率難于保證，所以，很多專業(yè)軟件可能不進(jìn)行Beta測試，隨著測試技術(shù)的提高，以及專業(yè)測試服務(wù)機(jī)構(gòu)的大量涌現(xiàn)，很多軟件的Beta測試外包給測試機(jī)構(gòu)進(jìn)行測試。區(qū)別：Alpha測試是:由用戶或開發(fā)人員在開發(fā)環(huán)境下進(jìn)行的測試.Beta測試是:在實際應(yīng)用環(huán)境中進(jìn)行的測試,通常由用戶

40、來完成,開發(fā)人員不在現(xiàn)場.兩種測試最根本的區(qū)別是在于測試環(huán)境.7.3 Gamma測試Gamma測試是一個很少被提及的非正式測試階段，該測試階段對應(yīng)的是對“存在缺陷”產(chǎn)品的測試?？紤]到任何產(chǎn)品都可以被稱為“存在缺陷”的產(chǎn)品（測試只能發(fā)現(xiàn)產(chǎn)品中存在的問題，不能說明產(chǎn)品不存在問題），因此這個概念存在一定不確定。8、測試結(jié)束的標(biāo)準(zhǔn)是什么  用例全部測試。  覆蓋率達(dá)到標(biāo)準(zhǔn)。  缺陷率達(dá)到標(biāo)準(zhǔn)。  其他指標(biāo)達(dá)到質(zhì)量標(biāo)準(zhǔn)9、描述軟件測試活動的生命周期 測試周期分為計劃、設(shè)計、實現(xiàn)、執(zhí)行、總結(jié)。計劃：對整個測試周期中所有活動進(jìn)行規(guī)劃，估計工作量、風(fēng)險，安排人力物力資源

41、，安排進(jìn)度等；設(shè)計：完成測試方案，從技術(shù)層面上對測試進(jìn)行規(guī)劃；實現(xiàn)：進(jìn)行測試用例和測試規(guī)程設(shè)計；執(zhí)行：根據(jù)前期完成的計劃、方案、用例、規(guī)程等文檔，執(zhí)行測試用例。總結(jié)：記錄測試結(jié)果，進(jìn)行測試分析，完成測試報告。10、軟件的缺陷等級應(yīng)如何劃分？A類嚴(yán)重錯誤：1 由于程序所引起的死機(jī),非法退出 2 死循環(huán) 3 數(shù)據(jù)庫發(fā)生死鎖 4 因錯誤操作導(dǎo)致的程序中斷 5 功能錯誤 6 與數(shù)據(jù)庫連接錯誤 7 數(shù)據(jù)通訊錯誤B類較嚴(yán)重錯誤：1 程序錯誤 2 程序接口錯誤 3 數(shù)據(jù)庫的表、業(yè)務(wù)規(guī)則、缺省值未加完整性等約束條件 C類一般性錯誤，1 操作界面錯誤（包括數(shù)據(jù)窗口內(nèi)列名定義、含義是否一致） 2 打印內(nèi)

42、容、格式錯誤 3 簡單的輸入限制未放在前臺進(jìn)行控制 4 刪除操作未給出提示 5 數(shù)據(jù)庫表中有過多的空字段 D類較小錯誤，1 界面不規(guī)范 2 輔助說明描述不清楚 3 輸入輸出不規(guī)范 4 長操作未給用戶提示 5 提示窗口文字未采用行業(yè)術(shù)語 6、可輸入?yún)^(qū)域和只讀區(qū)域沒有明顯的區(qū)分標(biāo)志11、當(dāng)開發(fā)人員說不是BUG時,你如何應(yīng)付？  開發(fā)人員說不是bug，有2種情況，一是需求沒有確定，所以我可以這么做，這個時候可以找來產(chǎn)品經(jīng)理進(jìn)行確認(rèn)，需不需要改動，3方商量確定好后再看要 不要改。二是這種情況不可能發(fā)生，所以不需要修改，這個時候，我可以先盡可能的說出是BUG的依據(jù)是什么？如

43、果被用戶發(fā)現(xiàn)或出了問題，會有什么不良結(jié)果？ 程序員可能會給你很多理由，你可以對他的解釋進(jìn)行反駁。如果還是不行，那我可以給這個問題提出來,跟開發(fā)經(jīng)理和測試經(jīng)理進(jìn)行確認(rèn),如果要修改就改,如果不 要修改就不改。其實有些真的不是bug，我也只是建議的方式寫進(jìn)TD中，如果開發(fā)人員不修改也沒有大問題。如果確定是bug的話，一定要堅持自己的立場， 讓問題得到最后的確認(rèn)（ 首先你要正確理解出錯誤是bug，還是軟件缺陷，如果是軟件缺陷的話，最好直接找你的部門經(jīng)理，然后由部門經(jīng)理與開發(fā)部經(jīng)理協(xié)調(diào)。如果是bug，你應(yīng)當(dāng)理清bug出現(xiàn)的原因，然后整理成報告給相應(yīng)的開發(fā)人員，如果此人員不改正的情況下，交給部門經(jīng)理負(fù)責(zé)。

44、）12.為什么一個團(tuán)隊中要開展軟件測試工作？ 答：軟件測試在整個團(tuán)隊中占有非常重要的地位，具體來說就是測試是一個發(fā)現(xiàn)軟件錯誤的過程，執(zhí)行軟件測試會以最少的人力和時間，系統(tǒng)要找到軟件存在的缺陷和錯誤，建立起開發(fā)人員和使用者對軟件的信息。13.您是否了解以往所工作的企業(yè)的軟件測試過程？如果了解，請敘述在這個過程中都有哪些工作要做？分別有哪些不同的角色來完成這些工作？答：軟件測試人員負(fù)責(zé)軟件開發(fā)部門的新產(chǎn)品的升級測試，負(fù)責(zé)軟件問題解決過程跟蹤，負(fù)責(zé)人軟件開發(fā)文檔開發(fā)工作的規(guī)范化及管理開發(fā)部門的產(chǎn)品文檔，制作用戶手冊及操作手冊，負(fù)責(zé)產(chǎn)品的上線測試，監(jiān)督軟件開發(fā)過程的執(zhí)行，提高產(chǎn)品質(zhì)量。14.您是否了解以往開發(fā)所工作的企業(yè)的開發(fā)過程？如果了解，請敘述一個完整的開發(fā)過程需要完成那些工作？分別有哪些不同的角色來完成這些工作？(對于軟件測試部分，可以簡述) 答：需求人員連同系統(tǒng)分析人員、測試人員開會討論需求。系統(tǒng)分析人員寫出需求分析說明書，并連同系統(tǒng)分析人員、測試人員、需求人員開會討論可行性。系統(tǒng)分析人員寫出詳細(xì)設(shè)計說明書，程式人員編碼，給出系統(tǒng)流程圖，交與測試人員，測試人員給出Bug統(tǒng)計