目錄
1.什么是軟件測(cè)試？
2.什么是需求？
3.什么是測(cè)試用例
4.什么是軟件錯(cuò)誤（bug）？
5.開發(fā)模型和測(cè)試模型
5.1軟件的生命周期
5.2瀑布模型
5.3螺旋模型
5.4軟件測(cè)試V模型
5.5軟件測(cè)試w模型
6.軟件測(cè)試的生命周期
7.bug的生命周期
1.什么是軟件測(cè)試？
最常見的理解是：軟件測(cè)試就是找
BUG
，發(fā)現(xiàn)缺陷。
現(xiàn)實(shí)生活中在很多情況下我們都在默默進(jìn)行測(cè)試：剛新買來(lái)一部手機(jī)，我們要干什么？一場(chǎng)考試 , 做完一遍題目之后 , 進(jìn)行一遍檢查 , 就是在 " 測(cè)試 "買一臺(tái)電視 , 安裝好之后打開試試看能不能正常使用 , 也是在 " 測(cè)試 "
軟件測(cè)試
就是驗(yàn)證軟件產(chǎn)品特性是否滿足用戶的需求
。
軟件測(cè)試的特點(diǎn)：????????軟件測(cè)試只是一個(gè)樣本試驗(yàn)，具有不可窮盡性。
2.什么是需求？
需求：滿足用戶期望或正式規(guī)定文檔（合同、標(biāo)準(zhǔn)、規(guī)范）所具有的條件和權(quán)能，包含用戶需求和軟件需求。
IEEE 定義：軟件需求是（1） 用戶解決問(wèn)題或達(dá)到目標(biāo)所需條件或權(quán)能 (Capability) 。 (2) 系統(tǒng)或系統(tǒng)部件要 滿足合同、標(biāo)準(zhǔn)、規(guī)范或其它正式規(guī)定文檔所需具有的條件或權(quán)能。 一種反映上面 (1) 或 (2) 所述條件或 權(quán)能的文檔說(shuō)明。它包括功能性需求及非功能性需求，非功能性需求對(duì)設(shè)計(jì)和實(shí)現(xiàn)提出了限制，比如性 能要求，質(zhì)量標(biāo)準(zhǔn)，或者設(shè)計(jì)限制
在多數(shù)軟件公司，會(huì)有兩部分需求，一部分是用戶需求，一部分是軟件需求
用戶需求：
可以簡(jiǎn)單理解為甲方提出的需求，如果沒有甲方，那么就是終端用戶使用產(chǎn)品時(shí)必須要完成的任務(wù)。該需求一般比較簡(jiǎn)略。
軟件需求：
或者叫功能需求，該需求會(huì)詳細(xì)描述開發(fā)人員必須實(shí)現(xiàn)的軟件功能。
大多數(shù)公司在進(jìn)行軟件開發(fā)的時(shí)候會(huì)把用戶需求轉(zhuǎn)化為軟件需求，開發(fā)人員和測(cè)試人員工作的直接依據(jù)就是軟件需求 。
從軟件測(cè)試人員的角度看需求：
需求是測(cè)試人員開展軟件測(cè)試工作的依據(jù)。
在具體設(shè)計(jì)測(cè)試用例的時(shí)候，首先需要搞清楚每一個(gè)業(yè)務(wù)需求對(duì)應(yīng)的多個(gè)軟件功能需求點(diǎn)，然后分析出每個(gè)軟件功能需求點(diǎn)對(duì)應(yīng)的多個(gè)測(cè)試需求點(diǎn)，然后針對(duì)每個(gè)測(cè)試需求點(diǎn)設(shè)計(jì)測(cè)試用例。
過(guò)程如下，業(yè)務(wù)需求
—>軟件功能需求點(diǎn)—>測(cè)試需求點(diǎn)—>測(cè)試用例
3.什么是測(cè)試用例
測(cè)試用例（Test Case
）是為了實(shí)施測(cè)試而向被測(cè)試的系統(tǒng)提供的一組集合，這組集合包含：
測(cè)試環(huán)境、操作步驟、測(cè)試數(shù)據(jù)、預(yù)期結(jié)果
等要素。
測(cè)試用例解決了兩大問(wèn)題：測(cè)什么，怎么測(cè)。
例如：
測(cè)試一個(gè)登錄頁(yè)面。
測(cè)試環(huán)境：chrome瀏覽器操作步驟：輸入賬號(hào)，輸入密碼，點(diǎn)擊登錄測(cè)試數(shù)據(jù)：賬號(hào)3874482，密碼111111預(yù)期結(jié)果：登錄成功
4.什么是軟件錯(cuò)誤（bug）？
第一個(gè) bug ：1945 年 9 月的某天，在一間老式建筑里，從窗外飛進(jìn)來(lái)一只飛蛾，此時(shí) Hopper 正埋頭工作在一臺(tái)名為Mark Il 的計(jì)算機(jī)前，并沒有注意到這只即將造就歷史事件的飛蛾。這臺(tái)計(jì)算機(jī)使用了大量的繼電器（電 子機(jī)械裝置，那時(shí)還沒有使用晶體管）。突然， Mark II 死機(jī)了。 Hopper 試了很多次還是不能啟動(dòng)，他 開始用各種方法查找問(wèn)題，最后定位到了某個(gè)電路板的繼電器上。 Hopper 觀察這個(gè)繼電器，驚奇地發(fā) 現(xiàn)一只飛蛾已經(jīng)被繼電器打死。 Hopper 小心地用鑷子將飛蛾夾出來(lái)，用透明膠布貼到 “ 事件記錄本 ” 中， 寫上 “ 第一個(gè)發(fā)現(xiàn)蟲子的實(shí)例 ” 。 Hopper 的事件記錄本，連同那只飛蛾，現(xiàn)在都陳列在美國(guó)歷史博物館 中。
軟件錯(cuò)誤的一般定義：
程序與規(guī)格說(shuō)明之前不匹配
。
注意：以上說(shuō)法是片面的，準(zhǔn)確的來(lái)說(shuō)：
當(dāng)且僅當(dāng)規(guī)格說(shuō)明是存在的并且正確，程序與規(guī)格說(shuō)明之間的不匹配才是錯(cuò)誤。
當(dāng)需求規(guī)格說(shuō)明書沒有提到的功能，判斷標(biāo)準(zhǔn)以最終用戶為準(zhǔn)：
當(dāng)程序沒有實(shí)現(xiàn)其最終用戶合理預(yù)期的功能要求時(shí)，就是軟件錯(cuò)誤（bug）。
5.開發(fā)模型和測(cè)試模型
隨著軟件工程學(xué)科的發(fā)展，人們對(duì)計(jì)算機(jī)軟件的認(rèn)識(shí)逐漸深入。軟件工作的范圍不僅僅局限在程序編
寫，而是擴(kuò)展到了整個(gè)軟件生命周期，如軟件基本概念的形成、需求分析、設(shè)計(jì)、實(shí)現(xiàn)、測(cè)試、安裝部
署、運(yùn)行維護(hù)，直到軟件被更新和替換新的版本。軟件工程還包括很多技術(shù)性的管理工作，例如過(guò)程管
理、產(chǎn)品管理、資源管理和質(zhì)量管理，在這些方面也逐步地建立起了標(biāo)準(zhǔn)或規(guī)范。
5.1軟件的生命周期
軟件生命周期是指從軟件產(chǎn)品的設(shè)想開始到軟件不再使用而結(jié)束的時(shí)間。 如果把軟件看成是有生命的事物，那么軟件的生命周期可以分成
6
個(gè)階段，即需求分析、計(jì)劃、、設(shè)計(jì)、編碼、測(cè)試、運(yùn)行維護(hù)。
5.2瀑布模型
瀑布模型在軟件工程中占有重要地位，是所有其他模型的基礎(chǔ)框架。瀑布模型的每一個(gè)階段都只執(zhí)行一次，因此是線性順序進(jìn)行的軟件開發(fā)模式。
瀑布模型的優(yōu)缺點(diǎn)如下：
優(yōu)點(diǎn)： 1. 強(qiáng)調(diào)開發(fā)的階段性；??????? ? ? 2. 強(qiáng)調(diào)早期計(jì)劃及需求調(diào)查；??????????? 3. 強(qiáng)調(diào)產(chǎn)品測(cè)試。缺點(diǎn)： 1. 依賴于早期進(jìn)行的 唯一一次需求調(diào)查，不能適應(yīng)需求的變化；??????????? 2. 由于是單一流程，開發(fā)中的經(jīng)驗(yàn)教訓(xùn)不能反饋應(yīng)用于本產(chǎn) 品的過(guò)程；??????????? 3.風(fēng)險(xiǎn)往往遲至后期的測(cè)試階段才顯露，因而失去及早糾正的機(jī)會(huì)。
瀑布模型的一個(gè)最大缺陷在于，可以運(yùn)行的產(chǎn)品很遲才能被看到。這會(huì)給項(xiàng)目帶來(lái)很大的風(fēng)險(xiǎn)，尤其是集成的風(fēng)險(xiǎn)。因?yàn)槿绻谛枨笠氲囊粋€(gè)缺陷要到測(cè)試階段甚至更后的階段才發(fā)現(xiàn)，通常會(huì)導(dǎo)致前面階
段的工作大面積返工，業(yè)界流行的說(shuō)法是：
“
集成之日就是爆炸之日
”
。盡管瀑布模型存在很大的缺陷，
例如，在前期階段未發(fā)現(xiàn)的錯(cuò)誤會(huì)傳遞并擴(kuò)散到后面的階段，而在后面階段發(fā)現(xiàn)這些錯(cuò)誤時(shí)，可能已經(jīng)
很難回頭再修正，從而導(dǎo)致項(xiàng)目的失敗。但是目前很多軟件企業(yè)還是沿用了瀑布模型的線性思想，在這
個(gè)基礎(chǔ)上做出自己的修改。例如細(xì)化了各個(gè)階段，在某些重點(diǎn)關(guān)注的階段之間摻入迭代的思想。
在瀑布模型中，測(cè)試階段處于軟件實(shí)現(xiàn)后，這意味著必須在代碼完成后有足夠的時(shí)間預(yù)留給測(cè)試活動(dòng)，否則將導(dǎo)致測(cè)試不充分，從而把缺陷直接遺留給用戶。
5.3螺旋模型
一般在軟件開發(fā)初期階段需求不是很明確時(shí)，采用漸進(jìn)式的開發(fā)模式。螺旋模型是漸進(jìn)式開發(fā)模型的代
表之一。
這對(duì)于那些規(guī)模龐大、復(fù)雜度高、風(fēng)險(xiǎn)大的項(xiàng)目尤其適合。這種迭代開發(fā)的模式給軟件測(cè)試帶來(lái)了新的要求，它不允許有一段獨(dú)立的測(cè)試時(shí)間和階段，測(cè)試必須跟隨開發(fā)的迭代而迭代。因此，回歸測(cè)試的重
要性就不言而喻了。
?螺旋模型的優(yōu)缺點(diǎn)如下：
優(yōu)點(diǎn)： 1. 強(qiáng)調(diào)嚴(yán)格的全過(guò)程風(fēng)險(xiǎn)管理。??????????? 2. 強(qiáng)調(diào)各開發(fā)階段的質(zhì)量。 – 提供機(jī)會(huì)檢討項(xiàng)目是否有價(jià)值繼續(xù)下 去。缺點(diǎn)： 1. 引入非常嚴(yán)格的風(fēng)險(xiǎn)識(shí)別、風(fēng)險(xiǎn)分析和風(fēng)險(xiǎn)控制（這對(duì)風(fēng)險(xiǎn)管理的技能水平提出了???????? 很高的要求。這需要人員、資金和時(shí)間的投入）
5.4軟件測(cè)試V模型
?文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-417962.html
V
模型最早是由
Paul Rook
在２０世紀(jì)８０年代后期提出的，目的是改進(jìn)軟件開發(fā)的效率和效果。是瀑布模型的變種。
1.明確的標(biāo)注了測(cè)試過(guò)程中存在的不同類型的測(cè)試，并且清楚的描述了這些測(cè)試階段和開發(fā)過(guò)程期間 各階段的對(duì)應(yīng)關(guān)系2.V 模型指出，單元和集成測(cè)試應(yīng)檢測(cè)程序的執(zhí)行是否滿足軟件設(shè)計(jì)的要求；系統(tǒng)測(cè)試應(yīng)檢測(cè)系統(tǒng)功 能、性能的質(zhì)量特性是否達(dá)到系統(tǒng)要求的指標(biāo)；驗(yàn)收測(cè)試確定軟件的實(shí)現(xiàn)是否滿足用戶需要或合同 的要求3.局限性 : 僅僅把測(cè)試作為在編碼之后的一個(gè)階段，未在需求階段就進(jìn)入測(cè)試
5.5軟件測(cè)試w模型
W
模型增加了軟件各開發(fā)階段中應(yīng)同步進(jìn)行的驗(yàn)證和確認(rèn)活動(dòng)。
W
模型由兩個(gè)
V
字型模型組成，分
別代表測(cè)試與開發(fā)過(guò)程，圖中明確表示出了測(cè)試與開發(fā)的并行關(guān)系。
W 模型特點(diǎn)：測(cè)試的對(duì)象不僅是程序，需求、設(shè)計(jì)等同樣要測(cè)試，測(cè)試與開發(fā)是同步進(jìn)行的W 模型優(yōu)點(diǎn)：有利于盡早地全面的發(fā)現(xiàn)問(wèn)題。例如，需求分析完成后，測(cè)試人員就應(yīng)該參與到對(duì)需 求的驗(yàn)證和確認(rèn)活動(dòng)中，以盡早地找出缺陷所在。同時(shí)，對(duì)需求的測(cè)試也有利于及時(shí)了解項(xiàng)目難度 和測(cè)試風(fēng)險(xiǎn)，及早制定應(yīng)對(duì)措施，顯著減少總體測(cè)試時(shí)間，加快項(xiàng)目進(jìn)度。
局限性：需求、設(shè)計(jì)、編碼等活動(dòng)被視為串行的；測(cè)試和開發(fā)活動(dòng)也保持著一種線性的前后關(guān)系， 上一階段完全結(jié)束，才可正式開始下一個(gè)階段工作。無(wú)法支持敏捷開發(fā)模式。對(duì)于當(dāng)前軟件開發(fā)復(fù) 雜多變的情況， W 模型并不能解除測(cè)試管理面臨著困惑。
6.軟件測(cè)試的生命周期
軟件測(cè)試的生命周期： 需求分析
→測(cè)試計(jì)劃→ 測(cè)試設(shè)計(jì)、測(cè)試開發(fā)→ 測(cè)試執(zhí)行→
測(cè)試評(píng)估
軟件測(cè)試&軟件開發(fā)生命周期 :
需求階段– 測(cè)試人員了解需求、對(duì)需求進(jìn)行分解，得出測(cè)試需求計(jì)劃階段-根據(jù)需求編寫測(cè)試計(jì)劃 / 測(cè)試方案設(shè)計(jì)階段– 測(cè)試人員適當(dāng)?shù)牧私庠O(shè)計(jì)，對(duì)于設(shè)計(jì)測(cè)試用例是很有幫助的，測(cè)試人員搭建測(cè)試用例框架，根據(jù) 需求和設(shè)計(jì)編寫一部分測(cè)試用例編碼階段– 測(cè)試人員一般是不需要編碼的，但已經(jīng)編碼的模塊，專業(yè)的白盒測(cè)試人員可以計(jì)劃執(zhí)行單元測(cè)試，完善、細(xì)化測(cè)試用例以及調(diào)整測(cè)試計(jì)劃和方案。測(cè)試階段– 測(cè)試階段是軟件測(cè)試人員最為重要的工作階段，根據(jù)測(cè)試用例和計(jì)劃執(zhí)行測(cè)試，在執(zhí)行的過(guò)程中記錄、管理缺陷，測(cè)試完成后編寫測(cè)試報(bào)告。運(yùn)行維護(hù)– 測(cè)試人員需要參與項(xiàng)目的實(shí)施工作。測(cè)試人員對(duì)項(xiàng)目產(chǎn)品的業(yè)務(wù)和操作非常了解，加上測(cè)試人員的溝通表達(dá)能力一般都比較強(qiáng)，所以測(cè)試人員可以參與用戶使用軟件的培訓(xùn)，在試運(yùn)行項(xiàng)目時(shí)收集 問(wèn)題并及時(shí)反饋給相關(guān)負(fù)責(zé)人。
7.bug的生命周期
文章來(lái)源：http://www.zghlxwxcb.cn/news/detail-417962.html
● New:新發(fā)現(xiàn)的
Bug
，未經(jīng)評(píng)審決定是否指派給開發(fā)人員進(jìn)行修改。
●
Open
：確認(rèn)是
Bug
，并且認(rèn)為需要進(jìn)行修改，指派給相應(yīng)的開發(fā)人員。
●
Fixed:
開發(fā)人員進(jìn)行修改后標(biāo)識(shí)成修改狀態(tài)，有待測(cè)試人員的回歸測(cè)試驗(yàn)證。
●
Rejected
：如果認(rèn)為不是
Bug
，則拒絕修改。
●
Delay:
如果認(rèn)為暫時(shí)不需要修改或暫時(shí)不能修改，則延后修改。
●
Closed
：修改狀態(tài)的
Bug
經(jīng)測(cè)試人員的回歸測(cè)斌驗(yàn)證通過(guò)，則關(guān)閉
Bug
。
●
Reopen
：如果經(jīng)驗(yàn)證
Bug
仍然存在，則需要重新打開
Bug
，開發(fā)人員重新修改。
無(wú)效的
bug
：
open->closed open-rejected-closed
Bug
的跟蹤以及狀態(tài)變更應(yīng)該遵循一些基本原則：
1.測(cè)試人員對(duì)每一個(gè)缺陷的修改必須重新取一個(gè)包含更改后的代碼的新版本進(jìn)行回歸測(cè)試，確保相同
的問(wèn)題不再出現(xiàn)，才能關(guān)閉缺陷。
2.對(duì)于拒絕修改和延遲修改的
Bug
，需要經(jīng)過(guò)包含測(cè)試人員代表和開發(fā)人員代表、用戶方面的代表
（或代表用戶角度的人）的評(píng)審。
?
到了這里，關(guān)于【軟件測(cè)試】淺了解什么是軟件測(cè)試及開發(fā)測(cè)試模型的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
