主頁 > 軟體設計 > 軟體測驗(白盒測驗與黑盒測驗)

軟體測驗(白盒測驗與黑盒測驗)

2021-10-07 08:45:48 軟體設計

  • 黑盒測驗
    • 概述
      • 黑盒測驗用例設計方法包括 等價類劃分法、邊界值分析法、錯誤推測法、因果圖法、判定表驅動法、正交試驗設計法、功能圖法、場景圖法等
    • 等價類劃分法
      • 概念
        • 等價類劃分法是把所有可能輸入的資料,即程式的輸入域劃分若干部分(子集),然后從每一個子集中選取少數具有代表性的資料作為測驗用例,
        • 測驗某等價類的代表值就等于對這一類其他值的測驗
      • 等價類:
        • 在所有測驗的資料中,具有某種共同特征的資料子集
      • 等價類的分類:
        • 有效等價類:滿足需求的
          • 有效等價類,是指對于程式的規格說明來說是合理的、有意義的輸入資料構成的集合,
          • 利用有效等價類可檢驗程式是否實作了規格說明所規定的功能和性能
        • 無效等價類:不滿足需求的
          • 無效等價類 指對程式的規格說明是不合理的或無意義的輸入資料所構成的集合,
          • 對于具體的問題,無效等價類至少應有一個,也可能多個,
      • 等價類劃分規則

        • 1.明確需求
        • 2.明確有效和無效等價類
        • 3.為每一個等價類規定一個唯一的編號
        • 4.設計一個新的測驗用例,使其盡可能多地覆寫尚未被覆寫地有效等價類,重復這一步,直到所有的有效等價類都被覆寫為止
        • 5.設計一個新的測驗用例,使其僅覆寫一個尚未被覆寫的無效等價類,重復這一步,直到所有的無效等價類都被覆寫為止
    • 邊界值分析法
      • 概念
        • 大量的錯誤是發生在輸入或輸出范圍的邊界上,而不是發生在輸入輸出范圍的內部,因此針對各種邊界情況設計測驗用例,可以查出更多的錯誤
        • 邊界值分析法就是對輸入或輸出的邊界值進行測驗的一種黑盒測驗方法,
        • 通常邊界值分析法是作為對等價類劃分法的補充,這種情況下,其測驗用例來自等價類的邊界
        • 與等價類區別:
          • 邊界值分析不是從某等價類中隨便挑一個作為代表,而是使這個等價類的每個邊界都要作為測驗條件,
          • 邊界值分析不僅考慮輸入條件,還要考慮輸出空間產生的測驗情況
      • 邊界范圍
        • 使用邊界值分析方法設計測驗用例,首先應確定邊界情況,通常輸入和輸出等價類的邊界,就是應著重測驗的邊界情況
        • 應當選取正好等于,剛剛大于或剛剛小于邊界的值作為測驗資料,而不是選取等價類中的典型值或任意值作為測驗資料
          • 上點:邊界上的點(等于)
          • 離點:距離上點最近的點
          • 內點:范圍內的點
        • 常見邊界值:
          • 1.對16Bit的整數而言,32767和32768是邊界
          • 2.螢屏上游標在最左上、最右下位置
          • 3.報表的第一行和最后一行
          • 4.陣列元素的第一個和最后一個
          • 5.回圈的第0次、第1次和倒數第2次、最后一次
    • 錯誤推測法(經驗)
      • 概念
        • 基于經驗和直覺推測程式中所有可能存在的各種錯誤,從而有針對性的設計測驗用例的方法
        • 列舉出程式中所有可能有的錯誤和容易發生錯誤的特殊情況,根據他們選擇測驗用例
    • 因果圖法
      • 概念
        • 因果圖法是一種利用圖解法分析輸入的各種組合情況,從而設計測驗用例的方法,它適合于檢查程式輸入條件的各種組合情況
        • 等價類劃分法和邊界值分析方法都是著重考慮輸入條件,但沒有考慮輸入條件的各種組合、輸入條件之間的相互制約關系,這樣雖然各種輸入條件可能出錯的情況已經測驗到了,但多個輸入條件組合起來可能出錯的情況卻被忽視了
        • 如果在測驗時必須考慮輸入條件的各種組合,則可能的組合數目將是天文數字,因此必須考慮采用一種適合于描述多種條件的組合、相應產生多個動作的形式來進行測驗用例的設計,這就需要利用因果圖(邏輯模型)
      • 因果圖
        • 因果圖中使用了簡單的邏輯符號,以直線聯接左右結點,左結點表示輸入狀態(或稱原因),右結點表示輸出狀態(或稱結果)
        • C1表示原因,通常置于圖的左部,e1表示結果,通常在圖的右部
        • 關系

          • 恒等:若c1是1,則e1也是1;否則e1為0,
          • 非:若c1是1,則e1是0;否則e1是1,
          • 或:若c1或c2或c3是1,則e1是1;否則e1為0,“或”可有任意個輸入,
          • 與:若c1和c2都是1,則e1為1;否則e1為0,“與”也可有任意個輸入,
        • 約束

          • 輸入狀態相互之間還可能存在某些依賴關系,稱為約束,例如,某些輸入條件本身不可能同時出現,輸出狀態之間也往往存在約束,在因果圖中,用特定的符號標明這些約束,
          • E約束(異):a和b中至多有一個可能為1,即a和b不能同時為1,
          • I約束(或):a、b和c中至少有一個必須是1,即 a、b 和c不能同時為0,
          • O約束(唯一);a和b必須有一個,且僅有1個為1,
          • R約束(要求):a是1時,b必須是1,即不可能a是1時b是0,
    • 判定表驅動法
      • 判定表是分析和表達多邏輯條件下執行不同操作的情況的工具
      • 能夠將復雜的問題按照各種可能的情況全部列舉出來,簡明并避免遺漏,
      • 因此,利用判定表能夠設計出完整的測驗用例集合,在一些資料處理問題當中,某些操作的實施依賴于多個邏輯條件的組合,即:針對不同邏輯條件的組合值,分別執行不同的操作,判定表適合于處理這類問題
      • 判定表建立步驟:
        • 1) 確定規則的個數,假如有n個條件,每個條件有兩個取值(0,1),故2n種規則,
        • 2) 列出所有的條件樁和動作樁
        • 3) 填入條件項
        • 4) 填入動作項,等到初始判定表
        • 5) 簡化,合并相似規則(相同動作)
    • 正交試驗法
      • 從大量的(實驗)資料(測驗例)中挑選適量的,有代表性的點(例),從而合理地安排實驗(測驗)的一種科學實驗設計方法.類似的方法有:聚類分析方法,因子方法方法等
  • 白盒測驗
    • 概念
      • 白盒測驗,又稱結構測驗、邏輯驅動測驗或基于程式代碼內部構成邏輯的測驗,測驗工程師需深入考察程式代碼的內部結構、邏輯設計等
      • 對于白盒測驗工程師來說,軟體產品內部構成是透明的

      • 特點
        • 優點:代碼覆寫率高
          • 黑盒測驗基于業務需求,因為不涉及代碼層面,測驗用例無法覆寫所有的代碼邏輯
        • 缺點:
          • 覆寫所有代碼路徑難度大
          • 業務功能可能覆寫不全
          • 測驗開銷大
    • 白盒測驗方法
      • 靜態白盒測驗方法(不需要執行代碼)
        • 桌面檢查(Code Review)
          • 相互交叉審查代碼
        • 代碼審查
          • 會議中,由開發人員講解代碼邏輯
        • 代碼走查
          • 會議中,參會人在會議程序中,使用測驗用例查看代碼走向(演示查看)
        • 代碼掃描工具
      • 動態白盒測驗方法
        • 邏輯覆寫法:通程序式邏輯結構的遍歷實作程式的覆寫
          • 覆寫率:用于衡量測驗完整性的手段
            • 覆寫率 = 至少被執行一次的item數 / item總數
            • item為程式邏輯結構,如陳述句、判斷、條件、路徑等
          • 陳述句覆寫
            • 陳述句覆寫測驗設計測驗用例,使得程式中每條陳述句至少被執行一次
            • 陳述句覆寫率 = 至少被執行一次的陳述句數 / 可執行的陳述句總數
            • 例如:代碼共有4條可執行陳述句,設計的測驗用例執行了3條,陳述句覆寫了為3/4=75%
            • 弊端:
              • 陳述句覆寫不能準確判斷運算中的邏輯關系錯誤,因為即使用例能覆寫到所有陳述句,當也可能無法檢測到判斷運算中的邏輯
          • 判定覆寫
            • 判定覆寫也叫分支覆寫,設計測驗用例,使得程式中的每個判斷的”真“和”假“都至少被執行一次
              • 即:程式中的每個分支至少執行一次
              • 只要滿足了判定覆寫標準就一定滿足陳述句覆寫標準
            • 判斷覆寫率 = 每個判斷的真偽值至少出現一次 / 判定結果的總數
            • 例如:代碼共有2個判定,4個判定結果,設計的測驗用例執行了3個分支,分支覆寫了為3/4=75%
            • 弊端:
              • 判斷覆寫會忽略條件中取或(||)的情況
          • 條件覆寫(組合的條件被拆分開)
            • 條件覆寫設計測驗用例,使得判定中的每個條件至少有一次取真值,有一次取假值
            • 條件覆寫率 = 每個條件的真偽值至少出現一次 / 條件結果的總數
            • 例如:代碼中有判定2個,條件3個,條件結果6個,設計測驗用例執行了5個條件結果,條件覆寫率為5/6=83%
            • 弊端:
              • 條件覆寫筆判定覆寫,增加了對判定中所有條件的測驗,但是條件覆寫無法保證判定覆寫(無法保證所有判定結果都被覆寫)
          • 判定-條件覆寫(判定和條件都被覆寫)
            • 判定條件覆寫設計測驗用例,使得被測驗程式中的每個判斷本身的判定結果(真偽)至少滿足一次,同時,每個邏輯條件的可能值(真偽)也至少被滿足一次,
              • 即同時滿足100%判定覆寫和100%條件覆寫的標準
            • 判定條件覆寫率 = 每個條件的真偽值和判定的真偽值至少出現一次 / 條件結果的總數 + 判定結果的總數
            • 例如:代碼中有判定2個,條件3個,判定結果4個,條件結果6個,設計測驗用例執行了3個判定結果,5個條件結果,判定條件覆寫率為:(3+5)/(4+6)=80%
            • 弊端:
              • 滿足判定-條件覆寫后,一定能滿足條件覆寫、判定覆寫、陳述句覆寫,但還是會忽略條件中取或的情況
          • 條件組合覆寫(每個判定中條件的可能性)
            • 條件組合覆寫設計測驗用例,使得被測驗程式中的每個判定中條件結果的所有可能組合至少執行一次
            • 條件組合覆寫率 = 條件組合至少出現一次 / 條件組合的總數
            • 例如:案例代碼中有判定2個,條件3個(判定1有2個條件,判定2有1一個條件),判定1的條件組合為4個,判定2的條件組合為2個,設計測驗用例執行了5個條件組合,條件組合覆寫率為:5/(4+2)=83%
            • 弊端:
              • 滿足條件組合覆寫后,一定能滿足條件覆寫、判定覆寫、條件-判定覆寫、陳述句覆寫,但還是會忽略條件中取或的情況
              • 條件組合覆寫不能保證所有路徑被執行
          • 路徑覆寫
            • 路徑覆寫設計測驗用例,覆寫程式中所有可能的路徑
            • 路徑覆寫率 = 至少被執行過一次的路徑數 / 路徑總數
            • 例如:案例代碼中共有4條路徑,設計測驗用例執行了3條路徑,路徑覆寫率為3/4=75%
            • 弊端:
              • 路徑覆寫可以對程式進行徹底的測驗,但是滿足路徑覆寫,并不一定滿足條件覆寫,也就不能滿足條件組合覆寫
        • 基本路徑測驗法
          • 由于路徑覆寫在實際專案中會非常復雜,作業量巨大,所以出現了基本路徑測驗法
          • 基本路徑測驗法在程式控制流程圖的基礎上,通過分析程式的環路復雜性,匯出基本可執行路徑集合,從而設計測驗用例

          • 步驟:
            • 1.根據代碼畫出程式控制流圖,并轉換為控制流圖

            • 2.計算環路復雜度,三種計算方法:

              • 流圖中區域的數量,就對應于環型的復雜性(區域數量 = 環形復雜度)
              • 給定流圖G的圈復雜度V(G),定義為v(G)=E-N+2
                • E是流圖中邊的數量,N是流圖中節點的數量
                • 上圖: V(G)=10-8+2
              • 給定流圖G的圈復雜度V(G),定義為v(G)=P+1
                • P是流圖G中判定節點的數量
                • 上圖:V(G)=3+1
            • 3.匯出可執行路徑(只需經過節點即可,一般路徑數和復雜度相等)

            • 4.根據路徑,設計測驗用例

