第一章：軟件測試概述

1、軟件及軟件測試

軟件=程序+文檔

軟件測試=程序測試+文檔測試

「程序」是指可以實現某種功能的指令的集合

「文檔」是指軟件在開發、使用和維護過程當中產生的圖文集合

2、常見軟件系統架構

C/S架構

C/S架構的優勢：

1 C/S架構的界面和操做能夠很豐富。（客戶端操做界面能夠隨意排列，知足客戶的須要）

2 安全性能能夠很容易保證。（由於只有兩層的傳輸，而不是中間有不少層。

3 因爲只有一層交互，所以響應速度較快。（直接相連，中間沒有什麼阻隔或岔路，好比QQ，天天那麼多人在線，也不以爲慢）

C/S架構的缺點：

能夠將QQ做爲類比：

1 適用面窄，一般用於局域網中。

2 用戶羣固定。因爲程序須要安裝纔可以使用，所以不適合面向一些不可知的用戶。

3 維護成本高，發生一次升級，則全部客戶端的程序都須要改變。

B/S

B/S架構的優勢：

1、客戶端無需安裝，有Web瀏覽器便可。 
2、BS架構能夠直接放在廣域網上，經過必定的權限控制實現多客戶訪問的目的，交互性較強。 
3、BS架構無需升級多個客戶端，升級服務器便可。能夠隨時更新版本，而無需用戶從新下載啊什麼的。

B/S架構的缺點：

一、在跨瀏覽器上，BS架構不盡如人意。 
2、表現要達到CS程序的程度須要花費很多精力。 
3、在速度和安全性上須要花費巨大的設計成本，這是BS架構的最大問題。 
4、客戶端服務器端的交互是請求-響應模式，一般須要刷新頁面，這並非客戶樂意看到的。

3、什麼是軟件測試

使用人工操做或軟件自動運行的方式來檢驗它是否知足規定的需求弄清預期結果與實際結果之間差異的過程

預期結果

指用戶的預期結果

實際結果

指的是軟件的實際運行結果

軟件缺陷

預期結果與實際結果之間的差異

4、開發人員的測試：是調試（Debug）仍是測試（Test）?

調試                                                    

在源程序內定爲錯誤     

分析錯誤的緣由

修改錯誤

在程序運行時檢驗程序功能

測試                                                                                           

誘發錯誤

重現錯誤

定位錯誤(功能·需求·模塊)

記錄錯誤

5、軟件測試概述-測試原則

軟件測試應該遵照哪些原則呢？

原則1：測試能顯示缺陷的存在

原則2：窮盡測試是不可能的

原則3：測試儘早介入

原則4：缺陷的集羣性

原則5：殺蟲劑悖論

原則6：測試活動依賴於測試內容

原則7：沒有失效不表明系統是可用的

原則8：測試的標準是用戶的需求

原則9：測試貫穿軟件整個生命週期

原則10：獨立的測試團隊

6、測試人員應具有的素質

技術能力（智商）

軟件測試知識

測試工具的使用

操做系統

代碼能力

數據庫知識

網絡知識

溝通交際能力（情商）

好奇心

主動溝通

膽大心細

不被別人綁架

要有懷疑的態度

我的素養（五心）

七、瀑布模型

特色：這是一種古老的瀑布模型，反映了實際和測試之間的關係

侷限：僅僅把測試過程做爲編碼以後的一個階段，忽視了測試對需求分析,系統設計的驗證，若是前面設計錯誤，得一直到後期的驗收測試才被發現，耗時耗力。 

生命週期劃分爲：

制訂計劃

需求分析

軟件設計

程序編寫

軟件測試

運行維護

優勢：

一、開發的各個階段班級清晰。

二、強調早期計劃及需求調查。

三、適合需求穩定的產品開發。

缺點：

一、依賴於早期的需求調查，不適合需求的變化。

二、單一流程不可逆。

三、風險每每延至少後期纔會顯露，失去及早糾正的機會。

四、問題在項目後期纔開始暴露

五、前面未發現的錯誤會傳遞並擴散到後面的階段，看你致使項目失敗

改良：

沿用瀑布模型的線性思想，細化了各個階段，在某些重要關注的階段之間摻入迭代的思想。

八、W模型

體現「儘早地和不斷地進行軟件測試」的原則

用戶需求 驗收測試準備

需求分析與系統設計 系統測試準備

概要設計 集成測試準備

