使用人工或者自動(dòng)手段來運(yùn)行或測試某個(gè)系統(tǒng)的過程,其目的在于檢驗(yàn)它是否滿足規(guī)定的需求或弄清預(yù)期結(jié)果與實(shí)際結(jié)果之間的差別.

　　它是幫助識別開發(fā)完成（中間或最終的版本）的計(jì)算機(jī)軟件（整體或部分）的正確度(correctness) 、完全度(completeness)和質(zhì)量(quality)的軟件過程；是SQA(software quality assurance)的重要子域。

　　 Grenford J.Myers曾對軟件測試的目的提出過以下觀點(diǎn):

　　(1)測試是為了發(fā)現(xiàn)程序中的錯(cuò)誤而執(zhí)行程序的過程；

　　(2)好的測試方案是極可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯(cuò)誤的測試方案；

　　(3)成功的測試是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn)的錯(cuò)誤的測試。

　　然而,這種觀點(diǎn)指出測試是以查找錯(cuò)誤為中心,而不是為了演示軟件的正確功能.但是只從字面意思理解,可能會(huì)產(chǎn)生誤導(dǎo),認(rèn)為發(fā)現(xiàn)錯(cuò)誤是軟件測試的唯一目的,查找不出錯(cuò)誤的測試就是沒有價(jià)值的測試,實(shí)際上并非如此!

　　(1)測試并不僅僅是為了找出錯(cuò)誤.通過分析錯(cuò)誤產(chǎn)生的原因和錯(cuò)誤的發(fā)生趨勢,可以幫助項(xiàng)目管理者

　　發(fā)現(xiàn)當(dāng)前軟件開發(fā)過程中的缺陷,以便及時(shí)改進(jìn)；

　　(2)這種分析也能幫助測試人員設(shè)計(jì)出有針對性的測試方法,改善測試的效率和有效性；

　　(3)沒有發(fā)現(xiàn)錯(cuò)誤的測試也是有價(jià)值的,完整的測試是評定軟件質(zhì)量的一種方法

　　軟件測試完整分類，參見：軟件測試的完整分類

　　軟件測試的幾大原則：

　　1.軟件開發(fā)人員即程序員應(yīng)當(dāng)避免測試自己的程序

不管是程序員還是開發(fā)小組都應(yīng)當(dāng)避免測試自己的程序或者本組開發(fā)的功能模塊。若條件允許，應(yīng)當(dāng)由獨(dú)立于開發(fā)組和客戶的第三方測試組或測試機(jī)構(gòu)來進(jìn)行軟件測試。但這并不是說程序員不能測試自己的程序，而且更加鼓勵(lì)程序員進(jìn)行調(diào)試，因?yàn)闇y試由別人來進(jìn)行可能會(huì)會(huì)更加有效、客觀，并且容易成功，而允許程序員自己調(diào)試也會(huì)更加有效和針對性。

　　2. 應(yīng)盡早地和不斷地進(jìn)行軟件測試

　　應(yīng)當(dāng)把軟件測試貫穿到整個(gè)軟件開發(fā)的過程中，而不應(yīng)該把軟件測試看作是其過程中的一個(gè)獨(dú)立階段。因?yàn)樵谲浖_發(fā)的每一環(huán)節(jié)都有可能產(chǎn)生意想不到的問題，其影響因素有很多，比如軟件本身的抽象性和復(fù)雜性、軟件所涉及問題的復(fù)雜性、軟件開發(fā)各個(gè)階段工作的多樣性，以及各層次工作人員的配合關(guān)系等。所以要堅(jiān)持軟件開發(fā)各階段的技術(shù)評審，把錯(cuò)誤克服在早期，從而減少成本，提高軟件質(zhì)量。

　　3.對測試用例要有正確的態(tài)度：第一，測試用例應(yīng)當(dāng)由測試輸入數(shù)據(jù)和預(yù)期輸出結(jié)果這兩部分組成；第二，在設(shè)計(jì)測試用例時(shí)，不僅要考慮合理的輸入條件，更要注意不合理的輸入條件。因?yàn)檐浖度雽?shí)際運(yùn)行中，往往不遵守正常的使用方法，卻進(jìn)行了一些甚至大量的意外輸入導(dǎo)致軟件一時(shí)半時(shí)不能做出適當(dāng)?shù)姆磻?yīng)，就很容易產(chǎn)生一系列的問題，輕則輸出錯(cuò)誤的結(jié)果，重則癱瘓失效！因此常用一些不合理的輸入條件來發(fā)現(xiàn)更多的鮮為人知的軟件缺陷。

　　

4.人以群分，物以類聚，軟件測試也不例外，一定要充分注意軟件測試中的群集現(xiàn)象，也可以認(rèn)為是“80-20原則”。不要以為發(fā)現(xiàn)幾個(gè)錯(cuò)誤并且解決這些問題之后，就不需要測試了。反而這里是錯(cuò)誤群集的地方，對這段程序要重點(diǎn)測試，以提高測試投資的效益。

　　5.嚴(yán)格執(zhí)行測試計(jì)劃，排除測試的隨意性，以避免發(fā)生疏漏或者重復(fù)無效的工作。

　　6.應(yīng)當(dāng)對每一個(gè)測試結(jié)果進(jìn)行全面檢查。一定要全面地、仔細(xì)地檢查測試結(jié)果，但常常被人們忽略，導(dǎo)致許多錯(cuò)誤被遺漏。

　　7.妥善保存測試用例、測試計(jì)劃、測試報(bào)告和最終分析報(bào)告，以備回歸測試及維護(hù)之用。

　　在遵守以上原則的基礎(chǔ)上進(jìn)行軟件測試，可以以最少的時(shí)間和人力找出軟件中的各種缺陷，從而達(dá)到保證軟件質(zhì)量的目的。

　　

人類行為具有高度目標(biāo)性，確立一個(gè)正確的目標(biāo)有著重要的心理學(xué)影響。軟件測試的心理學(xué)問題就是如何擺正測試的兩個(gè)目標(biāo)的關(guān)系，使得測試活動(dòng)更加富有成效。

　　1.程序測試的過程具有破壞性

　　每當(dāng)測試一個(gè)程序時(shí)，人們總希望為程序增加一些價(jià)值。利用測試來增加程序的價(jià)值，是指通過測試，找出并修改盡可能多的程序缺陷，從而提高程序的可靠性或質(zhì)量。

　　因此，不要只是為了證明程序能夠正確運(yùn)行而去測試程序。相反，應(yīng)該一開始就假設(shè)程序中隱藏著錯(cuò)誤（這種假設(shè)幾乎對所有的程序都成立），然后測試程序，發(fā)現(xiàn)盡可能多的錯(cuò)誤。

　　事實(shí)上，如果把測試目標(biāo)定位于要證明程序中沒有缺陷，那么就會(huì)在潛意識中傾向于實(shí)現(xiàn)這個(gè)目標(biāo)。也就是說，測試人員會(huì)傾向于挑選那些使程序失效的可能性較小的測試數(shù)據(jù)。另一方面，如果把測試目標(biāo)定位于要證明程序中存在缺陷，那么就會(huì)選擇一些容易發(fā)現(xiàn)程序缺陷的測試數(shù)據(jù)。而后一種態(tài)度會(huì)比前者給程序增加更多的價(jià)值。

　　

因此，大多數(shù)測試專業(yè)人員都贊同Myers對測試的定義：“測試是為發(fā)現(xiàn)錯(cuò)誤而執(zhí)行程序的錯(cuò)誤。”這個(gè)定義意味著程序測試的過程是具有破壞性的，甚至是一個(gè)“施虐”過程。開發(fā)人員可能不愿意這么做，因?yàn)槿藗兛偸莾A向于建設(shè)而不是破壞。這個(gè)定義還暗示了對于一個(gè)特定的程序，應(yīng)該如何設(shè)計(jì)測試用例（測試數(shù)據(jù)）、哪些人應(yīng)該而哪些人又不應(yīng)該執(zhí)行測試。

　　事實(shí)上，如果在測試某個(gè)程序段時(shí)發(fā)現(xiàn)了可以糾正的缺陷，或者測試最終確定在沒有其他缺陷，則應(yīng)將這次合理設(shè)計(jì)并得到有效執(zhí)行的測試稱作是“成功的”。而所謂“不成功的”測試，僅指未能適當(dāng)?shù)貙Τ绦蜻M(jìn)行檢查，未能找出程序中潛藏缺陷的測試。因?yàn)檐浖胁豢赡軟]有缺陷，沒有找出它們，當(dāng)然測試是“不成功的”。

