軟件開發(fā)里面單元測試是用來做什么的?

單元測試是開發(fā)者編寫的一小段代碼，用于檢驗(yàn)被測代碼的一個很小的、很明確的功能是否正確。通常而言，一個單元測試是用于判斷某個特定條件(或者場景)下某個特定函數(shù)的行為。例如，你可能把一個很大的值放入一個有序list 中去，然后確認(rèn)該值出現(xiàn)在list 的尾部?；蛘?，你可能會從字符串中刪除匹配某種模式的字符，然后確認(rèn)字符串確實(shí)不再包含這些字符了。
執(zhí)行單元測試，是為了證明某段代碼的行為確實(shí)和開發(fā)者所期望的一致。
為什么需要單元測試?
當(dāng)編寫項(xiàng)目的時刻，如果我們假設(shè)底層的代碼是正確無誤的，那么先是高層代碼中使用了底層代碼;然后這些高層代碼又被更高層的代碼所使用，如此往復(fù)。當(dāng)基本的底層代碼不再可靠時，那么必需的改動就無法只局限在底層。雖然你可以修正底層的問題，但是這些對底層代碼的修改必然會影響到高層代碼。于是，一個對底層代碼的修正，可能會導(dǎo)致對幾乎所有代碼的一連串改動，從而使修改越來越多，也越來越復(fù)雜。從而使整個項(xiàng)目也以失敗告終。
單元測試針對程序模塊，進(jìn)行正確性檢驗(yàn)的測試。其目的在于發(fā)現(xiàn)各模塊內(nèi)部可能存在的各種差錯。單元測試需要從程序的內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計測試用例。多個模塊可以平行地獨(dú)立進(jìn)行單元測試。

請問單元測試、集成測試、系統(tǒng)測試的側(cè)重點(diǎn)是什么？

單元測試是在軟件開發(fā)過程中要進(jìn)行的最低級別的測試活動，在單元測試活動中，軟件的獨(dú)立單元將在與程序的其他部分相隔離的情況下進(jìn)行測試，測試重點(diǎn)是系統(tǒng)的模塊，包括子程序的正確性驗(yàn)證等。

集成測試，也叫組裝測試或聯(lián)合測試。在單元測試的基礎(chǔ)上，將所有模塊按照設(shè)計要求，組裝成為子系統(tǒng)或系統(tǒng)，進(jìn)行集成測試。實(shí)踐表明，一些模塊雖然能夠單獨(dú)地工作，但并不能保證連接起來也能正常的工作。程序在某些局部反映不出來的問題，在全局上很可能暴露出來，影響功能的實(shí)現(xiàn)。測試重點(diǎn)是模塊間的銜接以及參數(shù)的傳遞等。

3.系統(tǒng)測試是將經(jīng)過測試的子系統(tǒng)裝配成一個完整系統(tǒng)來測試。它是檢驗(yàn)系統(tǒng)是否確實(shí)能提供系統(tǒng)方案說明書中指定功能的有效方法。測試重點(diǎn)是整個系統(tǒng)的運(yùn)行以及與其他軟件的兼容性。

什么是單元測試（軟件工程）

單元測試是在軟件開發(fā)過程中要進(jìn)行的最低級別的測試活動，在單元測試活動中，軟件的獨(dú)立單元將在與程序的其他部分相隔離的情況下進(jìn)行測試。 單元測試不僅僅是作為無錯編碼一種輔助手段在一次性的開發(fā)過程中使用，單元測試必須是可重復(fù)的，無論是在軟件修改，或是移植到新的運(yùn)行環(huán)境的過程中。因此，所有的測試都必須在整個軟件系統(tǒng)的生命周期中進(jìn)行維護(hù)。

1.為什么說軟件測試是軟件開發(fā)中不可缺少的重要一環(huán),但不是軟件質(zhì)量保證的安全網(wǎng)

你說的前半句我沒異議, 后半句可以討論一下.
根據(jù)軟件工程的思想, 軟件測試是檢測軟件功能和性能的一個流程, 如果沒有軟件測試, 那么軟件的正常使用將得不到保障. 軟件的風(fēng)險將會很大.
軟件測試在實(shí)際執(zhí)行過程中不能100%的找出軟件的所有問題, 如果軟件產(chǎn)品中有潛在的大問題沒有被發(fā)現(xiàn), 同樣會有隱患.
但是經(jīng)過嚴(yán)格流程測試過的軟件, 一般不會出現(xiàn)致命的問題, 當(dāng)然, 小問題應(yīng)該會有. 所以說軟件測試是軟件質(zhì)量的保障. 至于說是安全網(wǎng), 這個詞個人覺得用的很模糊.
還有什么問題我們可以討論, 相互學(xué)習(xí)..

單元測試的介紹

單元測試（unit testing），是指對軟件中的最小可測試單元進(jìn)行檢查和驗(yàn)證。對于單元測試中單元的含義，一般來說，要根據(jù)實(shí)際情況去判定其具體含義，如C語言中單元指一個函數(shù)，Java里單元指一個類，圖形化的軟件中可以指一個窗口或一個菜單等?？偟膩碚f，單元就是人為規(guī)定的最小的被測功能模塊。單元測試是在軟件開發(fā)過程中要進(jìn)行的最低級別的測試活動，軟件的獨(dú)立單元將在與程序的其他部分相隔離的情況下進(jìn)行測試。在一種傳統(tǒng)的結(jié)構(gòu)化編程語言中，比如C，要進(jìn)行測試的單元一般是函數(shù)或子過程。在像C++這樣的面向?qū)ο蟮恼Z言中， 要進(jìn)行測試1的基本單元是類。對Ada語言來說，開發(fā)人員可以選擇是在獨(dú)立的過程和函數(shù)，還是在Ada包的級別上進(jìn)行單元測試。單元測試的原則同樣被擴(kuò)展到第四代語言（4GL)的開發(fā)中，在這里基本單元被典型地劃分為一個菜單或顯示界面。經(jīng)常與單元測試聯(lián)系起來的另外一些開發(fā)活動包括代碼走讀（Code review)，靜態(tài)分析（Static analysis)和動態(tài)分析（Dynamic analysis)。靜態(tài)分析就是對軟件的源代碼進(jìn)行研讀，查找錯誤或收集一些度量數(shù)據(jù)，并不需要對代碼進(jìn)行編譯和執(zhí)行。動態(tài)分析就是通過觀察軟件運(yùn)行時的動作，來提供執(zhí)行跟蹤，時間分析，以及測試覆蓋度方面的信息。

在開發(fā)過程中怎樣利用單元和功能測試