詳細設計 單元測試準備

編碼 單元測試

集成 集成測試

實施 系統測試

交付 驗收測試

九、快速原型模型

在開發真實系統以前，構成一個原型，在該原型的基礎上，逐漸完成整個系統的開發工做。

第一步建造一個快速原型，實現用戶與系統的交互，用戶對原型進行評價，進一步細化待開發軟件需求。經過逐步調整原型使其知足用戶的要求，開發人員能夠肯定用戶的真正的需求。

第二步是在第一步的基礎上開發出用戶滿意的軟件產品。

優勢：

克服瀑布模型的缺點，更好地知足用戶的需求並減小因爲軟件需求不明確帶來的項目開發風險，適合預先不能確切定義需求的軟件系統的開發。

缺點：

不適合大型系統開發（適合開發小型的、靈活性高的系統）。前提要有一個展現性的產品原型，由此在必定程度上可能會限制開發人員的創新。

十、螺旋模型

螺旋模型將開發過程分爲幾個螺旋週期，每一個螺旋週期大體和瀑布模型和瀑布模型相符合，螺旋模型沿着螺旋螺線旋轉，即在座標的4個象限上分別表示了4個方向的活動

優勢：

螺旋模型很大程度上是一種風險驅動的方法體系，由於在每一個階段以前及常常發生的循環以前，都必須首先進行風險評估。

缺點：

採用螺旋模型須要具備至關豐富的風險評估的經驗和專門知識，在風險較大的項目開發中，若是未可以及時標識風險，勢必形成重大損失。過多的迭代次數會增長開發成本，延遲提交時間

十一、軟件測試與軟件工程

軟件測試與軟件工程息息相關，軟件測試是軟件工程中不可缺乏的一部分。

在軟件工程、項目管理、質量管理獲得規範應用的企業，軟件測試也會進行得比較順利，軟件測試發揮的價值也會更大。

要關注軟件工程、質量管理以及配置管理與軟件測試的關係；在不一樣的開發模式下，如何進行軟件測試

十二、測試模型

隨着測試過程的管理和發展，測試人員經過大量實踐，從而總結出了很多測試模型，如常見的V模型、W模型、H模型等。這些與開發緊密結合，對測試活動進行了抽象，成爲了測試過程管理的重要參考依據。

 

1三、V模型

 

需求分析—》概要設計—》詳細設計—》編碼—》單元測試—》集成測試—》系統測試—》驗收測試

優勢：

開發V模型即包含底層測試又包含高層測試

底層測試：檢驗源代碼質量的測試

高層測試：檢查整個系統的須要

V模型清楚的標識出軟件開發的階段

它採用自頂向下逐步求精的方式，把整個開發過程分紅不一樣階段，每一個階段的工做都很明確，所以便於控制開發過程。當全部的階段都完成以後，該軟件的開發過程也隨之結束。

缺點：

V模型一大缺點正是它自身的順序性所致使。到了測試階段，程序已經完成，錯誤已經產生，不少前期的錯誤一直到測試階段才發現，甚至沒法發現，每每無從修改了；

同時實際的開發過程當中，在需求階段就很難把用戶的需求徹底明確下來，所以，當需求變動時將會致使階段反覆，並且都要重複需求，設計、編碼、測試、等過程，返工量很是大，模型靈活性比較低。

 

一、單元測試：又稱爲模塊測試，針對單一的程序模塊進行測試

二、集成測試：又稱組裝測試，在單元測試的基礎上，對全部模塊進行測試

三、系統測試：將整個軟件看作一個總體來進行測試，包括功能、性能、兼容性

四、驗收測試：

（1）內測版：內部交流版本，可能存在有不少bug，不介意用戶安裝

（2）公測版：面對全部用戶，經過用戶的反饋再去進行修改

（3）候選版：與正式軟件相差無幾

1四、隨機測試（探索測試）

隨機測試主要是對被測軟件的-些重要功能進行復測，也包括測試那些當前的測試用例沒有覆蓋到的部分。另外，對於軟件更新和新增長的功能要重點測試。重點對一些特殊點狀況點、特殊的使用環境、併發性、進行檢查。尤爲對之前測試發現的重大Bug,進行再次測試，能夠結合迴歸測試一塊兒進行。

1五、灰盒測試

灰盒測試，是介於白盒測試與黑盒測試之間的一種測試，既可保證黑盒的關注點又可掌控白盒的內部結構，但不會去對內部程序功能和運做作詳細瞭解，灰盒測試結合了白盒測試和黑盒測試的要素。

