軟件測(cè)試基礎(chǔ)總結(jié)

1、1. 軟件生命周期(SDLC)的六個(gè)階段軟件危機(jī)的出現(xiàn)主要表現(xiàn)在：a. 由于缺乏大型軟件開(kāi)發(fā)經(jīng)驗(yàn)和軟件開(kāi)發(fā)數(shù)據(jù)積累，開(kāi)發(fā)工作計(jì)劃很難制定；b. 開(kāi)發(fā)早期需求分析不夠明確，造成開(kāi)發(fā)后期矛盾集中暴露；c. 不遵循開(kāi)發(fā)規(guī)范，開(kāi)發(fā)文檔不完整，軟件難以維護(hù)；d. 缺乏嚴(yán)密有效的軟件質(zhì)量檢測(cè)手段，交付給用戶的軟件質(zhì)量差。軟件危機(jī)的后果：a. 軟件質(zhì)量不高，很難穩(wěn)定；b. 軟件項(xiàng)目延期，進(jìn)度無(wú)法控制； c. 成本增加，無(wú)法控制預(yù)算。軟件危機(jī)的根源：a. 根據(jù)摩爾定律，硬件發(fā)展很快，相應(yīng)對(duì)軟件系統(tǒng)的期望越來(lái)越高； b. 軟件系統(tǒng)復(fù)雜性提高，需多人合作；c. 軟件開(kāi)發(fā)是人的智力活動(dòng)，無(wú)法用已有的產(chǎn)業(yè)工程方法來(lái)組

2、織管理。軟件生命周期(SDLC，軟件生存周期)是軟件的產(chǎn)生直到報(bào)廢的生命周期，周期內(nèi)有問(wèn)題定義、可行性分析、總體描述、系統(tǒng)設(shè)計(jì)、編碼、調(diào)試和測(cè)試、驗(yàn)收與運(yùn)行、維護(hù)升級(jí)到廢棄等階段，這種按時(shí)間分程的思想方法是軟件工程中的一種思想原則，即按部就班、逐步推進(jìn)，每個(gè)階段都要有定義、工作、審查、形成文檔以供交流或備查，以提高軟件的質(zhì)量。但隨著新的面向?qū)ο蟮脑O(shè)計(jì)方法和技術(shù)的成熟，軟件生命周期設(shè)計(jì)方法的指導(dǎo)意義正在逐步減少。1、問(wèn)題的定義及規(guī)劃      此階段是軟件開(kāi)發(fā)方與需求方共同討論，主要確定軟件的開(kāi)發(fā)目標(biāo)及其可行性。2、需求分析  

3、;    在確定軟件開(kāi)發(fā)可行的情況下，對(duì)軟件需要實(shí)現(xiàn)的各個(gè)功能進(jìn)行詳細(xì)分析。需求分析階段是一個(gè)很重要的階段，這一階段做得好，將為整個(gè)軟件開(kāi)發(fā)項(xiàng)目的成功打下良好的基礎(chǔ)。"唯一不變的是變化本身。"，同樣需求也是在整個(gè)軟件開(kāi)發(fā)過(guò)程中不斷變化和深入的，因此我們必須制定需求變更計(jì)劃來(lái)應(yīng)付這種變化，以保護(hù)整個(gè)項(xiàng)目的順利進(jìn)行。3、軟件設(shè)計(jì)      此階段主要根據(jù)需求分析的結(jié)果，對(duì)整個(gè)軟件系統(tǒng)進(jìn)行設(shè)計(jì)，如系統(tǒng)框架設(shè)計(jì)，數(shù)據(jù)庫(kù)設(shè)計(jì)等等。軟件設(shè)計(jì)一般分為總體設(shè)計(jì)和詳細(xì)設(shè)計(jì)。好的軟件設(shè)計(jì)將為軟件程序編寫(xiě)打下良好的基

