軟件測試學習筆記-概念篇（一）

時間 2019-11-13

標籤軟件測試學習筆記概念简体版

原文原文鏈接

前言

　　每一個系統的成型，上線都離不開測試，這段時間陸陸續續的學習測試，在這裏總結一番；做爲學習交流之用；html

正文

軟件測試概述

軟件測試的歷史：

什麼是軟件測試：

早期定義：軟件測試是對程序可以按預期運行創建起一種信心。
經典定義：測試是爲了發現錯誤而執行程序的過程。
IEEE定義（ISO/IEC/IEEE 29119）：使用人工或者自動的手段來運行或測量軟件系統的過程，以檢驗軟件系統是否知足規定的要求，並找出與預期結果之間的差別。安全

軟件測試≠程序測試

五大要素和兩個目標：

五大要素有：質量、人員、資源、流程、技術。
其中最主要的是軟件質量，其餘四個要素都是爲質量服務的。
其次是人員，決定了技術，資源，流程，以及配置和使用。
技術包含了：軟件測試技術、軟件測試方法、使用的工具。技術是手段。
流程：測試計劃，測試用例，測試執行，測試報告。有一些進入進出的標準（規範性，對軟件測試作一個規範的要求）。
資源：測試所須要的硬件設備、網絡環境、測試設備、測試時間（週期）。網絡

注意：人不是資源。數據結構

目標：
①提高測試覆蓋率-> 可以有效的保證軟件的質量
②提高測試效率->可以使咱們更好地完成軟件測試併發

軟件測試所遵循的原則

1、測試顯示缺陷的存在，但不能證實系統不存在缺陷。
通過軟件測試，能夠發現軟件中的故障；可是通過軟件測試，不能保證軟件就沒有故障了。
2、窮盡測試是不可能的，應設定及時終止的條件。
3、測試應該儘早進行
框架

4、缺陷具有羣集特性
越是發現問題多的模塊，越是須要重點測試的對象
5、測試的殺蟲劑悖論
在測試中，若是採用一樣的測試用例，一樣的測試方法。屢次重複的測試某一個模塊，最後就不能再發現新的缺陷。因此說，測試用例和測試方法應該不按期的評審修改，而且增長不一樣的測試方法和用例來測試不一樣的部分，從而更多的發現軟件的缺陷。
6、測試的二八原則
測試時間和資源每每是有限的，要找出全部的缺陷是不可能的，這時咱們須要遵循二八原則。
把80%的時間或者資源用在20%的重點模塊上，重點測試模塊中20%的重要模塊。來達到測試效率和資源配置的最佳的比例。
7、測試活動依賴於測試背景
針對不一樣的測試背景針對的活動是不一樣的，好比：電信級的軟件對性能、大併發量的訪問會有更高的要求。而金融，銀行系統相關的軟件，對安全性能要求更高。工具

軟件測試階段，手段，模式

按測試階段來分類

單元測試、繼承測試、系統測試、驗收測試性能

單元測試

什麼是單元測試單元測試

對軟件中的最小可測試單元進行檢查和驗證學習

單元測試的原則：

1.儘量保證各個測試用例是相互獨立的；

2.通常由代碼的開發人員來實施，用以檢驗所開發的代碼功能符合本身的設計要求。

單元測試的益處：

1.能儘早發現缺陷；收益最高；

2.有利於重構；

3.簡化集成；

4.文檔；

5.用於設計；

單元測試的限制

1.不可能覆蓋全部的執行路徑，因此不可能保證捕捉到全部路徑的錯誤；

2.每一行代碼，通常須要3-5行測試代碼才能完成單元測試。因此存在投入和產出的一個平衡；

單元測試框架：

Xunit，JUnit，nunit，PPUnit，CppUnit

集成測試：

定義:

在單元測試的基礎上，測試在將全部的軟件單元按照概要設計規格說明的要求組裝成模塊、子系統或系統過程當中各部分工做是否達到或實現相應技術指標及要求的活動