轉載請註明出處,本文鏈接:https://www.uj5u.com/ruanti/306023.html

標籤:其他

上一篇:CF33C Wonderful Randomized Sum

下一篇:MATLAB從入門到精通(1)

標籤雲
其他(157675) Python(38076) JavaScript(25376) Java(17977) C(15215) 區塊鏈(8255) C#(7972) AI(7469) 爪哇(7425) MySQL(7132) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5869) 数组(5741) R(5409) Linux(5327) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4554) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2429) ASP.NET(2402) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) 功能(1967) .NET技术(1958) Web開發(1951) python-3.x(1918) HtmlCss(1915) 弹簧靴(1913) C++(1909) xml(1889) PostgreSQL(1872) .NETCore(1853) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • 面試突擊第一季,第二季,第三季

    第一季必考 https://www.bilibili.com/video/BV1FE411y79Y?from=search&seid=15921726601957489746 第二季分布式 https://www.bilibili.com/video/BV13f4y127ee/?spm_id_fro ......

    uj5u.com 2020-09-10 05:35:24 more
  • 第三單元作業總結

    1.前言 這應該是本學期最后一次寫作業總結了吧。總體來說,對作業的節奏也差不多掌握了,作業做起來的效率也更高了。雖然和之前的作業一樣,作業中都要用到新的知識,但是相比之前,更加懂得了如何利用工具以及資料。雖然之間卡過殼,但總體而言,這幾次作業還算完成的比較好。 2.作業程序總結 相比前兩個單元,此單 ......

    uj5u.com 2020-09-10 05:35:41 more
  • 北航OO(2020)第四單元博客作業暨課程總結博客

    北航OO(2020)第四單元博客作業暨課程總結博客 本單元作業的架構設計 在本單元中,由于UML圖具有比較清晰的樹形結構,因此我對其中需要進行查詢操作的元素進行了包裝,在樹的父節點中存盤所有孩子的參考。考慮到性能問題,我采用了快取機制,一次查詢后盡可能快取已經遍歷過的資訊,以減少遍歷次數。 本單元我 ......

    uj5u.com 2020-09-10 05:35:48 more
  • BUAA_OO_第四單元

    一、UML決議器設計 ? 先看下題目:第四單元實作一個基于JDK 8帶有效性檢查的UML(Unified Modeling Language)類圖,順序圖,狀態圖分析器 MyUmlInteraction,實際上我們要建立一個有向圖模型,UML中的物件(元素)可能與同級元素連接,也可與低級元素相連形成 ......

    uj5u.com 2020-09-10 05:35:54 more
  • 6.1邏輯運算子

    邏輯運算子 1. && 短路與 運算式1 && 運算式2 01.運算式1為true并且運算式2也為true 整體回傳為true 02.運算式1為false,將不會執行運算式2 整體回傳為false 03.只要有一個運算式為false 整體回傳為false 2. || 短路或 運算式1 || 運算式2 ......

    uj5u.com 2020-09-10 05:35:56 more
  • BUAAOO 第四單元 & 課程總結

    1. 第四單元:StarUml檔案決議 本單元采用了圖模型決議UML。 UML檔案可以抽象為圖、子圖、邊的邏輯結構。 在實作中,圖的節點包括類、介面、屬性,子圖包括狀態圖、順序圖等。 采用了三次遍歷UML元素的方法建圖,第一遍遍歷建點,第二、三次遍歷設定屬性、連邊,實作圖物件的初始化。這里借鑒了一些 ......

    uj5u.com 2020-09-10 05:36:06 more
  • 談談我對C# 多型的理解

    面向物件三要素:封裝、繼承、多型。 封裝和繼承,這兩個比較好理解,但要理解多型的話,可就稍微有點難度了。今天,我們就來講講多型的理解。 我們應該經常會看到面試題目:請談談對多型的理解。 其實呢,多型非常簡單,就一句話:呼叫同一種方法產生了不同的結果。 具體實作方式有三種。 一、多載 多載很簡單。 p ......

    uj5u.com 2020-09-10 05:36:09 more
  • Python 資料驅動工具:DDT

    背景 python 的unittest 沒有自帶資料驅動功能。 所以如果使用unittest,同時又想使用資料驅動,那么就可以使用DDT來完成。 DDT是 “Data-Driven Tests”的縮寫。 資料:http://ddt.readthedocs.io/en/latest/ 使用方法 dd. ......

    uj5u.com 2020-09-10 05:36:13 more
  • Python里面的xlrd模塊詳解

    那我就一下面積個問題對xlrd模塊進行學習一下: 1.什么是xlrd模塊? 2.為什么使用xlrd模塊? 3.怎樣使用xlrd模塊? 1.什么是xlrd模塊? ?python操作excel主要用到xlrd和xlwt這兩個庫,即xlrd是讀excel,xlwt是寫excel的庫。 今天就先來說一下xl ......

    uj5u.com 2020-09-10 05:36:28 more
  • 當我們創建HashMap時,底層到底做了什么?

    jdk1.7中的底層實作程序(底層基于陣列+鏈表) 在我們new HashMap()時,底層創建了默認長度為16的一維陣列Entry[ ] table。當我們呼叫map.put(key1,value1)方法向HashMap里添加資料的時候: 首先,呼叫key1所在類的hashCode()計算key1 ......

    uj5u.com 2020-09-10 05:36:38 more