4、礎(chǔ)。4、程序編碼      此階段是將軟件設(shè)計(jì)的結(jié)果轉(zhuǎn)換成計(jì)算機(jī)可運(yùn)行的程序代碼。在程序編碼中必須要制定統(tǒng)一，符合標(biāo)準(zhǔn)的編寫(xiě)規(guī)范。以保證程序的可讀性，易維護(hù)性，提高程序的運(yùn)行效率。5、軟件測(cè)試      在軟件設(shè)計(jì)完成后要經(jīng)過(guò)嚴(yán)密的測(cè)試，以發(fā)現(xiàn)軟件在整個(gè)設(shè)計(jì)過(guò)程中存在的問(wèn)題并加以糾正。整個(gè)測(cè)試過(guò)程分單元測(cè)試、集成測(cè)試以及系統(tǒng)測(cè)試三個(gè)階段進(jìn)行。測(cè)試的方法主要有白盒測(cè)試和黑盒測(cè)試兩種。在測(cè)試過(guò)程中需要建立詳細(xì)的測(cè)試計(jì)劃并嚴(yán)格按照測(cè)試計(jì)劃進(jìn)行測(cè)試，以減少測(cè)試的隨意性。6、運(yùn)行維護(hù)  

5、;    軟件維護(hù)是軟件生命周期中持續(xù)時(shí)間最長(zhǎng)的階段。在軟件開(kāi)發(fā)完成并投入使用后，由于多方面的原因，軟件不能繼續(xù)適應(yīng)用戶的要求。要延續(xù)軟件的使用壽命，就必須對(duì)軟件進(jìn)行維護(hù)。軟件的維護(hù)包括糾錯(cuò)性維護(hù)和改進(jìn)性維護(hù)兩個(gè)方面。2、軟件生命周期模型 任何軟件都是從最模糊的概念開(kāi)始的：為某個(gè)公司設(shè)計(jì)辦公的流程處理；設(shè)計(jì)一種商務(wù)信函打印系統(tǒng)并投放市場(chǎng)。這個(gè)概念是不清晰的，但卻是最高層的業(yè)務(wù)需求的原型。這個(gè)概念都會(huì)伴隨著一個(gè)目的，例如在一個(gè)"銀行押匯系統(tǒng)" 的目的是提高工作的效率。這個(gè)目的將會(huì)成為系統(tǒng)的核心思想，系統(tǒng)成敗的評(píng)判標(biāo)準(zhǔn)。99年政府部門(mén)上了大量的OA

6、系統(tǒng)，學(xué)過(guò)一點(diǎn)Lotus Notes的人都發(fā)了財(cái)（IBM更不用說(shuō)了），但是更普遍的情況是，許多的政府部門(mén)原有的處理模式并沒(méi)有變化，反而又加上了自動(dòng)化處理的一套流程。提高工作效率的初衷卻導(dǎo)致了完全不同的結(jié)果。這樣的軟件究竟是不是成功的呢？ 從概念提出的那一刻開(kāi)始，軟件產(chǎn)品就進(jìn)入了軟件生命周期。在經(jīng)歷需求、分析、設(shè)計(jì)、實(shí)現(xiàn)、部署后，軟件將被使用并進(jìn)入維護(hù)階段，直到最后由于缺少維護(hù)費(fèi)用而逐漸消亡。這樣的一個(gè)過(guò)程，稱為"生命周期模型"（Life Cycle Model）。 典型的幾種生命周期模型包括瀑布模型、快速原型模型、迭代模型。瀑布模型（Waterfall Model）首先由R

