第13章軟件工程與開發(fā)方法軟件工程和硬件工程都可以看成是計算機系統(tǒng)工程的一部分。用于計算機硬件的工程技術(shù)是由電子設(shè)計技術(shù)發(fā)展起來的，而且在幾十年的時間里已經(jīng)達到了比較成熟的水平，雖然制造方法仍在不斷地改進，但硬件的可靠性已經(jīng)是一種可以期待的現(xiàn)實而不再是一種愿望了。但是，軟件工程還處于某種困境之中。在以計算機為基礎(chǔ)的系統(tǒng)中，軟件已經(jīng)取代硬件，成為系統(tǒng)中設(shè)計最困難、最不容易成功（即不能按時完成和容易超出預(yù)計的開發(fā)成本，且最不易管理）的部分。另一方面，隨著以計算機為基礎(chǔ)的系統(tǒng)在數(shù)量、復(fù)雜程度和應(yīng)用范圍上的不斷增長，對軟件的需求卻有增無減。軟件工程就是建立在這樣的基礎(chǔ)之上。13.1軟件生存周期及其模型軟件生存周期是軟件工程中的一個基礎(chǔ)概念。國家標(biāo)準(zhǔn)《軟件工程術(shù)語》（GB/T11457）定義了軟件生存周期，即：從設(shè)計軟件產(chǎn)品開始到產(chǎn)品不能再使用時為止的時間周期。亦即：一個計算機軟件，從出現(xiàn)一個構(gòu)思之日起，經(jīng)過開發(fā)成功投入使用，在使用中不斷增補修訂，直到最后決定停止使用，并被另一項軟件代替之時止，被認(rèn)為是該軟件的一個生存周期（或稱生命周期、生存期，lifecycle）。13.1.1軟件生存周期一個軟件產(chǎn)品的生存周期可以劃分成若干個互相區(qū)別而又有聯(lián)系的階段，每個階段中的工作均以上一階段工作的結(jié)果為依據(jù)，并為下一階段的工作提供了前提。經(jīng)驗表明，失誤造成的差錯越是發(fā)生在生存周期的前期，在系統(tǒng)交付使用時造成的影響和損失就越大，要糾正它所花費的代價也越高。因而在前一階段工作沒有做好之前，決不要草率地進入下一階段。13.1.1軟件生存周期國家標(biāo)準(zhǔn)《計算機軟件開發(fā)規(guī)范》（GB/T8566）將軟件生存周期劃分為以下八個階段，即：可行性研究與計劃、需求分析、概要設(shè)計（即結(jié)構(gòu)設(shè)計）、詳細設(shè)計、實現(xiàn)（包括單元測試）、組裝測試（即集成測試）、確認(rèn)測試、使用和維護。軟件生存周期是對軟件的一種長遠發(fā)展的看法，這種看法把軟件開發(fā)之前和軟件交付使用之后的一些活動都包括在軟件生存周期之內(nèi)。應(yīng)當(dāng)注意的是，軟件系統(tǒng)的實際開發(fā)工作不可能直線地通過分析、設(shè)計、編程和測試等階段，出現(xiàn)各階段間的回復(fù)是不可避免的。軟件生存周期的每個階段都要產(chǎn)生一定規(guī)格的軟件文件（文檔）移交給下一階段，使下一階段在此基礎(chǔ)上繼續(xù)開展工作。13.1.2軟件生存周期過程《軟件生存周期過程》（GB/T8566）根據(jù)軟件工程的實踐和軟件工程學(xué)科的發(fā)展，進一步完善了軟件生存周期的定義，即：從概念形成直到退役，并且由獲取和供應(yīng)軟件產(chǎn)品及服務(wù)的各個過程組成。該標(biāo)準(zhǔn)把軟件生存周期中開展的活動分為五個基本過程（獲取過程、供應(yīng)過程、開發(fā)過程、運作過程、維護過程）、八個支持過程（文檔編制過程、配置管理過程、質(zhì)量保證過程、驗證過程、確認(rèn)過程、聯(lián)合評審過程、審核過程、問題解決過程）和4個組織過程（管理過程、基礎(chǔ)設(shè)施過程、改進過程、培訓(xùn)過程）。13.1.2軟件生存周期過程軟件生存周期過程中階段的劃分，有助于軟件研制管理人員借用傳統(tǒng)工程的管理方法（重視工程性文件的編制，采用專業(yè)化分工方法，在不同階段使用不同的人員等），從而有利于明顯提高軟件質(zhì)量、降低成本、合理使用人才、進而提高軟件開發(fā)的勞動生產(chǎn)率。13.1.3軟件生存周期模型軟件生存周期模型（又稱軟件開發(fā)模型）是軟件工程的一個重要概念，它可以定義為：一個框架，它含有遍歷系統(tǒng)從確定需求到終止使用這一生存周期的軟件產(chǎn)品的開發(fā)、運行和維護中需實施的過程、活動和任務(wù)。軟件生存周期模型能清晰、直觀地表達軟件開發(fā)全過程，明確規(guī)定了開發(fā)工作各階段所要完成的主要活動和任務(wù)，以作為軟件項目開發(fā)工作的基礎(chǔ)。對于不同的軟件系統(tǒng)，可以采用不同的開發(fā)方法、使用不同的程序設(shè)計語言以及各種不同技能的人員參與工作、運用不同的管理方法和手段等，以及允許采用不同的軟件工具和不同的軟件工程環(huán)境。軟件生存周期模型是穩(wěn)定有效和普遍適用的。13.1.3軟件生存周期模型在軟件生存周期過程中，軟件生存周期模型僅對軟件的開發(fā)、運作和維護過程有意義，在ISO12207和ISO9000-3中都提到軟件生存周期模型，它包括：瀑布模型、漸增模型、演化模型、螺旋模型、噴泉模型和智能模型等。例如：瀑布模型是1970年W.Royce提出的最早的軟件開發(fā)模型，它將軟件開發(fā)過程中的各項活動規(guī)定為依固定順序連接的若干階段工作，形如瀑布流水，如圖13-1所示，最終得到軟件系統(tǒng)或軟件產(chǎn)品。換句話說，它將軟件開發(fā)過程劃分成若干個互相區(qū)別而又彼此聯(lián)系的階段，每個階段中的工作都以上一個階段工作的結(jié)果為依據(jù)，同時為下一個階段的工作提供了前提。13.1.3軟件生存周期模型圖13-1軟件生存周期的瀑布模型13.2軟件工程定義發(fā)展至今，軟件工程已經(jīng)是一門交叉性學(xué)科，它是解決軟件問題的工程，對它的理解不應(yīng)是靜止的和孤立的。軟件工程是應(yīng)用計算機科學(xué)、數(shù)學(xué)及管理科學(xué)等原理，借鑒傳統(tǒng)工程的原則、方法來創(chuàng)建軟件，從而達到提高質(zhì)量、降低成本的目的。其中，計算機科學(xué)和數(shù)學(xué)用于構(gòu)造模型、分析算法，工程科學(xué)用于制定規(guī)范、明確風(fēng)格、評估成本、確定權(quán)衡，管理科學(xué)用于進度、資源、質(zhì)量、成本等的管理。軟件工程的目標(biāo)是明確的，就是研制開發(fā)與生產(chǎn)出具有良好質(zhì)量和費用合算的軟件產(chǎn)品。費用合算是指軟件開發(fā)運行的整個開銷能滿足用戶的要求，軟件質(zhì)量是指該軟件能滿足明確的和隱含的需求能力的有關(guān)特征和特性的總和。13.2軟件工程定義軟件工程的基礎(chǔ)是一些指導(dǎo)性的原則，例如以下幾點。必須認(rèn)識軟件需求的變動性，并采取適當(dāng)措施來保證結(jié)果產(chǎn)品能忠實地滿足用戶要求。軟件設(shè)計中，通常要考慮模塊化、抽象與信息隱蔽、局部化、一致性等原則。穩(wěn)妥的設(shè)計方法大大地方便軟件開發(fā)，為達到軟件工程的目標(biāo)，軟件工具與環(huán)境對軟件設(shè)計的支持來說，頗為重要。軟件工程項目的質(zhì)量與經(jīng)濟開銷直接取決于對它所提供的支撐的質(zhì)量與效用。有效的軟件工程只有在對軟件過程進行有效管理的情況下才能實現(xiàn)。13.3軟件開發(fā)過程在軟件生存周期中，開發(fā)階段可以概括為四個階段，即分析、設(shè)計、實現(xiàn)和測試。13.3.1分析階段整個開發(fā)過程始于分析階段（包括可行性研究與計劃、需求分析）。在這個階段，系統(tǒng)分析員定義需求，指出系統(tǒng)所要實現(xiàn)的目標(biāo)。這些需求通常用用戶能理解的術(shù)語來表述。在分析階段有四個步驟：1）定義用戶。軟件可以為一般用戶或特殊用戶而設(shè)計，必須很清楚地劃分軟件的使用者。2）定義要求。確定用戶以后，系統(tǒng)分析員開始定義要求。在這個階段，最好的答案來自于用戶，用戶或用戶代表清楚地定義了他們對軟件的期望。13.3.1分析階段3）定義需求。在用戶要求的基礎(chǔ)上，系統(tǒng)分析員能夠準(zhǔn)確地定義系統(tǒng)的需求。例如：假設(shè)一個軟件在月底給每個雇員打印賬單，則需要說明實現(xiàn)怎樣的安全和精度的等級。4）定義方法。在清晰定義好需求之后，系統(tǒng)分析員應(yīng)選擇適當(dāng)?shù)姆椒▉頋M足這些需求。13.3.2設(shè)計階段設(shè)計階段定義系統(tǒng)怎樣完成在分析階段所定義的需求。在設(shè)計階段，將確定系統(tǒng)，完成文件和（或）數(shù)據(jù)庫的設(shè)計。1）模塊化。設(shè)計階段遵循模塊化原則。整個程序包劃分成許多小的模塊。每個模塊經(jīng)過設(shè)計、測試并通過主程序與其他模塊進行鏈接。2）工具。在設(shè)計階段使用許多工具，其中最常用是模塊結(jié)構(gòu)圖（SC）。模塊結(jié)構(gòu)圖顯示了如何將軟件包分解成邏輯步驟，每個步驟就是一個獨立的模塊。模塊結(jié)構(gòu)圖也顯示了各部分（模塊）之間的相互作用。13.3.3實現(xiàn)階段在實現(xiàn)階段，完成實際程序代碼的編寫。1）工具。在這個階段，在實際代碼編寫之前使用了許多工具來顯示程序的邏輯流程。程序流程圖（框圖）是流行的主要工具之一。程序流程圖使用標(biāo)準(zhǔn)的圖形符號來表示貫穿模塊的數(shù)據(jù)邏輯流程。第二個被程序員使用的工具是偽代碼。偽代碼部分是英文，部分是用精確的算法細節(jié)來描述程序?qū)⑼瓿墒裁吹某绦蜻壿嫛６@需要用足夠的細節(jié)定義步驟，以便能夠容易地轉(zhuǎn)換成計算機程序。2）編碼。在完成程序流程圖、偽代碼、或兩者都完成之后，程序員真正開始用指定的程序設(shè)計語言編寫代碼。13.3.4測試階段一旦程序設(shè)計完成，必須進行測試。測試階段是在程序開發(fā)中非常單調(diào)且很花費時間的部分。程序員負責(zé)測試他們編寫的程序（單元測試）。在大型開發(fā)項目中，通常有專家擔(dān)任測試工程師，負責(zé)測試整個系統(tǒng)（組裝測試），這種測試將確保所有的程序都能在一起工作。13.3.4測試階段測試的主要類型有兩種：黑盒測試和白盒測試。1）黑盒測試。即在不知道程序內(nèi)部構(gòu)造也不知道程序是怎樣工作的情況下測試程序。換言之，程序就像看不見內(nèi)部的黑盒。簡單地說，黑盒測試計劃是從需求說明發(fā)展起來的。這就是為什么有一組好的需求如此重要的原因之一。測試工程師通過利用這些需求和他的系統(tǒng)開發(fā)知識以及用戶的工作環(huán)境來產(chǎn)生測試計劃。這個計劃主要用于系統(tǒng)的整體測試。編寫程序之前，應(yīng)當(dāng)查看和了解這些測試計劃。13.3.4測試階段2）白盒測試。與黑盒測試假設(shè)對程序代碼的一無所知相反，白盒測試假定你知道有關(guān)程序的一切。在這種情況下，程序就像玻璃房子，其中的一切都是可見的。白盒測試主要是程序員的責(zé)任，他們準(zhǔn)確地知道程序內(nèi)部發(fā)生了什么。必須確保每一條指令和每一種可能情況都已經(jīng)被測試過。這不是一個簡單的工作。經(jīng)驗將幫助程序員設(shè)計好的測試數(shù)據(jù)，但是，程序員從一開始就能做的事是養(yǎng)成撰寫測試計劃的習(xí)慣，還在設(shè)計階段時就應(yīng)該開始編制測試計劃。13.4模塊化模塊化意味著將大項目分解成較小的部分，以便能夠容易理解和處理。換言之，模塊化意味著將大程序分解成能互相通訊的小程序。有兩種工具可以用于在程序設(shè)計中實現(xiàn)模塊化，即模塊結(jié)構(gòu)圖（SC）或類圖。模塊結(jié)構(gòu)圖用于過程化編程以顯示過程或函數(shù)之間的關(guān)系；類圖用于面向?qū)ο缶幊桃燥@示類之間的關(guān)系，統(tǒng)一建模語言（UML）作為一個標(biāo)準(zhǔn)，包括了有助于這方面的工具和圖。13.4.1耦合耦合是對兩個模塊互相綁定緊密程度的度量。越緊耦合的模塊，它們的獨立性越差。耦合的類型主要有如下幾種。1）數(shù)據(jù)耦合。只從調(diào)用函數(shù)向被調(diào)用函數(shù)傳遞最少的需求數(shù)據(jù)。所有需求數(shù)據(jù)作為參數(shù)傳遞，沒有額外的數(shù)據(jù)傳遞。這是耦合的最佳形式，應(yīng)該盡可能地使用。2）控制耦合。傳遞的是標(biāo)記，它可用于指示函數(shù)的邏輯流程，它與數(shù)據(jù)耦合極為相似，不同之處僅在于前者傳遞的是標(biāo)記，后者傳遞的是數(shù)據(jù)。如果使用得當(dāng)，控制耦合是兩個函數(shù)之間通訊所必需的和有效的方法，它傳遞狀態(tài)，如到達文件尾部、找到查詢的值等。糟糕的標(biāo)記使用通常是糟糕的程序設(shè)計的一種標(biāo)志，比如一個處理過程在兩個或更多的獨立函數(shù)之間分開等。13.4.1耦合3）公共耦合。又稱全局耦合，是用全局變量來進行兩個或更多函數(shù)之間的通訊，這不是一個好的耦合技術(shù)。實際上，應(yīng)該避免使用它。例如，全局耦合實際上不可能決定哪些模塊正在互相通訊。當(dāng)一個程序需要改動時，它無法評估和隔離這種變化造成的影響。這常常導(dǎo)致沒改動的函數(shù)突然失效。其次，全局耦合緊密地把函數(shù)綁定在程序上，這意味著它很難移植到另一個程序中。4）內(nèi)容耦合。是在一個函數(shù)直接引用另一個函數(shù)的數(shù)據(jù)或語句時產(chǎn)生的耦合。顯然，這種觀念打破了結(jié)構(gòu)化編程的宗旨，引用另一個函數(shù)的數(shù)據(jù)要求該數(shù)據(jù)在函數(shù)的外部可見。13.4.2內(nèi)聚模塊化的另一個問題是內(nèi)聚，內(nèi)聚是程序中處理過程相關(guān)緊密程度的度量。內(nèi)聚的級別有多種。1）功能內(nèi)聚。帶有功能內(nèi)聚的模塊僅僅包含一個處理過程，這是最高級別的內(nèi)聚，并且這是應(yīng)該盡力實現(xiàn)的級別。只做一件事：每個函數(shù)應(yīng)該只做一件事，而且函數(shù)中的所有語句應(yīng)該僅為這件事服務(wù)。在一個位置：一個函數(shù)應(yīng)該只在一個地方做一件事。如果一個處理過程的代碼散落在程序中多個不同的無關(guān)的部分，那么它將很難改動。所以，一個任務(wù)的所有處理過程應(yīng)該放在一個函數(shù)中，如果需要也可以放在其子函數(shù)中。13.4.2內(nèi)聚2）順序內(nèi)聚。帶有順序內(nèi)聚的模塊包含兩個或更多緊密聯(lián)系在一起的相關(guān)任務(wù)，通常一個流程的輸出作為另一個的輸入。3）通信內(nèi)聚。將使用同一數(shù)據(jù)的處理過程合并。在程序的較高級別模塊中使用通信內(nèi)聚是很自然的，但是基本的級別中將不會發(fā)現(xiàn)通信內(nèi)聚。例如，考慮一個讀入庫存文件的函數(shù)，它打印當(dāng)前零部件的狀態(tài)，接著檢查是否有需要訂購的零部件。前三個級別的內(nèi)聚被認(rèn)為是良好的結(jié)構(gòu)化編程原則。一旦逾越這個觀點，易于理解和實現(xiàn)、可維修性及準(zhǔn)確性就開始急劇滑落。下幾個級別的內(nèi)聚僅被用于結(jié)構(gòu)圖中的更高級別。13.4.2內(nèi)聚4）過程內(nèi)聚。合并由控制流程連接的不相關(guān)的處理過程（它不同于順序內(nèi)聚，順序內(nèi)聚是數(shù)據(jù)流從一個過程到另一個過程）。5）時間內(nèi)聚。僅僅在超過處理過程的限定范圍時才被接受。它合并了那些總是一起發(fā)生但并不相關(guān)的處理過程。兩個瞬時內(nèi)聚的函數(shù)是工作的初始化和結(jié)尾。因為它們在程序中僅僅使用一次且從來不可移植。但是，無論何時使用，它仍然應(yīng)該包含對功能內(nèi)聚的原始函數(shù)的調(diào)用。13.4.2內(nèi)聚6）邏輯內(nèi)聚和偶然內(nèi)聚。這在如今的程序中是少見的。邏輯內(nèi)聚合并了由控制它們的實體所關(guān)聯(lián)的處理過程。一個函數(shù)基于作為參數(shù)傳遞的標(biāo)記，有條件地打開不同的文件集，這可能就是邏輯內(nèi)聚。最后，偶然內(nèi)聚合并了無關(guān)的處理過程，一般僅在理論上存在。13.5軟件質(zhì)量軟件質(zhì)量是“軟件產(chǎn)品具有滿足規(guī)定或隱含要求的與能力要求有關(guān)的特性與特性總和”。軟件質(zhì)量的評估通常從對軟件質(zhì)量框架的分析開始。軟件質(zhì)量是計算機軟件的所有內(nèi)在屬性的組合，它歷來是軟件開發(fā)中的關(guān)鍵問題，也是軟件生產(chǎn)中的核心問題。并且，軟件質(zhì)量包括程序、數(shù)據(jù)和文件等多方面的質(zhì)量。隨著計算機日益廣泛地應(yīng)用于各行各業(yè)，軟件質(zhì)量將直接影響到計算機應(yīng)用的深度和廣度。因此，如何科學(xué)地對軟件進行評價、測試和鑒定，對促進軟件質(zhì)量的提高，加速軟件產(chǎn)業(yè)化、商品化進程具有重要的意義。13.5軟件質(zhì)量在關(guān)于軟件質(zhì)量的討論過程中，應(yīng)該遵循以下三條原則。1）應(yīng)強調(diào)軟件的總體質(zhì)量，不應(yīng)該片面強調(diào)軟件的正確性，而忽略其可維護性與可靠性，或忽略其易用性與效率等。2）應(yīng)在軟件生產(chǎn)的整個過程中都注意軟件的質(zhì)量，而不能只注意軟件最終成品的質(zhì)量。3）應(yīng)定量地測量軟件的質(zhì)量，而不能僅僅定性地評價軟件的質(zhì)量，軟件產(chǎn)品評價應(yīng)逐步走上評測結(jié)合、以測試為主的科學(xué)軌道。13.5軟件質(zhì)量軟件質(zhì)量能夠劃分成三個廣義的度量：可操作性、可維護性和可移植性，如圖13-2所示。1）可操作性。涉及到系統(tǒng)的基本操作。用戶對系統(tǒng)的第一印象通常是該系統(tǒng)看上去和感覺上怎樣。特別是對在線的交互式系統(tǒng)，這意味著使用起來有多容易和多直觀？它是否很好地適應(yīng)其運行所依賴的操作系統(tǒng)？例如，如果運行在Windows環(huán)境中，它的下拉和彈出菜單應(yīng)該與其操作系統(tǒng)的菜單工作方式一致。組成可操作性的因素主要有：準(zhǔn)確性、效率、可靠性、安全性、及時和適用性等。13.5軟件質(zhì)量2）可維護性。以保持系統(tǒng)正常運行并及時更新為參照。很多系統(tǒng)經(jīng)常需要改變，這不是因為它們實現(xiàn)得不好而是因為外部因素的改變。可維護性包括：可變性、可修正性、靈活性和可測試性等。3）可遷移性。是指把數(shù)據(jù)和/或系統(tǒng)從一個平臺遷移到另一個平臺并重用代碼的能力。在很多情況下，這不是一個重要的因素。但如果你編寫的是具用通用性的軟件，那么可遷移性就很關(guān)鍵了?？蛇w移性包括：代碼可重用性、互操作性和可移植性等。13.5軟件質(zhì)量圖13-2軟件質(zhì)量因素13.6軟件測試作為保證軟件質(zhì)量和可靠性的關(guān)鍵技術(shù)手段，軟件測試正日益受到廣泛的重視。但如何進行測試，如何提高測試的質(zhì)量和效率，從而確保軟件產(chǎn)品的質(zhì)量和可靠性，仍是令人深感困擾的問題。13.6.1測試應(yīng)用程序嚴(yán)格的測試過程是保證新系統(tǒng)正常工作的唯一方法。在新系統(tǒng)投入正常運行之前，不同的測試方法可以幫助定位和解決問題。應(yīng)用程序測試一般由單元測試、組裝測試和確認(rèn)（驗收）測試等環(huán)節(jié)組成。13.6.1測試應(yīng)用程序當(dāng)每個應(yīng)用程序模塊完成時，可以進行單元測試，以確保它能可靠正確地工作。當(dāng)所有模塊都完成和測試后，就需要進行組裝測試以保證模塊之間可以正確操作。單元測試和組裝測試通常在測試域中完成。測試域是可以進行軟件測試，而不會影響組織正常信息系統(tǒng)的區(qū)域。測試域可以是運行組織機構(gòu)信息系統(tǒng)的計算機系統(tǒng)上某獨立的存儲空間，或者可能就位于完全獨立的計算機系統(tǒng)上。在進行單元測試或者組裝測試出現(xiàn)問題時，項目小組必須跟蹤問題源，并解決之（調(diào)試和排錯）。單元測試和組裝測試可以重復(fù)進行以確保問題已經(jīng)正確解決，并且沒有引入新的問題。13.6.1測試應(yīng)用程序在單元測試和組裝測試完成后，確認(rèn)測試可以保證所有的硬件和軟件組件能一起正常工作。如果修改了某個已經(jīng)存在的信息系統(tǒng)后，就需要進行確認(rèn)測試。在—個全新的信息系統(tǒng)中，確認(rèn)測試用來模擬日常的工作負載，以確保系統(tǒng)處理速度和精確性能滿足說明文檔的需求。在理想情況下，確認(rèn)測試應(yīng)該在測試域中進行。如果某組織機構(gòu)沒有足夠的硬件資源來為測試目的復(fù)制現(xiàn)有信息系統(tǒng)，則確認(rèn)測試必須“現(xiàn)場”進行，即在工作環(huán)境下進行測試，這時有可能會造成組織機構(gòu)中部分日常功能受到影響。13.6.1測試應(yīng)用程序有時，也組織單獨的驗收測試階段作為系統(tǒng)的最后測試。驗收測試用來讓新系統(tǒng)的購買者或使用者確信，系統(tǒng)能完成預(yù)期工作。驗收測試過程通常由用戶和系統(tǒng)分析員來設(shè)計，并且經(jīng)常包括使用真實數(shù)據(jù)來確信新系統(tǒng)在數(shù)據(jù)加載的尖峰和平常情況下都能正常工作。13.6.2軟件測試自動化軟件測試自動化是一項讓計算機代替測試人員進行軟件測試的技術(shù)，它可以讓測試人員從煩瑣和重復(fù)的測試活動中解脫出來，專心從事有意義的測試設(shè)計等活動。如果采用自動比較技術(shù)，還可以自動完成測試用例執(zhí)行結(jié)果的判斷，從而避免人工比對存在的疏漏問題。在大多數(shù)情況下，軟件測試自動化可以減少開支，增加有限時間內(nèi)可執(zhí)行的測試，在執(zhí)行相同數(shù)量測試時節(jié)約測試時間。13.6.2軟件測試自動化軟件測試自動化通常借助測試工具進行。測試工具可以進行部分的測試設(shè)計、實現(xiàn)、執(zhí)行和比較的工作。通過運用測試工具，可以達到提高測試效率的目的。所以，測試工具的選擇和推廣使用應(yīng)該給予重視。部分的測試工具可以實現(xiàn)測試用例的自動生成，但通常的工作方式為人工設(shè)計測試用例，使用工具進行用例的執(zhí)行和比較。軟件測試自動化的設(shè)計通常必須由測試人員進行手工設(shè)計，但是在設(shè)計時卻必須考慮自動化的特殊要求，否則無法實現(xiàn)利用工具進行用例的自動執(zhí)行。為此，就必須在測試的設(shè)計和內(nèi)容的組織方面采取一些特殊的方法。13.7軟件文檔軟件的正確使用和有效維護離不開文檔。通常軟件文檔包括用戶文檔和系統(tǒng)文檔。13.7.1用戶文檔為了正確運行軟件，用戶手冊對用戶是必不可少的，它告訴用戶如何使用該軟件，通常包含一個指導(dǎo)用戶熟悉該軟件各項特性的教程。好的用戶手冊能夠成為功能強大的營銷工具。手冊應(yīng)該面向新手和專業(yè)用戶。13.7.2系統(tǒng)文檔系統(tǒng)文檔定義軟件本身。撰寫系統(tǒng)文檔的目的是為了讓原始開發(fā)人員之外的人能夠維護和修改軟件。系統(tǒng)開發(fā)的各個階段都應(yīng)該有文檔。國家標(biāo)準(zhǔn)《計算機軟件產(chǎn)品開發(fā)文件編制指南》（GB/T8567）建議在軟件的開發(fā)過程中編制下述14種文件，即：可行性研究報告、項目開發(fā)計劃、軟件需求說明書、數(shù)據(jù)要求說明書、概要設(shè)計說明書、詳細設(shè)計說明書、數(shù)據(jù)庫設(shè)計說明書、用戶手冊、操作手冊、模塊開發(fā)卷宗、測試計劃、測試分析報告、開發(fā)進度月報以及項目開發(fā)總結(jié)報告。13.7.2系統(tǒng)文檔而《計算機軟件需求說明編制指南》（GB/T9385）、《計算機軟件測試文件編制規(guī)范》（GB/T9386）等有關(guān)軟件工程的國家標(biāo)準(zhǔn)對軟件文件的編制提出了更為詳盡的要求，《軟件文檔管理指南》（GB/T16680）則明確了對軟件文件的管理要求。13.8面向?qū)ο蠓椒ê蚒ML20世紀(jì)80年代以來，面向?qū)ο蟮姆椒ㄅc技術(shù)受到廣泛重視，80年代中到90年代，針對面向?qū)ο蟮姆治雠c設(shè)計演化成一種完整的軟件開發(fā)方法和系統(tǒng)的技術(shù)體系，即面向?qū)ο筌浖こ?。面向?qū)ο螅∣O）方法是一種把面向?qū)ο蟮乃枷霊?yīng)用于軟件開發(fā)過程中，指導(dǎo)開發(fā)活動的系統(tǒng)方法，它是建立在對象概念（對象、類和繼承）基礎(chǔ)上的方法。面向?qū)ο蟮湫偷姆椒ㄓ蠵.Coad和E.Yourdon的面向?qū)ο蠓治觯∣OA）和面向?qū)ο笤O(shè)計（OOD），G.Booch的面向?qū)ο箝_發(fā)方法，J.Rumbaugh等人提出的對象建模技術(shù)（OMT），Jacobson的面向?qū)ο筌浖こ蹋∣OSE）等。面向?qū)ο蠓椒ㄒ呀?jīng)成為主流開發(fā)方法之一。13.8面向?qū)ο蠓椒ê蚒ML各種面向?qū)ο蟮姆椒ǘ加凶约旱谋硎痉?、過程和工具，甚至各種方法所使用的術(shù)語也不盡相同。而每種方法都各有短長，很難找到一個最佳答案。設(shè)計“統(tǒng)一建模語言”（UML）的一個初始目標(biāo)就是結(jié)束面向?qū)ο箢I(lǐng)域中的方法大戰(zhàn)。1994年Booch和Rumbaugh在RationalSoftwareCorporatio