　　“軟件測試就是證明軟件不存在錯(cuò)誤的過程”。對幾乎所有的程序而言，甚至是非常小的程序，這個(gè)目標(biāo)實(shí)際上是無法達(dá)到的。因?yàn)榧词钩绦蛲耆珜?shí)現(xiàn)預(yù)期要求，仍可能包含有缺陷。也就是說，如果程序不按要求工作，它顯然有缺陷，但如果程序做了不要它做的事，它也有缺陷。

　　心理學(xué)研究告訴我們，當(dāng)人們在干一件已經(jīng)知道是不合適的或不可能做到的事時(shí)，往往他們的表現(xiàn)就相當(dāng)糟糕。把程序測試定義為在程序中找出錯(cuò)誤的過程，就使測試成了可以做到的任務(wù)，從而克服了心理上存在的問題。雖然這看起來像是個(gè)微妙的文字游戲，但對成功地進(jìn)行軟件測試有很大的影響。

　　總之，軟件測試更適宜被視為試圖發(fā)現(xiàn)程序中錯(cuò)誤（假設(shè)其存在）的破壞性的過程。一個(gè)成功的測試，通過誘發(fā)程序發(fā)生錯(cuò)誤，可以在這個(gè)方向上促進(jìn)軟件質(zhì)量的改進(jìn)。當(dāng)然最終人們還是要通過軟件測試來建立某種程度的信心：軟件做了其應(yīng)該做的，而沒有做其不應(yīng)該做的。

　　2.程序員應(yīng)避免測試自己的程序

　　

由開發(fā)人員來測試自己的代碼是一件很不妥當(dāng)?shù)氖虑?。開發(fā)和測試生來就是不同的活動(dòng)。開發(fā)是創(chuàng)造或者建立某種事物的行為，如一個(gè)功能模塊或整個(gè)系統(tǒng)。而測試的重要目的是證實(shí)一個(gè)模塊或者一個(gè)系統(tǒng)工作不正常。這兩個(gè)活動(dòng)之間有著本質(zhì)的矛盾。一個(gè)人不太可能把兩個(gè)截然對立的角色都扮演地很好，因此應(yīng)當(dāng)限制開發(fā)人員在測試中的參與，給他們比較合適的任務(wù)是進(jìn)行最底層的測試——單元測試。

　　當(dāng)一個(gè)程序員完成了設(shè)計(jì)與編寫程序的建設(shè)性工作后，要一夜之間突然改變他的觀點(diǎn)，設(shè)法對程序形成一個(gè)完全否定的態(tài)度，那是非常困難的。所以，大部分程序員都由于不能使自己進(jìn)入必要的精神狀態(tài)（不是抱著要揭露出自己程序中錯(cuò)誤的態(tài)度），就不能有效的測試自己的程序。除了這個(gè)心理學(xué)問題之外，還有一個(gè)重要的問題：程序中可能包含由于程序員對問題的敘述或說明的誤解而產(chǎn)生了錯(cuò)誤。如果是這種情況，當(dāng)程序員測試自己的程序時(shí)，往往還會(huì)帶著同樣的誤解致使問題難以發(fā)現(xiàn)。

　　3.程序設(shè)計(jì)組織不應(yīng)測試自己的程序

　　在宏觀意義上，一個(gè)程序設(shè)計(jì)組織或一個(gè)工程項(xiàng)目是個(gè)有生命的有機(jī)體，它同樣有心理學(xué)問題。在大多數(shù)情況下，人們都以“在給定日期內(nèi)，以一定代價(jià)完成程序編制任務(wù)的能力”來衡量程序設(shè)計(jì)組織和項(xiàng)目管理人員的。這樣做的理由是時(shí)間和成本指標(biāo)便于衡量，而程序的質(zhì)量很難度量。要程序設(shè)計(jì)組織在測試自己的程序時(shí)持客觀態(tài)度是很困難的，因?yàn)槿绻谜_的定義看待測試，就不大可能按預(yù)定計(jì)劃完成測試，也不大可能把耗費(fèi)的代價(jià)限制在要求的范圍以內(nèi)。

　　軟件生產(chǎn)的三個(gè)最重要的因素是：質(zhì)量、進(jìn)度和費(fèi)用。由于費(fèi)用和進(jìn)度的限制，要開發(fā)一種高質(zhì)量、快速交付和低成本的軟件產(chǎn)品并不容易。也就是說要同時(shí)達(dá)到三個(gè)目標(biāo)是困難的。因此在軟件產(chǎn)品的開發(fā)中要權(quán)衡它們之間的關(guān)系，是軟件的特性能滿足用戶的要求，這意味著軟件產(chǎn)品的特性的度量和預(yù)計(jì)是必要的。

　　軟件測試由獨(dú)立測試機(jī)構(gòu)承擔(dān)有很多好處。獨(dú)立測試是指軟件測試工作由在經(jīng)濟(jì)上和管理上獨(dú)立于開發(fā)機(jī)構(gòu)的組織進(jìn)行。獨(dú)立測試可以避免軟件開發(fā)者測試自己開發(fā)的軟件，由于心理學(xué)上的問題，軟件開發(fā)者難以客觀、有效的測試自己的軟件，要找出那些因?yàn)閷栴}的誤解而產(chǎn)生的錯(cuò)誤就更加困難。獨(dú)立測試還可以避免軟件開發(fā)機(jī)構(gòu)測試自己的軟件，軟件產(chǎn)品的開發(fā)過程受到時(shí)間、成本和質(zhì)量三者的制約，在軟件開發(fā)的過程中，當(dāng)時(shí)間、成本和質(zhì)量三者發(fā)生矛盾時(shí)，質(zhì)量最容易被忽視，如果測試組織與開發(fā)組織來自相同的機(jī)構(gòu)，測試過程就會(huì)面臨來自于開發(fā)組織同一來源的管理方面的壓力，使測試過程受到干擾。

　　采用獨(dú)立測試方式，無論在技術(shù)上還是管理上，對提高軟件測試的有效性都具有重要意義。

　　客觀性——對軟件測試和軟件中的錯(cuò)誤抱著客觀的態(tài)度，這種客觀的態(tài)度可以解決測試中的心理學(xué)問題，既能以揭露軟件中錯(cuò)誤的態(tài)度工作，也能不受發(fā)現(xiàn)的錯(cuò)誤的影響。經(jīng)濟(jì)上的獨(dú)立性使測試有更充分的條件按測試要求去完成。

　　專業(yè)性——獨(dú)立測試作為一種專業(yè)工作，在長期的工作過程中勢必能夠積累大量實(shí)踐經(jīng)驗(yàn)，形成自己的專業(yè)知識。同時(shí)軟件測試也是技術(shù)含量很高的工作，需要有專業(yè)隊(duì)伍加以研究，并進(jìn)行工程實(shí)踐。專業(yè)化分工是提高測試水平、保證測試質(zhì)量、充分發(fā)揮測試效應(yīng)的必然途徑。

　　權(quán)威性——由于專業(yè)優(yōu)勢，獨(dú)立測試工作形成的測試結(jié)果更具信服力，而測試結(jié)果常常和對軟件的質(zhì)量評價(jià)聯(lián)系在一起，專業(yè)化的獨(dú)立測試機(jī)構(gòu)的評價(jià)，更客觀、公正和具有權(quán)威性。

　　資源有保證——獨(dú)立測試機(jī)構(gòu)的主要任務(wù)是進(jìn)行獨(dú)立測試工作，這使得測試工作在經(jīng)費(fèi)、人力和計(jì)劃方面更有保證，不會(huì)因?yàn)殚_發(fā)的壓力減少對測試的投入，降低測試的有效性可以避免開發(fā)單位側(cè)重軟件開發(fā)而對測試工作產(chǎn)生不利的影響。

　　軟件測試主要工作內(nèi)容是驗(yàn)證(verification)和確認(rèn)(validation )，下面分別給出其概念：

　　驗(yàn)證(verification)是保證軟件正確地實(shí)現(xiàn)了一些特定功能的一系列活動(dòng)，即保證軟件做了你所期望的事情。(Do the right thing)

　　1.確定軟件生存周期中的一個(gè)給定階段的產(chǎn)品是否達(dá)到前階段確立的需求的過程；

　　2.程序正確性的形式證明，即采用形式理論證明程序符合設(shè)計(jì)規(guī)約規(guī)定的過程；