7、oyce提出。該模型由于酷似瀑布聞名。在該模型中，首先確定需求，并接受客戶和SQA小組的驗(yàn)證。然后擬定規(guī)格說(shuō)明，同樣通過(guò)驗(yàn)證后，進(jìn)入計(jì)劃階段可以看出，瀑布模型中至關(guān)重要的一點(diǎn)是只有當(dāng)一個(gè)階段的文檔已經(jīng)編制好并獲得SQA小組的認(rèn)可才可以進(jìn)入下一個(gè)階段。這樣，瀑布模型通過(guò)強(qiáng)制性的要求提供規(guī)約文檔來(lái)確保每個(gè)階段都能很好的完成任務(wù)。但是實(shí)際上往往難以辦到，因?yàn)檎麄€(gè)的模型幾乎都是以文檔驅(qū)動(dòng)的，這對(duì)于非專業(yè)的用戶來(lái)說(shuō)是難以閱讀和理解的。想象一下，你去買(mǎi)衣服的時(shí)候，售貨員給你出示的是一本厚厚的服裝規(guī)格說(shuō)明，你會(huì)有什么樣的感觸。雖然瀑布模型有很多很好的思想可以借鑒，但是在過(guò)程能力上有天生的缺陷。 迭代式模型

8、迭代式模型是RUP推薦的周期模型，也是我們?cè)谶@個(gè)系列文章討論的基礎(chǔ)。在RUP中，迭代被定義為：迭代包括產(chǎn)生產(chǎn)品發(fā)布（穩(wěn)定、可執(zhí)行的產(chǎn)品版本）的全部開(kāi)發(fā)活動(dòng)和要使用該發(fā)布必需的所有其它外圍元素。所以，在某種程度上，開(kāi)發(fā)迭代是一次完整地經(jīng)過(guò)所有工作流程的過(guò)程：（至少包括）需求工作流程、分析設(shè)計(jì)工作流程、實(shí)施工作流程和測(cè)試工作流程。實(shí)質(zhì)上，它類(lèi)似小型的瀑布式項(xiàng)目。RUP認(rèn)為，所有的階段（需求及其它）都可以細(xì)分為迭代。每一次的迭代都會(huì)產(chǎn)生一個(gè)可以發(fā)布的產(chǎn)品，這個(gè)產(chǎn)品是最終產(chǎn)品的一個(gè)子集。迭代的思想如上圖所示。 迭代和瀑布的最大的差別就在于風(fēng)險(xiǎn)的暴露時(shí)間上。"任何項(xiàng)目都會(huì)涉及到一定的風(fēng)險(xiǎn)。如果

9、能在生命周期中盡早確保避免了風(fēng)險(xiǎn)，那么您的計(jì)劃自然會(huì)更趨精確。有許多風(fēng)險(xiǎn)直到已準(zhǔn)備集成系統(tǒng)時(shí)才被發(fā)現(xiàn)。不管開(kāi)發(fā)團(tuán)隊(duì)經(jīng)驗(yàn)如何，都絕不可能預(yù)知所有的風(fēng)險(xiǎn)。"（RUP）二者的區(qū)別如下圖所示： 由于瀑布模型的特點(diǎn)（文檔是主體），很多的問(wèn)題在最后才會(huì)暴露出來(lái)，為了解決這些問(wèn)題的風(fēng)險(xiǎn)是巨大的。"在迭代式生命周期中，您需要根據(jù)主要風(fēng)險(xiǎn)列表選擇要在迭代中開(kāi)發(fā)的新的增量?jī)?nèi)容。每次迭代完成時(shí)都會(huì)生成一個(gè)經(jīng)過(guò)測(cè)試的可執(zhí)行文件，這樣就可以核實(shí)是否已經(jīng)降低了目標(biāo)風(fēng)險(xiǎn)。"（RUP） 快速原型（Rapid Prototype）模型是我喜歡采用的另一種模型。快速原型模型在功能上等價(jià)于產(chǎn)品的一個(gè)子

