軟件測試理論基礎第二天

? ? 今天說一下軟件測試模型,說到軟件測試模型就要先說一下軟件開發模型,之后是軟件測試分類以及測試用例。

1.軟件開發過程模型

這里要介紹的是瀑布模型,快速原型模型,螺旋模型這三種開發模型

為什么要先說一下開發模型?

軟件測試與軟件的開發模式有著緊密的聯系,作為一名測試人員,應該充分理解軟件的開發模式,以便找準自己在其中的位置,從而發揮自身的價值

1.1開發模型-瀑布模型? Waterfall Model


瀑布模型

瀑布模型介紹

該模型給出了固定的順序,將生存期活動從上一個階段向下一個階段過渡,如同流水下瀉,最終得到所開發的軟件產品。

瀑布模型定義

瀑布模型是將軟件生存周期的各項活動規定為按固定順序連接的若干階段工作,形如瀑布流水,最終得到軟件產品。

1.是線性模型的一種,在所有模型中占有重要地位,是所有其他模型的一個基礎。

2.每一個階段執行一次,按線性順序進行軟件開發

3.測試的切入點:測試階段處于軟件是先后,必須在代碼完成后留出足夠時間給測試活動,否側將導致測試不充分,很多問題到項目后期才暴露。

瀑布模型的優缺點

優點

1.開發的各個階段比較清晰

2.強調早期計劃及需求調查

3.適合需求穩定的產品開發

缺點

1.依賴與早期的需求檢查,不適應需求變化

2.單一流程不可逆

3.風險往往延至后期才顯露,失去及早糾正的機會

4.前面未發現的錯誤會傳遞并擴散到后面階段,可能導致項目失敗

1.2開發模型-快速原型模型【了解】

在開發真實系統(軟件,軟件系統)之前,構造一個原型,在該原型的基礎上,逐漸完成?整個系統的開發工作。

1.第一步是構建一個快速原型,實現用戶與系統的交互,用戶對原型進行評價,進一步細化待開發軟件的需求。通過逐步調整原型使其滿足用戶的要求,開發人員可以確定用戶的真正需求是什么。

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

快速原型模型

快速原型模型的優缺點

優點

克服瀑布模型的缺點,更好的滿足用戶需求并減少由于軟件需求不明確帶來的項目開發風險。適合預先不能確切定義需求的軟件系統開發。

缺點

不適合大型系統的開發(適合開發小型的、靈活性高的系統)。前提要有一個展示性的產品原型,因此在一定程度上可能會限制開發人員的創新。

1.3開發模型-螺旋模型【了解】

螺旋模型將開發過程分為幾個螺旋周期,每個螺旋周期大致和瀑布模型相符合,螺旋模型沿著螺旋線旋轉,即在坐標的4個象限上分別表示了4個方面的活動。

螺旋模型

a)制定計劃

b)風險分析

c)是會開發

d)客戶評估

螺旋模型的優缺點

優點

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

缺點

采用螺旋模型需要具有相當豐富的風險評估經驗和專門知識,在風險較大的項目開發中,如果未能及時表示風險,勢必會造成重大損失。過多的迭代次數會增加開發成本,延遲提交時間。

2.測試模型

測試模型主要介紹V模型,W模型,H模型

2.1????V模型

V模型

? ? * V模型是最具有代表意義的測試模型,旨在改進軟件開發的效率和效果。

? ? * V模型推出之前,人們通常把測試過程作為在需求分析、概要設計、詳細設計、編碼全部 ????????完成之后的一個階段,盡管當時已經出現了測試工作會占用這個項目周期一半的時間,? ????????但是大多數人認為測試只是一個收尾工作;V模型在這個時候推出,就是為了改變之前行 ????????業的普遍認識。

? ? * V模型本身是軟件開發中瀑布模型的變種,它反映了測試活動與分析和設計的關系。

? ? * V模型標明了測試過程中本身存在的不同階段,從左到右,描述了開發過程和測試過程間? ?????????的階段對應關系。

V模型大體可以劃分為以下幾個不同的階段步驟:需求分析、概要設計、詳細設計、軟件編碼、單元測試、集成測試、系統測試、驗收測試。(后四個是測試)

需求分析

首先要明確客戶需要的是什么,需要軟件做成什么樣子,需要有哪幾項功能,這一點上比較關鍵的是分析師和客戶溝通時的理解能力與交互性。要求分析師能準確的把客戶所要表達到的功能,實現方式,等表述出來,給出分析結果,寫出需求規格說明書。