　　3.評市、審查、測試、檢查、審計(jì)等各類活動(dòng)，或?qū)δ承╉?xiàng)處理、服務(wù)或文件等是否和規(guī)定的需求相一致進(jìn)行判斷和提出報(bào)告。

　　確認(rèn)(validation)是一系列的活動(dòng)和過程，目的是想證實(shí)在一個(gè)給定的外部環(huán)境中軟件的邏輯正確性。即保證軟件以正確的方式來做了這個(gè)事件(Do it right)

　　1.靜態(tài)確認(rèn)，不在計(jì)算機(jī)上實(shí)際執(zhí)行程序，通過人工或程序分析來證明軟件的正確性；

　　2.動(dòng)態(tài)確認(rèn)，通過執(zhí)行程序做分析，測試程序的動(dòng)態(tài)行為，以證實(shí)軟件是否存在問題。

　　軟件測試的對象不僅僅是程序測試，軟件測試應(yīng)該包括整個(gè)軟件開發(fā)期間各個(gè)階段所產(chǎn)生的文檔，如需求規(guī)格說明、概要設(shè)計(jì)文檔、詳細(xì)設(shè)計(jì)文檔，當(dāng)然軟件測試的主要對象還是源程序。

　　從是否關(guān)心軟件內(nèi)部結(jié)構(gòu)和具體實(shí)現(xiàn)的角度劃分

　　A.白盒測試

　　B.黑盒測試

　　C.灰盒測試

　　A.靜態(tài)測試

　　B.動(dòng)態(tài)測試。

　　A.單元測試

　　B.集成測試

　　C.確認(rèn)測試

　　D.系統(tǒng)測試

　　E.驗(yàn)收測試

　　* 測試過程按4個(gè)步驟進(jìn)行，即單元測試、集成測試、確認(rèn)測試和系統(tǒng)測試及發(fā)版測試。

　　* 開始是單元測試，集中對用源代碼實(shí)現(xiàn)的每一個(gè)程序單元進(jìn)行測試，檢查各個(gè)程序模塊是否正確地實(shí)現(xiàn)了規(guī)定的功能。

　　* 集成測試把已測試過的模塊組裝起來，主要對與設(shè)計(jì)相關(guān)的軟件體系結(jié)構(gòu)的構(gòu)造進(jìn)行測試。

　　* 確認(rèn)測試則是要檢查已實(shí)現(xiàn)的軟件是否滿足了需求規(guī)格說明中確定了的各種需求，以及軟件配置是否完全、正確。

　　* 系統(tǒng)測試把已經(jīng)經(jīng)過確認(rèn)的軟件納入實(shí)際運(yùn)行環(huán)境中，與其它系統(tǒng)成份組合在一起進(jìn)行測試。

　　單元測試 (Unit Testing)

　　* 單元測試又稱模塊測試，是針對軟件設(shè)計(jì)的最小單位 ─ 程序模塊，進(jìn)行正確性檢驗(yàn)的測試工作。其目的在于發(fā)現(xiàn)各模塊內(nèi)部可能存在的各種差錯(cuò)。

　　* 單元測試需要從程序的內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計(jì)測試用例。多個(gè)模塊可以平行地獨(dú)立進(jìn)行單元測試。

　　1. 單元測試的內(nèi)容

　　* 在單元測試時(shí)，測試者需要依據(jù)詳細(xì)設(shè)計(jì)說明書和源程序清單，了解該模塊的I/O條件和模塊的邏輯結(jié)構(gòu)，主要采用白盒測試的測試用例，輔之以黑盒測試的測試用例，使之對任何合理的輸入和不合理的輸入，都能鑒別和響應(yīng)。

　　(1) 模塊接口測試

　　* 在單元測試的開始，應(yīng)對通過被測模塊的數(shù)據(jù)流進(jìn)行測試。測試項(xiàng)目包括：

　　– 調(diào)用本模塊的輸入?yún)?shù)是否正確；

　　– 本模塊調(diào)用子模塊時(shí)輸入給子模塊的參數(shù)是否正確；

　　– 全局量的定義在各模塊中是否一致；

　　* 在做內(nèi)外存交換時(shí)要考慮：

　　– 文件屬性是否正確；

　　– OPEN與CLOSE語句是否正確；

　　– 緩沖區(qū)容量與記錄長度是否匹配；

　　– 在進(jìn)行讀寫操作之前是否打開了文件；

　　– 在結(jié)束文件處理時(shí)是否關(guān)閉了文件；

　　– 正文書寫／輸入錯(cuò)誤，

　　– I／O錯(cuò)誤是否檢查并做了處理。

　　(2) 局部數(shù)據(jù)結(jié)構(gòu)測試

　　* 不正確或不一致的數(shù)據(jù)類型說明

　　* 使用尚未賦值或尚未初始化的變量

　　* 錯(cuò)誤的初始值或錯(cuò)誤的缺省值

　　* 變量名拼寫錯(cuò)或書寫錯(cuò)

　　* 不一致的數(shù)據(jù)類型

　　* 全局?jǐn)?shù)據(jù)對模塊的影響

　　(3) 路徑測試

　　* 選擇適當(dāng)?shù)臏y試用例，對模塊中重要的執(zhí)行路徑進(jìn)行測試。

　　* 應(yīng)當(dāng)設(shè)計(jì)測試用例查找由于錯(cuò)誤的計(jì)算、不正確的比較或不正常的控制流而導(dǎo)致的錯(cuò)誤。

　　* 對基本執(zhí)行路徑和循環(huán)進(jìn)行測試可以發(fā)現(xiàn)大量的路徑錯(cuò)誤。

　　(4) 錯(cuò)誤處理測試

　　* 出錯(cuò)的描述是否難以理解

　　* 出錯(cuò)的描述是否能夠?qū)﹀e(cuò)誤定位

　　* 顯示的錯(cuò)誤與實(shí)際的錯(cuò)誤是否相符

　　* 對錯(cuò)誤條件的處理正確與否

　　* 在對錯(cuò)誤進(jìn)行處理之前，錯(cuò)誤條件是否已經(jīng)引起系統(tǒng)的干預(yù)等

　　(5) 邊界測試

　　* 注意數(shù)據(jù)流、控制流中剛好等于、大于或小于確定的比較值時(shí)出錯(cuò)的可能性。對這些地方要仔細(xì)地選擇測試用例，認(rèn)真加以測試。

　　* 如果對模塊運(yùn)行時(shí)間有要求的話，還要專門進(jìn)行關(guān)鍵路徑測試，以確定最壞情況下和平均意義下影響模塊運(yùn)行時(shí)間的因素。

　　2. 單元測試的步驟

　　* 模塊并不是一個(gè)獨(dú)立的程序，在考慮測試模塊時(shí)，同時(shí)要考慮它和外界的聯(lián)系，用一些輔助模塊去模擬與被測模塊相聯(lián)系的其它模塊。

　　– 驅(qū)動(dòng)模塊 (driver)

　　– 樁模塊 (stub) ── 存根模塊

　　* 如果一個(gè)模塊要完成多種功能，可以將這個(gè)模塊看成由幾個(gè)小程序組成。必須對其中的每個(gè)小程序先進(jìn)行單元測試要做的工作，對關(guān)鍵模塊還要做性能測試。

　　* 對支持某些標(biāo)準(zhǔn)規(guī)程的程序，更要著手進(jìn)行互聯(lián)測試。有人把這種情況特別稱為模塊測試，以區(qū)別單元測試。

　　集成測試（Integrated Testing）

　　* 集成測試 (集成測試、聯(lián)合測試）

　　* 通常，在單元測試的基礎(chǔ)上，需要將所有模塊按照設(shè)計(jì)要求組裝成為系統(tǒng)。這時(shí)需要考慮的問題是：

　　– 在把各個(gè)模塊連接起來的時(shí)候，穿越模塊接口的數(shù)據(jù)是否會(huì)丟失；

　　– 一個(gè)模塊的功能是否會(huì)對另一個(gè)模塊的功能產(chǎn)生不利的影響；

　　– 各個(gè)子功能組合起來，能否達(dá)到預(yù)期要求的父功能；

　　– 全局?jǐn)?shù)據(jù)結(jié)構(gòu)是否有問題；

　　– 單個(gè)模塊的誤差累積起來，是否會(huì)放大，從而達(dá)到不能接受的程度。

　　在單元測試的同時(shí)可進(jìn)行集成測試，

　　發(fā)現(xiàn)并排除在模塊連接中可能出現(xiàn)

　　的問題，最終構(gòu)成要求的軟件系統(tǒng)。