10、集。注意，這里說(shuō)的是功能上。瀑布模型的缺點(diǎn)就在于不夠直觀，快速原型法就解決了這個(gè)問(wèn)題。一般來(lái)說(shuō)，根據(jù)客戶的需要在很短的時(shí)間內(nèi)解決用戶最迫切需要，完成一個(gè)可以演示的產(chǎn)品。這個(gè)產(chǎn)品只是實(shí)現(xiàn)部分的功能（最重要的）。它最重要的目的是為了確定用戶的真正需求。在我的經(jīng)驗(yàn)中，這種方法非常的有效，原先對(duì)計(jì)算機(jī)沒(méi)有絲毫概念的用戶在你的原型面前往往口若懸河，有些觀點(diǎn)讓你都覺(jué)得非常的吃驚。在得到用戶的需求之后，原型將被拋棄。因?yàn)樵烷_(kāi)發(fā)的速度很快，設(shè)計(jì)方面是幾乎沒(méi)有考慮的，如果保留原型的話，在隨后的開(kāi)發(fā)中會(huì)為此付出極大的代價(jià)。至于保留原型方面，也是有一種叫做增量模型是這么做的，但這種模型并不為大家所接受，不在我們的

11、討論之內(nèi)。 上述的模型中都有自己獨(dú)特的思想，其實(shí)現(xiàn)在的軟件組織中很少說(shuō)標(biāo)準(zhǔn)的采用那一種模型的。模型和實(shí)用還是有很大的區(qū)別的。 軟件生命周期模型的發(fā)展實(shí)際上是體現(xiàn)了軟件工程理論的發(fā)展。在最早的時(shí)候，軟件的生命周期處于無(wú)序、混亂的情況。一些人為了能夠控制軟件的開(kāi)發(fā)過(guò)程，就把軟件開(kāi)發(fā)嚴(yán)格的區(qū)分為多個(gè)不同的階段，并在階段間加上嚴(yán)格的審查。這就是瀑布模型產(chǎn)生的起因。瀑布模型體現(xiàn)了人們對(duì)軟件過(guò)程的一個(gè)希望：嚴(yán)格控制、確保質(zhì)量?？上У氖?，現(xiàn)實(shí)往往是殘酷的。瀑布模型根本達(dá)不到這個(gè)過(guò)高的要求，因?yàn)檐浖倪^(guò)程往往難于預(yù)測(cè)。反而導(dǎo)致了其它的負(fù)面影響，例如大量的文檔、繁瑣的審批。因此人們就開(kāi)始嘗試著用其它的方法來(lái)改進(jìn)

12、或替代瀑布方法。例如把過(guò)程細(xì)分來(lái)增加過(guò)程的可預(yù)測(cè)性。補(bǔ)充：軟件開(kāi)發(fā)過(guò)程中的相關(guān)技術(shù)3.軟件測(cè)試概念廣義概念：指軟件生存周期中所有的檢查、評(píng)審和確認(rèn)工作，其中包括了對(duì)分析、設(shè)計(jì)階段，以及完成開(kāi)發(fā)后維護(hù)階段的各類(lèi)文檔、代碼的審查和確認(rèn)狹義概念：識(shí)別軟件缺陷的過(guò)程，即實(shí)際結(jié)果與預(yù)期結(jié)果的不一致4.軟件測(cè)試目的ü 測(cè)試的目的就是發(fā)現(xiàn)軟件中的各種缺陷ü 測(cè)試只能證明軟件存在缺陷，不能證明軟件不存在缺陷ü 測(cè)試可以使軟件中缺陷降低到一定程度，而不是徹底消滅ü 以較少的用例、時(shí)間和人力找出軟件中的各種錯(cuò)誤和缺陷，以確保軟件的質(zhì)量軟件測(cè)試的三層次：1.發(fā)現(xiàn)缺陷 2.盡早