最新发布
  • 【中介者設計模式詳解】C/Java/JS/Go/Python/TS不同語言實作

    * 中介者模式是一種行為型設計模式,它可以用來減少類之間的直接依賴關系,
    * 將物件之間的通信封裝到一個中介者物件中,從而使得各個物件之間的關系更加松散。
    * 在中介者模式中,物件之間不再直接相互互動,而是通過中介者來中轉訊息。 ......

    uj5u.com 2023-04-20 08:20:47 more
  • 露天煤礦現場調研和交流案例分享

    他們集團的資訊化公司及研究院在一個礦區正在做智能礦山的統一平臺的 試點,專案投資大概1億,包括了礦山的各方面的內容,顯示得我們這次交流有點多余。他們2年前開始做智能礦山的規劃,有很多煤礦行業專家的加持,他們的描述是非常完美,但是去年底應該上線的平臺,現在還沒有看到影子。他們確實有很多場景需求,但是被... ......

    uj5u.com 2023-04-20 08:20:25 more
  • 《社區人員管理》實戰案例設計&個人案例分享

    設計是一個讓人夢想成真程序,開始編碼、測驗、除錯之前進行需求分析和架構設計,才能保證關鍵方面都做正確 ......

    uj5u.com 2023-04-20 08:20:17 more
  • 軟體架構生態化-多角色交付的探索實踐

    作為一個技術架構師,不僅僅要緊跟行業技術趨勢,還要結合研發團隊現狀及痛點,探索新的交付方案。在日常中,你是否遇到如下問題 “ 業務需求排期長研發是瓶頸;非研發角色感受不到研發技改提效的變化;引入ISV 團隊又擔心質量和安全,培訓周期長“等等,基于此我們探索了一種新的技術體系及交付方案來解決如上問題。 ......

    uj5u.com 2023-04-20 08:20:10 more
  • 【中介者設計模式詳解】C/Java/JS/Go/Python/TS不同語言實作

    * 中介者模式是一種行為型設計模式,它可以用來減少類之間的直接依賴關系,
    * 將物件之間的通信封裝到一個中介者物件中,從而使得各個物件之間的關系更加松散。
    * 在中介者模式中,物件之間不再直接相互互動,而是通過中介者來中轉訊息。 ......

    uj5u.com 2023-04-20 08:19:44 more
  • 露天煤礦現場調研和交流案例分享

    他們集團的資訊化公司及研究院在一個礦區正在做智能礦山的統一平臺的 試點,專案投資大概1億,包括了礦山的各方面的內容,顯示得我們這次交流有點多余。他們2年前開始做智能礦山的規劃,有很多煤礦行業專家的加持,他們的描述是非常完美,但是去年底應該上線的平臺,現在還沒有看到影子。他們確實有很多場景需求,但是被... ......

    uj5u.com 2023-04-20 08:19:07 more
  • 《社區人員管理》實戰案例設計&個人案例分享

    設計是一個讓人夢想成真程序,開始編碼、測驗、除錯之前進行需求分析和架構設計,才能保證關鍵方面都做正確 ......

    uj5u.com 2023-04-20 08:18:57 more
  • 軟體架構生態化-多角色交付的探索實踐

    作為一個技術架構師,不僅僅要緊跟行業技術趨勢,還要結合研發團隊現狀及痛點,探索新的交付方案。在日常中,你是否遇到如下問題 “ 業務需求排期長研發是瓶頸;非研發角色感受不到研發技改提效的變化;引入ISV 團隊又擔心質量和安全,培訓周期長“等等,基于此我們探索了一種新的技術體系及交付方案來解決如上問題。 ......

    uj5u.com 2023-04-20 08:18:49 more
  • 05單件模式

    #經典的單件模式 public class Singleton { private static Singleton uniqueInstance; //一個靜態變數持有Singleton類的唯一實體。 // 其他有用的實體變數寫在這里 //構造器宣告為私有,只有Singleton可以實體化這個類! ......

    uj5u.com 2023-04-19 08:42:51 more
  • 【架構與設計】常見微服務分層架構的區別和落地實踐

    軟體工程的方方面面都遵循一個最基本的道理:沒有銀彈,架構分層模型更是如此,每一種都有各自優缺點,所以請根據不同的業務場景,并遵循簡單、可演進這兩個重要的架構原則選擇合適的架構分層模型即可。 ......

    uj5u.com 2023-04-19 08:42:41 more