? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??

1.測試流程:

2.測試分類

3.黑盒測試，灰盒測試和白盒測試

黑盒測試?：已知產(chǎn)品的功能設(shè)計(jì)規(guī)格，可以進(jìn)行測試證明每個(gè)實(shí)現(xiàn)了的功能是否符合要求。白盒測試?：已知產(chǎn)品的內(nèi)部工作過程，可以通過測試證明每種內(nèi)部操作是否符合設(shè)計(jì)規(guī)格要求，所有內(nèi)部成分是否以經(jīng)過檢查?；液袦y試，是介于白盒測試與黑盒測試之間的，可以這樣理解，灰盒測試關(guān)注輸出對于輸入的正確性，同時(shí)也關(guān)注內(nèi)部表現(xiàn)，但這種關(guān)注不象白盒那樣詳細(xì)、完整，只是通過一些表征性的現(xiàn)象、事件、標(biāo)志來判斷內(nèi)部的運(yùn)行狀態(tài)，有時(shí)候輸出是正確的，但內(nèi)部其實(shí)已經(jīng)錯誤了，這種情況非常多，如果每次都通過白盒測試來操作，效率會很低，因此需要采取這樣的一種灰盒的方法

4：測試發(fā)現(xiàn)bug 而開發(fā)不認(rèn)為是bug的時(shí)候：

1.測試人員在根據(jù)需求文檔或者是規(guī)格說明書/原型圖來進(jìn)行匹配

? 2.測試人員根據(jù)不同的測試環(huán)境來進(jìn)行多測嘗試來確認(rèn)bug 并將bug的復(fù)現(xiàn)步驟進(jìn)行記錄

? 3.如果開發(fā)仍舊認(rèn)為不是bug 需要的測試主管來進(jìn)行討論 確認(rèn)是否bug

? 4.需要找產(chǎn)品經(jīng)理和項(xiàng)目經(jīng)理進(jìn)行討論是否bug

? 5.如果認(rèn)為是bug測試人員將bug進(jìn)行記錄并提交測試總結(jié)中

5.?瀑布模型

瀑布模型是最早出現(xiàn)的軟件開發(fā)模型，在軟件工程中占有重要的地位，它提供了軟件開發(fā)的基本框架。其過程是從上一項(xiàng)活動接收該項(xiàng)活動的工作對象作為輸入，利用這一輸入實(shí)施該項(xiàng)活動應(yīng)完成的內(nèi)容給出該項(xiàng)活動的工作成果，并作為輸出傳給下一項(xiàng)活動。同時(shí)評審該項(xiàng)活動的實(shí)施，若確認(rèn)，則繼續(xù)下一項(xiàng)活動；否則返回前面，甚至更前面的活動。對于經(jīng)常變化的項(xiàng)目而言，瀑布模型毫無價(jià)值。

瀑布型簡單地說就是按照需求、設(shè)計(jì)、編碼、測試、軟件維護(hù)這個(gè)基本的順序來研發(fā)軟件，前面一個(gè)步驟不完成，后面的步驟不能開始，否則問題會滾到下個(gè)階段，帶來更多的問題

優(yōu)點(diǎn)：

?為項(xiàng)目提供了按階段劃分的檢查點(diǎn)

當(dāng)前一階段完成后，只需要去關(guān)注后續(xù)階段。

缺點(diǎn)：

1）各個(gè)階段的劃分完全固定，階段之間產(chǎn)生大量的文檔，極大地增加了工作量。

2）由于開發(fā)模型是線性的，用戶只有等到整個(gè)過程的末期才能見到開發(fā)成果，從而增加了開發(fā)風(fēng)險(xiǎn)。

3）通過過多的強(qiáng)制完成日期和里程碑來跟蹤各個(gè)項(xiàng)目階段。

4）瀑布模型的突出缺點(diǎn)是不適應(yīng)用戶需求的變化。

6.原型化模型

原型化模型的第一步是建造一個(gè)快速原型，實(shí)現(xiàn)客戶或未來的用戶與系統(tǒng)的交互，經(jīng)過和用戶針對原型的討論和交流，弄清需求以便真正把握用戶需要的軟件產(chǎn)品是什么樣子的。充分了解后，再在原型基礎(chǔ)上開發(fā)出用戶滿意的產(chǎn)品。如圖所示：原型嚴(yán)格來說不算一種軟件生命周期模型，它只是一種獲取需求的方法，在實(shí)際工作中該方法是相當(dāng)重要的方法。

