【導(dǎo)讀】個(gè)程序員從士兵到將軍的演變過(guò)程。為了幫助學(xué)員更好地理解什么是軟件技術(shù)以及。與軟件工程的區(qū)別，下面對(duì)軟件技術(shù)做些介紹。技術(shù)這個(gè)詞在有些辭典里的意思是指完成技術(shù)工作細(xì)節(jié)所必須具備的能力。生產(chǎn)出合格成品。程序編碼員就是軟件行業(yè)的一線工作人員，他們必須掌握的技術(shù)。很久以來(lái)一直由一種誤解，以為技巧在計(jì)算機(jī)軟件開(kāi)發(fā)中起著重要作用。但是，現(xiàn)在的程序設(shè)計(jì)已有完善的理論作為指導(dǎo)，軟件開(kāi)發(fā)也正在以越來(lái)越。大的工業(yè)化規(guī)模進(jìn)行。在這種形勢(shì)下，對(duì)編寫(xiě)程序的個(gè)體來(lái)說(shuō)，重要的不再是如何。巧妙地利用計(jì)算機(jī)資源，而是用規(guī)范化的作業(yè)方式，編寫(xiě)出高度規(guī)范化的程序代碼。技術(shù)和軟件工程是由不同的職能人員去實(shí)施的。職責(zé)在大多數(shù)情況下只是按設(shè)計(jì)說(shuō)明編寫(xiě)程序代碼，而不是從頭策劃一個(gè)項(xiàng)目。握的軟件技術(shù)，什么是軟件工程應(yīng)該考慮的問(wèn)題，從而更有目的地學(xué)習(xí)軟件技術(shù)。（這是一位中國(guó)軟件公司老板對(duì)印度軟件人所下的評(píng)語(yǔ)。軟件測(cè)試的目的和原則··························································

　　