　　* 子系統(tǒng)的集成測試特別稱為部件測試，它所做的工作是要找出集成后的子系統(tǒng)與系統(tǒng)需求規(guī)格說明之間的不一致。

　　* 通常，把模塊集成成為系統(tǒng)的方式有兩種

　　– 一次性集成方式

　　– 增殖式集成方式

　　1. 一次性集成方式(big bang)

　　* 它是一種非增殖式組裝方式。也叫做整體拼裝。

　　* 使用這種方式，首先對每個(gè)模塊分別進(jìn)行模塊測試，然后再把所有模塊組裝在一起進(jìn)行測試，最終得到要求的軟件系統(tǒng)。

　　2. 增殖式集成方式

　　* 這種集成方式又稱漸增式集成

　　* 首先對一個(gè)個(gè)模塊進(jìn)行模塊測試，然后將這些模塊逐步組裝成較大的系統(tǒng)

　　* 在集成的過程中邊連接邊測試，以發(fā)現(xiàn)連接過程中產(chǎn)生的問題

　　* 通過增殖逐步組裝成為要求的軟件系統(tǒng)。

　　(1) 自頂向下的增殖方式

　　* 這種集成方式將模塊按系統(tǒng)程序結(jié)構(gòu)，沿控制層次自頂向下進(jìn)行組裝。

　　* 自頂向下的增殖方式在測試過程中較早地驗(yàn)證了主要的控制和判斷點(diǎn)。

　　* 選用按深度方向組裝的方式，可以首先實(shí)現(xiàn)和驗(yàn)證一個(gè)完整的軟件功能。

　　(2) 自底向上的增殖方式

　　* 這種集成的方式是從程序模塊結(jié)構(gòu)的最底層的模塊開始集成和測試。

　　* 因?yàn)槟K是自底向上進(jìn)行組裝，對于一個(gè)給定層次的模塊，它的子模塊（包括子模塊的所有下屬模塊）已經(jīng)組裝并測試完成，所以不再需要樁模塊。在模塊的測試過程中需要從子模塊得到的信息可以直接運(yùn)行子模塊得到。

　　* 自頂向下增殖的方式和自底向上增殖的方式各有優(yōu)缺點(diǎn)。

　　* 一般來講，一種方式的優(yōu)點(diǎn)是另一種方式的缺點(diǎn)。

　　(3) 混合增殖式測試

　　* 衍變的自頂向下的增殖測試

　　– 首先對輸入／輸出模塊和引入新算法模塊進(jìn)行測試;

　　– 再自底向上組裝成為功能相當(dāng)完整且相對獨(dú)立的子系統(tǒng);

　　– 然后由主模塊開始自頂向下進(jìn)行增殖測試。

　　* 自底向上-自頂向下的增殖測試

　　– 首先對含讀操作的子系統(tǒng)自底向上直至根結(jié)點(diǎn)模塊進(jìn)行組裝和測試;

　　– 然后對含寫操作的子系統(tǒng)做自頂向下的組裝與測試。

　　* 回歸測試

　　– 這種方式采取自頂向下的方式測試被修改的模塊及其子模塊;

　　– 然后將這一部分視為子系統(tǒng)，再自底向上測試。

　　關(guān)鍵模塊問題

　　* 在組裝測試時(shí)，應(yīng)當(dāng)確定關(guān)鍵模塊，對這些關(guān)鍵模塊及早進(jìn)行測試。

　　* 關(guān)鍵模塊的特征：

　?、?滿足某些軟件需求；

　?、?在程序的模塊結(jié)構(gòu)中位于較高的層次（高層控制模塊）；

　　③ 較復(fù)雜、較易發(fā)生錯(cuò)誤；

　?、?有明確定義的性能要求。

　　確認(rèn)測試（Validation Testing）

　　* 確認(rèn)測試又稱有效性測試。任務(wù)是驗(yàn)證軟件的功能和性能及其它特性是否與用戶的要求一致。

　　* 對軟件的功能和性能要求在軟件需求規(guī)格說明書中已經(jīng)明確規(guī)定。它包含的信息就是軟件確認(rèn)測試的基礎(chǔ)。

　　1. 進(jìn)行有效性測試（黑盒測試）

　　* 有效性測試是在模擬的環(huán)境 (可能就是開發(fā)的環(huán)境) 下，運(yùn)用黑盒測試的方法，驗(yàn)證被測軟件是否滿足需求規(guī)格說明書列出的需求。

　　* 首先制定測試計(jì)劃，規(guī)定要做測試的種類。還需要制定一組測試步驟，描述具體的測試用例。

　　* 通過實(shí)施預(yù)定的測試計(jì)劃和測試步驟，確定

　　– 軟件的特性是否與需求相符；

　　– 所有的文檔都是正確且便于使用；

　　– 同時(shí)，對其它軟件需求，例如可移植性、兼容性、出錯(cuò)自動(dòng)恢復(fù)、可維護(hù)性等，也都要進(jìn)行測試

　　* 在全部軟件測試的測試用例運(yùn)行完后，所有的測試結(jié)果可以分為兩類：

　　– 測試結(jié)果與預(yù)期的結(jié)果相符。這說明軟件的這部分功能或性能特征與需求規(guī)格說明書相符合，從而這部分程序被接受。

　　– 測試結(jié)果與預(yù)期的結(jié)果不符。這說明軟件的這部分功能或性能特征與需求規(guī)格說明不一致，因此要為它提交一份問題報(bào)告。

　　2. 軟件配置復(fù)查

　　n 軟件配置復(fù)查的目的是保證

　　u 軟件配置的所有成分都齊全；

　　u 各方面的質(zhì)量都符合要求；

　　u 具有維護(hù)階段所必需的細(xì)節(jié)；

　　u 而且已經(jīng)編排好分類的目錄。

　　n 應(yīng)當(dāng)嚴(yán)格遵守用戶手冊和操作手冊中規(guī)定的使用步驟，以便檢查這些文檔資料的完整性和正確性。

　　驗(yàn)收測試（Acceptance Testing）

　　* 在通過了系統(tǒng)的有效性測試及軟件配置審查之后，就應(yīng)開始系統(tǒng)的驗(yàn)收測試。

　　* 驗(yàn)收測試是以用戶為主的測試。軟件開發(fā)人員和QA（質(zhì)量保證）人員也應(yīng)參加。

　　* 由用戶參加設(shè)計(jì)測試用例，使用生產(chǎn)中的實(shí)際數(shù)據(jù)進(jìn)行測試。

　　* 在測試過程中，除了考慮軟件的功能和性能外，還應(yīng)對軟件的可移植性、兼容性、可維護(hù)性、錯(cuò)誤的恢復(fù)功能等進(jìn)行確認(rèn)。

　　* 確認(rèn)測試應(yīng)交付的文檔有：

　　– 確認(rèn)測試分析報(bào)告

　　– 最終的用戶手冊和操作手冊

　　– 項(xiàng)目開發(fā)總結(jié)報(bào)告。

　　系統(tǒng)測試（System Testing）

　　* 系統(tǒng)測試，是將通過確認(rèn)測試的軟件，作為整個(gè)基于計(jì)算機(jī)系統(tǒng)的一個(gè)元素，與計(jì)算機(jī)硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其它系統(tǒng)元素結(jié)合在一起，在實(shí)際運(yùn)行環(huán)境下，對計(jì)算機(jī)系統(tǒng)進(jìn)行一系列的組裝測試和確認(rèn)測試。

　　* 系統(tǒng)測試的目的在于通過與系統(tǒng)的需求定義作比較, 發(fā)現(xiàn)軟件與系統(tǒng)的定義不符合或與之矛盾的地方。

　　單元測試

　　集成測試

　　系統(tǒng)測試

　　V模型是軟件開發(fā)瀑布模型的變種，它反映了測試活動(dòng)與分析和設(shè)計(jì)的關(guān)系 。

　　從左到右，描述了基本的開發(fā)過程和測試行為，非常明確地標(biāo)明了測試過程中存在的不同級別，并且清楚地描述了這些測試階段和開發(fā)過程期間各階段的對應(yīng)關(guān)系 。

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

　　用戶需求 驗(yàn)收測試

　　需求分析和系統(tǒng)設(shè)計(jì) 確認(rèn)測試和系統(tǒng)測試

　　概要設(shè)計(jì) 集成測試

　　詳細(xì)設(shè)計(jì) 單元測試

　　編碼

　　V模型問題：

　　1.測試是開發(fā)之后的一個(gè)階段。

　　2.測試的對象就是程序本身。