13、的發(fā)現(xiàn)缺陷3.幫助開(kāi)發(fā)軟件盡早的發(fā)現(xiàn)缺陷。（體現(xiàn)了測(cè)試人員的價(jià)值）5軟件測(cè)試原則ü Good-enough: 一種權(quán)衡投入/產(chǎn)出比的原則ü 保證測(cè)試的覆蓋程度，但窮舉測(cè)試是不可能的ü 所有的測(cè)試都應(yīng)追溯到用戶需求ü 越早測(cè)試越好，測(cè)試過(guò)程與開(kāi)發(fā)過(guò)程應(yīng)是相結(jié)合的ü 測(cè)試的規(guī)模由小而大，從單元測(cè)試到系統(tǒng)測(cè)試ü 為了盡可能地發(fā)現(xiàn)錯(cuò)誤，應(yīng)該由獨(dú)立的第三方來(lái)測(cè)試ü 不能為了便于測(cè)試擅自修改程序ü 既應(yīng)該測(cè)試軟件該做什么也應(yīng)該測(cè)試軟件不該做什么6軟件測(cè)試的的重點(diǎn)ü 測(cè)試用例的設(shè)計(jì) 測(cè)試用例的設(shè)計(jì)是整個(gè)軟件測(cè)試工作的核

14、心 測(cè)試用例反映對(duì)被測(cè)對(duì)象的質(zhì)量要求，決定對(duì)測(cè)試對(duì)象的質(zhì)量評(píng)估ü 測(cè)試工作的管理 尤其是對(duì)包含多個(gè)子系統(tǒng)的大型軟件系統(tǒng)，其測(cè)試工作涉及大量人力和物力，有效的測(cè)試工作管理是保證有效測(cè)試工作的必要前提ü 測(cè)試環(huán)境的建立 測(cè)試環(huán)境應(yīng)該與實(shí)際測(cè)試環(huán)境一致7軟件測(cè)試的幾種常用模型W模型由Evolutif公司提出，相對(duì)于V模型，W模型增加了軟件各開(kāi)發(fā)階段中應(yīng)同步進(jìn)行的驗(yàn)證和確認(rèn)活動(dòng)。W模型由兩個(gè)V字型模型組成，分別代表測(cè)試與開(kāi)發(fā)過(guò)程，圖中明確表示出了測(cè)試與開(kāi)發(fā)的并行關(guān)系。W模型強(qiáng)調(diào)：測(cè)試伴隨著整個(gè)軟件開(kāi)發(fā)周期，而且測(cè)試的對(duì)象不僅僅是程序，需求、設(shè)計(jì)等同樣要測(cè)試，也就是說(shuō)，測(cè)試與開(kāi)發(fā)是同

15、步進(jìn)行的。W模型有利于盡早地全面的發(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)度。但W模型也存在局限性。在W模型中，需求、設(shè)計(jì)、編碼等活動(dòng)被視為串行的，同時(shí)，測(cè)試和開(kāi)發(fā)活動(dòng)也保持著一種線性的前后關(guān)系，上一階段完全結(jié)束，才可正式開(kāi)始下一個(gè)階段工作。這樣就無(wú)法支持迭代的開(kāi)發(fā)模型。對(duì)于當(dāng)前軟件開(kāi)發(fā)復(fù)雜多變的情況，W模型并不能解除測(cè)試管理面臨著困惑。X模型是由Marick提出的，他的目標(biāo)是彌補(bǔ)V模型的一些缺陷，例如：交接、經(jīng)常性的集成等問(wèn)題

16、。     X模型的左邊描述的是針對(duì)單獨(dú)程序片段所進(jìn)行的相互分離的編碼和測(cè)試，此后將進(jìn)行頻繁的交接，通過(guò)集成最終合成為可執(zhí)行的程序。右上半部分，這些可執(zhí)行程序還需要進(jìn)行測(cè)試。已通過(guò)集成測(cè)試的成品可以進(jìn)行封版并提交給用戶，也可以作為更大規(guī)模和范圍內(nèi)集成的一部分。多根并行的曲線表示變更可以在各個(gè)部分發(fā)生。      X模型還定位了探索性測(cè)試（右下方）。這是不進(jìn)行事先計(jì)劃的特殊類(lèi)型的測(cè)試，諸如“我這么測(cè)一下結(jié)果會(huì)怎么樣？”，這一方式往往能幫助有經(jīng)驗(yàn)的測(cè)試人員在測(cè)試計(jì)劃之外發(fā)現(xiàn)更多的軟件錯(cuò)誤。  

