1. 程式人生 > >面試總結------黑盒、白盒測試相關

面試總結------黑盒、白盒測試相關

黑盒、白盒測試

黑盒測試:已知產品的功能設計規格,可以進行測試證明每個實現了的功能是否符合要求。
白盒測試:已知產品的內部工作過程,可以通過測試證明每種內部操作是否符合設計規格要求,所有內部成分是否以經過檢查。

一、黑盒測試(又叫功能測試或資料驅動測試)
軟體的黑盒測試意味著測試要在軟體的介面處進行。這種方法是把測試物件看做一個黑盒子,測試人員完全不考慮程式內部的邏輯結構和內部特性,只依據程式的需求規格說明書,檢查程式的功能是否符合它的功能說明。

黑盒測試主要是為了發現以下幾類錯誤:
1、是否有不正確或遺漏的功能?
2、在介面上,輸入是否能正確的接受?能否輸出正確的結果?
3、是否有資料結構錯誤或外部資訊(例如資料檔案)訪問錯誤?
4、效能上是否能夠滿足要求?
5、是否有初始化或終止性錯誤?

黑盒測試方法:
1.等價類劃分(等價類是指某個輸入域的集合,它表示對揭露程式中的錯誤來說,集合中的每個輸入條件是等效的)
2.邊值分析法:列出單元功能、輸入、狀態及控制的合法邊界值,設計測試用例,包含全部邊界值的方法。
3.因果圖:
4.錯誤推測法
5.判定表法
6.狀態遷移法
7.正交實驗法

二、白盒測試(又稱為結構測試或邏輯驅動測試)
軟 件的白盒測試是對軟體的過程性細節做細緻的檢查。這種方法是把測試物件看做一個開啟的盒子,它允許測試人員利用程式內部的邏輯結構及有關資訊,設計或選擇 測試用例,對程式所有邏輯路徑進行測試。通過在不同點檢查程式狀態,確定實際狀態是否與預期的狀態一致。因此白盒測試又稱為結構測試或邏輯驅動測試。
白盒測試主要是想對程式模組進行如下檢查:


1、對程式模組的所有獨立的執行路徑至少測試一遍。
2、對所有的邏輯判定,取“真”與取“假”的兩種情況都能至少測一遍。
3、在迴圈的邊界和執行的界限內執行迴圈體。
4、測試內部資料結構的有效性,等等。

白盒測試方法:
1.程式碼檢查法
2.靜態結構分析法
3.靜態質量度量法
4.邏輯覆蓋法(語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋)
5.基本路徑測試法
6.域測試
7.符號測試
8.Z路徑覆蓋
9.程式變異
以上事實說明,軟體測試有一個致命的缺陷,即測試的不完全、不徹底性。由於任何程式只能進行少量(相對於窮舉的巨大數量而言)的有限的測試,在未發現錯誤時,不能說明程式中沒有錯誤。

三、灰盒測試
灰 盒測試,是介於白盒測試與黑盒測試之間的,可以這樣理解,灰盒測試關注輸出對於輸入的正確性,同時也關注內部表現,但這種關注不象白盒那樣詳細、完整,只 是通過一些表徵性的現象、事件、標誌來判斷內部的執行狀態,有時候輸出是正確的,但內部其實已經錯誤了,這種情況非常多,如果每次都通過白盒測試來操作, 效率會很低,因此需要採取這樣的一種灰盒的方法。

相關推薦

面試總結------測試相關

黑盒、白盒測試 黑盒測試:已知產品的功能設計規格,可以進行測試證明每個實現了的功能是否符合要求。 白盒測試:已知產品的內部工作過程,可以通過測試證明每種內部操作是否符合設計規格要求,所有內部成分是否

測試測試單元測試集成測試系統測試驗收測試的區別與聯系

角色 同時 驗收 center 調試 需求 lan 說明書 錯誤 黑盒測試、白盒測試、單元測試、集成測試、系統測試、驗收測試的區別與聯系   接下來為大家細心講述一下各種測試應用的環境及作用。 一、測試環境和角色 黑盒測試、白盒測試、單元測試、集成測試、系統測試、

軟體測試 -- 比較一下測試測試單元測試整合測試系統測試驗收測試的區別與聯絡

黑盒測試:已知產品的功能設計規格,可以進行測試證明每個實現了的功能是否符合要求。 白盒測試:已知產品的內部工作過程,可以通過測試證明每種內部操作是否符合設計規格要求,所有內部成分是否以經過檢查。 軟體的黑盒測試意味著測試要在軟體的介面處進行。這種方法是把測試物件看做一個黑盒子,測試人員完全不考慮程式內部的邏

迴歸測試測試測試等概念

迴歸測試 迴歸測試是指修改了舊程式碼後,重新進行測試以確認修改沒有引入新的錯誤或導致其他程式碼產生錯誤。自動迴歸測試將大幅降低系統測試、維護升級等階段的成本。 迴歸測試包括兩部分:函式本身的測試、其他程式碼的測試。在 對被修改的函式重新測試。如果函式的設計功能沒有變化,直接執行函式測試就可以了。如果修改了設計

軟件測試中的“”與“

外部 想是 區間 設計 nbsp ron 添加 這一 白盒測試  軟件測試中,最常聽到“黑盒測試”與“白盒測試”,它們是軟件測試中最基本的測試方法。   那麽究竟何為“黑盒”,何為“白盒&