模型要點(diǎn)：瀑布和原型模型相結(jié)合，強(qiáng)調(diào)版本升級。

該模式的特點(diǎn)是一次性地獲取全部的需求，然后做出分版本實(shí)現(xiàn)各需求的計(jì)劃，每個(gè)版本只實(shí)現(xiàn)一部分需求，通過多個(gè)版本逐步實(shí)現(xiàn)全部需求，而每個(gè)版本可以認(rèn)為是一個(gè)“小瀑布”。

該模型的好處是可以盡快讓系統(tǒng)上線，讓客戶先使用部分功能，盡早實(shí)現(xiàn)系統(tǒng)的價(jià)值。

該模型比較能符合實(shí)際的情況，我們往往也是通過多個(gè)版本來逐步實(shí)現(xiàn)全部需求，但需求是不可能在一開始就完全確定的，實(shí)際情況是往往只能確定80%，而后期通過各版本我們還會獲取更多的新需求以及需求調(diào)整。將此模型稍微調(diào)整后，可以適用于大部分的實(shí)際項(xiàng)目。

7.增量模型

增量模型也是原型化開發(fā)方法。如圖所示

8.螺旋模型

螺旋模型是一個(gè)演化軟件過程模型，將原型實(shí)現(xiàn)的迭代特征與線性順序（瀑布）模型中控制的和系統(tǒng)化的方面結(jié)合起來。使得軟件的增量版本的快速開發(fā)成為可能。在螺旋模型中，軟件開發(fā)是一系列的增量發(fā)布。螺旋模型的整個(gè)開發(fā)過程如圖所示。

圖中的螺旋線代表隨著時(shí)間推進(jìn)的工作進(jìn)展；開發(fā)過程具有周期性重復(fù)的螺旋線形狀。4個(gè)象限分別標(biāo)志每個(gè)周期所劃分的4?個(gè)階段：制定計(jì)劃、風(fēng)險(xiǎn)分析、實(shí)施工程和客戶評估。螺旋模型要點(diǎn)：統(tǒng)一了瀑布模型與原型模型，與增量模型相似，更強(qiáng)調(diào)風(fēng)險(xiǎn)分析。

1.軟件分多個(gè)版本開發(fā)，每個(gè)版本就是一次螺旋。

2.每個(gè)版本按照這樣的順序進(jìn)行：

1）確定軟件目標(biāo)，選取定實(shí)施方案，弄清項(xiàng)目開發(fā)的限制條件；（圖中左上象限）

2）分析所選取方案，考慮如何識別和消除風(fēng)險(xiǎn)；（圖中右上象限）

3）實(shí)施軟件開發(fā)；（圖中右下象限）

4）評價(jià)開發(fā)工作，提出修正建議，調(diào)整計(jì)劃。（圖中右下象限、左下象限）

3.需求不是一次獲取和實(shí)現(xiàn)的，通過多個(gè)螺旋來完善。

4.計(jì)劃也不是一次成型的，每次螺旋都需要調(diào)整。

優(yōu)點(diǎn)：

1）設(shè)計(jì)上很靈活，可以在項(xiàng)目的各個(gè)階段進(jìn)行變更；

2）以小的分段來構(gòu)建大型系統(tǒng)，使成本計(jì)算變得簡單容易；(國企項(xiàng)目)

3）客戶始終參與每個(gè)階段的開發(fā)，保證了項(xiàng)目不偏離正確方向以及項(xiàng)目的可控性；

4）隨著項(xiàng)目推進(jìn)，客戶始終掌握項(xiàng)目的最新信息?,?從而能夠和管理層有效地交互；

5）客戶認(rèn)可這種公司內(nèi)部的開發(fā)方式帶來的良好的溝通和高質(zhì)量的產(chǎn)品。

缺點(diǎn)：

螺旋模型強(qiáng)調(diào)風(fēng)險(xiǎn)分析，但要求許多客戶接受和相信這種分析，并做出相關(guān)反應(yīng)是不容易的。

因此，這種模型往往適應(yīng)于內(nèi)部的大規(guī)模軟件開發(fā)。該模型建設(shè)周期長，而軟件技術(shù)發(fā)展比較快，所以經(jīng)常出現(xiàn)軟件開發(fā)完畢后，和當(dāng)前的技術(shù)水平有了較大的差距，無法滿足當(dāng)前用戶需求。

9.Ｖ模型