　　3.實(shí)際應(yīng)用中容易導(dǎo)致需求階段的錯(cuò)誤一直到最后系統(tǒng)測試階段才被發(fā)現(xiàn)。

　　4.整個(gè)軟件產(chǎn)品的過程質(zhì)量保證完全依賴于開發(fā)人員的能力和對工作的責(zé)任心，而且上一步的結(jié)果必須是充分和正確的，如果任何一個(gè)環(huán)節(jié)出了問題，則必將嚴(yán)重的影響整個(gè)工程的質(zhì)量和預(yù)期進(jìn)度

　　W模型由Evolutif公司公司提出，相對于V模型，W模型增加了軟件各開發(fā)階段中應(yīng)同步進(jìn)行的驗(yàn)證和確認(rèn)活動(dòng)。W模型由兩個(gè)V字型模型組成，分別代表測試與開發(fā)過程，圖中明確表示出了測試與開發(fā)的并行關(guān)系。 W模型強(qiáng)調(diào)：測試伴隨著整個(gè)軟件開發(fā)周期，而且測試的對象不僅僅是程序，需求、設(shè)計(jì)等同樣要測試，也就是說，測試與開發(fā)是同步進(jìn)行的。W模型有利于盡早地全面的發(fā)現(xiàn)問題。例如，需求分析完成后，測試人員就應(yīng)該參與到對需求的驗(yàn)證和確認(rèn)活動(dòng)中，以盡早地找出缺陷所在。同時(shí)，對需求的測試也有利于及時(shí)了解項(xiàng)目難度和測試風(fēng)險(xiǎn)，及早制定應(yīng)對措施，這將顯著減少總體測試時(shí)間，加快項(xiàng)目進(jìn)度。 但W模型也存在局限性。在W模型中，需求、設(shè)計(jì)、編碼等活動(dòng)被視為串行的，同時(shí)，測試和開發(fā)活動(dòng)也保持著一種線性的前后關(guān)系，上一階段完全結(jié)束，才可正式開始下一個(gè)階段工作。這樣就無法支持迭代的開發(fā)模型。對于當(dāng)前軟件開發(fā)復(fù)雜多變的情況，W模型并不能解除測試管理面臨著困惑。

　　

　　H模型中, 軟件測試過程活動(dòng)完全獨(dú)立,貫穿于整個(gè)產(chǎn)品的周期,與其他流程并發(fā)地進(jìn)行,某個(gè)測試點(diǎn)準(zhǔn)備就緒時(shí),就可以從測試準(zhǔn)備階段進(jìn)行到測試執(zhí)行階段。軟件測試可以盡早的進(jìn)行,并且可以根據(jù)被測物的不同而分層次進(jìn)行。

　　

這個(gè)示意圖演示了在整個(gè)生產(chǎn)周期中某個(gè)層次上的一次測試“微循環(huán)”。圖中標(biāo)注的其它流程可以是任意的開發(fā)流程,例如設(shè)計(jì)流程或者編碼流程。也就是說, 只要測試條件成熟了,測試準(zhǔn)備活動(dòng)完成了,測試執(zhí)行活動(dòng)就可以進(jìn)行了。

　　H模型揭示了一個(gè)原理:軟件測試是一個(gè)獨(dú)立的流程,貫穿產(chǎn)品整個(gè)生命周期,與其他流程并發(fā)地進(jìn)行。H模型指出軟件測試要盡早準(zhǔn)備, 盡早執(zhí)行。不同的測試活動(dòng)可以是按照某個(gè)次序先后進(jìn)行的,但也可能是反復(fù)的,只要某個(gè)測試達(dá)到準(zhǔn)備就緒點(diǎn),測試執(zhí)行活動(dòng)就可以開展。

　　X模型也是對V模型的改進(jìn),X模型提出針對單獨(dú)的程序片段進(jìn)行相互分離的編碼和測試,此后通過頻繁的交接,通過集成最終合成為可執(zhí)行的程序。X模型的左邊描述的是針對單獨(dú)程序片段所進(jìn)行的相互分離的編碼和測試，此后將進(jìn)行頻繁的交接，通過集成最終成為可執(zhí)行的程序，然后再對這些可執(zhí)行程序進(jìn)行測試。己通過集成測試的成品可以進(jìn)行封裝并提交給用戶，也可以作為更大規(guī)模和范圍內(nèi)集成的一部分。多根并行的曲線表示變更可以在各個(gè)部分發(fā)生。由圖中可見，X模型還定位了探索性測試，這是不進(jìn)行事先計(jì)劃的特殊類型的測試，這一方式往往能幫助有經(jīng)驗(yàn)的測試人員在測試計(jì)劃之外發(fā)現(xiàn)更多的軟件錯(cuò)誤。但這樣可能對測試造成人力、物力和財(cái)力的浪費(fèi)，對測試員的熟練程度要求比較高。

　　

　　軟件測試職業(yè)發(fā)展前景

　　隨著我國軟件業(yè)的發(fā)展，專業(yè)的軟件測試人員成為了眾多知名公司追逐的對象，軟件測試有著廣闊的發(fā)展前景，具體可以分為：

　　• 初級測試工程師：初級職位，開發(fā)測試腳本，執(zhí)行測試

　　•測試工程師 / 程序分析員：編寫自動(dòng)測試腳本程序

　　•高級測試工程師 / 程序分析員：確定測試過程并指導(dǎo)初級測試工程師

　　•測試組負(fù)責(zé)人：監(jiān)管 1-3 人工作，負(fù)責(zé)規(guī)模 / 成本估算

　　•測試 / 編程負(fù)責(zé)人：監(jiān)管 4-8 人，安排和領(lǐng)導(dǎo)任務(wù)完成，提出技術(shù)方法

　　•測試 / 質(zhì)量保證 / 項(xiàng)目經(jīng)理：負(fù)責(zé) 8 名以上人員的一個(gè)或多個(gè)項(xiàng)目，負(fù)責(zé)全生存期

　　•業(yè)務(wù) / 產(chǎn)品經(jīng)理：負(fù)責(zé)多個(gè)項(xiàng)目的人員管理，負(fù)責(zé)項(xiàng)目方向和業(yè)務(wù)盈虧

　　• 軟件測試工程師

　　軟件測試工程師簡單的說是軟件開發(fā)過程中的質(zhì)量檢測者和保障者，負(fù)責(zé)軟件質(zhì)量的把關(guān)工作。軟件測試工程師（Software Testing Engineer）的主要工作職責(zé)是，理解產(chǎn)品的功能要求，并對其進(jìn)行測試，檢查軟件有沒有錯(cuò)誤（Bug），決定軟件是否具有穩(wěn)定性（Robustness），寫出相應(yīng)的測試規(guī)范和測試用例。簡而言之，軟件測試工程師在一家軟件企業(yè)中擔(dān)當(dāng)?shù)氖?#8220;質(zhì)量管理”角色，及時(shí)糾錯(cuò)及時(shí)更正，確保產(chǎn)品的正常運(yùn)作。^[1]

　　1、編寫軟件測試計(jì)劃，設(shè)計(jì)軟件測試腳本和用例，搭建軟件測試環(huán)境；

　　2、執(zhí)行軟件項(xiàng)目測試，包括功能測試、性能測試、易用性測試等；

　　3、整理、分析、報(bào)告并追蹤軟件缺陷，并確認(rèn)軟件測試問題得以解決；

　　4、撰寫軟件測試結(jié)果分析報(bào)告，預(yù)先評估項(xiàng)目的風(fēng)險(xiǎn)，編寫其它相關(guān)文檔；

　　5、結(jié)合研發(fā)軟件產(chǎn)品項(xiàng)目情況，制定相應(yīng)的軟件、項(xiàng)目版本控制制度。

　　• 至少是一名軟件開發(fā)工程師

　　• 軟件測試技術(shù)主管

　　• 軟件測試設(shè)計(jì)師

　　• 測試主管

　　• 測試管理者

　　• 項(xiàng)目主管

　　• 產(chǎn)品發(fā)布主管

　　AutoRunner 是國內(nèi)第一款自動(dòng)化測試工具，可以用來完成功能測試、回歸測試、每日構(gòu)建測試與自動(dòng)回歸測試等工作。是具有腳本語言的、提供針對腳本完善的跟蹤和調(diào)試功能的、支持IE測試和Windows native測試的自動(dòng)化測試工具。