前端面試總結之httphtml和瀏覽器

前言:本文是轉載文,文章中的'我'指原作者 1.http和https https的SSL加密是在傳輸層實現的。 (1)http和https的基本概念 http: 超文字傳輸協議,是網際網路上應用最為廣泛的一種網路協議,是一個客戶端和伺服器端請求和應答的標準(TCP),用於從WWW伺服

處理chrome屏的三種方法

處理谷歌瀏覽器網頁黑屏、白屏的三種方法   Chrome是谷歌旗下的一款瀏覽器,全稱:Google Chrome。它的的特點是簡潔、快速。並且支援多標籤瀏覽,也就是說若是一個標籤頁面的崩潰也不會

javaweb面試總結(二電商專案)

電商架構:https://blog.csdn.net/yangbutao/article/details/12242441九個模組:https://blog.csdn.net/belvine/article/details/79400813電商類目:https://blog.

javaweb面試總結(四分散式事務CAP原理和BASE思想JDBC事務和JTA事務的區別2PC與TCC區別)

CAP原理和BASE思想: http://www.jdon.com/37625分散式事務如何處理?解決方案有很多種!比如事務補償機制:即在事務鏈中的任何一個正向事務操作,都必須存在一個完全符合回滾規則的可逆事務。或者利用訊息系統實現最終一致性;----------------

軟體測試基礎--測試測試自動化測試

1   白盒測試         白盒測試也稱為結構測試或者邏輯驅動測試,它是按照程式內部的結構測試程式,通過測試來檢驗產品內部動作是否按照設計規格說明書的規定正常進行,檢驗程式中的每條通路是否能按照預定要求正確工作          這一方法是吧測試物件看做一個開啟的盒

測試剖析(面試專用)

白盒測試: 因為無論測試方案多完美也不可能100%保證發現所有bug,所以白盒測試只是要用最小的資源做最多的測試檢查,我比較常用的是基本路徑測試法。小程式 基本路徑測試法也就是設計出的測試用例要保證每個基本的獨立路徑要至少執行一次。 畫圖方法: 首先要計算圈複雜度V(G)

.測試

情況 正交 tro 可能 關系 結果 次數 media player 1.黑盒測試:不關心被測軟件的內部結構,只關心軟件的輸入數據和輸出結果 測試方法:等價類劃分法,邊界值,決策表,因果圖,場景法,錯誤推測法..... 1.

軟體測試——測試的方法

軟體測試 黑盒白盒的區別不用說了,這裡介紹黑盒白盒測試所用的方法,都是關於測試樣例的設計 白盒測試 語句覆蓋 每條語句至少執行一次 判定覆蓋 每一判定的每個分支至少執行一次

測試 測試

習題1 為以下流程圖所示的程式段設計一組測試用例,要求分別滿足語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、組合覆蓋和路徑覆蓋。 語句覆蓋 原則覆蓋程式中所有可執行的語句 設計的測試用例如下 編號 輸入項 執行語句

Android 測試之單元測試(junit),測試之mokey測試

導言: 做安卓也有幾個年頭,對於小專案基本都不去單元測試和穩定性測試等,都是在出現異常後通過debug處理或log列印即可解決,當然對於大的專案,由於執行時效問題,加快開發效率,一些測試方法必須要做,比如白盒測試之單元測試,最新的AS都集成了junit,還有黑盒測試(功能測試)之moke

測試總結

第一章 白盒測試: 又稱為邏輯驅動測試或者結構測試,是按照程式內部結構測試程式, 通過測試來檢驗產品內部動作是否按照設計說明書的規定來正常執行,該測試可以覆蓋全部程式碼,分支,路徑和條件 白盒測試的原因: 1,黑盒不能對程式程式碼進行測試 2,程式如果存在記憶體洩漏,黑盒不會發現 3,程

測試 Redis 叢集快取測試要點--關於 線上 token 失效 BUG 的總結

在測試xx系統過程中遇到了線上大面積使用者登入態失效的嚴重問題,事後對於其原因及測試盲點做了一些總結記錄以便以後查閱,總結分為以下7點,其中原理性的解釋有些摘自網路。 1.xx系統token失效問題覆盤 2.Redis 經典流程 3.Redis分片部署方式 4.Redis擴

Android 測試之單元測試(junit),測試之mokey

導言: 做安卓也有幾個年頭,對於小專案基本都不去單元測試和穩定性測試等,都是在出現異常後通過debug處理或log列印即可解決,當然對於大的專案,由於執行時效問題,加快開發效率,一些測試方法必須要做,比

一句話瞭解 “測試測試

軟體測試的兩個方面: 通俗的語言解釋為: 黑盒測試:一個黑盒子留了兩個口,一個輸入和一個輸出。裡面什麼也看不到,只能通過操作手冊來進行測試。 ps:當然可以藉助一些專業測試工具。 白盒測試:把黑

測試測試的比較

白盒測試是窮舉路徑測試,黑盒測試是窮舉輸入測試,這兩種方法是基於完全不同的觀點,反應了事物的兩個極端,它們各有側重和優勢,但不能彼此替代。在現代的測試理念中,這兩種測試方法不是截然分開的,而是交叉使用。