軟件測試 入門理論丶

 

 

一：軟件測試的定義：根據用戶需求行業規範，採用一些測試方法或一些工具對被測系統（程序數據文檔）進行相應的測試（審覈，運行，評估），儘早儘快的發現軟件問題，提高軟件的質量。

 

二：軟件測試的生命週期：

第一階段：問題的定位與規劃階段    

第二階段：需求分析階段   

第三階段：軟件的設計階段（概要設計，詳細設計）

第四階段：軟件編碼階段   

第五極端：軟件測試階段   

第六階段：運行與維護階段 

 

三：軟件測試的需求   需求規格說明書（產平經理編輯）：收集客戶的反饋，市場人員的調研，收集市場需求，和市場人員溝通，業內需求（行業規範，功能需求）

      爲何都要造成文檔：項目管理的須要

      做用：描述客戶對於軟件的指望和要求

      供你們評審：需求有沒有錯誤或不一致，需求是否能夠測試，進一步理解用戶的需求，爲後續的測試做準備第一階段：需求分析

      需求分析：

1：學習需求，充分理解需求   

2：找出需求中的問題（模糊不清，有歧義），如需求文檔已經發布或測試已經開始執行提交文檔bug單的狀況 （二者瞞住一個就須要提文檔bug單）

3：準確評估測試點和工做量（爲寫用例奠基基礎）   

 

四：軟件測試的分類：

技術劃分   

-白盒測試；（針對單元測試）對內部代碼邏輯進行測試，關注輸出對於輸入的正確性   

-灰盒測試：（針對集成測試）基於白盒與黑盒之間   

-黑盒測試：（針對系統測試）依據需對求程序的多面處進行測試經過軟件的外部表現來發現其缺陷。

                   

狀態劃分   

1：動態 - 手工，自動化，半自動化

2：靜態 -文檔評審（雪球評審，設計評審，測試文檔（猜想是計劃，用例，報告），用戶手冊）

             -代碼走查：開發人員之間相互閱讀代碼檢查代碼是否符合編程規範   注：代碼走查發現的問題比單元測試的多

                      

階段劃分   

1：單元測試：根據系統設計文檔，主要測試程序的源代碼和內部邏輯，力度最小，通常是開發小組採用百合測試 

                    注：不關注代碼是否符合編程規範

                                     

 2：集成測試：依據系統設計文檔和需求文檔，屬於單元測試和（確認測試）系統測試之間起到橋接的做用  

                    單元測試以後進行，由開發小組運用灰盒測試技術進行測試 

                    即驗證內部代碼邏輯又關注需求實現（跑通基本功能不會像系統測試那樣驗證多種異常場景）

                                     

3：確認測試：依據需求文檔，在集成測試後，經過集成測試以後，軟件已徹底組裝起來，接口方面的錯誤也已排除，

                    確認測試便可開始。   

                    確認測試應檢查軟件可否按合同要求進行工做，便是否知足軟件需求說明書中的確認標準。

 

4：冒煙測試：進行時間：新版本發佈後   測試內容：對軟件的基本功能點的流程測試確保經過冒煙（軟件可否跑起來）   

                                     

5：系統測試：依據需求文檔，粒度最大，通常由獨立測試小組採用黑河測試驗證多種場景下功能是否符合課採用手工或自動化

         -包括：

                 功能測試-對產品的功能進行驗證，根據測試用例逐項進行驗證                                               

                 性能測試- 測試軟件處理業務的速度（同時併發，同時在線）

                 壓力測試-系統正常運行的極限狀態

                 健壯性測試-異常狀況下軟件正常運行的能力（包括容錯力和恢復力）

                 可靠性測試-長時間的運行看軟件有沒有問題（如手機用長了會卡頓）   

                 安全性測試-指軟件防止非法入侵的能力（屬於技術問題也屬於管理問題）

 

6：探索性測試：天馬行空的的設計和執行測試用例，利用軟件程序所提供的信息只有發揮，沒有限制不受任何條件的約束的探索程序的各類功能      

                                     

7：alpha和beta測試：

                   alpha：（內測）在受控制環境下進行的測試，技術人員會在現場

                    beta：（公測）開發者一般不在測試現場,於是開發者沒法 控制測試現場

                       注：通常應用於大型公用軟件，沒有具體用例，這兩種測試都是從實際終端用戶角度出發對軟件功能和性能進行測試

 