　　TestCenter 是一款功能強(qiáng)大測試管理工具，它可以幫助您：實(shí)現(xiàn)測試用例的過程管理，對測試需求過程、測試用例設(shè)計(jì)過程、業(yè)務(wù)組件設(shè)計(jì)實(shí)現(xiàn)過程等整個(gè)測試過程進(jìn)行管理。實(shí)現(xiàn)測試用例的標(biāo)準(zhǔn)化即每個(gè)測試人員都能夠理解并使用標(biāo)準(zhǔn)化后的測試用例，降低了測試用例對個(gè)人的依賴；提供測試用例復(fù)用，用例和腳本能夠被復(fù)用，以保護(hù)測試人員的資產(chǎn)；提供可伸縮的測試執(zhí)行框架，提供自動(dòng)測試支持；提供測試數(shù)據(jù)管理，幫助用戶同意管理測試數(shù)據(jù)，降低測試數(shù)據(jù)和測試腳本之間的耦合度。

　　TAR(Terminal AutoRunner)適用于VT100、VT220等標(biāo)準(zhǔn)的應(yīng)用系統(tǒng)，支持命令行模式和窗口模式（使用Cursors編寫的應(yīng)用程序）,支持自動(dòng)錄制腳本、所見即所得的資源和腳本編輯，穩(wěn)定的自動(dòng)同步功能。是目前國內(nèi)最好的銀行業(yè)務(wù)測試工具.

　　LoadRunner 是一種預(yù)測系統(tǒng)行為和性能的工業(yè)標(biāo)準(zhǔn)級負(fù)載測試工具。通過以模擬上千萬用戶實(shí)施并發(fā)負(fù)載及實(shí)時(shí)性能監(jiān)測的方式來確認(rèn)和查找問題，LoadRunner 能夠?qū)φ麄€(gè)企業(yè)架構(gòu)進(jìn)行測試。通過使用LoadRunner ， 企業(yè)能最大限度地縮短測試時(shí)間， 優(yōu)化性能和加速應(yīng)用系統(tǒng)的發(fā)布周期。目前企業(yè)的網(wǎng)絡(luò)應(yīng)用環(huán)境都必須支持大量用戶，網(wǎng)絡(luò)體系架構(gòu)中含各類應(yīng)用環(huán)境且由不同供應(yīng)商提供軟件和硬件產(chǎn)品。難以預(yù)知的用戶負(fù)載和愈來愈復(fù)雜的應(yīng)用環(huán)境使公司時(shí)時(shí)擔(dān)心會(huì)發(fā)生用戶響應(yīng)速度過慢， 系統(tǒng)崩潰等問題。這些都不可避免地導(dǎo)致公司收益的損失。

　　TestDirector 是全球最大的軟件測試工具提供商Mercury Interactive公司生產(chǎn)的企業(yè)級測試管理工具，也是業(yè)界第一個(gè)基于Web的測試管理系統(tǒng),它可以在您公司內(nèi)部或外部進(jìn)行全球范圍內(nèi)測試的管理。通過在一個(gè)整體的應(yīng)用系統(tǒng)中集成了測試管理的各個(gè)部分，包括需求管理，測試計(jì)劃，測試執(zhí)行以及錯(cuò)誤跟蹤等功能，TestDirector極大地加速了測試過程。

　　1 目的：統(tǒng)一測試用例編寫的規(guī)范，以保證使用最有效的測試用例，保證測試質(zhì)量。

　　2 范圍：適用于公司對產(chǎn)品的業(yè)務(wù)流程、功能測試測試用例的編寫。

　　3 術(shù)語解釋

　　3.1 測試分析：對重要業(yè)務(wù)、重要流程進(jìn)行測試前的分析。

　　3.2 業(yè)務(wù)流程測試用例：關(guān)于產(chǎn)品業(yè)務(wù)、重要流程的測試用例。

　　4 業(yè)務(wù)流程測試用例編寫原則

　　4.1 系統(tǒng)性

　　4.1.1 對于系統(tǒng)業(yè)務(wù)流程要能夠完整說明整個(gè)系統(tǒng)的業(yè)務(wù)需求、系統(tǒng)由幾個(gè)子系統(tǒng)組成以及它們之間的關(guān)系；

　　4.1.2 對于模塊業(yè)務(wù)流程要能夠說明清楚子系統(tǒng)內(nèi)部功能、重要功能點(diǎn)以及它們之間的關(guān)系；

　　4.2 連貫性

　　4.2.1 對于系統(tǒng)業(yè)務(wù)流程來說，各個(gè)子系統(tǒng)之間是如何連接在一起，如果需要接口，各個(gè)子系統(tǒng)之間是否有正確的接口；如果是依靠頁面鏈接，頁面鏈接是否正確；

　　4.2.2 對于模塊業(yè)務(wù)流程來說，同級模塊以及上下級模塊是如何構(gòu)成一個(gè)子系統(tǒng)，其內(nèi)部功能接口是否連貫；

　　5 測試用例設(shè)計(jì)的方法

　　5.1 等價(jià)類劃分法

　　5.1.1 確定等價(jià)類的原則

　　5.1.1.1 如果輸入條件決定了取值范圍，或值的個(gè)數(shù)，則可以確立一個(gè)有效等價(jià)類和兩個(gè)無效等價(jià)類。

　　5.1.1.2 如果輸入條件規(guī)定了輸入值的集合，或者規(guī)定了“必須如何”的條件，此時(shí)可確立一個(gè)有效等價(jià)類和一個(gè)無效等價(jià)類；

　　5.1.1.3 如果輸入條件是一個(gè)布爾量，則可以確定一個(gè)有效等價(jià)類和一個(gè)無效等價(jià)類；

　　5.1.1.4 如果規(guī)定了輸入數(shù)據(jù)的一組值，而且程序?qū)γ總€(gè)輸入值分別進(jìn)行處理，此時(shí)可為每一個(gè)輸入值確立一個(gè)有效等價(jià)類，此外，針對這組值確立一個(gè)無效等價(jià)類，它是所有不允許輸入值的集合；

　　5.1.1.5 如果規(guī)定了輸入數(shù)據(jù)必須遵守的規(guī)則，則可以確立一個(gè)有效等價(jià)類（符合規(guī)則）和若干個(gè)無效等價(jià)類（從不同的角度違反規(guī)則）。

　　5.1.1.6 如果確知，已劃分的等價(jià)類中各元素在程序中的處理方式不同，則應(yīng)將此等價(jià)類進(jìn)一步劃分成更小的等價(jià)類。

　　5.1.2 測試用例的選擇原則

　　5.1.2.1 為每一個(gè)等價(jià)類規(guī)定一個(gè)唯一的編號；

　　5.1.2.2 設(shè)計(jì)一個(gè)新的測試用例，使其盡可能多的覆蓋尚未被覆蓋的有效等價(jià)類，重復(fù)這一步，直至所有的有效等價(jià)類都被覆蓋過；

　　5.1.2.3 設(shè)計(jì)一個(gè)新的測試用例，使其僅覆蓋一個(gè)尚未被覆蓋的無效等價(jià)類，重復(fù)這一步，直至所有的無效等價(jià)類都被覆蓋為止。

　　5.2 邊界值分析法

　　5.2.1 測試用例的選擇原則

　　5.2.1.1 如果輸入了條件規(guī)定了值的范圍，則應(yīng)取剛達(dá)到這個(gè)范圍的邊界值，以及剛剛超越這個(gè)邊界范圍的值作為測試輸入數(shù)據(jù)；

　　5.2.1.2 如果輸入條件規(guī)定了值的個(gè)數(shù)，則用最大個(gè)數(shù)、最小個(gè)數(shù)、比最大多1、比最小小1的數(shù)作為測試輸入數(shù)據(jù)；

　　5.2.1.3 根據(jù)規(guī)格說明的每個(gè)輸出條件，使用前面的原則；

　　5.2.1.4 如果程序的規(guī)格說明給出的輸入輸出域是有序集合，則應(yīng)選取集合的每一個(gè)元素和最后一個(gè)元素作為測試用列；

　　5.2.1.5 如果程序中使用了一個(gè)內(nèi)部數(shù)據(jù)結(jié)構(gòu)，則應(yīng)當(dāng)選擇這個(gè)內(nèi)部數(shù)據(jù)結(jié)構(gòu)的邊界上的值作為測試用例；

　　5.2.1.6 分析規(guī)格說明，找出其他可能的邊界條件。

　　6 測試用例設(shè)計(jì)的原則

　　6.1 全面性

　　6.1.1 應(yīng)盡可能覆蓋程序的各種路徑

　　6.1.2 應(yīng)考慮存在跨年、跨月的數(shù)據(jù)