17、60;   但V模型的一個(gè)強(qiáng)項(xiàng)是它明確的需求角色的確認(rèn)，而X模型沒(méi)有這么做，這大概是X模型的一個(gè)不足之處。 而且由于X模型從沒(méi)有被文檔化，其內(nèi)容一開(kāi)始需要從V模型的相關(guān)內(nèi)容中進(jìn)行推斷，因?yàn)樗€沒(méi)有完全從文字上成為V模型的全面擴(kuò)展。V 模型 ：“V”的左端表示傳統(tǒng)的瀑布開(kāi)發(fā)模型，而“V”右端表明相應(yīng)的測(cè)試階段。在V模型中，每一個(gè)開(kāi)發(fā)階段和一個(gè)相應(yīng)的測(cè)試階段相連。當(dāng)工作進(jìn)行到某個(gè)特定的開(kāi)發(fā)階段時(shí)，就要執(zhí)行相應(yīng)測(cè)試階段的計(jì)劃和一些基本的設(shè)計(jì)工作。用戶需求單元測(cè)試編碼集成測(cè)試概要設(shè)計(jì)詳細(xì)設(shè)計(jì)需求說(shuō)明系統(tǒng)測(cè)試驗(yàn)收測(cè)試8黑盒測(cè)試ü 什么是黑盒測(cè)試 又稱功能測(cè)試或數(shù)據(jù)驅(qū)動(dòng)測(cè)試，

18、是針對(duì)軟件的功能需求/實(shí)現(xiàn)進(jìn)行測(cè)試，通過(guò)測(cè)試來(lái)檢測(cè)每個(gè)功能是否符合需求，不考慮程序內(nèi)部的邏輯結(jié)構(gòu)ü 黑盒測(cè)試方法 功能劃分 等價(jià)類(lèi)劃分 邊界值分析 因果圖 錯(cuò)誤推測(cè)等9什么是白盒測(cè)試 白盒測(cè)試也稱結(jié)構(gòu)測(cè)試或邏輯驅(qū)動(dòng)測(cè)試，必須知道軟件內(nèi)部工作過(guò)程，通過(guò)測(cè)試來(lái)檢測(cè)軟件內(nèi)部是否按照需求、設(shè)計(jì)正常運(yùn)行 白盒測(cè)試的主要方法 對(duì)應(yīng)于程序的一些主要結(jié)構(gòu)：語(yǔ)句、分支、邏輯路徑、變量；白盒測(cè)試的主要方法是： 語(yǔ)句覆蓋方法 分支覆蓋方法 邏輯覆蓋方法10.什么是動(dòng)態(tài)測(cè)試動(dòng)態(tài)測(cè)試需要在開(kāi)發(fā)/測(cè)試環(huán)境或?qū)嶋H運(yùn)行環(huán)境中運(yùn)行軟件，并使用測(cè)試用例去查找軟件缺陷；動(dòng)態(tài)測(cè)試包括功能確認(rèn)與接口測(cè)試、覆蓋率分析、性能分析