8：迴歸測試：1：bug修復後且在新的測試版本發佈後須要進行迴歸測試

                    2：bug修復後的迴歸測試在交付前須要進行全量用例迴歸的測試也叫（頂版測試）

                        確保BUG修改後有沒有引入新的bug致使其餘部分有沒有產生錯誤

 

9：驗收測試：驗收測試與系統測試很是類似主要區別是驗收測試是由客戶或用戶執行

 

五：測試工做的開展

測試啓動準則：

1：需求已經就緒，測試計劃制定並經過審覈   

2：用例已經設計完並經過審覈 

3：測試的對象已經開發完等待測試

4：測試環境已經搭建，測試數據準備好了

測試結束準則:

1：產品經過驗收測試且用例覆蓋率，用例執行率，用例經過率都達到相應的指標 

2；出現的問題得以修復且再次執行用例沒有新的問題出現   

3：項目規劃時間到期，測試用例執行完成（覆蓋率達到多少），bug出現收斂

 

基於測試用例的準則

基於缺陷密度的準則則

基於試運行期間缺陷密度

 

六：傳統測試流程

第一階段：需求分析

• 1：學習需求，充分理解需求（瞭解項目的整個實現背景，挖掘隱藏需求）
• 2：分析需求的合理性，找出需求中的問題（模糊不清，有歧義）
• • 1：功能描述不清晰的
  • 2：有歧義的
  • 3：文字表述錯誤的
  • 4：‘多’‘等’‘長時間’等模糊字眼
  • 5：需求重複的
  • 6：一些模棱兩可的描述
  • 7：先後功能衝圖
  • 8：潛在性需求可提出（爲了產品質量更好，若是是客戶定製的那麼客戶更加滿意）
  • 9：異常操做需求可提出（是做爲軟件系統基本的邏輯異常問題處理機智）
• 3：準確評估測試點和工做量（爲寫用例奠基基礎）
• 4：熟悉業務
• 5：羅列出個功能點
• 6：記錄評審的問題，便於跟蹤問題
• 7：對設計方案看能不給出比較好的建議

第二階段：制定測試計劃：

• why（什麼）---什麼項目   爲什們進行測試
• what（在那一反面）---測試那些方面（不一樣階段的測試內容）
• when（什麼時間）---測試不一樣階段的起止時間（開始和結束，里程碑）
• where（在什麼地方）---相應文檔，缺陷存放在什麼位置，測試環境等
• who（誰；什麼人）---項目相關人員，安排那些人員進行測試
• how（如何作）---（測試方案技術層面）如何去作，使用那些工具以及那些方法進行測試
• 計劃做用：在測試以前編寫的，是用來指導測試行爲的（管理層面的）

第三階段：測試設計階段（寫用列）

• + - 黑盒測試的特色：
  • 黑盒測試只有採用窮舉時輸入測試，把全部可能考慮到，實際上測試有無窮多個，徹底測試是不可能的
• + - 測試用例概述：
  • 測試用例的定義：設計一種狀況（輸入數據）軟件在種場景下可以正常運行而且達到指望執行結果則經過如不能正常運行並且重複發生，那多是一個軟件缺陷
  • 軟件測試過程管理：軟件測試是軟件質量管理中最實際的行動，同時也是耗時最大的一項工做（組織，步驟，計劃的開展）（量化，測試用例是具體的量化行爲之一）
