• http://p.qiao.baidu.com/cps/chat?siteId=15318487&userId=28207205&siteToken=ce56fdf19708fa097364259760b7dd18
    您的位置:主頁 > 服務 >

    軟件測試

    2019-10-08 16:00

    程序+文檔+數據=軟件
     
    狹義的軟件測試定義:為發現軟件缺陷而執行程序或系統的過程
     
    廣義的軟件測試定義:人工或自動地運行或測定某系統的過程,目的在于檢驗它是否滿足規定的需求或弄清預期結果和實際結果間的差別
     
    為什么要做軟件測試
     
    發現軟件缺陷 
    功能錯
    功能遺漏
    超出需求部分(畫蛇添足)
    性能不符合要求
    軟件質量高低:是否符合用戶習慣、符合用戶需求
    測試的任務
     
    找出
    定位
    修改
    修改后要做回歸測試,對已修改的部分進行再次的測試,避免引入新的錯誤
    測試用例的定義和組成部分
     
    測試用例是為特定的目的而設計的一組測試輸入、執行條件和預期的結果。測試用例是執行的最小實體。簡單地說,測試用例就是設計一個場景,使軟件程序在這種場景下,必須能夠正常運行并且達到程序所設計的執行結果。
    包含 
    用例ID
    用例名稱
    測試目的
    測試環境
    前提條件
    測試步驟
    預期結果
    其他信息
    一個好的高質量的測試用例在于能發現至今未發現的錯誤,一個成功的測試是發現了至今未發現的錯誤的測試(Copyright © https://blog.csdn.net/s_gy_zetrov. All Rights Reserved)
     
    兩個方向
     
    找錯誤,反向思維。
    證明能正常工作,正向思維。
    目前的方法出發點一般是“找錯誤”,因為沒法證明軟件是正確的。
    用戶需求
     
    要求(用戶想要) 需求(用戶目的) 需要(用戶內在欲望)
    牙膏 清潔牙齒 個人魅力(個人外表整潔)
    什么時候停止測試
     
    繼續測試沒有產生新的失效
    繼續測試沒有發現新缺陷
    回報很小
    以達到要求的覆蓋
    無法考慮新的測試用例(若已遵循測試規則和指導方針,則可以選擇)
    測試過程模型
    缺陷具有放大的特點,隨著階段的推進發現bug的成本會指數型上升,所以并不是代碼級的測試才叫測試,而是開發過程各個階段越早開始測試越好。
     
    瀑布模型:需求分析->設計(概要、詳細)->編程->測試(單元、集成、系統)->維護
    V模型(瀑布-改):在軟件開發的生存期,開發活動和測試活動幾乎同時的開始,如概要設計階段結束后集成測試的測試用例就出來了、詳細設計階段結束后單元測試的測試用例也就出來了等
    W模型(V模型更加細化、每步都加測試,邊造軟件邊進行測試):需求分析加了需求測試、概要設計加了功能測試、詳細設計加了設計測試、編碼加了單元測試、集成加了集成測試、確認加了確認測試、驗收加了系統測試
    H模型:無實際意義,僅說明可以獨立測試
    軟件測試的原則
    所有的測試都應追溯到用戶的需求
    盡早地和不斷地進行軟件測試(缺陷具有放大的特點,測試成本隨階段深入而上升)
    8-2原則 
    測試中發現的錯誤80%很可能起源于程序中的20%
    提前測試可發現80%,系統測試找出剩余bug的80%(總體的16%),最后的4%可能只有用戶大范圍長時間使用后才暴露出來
    80%的工程用在20%的需求上(即關鍵需求)
    軟件缺陷的寄生蟲性:找到的缺陷越多說明軟件遺留的缺陷越多
    避免自己測試自己的程序
    回歸測試:避免引入新的錯誤
    軟件測試流程
    制定測試計劃->測試設計->測試開發->測試執行->評估測試
     
    注意
     
    測試不是開發后期的一個階段
    測試入門其實稍容易,但要求技術一樣高
    測試多數情況下不能覆蓋所有輸入
    不要“有時間多測,沒時間少測”
    軟件測試不止是測試人員的事,也是開發人員的事
    調試和測試不一樣
    測試絕非只運行一下軟件看結果對不對
    L10N:本地化測試
     
    I18N:國際化測試
     
    黑盒測試
    等價類劃分與邊界值分析
    如何劃分有效和無效等價類(一些常用原則)
     
    如果一個變量在某一個范圍內,給它一個有效等價類兩個無效等價類
    如果一個變量取值在某一個集合范圍內,可在集合內取一個有效等價類在集合外取一個無效等價類
    如果一個變量的條件是“必須怎樣”、“一定會是怎樣”則去一個值滿足“必須要”的條件再取多個不滿足的從多個角度去違背這個條件
    如果一個變量是布爾類型,則取一個對的一個錯的
    在找到有效等價類和無效等價類后如何找測試數據
     
    有效等價類:要盡可能多的覆蓋有效等價類
    無效等價類:每找到一組數據要至少覆蓋一組無效等價類
    如果功能模塊的輸入是多個,多個自變量放在一起如何找有效等價類、無效等價類、測試數據,4鐘方法:
     
    以一個具有自變量X1、X2的函數F為例,X1取值范圍為[a, b)、[b, c)、[c, d];X2取值范圍為[e, f)、[f, g]。僅考慮有標記的方塊內為一般等價類測試(不處理無效數據的測試)、所有方塊都考慮為健壯等價類測試(進行無效數據處理的測試)
     
    g |_______|_______|_______|_______|_______|
    f |_______|///////|///////|///////|_______|
    e |_______|///////|///////|///////|_______|
      |_______|_______|_______|_______|_______|
              a       b       c       d
    1
    2
    3
    4
    5
    弱一般等價類 
    有假設前提:是單缺陷的,即假設系統出現的缺陷很少是由兩個及以上的輸入變量共同出現缺陷而引起的。
    選取的測試用例覆蓋所有的有效等價類 
    對于X1(橫軸):[a, b)、[b, c)、[c, d]都需要覆蓋到;對于X2(縱軸):[e, f)、[f, g]都需要覆蓋到。保證了這兩點的情況下,就可以任意取點了
    g |_______|_______|_______|_______|_______|
    f |_______|_______|____x__|_______|_______|
    e |_______|___x___|_______|___x___|_______|
      |_______|_______|_______|_______|_______|
              a       b       c       d
    1
    2
    3
    4
    5
    強一般等價類 
    基于多缺陷假設
    選取的測試用例覆蓋所有的有效等價類的笛卡爾積(集合A{a1,a2,a3} 集合B{b1,b2} 他們的 笛卡爾積 是 A*B ={(a1,b1),(a1,b2),(a2,b1),(a2,b2),(a3,b1),(a3,b2)} ) 
    對于X1(橫軸):[a, b)、[b, c)、[c, d];X2(縱軸):[e, f)、[f, g],笛卡爾積的結果就是所有的格子,所以必須所有格子都取點
    g |_______|_______|_______|_______|_______|
    f |_______|___x___|___x___|___x___|_______|
    e |_______|___x___|___x___|___x___|_______|
      |_______|_______|_______|_______|_______|
              a       b       c       d
    1
    2
    3
    4
    5
    弱健壯等價類 
    有假設前提:是單缺陷的,即假設系統出現的缺陷很少是由兩個及以上的輸入變量共同出現缺陷而引起的。
    考慮無效值,對有效輸入,測試用例的設計等同于弱一般等價類;對無效輸入,測試用例需要保證擁有一個無效值(比如某一變量的有效類的取值范圍為x、y、z,則無效類為x-和z+,加起來取值范圍一共:x-、x、y、z、z+),并保持其余的值都是有效的。
    所以如下圖,在保證弱一般等價類的取點后,還需要分別保證X1、X2中有1個屬于無效輸入的兩個額外的取值范圍,另一個屬于有效輸入的原本取值范圍(如X1取無效X2取有效或X1取有效X2取無效,并全部覆蓋無效范圍)
     
    g |_______|_______|_______|___O___|_______|
    f |_______|_______|___x___|_______|___O___|
    e |___O___|___x___|_______|___x___|_______|
      |_______|___O___|_______|_______|_______|
              a       b       c       d
    1
    2
    3
    4
    5
    強健壯等價類 
    基于多缺陷假設
    所有的取值范圍取笛卡爾積(比如某一變量的有效類的取值范圍為x、y、z,則無效類為x-和z+,加起來取值范圍一共:x-、x、y、z、z+,再與另一變量的取值范圍取笛卡爾積)
    g |___O___|___O___|___O___|___O___|___O___|
    f |___O___|___x___|___x___|___x___|___O___|
    e |___O___|___x___|___x___|___x___|___O___|
      |___O___|___O___|___O___|___O___|___O___|
              a       b       c       d
    1
    2
    3
    4
    5
    在找測試數據時
     
    對于單缺陷的,即只有一個輸入變量是處于無效等價類,其他所有輸入變量都處在有效等價類中。包含: 
    單缺陷有效值
    單缺陷無效值
    對于多缺陷的,即多個輸入變量同時出現錯誤引起的。包含: 
    有效值
    無效值
    與等價類劃分密切相關的就是邊界值分析。先劃分等價類,再結合邊界值產生測試用例。邊界值分析中也有假設前提:單缺陷。包含4種設計測試用例的方法:
     
    一般的邊界值分析 
    有效范圍:最小的、比最小大一點的、正常值、比最大小一點、最大值
    無效范圍:比最小更小、比最大更大
    共7個,再分單缺陷和多缺陷,這樣設計測試用例的個數就會指數上升
    - 單變量假設 多變量假設
    有效值 **一般邊界值**5n-(n-1)【n-1個變量取正常值】=4n+1【僅考慮有效區間單個變量邊界值(一般邊界值):用最小值、略高于最小值、正常值、略低于最大值和最大值?!?span style="white-space:pre"> **一般最壞情況邊界值**5^n【僅考慮有效區間多個變量邊界值同時作用(一般最壞情況邊界值):用各個變量最小值、略高于最小值、正常值、略低于最大值和最大值的笛卡爾積?!?/div>
    無效值 **健壯性邊界值**7n-(n-1)=6n+1【 同時考慮有效區間和無效區間單個變量邊界值(健壯邊界值):除了最小值、略高于最小值、正常值、略低于最大值、最大值,還要有略超過最大值和略小于最小值的值?!?span style="white-space:pre"> **健壯最壞情況邊界值**7^n【同時考慮有效區間和無效區間多個變量邊界值同時作用(健壯最壞情況邊界值):用各個變量最小值、略高于最小值、正常值、略低于最大值、最大值、略超過最大值和略小于最小值的笛卡爾積?!?/div>
    常見的邊界值
     
    16bit整數32767~-32768
    報表第一行和最后一行
    屏幕光標最左上和最右下
    數組的第一個和最后一個
    循環的第0、1、倒數第一、倒數第二次
    決策表
    適合于問題有多個條件,條件有多種組合執行不同操作(有很多if、else if、else),不能表達循環結構
     
    最嚴格、最具有邏輯性
     
    判定表
    | 條件樁 | 條件項 | ... | 動作項 |
    | 動作樁 | 動作項 | ... | 動作項 |
    1
    2
    3
    規則:條件的任意組合,判定表中的一列(貫穿條件項和動作項)。判定表有多少列就代表有多少條規則。
     
    規則的化簡:有的規則相互包含,可以化簡
     
    因果圖
    找出所有的原因,找出結果,可能還有中間結果的產生,在畫因果圖時注意。
     
    從輸入考慮 
    I:連虛線出去,如連到ab,表示ab中至少有一個必須成立
    E:連虛線出去,如連到ab,表示ab不能同時成立
    R:如處于a指向b的虛線三角箭頭上,表示a出現時b也必須出現,不可能一個出現一個不出現
    從輸出考慮 
    M:如處于a指向b的虛線三角箭頭上,表示a為1時b必須為0,a為0時b值不定
    連線:恒等
    ~:非
    ∨:或
    ∧:且
    ci:原因
    ei:結果
    畫出因果圖后,根據圖得到決策表從而得到相應的測試數據:原因節點+中間節點為條件樁,結果結點為動作樁
     
    白盒測試
    邏輯覆蓋
    語句覆蓋->判定覆蓋->判定/條件覆蓋->條件組合覆蓋->路徑覆蓋
          _條件覆蓋/
    1
    2
    語句覆蓋:每條語句執行一次
    判定覆蓋:每個判定分支至少執行一次
    條件覆蓋:每個判定條件應取到各種可能的值
    判定/條件覆蓋:同時滿足判定和條件
    條件組合覆蓋:每個判定條件的每一種組合各出現一次
    路徑覆蓋:每一條可能的路徑至少執行一次
    關系:
     
    條件組合覆蓋>判定覆蓋>語句覆蓋(即如果達到條件組合覆蓋,就達到判定覆蓋和語句覆蓋:如果達到判定覆蓋,就達到語句覆蓋,下面類似理解)。
    條件組合覆蓋>條件覆蓋。
    條件覆蓋不一定包含判定覆蓋、語句覆蓋。
    判定覆蓋不一定包含條件覆蓋。
    路徑覆蓋,判定覆蓋>語句覆蓋。
    基本路徑測試
    基于程序圈復雜度產生的測試方法,畫出控制流程圖,算圈復雜度,找到獨立路徑并壓縮為基本路徑集合,根據集合中每條路徑設計用例。把復合邏輯表達式拆成單個表達式
     
    圈復雜度用于計算程序的基本的獨立路徑數目(每條新的獨立路徑都必須包含一條新的有向邊,從入口到出口互不相同的路徑數)
     
    圈復雜的V(G) = e - n + 2p【邊-節點+2*連接區域數,連接區域p通常為1】=P+1【判定節點數+1】
    一般來說,一個單元模塊的最大復雜度V(G)<10
    如果把覆蓋的路徑數壓縮到一定限度內,例如程序中的循環體只執行0次和1次,就成為基本路徑測試,通過導出基本路徑集合,從而設計測試用例,保證這些路徑至少通過一次
     
    基于數據流的測試
    基于真的數據定義到數據的使用來進行測試,需要找到定義的節點(包括賦值的和比較的)和使用的節點(Copyright © https://blog.csdn.net/s_gy_zetrov. All Rights Reserved)
     
    定義節點DEF:輸入語句、賦值語句、循環語句和過程調用;變量的值會發生變化的語句
    使用節點USE:數出語句、賦值語句、條件語句、循環控制語句、過程調用
    需要找到所有這段功能代碼從哪里開始定義,到哪里開始執行,把路徑找出來。什么是定義使用路徑(某一變量在最初節點定義到最終節點被使用)、定義清除路徑(某一個變量從它的定義節點到使用節點這個過程中沒有對這個變量進行二次定義)
     
    循環測試
    前提是程序是結構化的。
     
    簡單循環測試
     
    0次通過循環
    1次通過循環
    2次通過循環
    m次通過循環(m<=循環最大次數)
    m-1,m,m+1次通過循環
    測試的過程
    單元測試
    單元測試的內容:5點(簡答題)
     
    模塊接口的測試
    局部數據結構的測試
    獨立路徑測試
    錯誤處理測試
    邊界測試
    單元測試的模塊
     
    被測模塊:被測試的程序的模塊
    驅動模塊:用來模擬測試模塊的上一級模塊,相當于被測模塊的主程序
    樁模塊:用來模擬被測模塊工作過程中所調用的模塊
    單元測試的工具:Junit相關的概念:以插入斷言的方式進行測試(類似黑盒測試)
     
    針對被測代碼或者被測的功能點先創建測試類,然后在類里面創建一個個測試方法。通過實例化對象調用被測方法,用斷言進行實際值預期值比較。
    單元測試的方法
     
    以白盒測試法為主(覆蓋),先靜態檢查代碼是否符合規范,再動態運行代碼,檢查結果。除了需要驗證結果是否正確,還需要檢查程序的容錯能力、邊界值處理等問題。
    集成測試
    一次性的集成big-bang:把所有通過了單元測試的模塊按設計要求一次全部組裝起來,然后進行整體測試。時間隨變短了但急于求成。
    漸進地集成 
    自上而下:從主程序模塊開始按深度或廣度優先策略邊組裝邊測試
    自下而上:從最底層模塊開始組裝和集成測試
    漢堡包:兩者進行結合,樹狀圖每層畫線,頂層采用自頂向下,底層采用自底向上 
    相鄰的集成:上下三層進行集成 
    成對集成:先成對再相鄰 
    基于MM路徑的集成:MM路徑不是可執行路徑,描述單元之間的控制轉移。
    最終得到調用圖,然后就會到基本路徑測試,找復雜度,找路徑,得到測試用例的套路
     
    系統測試
    黑盒為主
     
    對哪些內容進行系統測試(9個):易用性、國際化本地化、性能、功能、界面、兼容性、安全性、文檔、安裝
     
    Web系統測試
    具體到如Web系統測試中的功能測試包含哪些內容、對cookies里面的內容進行測試屬于Web系統測試里面的哪一項的測試(屬于功能測試)
     
    功能測試 
    頁面內容測試
    頁面鏈接測試
    表單測試
    Cookies測試、Session測試
    設計語言測試
    數據庫測試
    性能測試(負載/壓力) 
    連接速度測試
    測試工具 LoadRunner 
    負載測試
    壓力測試
    網頁性能Firefox插件:Yslow,Findbug,PageSpeed
    Dynatrace檢查網頁性能
    可靠性測試:不間斷測試,看多久不出錯
    用戶界面測試/易用性測試 
    導航測試
    圖形測試
    內容測試
    整體界面測試
    安全性測試
    兼容性測試
    接口測試 
    服務器接口
    外部接口
    錯誤處理
    主要講了性能測試的含義和怎么做,如所涵蓋的含義如壓力測試怎么做、負載測試怎么做等
     
    性能測試是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項性能指標進行測試。 
    時間性能:軟件的一個具體事務的響應時間
    空間性能:軟件運行時所消耗的系統資源
    我讓你背1袋米(輕松)
    我讓你背1袋米,但讓你去操場上跑圈,看多久累倒(吃力)
    我讓你背3袋米去操場跑圈,看多久累倒(極限)
    我讓你背1袋、2袋、3袋、4袋…發現最多背3袋
    負載測試讓被測系統在其能忍受的壓力的極限范圍之內連續運行,來測試系統的可靠性。 
    系統能否處理某個時刻同時訪問Web系統/某個頁面的用戶數量
    超過了這個數量,會出現什么現象?
    在線數據處理的數量
    負載/壓力測試關注什么? 
    驗證系統能否同一時間響應大量的用戶,用戶傳送大量數據時能否響應,系統能否長時間運行。 
    瞬間訪問高峰
    每個用戶傳送大量數據
    長時間使用
    LoadRunner性能測試工具原理:錄制+回放模擬用戶實際操作場景,監控并分析運行結果。
    自動化測試
    錄制+回放+腳本 是主要的方式
     
    常用的自動化測試的工具,哪些種類,每種有什么工具
     
    功能測試工具:QTP
    性能測試工具:LoadRunner 
    寫腳本或者錄制腳本
    使用用戶自定義參數
    場景設計
    產生虛擬用戶的機制:使用控制器,來控制模擬多少用戶。
    使用監聽器,查看測試結果
     
    上一篇:系統運維 下一篇:軟件研發

    AI企業風控平臺

    2019-10-08

    企業財務、人力資源、項目管理、客戶管理AI風險預警/報警/應急指揮 ...
    MORE

    雪亮工程

    2019-10-08

    結合鄉鎮實際,不斷優化創新,將“雪亮工程”與網格化服務管理工作相結合,探索性地將“雪亮工程”的視頻監控、報警事件、基礎數據 ...
    MORE

    系統信息集成

    2019-10-08

    為公安、檢察院、法院、大學、交通等領域提供信息系統建設、包括網絡、軟硬件建設以及整體信息系統集成管理服務 ...
    MORE

    系統運維

    2019-10-08

    IAAS平臺的運維,保障IAAS平臺服務的穩定性和可用性;對現有的運維架構進行優化和建設;參與DevOps自動化運維平臺的建設;服務器LINUXCEN ...
    MORE

    軟件測試

    2019-10-08

    測試需求分析和文檔審查 → 設計測試計劃,并進行同行評審 → 測試設計(用例編寫,測試腳本編寫,開發,測試場景的編寫)并進行同行 ...
    MORE

    掃描二維碼分享到微信

    在線咨詢
    聯系電話

    17340186875

    彩票360