概要設計

主要是架構的實現,指搭建架構、表述各模塊功能、模塊接口連接和數據傳遞的實現等項事務

詳細設計

對概要設計中表達的各模塊進行深入分析,對各模塊組合進行分析等,這一階段要求達到偽代碼級別,已經把程序的具體實現的功能,現象等描述出來。其中需要包含數據庫設計說明。

軟件編碼

按照詳細設計好的模塊功能表,編程人員編出實際的代碼。

單元測試

按照設定好的最小測試單元進行按單元測試,主要是測試程序代碼,為的是確保各單元模塊被正確的編譯,單元的具體劃分按不同的單位與不同的軟件有不同,比如有具體到模塊的測試,也有具體到類,函數的測試等。

集成測試

經過了單元測試后,將各單元組合成完整的體系,主要測試各模塊間組合后的功能實現情況,以及模塊接口連接的成功與否,數據傳遞的正確性等,其主要目的是檢查軟件單位之間的接口是否正確。根據集成測試計劃,一邊將模塊或其他軟件單位組合成系統,一邊運行該系統,以分析所組成的系統是否正確,各組成部分是否合拍。

系統測試

經過了單元測試和集成測試以后,我們要把軟件系統搭建起來,按照軟件規格說明書中所要求,測試軟件其性能功能是否和用戶需求相符合,在系統中運行是否存在漏洞,等。

驗收測試

主要就是用戶在拿到軟件的時候,在使用現場,會根據前邊所提到的需求,以及規格說明書來做相應測試,以確定軟件達到預期的效果。

V模型的優缺點

優點

測試V模型即包含了底層測試(單元測試)又包含了高層測試(系統測試);

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

它采用自頂向下逐步求精的方式把整個開發過程分成不同的階段,每個階段的工作都很明確,因此便于控制開發過程。當所有階段完成之后,該軟件的開發過程也隨之結束。

缺點

V模型一大缺點正是它自身的順序性所導致的。到了測試階段,程序已經完成,錯誤已經產生,很多前期的錯誤一直到測試階段才發現,甚至無法發現,往往無從修改了。

同時實際的開發過程中,在需求階段很難把用戶的需求完全明確下來,因此,當需求變更時將會導致階段反復,而且都要重復需求、設計、編碼、測試等過程,返工量非常大,模型靈活性比較低。

2.2? ? W模型

W模型由Evolutif公司提出:開發一個V,測試一個V,組合的W模型;

測試伴隨著整個軟件開發周期,并且測試的對象不僅僅是程序,需求和設計同樣需要測試。

W模型


W?模型優缺點

優點

強調測試伴隨著整個軟件開發周期,而且測試的對象不僅僅是程序,需求和概要設計同樣要測試;

更早的接入測試,可以發現開發初期的缺陷,那么可以用更加低的成本進行缺陷修復;

同樣是分階段的工作,便于控制項目過程。

缺點

依賴于軟件開發和軟件測試依然保持一前一后的線性關系,依然無法支持迭代、自發性和需求等變更調整;

對于當前很多項目,在執行的過程中根本不產生文檔,那么W模型基本無法適用;

使用起來技術復雜度很高,對于需求和設計的測試要求很高,實踐起來困難。

2.3? ? H模型【了解】

人們發現雖然軟件開發中需求、設計、編碼等活動被分階段執行、但是實踐中,他們并不是完全串行的,他們之間更多時候是交叉進行的,更多的是迭代執行。

為了解決上面的問題,有專家專門提出了H模型,它將測試活動完全獨立出來,形成一個完全獨立的流程,同時將測試準備測試和測試執行也清晰表現出來。

H模型

測試流程

? ? *測試準備:所有測試執行活動的準備;判斷是否到測試就緒點;

? ? *測試就緒點:測試準入準則,即是否可以開始執行測試的條件;

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

其他流程

? ? *具體開發中的流程,如:設計流程

H模型優缺點

優點

開發的H模型揭示了軟件除測試執行外,還有很多工作;

軟件測試完全獨立,貫穿整個生命周期,且于其他流程并發進行;

軟件測試活動可以盡早準備、盡早執行,具有很強的靈活性;

軟件測試可以根據被測物的不同而分層次、分階段、分次序的執行,同時也是可以被迭代的。

缺點

管理型要求較高:由于模型很靈活,必須要定義清晰的規則和管理制度,否則測試過程將非常難以管理和控制;

