完美的軟件是不存在的，每個(gè)程序都有潛在的故障點(diǎn)。軟件測(cè)試是軟件開(kāi)發(fā)生命周期的一個(gè)階段，在此期間團(tuán)隊(duì)會(huì)發(fā)現(xiàn)程序或系統(tǒng)中不需要的錯(cuò)誤。不同的測(cè)試方法有助于查明幾種類型的軟件錯(cuò)誤。了解每個(gè)軟件測(cè)試模型的工作原理對(duì)于構(gòu)建、部署和維護(hù)高質(zhì)量的測(cè)試策略和軟件至關(guān)重要。
為什么測(cè)試在 SDLC 中很重要？
測(cè)試階段是軟件開(kāi)發(fā)生命周期中的關(guān)鍵階段。它發(fā)生在軟件實(shí)施之后，測(cè)試旨在發(fā)現(xiàn)和修復(fù)軟件錯(cuò)誤。軟件測(cè)試至關(guān)重要，因?yàn)楫a(chǎn)品在測(cè)試后會(huì)投入生產(chǎn)。每個(gè)軟件開(kāi)發(fā)團(tuán)隊(duì)都必須交付高質(zhì)量的軟件，原因有二：
- 最終用戶受益于根據(jù)要求和規(guī)格制造的高質(zhì)量產(chǎn)品。
- 開(kāi)發(fā)團(tuán)隊(duì)的完整性和新項(xiàng)目的可能性取決于軟件的質(zhì)量。
軟件測(cè)試團(tuán)隊(duì)與開(kāi)發(fā)人員分開(kāi)對(duì)不同的問(wèn)題進(jìn)行各種檢查。這種方法有助于讓團(tuán)隊(duì)專注于發(fā)現(xiàn)問(wèn)題并允許實(shí)施持續(xù)開(kāi)發(fā)。
軟件測(cè)試方法論
軟件測(cè)試是由測(cè)試團(tuán)隊(duì)執(zhí)行的正式過(guò)程，用于幫助確認(rèn)程序在邏輯上正確且有價(jià)值。測(cè)試需要使用特定的測(cè)試程序并創(chuàng)建測(cè)試用例。
軟件測(cè)試分兩個(gè)階段進(jìn)行：
- 驗(yàn)證——系統(tǒng)構(gòu)建是否正確？
- 驗(yàn)證——系統(tǒng)是否按照用戶要求構(gòu)建？
軟件測(cè)試使用多種方法和模型來(lái)回答這兩個(gè)問(wèn)題。
黑盒測(cè)試
在黑盒測(cè)試方法中，程序是一個(gè)封閉的（黑）盒，細(xì)節(jié)未知。測(cè)試人員唯一可見(jiàn)的組件是程序輸入和輸出。測(cè)試人員可以通過(guò)觀察各種輸入的結(jié)果輸出來(lái)確定程序是否正常運(yùn)行。黑盒測(cè)試不考慮程序的規(guī)范或代碼，只考慮不同測(cè)試用例的預(yù)期行為。黑盒測(cè)試人員不必非常熟練，因?yàn)樗麄儾慌c任何代碼交互。黑盒測(cè)試既有優(yōu)點(diǎn)也有缺點(diǎn)。黑盒測(cè)試的關(guān)鍵優(yōu)勢(shì)是不需要使用代碼和編程邏輯。然而，?測(cè)試所有輸入組合是不可能的。三種類型的測(cè)試基于黑盒測(cè)試方法：功能測(cè)試、非功能測(cè)試和回歸測(cè)試。
功能測(cè)試
功能測(cè)試檢查軟件是否執(zhí)行特定功能，而不考慮系統(tǒng)中的哪個(gè)組件負(fù)責(zé)操作。測(cè)試團(tuán)隊(duì)檢查功能的好壞輸入。一個(gè)示例函數(shù)是用戶登錄頁(yè)面行為。功能測(cè)試檢查用戶是否可以使用正確的憑據(jù)登錄或不能使用不正確的憑據(jù)登錄。
隨著軟件復(fù)雜性的增加，軟件中的功能數(shù)量也在增加。測(cè)試功能的順序?qū)τ谟行У墓δ軠y(cè)試策略至關(guān)重要。由于功能通常是嵌套的，因此軟件的行為取決于人們?cè)谑褂密浖r(shí)所采取的步驟順序。
功能測(cè)試的主要好處是測(cè)試團(tuán)隊(duì)可以在所有軟件組件完成之前檢查各個(gè)功能。在功能測(cè)試中檢測(cè)到錯(cuò)誤的可能性非常高，因?yàn)樗鼜挠脩舻慕嵌蕊@示了使用軟件時(shí)的問(wèn)題。
非功能測(cè)試
非功能測(cè)試方法除了功能和特性之外，還驗(yàn)證軟件方面。這種測(cè)試方法側(cè)重于程序如何在特定條件下執(zhí)行某些操作。非功能測(cè)試有助于從用戶的角度發(fā)現(xiàn)程序是否可用。該方法檢查可用性問(wèn)題，例如跨不同設(shè)備、瀏覽器或操作系統(tǒng)的交叉兼容性。
回歸測(cè)試
回歸測(cè)試是一種軟件測(cè)試方法，可確保所有新代碼更改不會(huì)導(dǎo)致先前測(cè)試的組件出現(xiàn)問(wèn)題并對(duì)系統(tǒng)穩(wěn)定性產(chǎn)生負(fù)面影響。測(cè)試方法重復(fù)先前迭代的測(cè)試，確保最新的更改不會(huì)對(duì)現(xiàn)有代碼造成不良影響。
在任何導(dǎo)致原始代碼更改的程序操作之后，回歸測(cè)試都是必要的，例如：
- 落實(shí)新要求。
- 向程序添加新功能。
- 刪除現(xiàn)有功能。
- 修復(fù)任何缺陷。
- 優(yōu)化以獲得更好的性能。
如果軟件經(jīng)常更改，最好的方法是使用自動(dòng)化測(cè)試工具并為多次迭代和回歸測(cè)試周期創(chuàng)建可重用測(cè)試。
白盒測(cè)試
白盒測(cè)試方法與黑盒測(cè)試相反。在這種方法中，程序是一個(gè)打開(kāi)的（白色）盒子，測(cè)試人員知道其內(nèi)部工作原理。
白盒測(cè)試分析源代碼并需要以下技能：
- 編碼和腳本知識(shí)。
- 熟悉所使用的特定編程語(yǔ)言。
- 特定組件的設(shè)計(jì)。
測(cè)試人員根據(jù)程序的結(jié)構(gòu)制定計(jì)劃。例如，白盒測(cè)試可以包括創(chuàng)建腳本測(cè)試，這些測(cè)試遍歷整個(gè)代碼并運(yùn)行每個(gè)功能。具體測(cè)試可以檢查是否存在死循環(huán)或者代碼不運(yùn)行的情況。白盒測(cè)試的主要缺點(diǎn)是測(cè)試迭代次數(shù)，隨著應(yīng)用程序變得更復(fù)雜，迭代次數(shù)會(huì)增加。該方法需要?jiǎng)?chuàng)建一種策略，其中遞歸或循環(huán)對(duì)精心選擇的代表性值執(zhí)行次數(shù)更少。三種類型的測(cè)試基于白盒測(cè)試方法：語(yǔ)句測(cè)試、路徑測(cè)試和分支測(cè)試。
語(yǔ)句測(cè)試
語(yǔ)句測(cè)試是白盒測(cè)試中的一種測(cè)試技術(shù)。該方法至少評(píng)估一次代碼中的所有可執(zhí)行語(yǔ)句。例如，如果代碼塊包含多個(gè)條件語(yǔ)句，則語(yǔ)句測(cè)試技術(shù)涉及遍歷所有輸入迭代以確保代碼的所有部分都執(zhí)行。
語(yǔ)句測(cè)試技術(shù)發(fā)現(xiàn)未使用的代碼部分、缺少引用的語(yǔ)句以及以前修訂的剩余代碼。因此，語(yǔ)句測(cè)試有助于清理現(xiàn)有代碼并減少冗余代碼或添加缺失的組件。
路徑測(cè)試
路徑測(cè)試在整個(gè)代碼中創(chuàng)建獨(dú)立的線性路徑。測(cè)試團(tuán)隊(duì)創(chuàng)建代碼的控制流程圖，這有助于設(shè)計(jì)單元測(cè)試以評(píng)估所有代碼路徑。分析不同的路徑有助于發(fā)現(xiàn)應(yīng)用程序的低效、中斷或冗余流。
分支測(cè)試
分支測(cè)試映射代碼中的條件語(yǔ)句并標(biāo)識(shí)單元測(cè)試的分支。分支類型有：
- 有條件的：當(dāng)條件滿足時(shí)執(zhí)行。
- Unconditional：不管任何情況都執(zhí)行。
例如，以下代碼包含多個(gè)嵌套語(yǔ)句：
如果條件 1：
W
否則如果條件 2：
X
是
別的：
Z
測(cè)試人員識(shí)別所有條件分支。在示例代碼中，條件分支是W,?X, 和Z因?yàn)檎Z(yǔ)句只在特定條件下運(yùn)行。另一方面，Y是一個(gè)無(wú)條件分支，因?yàn)樗偸窃赬語(yǔ)句之??后執(zhí)行。分支測(cè)試旨在執(zhí)行盡可能多的分支并測(cè)試所有分支條件。
功能測(cè)試
功能測(cè)試是黑盒測(cè)試的一種子類型，它考慮給定功能或程序的軟件規(guī)范。該測(cè)試方法在不考慮內(nèi)部軟件結(jié)構(gòu)的情況下提供各種輸入并分析輸出。功能測(cè)試包括 4 個(gè)不同的步驟，這些步驟從代碼的更多次要部分開(kāi)始，然后擴(kuò)展到評(píng)估整個(gè)系統(tǒng)。該模型旨在分析組件或程序的合規(guī)性，并檢查系統(tǒng)是否按照規(guī)范執(zhí)行它應(yīng)該執(zhí)行的操作。
第 1 步：?jiǎn)卧獪y(cè)試
單元測(cè)試是一種軟件測(cè)試方法，可驗(yàn)證源代碼的各個(gè)部分。單元測(cè)試有助于確定特定模塊（單元）的功能，并且該過(guò)程隔離各個(gè)部分以確定它們是否正常運(yùn)行。
單元是一個(gè)單獨(dú)的函數(shù)、過(guò)程或面向?qū)ο蟮木幊填悺Ｍǔ＃瑔卧獪y(cè)試有助于驗(yàn)證前端接口。
單元測(cè)試的主要好處是在開(kāi)發(fā)生命周期中盡早發(fā)現(xiàn)問(wèn)題。在測(cè)試驅(qū)動(dòng)的開(kāi)發(fā)中，例如 Scrum 或極限編程，測(cè)試人員在任何代碼存在之前創(chuàng)建單元測(cè)試。
應(yīng)用單元測(cè)試的主要缺點(diǎn)是需要評(píng)估程序中的復(fù)雜執(zhí)行路徑。單元測(cè)試是本地化的并且不兼容，無(wú)法發(fā)現(xiàn)集成或系統(tǒng)范圍的錯(cuò)誤。
第二步：集成測(cè)試
集成測(cè)試是單元測(cè)試之后的一個(gè)階段。該方法將先前評(píng)估的單個(gè)程序單元（模塊）組合成更大的組，并對(duì)聚合體進(jìn)行測(cè)試。
有幾種不同的集成測(cè)試方法：
- 自下而上的策略首先評(píng)估和集成低級(jí)組件，然后再轉(zhuǎn)向更復(fù)雜的組。
- 自上而下的方法使用逆向工程來(lái)評(píng)估來(lái)自更復(fù)雜組的組件并將它們簡(jiǎn)化為更小的單元。
- 三明治（混合）測(cè)試通過(guò)同時(shí)測(cè)試低級(jí)和高級(jí)組件來(lái)結(jié)合自下而上和自上而下的策略。
- 大爆炸測(cè)試將所有組件組合成一個(gè)大單元進(jìn)行測(cè)試。與其他測(cè)試方法相比，該方法沒(méi)有增量方法。
集成測(cè)試驗(yàn)證前端接口和應(yīng)用程序后端之間的連接。
第三步：系統(tǒng)測(cè)試
系統(tǒng)測(cè)試對(duì)完全集成的系統(tǒng)進(jìn)行測(cè)試。該步驟分析行為并將它們與預(yù)期要求（質(zhì)量保證）進(jìn)行比較，從而驗(yàn)證完全集成的軟件。
系統(tǒng)測(cè)試旨在發(fā)現(xiàn)集成和單元測(cè)試遺漏的問(wèn)題，并全面概述軟件是否已準(zhǔn)備好發(fā)布。系統(tǒng)測(cè)試中的不同測(cè)試方法考慮了軟件在各種環(huán)境中的工作情況以及軟件的可用性。
系統(tǒng)測(cè)試的主要挑戰(zhàn)是設(shè)計(jì)一種適合可用時(shí)間和資源限制的策略，同時(shí)在集成后提供對(duì)整個(gè)系統(tǒng)的全面分析。
第 4 步：驗(yàn)收測(cè)試
功能測(cè)試的最后一部分是驗(yàn)收測(cè)試。該測(cè)試方法旨在評(píng)估應(yīng)用程序最終用戶的認(rèn)可度。該方法讓最終用戶參與測(cè)試過(guò)程，并收集用戶對(duì)任何潛在可用性問(wèn)題或任何先前測(cè)試階段遺漏錯(cuò)誤的反饋。
驗(yàn)收測(cè)試屬于以下兩個(gè)類別之一：
- 用戶驗(yàn)收測(cè)試允許目標(biāo)用戶通過(guò) Beta 測(cè)試或類似策略來(lái)評(píng)估和使用軟件。用戶群決定了軟件是否按預(yù)期運(yùn)行。
- 操作驗(yàn)收測(cè)試檢查軟件是否正常運(yùn)行并按預(yù)期運(yùn)行。該測(cè)試檢查各種軟件組件，例如安全性、備份和災(zāi)難恢復(fù)以及故障轉(zhuǎn)移測(cè)試。
驗(yàn)收測(cè)試后，如果結(jié)果滿足驗(yàn)收標(biāo)準(zhǔn)，則軟件可以投入生產(chǎn)。否則，如果測(cè)試未通過(guò)閾值，軟件將被推回到之前的開(kāi)發(fā)和測(cè)試階段。
非功能測(cè)試
非功能測(cè)試從用戶的角度對(duì)軟件進(jìn)行評(píng)估，著重于用戶體驗(yàn)。測(cè)試方法旨在發(fā)現(xiàn)與軟件功能無(wú)關(guān)但對(duì)用戶體驗(yàn)至關(guān)重要的任何問(wèn)題。
非功能測(cè)試考慮以下參數(shù)：
- 安全
- 可靠性
- 可擴(kuò)展性
- 可用性
- 可用性
非功能測(cè)試的重點(diǎn)是產(chǎn)品如何運(yùn)行，而不是它在特定用例中的行為方式。這種測(cè)試模型是通過(guò)性能測(cè)試、安全測(cè)試、可用性測(cè)試和兼容性測(cè)試來(lái)進(jìn)行的。
性能測(cè)試
性能測(cè)試檢查軟件的速度、可擴(kuò)展性和穩(wěn)定性。存在幾種不同的性能測(cè)試子類型，例如：
- 負(fù)載測(cè)試檢查軟件在常規(guī)用戶需求下的功能。
- 壓力測(cè)試檢查軟件在高用戶負(fù)載或其他復(fù)雜情況下的行為。
- 尖峰測(cè)試檢查軟件在突然的高用戶負(fù)載尖峰下的行為。
- 耐久性測(cè)試顯示應(yīng)用程序在較長(zhǎng)時(shí)間內(nèi)的穩(wěn)定性。
所有性能測(cè)試都旨在發(fā)現(xiàn)并修復(fù)會(huì)降低用戶體驗(yàn)的低延遲和性能問(wèn)題。
安全測(cè)試
安全測(cè)試檢查軟件中的任何安全問(wèn)題，是最關(guān)鍵的軟件測(cè)試方法之一。該方法檢查系統(tǒng)內(nèi)的任何漏洞和網(wǎng)絡(luò)攻擊的可能性。滲透測(cè)試和漏洞掃描等方法有助于發(fā)現(xiàn)和降低軟件內(nèi)部的安全風(fēng)險(xiǎn)，還有許多滲透測(cè)試工具可以使測(cè)試過(guò)程自動(dòng)化。
可用性測(cè)試
可用性測(cè)試評(píng)估軟件對(duì)用戶的用戶友好性和便利性。這些測(cè)試突出了未受指導(dǎo)的用戶在程序或應(yīng)用程序中做某事的速度有多快。可用性測(cè)試結(jié)果表明新用戶可以多快學(xué)會(huì)使用該軟件，以及是否有必要對(duì)界面進(jìn)行改進(jìn)。
兼容性測(cè)試
兼容性測(cè)試顯示系統(tǒng)在各種環(huán)境中以及與其他軟件的行為。該方法側(cè)重于與現(xiàn)有解決方案和技術(shù)的集成。
軟件測(cè)試模型
軟件開(kāi)發(fā)生命周期中的測(cè)試階段并不是唯一可以識(shí)別和修復(fù)錯(cuò)誤的地方。所有開(kāi)發(fā)階段都受益于包括軟件測(cè)試。持續(xù)的軟件開(kāi)發(fā)也需要持續(xù)的軟件測(cè)試。軟件開(kāi)發(fā)應(yīng)與測(cè)試團(tuán)隊(duì)合作，盡早發(fā)現(xiàn)潛在問(wèn)題或確定無(wú)法進(jìn)行測(cè)試的地方。越早發(fā)現(xiàn)越好，隨著步驟的推進(jìn)，發(fā)現(xiàn)和修復(fù)錯(cuò)誤的成本會(huì)增加。據(jù) IBM 系統(tǒng)科學(xué)研究所稱，在維護(hù)階段發(fā)現(xiàn)和修復(fù)缺陷的相對(duì)成本要高出大約六倍。
因此，了解測(cè)試如何集成到各種軟件開(kāi)發(fā)過(guò)程和方法中至關(guān)重要。下面是對(duì)眾所周知的軟件開(kāi)發(fā)模型以及測(cè)試如何集成到每種方法中的概述。
瀑布模型
瀑布模型是一種軟件開(kāi)發(fā)方法，分為順序步驟或階段。團(tuán)隊(duì)只有在完成前一階段后才能進(jìn)入下一階段。測(cè)試團(tuán)隊(duì)在瀑布模型的需求階段開(kāi)始創(chuàng)建測(cè)試計(jì)劃和策略。一旦軟件進(jìn)入實(shí)施階段，測(cè)試人員將驗(yàn)證軟件是否正常工作并符合規(guī)范。瀑布法在軟件測(cè)試中的主要好處是需求定義明確并且在測(cè)試階段很容易應(yīng)用。該模型不適合條件經(jīng)常變化和意外事件發(fā)生的項(xiàng)目。
優(yōu)點(diǎn)
- 簡(jiǎn)單：高度抽象簡(jiǎn)化了與最終用戶的溝通過(guò)程，最終用戶無(wú)需了解技術(shù)流程細(xì)節(jié)即可參與開(kāi)發(fā)過(guò)程。
- 易于遵循：項(xiàng)目經(jīng)理可以訪問(wèn)項(xiàng)目開(kāi)發(fā)中的關(guān)鍵點(diǎn)，這使他們能夠了解開(kāi)發(fā)過(guò)程中的進(jìn)度水平。
- 易于應(yīng)用：模型經(jīng)過(guò)單次迭代，便于用新軟件替換現(xiàn)有解決方案。
缺點(diǎn)
- 無(wú)反饋循環(huán)：瀑布模型缺乏反饋機(jī)制和多次迭代。在項(xiàng)目開(kāi)始時(shí)定義所有需求是不可能的，并且返回到任何先前的步驟進(jìn)行更改不是模型中支持的路徑。
- 階段之間沒(méi)有明顯的聯(lián)系：該模型假設(shè)每個(gè)先前的開(kāi)發(fā)階段都是后續(xù)步驟的輸入。但是，該模型沒(méi)有定義需求如何轉(zhuǎn)化為設(shè)計(jì)。
- 不專注于解決問(wèn)題：瀑布模型將軟件設(shè)計(jì)視為硬件或生產(chǎn)機(jī)制。另一方面，軟件設(shè)計(jì)需要測(cè)試和嘗試不同的方法。該模型限制了軟件開(kāi)發(fā)過(guò)程中的任何模塊化和創(chuàng)造性過(guò)程。
- 有限的最終用戶交互：瀑布模型僅在開(kāi)發(fā)階段的第一步和產(chǎn)品完成的最后階段與用戶進(jìn)行通信。該方法限制了用戶交互，這使得開(kāi)發(fā)過(guò)程效率低下。
V型
V模型是瀑布模型的擴(kuò)展和改進(jìn)。該模型分為順序步驟，每個(gè)開(kāi)發(fā)階段都有額外的測(cè)試步驟。V 模型通過(guò)功能測(cè)試的所有階段來(lái)驗(yàn)證和驗(yàn)證軟件。
V 模型的形狀顯示了與開(kāi)發(fā)生命周期階段對(duì)應(yīng)的測(cè)試階段。當(dāng)從左到右查看時(shí)，模型展示了隨著時(shí)間推移的步驟順序，而從上到下查看則揭示了抽象級(jí)別。
優(yōu)點(diǎn)
- 反饋機(jī)制：V 模型對(duì)于簡(jiǎn)單和復(fù)雜的項(xiàng)目都很實(shí)用，因?yàn)樗梢苑祷氐街暗娜魏我粋€(gè)階段。
- 驗(yàn)證和驗(yàn)證：該模型允許檢查項(xiàng)目是否開(kāi)發(fā)良好、是否完全實(shí)施并滿足用戶要求。
- 高質(zhì)量的產(chǎn)品：開(kāi)發(fā)過(guò)程組織嚴(yán)密，控制嚴(yán)密，保證了軟件的質(zhì)量。
- 早期階段測(cè)試：測(cè)試團(tuán)隊(duì)參與早期開(kāi)發(fā)階段，從而從一開(kāi)始就更好地了解項(xiàng)目。該模型顯著節(jié)省了開(kāi)發(fā)后期測(cè)試的時(shí)間和資源。
缺點(diǎn)
- 不靈活：當(dāng)出現(xiàn)問(wèn)題時(shí)，團(tuán)隊(duì)必須更新所有階段必須適應(yīng)軟件的變化并進(jìn)行更新，包括文檔。任何更改都會(huì)減慢開(kāi)發(fā)過(guò)程。
- 成本高：實(shí)施 V 模型需要大量資源來(lái)支持眾多開(kāi)發(fā)團(tuán)隊(duì)。該模型更適合大型項(xiàng)目和企業(yè)。
敏捷模型
敏捷方法是一種快速迭代的軟件開(kāi)發(fā)方法，它遵循敏捷宣言中定義的原則。它將軟件開(kāi)發(fā)分解為小的增量和多次迭代。敏捷模型允許與最終用戶持續(xù)交互，并且需求不斷變化。敏捷模型中的測(cè)試發(fā)生在每次迭代中。此環(huán)境中的軟件測(cè)試需要通過(guò)自動(dòng)化測(cè)試工具和測(cè)試框架對(duì)CI/CD 管道進(jìn)行持續(xù)測(cè)試。
優(yōu)點(diǎn)
- 快速開(kāi)發(fā)：部署軟件比其他模型更快。該模型具有適應(yīng)性和響應(yīng)變化的能力，從而縮短了周轉(zhuǎn)時(shí)間。
- 更小的迭代：錯(cuò)誤和缺陷更容易在更小的塊中發(fā)現(xiàn)和分析。交付軟件花費(fèi)的時(shí)間更少，并且經(jīng)常發(fā)生新的迭代。
- 高水平的用戶交互：持續(xù)的最終用戶反饋確保經(jīng)常進(jìn)行驗(yàn)收測(cè)試。因此，產(chǎn)品在每次迭代中都更接近需求。
缺點(diǎn)
- 不可預(yù)測(cè)：盡管測(cè)試團(tuán)隊(duì)收集了用戶反饋，但不能保證下一次迭代將包含這些更改。快節(jié)奏創(chuàng)造了不可預(yù)測(cè)的產(chǎn)品路線圖。
- 成本高：持續(xù)發(fā)布到生產(chǎn)和開(kāi)發(fā)會(huì)導(dǎo)致更高的費(fèi)用。預(yù)測(cè)每次更改所需的工作量變得很困難。
- 階段重疊：每次迭代都會(huì)經(jīng)歷所有開(kāi)發(fā)階段。隨著沖刺的進(jìn)行，區(qū)分誰(shuí)負(fù)責(zé)哪個(gè)任務(wù)變得更加棘手。
Scrum模型
Scrum 模型是一種使用敏捷模型原則的項(xiàng)目管理方法。該模型以目標(biāo)為導(dǎo)向，并在稱為沖刺的迭代中受時(shí)間限制。每個(gè)沖刺都包含會(huì)議、里程碑和由 scrum 主管管理的事件。
Scrum 模型沒(méi)有測(cè)試團(tuán)隊(duì)，開(kāi)發(fā)人員負(fù)責(zé)構(gòu)建和實(shí)施單元測(cè)試。在每個(gè)沖刺中，最終用戶也經(jīng)常測(cè)試該軟件。一些 Scrum 團(tuán)隊(duì)有功能測(cè)試員，在這種情況下，測(cè)試員必須在 Scrum 會(huì)議期間為每個(gè)測(cè)試會(huì)話提供時(shí)間估計(jì)。
優(yōu)點(diǎn)
- 快節(jié)奏：scrum 模型確保項(xiàng)目交付快速發(fā)生，這使其適用于正在開(kāi)發(fā)的快節(jié)奏項(xiàng)目。
- 成本效益：每個(gè)沖刺由幾個(gè)成員組成，快節(jié)奏的環(huán)境確保項(xiàng)目在指定的時(shí)間范圍內(nèi)完成。
- 高水平的用戶交互：與敏捷模型一樣，scrum 經(jīng)常發(fā)布代碼，從而導(dǎo)致持續(xù)的用戶交互。持續(xù)的反饋會(huì)在每個(gè)沖刺中滿足用戶需求。
缺點(diǎn)
- 高失敗率：Scrum 模型需要高水平的互動(dòng)和承諾。日常會(huì)議壓力很大，一個(gè)團(tuán)隊(duì)成員的離開(kāi)會(huì)影響整個(gè)項(xiàng)目。該軟件在不合規(guī)的團(tuán)隊(duì)中失敗的風(fēng)險(xiǎn)更高。
- 缺乏質(zhì)量：當(dāng)模型缺少測(cè)試團(tuán)隊(duì)時(shí)，軟件的質(zhì)量是不可接受的。由此產(chǎn)生的軟件的等級(jí)低于那些經(jīng)過(guò)密集測(cè)試的軟件。
開(kāi)發(fā)運(yùn)營(yíng)模式
DevOps 模型將持續(xù)測(cè)試結(jié)合到每個(gè)開(kāi)發(fā)階段，同時(shí)在團(tuán)隊(duì)中也有專門的測(cè)試角色。DevOps 管道中的測(cè)試目標(biāo)側(cè)重于軟件質(zhì)量和風(fēng)險(xiǎn)評(píng)估。自動(dòng)化測(cè)試和測(cè)試驅(qū)動(dòng)開(kāi)發(fā)提高了代碼可靠性，這有助于最大限度地降低新構(gòu)建破壞現(xiàn)有代碼的可能性。
優(yōu)點(diǎn)
- 快速軟件交付：DevOps 提高了新功能和錯(cuò)誤修復(fù)的交付速度。對(duì)問(wèn)題的快速響應(yīng)時(shí)間提高了客戶對(duì)產(chǎn)品的滿意度。
- 質(zhì)量軟件：自動(dòng)化測(cè)試和持續(xù)部署提高了軟件質(zhì)量。DevOps 確保在將軟件部署到生產(chǎn)環(huán)境之前測(cè)試每個(gè)更改。
- 錯(cuò)誤有效：在開(kāi)發(fā)的初始階段集成測(cè)試避免了在開(kāi)發(fā)周期的后期解決問(wèn)題。
缺點(diǎn)
- 難以實(shí)施：DevOps 需要將開(kāi)發(fā)與運(yùn)營(yíng)相結(jié)合，并遵循DevOps 原則，這在擁有復(fù)雜系統(tǒng)的大型組織中很難實(shí)現(xiàn)。
- 風(fēng)險(xiǎn)增加：DevOps 嚴(yán)重依賴自動(dòng)化，如果配置不當(dāng)會(huì)導(dǎo)致問(wèn)題。問(wèn)題一旦發(fā)生就很難追蹤。
- 成本過(guò)高：該模型需要對(duì)基礎(chǔ)架構(gòu)和DevOps 工具進(jìn)行大量投資。錯(cuò)誤配置的系統(tǒng)會(huì)帶來(lái)難以管理的集成挑戰(zhàn)。
迭代開(kāi)發(fā)
迭代開(kāi)發(fā)根據(jù)功能將軟件開(kāi)發(fā)步驟劃分為子系統(tǒng)。該方法是增量的，每個(gè)增量都交付一個(gè)完整的系統(tǒng)。每一次新的迭代都會(huì)改進(jìn)每個(gè)子系統(tǒng)中的現(xiàn)有流程。早期版本提供軟件的原始版本，而隨后的每個(gè)版本都會(huì)改??進(jìn)現(xiàn)有功能的質(zhì)量。測(cè)試在早期階段更簡(jiǎn)單，并且隨著迭代的進(jìn)行而增加復(fù)雜性。
優(yōu)點(diǎn)
- 風(fēng)險(xiǎn)控制：迭代開(kāi)發(fā)允許首先從高風(fēng)險(xiǎn)任務(wù)開(kāi)始。開(kāi)發(fā)方法的受控特性可以通過(guò)迭代改進(jìn)任何問(wèn)題。
- 易于遵循：每次迭代都比上一次有所改進(jìn)。對(duì)于項(xiàng)目經(jīng)理來(lái)說(shuō)，測(cè)量迭代之間的變化變得簡(jiǎn)單。
- 早期培訓(xùn)：由于迭代開(kāi)發(fā)提供了完整軟件的更簡(jiǎn)單版本，因此用戶會(huì)盡早參與并使用該軟件。用戶反饋基于整個(gè)系統(tǒng)，改進(jìn)在后續(xù)迭代中更容易實(shí)現(xiàn)。
- 專用版本：版本控制軟件變得簡(jiǎn)單，因?yàn)殚_(kāi)發(fā)團(tuán)隊(duì)可以專注于每次迭代的特定改進(jìn)。例如，一次迭代改進(jìn)了用戶界面，而下一次迭代改進(jìn)了軟件的性能。該方法簡(jiǎn)化了測(cè)試設(shè)計(jì)過(guò)程。
缺點(diǎn)
- 成本高：每次迭代都需要整個(gè)軟件開(kāi)發(fā)團(tuán)隊(duì)的參與。
- 缺乏完整的規(guī)范：迭代開(kāi)發(fā)方法從簡(jiǎn)單的需求開(kāi)始創(chuàng)建系統(tǒng)。隨著時(shí)間的推移，條件也會(huì)發(fā)生變化。規(guī)格的流動(dòng)性使得項(xiàng)目何時(shí)結(jié)束變得具有挑戰(zhàn)性。
- 難以管理：迭代開(kāi)發(fā)需要對(duì)每次迭代進(jìn)行密集的項(xiàng)目管理和風(fēng)險(xiǎn)評(píng)估。隨著項(xiàng)目的增長(zhǎng)，系統(tǒng)的復(fù)雜性增加。
螺旋模型
螺旋模型是一種專注于風(fēng)險(xiǎn)評(píng)估的敏捷模型。該模型結(jié)合了自上而下和自下而上開(kāi)發(fā)方法的優(yōu)點(diǎn)。該方法使用瀑布模型階段作為越來(lái)越復(fù)雜的原型。
由于風(fēng)險(xiǎn)分析是每一步的重點(diǎn)，因此螺旋模型可以及早發(fā)現(xiàn)故障和漏洞。該模型對(duì)問(wèn)題進(jìn)行早期評(píng)估，從長(zhǎng)遠(yuǎn)來(lái)看，這可以降低安全測(cè)試的成本。
優(yōu)點(diǎn)
- 靈活；螺旋模型可以適應(yīng)需求的變化，即使是在開(kāi)發(fā)了一個(gè)特性之后。報(bào)告問(wèn)題時(shí)測(cè)試團(tuán)隊(duì)的壓力較小。
- 安全；風(fēng)險(xiǎn)分析存在于開(kāi)發(fā)過(guò)程的每一步，迭代方法也有助于管理風(fēng)險(xiǎn)。與其他開(kāi)發(fā)模型相比，螺旋模型更側(cè)重于軟件安全。
- 高水平的用戶交互；螺旋模型中的迭代方法允許讓客戶參與開(kāi)發(fā)過(guò)程并接收持續(xù)的反饋。開(kāi)發(fā)團(tuán)隊(duì)在開(kāi)發(fā)過(guò)程中快速做出更改，從長(zhǎng)遠(yuǎn)來(lái)看可以節(jié)省成本和資源。
缺點(diǎn)
- 成本高：螺旋模型最適合大型項(xiàng)目和復(fù)雜的軟件。
- 專業(yè)的風(fēng)險(xiǎn)分析師：該模型依賴于在每個(gè)開(kāi)發(fā)步驟中都包含高質(zhì)量的風(fēng)險(xiǎn)分析師以進(jìn)行有效的風(fēng)險(xiǎn)評(píng)估。
- 復(fù)雜：該模型難以遵循，需要在開(kāi)發(fā)的每個(gè)步驟中更加關(guān)注協(xié)議和文檔。
- 時(shí)間管理：每個(gè)階段的持續(xù)時(shí)間是未知的。該模型容易超出預(yù)算并在時(shí)間限制上落后。
RAD模型
RAD（快速應(yīng)用程序開(kāi)發(fā)）模型是一種將原型制作與迭代開(kāi)發(fā)相結(jié)合的敏捷方法。該方法側(cè)重于收集用戶需求，而其余的開(kāi)發(fā)過(guò)程沒(méi)有具體的計(jì)劃或步驟。RAD 是一種快節(jié)奏的技術(shù)，專注于創(chuàng)建可重用的組件，作為后續(xù)項(xiàng)目或原型的模板。測(cè)試團(tuán)隊(duì)在每次迭代中評(píng)估所有原型，并立即將組件集成到最終產(chǎn)品中。
優(yōu)點(diǎn)
- 靈活：該模型可以快速實(shí)現(xiàn)需求變更并適應(yīng)新的用戶需求。
- 可重用：創(chuàng)建可重用原型提供了一種模板化開(kāi)發(fā)方法，提高了代碼的可重用性，并且從長(zhǎng)遠(yuǎn)來(lái)看需要更少的工作量。
- 快速：開(kāi)發(fā)時(shí)間和短迭代支持持續(xù)的軟件集成和快速交付。RAD 模型結(jié)合了各種自動(dòng)化工具來(lái)加速開(kāi)發(fā)過(guò)程。
缺點(diǎn)
- 高專業(yè)知識(shí)依賴性：基于 RAD 的團(tuán)隊(duì)規(guī)模小、技能高、技術(shù)強(qiáng)。RAD 模型需要經(jīng)驗(yàn)豐富的開(kāi)發(fā)人員團(tuán)隊(duì)來(lái)識(shí)別和建模用戶需求。
- 僅適用于模塊化系統(tǒng)：并非所有軟件都有明確的組件。RAD 需要?jiǎng)?chuàng)建可重復(fù)使用的更小的原型。復(fù)雜系統(tǒng)需要專門的功能，這些功能并不適用于所有用例。
極限編程
極限編程 (XP) 是一種敏捷的軟件開(kāi)發(fā)方法，最適合中小型團(tuán)隊(duì)（6-20 名成員）。該技術(shù)專注于為用戶提供直接結(jié)果的測(cè)試驅(qū)動(dòng)開(kāi)發(fā)和短迭代。
XP 沒(méi)有供開(kāi)發(fā)團(tuán)隊(duì)遵循的嚴(yán)格方法。相反，該方法提供了一個(gè)靈活的框架，其中的過(guò)程或步驟順序會(huì)根據(jù)活動(dòng)而變化。敏捷宣言原則和?結(jié)對(duì)編程等技術(shù)是 XP 中的重要組成部分。
優(yōu)點(diǎn)
- 專注于軟件開(kāi)發(fā)：團(tuán)隊(duì)創(chuàng)建軟件而不是專注于會(huì)議和文檔。工作環(huán)境對(duì)開(kāi)發(fā)人員來(lái)說(shuō)很舒適，有很多學(xué)習(xí)和提高技能的機(jī)會(huì)。
- 開(kāi)發(fā)時(shí)間短：缺乏規(guī)則和程序使得軟件交付速度很快。快速的結(jié)果對(duì)客戶有利。
- 測(cè)試驅(qū)動(dòng)開(kāi)發(fā)：?jiǎn)卧獪y(cè)試存在于編寫代碼之前，程序員在創(chuàng)建軟件之前就知道要測(cè)試什么。這種方法會(huì)刺激程序員在編碼時(shí)采取更好的預(yù)防措施。
缺點(diǎn)
- 難以實(shí)施：該方法難以實(shí)施。XP 需要紀(jì)律嚴(yán)明的程序員，他們接受并遵循所要求的原則，并能緊密合作。
- 客戶端依賴：客戶端選擇是否參與開(kāi)發(fā)過(guò)程。不參與的客戶通常會(huì)導(dǎo)致軟件不盡如人意。
結(jié)論
高質(zhì)量的軟件測(cè)試是區(qū)分高質(zhì)量軟件和乏善可陳的項(xiàng)目的關(guān)鍵。軟件測(cè)試的重要性對(duì)開(kāi)發(fā)至關(guān)重要，這就是為什么有這么多的測(cè)試方法和途徑。開(kāi)發(fā)團(tuán)隊(duì)?wèi)?yīng)該遵循軟件測(cè)試的趨勢(shì)，并準(zhǔn)備好從根本上改變他們的方法，以便從新的軟件測(cè)試方法和模型中獲利。