　　6.1.3 大量數(shù)據(jù)并發(fā)測試的準(zhǔn)備

　　6.2 正確性

　　6.2.1 輸入界面后的數(shù)據(jù)應(yīng)與測試文檔所記錄的數(shù)據(jù)一致

　　6.2.2 預(yù)期結(jié)果應(yīng)與測試數(shù)據(jù)發(fā)生的業(yè)務(wù)吻合

　　6.3 符合正常業(yè)務(wù)慣例

　　6.3.1 測試數(shù)據(jù)應(yīng)符合用戶實(shí)際工作業(yè)務(wù)流程

　　6.3.2 兼顧各種業(yè)務(wù)變化的可能

　　6.4 仿真性

　　人名、地名、電話號碼等應(yīng)具有模擬功能，符合一般的命名慣例；不允許出現(xiàn)與知名人士、小說中人物名等雷同情況。

　　6.5 可操作性

　　測試用例中應(yīng)寫清測試的操作步驟，不同的操作步驟相對應(yīng)的操作結(jié)果。

　　7 測試用例編寫格式細(xì)則

　　7.1 測試用例內(nèi)容

　　7.1.1 具體實(shí)施可以采用EXCEL和圖形相結(jié)合，可用EXCEL編寫測試用例的同時(shí)插入圖形來加以說明。測試用例設(shè)計(jì)的內(nèi)容可由：模塊名、功能說明或圖形說明、測試用例輸入、應(yīng)輸出結(jié)果、實(shí)際輸出結(jié)果、結(jié)論、BUG編號、BUG級別8部分組成。

　　7.1.2 在測試用例設(shè)計(jì)模版中有“業(yè)務(wù)流程測試用例設(shè)計(jì)模版”（包含整體業(yè)務(wù)流程）和“功能測試用例設(shè)計(jì)模版”兩個(gè)模板可按需要選擇。

　　7.2 測試用例表格格式

　　7.2.1 表格內(nèi)容的字體為宋體；

　　7.2.2 表格內(nèi)容的字型為12號；

　　8 測試用例優(yōu)先級

　　測試用例優(yōu)先級 描述

　　A 測試計(jì)劃中重要的模塊功能和業(yè)務(wù)流程

　　B 測試計(jì)劃中比較重要的模塊功能和業(yè)務(wù)流程

　　C 測試計(jì)劃中次重要的模塊功能和業(yè)務(wù)流程

　　D 測試計(jì)劃中不重要的模塊功能和業(yè)務(wù)流程

　　E 系統(tǒng)小單元、系統(tǒng)容錯(cuò)功能

　　對于A、B 級應(yīng)重點(diǎn)考慮

　　9 BUG級別

　　參考軟件測試停止標(biāo)準(zhǔn)中的錯(cuò)誤級別.

　　外包軟件測試就是指軟件企業(yè)將軟件項(xiàng)目中的全部或部分測試工作，交給提供軟件外包測試服務(wù)的公司，由他們?yōu)檐浖M(jìn)行專門的測試。這樣做的好處有兩個(gè)：一方面軟件企業(yè)可以更好地專注核心競爭力業(yè)務(wù)，同時(shí)降低軟件項(xiàng)目成本；另一方面，由第三方專業(yè)的測試公司進(jìn)行測試，無論在技術(shù)上還是管理上，對提高軟件測試的有效性都具有重要意義。

　　外包軟件測試行業(yè)前景非?？春?，發(fā)展空間很大。IDG的數(shù)據(jù)顯示，最近幾年，中國的軟件外包產(chǎn)業(yè)年均增長率為36.5%，正處于快速發(fā)展的階段，2008年預(yù)計(jì)已達(dá)到16.9億美元的市場規(guī)模。目前韓日、歐美國家的軟件企業(yè)紛紛關(guān)注中國市場，而作為軟件外包強(qiáng)國的印度，在其國內(nèi)處于前幾位的軟件外包服務(wù)商也準(zhǔn)備來“分一杯羹”。從目前市場來看，選擇將部分軟件測試工作進(jìn)行外包的公司主要是微軟、IBM等國際軟件旗艦企業(yè)，他們利用第三方專業(yè)軟件測試公司，在產(chǎn)品發(fā)布前對軟件進(jìn)行一系列的集成測試和系統(tǒng)測試，既保證了測試工作的全面性，又節(jié)省了人力、物力的開銷。最重要的是，測試結(jié)果往往好于這些軟件企業(yè)最初的預(yù)期，效果非常令人滿意。軟件企業(yè)和提供軟件外包測試服務(wù)的公司進(jìn)行合作，只要達(dá)成雙贏，兩方皆大歡喜，這樣的合作就會(huì)越來越多，項(xiàng)目也會(huì)越做越大。

　　主要業(yè)務(wù)類型

　　·本地化軟件測試

　　·國際化軟件測試

　　主要測試的范圍

　　·本地化語言質(zhì)量測試

　　·國際化軟件的功能和性能測試

　　測試工作主要方式

　　·公司內(nèi)部（In house）執(zhí)行的測試

　　·派駐客戶開發(fā)中心的現(xiàn)場測試（On site）。

　　市場對軟件質(zhì)量重要性的認(rèn)識逐漸增強(qiáng)。所以，軟件測試在軟件項(xiàng)目實(shí)施過程中的重要性日益突出。但是，現(xiàn)實(shí)情況是，與軟件編程比較，軟件測試的地位和作用，還沒有真正受到重視，對于很多人（甚至是軟件項(xiàng)目組的技術(shù)人員）還存在對軟件測試的認(rèn)識誤區(qū)，這進(jìn)一步影響了軟件測試活動(dòng)開展和真正提高軟件測試質(zhì)量。

　?。?）誤區(qū)之一：軟件開發(fā)完成后進(jìn)行軟件測試

　　人們一般認(rèn)為，軟件項(xiàng)目要經(jīng)過以下幾個(gè)階段：需求分析，概要設(shè)計(jì)，詳細(xì)設(shè)計(jì)，軟件編碼，軟件測試，軟件發(fā)布。據(jù)此，認(rèn)為軟件測試只是軟件編碼后的一個(gè)過程。這是不了解軟件測試周期的錯(cuò)誤認(rèn)識。軟件測試是一個(gè)系列過程活動(dòng)，包括軟件測試需求分析，測試計(jì)劃設(shè)計(jì)，測試用例設(shè)計(jì)，執(zhí)行測試。因此，軟件測試貫穿于軟件項(xiàng)目的整個(gè)生命過程。在軟件項(xiàng)目的每一個(gè)階段都要進(jìn)行不同目的和內(nèi)容的測試活動(dòng)，以保證各個(gè)階段的正確性。軟件測試的對象不僅僅是軟件代碼，還包括軟件需求文檔和設(shè)計(jì)文檔。軟件開發(fā)與軟件測試應(yīng)該是交互進(jìn)行的，例如，單元編碼需要單元測試，模塊組合階段需要集成測試。如果等到軟件編碼結(jié)束后才進(jìn)行測試，那么，測試的時(shí)間將會(huì)很短，測試的覆蓋面將很不全面，測試的效果也將大打折扣。更嚴(yán)重的是如果此時(shí)發(fā)現(xiàn)了軟件需求階段或概要設(shè)計(jì)階段的錯(cuò)誤，如果要修復(fù)該類錯(cuò)誤，將會(huì)耗費(fèi)大量的時(shí)間和人力。

　?。?）誤區(qū)之二：軟件發(fā)布后如果發(fā)現(xiàn)質(zhì)量問題，那是軟件測試人員的錯(cuò)

　　這種認(rèn)識很打擊軟件測試人員的積極性。軟件中的錯(cuò)誤可能來自軟件項(xiàng)目中的各個(gè)過程，軟件測試只能確認(rèn)軟件存在錯(cuò)誤，不能保證軟件沒有錯(cuò)誤，因?yàn)閺母旧现v，軟件測試不可能發(fā)現(xiàn)全部的錯(cuò)誤。從軟件開發(fā)的角度看，軟件的高質(zhì)量不是軟件測試人員測出來的，是靠軟件生命周期的各個(gè)過程中設(shè)計(jì)出來的。出現(xiàn)軟件錯(cuò)誤，不能簡單地歸結(jié)為某一個(gè)人的責(zé)任，有些錯(cuò)誤的產(chǎn)生可能不是技術(shù)原因，可能來自于混亂的項(xiàng)目管理。應(yīng)該分析軟件項(xiàng)目的各個(gè)過程，從過程改進(jìn)方面尋找產(chǎn)生錯(cuò)誤的原因和改進(jìn)的措施。

