2 测试方法与理论 - 软件测试
生活随笔
收集整理的這篇文章主要介紹了
2 测试方法与理论 - 软件测试
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
軟件測試所有內容筆記正在陸續更新中，筆記已經在本地記錄，全部為自己手動記錄的筆記及總結，正在開始更新中，后續會逐步更新并完善到 軟件測試學習內容總結 專欄。
本節內容：測試方法與理論基礎知識。
文章目錄
- 1 軟件開發流程
- 軟件
- 軟件開發流程的演變
- 瀑布模型
- 敏捷模型
- DevOps
- 2 項目管理與跨部門溝通協作
- 項目管理
- 軟件項目管理的方法
- 跨部門溝通協作
- 3 測試流程體系
- 1. 軟件測試基本概念
- 軟件測試
- 軟件測試作用
- 軟件測試原則
- 軟件測試對象
- 測試用例
- 2. 軟件測試模型
- V模型
- W模型
- H模型
- 3. 軟件測試工作流程
- 傳統測試流程
- 系統測試流程
- Bug管理流程
- 4. 測試左移和測試右移
- 測試左移
- 測試右移
- 4 測試技術體系
- 1. 軟件測試分類
- 2. 分層測試體系
- 單元測試方法
- 接口測試方法
- UI測試方法
- 5 常用測試平臺
- 1. 測試用例管理與bug管理平臺
- 測試用例管理平臺 --jira
- bug管理平臺
- 2. 代碼管理平臺 --gitlab
- 3. 流程管理平臺
- 持續集成管理平臺 --jenkins
- 持續集成與持續交付
- 6 黑盒測試方法論
- 常用測試方法
- 等價類
- 邊界值
- 因果圖與判定表
- 決策樹
- 探索式測試
- 7 白盒測試方法論
- 白盒測試的度量
- 代碼覆蓋率常見概念
- 覆蓋率統計的工具
- 流程覆蓋
- 精準化測試
- 8 測試經典書籍拆分講解 5分鐘
- 1. 全程軟件測試
- 2. 探索式測試
- 3. Google軟件測試之道
- 4. 持續交付
- 5 不測的秘密
1 軟件開發流程
-
軟件
與計算機系統操作有關的計算機程序、可能的文件、文檔及數據。
-
軟件開發流程的演變
傳統瀑布模型 --> 敏捷開發模型 --> DevOps開發模型
瀑布模型
- 瀑布模型優缺點
敏捷模型
-
XP
-
SCRUM
-
敏捷開發總結
- 增量迭代
- 小步快跑
DevOps
-
DevOps 生命周期
-
DevOps 對發布的影響
- 減少變更范圍
- 加強發布協調
- 自動化
-
持續集成 CI/持續交付 CD
-
CD與DevOps的關系
從 CI_CD 到 DevOps
CI/CD 是一種在應用開發階段通過自動化的方式，頻繁向客戶交付應用的方法，其核心概念是持續集成、持續交付和持續部署。CI/CD 可以讓持續的自動化與監控貫穿整個生命周期，覆蓋從集成到測試再到交付與部署，與之相關聯的事務通常被統稱為“CI/CD 管道”，具體實施則由開發和運維團隊以敏捷開發的方式協作。
https://my.oschina.net/u/4868096/blog/5233761
2 項目管理與跨部門溝通協作
-
項目管理
-
軟件項目管理的方法
- 制定項目計劃
- 執行該計劃并監控跟蹤管理
- 項目風險應對與問題解決
- 項目收尾
-
跨部門溝通協作
-
與產品溝通
- 需求評審會
- 在分析需求階段
- 在測試用例編寫階段
- 在測試過程中
-
與研發溝通
- 在分析需求階段
- 在測試用例編寫階段
- 在測試過程中
- 在線上監控發現bug時
-
上下游配合測試
- 測試計劃溝通
- 環境對接
- 熟悉業務
-
-
項目實例
3 測試流程體系
1. 軟件測試基本概念
-
軟件測試
- 通過手工或者工具對“被測對象”進行測試
- 驗證實際結果與預期結果之間是否存在差異
-
軟件測試作用
- 通過測試工作可以發現并修復軟件當中存在的缺陷，從而提高用戶對產品的使用信心。
- 測試可以降低同類型產品開發遇到問題的風險。
-
軟件缺陷
- 軟件缺陷被測試工程師和開發工程師們稱作bug
- 軟件缺陷會導致軟件不能正常運行，它的存在會在一定程度上導致軟件不能滿足用戶的需求，甚至有可能破壞或泄露用戶的重要數據
-
軟件測試原則
- 測試顯示缺陷的存在
- 窮盡測試是不可能的
- 測試盡早介入
- 缺陷集群性（2/8原則）
- 殺蟲劑悖論
- 測試活動依賴于測試內容
- 沒有錯誤是好是謬論
-
軟件測試對象
- 需求分析階段：需求文檔、接口文檔
- 編碼實現階段：源代碼
- 系統功能使用：軟件程序
-
測試用例
- 為特定的目的而設計的一組測試輸入、執行步驟和預期的結果，以便測試產品是否滿足某個特定需求的文檔
2. 軟件測試模型
-
V模型
- V模型是瀑布模型的一種改進
- V模型標明了測試過程中的不同階段
-
V模型的優缺點
- 優點
- 既有底層測試又有高層測試。
- 將開發階段清楚的表現出來，便于控制開發的過程。
- 缺點
- 容易讓人誤解為測試是在開發完成之后的一個過程。
- 由于它的順序性，當編碼完成之后，正式進入測試時，這時發現的一些bug可能不容易找到其根源，并且代碼修改起來很困難。
- 如果需求變更較大，導致要重復變更需求、設計、編碼、測試。返工量大。
- 優點
-
W模型
- W模型明確表示出了測試與開發的并行關系
- W模型中測試伴隨著整個軟件開發周期，并且測試的對象不僅僅是程序，需求和設計同樣要測試
-
W模型的優缺點
- 優點
- 將測試貫穿到整個軟件的生命周期中，且除了代碼要測試，需求、設計等都要測試。
- 更早的介入到軟件開發中，能盡早的發現缺陷進行修復
- 測試與開發獨立起來，并與開發并行
- 缺點
- 無法支持迭代的開發模型
- 對有些項目，開發過程中根本沒有文檔產生，故W模型無法使用
- 對于需求和設計的測試技術要求很高，實踐起來很困難
- 優點
-
H模型
- 軟件開發中需求、設計、編碼等活動被分階段執行、但是實踐中，他們并不是完全串行的，他們之間更多時候是交叉進行的，更多的事迭代執行
- 把測試活動完全獨立出來，形成一個完全獨立的流程，將測試準備活動和測試執行活動清晰地體現出來
-
H模型的優缺點
-
優點
- 軟件測試完全獨立，貫穿整個生命周期，且與其他流程并發進行
- 軟件測試活動可以盡早準備、盡早執行，具有很強的靈活性
-
缺點
- 測試就緒點分析困難
- 對于整個項目組的人員要求非常高
-
3. 軟件測試工作流程
-
傳統測試流程
-
系統測試流程
-
Bug管理流程
4. 測試左移和測試右移
-
測試左移
- 左移是往測試之前的開發階段移
- 測試團隊在軟件開發周期早期就開始介入
- 對代碼進行測試
- 從發現 bug 到預防 bug
-
測試左移-質量保障手段
- 代碼評審（code review）
- 代碼審計
- 單元測試
- 自動化冒煙測試
- 研發自測
-
測試右移
- 右移是往發布之后移
- 產品上線后進行線上監控
-
測試右移-線上監控
- 閉環的線上問題反饋-檢查-解決-更新流程
- 更便捷的日志查看、回傳服務
- 豐富有效的log，便于問題的快速定位
- 豐富的監控指標（例如業務異常點指標）
- 業務監控（例如短信發送等）
- 關鍵指標每日監控（服務器指標）
- 生產數據監控（警報）
4 測試技術體系
1. 軟件測試分類
按開發階段分類
-
系統測試分類
-
驗收測試分類
按是否查看代碼
- 黑盒測試
- 白盒測試
2. 分層測試體系
- 自動化分層測試體系
- 70% 單元測試
- 20% 服務測試
- 10% 用戶界面測試
-
單元測試方法
- Java
- JUnit
- TestNG
- Python
- unittest
- pytest
- Java
-
接口測試
- 接口全程Application Programming Interface，一般稱作API
- 是針對軟件對外提供服務的接口的輸入輸出進行測試
- 檢查接口參數傳遞的正確性，接口功能實現的正確性，輸出結果的正確性，以及對各種異常情況的容錯處理的完整性和合理性
-
接口測試方法
- Charles、Fiddler
- postman
- Jmeter
- loadRunner
- python：Requests、HttpRunner
- Java：HttpClient、RestAssured
-
UI測試方法
- 手工方法：人工查看、操作
- 自動化方法
- web：selenium
- app：appium
5 常用測試平臺
1. 測試用例管理與bug管理平臺
-
測試用例管理平臺 --jira
- jira：推薦方案、定制型很強 --大企業，收費
- redmine：推薦方案，開源，活躍，定制型很強 --中小企業使用
- testlink：流行的測試用例管理平臺，體驗不太好
- 其他：tapd、云效、禪道、gitlab、在線協作文檔
- 無協作模式：Excel、思維導圖
-
bug管理平臺
- 通常與用例管理平臺一致
- 測試用例、bug都可以使用issue表達
- 關聯關系設定
- 測試用例與bug的屬性設定
2. 代碼管理平臺 --gitlab
- 代碼管理平臺
- gitlab：可本地部署的git代碼管理平臺，行業標準
- subversion：SVN管理，已經過時
- github：開源項目運作
- bitbucket：與jira同屬一家公司altassian
3. 流程管理平臺
-
持續集成管理平臺 --jenkins
- jenkins：持續集成與持續交付的主流平臺
- gitlab runner：gitlab的持續交付方案
- github action：GitHub的開源方案
- 自檢devops平臺：企業定制平臺、tapd、云效等
-
持續集成與持續交付
- 研發
- 構建、單元測試+覆蓋率分析
- 自動化代碼審計
- 運維：自動化部署
- 測試
- 接口測試
- UI自動化測試
- 專項測試自動化
- 性能測試、安全測試
- 研發
6 黑盒測試方法論
-
常用測試方法
- 等價類劃分
- 邊界值分析
- 因果圖
- 判定表
- 決策樹
- 探索式測試
-
等價類
- 輸入域明確：把程序的輸入域劃分成若干子集
- 分類：從每個部分中選區少數代表性數據作為測試用例。每一類的代表性數據在測試中的作用等價與這一類中的其他值。
- 常見分類：有效、無效等價類
-
等價類劃分案例
-
用戶名測試例子
-
邊界值
- 根據經驗大多數的錯誤都是來自于對邊界值的處理不嚴謹，所以把邊界值作為重點測試數據
- 邊界值測試法是對等價類的補充
-
用邊界值測試法補充測試用例
-
因果圖與判定表
-
判定表概念
- 一種表達因果關系的邏輯表達方式
- 使用表格分類條件、中間結果、最終結果之間的關系
-
判定表例子
-
決策樹
- 判定表也可以用決策樹表示
- 決策樹比因果圖和判定表更好
- 可以用流程圖表示決策樹
-
因果圖、判定表、決策樹
- 這三者本質一樣用于表達流程關系，只是表現形式不同
- 他們的含義其實就是編程邏輯 if else switch
- 測試過程中可以用流程圖去表達
- 黑盒的流程圖與白盒的路徑流程是存在關聯關系的
-
探索式測試
-
探索式測試的認知
- 探索式測試是一種基于上下文質量反饋的測試風格
- 基于上進下文的反饋，適時調整測試執行
- 探索式測試通常被認為是黑盒測試技術。在白盒測試中也可以應用類似的思想去實施（基于實時反饋的精準化測試）
-
探索式測試的優缺點
- 成本低，可以不用提前設計大量測試用例
- 可以激發測試工程師的創造性，更快的發現問題
- 對測試的覆蓋度無法進行有效保障
- 多數測試活動都是由探索式測試與腳本式用例結合
7 白盒測試方法論
-
白盒測試的度量
- 根據待測產品的內部實現細節來設計測試用例
- 白盒測試的執行手段是可以涵蓋單元測試、集成測試
- 使用代碼覆蓋率作為白盒測試的主要度量指標
-
代碼覆蓋率常見概念
-
覆蓋率統計的工具
- emma
- cobertura
- jacoco
-
插樁原理
-
JACOCO覆蓋率報告
-
流程覆蓋
-
精準化測試
- 代碼調用鏈與黑盒測試用例的關聯
- 根據代碼變更自動分析影響范圍
- 黑盒測試過程中借助代碼流程覆蓋數據指導探索式測試
- 利用線上數據推導有效測試用例
- 代碼流程分析與覆蓋率統計
8 測試經典書籍拆分講解 5分鐘
1. 全程軟件測試
2. 探索式測試
3. Google軟件測試之道
4. 持續交付
5 不測的秘密
總結
以上是生活随笔為你收集整理的2 测试方法与理论 - 软件测试的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： SCOM Rule 介绍 [SCOM中文
- 下一篇： html生物代码,方舟生存进化全生物代码