“軟件測試”基礎,要點概念總結(一步到位)

注意,如果是準備“計算機三級軟件測試”的同學,應該多看看面向對象測試流程圖等方面的知識。

軟件測試
  爲了發現程序中的錯誤而執行程序的過程

描述軟件測試活動的生命週期
  計劃、設計、實現、執行、總結

軟件缺陷等級劃分
  A類,嚴重錯誤
  B類,較嚴重錯誤
  C類,一般性錯誤
  D類,較小錯誤
  E類,測試建議

黑盒測試
  又稱爲功能測試或者數據驅動測試,不考慮程序內部結構和內部特性的情況下,測試者在程序結構進行測試。
  它只檢查程序功能是否按照需求規格說明書的規定正常使用,程序是否能適當地接收輸入數據而產生正確的輸出信息,並且保持外部信息

白盒測試
  又稱爲結構測試或邏輯驅動測試,它是知道產品內部工作過程,可通過測試來檢測產品內部動作是否按照規則說明書的規定正常進行。
  按照程序內部的結構測試程序,檢驗程序中的每條通路是否都有能按預定要求正確工作,而不顧它的功能

靜態測試
  靜態方法是指不運行被測程序本身,僅通過分析或檢查源程序的語法、結構、過程、接口等來檢查程序的正確性。
  對需求規格說明書、軟件設計說明書、源程序做結構分析、流程圖分析、符號執行來找錯。

動態測試
  動態測試方法是指通過運行被測程序,檢查運行結果與預期結果的差異,並分析運行效率、正確性和健壯性等性能。
  這種方法由三部分組成:
    構造測試用例、
    執行程序、
    分析程序的輸出結果

自動化測試
  一般是指軟件測試的自動化,軟件測試就是在預設條件下運行系統或應用程序,評估運行結果,預先條件應包括正常條件和異常條件。

黑盒測試方法有
  等價類劃分法、
  邊界值分析法、
  因果圖法、
  錯誤推斷法、
  綜合策略、
  正交分析法,

白盒測試有哪幾種方法
  總體上分爲靜態方法和動態方法
  靜態方法:
    關鍵功能是檢查軟件的表示和描述是否一致,沒有衝突或者沒有歧義
  動態方法:
    邏輯覆蓋法(語句覆蓋、判斷覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋、路徑覆蓋)
    循環覆蓋、
    基本路徑測試、

動態測試的兩個基本要素是
  被測試程序、被測試數據(測試用例)

開發模式包括
  大棒模型、
  邊做邊改模型、
  瀑布模型、
  螺旋模型、
  敏捷軟件開發、
  噴泉模型
  演化模型、
  迭代模型、
  快速原型模型、
  增量模型、

不需要修復軟件缺陷的原因包括
  沒有時間、
  不能算真正的軟件缺陷、
  風險太大、
  不值得修復、

軟件缺陷
  常常又被叫做Bug。
  所謂軟件缺陷,即爲計算機軟件或程序中存在的某種破壞正常運行能力的問題、錯誤,或者隱藏的功能缺陷。缺陷的存在會導致軟件產品在某種程度上不能滿足用戶的需要。
  IEEE729-1983對缺陷有一個標準的定義:從產品內部看,缺陷是軟件產品開發或維護過程中存在的錯誤、毛病等各種問題;從產品外部看,缺陷是系統所需要實現的某種功能的失效或違背。

alpha測試
  alpha測試是由一個用戶在開發環境下進行的測試,也可以是公司內部的用戶在模擬實際操作環境下進行的測試。α測試的目的是評價軟件產品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。尤其注重產品的界面和特色。
  alpha測試可以從軟件產品編碼結束之時開始,或在模塊(子系統)測試完成之後開始,也可以在確認測試過程中產品達到一定的穩定和可靠程度之後再開始。α測試即爲非正式驗收測試。

beta測試
  Beta測試是一種驗收測試。所謂驗收測試是軟件產品完成了功能測試和系統測試之後,在產品發佈之前所進行的軟件測試活動,它是技術測試的最後一個階段,通過了驗收測試,產品就會進入發佈階段。