這種方法要求我為新加入的每個函數(shù)都編寫單元測試，并且維護(hù)這些測試。沒有通過單元測試，我就不能將任何一個的代碼加到模塊中。在代碼基數(shù)增長的同時，這些測試允許開發(fā)者有依據(jù)地將改變集成起來。起初，我認(rèn)為這些單元測試就足以應(yīng)付全局，沒有必要涉及到功能測試。噢，又錯了。功能測試和單元測試完全不同的兩者。我花費(fèi)了很長的時間才理解到兩者的區(qū)別，以及如何將它們結(jié)合起來，用以改進(jìn)開發(fā)進(jìn)程。 本文探討了單元測試和功能測試之間的差別，同時介紹在你的日常開發(fā)的過程中如何來利用它測試和開發(fā)過程作為一個開發(fā)人員，測試如此之重要，以至于你甚至應(yīng)該花費(fèi)幾乎所有的時間來完成它。它不僅需要只被劃分為開發(fā)過程中的某個特定階段。顯然，它不該是在你把系統(tǒng)交付給客戶之前完成的最后一項(xiàng)任務(wù)。然而，你又如何得知它在何時結(jié)束呢？或是你如何得知是否因?yàn)樾薷囊粋€微小的bug而破壞了系統(tǒng)的主要功能呢？或是系統(tǒng)可能會演化成超乎現(xiàn)在想象的模樣？測試，單元的和功能的都應(yīng)該是開發(fā)的過程中的一部分。 單元測試應(yīng)成為你編寫代碼的核心環(huán)節(jié)，尤其當(dāng)你在從事一個項(xiàng)目時，緊張的時間約束你的開發(fā)進(jìn)度，你也很想讓它是在可控的有序下進(jìn)行。我希望測試也是在你編寫代碼之前編寫測試時的重要內(nèi)容。 一套適用的單元測試應(yīng)具備以下功能： 說明可能的最佳適用設(shè)計 提供類文檔的最佳格式 判斷一個類何時完成 增強(qiáng)開發(fā)人員對代碼的信心 是快速重構(gòu)的基礎(chǔ) 在系統(tǒng)中自然要包含單元測試所需的設(shè)計文檔。重新閱讀它，你會發(fā)現(xiàn)這是軟件開發(fā)進(jìn)程中的圣杯，文檔跟隨系統(tǒng)的變化而逐步演化。為每一個類提供完備的文檔比起為它提供一系列的使用框架，或是一系列可控的輸入要好得多。這樣，設(shè)計文檔就會因?yàn)閱卧獪y試的逐步通過而隨時更新。 你應(yīng)該在你編寫代碼之前完成編寫測試的工序。這樣做會為測試所涉及的類提供設(shè)計方案，并促使你關(guān)注代碼中更小的程序模塊。這種練習(xí)也會使設(shè)計方案變得更加簡單。你不能試圖去了解將來的情形，去實(shí)現(xiàn)不必要的功能。編寫測試工作也會讓你清楚類會在什么時間結(jié)束。可以說，當(dāng)所有的測試通過時，任務(wù)也就完成了。 最后，單元測試會提供給你更高級別的依據(jù)，這絕對會滿足開發(fā)者的。如果你在改動代碼的同時，進(jìn)行單元測試，你就會在你破壞的同時立即察覺到事態(tài)的發(fā)生。 功能測試甚至比單元測試更加重要，因?yàn)樗鼈冋f明了你的系統(tǒng)就要預(yù)備發(fā)布了。功能測試將把你的工作系統(tǒng)放置于一個可用的狀態(tài)中。 一套適用的功能測試應(yīng)具備以下功能： 有效地掌握用戶的需求 向項(xiàng)目組成員（包括用戶和開發(fā)者）給出系統(tǒng)面臨這些需求的依據(jù) 功能測試要在有效地情況下掌握用戶的需求。而傳統(tǒng)的開發(fā)者是在使用的過程中發(fā)現(xiàn)需求的。通常，人們贊同使用項(xiàng)目工程并且花費(fèi)相當(dāng)?shù)臅r間去重新定制它們。當(dāng)它們被完成時，它們所得到的僅僅是一堆廢紙。功能測試?yán)淄谧孕猩У氖褂庙?xiàng)目的情況。極端程序設(shè)計方法（）能夠說明這種概念。XP 的說法就是對未來發(fā)生在用戶和開發(fā)者之間的交流技巧的描述。功能測試也是這種交流的結(jié)果。而沒有功能測試，這種說法也不會建立起來的。 功能測試恰好填充了在單元測試和向項(xiàng)目小組提交的代碼依據(jù)之間的空隙。單元測試會漏過許多的bug。它可以給出代碼中你所需的所有有效部分，它也會給你所需的整個系統(tǒng)。功能測試可以使單元測試?yán)锫┑舻膯栴}曝光。一系列可維護(hù)的，自動化的功能測試也會有漏網(wǎng)的情況，但是它至少比獨(dú)立地進(jìn)行最全面的單元測試要有用得多。 單元測試VS 功能測試 單元測試告訴開發(fā)者代碼使事情正確地被執(zhí)行，而功能測試所說的則是代碼在正確地發(fā)揮功效。 單元測試 單元測試是從開發(fā)者的角度來編寫的。它們確保類的每個特定方法成功執(zhí)行一系列特定的任務(wù)。每一個測試都要保證對于給定的一個已知的輸入應(yīng)該得到所期望的輸出。 編寫一系列可維護(hù)、自動化、沒有測試框架的單元測試幾乎是不可能的。在你開始之前，選擇一個項(xiàng)目小組都認(rèn)可的框架。不斷地應(yīng)用它，逐漸地喜歡它。在極端編程的介紹網(wǎng)頁上（見資源一節(jié)），有很多適用的單元測試框架。我喜歡用的是Juint 來進(jìn)行Java 代碼的測試。</P> 功能測試 功能測試則是從用戶的角度來編寫的。這些測試保證系統(tǒng)能夠按照用戶所期望的那樣去運(yùn)行。很多時候，開發(fā)一個完整的系統(tǒng)更像是建造一座大樓。當(dāng)然，這種比喻并不是完全地恰當(dāng)，但我們可以擴(kuò)展它，來理解單元測試和功能測試之間的區(qū)別。 單元測試類似于一個建筑檢查員對房屋的建設(shè)現(xiàn)場進(jìn)行檢查。他注重的是房屋內(nèi)部不同的系統(tǒng)，地基，架構(gòu)設(shè)計，電氣化，垂直的線條等等。他檢查房屋的某個部分，以確保它在安全狀態(tài)下，正確無誤地工作，即是說，直接針對房屋的代碼。功能測試在這個劇本里類似于房屋的主人在檢查同樣的建設(shè)場地。他所期望的是房屋的內(nèi)部系統(tǒng)正常地運(yùn)轉(zhuǎn)，并且房屋檢查員執(zhí)行了他的任務(wù)。房屋的主人看重的是生活在這樣的房屋中會是什么樣子。他關(guān)注這間房屋的外貌，不同的房間有合適的空間，房屋適用于家庭的需要，窗戶恰好位于最佳采光的位置。房屋的主人運(yùn)行的是對房屋的功能測試，他站在用戶的角度上。房屋檢查員運(yùn)行的是單元測試，他是站在建設(shè)者的角度上。 象單元測試一樣，編寫一系列可維護(hù)、自動化、沒有測試框架的功能測試幾乎是不可能的。Junit在單元測試方面做得很好；然而，它在試圖編寫功能測試時就顯得比較松散。Junit 不等同于功能測試?，F(xiàn)在已經(jīng)有滿足這個功能的產(chǎn)品問世了，但是我還沒有看到它們被應(yīng)用于開發(fā)產(chǎn)品過程里。如果你不能找到一個測試框架的話，就只好自己創(chuàng)建一個了。無論我們在建立一個項(xiàng)目時多么聰明，建立的系統(tǒng)多么靈活，如果我們的產(chǎn)品不能用，我們就是在浪費(fèi)時間。結(jié)論是，功能測試是開發(fā)進(jìn)程中最重要的一部分。 因?yàn)閮煞N類型的測試都是必要的，你會需要編寫它們的指南。 如何編寫單元測試<BR></STRONG>在你開始編寫單元測試很容易被激動的情緒感染。最簡單的起步方式就是為新的代碼創(chuàng)建單元測試。為已經(jīng)存在的代碼創(chuàng)建單元測試是一種比較有難度的開始方式，但是也是可行的。）從新的代碼開始，習(xí)慣了這樣的步驟后，還要堅持重新閱讀現(xiàn)有代碼，并為它們創(chuàng)建一套測試程序。 就像前面提到過的一樣，你應(yīng)該在你編寫要測試的代碼之前編寫單元測試。如何做到為還不存在的事物編寫測試呢？好問題！掌握這個能力需要90％的智力和10％技巧。我的意思是你只需假裝是在為已有的類編寫測試。接下來，進(jìn)行編寫的工作。最初，你將出現(xiàn)很多語法錯誤，但是let it be，不要理會它。緊接著進(jìn)行單元測試，修改語法錯誤（即是說，只用你自己定義的測試接口來實(shí)現(xiàn)類），再一次進(jìn)行測試。重復(fù)這個過程，每一次都寫下充足的代碼去修改錯誤，進(jìn)行測試直到它們通過為止。當(dāng)所有的單元測試都通過時，代碼才算真正地完成了。 一般地說，你的類應(yīng)具有開放的單元測試方式。然而，帶有直截了當(dāng)?shù)墓δ苄缘姆椒ū热缯f，Java 語言里的Getting 和Setting 讀寫方法，就不需要單元測試，除非它們是以“特殊”的方式進(jìn)行的。接下來的指導(dǎo)就是，當(dāng)你感到需要對代碼中的某些特性添加注釋時，同時要編寫出單元測試。如果你同很多的程序員一樣，厭惡為代碼寫注釋，單元測試就是將你的代碼的特性文檔化的一種好方法。 將單元測試同被測試的相關(guān)的類打包在一起。（這種組織的方式允許每一個單元測試都能夠直接訪問類中被打包和保護(hù)的方法和參數(shù)）。要避免在單元測試中用到域?qū)ο螅╠omain object）。域?qū)ο缶褪菍τ谝粋€應(yīng)用程序特定的對象。 例如，電子表格應(yīng)用程序有個工作簿對象，它就是一個域?qū)ο蟆Ｈ绻愕囊粋€類已經(jīng)知道了域?qū)ο?，在你的測試中用到這些對象是很好的。但是如果你的類沒有涉及到這些對象，就不要在測試?yán)镒屗鼈兺惣m纏不清了。不這樣做的話，就會產(chǎn)生打包的代碼被重用。經(jīng)常是為一個項(xiàng)目創(chuàng)建的類也可以應(yīng)用于其他的項(xiàng)目，這樣可能會出現(xiàn)直接重用這些類的情況。但是如果針對這些類的測試也用于另外的項(xiàng)目對象，讓測試生效會很費(fèi)時，通常測試不是被拋棄掉就是被重新編寫。 以上的一些技巧會讓你從中受益，但最重要的是如果你不實(shí)際地去做，就永遠(yuǎn)不會對單元測試有全面、深入的理解。更早地運(yùn)行測試，并且在整個過程中都在代碼中給出全面的依據(jù)。當(dāng)項(xiàng)目進(jìn)展時，你會隨時添加更多的特性。運(yùn)行測試就會提醒你，實(shí)現(xiàn)剛添加的特性會不會破壞已有的東西。 在你已經(jīng)掌握編寫單元測試的技巧之后，你需要重新閱讀已存在的代碼。的確，為它們編寫代碼可能會是一場挑戰(zhàn)。但是千萬不要為了測試的目的而測試?？梢哉f，編寫測試是一件緊跟時效的事情，尤其是當(dāng)你發(fā)現(xiàn)要修改一個沒有好的測試程序的類時，那就是添加測試的恰當(dāng)時機(jī)。和平常一樣，單元測試應(yīng)該具備類每個方法的特性。實(shí)現(xiàn)測試的一個最簡單的方法就是，測試的同時一定要注意代碼的注釋。在單元測試中，不能放過任何一個注釋，在描述測試方法的開始就要為單元測試添加大量的注釋中。 如何編寫功能測試 盡管功能測試是如此重要，它也有個開發(fā)過程里丑陋的繼生子的壞名聲。在大多數(shù)的項(xiàng)目里，是由一個獨(dú)立的工作組來完成功能測試的工作。通常需要一群人在系統(tǒng)中的相互協(xié)助才能保證工序的正確運(yùn)行。這種通常的看法和隊伍的組建的做法，都是非常愚蠢的。 功能測試同單元測試相類似。一旦要編寫有用戶涉入的產(chǎn)品的代碼（例如，對話框）時，就要編寫測試，但是一定要在實(shí)際編寫代碼之前做。一旦你開始了一項(xiàng)新任務(wù)，就要在功能測試的框架里清楚地描述這個任務(wù)的內(nèi)容。你加入的新代碼的同時進(jìn)行單元測試，開發(fā)工作就向前持續(xù)進(jìn)行。 當(dāng)所有的單元測試都進(jìn)行通過后，再進(jìn)行最初的功能測試來判斷項(xiàng)目是否可以通過，或是需要修改。理想的狀況下，功能測試小組的概念應(yīng)該不存在的。開發(fā)者應(yīng)該同用戶一同編寫功能測試。系統(tǒng)通過了一系列的單元測試后，負(fù)責(zé)進(jìn)行功能測試的小組成員就要改變初試測試的參數(shù)，再進(jìn)行系統(tǒng)的功能測試。 單元測試和功能測試之間的界線<BR></STRONG>一般情況下，很難劃清在單元測試和功能測試之間的界限。說實(shí)話，一直以來，我就不知道這個界線應(yīng)該定在哪里。當(dāng)編寫單元測試時，我用以下幾個方法來判定單元測試是不是已經(jīng)變成了功能測試：<BR>如果單元測試超越了類之間的界限，它可能變成了功能測試<BR>如果單元測試變得非常的復(fù)雜，它可能變成了功能測試<BR>如果單元測試變得很脆弱（即是說，它已經(jīng)成為一個測試，但是卻因?yàn)橐喜煌脩粜枨蟮母淖兌粍拥刈兓?，它可能變成了功能測試<BR>如果單元測試比需要測試的代碼還要難于編寫，它可能變成了功能測試 注意“它可能變成了功能測試”的說法，在這里沒有嚴(yán)格的標(biāo)準(zhǔn)。在單元測試和功能測試之間是有界線的，但是你必須自己判定它在哪里。單元測試進(jìn)行地順利，特定的測試逾越兩者界線的過渡就越明顯。 結(jié)論 單元測試以開發(fā)者的角度來編寫，并注重被測試類的特性。當(dāng)編寫單元測試時，利用以下幾條指導(dǎo)： 在類代碼進(jìn)行測試之前編寫單元測試 在單元測試?yán)镎莆沾a的注釋 測試所有執(zhí)行特定功能的公用程序（即是說，和Java 語言中的Getting 和Setting 讀寫方法不同的方法。除非它們是通過一種特殊的方式來完成Getting 和Setting 功能的。） 將所有的測試項(xiàng)目同被測試的類打包在一起，并且分配它們對在模塊包內(nèi)的和被保護(hù)成員的訪問權(quán)限 在單元測試中避免使用某些特定的對象 功能測試也需要從用戶的角度出發(fā)來編寫，并且注重用戶所感興趣的系統(tǒng)功能。選擇一個適當(dāng)?shù)墓δ軠y試框架，或是開發(fā)出一種，并利用這些功能測試來制定用戶們想要的東西。通過這種方式，功能測試的人員可以獲得一個自動的工具，并且對使用工具的習(xí)慣有了一個好的起點(diǎn)。 將單元測試和功能測試作為開發(fā)進(jìn)程的核心內(nèi)容。這樣做，你就會確定系統(tǒng)在正常運(yùn)轉(zhuǎn)。如果沒有，你恐怕不能保證系統(tǒng)是正常工作的。測試可能不是一件好玩的事情，但是從事單元測試和功能測試會使開發(fā)過程里含有更多的樂趣。 資源 “利用Ant 和JUnit 改進(jìn)開發(fā)過程”（開發(fā)工作，2000 年12 月）揭示了單元測試的益處，尤其是應(yīng)用了Ant 和Junit 之后。 開始了解極端編程的方法從極端編程的網(wǎng)頁上下載各種單元測試的框架【文章出處】