• 測試用例設計方法：
  • 等價類
    • 有效等價類：規範有意義，合理的輸入
    • 無效等價類:不合理或無心義的輸入
  • 邊界值
    • 邊界值法：以邊界狀況的處理做爲主要目標專門設計測試用例額的方法
    • 邊界點
      • 上點：邊界上的點
      • 內點：區間內的點
      • 離點：離上點最近且不與上點爲同一等價類的點
  • 錯誤推敲法
    • 單元測試時列出在模塊中常見的錯誤在模塊
    • 之前產品中曾經發現的錯誤
    • 產品在客戶實用過程當中發現的錯誤
    • 整體體發生錯誤的狀況
    • 一些公共的模塊
    • 修復了bug功能和模塊
  • 因果突圖法
    • 概述：
      • 分析需求規格說明書哪些是緣由哪些是結果
      • 選擇條件以及對應的結果
    • 使用範圍：1：多輸入的狀況下條件沒有順序性
    • + - 基本步驟
      • 1：分析哪些是緣由哪些是結果
      • 2：分析描述語義的內容，並將其表示成鏈接各個緣由與各個結果的因果圖
      • 3：把因果圖圖寫成斷定表
    • 斷定表(合併類似的內容
      • 條件樁；列出了問題的全部條件
      • 條件項；列出特定條件的的取值
      • 動做樁；列出問題規定可能採起的全部操做
      • 動做項：各類取值條件下應該纔去的的動做
  • 正交法（PICT工具）
    • + - 1：在安裝PICT的目錄中新建一個txt文件並把須要組合的參數輸入進去
      • 賬戶名: 空,不存在,超長,超短,正常
      • 密碼: 空,超長,超短,不匹配,正常
      • 驗證碼: 空,超長,超短,不匹配,正常
    • 2：打開開cmd進入pict的目錄內  執行命令：pict  參數文件  (可在命令增長文件保存的路徑)
  • 場景法
    • 概述;：運用場景對系統發生的功能或業務流程進行描述，從而列出出問題的一種方法  /   模擬特色場景發生的事情事件來觸發某個動做的發生，觀察最終結果，從而來發現軟件的存在問題
    • 場景法的路徑：基本流（用戶的正常操做）和備選流（基本流之外一系列的異常操做）在基本流和備選流的 過程當中能夠採用前面的等價值和邊界值，因果圖法等從而達到各類測試方法的融合。
    • + - 設計方法
      • 1描述基本流和各項備選流
      • 2根據基本流備選流生成測試場景
      • 3對每個場景生成測試用例
        • 1：首先進行等價類劃分
        • 2：再進行邊界值的劃分
      • 4複審用例，去掉多餘的用例，對每個測試用例肯定測試數據值（注：簡單的用列能合併就合併）
    • 是測試使用最多的方法，策略：先對於項目測試先使用用場景法進行測試並進行場景法編寫用例，儘量在場景法裏面融合其餘方法，對於輸入框，能夠編寫單獨的用例進行進一步策測試
• 用例例格式基本要素：
  • 1用例編號
  • 2測試項目
  • 3測試標題
  • 4級別（優先級）
    • 越基礎的功能和用戶經常使用的優先級越高，複雜異常的低
  • 5預置條件
  • 6操做步驟
  • 7預期輸出
  • + - 8測試結果
    • pass：表現與預期一致
    • falt：與預期不同
    • NA：功能未完成/環境不支持/沒有工具
    • block：有bug阻塞（備註阻塞bug的ID）
  • 9測試者
  • 10測試時間
  • 11：備註
• 需求不明確如何寫用例：
  • 1：能夠去問下開發看看開發如何去描述的
  • 2：能夠參考一下同類競品
  • 3：有經驗的話根據我的經驗
  • 4：還能夠請教領導
• 測試用例的做用：
  • 1避免盲目測試使測試重點突出目的明確，軟件更新後只須要修改少部分測試用例
  • 2:通用化和複用化使軟件測試易於開展，有助於不斷改進工做。
  • 3時間緊迫的話能夠分清重點。 是測試工做的見證
• 測試用例的維護：
  • 及時更新，及時補充，及時修改，刪除冗餘的用例
• + - 如何保證測試用例對需求的覆蓋：
  • 1：測試需求的獲取分爲兩步
    • 顯式需求
      • 原始需求說明書
      • 產品規格說明書
      • 軟件需求文檔
      • 通用的協議規範
      • 有無繼承性文檔
      • 經驗庫有無課借鑑的
    • 隱性需求
      • 用戶的主觀感覺
      • 市場的主流觀點
      • 專業人士的評價
  • 2：將不一樣的需求產生一個個需求點
    • 界定需求點的範圍
    • 利用各類測試設計方法產生不一樣的測試點
  • 3：需求有變更及時更新用例
  • 4：經過用例評審，團隊人員一塊兒討論補充和完善
  • 5：用例執行階段保證100%執行率，對新增的需求及時補充用例
  • 6：將測試的需求，測試的用例，發現的bug關聯起來，便於管理和跟蹤，同時也便於查看需求覆蓋率

第四階段：測試（系統測試）執行階段——提bug

• 執行前（冒煙測試/確認測試）
• + - 執行中（提交缺陷）
  • + - 1軟件缺陷的定義
    • 軟件未實現產平說書要求的功能明
    • 軟件出現了產品說明書指明不該該出現的錯誤
    • 出現了產品說明說未提到的功能
    • 軟件沒有實現產品說明書雖未明確說起但應該實現的目標功能
    • 軟件難以理解，不易使用  運行速度慢，或者軟件測試員人爲用戶會認爲很差的地方
  • + - 2軟件缺陷報告的原則
    • 儘早報告軟件缺陷。有效描述給出說明問題的一系列明確步驟（對事不對人）
    • 對軟件缺陷報告跟蹤到底（天天到公司先看下bug狀態，監視其修復全過程）
    • 每一個報告只針對一個缺陷
  • + - 3軟件缺陷報告描述
    • 缺陷ID
    • 缺陷狀態
    • 缺陷標題
    • 缺陷的詳細描述
    • 缺陷的嚴重程度
    • 缺陷的緊急程度
    • 缺陷提交人
    • 缺陷提交時間
    • 缺陷所屬項目/模塊
    • 缺陷指定解決人 解決時間     最終解決人
    • ·缺陷處理結果描述
    • 缺陷結果複覈人
    • 缺陷複合結果描述
    • 測試環境說明
    • 必要的附件（對於某些文職難以描述的結果使用圖片等附件）
  • + - 4軟件缺陷嚴重程度：
    • + - A類-（致命）錯誤致命：系統崩潰，數據丟失，死機，擁塞等
      • 不能執行重要功能
      • 程序硬氣的死機
      • 死循環  數據庫發生死鎖
      • 應錯誤致使的程序中段
      • 與數據庫連接錯誤
    • + - B-較（嚴重）的錯誤（嚴重的影響系統或基本功能的實現且沒有辦法更正
      • 程序錯誤
      • 程序接口錯誤
      • 數據庫的表。業務規則。缺陷值未加完整性等約束條件
    • + - C- 類（通常）描述不清，內容錯別字，易用性差
      • 界面不規範
      • 輔助說明描述不清楚或不描述
      • 輸入輸出不規範
      • 長操做做未給用戶提示
      • 未採用行業術語
      • 可輸入區域和只讀區域沒有明顯區分標誌
    • D-類（輕微）建議優化：建議軟件優化的方面
  • + - 6軟件缺陷的管理
    • 缺陷管理概述：
      • 在軟件的生命週期中識別，管理，溝通任何缺陷的過程，確保軟件跟蹤管理而不丟失
      • 通常須要跟蹤管理工具幫助進行管理（禪道 ，bugzila）
    • 缺陷管理做用：
      • 對bug進行管理，使得相關測試人員能夠經過該系統進行無縫對接，及時交流和溝通而且記錄bug的整個生命週期
  • + - 7軟件缺陷生命週期
    • 發現識別bug——提交bug——分析和定位bug——修改相應的程序處理bug——驗證修改——關閉缺陷——經過分析bug的共性，防止再次發生
  • + - 8軟件缺陷處理流程

    • 流程：識別---新建--編輯----提交---分配（從新分配）---修復---                                                                                   驗證(驗證不經過)---關閉（從新打開）---總結防止bug再次產生      最後進行迴歸測試

• 如何定位BUG？

  • WEB：打開f12，進入開發者模式，再去點擊列表，f12裏面去看 查詢出來的頁面內容，你點擊這個按鈕的時候，他會向後 臺發送請求，類表查詢，能夠從開發者模式頁面查看具體 請求信息和返回的請求報文信息，看Reponse（響應）裏 面，若是返回有數據，數據對的，就是前端的問題，是前端本身沒有獲取到，可是後端是給了你的。

    APP：經過抓包來查看請求或響應數據

• + - 如何找到高質量的bug：
  • 1：充分學習產品的需求，知識和流程
  • 2：充分考慮異常包含邏輯異常，甚至開發設計中的異常
  • 3：充分了解客戶需求，客戶使用場景，客戶使用流程，多從客戶角度出發
• + - 如何提交高質量的bug：
  • 1：發現bug先確認不是本身的誤操做
  • 2:：記錄bug出現的步驟和保留現場（必要時提供日誌和現象截圖）
  • 3：最後提交bug（達到下面要求）
  • a：準確——每一個組成部分描述準確
  • b：清晰——描述清晰，易於理解
  • c：簡潔——只包含必要的信息
  • d：完整——復現bug的完整步驟和其餘本質信息
  • e：一致——按照一致的格式書寫缺陷報告
• + - 什麼是高質量的bug：
  • a：影響功能的
  • b：迄今爲止都未被發現的
  • c：形成影響比較大的bug
• + - bug漏測如何處理？
  • 1：對漏測的緣由進行分析，和自我反省
  • 2：對漏測的bug進行歸類，尋找彌補的方法
  • 3：對這次行爲進行總結檢討
• + - 提交的bug開發拒絕了怎麼辦：
  • 第一步：首先在bug系統備註溝通（如承認開發的觀點則關閉）——來回溝通屢次
  • 第二步：直接找開當面溝通（把我認爲是bug的理由和須要的證據給他看）——還不認可是bug
    • 告訴開發這個問題被客戶發現後產生的影響和後果
  • 第三步：找本身的領導和產品經理說明狀況（對事不對人）——若是還未解決
  • 第四步：開會討論（通常找了領導就會出結果）
• + - 對於難以重現的bug該怎麼辦？：
  • 一、盡力去查找出錯緣由，好比有什麼特別的操做或特定的環境和數據
  • 二、在測試報告中詳細描述測試操做步驟，bug發生的症狀，bug發生的具體環境描述，這樣對於再次重現有必定的參考做用
  • 三、沒法重現的bug嘗試屢次，再次出現後能夠直接叫程序員過來看
  • 四、沒法重現的嚴重bug，由於概率緣由，重現不了或難以重現的不表明沒有發生，能夠嘗試屢次，寫下發生的機率。開發對程序比測試熟悉的多，及時沒法重現，程序員也需會了解問題所在
• + - 測試時很難發現bug怎麼辦？
  • 第一種正常執行用例
    • 1：若是測試的人只有我一個的時候，看測試的版本是開發中的仍是已經上線的，若是是開發中的未上線的版本，未發現bug就要引發注意了，畢竟大部分狀況是能發現bug的。
    • 2：若是測試的人不止你一我的的時候，看看其餘人是否能發現bug——分組討論

      • 場景一、若是測試的bug很少，那說明軟件質量應該還不錯， 測試不出來bug 也不要着急，

        場景二、其餘人可以發現bug，可是你發現不了， 這個狀況就要去思考，你的測試方法是否是不對， 你對需求是否理解到位，是否還有遺漏， 仔細分析下其餘人發現的bug是否在本身負責的模塊存在，這時須要：測試人員需突破思惟定勢,打破常規須要補充新的測試用例.尤爲須要補充一些覆蓋無效等價類的測試用例.

  • 第二種狀況：
    • 第二種狀況：新人到公司， 爲了讓新人儘快熟悉業務，會讓新人跑跑 測試用例， 這個時候測試的模塊通常都比較成熟了，或者可能都已經上線了， 發現不了bug很正常

第五階段：測試評估階段

• 1：撰寫測試報告：
  • 1：測試的模塊
    • （模塊開始和結束的測試時間）
    • （設計的用例數和執行數）
    • （用例經過多少失敗多少）
    • （有多少bug，已解決多少bug）
    • （遺留的問題）
  • 2：彙報一下大體的結果
  • 3：遺留問題和風險說明
  • 4：評估是否符合上線標準
• 經過：上線
• 不經過：打會修改字後重測

   

七：敏捷測試流程

H模型  有什麼就測就測什麼，體現的軟件測試儘早開始   

H模型中：軟件測試過程活動徹底獨立,貫穿於整個產品的週期,與其餘流程併發地進行,某個測試點準備就緒時,就能夠從測試準備階段進行到測試執行階段。

軟件測試能夠儘早的進行,而且能夠根據被測物的不一樣而分層次進行   

 

八：企業測試人員組織

企業測試人員組織

• 條件特別好的  1：1
• 條件比較好的  有獨立的測試團隊服務於多個開發
• 條件通常的 到達系統測試測試階段外面調配測試人員加本公司開發一塊兒測
• + - 條件差的沒有專門的測試人員
  • 需求：業務，學習以前的bug單
  • 搭建測試管理系統（禪道，項目軟件搭建運行經過運行軟件進一不步瞭解）
  • 編寫用例，執行，文檔化
• + - 測試工程師的分類：
  • 系統測試工程師
  • 性能測試工程師
  • 自動化測試工程
  • 測試開發工程師