alpha測試與beta測試區別
  Alpha測試在系統開發接近完成時對應用系統的測試,測試後仍然會有少量的設計變更。這種測試一般由最終用戶或其他人員完成,不能由程序員或測試員完成。
  Beta測試當開發和測試根本完成時所做的測試,最終錯誤和問題需要在最終發行前找到。這種測試一般由最終用戶或其他人員完成,不能由程序員或者測試員完成。

測試用例(測試時執行的最小實體)
  測試用例(TestCase)是爲某個特殊目標而編制的一組測試輸入、執行條件以及預期結果,以便測試某個程序路徑或覈實是否滿足某個特定需求。

等價類劃分概念
  等價類劃分就是解決如何選擇適當的數據子集來代表整個數據集的問題,通過降低測試的數目去實現“合理的”覆蓋,覆蓋了更多的可能數據,以發現更多的軟件缺陷。

如何劃分等價類
  1).在輸入條件規定了取值範圍或值的個數的情況下,則可以確立一個有效等價類和兩個無效等價類。
  2).在輸入條件規定了輸入值的集合或者規定了“必須如何”的條件的情況下,則可以確立一個有效等價類和一個無效等價類。
  3).在輸入條件是一個布爾量的情況下,可以確立一個有效等價類和一個無效等價類。
  4).在規定了輸入數據的一組值(假定n個),並且程序要對每一個輸入值分別處理的情況下,可以確立n個有效等價類和一個無效等價類。
  5).在規定了輸入數據必須遵守的規則的情況下,可以確立一個有效等價類(符合規則)和若干個無效等價類(從不同角度違反規則)。
  6).在確知已劃分的等價類中各元素在程序處理中的方式不同的情況下,則應再將該等價類進一步的劃分爲更小的等價類。

劃分等價類的方法
  按區間劃分
  按數值劃分
  按數值集合劃分
  按限制條件劃分
  按限制規則劃分
  按處理方式劃分

軟件驗收測試包括:
  正式驗收測試
  aphla測試
  beta測試

軟件驗收測試應完成哪些主要測試工作
  1)文檔資料的審查驗收
  2)功能測試
  3)性能測試
  4)強化測試
  5)性能降級執行方式測試
  6)檢查系統的餘量要求
  7)安裝測試
  8)用戶操作

餘量的概念(兩方面):
  一.進行操作後某種相關資源的剩餘數量;
  二.常用於加工製造業或工業工程應用,多指加工或操作過程中預留的一部分附加資源空間,比如加工材料的餘量、器具運動軌跡的餘量等等。
  可以說,餘量的存在有效的提升了工程應用執行過程的容錯能力,對於確保應用正常實施極爲重要。因此,爲了確保系統能夠正常運作,往往會在計劃階段將餘量因素納入考慮範圍。

階段評審與同行評審的區別
  同行評審目的:發現小規模工作產品的錯誤,主要是找錯誤;
  階段評審目的:評審模塊 階段作品的正確性 可行性 及完整性
  同行評審人數:3-7人,人員必須經過同行評審會議的培訓,由SQA指導
  階段評審人數:5人左右 評審人必須是專家 具有系統評審資格
  同行評審內容:內容小 一般文檔 < 40頁, 代碼 < 500行
  階段評審內容: 內容多,主要看重點
  同行評審時間:一小部分工作產品完成
  階段評審時間: 通常是設置在關鍵路徑的時間點上

設計系統測試計劃需要參考的項目文檔有
  軟件測試計劃,
  軟件需求工件,
  迭代計劃,

對面向過程的系統採用的集成策略有
  自頂而下集成測試
  自底向上集成測試

簡述集成測試的過程主要包括哪些過程
  1.構建的確認過程
  2.補丁的確認過程
  3.系統集成測試測試組提交過程
  4.測試用例設計過程
  5.測試代碼編寫過程
  6.Bug的報告過程
  7.每週/每兩週的構架過程
  8.點對點的測試過程
  9.組內培訓過程

怎麼做好文檔測試
  仔細閱讀,跟隨每個步驟,檢查每個圖形,嘗試每個示例
  檢查文檔的編寫是否滿足文檔編寫的目的
  內容是否齊全、正確
  內容是否完善
  標記是否正確