軟件測試和軟件開發(fā)過程的關(guān)系

平常我們理解的軟件開發(fā)可能只是代碼實(shí)現(xiàn)。
其實(shí)軟件開發(fā)是一個系統(tǒng)的工程。包括需求分析，設(shè)計，編碼，測試，維護(hù)等等幾個環(huán)節(jié)。
測試是整個軟件開發(fā)流程中的一個環(huán)節(jié)。包括白盒測試，灰盒測試和黑盒測試。
白盒測試要求測試人員對于代碼結(jié)構(gòu)有很好的理解，一般用于單元測試；黑盒測試就是測試軟件能否滿足系統(tǒng)的功能要求，一般用于集成測試?；液袦y試介于兩者之間。
在現(xiàn)代軟件開發(fā)的流程中，測試是貫穿于整個開發(fā)流程了，而不是只是在編碼完成以后才開始的了。

軟件測試和軟件開發(fā)的關(guān)系是怎樣的

軟件開發(fā)是生產(chǎn)制造軟件；軟件測試是驗(yàn)證開發(fā)出來軟件的質(zhì)量。類比傳統(tǒng)加工制造企業(yè)，軟件開發(fā)人員就是生產(chǎn)加工的工人，軟件測試人員就是質(zhì)檢人員。
關(guān)系應(yīng)該是：
1、沒有軟件開發(fā)就沒有測試，軟件開發(fā)提供軟件測試的對象。
2、軟件開發(fā)和軟件測試都是軟件生命周期中的重要組成部分
3、軟件開發(fā)和軟件測試都是軟件過程中的重要活動。
4、軟件測試是保證軟件開發(fā)產(chǎn)物質(zhì)量的重要手段。