19、、內(nèi)存分析等 11.什么是靜態(tài)測(cè)試靜態(tài)測(cè)試不實(shí)際運(yùn)行軟件，主要是對(duì)軟件的編程格式、結(jié)構(gòu)等方面進(jìn)行評(píng)估.靜態(tài)測(cè)試包括代碼檢查、程序結(jié)構(gòu)分析、代碼質(zhì)量度量等。它可以由人工進(jìn)行，也可以借助軟件工具自動(dòng)進(jìn)行 12.手工測(cè)試和自動(dòng)測(cè)試a.手工測(cè)試缺點(diǎn)在于測(cè)試工作量大，重復(fù)多，回歸測(cè)試難以實(shí)現(xiàn)b.自動(dòng)測(cè)試?yán)密浖y(cè)試工具自動(dòng)實(shí)現(xiàn)全部或部分測(cè)試工作：管理、設(shè)計(jì)、執(zhí)行和報(bào)告；節(jié)省大量的測(cè)試開(kāi)銷(xiāo)，并能夠完成一些手工測(cè)試無(wú)法實(shí)現(xiàn)的測(cè)試ü 手工完成測(cè)試的全部過(guò)程無(wú)法保證測(cè)試的科學(xué)性與嚴(yán)密性: 修改的缺陷越多，回歸測(cè)試越困難 沒(méi)有人能向決策層提供精確的數(shù)據(jù)以度量當(dāng)前的工作進(jìn)度及工作效率 反復(fù)測(cè)試帶來(lái)的倦怠情

20、緒及其它人為因素使得測(cè)試標(biāo)準(zhǔn)前后不一 測(cè)試花費(fèi)的時(shí)間越長(zhǎng)，測(cè)試的嚴(yán)格性也就越低ü 自動(dòng)測(cè)試將測(cè)試人員從反復(fù)、煩雜的測(cè)試執(zhí)行中解放出來(lái)，用更多的時(shí)間進(jìn)行測(cè)試設(shè)計(jì)和結(jié)果分析ü 軟件測(cè)試不可能完全自動(dòng)化ü 不能完成所有手工測(cè)試任務(wù)ü 無(wú)創(chuàng)造性且靈活性差，不能改進(jìn)測(cè)試的有效性ü 過(guò)程中可能會(huì)遇到許多意想不到的問(wèn)題，特別是當(dāng)軟件不穩(wěn)定時(shí)ü 測(cè)試腳本的維護(hù)高13. 測(cè)試流程ü 單元測(cè)試ü 集成測(cè)試ü 系統(tǒng)測(cè)試ü 用戶驗(yàn)收測(cè)試ü 回歸測(cè)試14.單元測(cè)試ü 完成對(duì)最小的軟件設(shè)計(jì)單元模塊的驗(yàn)證

21、工作ü 目標(biāo)是確保模塊被正確地編碼ü 使用過(guò)程設(shè)計(jì)描述作為指南，對(duì)重要的控制路徑進(jìn)行測(cè)試以發(fā)現(xiàn)模塊內(nèi)的錯(cuò)誤ü 通常情況下是面向白盒的ü 對(duì)代碼風(fēng)格和規(guī)則、程序設(shè)計(jì)和結(jié)構(gòu)、業(yè)務(wù)邏輯等進(jìn)行靜態(tài)測(cè)試，及早地發(fā)現(xiàn)和解決不易顯現(xiàn)的錯(cuò)誤ü 單元測(cè)試的內(nèi)容 接口測(cè)試 內(nèi)部數(shù)據(jù)結(jié)構(gòu) 全局?jǐn)?shù)據(jù)結(jié)構(gòu) 邊界 語(yǔ)句覆蓋，錯(cuò)誤路徑15.集成測(cè)試ü 通過(guò)測(cè)試發(fā)現(xiàn)與模塊接口有關(guān)的問(wèn)題ü 目標(biāo)是把通過(guò)了單元測(cè)試的模塊拿來(lái)，構(gòu)造一個(gè)在設(shè)計(jì)中所描述的程序結(jié)構(gòu) ü 應(yīng)當(dāng)避免一次性的集成（除非軟件規(guī)模很小），而采用增量集成集成測(cè)試主要內(nèi)容ü A