技術要求高:H模型要求能夠很好的定義每個迭代的規模,不能太大也不能太小;

測試就緒點分析困難:測試很多時候,你并不知道測試準備到什么時候是最合適的,就緒點在哪里,就緒點的標準是什么,這就對后續的測試執行的啟動帶來很大困難;

對于整個項目組的人員要求非常高:在很好的規范制度下,大家都能高效的工作,否則容易混亂。例如:你分了一個小的迭代,但是因為人員技能不足,使得無法有效完成,那么整個項目就會受到很大的干擾。

3.軟件測試分類

3.1按照測試階段劃分

單元測試

又稱模塊測試,針對軟件設計中的最小單位-------程序模塊,進行正確性檢查的測試工作。單元測試需要從程序的內部結構出發設計測試用例。多個模塊可以平行的獨立進行單元測試。

單元定義:C中指一個函數,Java中指一個類或函數,在圖形化的軟件中,一般指1個窗口,一個菜單。

集成測試

又叫組裝測試,通常在單元測試的基礎上,將所有程序模塊進行有序的、遞增的測試。重點測試不同模塊的接口部分。

系統測試

指的是將整個軟件系統看為一個整體進行測試,包括對功能、性能、以及軟件所運行的軟硬件環境進行測試。

系統測試在系統集成完畢后進行測試,前期主要測試系統的功能是否滿足需求,后期主要測試系統運行的性能是否滿足需求,以及系統在不同的軟硬件環境中的兼容性等。

3.2按照是否查看源碼

黑盒測試(black-box?testing)

又稱數據驅動測試,完全不考慮程序內部結構和內部特性,注重于測試軟件的功能需求,只關心軟件的輸入數據和輸出數據

白盒測試(white-box?testing)

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

在軟件公司,往往采用黑盒測試&白盒測試相結合的方式。

????軟件的整體功能和性能進行黑盒測試。

? ? 軟件的源代碼采用白盒測試。

黑盒測試的優缺點

優點

測試人員不需要了解實現的細節,包括特定的編程語言(沒有編程經驗的人也可以設計測試用例);

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

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

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

缺點

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

如果程序未執行的代碼無法發現;

不可能做到窮舉測試;

黑盒測試能發現以下幾類錯誤:

功能不對或功能遺漏。

界面錯誤。

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

性能問題。

黑盒測試分類

功能測試

檢查實際軟件的功能是否符合用戶的需求。

? ? *邏輯功能測試

? ? *界面測試

? ? *易用性測試

? ? *安裝測試

? ? *兼容性測試

性能測試【后面詳解,現在了解】

時間性能

空間性能

一般性能測試

穩定性測試

負載測試

壓力測試

灰盒測試【了解】

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

3.3按照是否運行分類

靜態測試

指不實際運行被測軟件,而只是靜態地檢查程序代碼、界面或文檔中可能存在的錯誤過程。

動態測試

是指實際運行被測程序,輸入相應的測試數據,檢查實際輸出結果和預期結果是否相符的過程。

3.4驗收測試

α測試

內測?bug較多,一般是內部人員使用。

β測試

公測?大型bug沒了,小bug一大堆,一般是內部人員和高玩使用。

γ測試

正式發布版本的候選版,基本沒啥問題了。

3.5隨機測試(探索測試)

意思就是對一些重要功能進行復測,尤其以前有缺陷的地方。

4.測試用例

定義:測試用例(Test Case)是為特定的目的而設計的一組測試輸入、執行條件?和預期的結果,一遍測試是否滿足某個特定需求。通過大量的測試用例來檢驗軟件的運行效果,他是指導測試工作進行的依據。

4.1等價劃分法

我們發現我們用戶所有可能輸入的數據,劃成了若干份(或者也可以稱為子集),然后從每一個子集當中選取少數具有代表性的數據作為測試用例,這種測試用例我們稱為“等價類劃分法”

等價類劃分(分類)

有效等價類

? ? 指符合《需求規格說明書》,輸入合理的數據集合。

無效等價類

? ? 指不符合《需求規格說明書》,輸入不合理的數據集合。

等價類思考步驟

1、先確定有效和無效等價類

2、有效等價類就是題目條件(兩端的極值(邊界值)要判斷、中間隨意一個值也要判斷)

3、無效等價類先劃分與條件相反的情況,再找特殊情況(中文、英文、符號、空格、空)

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容