【正文】 83。135 對(duì)源程序進(jìn)行檢查 135 對(duì)代碼進(jìn)行審查 135 代碼測(cè)試、維護(hù) 136 單元測(cè)試要求至少達(dá)到語(yǔ)句覆蓋 136 單元測(cè)試開(kāi)始要跟蹤每一條語(yǔ)句 136 清理、整理或優(yōu)化后的代碼要經(jīng)過(guò)審查及測(cè)試 136 代碼版本升級(jí)要經(jīng)過(guò)嚴(yán)格測(cè)試 136 使用工具軟件對(duì)代碼版本進(jìn)行維護(hù) 136 正式版本上軟件的任何修改都應(yīng)有詳細(xì)的文檔記錄 136 發(fā)現(xiàn)錯(cuò)誤立即修改，并且要記錄下來(lái) 136 關(guān)鍵的代碼在匯編級(jí)跟蹤 136 提高測(cè)試用例的效率。 136 對(duì)出錯(cuò)處理代碼進(jìn)行充分的測(cè)試 136 仔細(xì)測(cè)試代碼處理數(shù)據(jù)、變量的邊界情 況 136 保留測(cè)試信息 136 不應(yīng)通過(guò)“試”來(lái)解決問(wèn)題，應(yīng)尋找問(wèn)題的根本原因 137 對(duì)自動(dòng)消失的錯(cuò)誤進(jìn)行分析 137 修改錯(cuò)誤不僅要治標(biāo)，更要治本 137 測(cè)試時(shí)應(yīng)設(shè)法使很少發(fā)生的事件經(jīng)常發(fā)生 137 明確模塊或函數(shù)處理哪些事件，并使它們經(jīng)常發(fā)生 137 堅(jiān)持在編碼階段就對(duì)代碼進(jìn)行徹底的單元測(cè)試 137 去除代碼運(yùn)行的隨機(jī)性 137 軟件測(cè)試技術(shù)與質(zhì)量保證 10 第一章 軟件測(cè)試技術(shù) 為了保證軟件的質(zhì)量和可靠性，人們力求在分析、設(shè)計(jì)等各個(gè)開(kāi)發(fā)階段結(jié)束之前，對(duì)軟件進(jìn)行嚴(yán)格的技術(shù)評(píng)審。但即使如此，由于人們本身能力的局限性，審查還不能發(fā)現(xiàn)所有的錯(cuò)誤。而且在編碼階段還會(huì)引進(jìn)大量的錯(cuò)誤。這些錯(cuò)誤和缺陷如果在軟件交付投入生產(chǎn)性運(yùn)行之前不能加以排除的話，在運(yùn)行中遲早會(huì)暴露出來(lái)。但到那時(shí)，不僅改正這些錯(cuò)誤的大家更高，而且往往造成很惡劣的后果。 軟件測(cè)試是在軟件投入生產(chǎn)性運(yùn)行之前，對(duì)軟件需求分析、設(shè)計(jì)規(guī)格說(shuō)明和編碼的最終復(fù)審，是軟件質(zhì)量保證的關(guān)鍵步驟。如果給軟件測(cè)試下 定義的話，可以這樣講：軟件測(cè)試是為了發(fā)現(xiàn)錯(cuò)誤而執(zhí)行程序的過(guò)程?；蛘哒f(shuō)，軟件測(cè)試是根據(jù)軟件開(kāi)發(fā)各階段的規(guī)格說(shuō)明和程序的內(nèi)部結(jié)構(gòu)而精心設(shè)計(jì)一批測(cè)試用例（即輸入數(shù)據(jù)及其預(yù)期的輸出結(jié)果），并利用這些測(cè)試用例去運(yùn)行程序，以發(fā)現(xiàn)程序錯(cuò)誤的過(guò)程。 軟件測(cè)試在軟件生存期中橫跨兩個(gè)階段：通常在編寫(xiě)出每一個(gè)模塊之后就對(duì)它作單元測(cè)試。模塊的編寫(xiě)者與測(cè)試者是同一個(gè)人。在每個(gè)模塊都完成單元測(cè)試后，對(duì)軟件系統(tǒng)還要進(jìn)行各種綜合測(cè)試，通常由專門的測(cè)試人員承擔(dān)這項(xiàng)工作。 軟件測(cè)試的目的和原則 軟件測(cè)試的目的 軟件測(cè)試從不 同的角度出發(fā)會(huì)派生出兩種不同的測(cè)試目的，從用戶的角度出發(fā)，就是希望通過(guò)軟件測(cè)試能充分暴露軟件中存在的問(wèn)題和缺陷，從而考慮是否可以接受該產(chǎn)品，從開(kāi)發(fā)者的角度出發(fā)，就是希望測(cè)試能表明軟件產(chǎn)品不存在錯(cuò)誤，已經(jīng)正確地實(shí)現(xiàn)了用戶的需求，確立人們對(duì)軟件質(zhì)量的信心。顯然，我們應(yīng)該站在用戶的角度，替他們?cè)O(shè)想，就應(yīng)當(dāng)把測(cè)試活動(dòng)的目標(biāo)對(duì)準(zhǔn)揭露程序中存在的錯(cuò)誤。在選取測(cè)試用例時(shí)，考慮那些易于發(fā)現(xiàn)程序錯(cuò)誤的數(shù)據(jù)。 鑒于此， Grenford J. Myers 就軟件測(cè)試目的提出以下觀點(diǎn)。 ? 測(cè)試是程序的執(zhí)行過(guò)程，目的在于發(fā)現(xiàn)錯(cuò)誤； ? 一個(gè)好的測(cè)試用例在于發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯(cuò)誤； ? 一個(gè)成功的測(cè)試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯(cuò)誤的測(cè)試。 這幾句話的意思就是說(shuō)，設(shè)計(jì)測(cè)試的目標(biāo)是以最少的時(shí)間和人力系統(tǒng)地找出軟件中潛在的各種錯(cuò)誤和缺陷。如果我們成功地實(shí)現(xiàn)了測(cè)試，就能夠發(fā)現(xiàn)軟件中的錯(cuò)誤。測(cè)試的附帶收獲是，它能夠證明軟件的功能和性能與需求說(shuō)明相符合。此外，實(shí)施測(cè)試收集到的測(cè)試結(jié)果數(shù)據(jù)為可靠性分析提供了依據(jù)。這里，特別需要說(shuō)明的是，測(cè)試不能表明軟件中不存在錯(cuò)誤，它只能說(shuō)明軟件中存在錯(cuò)誤。 軟件測(cè)試技術(shù)與質(zhì)量保證 11 軟件測(cè)試的原則 根據(jù)上述的測(cè)試 目的 ，軟件測(cè)試的 原則應(yīng)該是 ： 1．應(yīng)當(dāng)把“盡早地和不斷地進(jìn)行軟件測(cè)試”作為軟件開(kāi)發(fā)者的座右銘 由于原始問(wèn)題的復(fù)雜性，軟件本身的復(fù)雜性和抽象性，軟件開(kāi)發(fā)各個(gè)階段工作的多樣性，以及參加開(kāi)發(fā)各種層次人員之間工作的配合關(guān)系等因素，使得開(kāi)發(fā)的每個(gè)環(huán)節(jié)都可能產(chǎn)生錯(cuò)誤。所以我們不應(yīng)把軟件測(cè)試僅僅看作是軟件開(kāi)發(fā)的一個(gè)獨(dú)立階段，而應(yīng)當(dāng)把它貫穿到軟件開(kāi)發(fā)的各個(gè)階段中。堅(jiān)持在軟件開(kāi)發(fā)的各個(gè)階段進(jìn)行技術(shù)評(píng)審，這樣才能在開(kāi)發(fā)過(guò)程中盡早發(fā)現(xiàn)和預(yù)防錯(cuò)誤，把出現(xiàn)的錯(cuò)誤克服在早期，以提高軟件質(zhì)量。 2．測(cè)試用例應(yīng)由測(cè)試輸入數(shù)據(jù)和與之對(duì)應(yīng)的預(yù)期輸出結(jié)果這兩部分組成。 測(cè)試以 前應(yīng)當(dāng)根據(jù)測(cè)試的要求選擇測(cè)試用例，以在測(cè)試過(guò)程中使用。測(cè)試用例主要用來(lái)檢驗(yàn)程序員編制的程序，因此不但需要測(cè)試的輸入數(shù)據(jù)，而且需要針對(duì)這些輸入數(shù)據(jù)的預(yù)期輸出結(jié)果，作為檢驗(yàn)實(shí)測(cè)結(jié)果的基準(zhǔn)。 3．程序員應(yīng)該避免檢查自己的程序。（注意不是指對(duì)程序的調(diào)試） 程序員應(yīng)盡可能避免測(cè)試自己編寫(xiě)的程序，程序開(kāi)發(fā)小組也應(yīng)盡可能避免測(cè)試本小組開(kāi)發(fā)的程序。如果條件允許，最好建立獨(dú)立的軟件測(cè)試小組或機(jī)構(gòu)。這是因?yàn)槿藗兂Ｓ捎诟鞣N原因具有一種不愿意否定自己工作的心理，認(rèn)為揭露自己程序中的問(wèn)題總不是一件愉快的是。這一心理狀態(tài)就成為測(cè)試自己 程序的障礙。另外，程序員對(duì)軟件規(guī)格說(shuō)明理解錯(cuò)誤而引入的錯(cuò)誤則更難發(fā)現(xiàn)。但這并不是說(shuō)程序員不能測(cè)試自己的程序。而是說(shuō)由別人來(lái)測(cè)試可能會(huì)更客觀、更有效，并更容易取得成功。 4．在設(shè)計(jì)測(cè)試用例時(shí)，應(yīng)當(dāng)包括合理的輸入條件和不合理的輸入條件。 所謂合理的輸入條件是指能驗(yàn)證程序正確的輸入條件，而不合理的輸入條件是指異常的、臨界的、可能引起問(wèn)題變異的輸入條件。在測(cè)試程序時(shí)，人們常常傾向于過(guò)多的考慮合法的和期望的輸入條件，以檢查程序是否作了它應(yīng)該作的事情，而忽視了不合法的和預(yù)想不到的輸入條件。事實(shí)上，軟件在投入運(yùn)行以后，用 戶的實(shí)用往往不遵循事先的約定，使用了一些意外的輸入，如果我們開(kāi)發(fā)的軟件遇到這種情況時(shí)不能作出適當(dāng)?shù)姆从?，就容易產(chǎn)生故障，輕則給出錯(cuò)誤的結(jié)果，重則導(dǎo)致軟件失效。因此，用不合理的輸入條件測(cè)試程序時(shí)，往往比用合理的輸入條件進(jìn)行測(cè)試能發(fā)現(xiàn)更多的錯(cuò)誤。 5．充分注意測(cè)試中的群集現(xiàn)象。 測(cè)試是不要被一開(kāi)始發(fā)現(xiàn)的若干錯(cuò)誤所迷惑，找到了幾個(gè)錯(cuò)誤就以為問(wèn)題已經(jīng)解決，不需要繼續(xù)測(cè)試了。經(jīng)驗(yàn)表明，測(cè)試后程序中殘存的錯(cuò)誤數(shù)目與該程序的錯(cuò)誤檢出率成正比。根據(jù)這個(gè)規(guī)律，應(yīng)當(dāng)對(duì)錯(cuò)誤群集的程序段進(jìn)行重點(diǎn)測(cè)試。 軟件測(cè)試技術(shù)與質(zhì)量保證 12 6．嚴(yán)格執(zhí)行測(cè)試計(jì)劃，排除測(cè) 試的隨意性。 對(duì)于測(cè)試計(jì)劃，要明確規(guī)定，不要隨意解釋。 7．應(yīng)當(dāng)對(duì)每一個(gè)測(cè)試結(jié)果作全面檢查。 有些錯(cuò)誤的征兆在輸出實(shí)測(cè)結(jié)果時(shí)已經(jīng)明顯的出現(xiàn)了，但是如果不仔細(xì)地全面地檢查測(cè)試結(jié)果，就會(huì)使這些錯(cuò)誤被遺漏掉。所以必須對(duì)預(yù)期的輸出結(jié)果明確定義，對(duì)實(shí)測(cè)的結(jié)果仔細(xì)分析檢查，抓住征兆，暴露錯(cuò)誤。 8．妥善保存測(cè)試計(jì)劃、測(cè)試用例、出錯(cuò)統(tǒng)計(jì)和最終分析報(bào)告，為維護(hù)提供方便。 黑盒測(cè)試和白盒測(cè)試 任何工程產(chǎn)品（注意是任何工程產(chǎn)品）都可以使用以下兩種方法之一進(jìn)行測(cè)試。 ? 黑盒測(cè)試： 已知產(chǎn)品的功能設(shè)計(jì)規(guī)格，可以進(jìn)行測(cè)試來(lái)證明每 個(gè)實(shí)現(xiàn)了的功能是否符合要求。 ? 白盒測(cè)試： 已知產(chǎn)品的內(nèi)部工作過(guò)程，可以通過(guò)測(cè)試來(lái)證明每種內(nèi)部操作是否符合設(shè)計(jì)規(guī)格要求，所有內(nèi)部成分是否已經(jīng)過(guò)檢查。 軟件的黑盒測(cè)試意味著測(cè)試要在軟件的接口處進(jìn)行。這種方法是把測(cè)試對(duì)象看做一個(gè)黑盒子，測(cè)試人員完全不考慮程序內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程序的需求規(guī)格說(shuō)明書(shū)，檢查程序的功能是否符合它的功能說(shuō)明。因此黑盒測(cè)試又叫功能測(cè)試或數(shù)據(jù)驅(qū)動(dòng)測(cè)試。 黑盒測(cè)試主要是為了發(fā)現(xiàn)以下幾類錯(cuò)誤： ? 是否有不正確或遺漏的功能？ ? 在接口上，輸入是否能正確的接受？能否輸出正確的結(jié)果？ ? 否有數(shù)據(jù) 結(jié)構(gòu)錯(cuò)誤或外部信息（例如數(shù)據(jù)文件）訪問(wèn)錯(cuò)誤？ ? 能上是否能夠滿足要求？ ? 否有初始化或終止性錯(cuò)誤？ 軟件的白盒測(cè)試是對(duì)軟件的過(guò)程性細(xì)節(jié)做細(xì)致的檢查。這種方法是把測(cè)試對(duì)象看做一個(gè)打開(kāi)的盒子，它允許測(cè)試人員利用程序內(nèi)部的邏輯結(jié)構(gòu)及有關(guān)信息，設(shè)計(jì)或選擇測(cè)試用例，對(duì)程序所有邏輯路徑進(jìn)行測(cè)試。通過(guò)在不同點(diǎn)檢查程序狀態(tài)，確定實(shí)際狀態(tài)是否與預(yù)期的狀態(tài)一致。因此白盒測(cè)試又稱為結(jié)構(gòu)測(cè)試或邏輯驅(qū)動(dòng)測(cè)試。 白盒測(cè)試主要是想對(duì)程序模塊進(jìn)行如下檢查： ? 對(duì)程序模塊的所有獨(dú)立的執(zhí)行路徑至少測(cè)試一遍。 ? 對(duì)所有的邏輯判定，取“真”與 取“假”的兩種情況都能至少測(cè)一遍。 ? 在循環(huán)的邊界和運(yùn)行的界限內(nèi)執(zhí)行循環(huán)體。 ? 測(cè)試內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性，等等。 以上事實(shí)說(shuō)明，軟件測(cè)試有一個(gè)致命的缺陷，即測(cè)試的不完全、不徹底性。由于任何程序只能進(jìn)行少量（相對(duì)于窮舉的巨大數(shù)量而言）的有限的測(cè)試，在未發(fā)現(xiàn)錯(cuò)誤時(shí)，不能說(shuō)明程序中沒(méi)有錯(cuò)誤。 軟件測(cè)試技術(shù)與質(zhì)量保證 13 軟件測(cè)試的步驟 測(cè)試過(guò)程必須分步驟進(jìn)行，每個(gè)步驟在邏輯上是前一個(gè)步驟的繼續(xù)。大型軟件系統(tǒng)通常由若干個(gè)子系統(tǒng)組成，每個(gè)子系統(tǒng)又由許多模塊組成。因此，大型軟件系統(tǒng)的測(cè)試基本上由下述 4個(gè)步驟組成：?jiǎn)卧獪y(cè)試、集成測(cè)試、 確認(rèn)測(cè)試和系統(tǒng)測(cè)試。 單元測(cè)試 單元測(cè)試又稱模塊測(cè)試，是測(cè)試過(guò)程的第一步，也是整個(gè)測(cè)試的基礎(chǔ)。據(jù)統(tǒng)計(jì)，單元測(cè)試發(fā)現(xiàn)的錯(cuò)誤，約占程序總錯(cuò)誤數(shù)的 65%。 對(duì)整個(gè)程序的測(cè)試從單元測(cè)試開(kāi)始，至少有以下好處：減少測(cè)試的復(fù)雜性；易于確定錯(cuò)誤的位置（不超過(guò)一個(gè)模塊）；多個(gè)單元可以并行測(cè)試，縮短測(cè)試周期。 1．目的與任務(wù) 目的：通過(guò)對(duì)象模塊的靜態(tài)分析與動(dòng)態(tài)測(cè)試，使其代碼達(dá)到模塊說(shuō)明書(shū)的需求。 任務(wù)： ? 模塊代碼進(jìn)行編譯，發(fā)現(xiàn)并糾正其語(yǔ)法錯(cuò)誤； ? 行靜態(tài)分析，驗(yàn)證模塊結(jié)構(gòu)及其內(nèi)部調(diào)用序列是否正確； ? 確 定模塊的測(cè)試策略，并據(jù)此設(shè)計(jì)一組測(cè)試用例和必要的測(cè)試軟件； ? 用選定的測(cè)試用例對(duì)模塊進(jìn)行測(cè)試，直到滿足測(cè)試終止標(biāo)準(zhǔn)為止； ? 靜態(tài)分析與動(dòng)態(tài)測(cè)試的重點(diǎn)，均應(yīng)放在模塊內(nèi)部的重要執(zhí)行路徑、出錯(cuò)處理路徑和局部數(shù)據(jù)結(jié)構(gòu)，也要重視模塊的對(duì)外接口。 ? 編制單元測(cè)試報(bào)告。 2．實(shí)施步驟 按照上述單元測(cè)試的任務(wù)，單元測(cè)試的實(shí)施步驟可以簡(jiǎn)述為： 編譯 〉靜態(tài)分析器檢查 〉代碼評(píng)審 〉動(dòng)態(tài)測(cè)試 從測(cè)試的角度來(lái)說(shuō)，編譯或其他語(yǔ)言翻譯程序也是一種靜態(tài)分析工具，其檢查對(duì)象是代碼中的語(yǔ)法錯(cuò)誤。接下來(lái)的兩步仍 然是靜態(tài)分析，不過(guò)檢查對(duì)象已從語(yǔ)法錯(cuò)誤改變?yōu)橐越Y(jié)構(gòu)性錯(cuò)誤為主的其他錯(cuò)誤。而且，第二步是使用專用工具（靜態(tài)分析器）來(lái)進(jìn)行分析的，第三步則主要依靠人工。從本質(zhì)上講，前三步都屬于代碼的靜態(tài)分析，即不依靠執(zhí)行被測(cè)程序來(lái)發(fā)現(xiàn)代碼中的錯(cuò)誤。 在大型程序的測(cè)試中，使用靜態(tài)分析器可以節(jié)省許多人力。 20世紀(jì) 70年代以來(lái)，已有許多靜態(tài)分析器投入使用，并獲得成功。但直到現(xiàn)在，代碼評(píng)審仍然以人工方式為主，并未被分析器取代。這是因?yàn)槎鄶?shù)分析工具只有有限的功能，且依賴于特定的語(yǔ)言（即一種工具僅適用于一種語(yǔ)言編寫(xiě)的程序），不易普遍推廣。 動(dòng)態(tài)測(cè)試是單元測(cè)試的最后步驟，重點(diǎn)是發(fā)現(xiàn)單元的功能性錯(cuò)誤。根據(jù)程序的實(shí)際情況，可采用白盒測(cè)試或黑盒測(cè)試方法。 單元測(cè)試一般安排在編碼階段完成。實(shí)施單元測(cè)試的人員可以有兩種選擇：一是由編碼者負(fù)責(zé)實(shí)施，其優(yōu)點(diǎn)是，他對(duì)單元的結(jié)構(gòu)與功能最熟悉，容易設(shè)計(jì)出符合軟件測(cè)試技術(shù)與質(zhì)量保證 14 需要的測(cè)試用例；二是由單元的設(shè)計(jì)者而不是編碼者（如果不是同一人）來(lái)設(shè)計(jì)測(cè)試用例，他同樣對(duì)單元比較熟悉，又可以避開(kāi)編碼者怕揭露自已程序弊病的心理。在選擇后一種做法時(shí)，應(yīng)提倡編碼者在單元提交正式測(cè)試前先做一次非正式的私下測(cè)試。 3．代碼評(píng)審 如前所述，代碼評(píng)審在編 譯之后，動(dòng)態(tài)測(cè)試以前進(jìn)行。如果有靜態(tài)分析工具，則應(yīng)在工具分析之后進(jìn)行。 評(píng)審的目的，在于發(fā)現(xiàn)程序在結(jié)構(gòu)、功能與編碼風(fēng)格方面存在的問(wèn)題和錯(cuò)誤。組織良好的代碼評(píng)審，可發(fā)現(xiàn) 30% ~ 70%的設(shè)計(jì)和編碼錯(cuò)誤，從而加快單元測(cè)試的進(jìn)程，提高測(cè)試的質(zhì)量。眾所周知，動(dòng)態(tài)測(cè)試僅能發(fā)現(xiàn)錯(cuò)誤的癥狀，而代碼評(píng)審一旦發(fā)現(xiàn)錯(cuò)誤，就同時(shí)確定了錯(cuò)誤的位置。所以，許多學(xué)者和公司都把代碼評(píng)審看作測(cè)試中不可缺少的環(huán)節(jié)，認(rèn)為是動(dòng)態(tài)測(cè)試以前的必要準(zhǔn)備。 評(píng)審有兩類組織形式。一類叫辦公桌檢查（ Desk Check），由編程者自已審查自已的代碼，僅 適用于規(guī)模很小的程序。另一類以小組會(huì)的方式進(jìn)行，又可分“走查（ Walk Through）”和“代碼會(huì)審（ Code Inspection）”兩種，適用于各種規(guī)模的程序，具體作法不再贅述，有興趣者可參看有關(guān)書(shū)籍。 4．測(cè)試軟件 單元不是獨(dú)立的程序。在多模塊程序中，每一模塊都可能調(diào)用其他模塊或者被其他模塊所調(diào)用。所以在單元測(cè)試時(shí)，需要為被測(cè)模塊編制若干測(cè)試軟件，給它的上級(jí)模塊或下級(jí)模塊作替身。代替上級(jí)模塊的稱為測(cè)試驅(qū)動(dòng)模塊（ Test Driver），代替下級(jí)模塊的稱為測(cè)試樁模塊（ Test Stub）。 需要指出， 替身模塊應(yīng)該是真實(shí)模塊的簡(jiǎn)化，僅需模擬與被測(cè)模塊直接相關(guān)的一部分功能。它們?cè)谌繙y(cè)試過(guò)程結(jié)束后即完成了歷史使命，一般不移交給用戶。 集成測(cè)試 通過(guò)了單元測(cè)試的模塊，要按照一定的策略組裝為完整的程序。在組裝過(guò)程中進(jìn)行的測(cè)試，就稱為集成測(cè)試或組裝測(cè)試。 為什么所有的模塊都經(jīng)過(guò)了單元測(cè)試，組裝中還會(huì)出現(xiàn)問(wèn)題呢？這是因?yàn)椋? ? 單元測(cè)試中使用了測(cè)試軟件。它們是真實(shí)模塊的簡(jiǎn)化，與它們所代替的模塊并不完全等效。因此，單元測(cè)試本身可能有不充分的地方，存在缺陷。 ? 多模塊程序中各模塊之間，可能有比較復(fù)雜的接 口，稍有疏忽就易出錯(cuò)。例如有的數(shù)據(jù)在穿過(guò)接口時(shí)會(huì)不慎丟失，有些全局性數(shù)據(jù)在引用中可能出問(wèn)題等。 ? 有些在單個(gè)模塊中可以允許的誤差，組裝后的積累誤差可能達(dá)到不能容忍的地步；或者模塊的分功能似乎正常，組裝后也可能產(chǎn)生了預(yù)期的綜合功能。由此可見(jiàn)， 在軟件的測(cè)試過(guò)程中，集成測(cè)試不僅必要，而且占有重要的地位。 軟件測(cè)試技術(shù)與質(zhì)量保證 15 1．目的與任務(wù) 目的： 將經(jīng)過(guò)單元測(cè)試的模塊逐步組裝成具有良好一致性的完整程序。 任務(wù)： ? 制定集成測(cè)試實(shí)施策略。根據(jù)程序的結(jié)構(gòu)，可以選擇自頂向下或由底向上或二者混合的兩頭逼近策略。 ? 制定集成測(cè)試實(shí)施 步驟，設(shè)計(jì)測(cè)試用例。二者的選擇，應(yīng)有利于揭露在接口關(guān)系、訪問(wèn)全局性數(shù)據(jù)（包括公用文件與數(shù)據(jù)結(jié)構(gòu)）、模塊調(diào)用序列和出錯(cuò)處理等方面存在的隱患。 ? 進(jìn)行測(cè)試，即在已通過(guò)單元測(cè)試的基礎(chǔ)上，逐一地添加模塊。每并入一個(gè)模塊，除進(jìn)行新的測(cè)試項(xiàng)目外，還需重復(fù)進(jìn)行先前已進(jìn)行過(guò)的測(cè)試，后者也稱為“回歸測(cè)試”。回歸測(cè)試可用于防止因軟件組裝改變而導(dǎo)致新的不協(xié)調(diào)，出現(xiàn)不可預(yù)料的錯(cuò)誤。它通常是已經(jīng)進(jìn)行過(guò)的測(cè)試的一個(gè)子集。當(dāng)在軟件維護(hù)中修改了某些模塊后，也需要進(jìn)行回歸測(cè)試。 2．策略與步驟 集成測(cè)試的策略，可以分為自頂向下、由底向上和 從兩頭逼近的混合方式等 3 種。現(xiàn)在以圖 的多模塊程序?yàn)槔?，分別說(shuō)明如下： ? 自頂向下測(cè)試 從頂模塊開(kāi)始，沿被測(cè)程序的結(jié)構(gòu)圖逐步向下測(cè)試。按照移動(dòng)路線的差異，又可區(qū)分兩種不同的實(shí)施步驟。 ① 先廣后深實(shí)施步驟。這時(shí)模塊的組裝順序是： M1 – M2 – M3 – M4 – M5 – M6 – M7 – M8 ② 先深后廣實(shí)施步驟。組裝順序?yàn)椋? M1 – M2 – M5 – M8 – M6 – M3 – M4 – M7 圖 一個(gè)簡(jiǎn)單的多模塊程序 自頂向下測(cè)試要使用樁模塊 。圖 配置情況。圖中的樁模塊，都是下標(biāo)相同的真實(shí)模塊的替身（例如， S1是 M2的替身， S3是 M3的替身，依此類推）。 ? 由底向上測(cè)試 它與自頂向下一樣，每次也只增添一個(gè)新模塊。但組裝順序恰好相反，采用由下向上的路線。其典型步驟可以描述為： ① 從下層模塊中找出一個(gè)沒(méi)有下級(jí)模塊的模塊，由下向上地逐步添加新模塊，組成程序中的一個(gè)子系統(tǒng)或模塊群； ② 從另一子系統(tǒng)或群中選出另一個(gè)無(wú)下級(jí)模塊的模塊，仿照前一步組成又一 M2 M3 M4 M5 M6 M8 M7 M1 軟件測(cè)試技術(shù)與質(zhì)量保證 16 個(gè)子系統(tǒng)； ③ 重復(fù)上一步，直到得出所有的子系統(tǒng)，把它們組裝 為完整的程序。 仍以圖 ，按以上的步驟，其模塊組裝順序可能是： M8 M5 M6 M2 ； M7 M4 M3 M1 ； 全部模塊（即合并以上兩個(gè)群）。 ? 混合方式測(cè)試 它是上述兩種測(cè)試方式的結(jié)合，其具體步驟為： ? 對(duì)上層模塊采取自頂向下測(cè)試； ? 對(duì)關(guān)鍵模塊或子系統(tǒng)采取由底向上測(cè)試。 這種從兩頭向中間逼近的方法，可以兼有自頂向下和由底向上策略的優(yōu)點(diǎn)，所以應(yīng)用較廣。 為了保證測(cè)試的質(zhì)量，集成測(cè)試應(yīng)由獨(dú)立于開(kāi)發(fā)人員的測(cè)試小組負(fù)責(zé)實(shí)施。 (a)測(cè)試 M1 (b)測(cè)試 M1 與 M2 (c)測(cè)試 M M2 與 M3 圖 先深度后廣度的測(cè)試 M1 S1 S3 S4 M1 M2 S3 S4 S5 S6 M1 M2 S8 S3 M5 S6 S4 軟件測(cè)試技術(shù)與質(zhì)量保證 17 3．幾種策略的比較 由頂向下測(cè)試的優(yōu)點(diǎn)是 ,能較早顯示整個(gè)程序的輪廓，向用戶展示程序的概貌，取得用戶的理解和支持。主要缺點(diǎn)是，當(dāng)測(cè)試上層模塊時(shí)因使用樁模塊較多，很難模擬出真實(shí)模塊的全部功能，使部分測(cè)試內(nèi)容被迫推遲，只能等換上真實(shí)模塊后再補(bǔ)充測(cè)試。在低層次上的替身模塊較多，也會(huì)增加設(shè)計(jì)測(cè)試用例的難度。由底向上測(cè)試從下層模塊開(kāi)始，設(shè)計(jì)測(cè)試用 例比較容易，但是在測(cè)試的早期不能顯示出程序的輪廓?；旌蠝y(cè)試的優(yōu)點(diǎn)，正在于揚(yáng)長(zhǎng)避短，綜合了以上兩種策略的長(zhǎng)處。例如，對(duì)關(guān)鍵模塊采取由底向上測(cè)試，就可能把輸入輸出模塊提前組裝進(jìn)程序，以便及早暴露可能存在的問(wèn)題。除關(guān)鍵模塊及少數(shù)與之相關(guān)的模塊外，對(duì)其余模塊尤其是上層模塊仍采取自頂向下的測(cè)試方法，以便盡早地顯示程序的總體輪廓。 確認(rèn)測(cè)試 1．有效性測(cè)試（黑盒測(cè)試）和配置復(fù)審 確認(rèn)測(cè)試?yán)^集成測(cè)試之后進(jìn)行，其目的在于確認(rèn)組裝完畢的程序是否滿足軟件需求規(guī)格說(shuō)明書(shū)（ SRS）的要求。典型的確認(rèn)測(cè)試通常包括有效性 測(cè)試（黑盒測(cè)試）和配置復(fù)審等內(nèi)容。在 SRS中一般都有標(biāo)題為“有效性標(biāo)準(zhǔn)”得一節(jié)，其中的內(nèi)容就是確認(rèn)測(cè)試的依據(jù)。配置復(fù)審則用于查明程序的文檔是否配齊，以及文檔內(nèi)容的一致性。 確認(rèn)測(cè)試是由軟件開(kāi)發(fā)單位組織實(shí)施的最后一項(xiàng)開(kāi)發(fā)活動(dòng)。測(cè)試結(jié)束后，軟件就要交付驗(yàn)收了。因此，開(kāi)發(fā)單位必須十分重視作好這項(xiàng)工作。同集成測(cè)試一樣，確認(rèn)測(cè)試也應(yīng)由獨(dú)立的測(cè)試小組負(fù)責(zé)實(shí)施。 2．驗(yàn)收測(cè)試 如果軟件是給一個(gè)客戶開(kāi)發(fā)的，需要進(jìn)行一系列的驗(yàn)收測(cè)試來(lái)保證滿足客戶所有的需求。驗(yàn)收測(cè)試主要由用戶而不是開(kāi)發(fā)者來(lái)進(jìn)行，可以進(jìn)行幾個(gè)星期或者幾個(gè)月 ，因而可發(fā)現(xiàn)隨時(shí)間的積累而產(chǎn)生的錯(cuò)誤。 3． Alpha與 Beta測(cè)試 如果一個(gè)軟件是給很多客戶使用的（例如 Office軟件），讓每一個(gè)用戶都進(jìn)行正式的驗(yàn)收測(cè)試顯然是不切實(shí)際的。這時(shí)可使用 Alpha測(cè)試與 Beta 測(cè)試，來(lái)發(fā)現(xiàn)那些通常只有最終用戶才能發(fā)現(xiàn)的錯(cuò)誤。 Alpha測(cè)試是在一個(gè)受控的環(huán)境下，由用戶在開(kāi)發(fā)者的“指導(dǎo)”下進(jìn)行的測(cè)試，由開(kāi)發(fā)者負(fù)責(zé)紀(jì)錄錯(cuò)誤和使用中出現(xiàn)的問(wèn)題。 Beta 測(cè)試則不同于 Alpha 測(cè)試，是由最終用戶在自己的場(chǎng)所進(jìn)行的，開(kāi)發(fā)者通常不會(huì)在場(chǎng)，也不能控制應(yīng)用的環(huán)境。所有在 Beta 測(cè)試中 遇到的（真正的或是想象中）問(wèn)題均由用戶紀(jì)錄，并定期把它們報(bào)告給開(kāi)發(fā)者，開(kāi)發(fā)者在接收到 Beta測(cè)試的問(wèn)題報(bào)告之后，對(duì)系統(tǒng)進(jìn)行最后的修改，然后就開(kāi)始準(zhǔn)備向所有的用戶發(fā)布最終的軟件產(chǎn)品。 軟件測(cè)試技術(shù)與質(zhì)量保證 18 系統(tǒng)測(cè)試 系統(tǒng)測(cè)試是在更大范圍內(nèi)進(jìn)行的測(cè)試。除被測(cè)程序外，系統(tǒng)還可能包括硬件和原來(lái)就有的其它軟件。測(cè)試的目的是檢查把確認(rèn)測(cè)試合格的軟件安裝到系統(tǒng)中以后，能否與系統(tǒng)的其余部分協(xié)調(diào)運(yùn)行，并且完成 SRS對(duì)它的要求。 系統(tǒng)測(cè)試試驗(yàn)收工作的一部分，應(yīng)由用戶單位組織實(shí)施。軟件開(kāi)發(fā)單位應(yīng)該為系統(tǒng)測(cè)試創(chuàng)造良好的條件，負(fù)責(zé)回答和解 決測(cè)試中可能發(fā)現(xiàn)的一切質(zhì)量問(wèn)題。 終止測(cè)試的標(biāo)準(zhǔn) 黑盒測(cè)試和白盒測(cè)試都是選擇測(cè)試，不可能徹底發(fā)現(xiàn)程序的所有錯(cuò)誤。既然如此，測(cè)試該進(jìn)行到什么程度才算完成任務(wù)呢？顯然，測(cè)試過(guò)少，程序的遺留錯(cuò)誤較多，將降低其可靠性；但過(guò)量的測(cè)試，也會(huì)不必要地增大軟件成本。在這一小節(jié)，將介紹兩種實(shí)用的測(cè)試終止標(biāo)準(zhǔn)及其作法。 1．規(guī)定測(cè)試策略和應(yīng)達(dá)目標(biāo) 白盒測(cè)試時(shí)一般可規(guī)定以完成覆蓋為標(biāo)準(zhǔn)，即語(yǔ)句覆蓋率和分支覆蓋率必須分別達(dá)到 100%。滿足了這些條件就可終止測(cè)試。 黑盒測(cè)試時(shí)可結(jié)合程序的實(shí)際情況選擇一種或數(shù)種方法（ 例如，邊界值法或等價(jià)分類法）來(lái)設(shè)計(jì)測(cè)試用例。當(dāng)把所有測(cè)試用例全部用完后測(cè)試便可終止。 2．規(guī)定至少要查出的錯(cuò)誤數(shù)量 如果已經(jīng)積累了較豐富的測(cè)試經(jīng)驗(yàn)，可以把查出預(yù)定數(shù)量的錯(cuò)誤，作為某類應(yīng)用程序的測(cè)試終止標(biāo)準(zhǔn)。例如，假定被測(cè)程序是一個(gè)約有 10000行的管理信息系統(tǒng)，根據(jù)以往的經(jīng)驗(yàn)，這么多行的程序約有 300個(gè)設(shè)計(jì)錯(cuò)誤和 200個(gè)代碼與結(jié)構(gòu)錯(cuò)誤。若預(yù)定的目標(biāo)是查出 95%的設(shè)計(jì)錯(cuò)誤和 98%的編碼與結(jié)構(gòu)錯(cuò)誤，則可以規(guī)定，查出285個(gè)設(shè)計(jì)錯(cuò)誤和 196個(gè)編碼與結(jié)構(gòu)錯(cuò)誤后就可終止測(cè)試。 測(cè)試用例設(shè)計(jì) 黑盒 測(cè)試用例設(shè)計(jì) 黑盒測(cè)試就是根據(jù)被測(cè)程序的功能來(lái)進(jìn)行測(cè)試，所以也稱為功能測(cè)試。用黑盒設(shè)計(jì)測(cè)試用例，有 4種常用技術(shù)，本節(jié)僅介紹其中的 3種。 1．等價(jià)分類法 所謂等價(jià)分類，就是把輸入數(shù)據(jù)的可能值劃分為若干等價(jià)類，使每類中的任何一個(gè)測(cè)試用例，都能代表同一等價(jià)類中的其他測(cè)試用例。換句話說(shuō)，如果從某一等價(jià)類中任意選出一個(gè)測(cè)試用例未能發(fā)現(xiàn)程序的錯(cuò)誤，就可以合理地認(rèn)為在該類中的其他測(cè)試用例也不會(huì)發(fā)現(xiàn)程序的錯(cuò)誤。這樣，就把漫無(wú)邊際的隨機(jī)測(cè)試變成有針對(duì)軟件測(cè)試技術(shù)與質(zhì)量保證 19 性的等價(jià)類測(cè)試，有可能用少量有代表性的例子來(lái)代替大量?jī)?nèi)容相似的測(cè)試，借以實(shí) 現(xiàn)測(cè)試的經(jīng)濟(jì)性。 采用這一技術(shù)要注意以下兩點(diǎn)： ? 劃分等價(jià)類不僅要考慮代表“有效”輸入值得有效等價(jià)類，還須考慮代表“無(wú)效”輸入值得無(wú)效等價(jià)類； ? 每一個(gè)無(wú)效等價(jià)類至少要用一個(gè)測(cè)試用例，不然就可能漏掉某一類錯(cuò)誤，但允許若干有效等價(jià)類合用同一個(gè)測(cè)試用例，以便進(jìn)一步減少測(cè)試的次數(shù)。 2．邊界值分析法 實(shí)踐表明，程序員在處理邊界情況時(shí)，很容易因疏忽或考慮不周發(fā)生編碼錯(cuò)誤。例如，在數(shù)組容量、循環(huán)次數(shù)以及輸入數(shù)據(jù)與輸出數(shù)據(jù)的邊界值附近程序出錯(cuò)的概率往往較大。采用邊界值分析法，就是要這樣來(lái)選擇測(cè)試用例，使得被測(cè)程序 能在邊界值及其附近運(yùn)行，從而更有效地暴露程序中潛藏的錯(cuò)誤。 所謂邊界值分析，就是要把測(cè)試的重點(diǎn)放在各個(gè)等價(jià)類的邊界上，選取剛好等