22、PIü API/參數(shù)組合16系統(tǒng)測(cè)試ü 根據(jù)軟件需求規(guī)范的要求進(jìn)行系統(tǒng)測(cè)試，確認(rèn)系統(tǒng)滿足需求的要求ü 系統(tǒng)測(cè)試人員相當(dāng)于用戶代言人ü 在需求分析階段要確定軟件的可測(cè)性，保證有效完成系統(tǒng)測(cè)試工作ü 系統(tǒng)測(cè)試主要內(nèi)容ü 所有功能需求得到滿足ü 所有性能需求得到滿足ü 其它需求（例如安全性、容錯(cuò)性、兼容性等）得到滿足17.用戶驗(yàn)收/確認(rèn)測(cè)試ü Alpha測(cè)試 是由用戶在開(kāi)發(fā)者的場(chǎng)所來(lái)進(jìn)行的，Alpha測(cè)試是在一個(gè)受控的環(huán)境中進(jìn)行的ü Beta測(cè)試 由軟件的最終用戶在一個(gè)或多個(gè)用戶場(chǎng)所來(lái)進(jìn)行的，開(kāi)發(fā)者通

23、常不在現(xiàn)場(chǎng)，用戶記錄測(cè)試中遇到的問(wèn)題并報(bào)告給開(kāi)發(fā)者18壓力測(cè)試VS性能測(cè)試  性能測(cè)試的目的不是去找bugs,而是排除系統(tǒng)的瓶頸，以及為以后的回歸測(cè)試建立一個(gè)基準(zhǔn)。而性能測(cè)試的操作，實(shí)際上就是一個(gè)非常小心受控的測(cè)量分析過(guò)程。在理想的情況下，被測(cè)軟件在這個(gè)時(shí)候已經(jīng)是足夠穩(wěn)定了性能測(cè)試是為了檢查系統(tǒng)的反映，運(yùn)行速度等性能指標(biāo)，他的前提是要求在一定負(fù)載下，如檢查一個(gè)網(wǎng)站在100人同時(shí)在線的情況下的性能指標(biāo)，每個(gè)用戶是否都還可以正常的完成操作等。概括就是：在不同負(fù)載下（負(fù)載一定）時(shí)，通過(guò)一些系統(tǒng)參數(shù)（如反應(yīng)時(shí)間等）檢查系統(tǒng)的運(yùn)行情況；壓力測(cè)試是為了發(fā)現(xiàn)系統(tǒng)能支持的最大負(fù)載，他的前提是要求系統(tǒng)

24、性能處在可以接受的范圍內(nèi)，比如經(jīng)常規(guī)定的葉面3秒鐘內(nèi)響應(yīng)；概括就是：在性能可以接受的前提下，測(cè)試系統(tǒng)可以支持的最大負(fù)載。舉例說(shuō)明：針對(duì)一個(gè)網(wǎng)站進(jìn)行測(cè)試，模擬10到50個(gè)用戶就是在進(jìn)行常規(guī)性能測(cè)試，用戶增加到1000乃至上萬(wàn)就變成了壓力/負(fù)載測(cè)試。如果同時(shí)對(duì)系統(tǒng)進(jìn)行大量的數(shù)據(jù)查詢操作，就包含了強(qiáng)度測(cè)試。19. 主流測(cè)試工具的測(cè)試流程1.自動(dòng)化測(cè)試工具=loadrunner=1制定負(fù)載測(cè)試計(jì)劃(分析應(yīng)用程序， 確定測(cè)試目標(biāo)，計(jì)劃怎樣執(zhí)行LoadRunner）2開(kāi)發(fā)測(cè)試腳本（錄制基本的用戶腳本，完善測(cè)試腳本）3創(chuàng)建運(yùn)行場(chǎng)景（選擇場(chǎng)景類(lèi)型為Manual Scenario，選擇場(chǎng)景類(lèi)型，理解各種類(lèi)型，場(chǎng)景的類(lèi)型轉(zhuǎn)化）4運(yùn)行測(cè)試5監(jiān)視場(chǎng)景（MEMORY 相關(guān)，PROCESSOR相關(guān)，網(wǎng)絡(luò)吞量以及帶寬，磁盤(pán)相關(guān)，WEB應(yīng)用程序