?

?

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

?

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

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

第二階段：需求分析階段? ?

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

第四階段：軟件編碼階段? ?

第五極端：軟件測試階段? ?

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

?

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

? ? ? 為什么都要形成文檔：項目管理的需要

? ? ? 作用：描述客戶對于軟件的期望和要求

? ? ? 供大家評審：需求有沒有錯誤或不一致，需求是否可以測試，進一步理解用戶的需求，為后續的測試作準備第一階段：需求分析

? ? ??需求分析：

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該怎么辦？：
  • 1、盡力去查找出錯原因，比如有什么特別的操作或特定的環境和數據
  • 2、在測試報告中詳細描述測試操作步驟，bug發生的癥狀，bug發生的具體環境描述，這樣對于再次重現有一定的參考作用
  • 3、無法重現的bug嘗試多次，再次出現后可以直接叫程序員過來看
  • 4、無法重現的嚴重bug，因為幾率原因，重現不了或難以重現的不代表沒有發生，可以嘗試多次，寫下發生的概率。開發對程序比測試熟悉的多，及時無法重現，程序員也需會了解問題所在
• + - 測試時很難發現bug怎么辦？
  • 第一種正常執行用例
    • 1：如果測試的人只有我一個的時候，看測試的版本是開發中的還是已經上線的，如果是開發中的未上線的版本，未發現bug就要引起注意了，畢竟大部分情況是能發現bug的。
    • 2：如果測試的人不止你一個人的時候，看看其他人是否能發現bug——分組討論

      • 場景1、如果測試的bug不多，那說明軟件質量應該還不錯， 測試不出來bug 也不要著急，

        場景2、其他人能夠發現bug，但是你發現不了， 這個情況就要去思考，你的測試方法是不是不對，?你對需求是否理解到位，是否還有遺漏，?仔細分析下其他人發現的bug是否在自己負責的模塊存在，這時需要：測試人員需突破思維定勢,打破常規需要補充新的測試用例.尤其需要補充一些覆蓋無效等價類的測試用例.

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

第五階段：測試評估階段

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

? ?

七：敏捷測試流程

H模型 ?有什么就測就測什么，體現的軟件測試盡早開始? ?

H模型中：軟件測試過程活動完全獨立,貫穿于整個產品的周期,與其他流程并發地進行,某個測試點準備就緒時,就可以從測試準備階段進行到測試執行階段。

軟件測試可以盡早的進行,并且可以根據被測物的不同而分層次進行? ?

?

八：企業測試人員組織

企業測試人員組織

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

? ? ?

?

?

轉載于:https://www.cnblogs.com/ll1996/p/10253991.html

總結

以上是生活随笔為你收集整理的软件测试 入门理论丶的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。