單元測試、集成測試、系統(tǒng)測試的順序可否調(diào)換，為什么？

軟件測試就是在軟件交付用戶使用或投入運(yùn)行前，對軟件需求規(guī)格說明、設(shè)計規(guī)格說明和編碼的最終復(fù)審，是軟件質(zhì)量保證的關(guān)鍵步驟。軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。軟件測試在軟件生命周期中橫跨兩個階段：通常在編寫出每一個模塊之后就需要對它做必要的測試（稱為單元測試）。編碼和單元測試屬于軟件生命周期中的同一個階段。在結(jié)束這個階段后對軟件系統(tǒng)還要進(jìn)行各種綜合測試，如集成測試、系統(tǒng)測試、性能測試和配置測試等，這是軟件生命周期的另一個獨(dú)立階段，即測試階段。
軟件測試的目的：
1、測試的最終目的是為了避免錯誤的發(fā)生，確保應(yīng)用程序能夠正常高效的運(yùn)行；
2、好的測試用例在于發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤；
3、成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試；
4、好的測試工程師應(yīng)該做到不僅發(fā)現(xiàn)問題，還能夠幫助開發(fā)人員分析問題；
軟件測試的原則：
1、應(yīng)把“盡早和不斷地進(jìn)行軟件測試”作為軟件開發(fā)者的座右銘，實(shí)踐證明單元測試能夠盡早發(fā)現(xiàn)問題，減少后期測試的錯誤量?？梢圆捎肑unit和Jtest來輔助進(jìn)行單元測試。
2、測試用例應(yīng)由測試輸入數(shù)據(jù)、測試執(zhí)行步驟和與之對應(yīng)的預(yù)期輸出結(jié)果三部分組成。
3、應(yīng)當(dāng)避免由程序員檢查自己的程序。（指后期系統(tǒng)測試階段，不包括單元測試）
4、測試用例的設(shè)計要確保能覆蓋所有可能路徑。在設(shè)計測試用例時，應(yīng)當(dāng)包括合理的輸入條件和不合理的輸入條件。不合理的輸入條件是指異常的，臨界的，可能引起問題的輸入條件。
5、充分注意測試中的群集現(xiàn)象。經(jīng)驗(yàn)表明，測試后程序殘存的錯誤數(shù)目與該程序中已發(fā)現(xiàn)的錯誤數(shù)目或檢錯率成正比。應(yīng)該對錯誤群集的程序段進(jìn)行重點(diǎn)測試。
6、嚴(yán)格執(zhí)行測試計劃，排除測試的隨意性。
測試計劃應(yīng)包括：所測軟件的功能，輸入和輸出，測試內(nèi)容，各項(xiàng)測試的進(jìn)度安排，資源要求，測試資料，測試工具，測試用例的選擇，測試的控制方法和過程，系統(tǒng)的配置方式，跟蹤規(guī)則，調(diào)試規(guī)則，以及回歸測試的規(guī)定等等以及評價標(biāo)準(zhǔn)。
7、應(yīng)當(dāng)對每一個測試結(jié)果做全面的檢查。
8、妥善保存測試計劃，測試用例，出錯統(tǒng)計和最終分析報告，為維護(hù)提供方便。
軟件測試的對象：
軟件測試并不單純等同于程序測試。軟件測試應(yīng)該貫穿整個軟件定義與開發(fā)整個期間。因此需求分析、概要設(shè)計、詳細(xì)設(shè)計以及程序編碼等各階段所得到的文檔，包括需求規(guī)格說明、概要設(shè)計規(guī)格說明、詳細(xì)設(shè)計規(guī)格說明以及源程序，都應(yīng)該是軟件測試（評審）的對象。
在對需求理解與表達(dá)的正確性、設(shè)計與表達(dá)的正確性、實(shí)現(xiàn)的正確性以及運(yùn)行的正確性的驗(yàn)證中，任何一個環(huán)節(jié)發(fā)生了問題都可能在軟件測試中表現(xiàn)出來。
什么是單元測試
單元測試是在軟件開發(fā)過程中要進(jìn)行的最低級別的測試活動，測試的對象是軟件設(shè)計的最小單位——模塊。單元測試的依據(jù)是詳細(xì)設(shè)描述，單元測試應(yīng)對模塊內(nèi)所有重要的控制路徑設(shè)計測試用例，以便發(fā)現(xiàn)模塊內(nèi)部的錯誤。在單元測試活動中，軟件的獨(dú)立單元將在與程序的其他部分相隔離的情況下進(jìn)行測試。單元測試多采用白盒測試技術(shù)，系統(tǒng)內(nèi)多個模塊可以并行地進(jìn)行測試。
在一種傳統(tǒng)的結(jié)構(gòu)化編程語言中，比如C，要進(jìn)行測試的單元一般是函數(shù)或子過程。在象C++這樣的面向?qū)ο蟮恼Z言中，要進(jìn)行測試的基本單元是類。對Ada語言來說，開發(fā)人員可以選擇是在獨(dú)立的過程和函數(shù)，還是在Ada包的級別上進(jìn)行單元測試。單元測試的原則同樣被擴(kuò)展到第四代語言(4GL)的開發(fā)中，在這里基本單元被典型地劃分為一個菜單或顯示界面。
單元測試不僅僅是作為無錯編碼一種輔助手段在一次性的開發(fā)過程中使用，單元測試必須是可重復(fù)的，無論是在軟件修改，或是移植到新的運(yùn)行環(huán)境的過程中。因此，所有的測試都必須在整個軟件系統(tǒng)的生命周期中進(jìn)行維護(hù)。
經(jīng)常與單元測試聯(lián)系起來的另外一些開發(fā)活動包括代碼走讀(Code review)，靜態(tài)分析(Static analysis)和動態(tài)分析(Dynamic analysis)。靜態(tài)分析就是對軟件的源代碼進(jìn)行研讀，查找錯誤或收集一些度量數(shù)據(jù)，并不需要對代碼進(jìn)行編譯和執(zhí)行。動態(tài)分析就是通過觀察軟件運(yùn)行時的動作，來提供執(zhí)行跟蹤，時間分析，以及測試覆蓋度方面的信息。