系統測試計劃是否需要同行評審,爲什麼
  需要,系統測試計劃屬於項目階段性關鍵文檔,因此需要評審。

比較負載測試,容量測試,強度測試的區別
  負載測試:在一定的工作負荷下,系統的負荷和響應時間
  強度測試:在一定的負荷條件下,在較長時間跨度內的系統連續運行給系統性能所造成的影響。
  容量測試:容量測試目的是通過測試預先分析出反映軟件、系統應用特徵的某項指標的極限值(如最大併發用戶數、數據庫記錄數等),系統在極限值狀態下沒有出現任何軟件故障或還能保持主要功能正常運行。

測試結束的標準是什麼
  用例全部測試
  覆蓋率達到標準
  缺陷率達到標準
  其他指標達到質量標準

測試用例在軟件測試中的作用
  1.指導測試的實施
  2.規劃測試數據的準備
  3.編寫測試腳本的”設計規格說明書”
  4.評估測試結果的度量基準
  5.分析缺陷的標準

測試文檔有哪些,並且有哪些作用
  測試計劃、測試說明、測試報告、測試記錄、測試問題報告、測試總結報告
  作用:
    促進項目組成員之間的交流溝通,
    便於對測試項目的管理,
    決定測試的有效性,
    檢驗測試資源,
    明確任務的風險,
    評價測試結果,
    方便再測試,
    驗證需求的正確性

測試計劃中包括
  測試資源、進度測試、進度安排、測試策略、測試範圍

什麼是迴歸測試,其目的是什麼
  迴歸測試是指修改了舊代碼後,重新進行測試以確認修改沒有引入新的錯誤或導致其他代碼產生錯誤。自動迴歸測試將大幅降低系統測試、維護升級等階段的成本。
  目的:1.檢查bug是否修復;2.檢查修復bug是否引入新bug;3.檢查新版本是否保留了舊版本;

驗收測試目的是什麼
  驗收測試的目的是確保軟件準備就緒,並且可以讓最終用戶將其用於執行軟件的既定功能和任務

軟件測試的原則有哪些
  原則1:測試用例中一個必須部分是對預期輸出或結果的定義。
  原則2:程序員應當避免測試自己編寫的程序。
  原則3:編寫軟件的組織不應當測試自己編寫的軟件。
  原則4:應當徹底檢查每個測試的執行結果。
  原則5:測試用例的編寫不僅應當根據有效和預期的輸入情況,而且也應當根據無效和未預料到的輸入情況。
  原則6:檢查程序是否“未做其應該做的”僅是測試的一半,測試的另一半是檢查程序是否“做了其不應該做的”。
  原則7:應避免測試用例用後即棄,除非軟件本身就是一個一次性的軟件。
  原則8:計劃測試工作時不應默許假定不會發現錯誤。
  原則9:程序某部分存在更多錯誤的可能性,與該部分已發現的數量成正比。
  原則10:軟件測試是一項極富有創造性,極具智力挑戰性的工作

單元測試,集成測試,系統測試的側重點是什麼
  單元測試的重點是系統的模塊,包括子程序的正確性驗證等。
  集成測試的重點是模塊間的銜接以及參數的傳遞等。
  系統測試的重點是整個系統的運行以及與其他軟件的兼容性。

一個缺陷測試報告的組成
  主要是:測試目的、時間、人力、資源、用例執行、覆蓋及其缺陷(要說明缺陷的級別、內容和嚴重性)、測試說明分析、測試建議及測試結果。

對手機可以施加的壓力測試類型主要有
  存儲壓力、邊界壓力、響應能力壓力、網絡流量壓力

儘量採用複合的條件測試,以避免嵌套的分支結構
發現錯誤多的程序模塊,殘留在模塊中的錯誤也多
程序效率的提高主要通過選擇高效的算法來實現

ps.百度文庫有很多自稱計三軟測的卷子,但是好像和計三軟測的題目關係不大(不清楚是不是計四軟測,博主吃過虧(doge臉)…)

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章