　?。?）誤區(qū)之三：軟件測試要求不高，隨便找個(gè)人多都行

　　很多人都認(rèn)為軟件測試就是安裝和運(yùn)行程序，點(diǎn)點(diǎn)鼠標(biāo)，按按鍵盤的工作。這是由于不了解軟件測試的具體技術(shù)和方法造成的。隨之軟件工程學(xué)的發(fā)展和軟件項(xiàng)目管理經(jīng)驗(yàn)的提高，軟件測試已經(jīng)形成了一個(gè)獨(dú)立的技術(shù)學(xué)科，演變成一個(gè)具有巨大市場需求的行業(yè)。軟件測試技術(shù)不斷更新和完善，新工具，新流程，新測試設(shè)計(jì)方法都在不斷更新，需要掌握和學(xué)習(xí)很多測試知識。所以，具有編程經(jīng)驗(yàn)的程序員不一定是一名優(yōu)秀的測試工程師。軟件測試包括測試技術(shù)和管理兩個(gè)方面，完全掌握這兩個(gè)方面的內(nèi)容，需要很多測試實(shí)踐經(jīng)驗(yàn)和不斷學(xué)習(xí)精神。

　?。?）誤區(qū)之四：軟件測試是測試人員的事情，與程序員無關(guān)開發(fā)和測試是相輔相成的過程

　　需要軟件測試人員、程序員和系統(tǒng)分析師等保持密切的聯(lián)系，需要更多的交流和協(xié)調(diào)，以便提高測試效率。另外，對于單元測試主要應(yīng)該由程序員完成，必要時(shí)測試人員可以幫助設(shè)計(jì)測試樣例。對于測試中發(fā)現(xiàn)的軟件錯(cuò)誤，很多需要程序員通過修改編碼才能修復(fù)。程序員可以通過有目的的分析軟件錯(cuò)誤的類型、數(shù)量，找出產(chǎn)生錯(cuò)誤的位置和原因，以便在今后的編程中避免同樣的錯(cuò)誤，積累編程經(jīng)驗(yàn)，提高編程能力。

　　（5）誤區(qū)之五：項(xiàng)目進(jìn)度吃緊時(shí)少做些測試，時(shí)間富裕時(shí)多做測試

　　這是不重視軟件測試的表現(xiàn)，也是軟件項(xiàng)目過程管理混亂的表現(xiàn)，必然會(huì)降低軟件測試的質(zhì)量。一個(gè)軟件項(xiàng)目的順利實(shí)現(xiàn)需要有合理的項(xiàng)目進(jìn)度計(jì)劃，其中包括合理的測試計(jì)劃，對項(xiàng)目實(shí)施過程中的任何問題，都要有風(fēng)險(xiǎn)分析和相應(yīng)的對策，不要因?yàn)殚_發(fā)進(jìn)度的延期而簡單的縮短測試時(shí)間、人力和資源。因?yàn)榭s短測試時(shí)間帶來的測試不完整，對項(xiàng)目質(zhì)量的下降引起的潛在風(fēng)險(xiǎn)，往往造成更大的浪費(fèi)?？朔@種現(xiàn)象的最好辦法是加強(qiáng)軟件過程的計(jì)劃和控制，包括軟件測試計(jì)劃、測試設(shè)計(jì)、測試執(zhí)行、測試度量和測試控制。

　?。?）誤區(qū)之六：軟件測試是沒有前途的工作，只有程序員才是軟件高手

　　由于我國軟件整體開發(fā)能力比較低，軟件過程很不規(guī)范，很多軟件項(xiàng)目的開發(fā)都還停留在“作坊式”和“壘雞窩”階段。項(xiàng)目的成功往往靠個(gè)別全能程序員決定，他們負(fù)責(zé)總體設(shè)計(jì)和程序詳細(xì)設(shè)計(jì)，認(rèn)為軟件開發(fā)就是編寫代碼，給人的印象往往是程序員是真正的牛人，具有很高的地位和待遇。因此，在這種環(huán)境下，軟件測試很不受重視，軟件測試人員的地位和待遇自然就很低了，甚至軟件測試變得可有可無。隨著市場對軟件質(zhì)量的不斷提高，軟件測試將變得越來越重要，相應(yīng)的軟件測試人員的地位和待遇將會(huì)逐漸提高。在微軟等軟件過程比較規(guī)范的大公司，軟件測試人員的數(shù)量和待遇與程序員沒有多大差別，優(yōu)秀測試人員的待遇甚至比程序員還要高。軟件測試將會(huì)成為一個(gè)具有很大發(fā)展前景的行業(yè)，軟件測試大有前途，市場需要更多具有豐富測試技術(shù)和管理經(jīng)驗(yàn)的測試人員，他們同樣是軟件專家。這兩年來國內(nèi)軟件測試人員的需求不斷增大,越來越多的IT企業(yè)認(rèn)識到了軟件測試的重要性,這種可喜的現(xiàn)狀與發(fā)展趨勢讓筆者對我國軟件業(yè)的發(fā)展重新抱有較大的希望。

　　盡管這是一門嶄新的學(xué)科,目前在國內(nèi)的發(fā)展仍處于"嬰兒"階段,但看到越來越多的軟件公司為軟件測試招兵買馬,看到越來越多的技術(shù)人員投入到軟件測試中,我就情不自禁地感嘆:機(jī)會(huì)來了!這機(jī)會(huì)不僅僅是某一個(gè)人的,而是所有人的,它對每個(gè)人都是公平的,學(xué)的領(lǐng)域需要新的理論新的工具新的方法,由于國內(nèi)的軟件測試還處在一個(gè)比較初級的階段，沒有人確切地知道它需要什么樣的基礎(chǔ),也沒有人確切地知道它應(yīng)該怎樣發(fā)展,因此這個(gè)領(lǐng)域需要大家來共同革命,以促進(jìn)它的深入發(fā)展。

　　隨著軟件產(chǎn)業(yè)的發(fā)展，軟件產(chǎn)品的質(zhì)量控制與質(zhì)量管理正逐漸成為軟件企業(yè)生存與發(fā)展的核心。幾乎每個(gè)大中型IT企業(yè)的軟件產(chǎn)品在發(fā)布前都需要大量的質(zhì)量控制、測試和文檔工作，而這些工作必須依靠擁有嫻熟技術(shù)的專業(yè)軟件人才來完成。軟件測試工程師就是這樣的一個(gè)企業(yè)重頭角色。業(yè)內(nèi)人士分析，該類職位的需求主要集中在沿海發(fā)達(dá)城市，其中北京和上海的需求量分別占去33%和29%。民企需求量最大，占19%，外商獨(dú)資歐美類企業(yè)需求排列第二，占15%。然而，目前的現(xiàn)狀是：一方面企業(yè)對高質(zhì)量的測試工程師需求量越來越大越大，另一方面國內(nèi)原來對測試工程師的職業(yè)重視程度不夠，使許多人不了解測試工程師具體是從事什么工作。這使得許多IT公司只能通過在實(shí)際工作中進(jìn)行淘汰的方式對測試工程師進(jìn)行篩選，因此國內(nèi)在短期將出現(xiàn)測試工程師嚴(yán)重短缺的現(xiàn)象。根據(jù)對近期網(wǎng)絡(luò)招聘IT人才情況的了解，許多正在招聘軟件測試工程師的企業(yè)

　　很少能夠在招聘會(huì)上順利招到合適的人才。在具體工作過程中，測試工程師的工作是利用測試工具按照測試方案和流程對產(chǎn)品進(jìn)行功能和性能測試，甚至根據(jù)需要編寫不同的測試用例，設(shè)計(jì)和維護(hù)測試系統(tǒng)，對測試方案可能出現(xiàn)的問題進(jìn)行分析和評估。對軟件測試工程師而言，必須具有高度的工作責(zé)任心和自信心。任何嚴(yán)格的測試必須是一種實(shí)事求是的測試，因?yàn)樗P(guān)系到一個(gè)產(chǎn)品的質(zhì)量問題，而測試工程師則是產(chǎn)品出貨前的把關(guān)人，所以，沒有專業(yè)的技術(shù)水準(zhǔn)是無法勝任這項(xiàng)工作的。同時(shí)，由于測試工作一般由多個(gè)測試工程師共同完成，并且測試部門一般要與其他部門的人員進(jìn)行較多的溝通，所以要求測試工程師不但要有較強(qiáng)的技術(shù)能力而且要有較強(qiáng)的溝通能力。