2、單元測試任務(wù)
單元測試任務(wù)包括：1 模塊接口測試；2 模塊局部數(shù)據(jù)結(jié)構(gòu)測試；3 模塊邊界條件測試；4 模塊中所有獨(dú)立執(zhí)行通路測試；5 模塊的各條錯誤處理通路測試。
模塊接口測試是單元測試的基礎(chǔ)。只有在數(shù)據(jù)能正確流入、流出模塊的前提下，其他測試才有意義。測試接口正確與否應(yīng)該考慮下列因素：
1 輸入的實(shí)際參數(shù)與形式參數(shù)的個數(shù)是否相同；
2 輸入的實(shí)際參數(shù)與形式參數(shù)的屬性是否匹配；
3 輸入的實(shí)際參數(shù)與形式參數(shù)的量綱是否一致；
4 調(diào)用其他模塊時所給實(shí)際參數(shù)的個數(shù)是否與被調(diào)模塊的形參個數(shù)相同；
5 調(diào)用其他模塊時所給實(shí)際參數(shù)的屬性是否與被調(diào)模塊的形參屬性匹配；
6調(diào)用其他模塊時所給實(shí)際參數(shù)的量綱是否與被調(diào)模塊的形參量綱一致；
7 調(diào)用預(yù)定義函數(shù)時所用參數(shù)的個數(shù)、屬性和次序是否正確；
8 是否存在與當(dāng)前入口點(diǎn)無關(guān)的參數(shù)引用；
9 是否修改了只讀型參數(shù)；
10 對全程變量的定義各模塊是否一致；
11是否把某些約束作為參數(shù)傳遞。
如果模塊內(nèi)包括外部輸入輸出，還應(yīng)該考慮下列因素：
1 文件屬性是否正確；
2 OPEN/CLOSE語句是否正確；
3 格式說明與輸入輸出語句是否匹配；
4緩沖區(qū)大小與記錄長度是否匹配；
5文件使用前是否已經(jīng)打開；
6是否處理了文件尾；
7是否處理了輸入/輸出錯誤；
8輸出信息中是否有文字性錯誤；

檢查局部數(shù)據(jù)結(jié)構(gòu)是為了保證臨時存儲在模塊內(nèi)的數(shù)據(jù)在程序執(zhí)行過程中完整、正確。局部數(shù)據(jù)結(jié)構(gòu)往往是錯誤的根源，應(yīng)仔細(xì)設(shè)計測試用例，力求發(fā)現(xiàn)下面幾類錯誤：
1 不合適或不相容的類型說明；
2變量無初值；
3變量初始化或省缺值有錯；
4不正確的變量名（拼錯或不正確地截斷）；
5出現(xiàn)上溢、下溢和地址異常。
除了局部數(shù)據(jù)結(jié)構(gòu)外，如果可能，單元測試時還應(yīng)該查清全局?jǐn)?shù)據(jù)（例如FORTRAN的公用區(qū)）對模塊的影響。
在模塊中應(yīng)對每一條獨(dú)立執(zhí)行路徑進(jìn)行測試，單元測試的基本任務(wù)是保證模塊中每條語句至少執(zhí)行一次。此時設(shè)計測試用例是為了發(fā)現(xiàn)因錯誤計算、不正確的比較和不適當(dāng)?shù)目刂屏髟斐傻腻e誤。此時基本路徑測試和循環(huán)測試是最常用且最有效的測試技術(shù)。計算中常見的錯誤包括：
1 誤解或用錯了算符優(yōu)先級；
2混合類型運(yùn)算；
3變量初值錯；
4精度不夠；
5表達(dá)式符號錯。
比較判斷與控制流常常緊密相關(guān)，測試用例還應(yīng)致力于發(fā)現(xiàn)下列錯誤：
1不同數(shù)據(jù)類型的對象之間進(jìn)行比較；
2錯誤地使用邏輯運(yùn)算符或優(yōu)先級；
3因計算機(jī)表示的局限性，期望理論上相等而實(shí)際上不相等的兩個量相等；
4比較運(yùn)算或變量出錯；
5循環(huán)終止條件或不可能出現(xiàn)；
6迭代發(fā)散時不能退出；
7錯誤地修改了循環(huán)變量。
一個好的設(shè)計應(yīng)能預(yù)見各種出錯條件，并預(yù)設(shè)各種出錯處理通路，出錯處理通路同樣需要認(rèn)真測試，測試應(yīng)著重檢查下列問題：
1輸出的出錯信息難以理解；
2記錄的錯誤與實(shí)際遇到的錯誤不相符；
3在程序自定義的出錯處理段運(yùn)行之前，系統(tǒng)已介入；
4異常處理不當(dāng)；
5錯誤陳述中未能提供足夠的定位出錯信息。
邊界條件測試是單元測試中最后，也是最重要的一項(xiàng)任務(wù)。眾的周知，軟件經(jīng)常在邊界上失效，采用邊界值分析技術(shù)，針對邊界值及其左、右設(shè)計測試用例，很有可能發(fā)現(xiàn)新的錯誤。

3、單元測試的過程與環(huán)境
一般認(rèn)為單元測試應(yīng)緊接在編碼之后，當(dāng)源程序編制完成并通過復(fù)審和編譯檢查，便可開始單元測試。測試用例的設(shè)計應(yīng)與復(fù)審工作相結(jié)合，根據(jù)設(shè)計信息選取測試數(shù)據(jù)，將增大發(fā)現(xiàn)上述各類錯誤的可能性。在確定測試用例的同時，應(yīng)給出期望結(jié)果。
應(yīng)為測試模塊開發(fā)一個驅(qū)動模塊（driver）和（或）若干個樁模塊（stub）,下圖顯示了一般單元測試的環(huán)境。驅(qū)動模塊在大多數(shù)場合稱為"主程序"，它接收測試數(shù)據(jù)并將這些數(shù)據(jù)傳遞到被測試模塊，被測試模塊被調(diào)用后，"主程序"打印"進(jìn)入-退出"消息。
驅(qū)動模塊和樁模塊是測試使用的軟件，而不是軟件產(chǎn)品的組成部分，但它需要一定的開發(fā)費(fèi)用。若驅(qū)動和樁模塊比較簡單，實(shí)際開銷相對低些。遺憾的是，僅用簡單的驅(qū)動模塊和樁模塊不能完成某些模塊的測試任務(wù)，這些模塊的單元測試只能采用下面討論的綜合測試方法。
提高模塊的內(nèi)聚度可簡化單元測試，如果每個模塊只能完成一個，所需測試用例數(shù)目將顯著減少，模塊中的錯誤也更容易發(fā)現(xiàn)。
三、集成測試的基本方法