1六、黑盒測試的分類

功能測試(funct iontest ing)

-是黑盒測試的一方面，它檢查實際軟件的功能是否符合用戶的需

求。

●邏輯功能測試(funct ionesting)

●界面測試(Test ing)

●易用性測試(usability testing)

●安裝測試(installationtest ing)

兼容性測試(compatibillitytesting)

性能測試(performance testing)峯值(後面詳細如今瞭解)

-是軟件測試的高端領域，性能測試工程師的待遇和白盒測試工程師不相上

下，一般咱們所說的高級軟件測試工程師通常就是指性能測試或是白盒測試工程師。

●時間性能(事務響應時間等)

●空間性能(系統資源消耗)

●-般性能測試

●穩定性測試

●負載測試:經過負載測試來肯定在各類工做負載下，系統各項性能指

標的變化狀況。

●壓力測試:經過肯定- -個系統的瓶頸或者恰好不能接受的性能點，來

得到系統可以提供的最大服務級別。

1七、黑盒測試:

黑盒能發現如下幾類錯誤：

功能不對或功能遺漏。

界面錯誤。

數據庫訪問或者處理錯誤。

性能問題。

 

黑盒測試的缺點

不能測試程序內部特定部位;

若是程序未執行的代碼沒法發現;

不可能作到窮舉測試

 

黑盒測試的優勢

測試人員不須要了解實現得細節，包括特定的編程語言(沒有編程經驗的人也可

以設計測試用例) ;

測試人員和編程人員是相互獨立的(黑盒測試用例設計與程序如何實現無關) ;

從用戶的角度進行測試，很容易被接受和理解;

有助於暴露任何與規格不一致或者歧異的地方;

 

1八、按是否查看源代碼

黑盒測試：

又稱數據驅動測試，徹底不考慮程序內部結構和內部特性，注重

於測試軟件的功能需求，只關心軟件的輸入數據和輸出數據。

白盒測試：

指的是把盒子打開，去研究裏面的源代碼和程序結構。

1九、H模型

測試流程：

測試準備:全部測試執行活動的準備;判斷是否到測試就緒點;

測試就緒點:測試准入準則，便是否能夠開始執行測試的條件;

測試執行:具體的執行測試的程序。

其餘流程：

具體開發中的流程，如:設計流程

H模型的優勢:

開發的H模型揭示了軟件測試除測試執行外，還有不少工做;

軟件測試徹底獨立，貫穿整個生命週期，且與其餘流程併發進行:

軟件測試活動能夠儘早準備、儘早執行，具備很強的靈活性;

軟件測試能夠根據被測物的不一樣而分層次、分階段、分次序的執行，同時也是能夠被迭代的。

H模型的缺點:

管理型要求高:因爲模型很靈活，必需要定義清晰的規則和管理制度，不然測試過程將很是難以管理和控制;

技能要求高: H模型要求可以很好的定義每一個迭代的規模，不能太大也不能過小;

測試就緒點分析困難:測試不少時候，你並不知道測試準備到何時是合適的，就緒點在哪裏，就緒點的標準是什麼，這就對後續的測試執行的啓動帶來很大困難;

對於整個項目組的人員要求很是高:在很好的規範制度下，你們都能高效的工做，不然容易混亂。例如:你分了一個小的迭代，可是由於人員技能不足，使得沒法有效完成，那麼整個項目就會受到很大的干擾。

20、敏捷開發模型

敏捷開發(Agile Development)

以用戶的需求進化爲核心、迭代、按部就班的開發方法

軟件項目的構建被切分紅多個子項目

各個子項目的成果都通過測試具有集成和可運行的特徵

經過儘早、持續交付有價值的軟件來使客戶滿意

即便在開發的後期，需求變動也是容許的

常常交付可工做軟件

項目開發期間，業務人員和開發人員在一塊兒工做

強化激勵機制，爲受激勵的我的單獨構建項目在團隊內部，最富有效果和效率的信息傳 遞方法是面對面交談

可工做軟件是進度的首要度量標準

敏捷過程提倡可持續的開發速度

不斷關注優秀的技能和好的設計，加強敏捷能力

簡化

儘可能簡化所要作的工做

好的架構、需求和設計出自於組織團隊自身

團隊要按期檢討如何更有效地工做，並相應地調整本身的行爲