V模型的左邊下降的是開發(fā)過程各階段，與此相對應(yīng)的是右邊上升的部分，即各測試過程的各個(gè)階段。

V模型的優(yōu)點(diǎn)在于它非常明確地標(biāo)明了測試過程中存在的不同級別，并且清楚地描述了這些測試階段和開發(fā)各階段的對應(yīng)關(guān)系。

1、需求分析階段對應(yīng)生成需求規(guī)格說明書，對應(yīng)測試生成系統(tǒng)測試方案，即為系統(tǒng)測試準(zhǔn)備的，該階段已經(jīng)完成了單元測試和集成測試，主要是對軟件產(chǎn)品的功能與非功能進(jìn)行測試，幾乎不測試代碼，所以測試方法以黑盒為主；

2、概要設(shè)計(jì)階段對應(yīng)生成概要設(shè)計(jì)說明書，對應(yīng)測試生成集成測試方案，該階段已完成單元測試，是將各個(gè)功能模塊組裝起來進(jìn)行的測試，所以也叫組裝測試。主要看模塊調(diào)用是否正常，接口是否可用，數(shù)據(jù)傳輸是否正確等，所以用到的測試方法幾乎是白盒的方法，如路徑覆蓋，條件組合覆蓋等；

3、詳細(xì)設(shè)計(jì)階段對應(yīng)生成詳細(xì)設(shè)計(jì)說明書，對應(yīng)測試生成單元測試方案，該階段是開發(fā)人員編碼后的第一個(gè)測試階段，是對開發(fā)出來的單獨(dú)模塊進(jìn)行測試，以確保每一個(gè)功能模塊的功能正常，可以構(gòu)建樁模塊和驅(qū)動模塊來回調(diào)用，方法也是以白盒為主。

4、白盒測試的準(zhǔn)則是盡可能覆蓋程序內(nèi)部的邏輯結(jié)構(gòu)，黑盒則是盡可能覆蓋所有的輸入輸出接口，包括文檔等一些靜態(tài)的測試。除常用的測試方法外，仍需補(bǔ)充大范圍的隨機(jī)測試，盡可能達(dá)到覆蓋率100%。

V模型的缺陷及解決思路

V模型僅僅把測試過程作為在需求分析、系統(tǒng)設(shè)計(jì)及編碼之后的一個(gè)階段，忽視了測試對需求分析,系統(tǒng)設(shè)計(jì)的驗(yàn)證，需求的滿足情況一直到后期的驗(yàn)收測試才被驗(yàn)證。

解決的思路是，當(dāng)一個(gè)軟件開發(fā)的時(shí)候，研發(fā)人員和測試人員需要同時(shí)工作，測試在軟件做需求分析的同時(shí)就會有測試用例的跟蹤，這樣，可以盡快找出程序錯誤和需求偏離，從而更高效的提高程序質(zhì)量，最大可能的減少成本，同時(shí)滿足用戶的實(shí)際軟件需求。

10.Ｗ模型

相對于V模型，W模型更科學(xué)。W模型是V模型的發(fā)展，強(qiáng)調(diào)的是測試伴隨著整個(gè)軟件開發(fā)周期，而且測試的對象不僅僅是程序，需求、功能和設(shè)計(jì)同樣要測試。測試與開發(fā)是同步進(jìn)行的，從而有利于盡早地發(fā)現(xiàn)問題。

11.回歸測試、冒煙測試、隨機(jī)測試

????????1.回歸測試

? ??????????????是指對軟件的新版本進(jìn)行測試時(shí)，重復(fù)執(zhí)行上一個(gè)版本測試時(shí)的用例，比如在1.0版本中，有一個(gè)bug，到了2.0版本中,再重新測試1.0中這個(gè)bug

? ??????2.冒煙測試

指對一個(gè)軟件進(jìn)行系統(tǒng)大規(guī)模的測試之前，先驗(yàn)證一下軟件的基本功能是否實(shí)現(xiàn)，是否具備可測性。

測試小組在正式測試一個(gè)新版本之前，先指派一兩個(gè)測試人員測試一下軟件的主要功能，如果沒有實(shí)現(xiàn)，則打回開發(fā)組重新開發(fā)，這樣做可以節(jié)省大量的時(shí)間成本和人力成本。

????3.隨機(jī)測試

? ? 是指測試中所有的輸入數(shù)據(jù)都是隨機(jī)生成的，其目的是模擬用戶的真實(shí)操作，并發(fā)現(xiàn)一些邊緣性的錯誤。