時常有這樣的情況發(fā)生，每個模塊都能單獨(dú)工作，但這些模塊集成在一起之后卻不能正常工作。主要原因是，模塊相互調(diào)用時接口會引入許多新問題。例如，數(shù)據(jù)經(jīng)過接口可能丟失；一個模塊對另一模塊可能造成不應(yīng)有的影響；幾個子功能組合起來不能實(shí)現(xiàn)主功能；誤差不斷積累達(dá)到不可接受的程度；全局?jǐn)?shù)據(jù)結(jié)構(gòu)出現(xiàn)錯誤，等等。綜合測試是組裝軟件的系統(tǒng)測試技術(shù)，按設(shè)計要求把通過單元測試的各個模塊組裝在一起之后，進(jìn)行綜合測試以便發(fā)現(xiàn)與接口有關(guān)的各種錯誤。
某設(shè)計人員習(xí)慣于把所有模塊按設(shè)計要求一次全部組裝起來，然后進(jìn)行整體測試，這稱為非增量式集成。這種方法容易出現(xiàn)混亂。因?yàn)闇y試時可能發(fā)現(xiàn)一大堆錯誤，為每個錯誤定位和糾正非常困難，并且在改正一個錯誤的同時又可能引入新的錯誤，新舊錯誤混雜，更難斷定出錯的原因和位置。與之相反的是增量式集成方法，程序一段一段地擴(kuò)展，測試的范圍一步一步地增大，錯誤易于定位和糾正，界面的測試亦可做到完全徹底。
下面討論兩種增量式集成方法。
1、自頂向下集成
自頂向下集成是構(gòu)造程序結(jié)構(gòu)的一種增量式方式，它從主控模塊開始，按照軟件的控制層次結(jié)構(gòu)，以深度優(yōu)先或廣度優(yōu)先的策略，逐步把各個模塊集成在一起。深度優(yōu)先策略首先是把主控制路徑上的模塊集成在一起，至于選擇哪一條路徑作為主控制路徑，這多少帶有隨意性，一般根據(jù)問題的特性確定。以下圖為例，若選擇了最左一條路徑，首先將模塊M1，M2，M5和M8集成在一起，再將M6集成起來，然后考慮中間和右邊的路徑。廣度優(yōu)先策略則不然，它沿控制層次結(jié)構(gòu)水平地向下移動。仍以下圖為例，它首先把M2、M3和M4與主控模塊集成在一起，再將M5和M6 和其他模塊集資集成起來。
自頂向下綜合測試的具體步驟為：
1 以主控模塊作為測試驅(qū)動模塊，把對主控模塊進(jìn)行單元測試時引入的所有樁模塊用實(shí)際模塊替代； 2 依據(jù)所選的集成策略（深度優(yōu)先或廣度優(yōu)先），每次只替代一個樁模塊； 3 每集成一個模塊立即測試一遍； 4 只有每組測試完成后，才著手替換下一個樁模塊； 5 為避免引入新錯誤，須不斷地進(jìn)行回歸測試（即全部或部分地重復(fù)已做過的測試）。 從第二步開始，循環(huán)執(zhí)行上述步驟，直至整個程序結(jié)構(gòu)構(gòu)造完畢。下圖中，實(shí)線表示已部分完成的結(jié)構(gòu)，若采用深度優(yōu)先策略，下一步將用模塊M7替換樁模塊S7，當(dāng)然M7本身可能又帶有樁模塊，隨后將被對應(yīng)的實(shí)際模塊一一替代。
自頂向下集成的優(yōu)點(diǎn)在于能盡早地對程序的主要控制和決策機(jī)制進(jìn)行檢驗(yàn)，因此較早地發(fā)現(xiàn)錯誤。缺點(diǎn)是在測試較高層模塊時，低層處理采用樁模塊替代，不能反映真實(shí)情況，重要數(shù)據(jù)不能及時回送到上層模塊，因此測試并不充分。解決這個問題有幾種辦法，第一種是把某些測試推遲到用真實(shí)模塊替代樁模塊之后進(jìn)行，第二種是開發(fā)能模擬真實(shí)模塊的樁模塊；第三種是自底向上集成模塊。第一種方法又回退為非增量式的集成方法，使錯誤難于定位和糾正，并且失去了在組裝模塊時進(jìn)行一些特定測試的可能性；第二種方法無疑要大大增加開銷；第三種方法比較切實(shí)可行，下面專門討論。

2、自底向上集成
自底向上測試是從"原子"模塊（即軟件結(jié)構(gòu)最低層的模塊）開始組裝測試，因測試到較高層模塊時，所需的下層模塊功能均已具備，所以不再需要樁模塊。
自底向上綜合測試的步驟分為：
1 把低層模塊組織成實(shí)現(xiàn)某個子功能的模塊群（cluster）; 2 開發(fā)一個測試驅(qū)動模塊，控制測試數(shù)據(jù)的輸入和測試結(jié)果的輸出； 3 對每個模塊群進(jìn)行測試； 4 刪除測試使用的驅(qū)動模塊，用較高層模塊把模塊群組織成為完成更大功能的新模塊群。 從第一步開始循環(huán)執(zhí)行上述各步驟，直至整個程序構(gòu)造完畢。 下圖說明了上述過程。首先"原子"模塊被分為三個模塊群，每個模塊群引入一個驅(qū)動模塊進(jìn)行測試。因模塊群1、模塊群2中的模塊均隸屬于模塊Ma，因此在驅(qū)動模塊D1、D2去掉后，模塊群1與模塊群2直接與Ma接口，這時可對MaD3被去掉后，M3與模塊群3直接接口，可對Mb進(jìn)行集成測試，最后Ma、Mb和 Mc全部集成在一起進(jìn)行測試。