集成測試的主要實施方案

1.Big Bang 所有完成，測試

2.自頂向下　　

3.自底向上從最低層測試，逐步組裝測試；（經常使用測試）

4.核心系統集成

5.高頻集成

集成測試&單元測試

1.測試的對象不一樣；

2.測試的一舉不一樣；

3.測試的方法不一樣；

系統測試

定義：是將通過集成測試的軟件，做爲計算機系統的一個部分，系統中其餘部分結合起來，在實際運行環境下對計算機系統進行的一系列嚴格有效的測試，以發現軟件潛在的問題，保證系統的正常運行。

關注點

關注系統自己的使用

關注系統與其餘相關係統間的連通

關注系統在不一樣使用壓力下的表現

關注系統在真實使用環境下的表現

系統測試&集成測試

　　測試環境：

　　　　集成測試：由經過了單元測試的各個模塊所集成起來的構件

　　　　系統測試：除了軟件以外，還包括計算機硬件及相關的外圍設備、數據採集和傳輸機構、支持軟件、系統操做人員等整個系統；

　　測試時間：

　　　　集成測試介於單元測試和系統測試之間測試

　　　　系統測試在集成測試以後

　　測試內容：

　　　　集成測試：各個單元模塊之間的接口

　　　　系統測試：整個系統的功能和性能

　　測試角度：

　　　　集成測試：偏向於技術角度的驗證

　　　　系統測試：偏向於業務角度的驗證

驗收測試　

　　定義：也稱交付測試，針對用戶需求、業務流程的正式的測試，肯定系統是否知足驗收標準，由用戶、客戶、或其餘受權機構決定是否接受系統。

　　細分

　　　　用戶驗收測試

　　　　運行驗收測試

　　　　合同和規範驗收測試

　　　　alpha測試

　　　　Beta測試

按測試手段來分類：

　　黑盒測試、白盒測試

　　靜態測試、動態測試

　　手工測試、自動化測試

黑盒測試

　　定義：把程序看做一個不能打開的黑盒子，在徹底不考慮程序內部結構和內部特性的狀況下，在程序接口進行測試，它只檢查程序功能是否按照需求規格說明書的規定正常使用，程序是否能適當地接收輸入數據而產生正確的輸出信息。主要針對軟件界面和軟件功能進行測試。

　　圖例：

優勢：　

　　1.容易實施，不須要關注內部的實現

　　2.更貼近用戶的使用角度

缺點：

　　1.測試覆蓋率角度，通常只能覆蓋到代碼量的不到40%；

　　2.針對黑盒測試的自動化測試，複用率較低，維護成本較高；

關注點：

　　1.是否有不正確或者遺漏的功能？

　　2.在接口上，輸入是否能正確的接受？可否輸出正確的結果？

　　3.是否有數據結構錯誤或者外部信息(例如數據文件)訪問錯誤？

　　4.性能上是否可以知足要求?

黑盒測試的主要設計方法

白盒測試

定義　

　　白盒測試又稱結構測試、透明盒測試、邏輯驅動測試或基於代碼的測試。白盒測試是一種測試用例方法，盒子指的是被測試的軟件，白盒指的是盒子是可視的，你清楚盒子內部的東西以及裏面是如何運做的。"白盒"法全面瞭解程序內部邏輯結構、對全部邏輯路徑進行測試。"白盒"法是窮舉路徑測試。在使用這一方案時，測試者必須檢查程序的內部結構，從檢查程序的邏輯着手，得出測試數據。貫穿程序的獨立路徑數是天文數字。

圖示：

優勢：

　　1.迫使測試人員去仔細思考軟件的實現，理解原理

　　2.能夠檢測代碼中的每一條分支和路徑

　　3.揭示隱藏在代碼中的錯誤

　　4.對代碼的測試比較完全

缺點：

　　1.昂貴

　　2.沒法檢測代碼中遺落的路徑和數據敏感性錯誤

　　3.不能直接驗證需求的正確性

主要測試方法：