自底向上集成方法不用樁模塊，測試用例的設(shè)計亦相對簡單，但缺點(diǎn)是程序最后一個模塊加入時才具有整體形象。它與自頂向綜合測試方法優(yōu)缺點(diǎn)正好相反。因此，在測試軟件系統(tǒng)時，應(yīng)根據(jù)軟件的特點(diǎn)和工程的進(jìn)度，選用適當(dāng)?shù)臏y試策略，有時混和使用兩種策略更為有效，上層模塊用自頂向下的方法，下層模塊用自底向上的方法。
此外，在綜合測試中尤其要注意關(guān)鍵模塊，所謂關(guān)鍵模塊一般都具有下述一或多個特征：①對應(yīng)幾條需求；②具有高層控制功能；③復(fù)雜、易出錯；④有特殊的性能要求。關(guān)鍵模塊應(yīng)盡早測試，并反復(fù)進(jìn)行回歸測試。
四、確認(rèn)測試的基本方法
通過集成測試之后，軟件已完全組裝起來，接口方面的錯誤也已排除，確認(rèn)測試即可開始。確認(rèn)測試應(yīng)檢查軟件能否按合同要求進(jìn)行工作，即是否滿足軟件需求說明書中的確認(rèn)標(biāo)準(zhǔn)。
1. 確認(rèn)測試標(biāo)準(zhǔn) 實(shí)現(xiàn)軟件確認(rèn)要通過一系列墨盒測試。確認(rèn)測試同樣需要制訂測試計劃和過程，測試計劃應(yīng)規(guī)定測試的種類和測試進(jìn)度，測試過程則定義一些特殊的測試用例，旨在說明軟件與需求是否一致。無是計劃還是過程，都應(yīng)該著重考慮軟件是否滿足合同規(guī)定的所有功能和性能，文檔資料是否完整、準(zhǔn)確人機(jī)界面和其他方面（例如，可移植性、兼容性、錯誤恢復(fù)能力和可維護(hù)性等）是否令用戶滿意。 確認(rèn)測試的結(jié)果有兩種可能，一種是功能和性能指標(biāo)滿足軟件需求說明的要求，用戶可以接受；另一種是軟件不滿足軟件需求說明的要求，用戶無法接受。項(xiàng)目進(jìn)行到這個階段才發(fā)現(xiàn)嚴(yán)重錯誤和偏差一般很難在預(yù)定的工期內(nèi)改正，因此必須與用戶協(xié)商，尋求一個妥善解決問題的方法。
2. 配置復(fù)審 確認(rèn)測試的另一個重要環(huán)節(jié)是配置復(fù)審。復(fù)審的目的在于保證軟件配置齊全、分類有序，并且包括軟件維護(hù)所必須的細(xì)節(jié)。
3. α、β測試 事實(shí)上，軟件開發(fā)人員不可能完全預(yù)見用戶實(shí)際使用程序的情況。例如，用戶可能錯誤的理解命令，或提供一些奇怪的數(shù)據(jù)組合，亦可能對設(shè)計者自認(rèn)明了的輸出信息迷惑不解，等等。因此，軟件是否真正滿足最終用戶的要求，應(yīng)由用戶進(jìn)行一系列"驗(yàn)收測試"。驗(yàn)收測試既可以是非正式的測試，也可以有計劃、有系統(tǒng)的測試。有時，驗(yàn)收測試長達(dá)數(shù)周甚至數(shù)月，不斷暴露錯誤，導(dǎo)致開發(fā)延期。一個軟件產(chǎn)品，可能擁有眾多用戶，不可能由每個用戶驗(yàn)收，此時多采用稱為α、β測試的過程，以期發(fā)現(xiàn)那些似乎只有最終用戶才能發(fā)現(xiàn)的問題。 α測試是指軟件開發(fā)公司組織內(nèi)部人員模擬各類用戶行對即將面市軟件產(chǎn)品（稱為α版本）進(jìn)行測試，試圖發(fā)現(xiàn)錯誤并修正。α測試的關(guān)鍵在于盡可能逼真地模擬實(shí)際運(yùn)行環(huán)境和用戶對軟件產(chǎn)品的操作并盡最大努力涵蓋所有可能的用戶操作方式。經(jīng)過α測試調(diào)整的軟件產(chǎn)品稱為β版本。緊隨其后的β測試是指軟件開發(fā)公司組織各方面的典型用戶在日常工作中實(shí)際使用β版本，并要求用戶報告異常情況、提出批評意見。然后軟件開發(fā)公司再對β版本進(jìn)行改錯和完善。
五、系統(tǒng)測試的基本方法
計算機(jī)軟件是基于計算機(jī)系統(tǒng)的一個重要組成部分，在系統(tǒng)測試之前，軟件工程師應(yīng)完成下列工作：
為測試軟件系統(tǒng)的輸入信息設(shè)計出錯處理通路；
設(shè)計測試用例，模擬錯誤數(shù)據(jù)和軟件界面可能發(fā)生的錯誤，記錄測試結(jié)果，為系統(tǒng)測試提供經(jīng)驗(yàn)和幫助；
參與系統(tǒng)測試的規(guī)劃和設(shè)計，保證軟件測試的合理性。
系統(tǒng)測試應(yīng)該由若干個不同測試組成，目的是充分運(yùn)行系統(tǒng)，驗(yàn)證系統(tǒng)各部件是否都能政黨工作并完成所賦予的任務(wù)。
下面簡單討論幾類系統(tǒng)測試。
1、恢復(fù)測試 恢復(fù)測試主要檢查系統(tǒng)的容錯能力。當(dāng)系統(tǒng)出錯時，能否在指定時間間隔內(nèi)修正錯誤并重新啟動系統(tǒng)。恢復(fù)測試首先要采用各種辦法強(qiáng)迫系統(tǒng)失敗，然后驗(yàn)證系統(tǒng)是否能盡快恢復(fù)。對于自動恢復(fù)需驗(yàn)證重新初始化（）、檢查點(diǎn)( )、數(shù)據(jù)恢復(fù)(data recovery)和重新啟動 (restart)等機(jī)制的正確性；對于人工干預(yù)的恢復(fù)系統(tǒng)，還需估測平均修復(fù)時間，確定其是否在可接受的范圍內(nèi)。
2、安全測試 安全測試檢查系統(tǒng)對非法侵入的防范能力。安全測試期間，測試人員假扮非法入侵者，采用各種辦法試圖突破防線。例如，①想方設(shè)法截取或破譯口令；②專門定做軟件破壞系統(tǒng)的保護(hù)機(jī)制；③故意導(dǎo)致系統(tǒng)失敗，企圖趁恢復(fù)之機(jī)非法進(jìn)入；④試圖通過瀏覽非保密數(shù)據(jù)，推導(dǎo)所需信息，等等。理論上講，只要有足夠的時間和資源，沒有不可進(jìn)入的系統(tǒng)。因此系統(tǒng)安全設(shè)計的準(zhǔn)則是，使非法侵入的代價超過被保護(hù)信息的價值。此時非法侵入者已無利可圖。
3、強(qiáng)度測試 強(qiáng)度測試檢查程序?qū)Ξ惓Ｇ闆r的抵抗能力。強(qiáng)度測試總是迫使系統(tǒng)在異常的資源配置下運(yùn)行。例如，①當(dāng)中斷的正常頻率為每秒一至兩個時，運(yùn)行每秒產(chǎn)生十個中斷的測試用例；②定量地增長數(shù)據(jù)輸入率，檢查輸入子功能的反映能力；③運(yùn)行需要最大存儲空間（或其他資源）的測試用例；④運(yùn)行可能導(dǎo)致虛存操作系統(tǒng)崩潰或磁盤數(shù)據(jù)劇烈抖動的測試用例，等等。
4、 性能測試 對于那些實(shí)時和嵌入式系統(tǒng)，軟件部分即使?jié)M足功能要求，也未必能夠滿足性能要求，雖然從單元測試起，每一測試步驟都包含性能測試，但只有當(dāng)系統(tǒng)真正集成之后，在真實(shí)環(huán)境中才能全面、可靠地測試運(yùn)行性能系統(tǒng)性能測試是為了完成這一任務(wù)。性能測試有時與強(qiáng)度測試相結(jié)合，經(jīng)常需要其他軟硬件的配套支持。
六、軟件測試自動化的一些具體做法
因?yàn)檐浖y試的工作量很大（40% 到60% 的總開發(fā)時間），而又有很大部分適于自動化，因此，測試的改進(jìn)會對整個開發(fā)工作的質(zhì)量、成本和周期帶來非常顯著的效果。
下面舉出一些測試自動化的例子：
1. 測試個案（test case ，或稱為測試用例）的生成
用編程語言或更方便的劇本語言（script language 例如Perl等）寫出短小的程序來產(chǎn)生大量的測試輸入（包括輸入數(shù)據(jù)與操作指令）。或同時也按一定的邏輯規(guī)律產(chǎn)生標(biāo)準(zhǔn)輸出。輸入與輸出的文件名字按規(guī)定進(jìn)行配對，以便控制自動化測試及結(jié)果核對的程序易于操作。 這里提到測試個案的命名問題，如果在項(xiàng)目的文檔設(shè)計中作統(tǒng)一規(guī)劃的話，軟件產(chǎn)品的需求與功能的命名就應(yīng)該成為后繼開發(fā)過程的中間產(chǎn)品的命名分類依據(jù)。這樣，就會為文檔管理和配置管理帶來很大的方便，使整個產(chǎn)品的開發(fā)過程變得更有條理，更符合邏輯。任何新手半途加入到開發(fā)工作中也會更容易進(jìn)入狀態(tài)。
2. 測試的執(zhí)行寫控制
單元測試或集成測試可能多用單機(jī)運(yùn)行。但對于系統(tǒng)測試或回歸測試，就極有可能需要多臺機(jī)在網(wǎng)絡(luò)上同時運(yùn)行。記住一個這樣的原則，在開發(fā)過程中的任何時候，如果你需要等候測試的運(yùn)行結(jié)果的話，那就是一個縮短開發(fā)時間的機(jī)會。對于單個的測試運(yùn)行，挖潛的機(jī)會在測試的設(shè)置及開始運(yùn)行和結(jié)果的對比及顯示。有時候，需要反復(fù)修改程序，重新匯編和重新測試。這樣，每一個循環(huán)的各種手工鍵入的設(shè)置與指令所花費(fèi)的時間，加起來就非?？捎^。如果能利用make或類似的軟件工具來幫助，就能節(jié)省大量的時間。 對于系統(tǒng)測試或回歸測試這類涉及大量測試個案運(yùn)行的情況，挖潛的的機(jī)會除了利用軟件工具來實(shí)現(xiàn)自動化之外，就是怎樣充分利用一切硬件資源。往往，就算是在白天的工作時間內(nèi)，每臺計算機(jī)的負(fù)荷都沒有被充分利用。能夠把大量測試個案分配到各臺機(jī)器上去同時運(yùn)行，就能節(jié)省大量的時間。另外，把大量的系統(tǒng)測試及回歸測試安排到夜間及周末運(yùn)行，更能提高效率。如果不購買商品化的工具的話，應(yīng)當(dāng)遵從正規(guī)的軟件開發(fā)要求來開發(fā)出好的軟件測試自動化工具。在實(shí)踐中，許多企業(yè)自行開發(fā)的自動化工具都是利用一些現(xiàn)成的軟件工具再加上自己寫的程序而組成的。這些自己開發(fā)的工具完全是為本企業(yè)量身定做的，因此可用性非常強(qiáng)。同時，也能根據(jù)需要隨時進(jìn)行改進(jìn)，而不必受制于人。在設(shè)計軟件自動測試工具的時候，路徑（path）控制是一個非常重要的功能。理想的使用情況是：這個工具可以在任何一個路徑位置上運(yùn)行，可以到任何路徑位置去取得測試用例，同時也可以把測試的結(jié)果輸出放到任何的路徑位置上去。這樣的設(shè)計，可以使不同的測試運(yùn)行能夠使用同一組測試用例而不至于互相干擾，也可以靈活使用硬盤的空間，并且使備份保存工作易于控制。同時，軟件自動測試工具必須能夠有辦法方便地選擇測試用例庫中的全部或部分來運(yùn)行，也必須能夠自由地選擇被測試的產(chǎn)品或中間產(chǎn)品采作為測試對象。
3. 測試結(jié)果與標(biāo)準(zhǔn)輸出的對比
在設(shè)計測試用例的時候，必須考慮到怎樣才能夠易于對此測試結(jié)果和標(biāo)準(zhǔn)輸出。輸出數(shù)據(jù)量的多少及數(shù)據(jù)格式對比較的速度有直接影響。而另一方面，也必須考慮到輸出數(shù)據(jù)與測試用例的測試目標(biāo)的邏輯對應(yīng)性及易讀性，這將會大大有利于分析測試所發(fā)現(xiàn)的不吻合，也有利于測試用例的維護(hù)。 許多時候，要寫一些特殊的軟件來執(zhí)行測試結(jié)果與標(biāo)準(zhǔn)輸出的對比工作，因?yàn)榭赡苡胁糠值妮敵鰞?nèi)容是不能直接對比的（比如，對運(yùn)行的日期時間的記錄，對運(yùn)行的路徑的記錄，以及測試對象的版本數(shù)據(jù)等），就要用程序進(jìn)行處理。
4. 不吻合的測試結(jié)果的分析、分類、記錄和通報
上一點(diǎn)所談到的，用于對測試結(jié)果與標(biāo)準(zhǔn)輸出進(jìn)行對比的特殊軟件，往往也同時擔(dān)任對不吻合的測試結(jié)果進(jìn)行分析、分類、記錄和通報的任務(wù)。"分析"是找出不吻合的地方并指出錯誤的可能起因。"分類"包括各種統(tǒng)計上的分項(xiàng)，例如，對應(yīng)的源程序的位置，錯誤的嚴(yán)重級別（提示、警告、非失效性錯誤、失效性錯誤；或別的分類方法），新發(fā)現(xiàn)的還是已有記錄的錯誤，等等。"記錄"，是按分類存檔。"通報"，是主動地對測試的運(yùn)行者及測試用例的"負(fù)責(zé)人"通報出錯的信息。 這里提到測試用例的"負(fù)責(zé)人"的概念。是用以指定一個測試用例運(yùn)行時發(fā)現(xiàn)的缺陷，由哪一個開發(fā)人員負(fù)責(zé)分析（有時是另外的開發(fā)人員引進(jìn)的缺陷而導(dǎo)致的錯誤）及修復(fù)。在設(shè)立測試用例庫時，各用例均應(yīng)有指定的負(fù)責(zé)人。 最直接的通報方法是由自動測試軟件發(fā)出電子郵件給測試運(yùn)行者及測試用例負(fù)責(zé)人。郵件內(nèi)容的詳細(xì)程度可根據(jù)需要靈活決定。
5. 總測試狀況的統(tǒng)計，報表的產(chǎn)生
這些都是自動測試工具所應(yīng)有的功能。目的是提高過程管理的質(zhì)量，同時節(jié)省用于產(chǎn)生統(tǒng)計數(shù)據(jù)的時間。產(chǎn)生出來的統(tǒng)計報表，最好是存放到一個約定的路徑位置，以便任何有關(guān)人員都知道怎樣查閱。同時，可按需要用電子郵件向適當(dāng)?shù)膶ο螅ㄈ珥?xiàng)目經(jīng)理，測試經(jīng)理和質(zhì)量保證經(jīng)理）寄出統(tǒng)計報表。

項(xiàng)目開發(fā)中如何進(jìn)行單元測試？

很多人在進(jìn)行軟件開發(fā)的之后會忽略一個重要的細(xì)節(jié)，一般情況下很多人不寫單元測試，只是偶爾才會寫寫。只有很少一部分程序員會自己編寫代碼進(jìn)行單元測試，這樣才能保證測試通過。下面云南電腦培訓(xùn)為大家介紹項(xiàng)目開發(fā)的單元測試，有哪些理解誤區(qū)。

一、不知道怎么編寫單元測試

這個問題主要是沒有接觸過單元測試的，并且沒有體會過企業(yè)的代碼開發(fā)。在開發(fā)功能模塊時，您需要確定模塊是否有錯誤？如果您有特定的業(yè)務(wù)，您需要運(yùn)行debug模式，然后將其逐漸深入到代碼中？在這種情況下，云南IT培訓(xùn)認(rèn)為就需要了解單元測試工具了。

二、單元測試價值不高，浪費(fèi)時間

這樣的想法是非常錯誤的。在開發(fā)過程中，代碼完成并不等于開發(fā)完成，如果沒有進(jìn)行有效的代碼測試，是不能保證代碼的正常運(yùn)行。一般情況下，測試人員是進(jìn)行業(yè)務(wù)上的測試，對單元是無法進(jìn)行測試的，所以昆明IT培訓(xùn)建議在進(jìn)行項(xiàng)目開發(fā)中使用更多的時間進(jìn)行單元測試。

三、項(xiàng)目業(yè)務(wù)邏輯簡單，不進(jìn)行單元測試

業(yè)務(wù)邏輯是否簡單，其實(shí)是相對的。當(dāng)你熟悉某個業(yè)務(wù)邏輯時，你就會認(rèn)為它很簡單。但是測試代碼功能是否正確還是在于你對同事的了解，這樣你可以在不讀代碼的情況下了解很多知識，所以單元測試不僅能夠解放自己，還能更好的方便別人。

單元測試是很多程序員比較討厭的環(huán)節(jié)，但是單元測試能夠帶來的好處卻是非常多的。雖然測試不能保證每個程序的正確性，但是測試能夠給我們帶來自信，昆明電腦培訓(xùn)認(rèn)為程序員應(yīng)該進(jìn)行單元測試，在短時間找到項(xiàng)目存在的問題。