1.1軟件
1.軟件的發展
軟件的發展經歷瞭如下幾個階段：
第一階段從20世紀50年代初期至60年代中期，這一階段又稱爲程序設計階段。此時硬件已經通用化，而軟件的生產卻是個體化。軟件產品爲專用軟件，規模較小，功能單一，開發者即爲使用者，軟件只有程序，無文檔。軟件設計在人們的頭腦中完成，形成了“軟件等於程序”的錯誤觀念。
第二階段從20世紀60年代中期至70年代末期，稱爲程序系統階段。此時多道程序設計技術、多用戶系統、人機交互技術、實時系統和第一代數據庫管理系統的出現，催生了專門從事軟件開發的“軟件作坊”，軟件廣泛應用，但軟件技術和管理水平相對落後，導致“軟件危機”出現。軟件危機主要表現在以下幾個方面：
(1) 軟件項目無法按期完成，超出經費預算，軟件質量難以控制；
(2) 開發人員和開發過程之間管理不規範，約定不嚴密，文檔書寫不完整，使得軟件維護費用高，某些系統甚至無法進行修改；
(3) 缺乏嚴密、有效的質量檢測手段，交付給用戶的軟件質量差，在運行中出現許多問題，甚至產生嚴重的後果；
(4) 系統更新換代難度大。
第三階段從20世紀70年代末期至80年代中期稱爲軟件工程階段。微處理器的出現及分佈式系統的廣泛應用，使得計算機真正成爲大衆化的東西。以軟件的產品化、系列化、工程化和標準化爲特徵的軟件產業發展起來，軟件開發有了可以遵循的軟件工程化的設計準則、方法和標準。1968年，北大西洋公約組織的計算機科學家在聯邦德國召開國際會議，會議討論了軟件危機問題，正式提出並使用“軟件工程”概念。這標誌着軟件工程的誕生。
第四階段從20世紀80年代中期至今，客戶端/服務器(C/S)體系結構，特別是Web技術和網絡分佈式對象技術的飛速發展，導致軟件系統體系結構向更加靈活的多層分佈式結構演變，CORBA、EJB、COM/DCOM等三大分佈式的對象模型技術相繼出現。
2006年提出的面向服務架構(Service-Oriented Architecture，簡稱SOA)作爲下一代軟件架構，是一種“抽象、鬆散耦合和粗粒度”的軟件架構，根據需求通過網絡對鬆散耦合的粗粒度應用組件進行分佈式部署、組合和使用，主要用於解決傳統對象模型中無法解決的異構和耦合問題。
2.軟件的生命週期
軟件生命週期具有如下六個階段：
(1) 問題的定義及規劃。此階段由軟件開發方與需求方共同討論，確定軟件的開發目標及其可行性。
(2) 需求分析。在確定軟件開發可行的情況下，對軟件需要實現的各個功能進行詳細分析。需求分析階段作爲一個很重要的階段，在整個軟件開發過程中是不斷變化和深入的，因此必須制定需求變更計劃來應付這種變化，以保護整個項目的順利進行。
(3) 軟件設計。此階段主要根據需求分析的結果，對整個軟件系統進行設計，如系統框架設計、數據庫設計等。軟件設計一般分爲總體設計和詳細設計。
(4) 程序編碼。此階段是將軟件設計的結果轉換成計算機可運行的程序代碼。程序編碼必須符合標準的編寫規範，以保證程序的可讀性、易維護性，提高程序的運行效率。
(5) 軟件測試。在軟件設計完成後要經過嚴密的測試，以發現軟件在整個設計過程中存在的問題並加以糾正。整個測試過程分爲單元測試、組裝測試以及系統測試等階段。測試的方法主要有白盒測試和黑盒測試兩種。在測試過程中需要建立詳細的測試計劃並嚴格按照測試計劃進行測試，以減少測試的隨意性。
(6) 運行維護。軟件維護是軟件生命週期中持續時間最長的階段。在軟件開發完成並投入使用後，由於多方面的原因，軟件有可能不適應用戶的要求，要延續軟件的使用壽命，此時就必須對軟件進行維護。
1.2軟件過程
一、RUP（Rational Unified Process），統一軟件開發過程，統一軟件過程是一個面向對象且基於網絡的程序開發方法論。
1. RUP特點：
1）.迭代模型
RUP強調軟件開發是一個迭代模型(Iterative Model)，它定義了四個階段(Phase)：初始(Inception)、細化(Elaboration)、構造(Construction)、交付(Transition)。其中每個階段都有可能經歷以上所提到的從商務需求分析開始的各個步驟，只是每個步驟的高峯期會發生在相應的階段，例如開發實現的高峯期是發生在構造階段。實際上這樣的一個開發方法論是一個二維模型，這種迭代模型的實現在很大程度上提供了及早發現隱患和錯誤的機會，因此被現代大型信息技術項目所採用。
2）、用例驅動
RUP的另一大特徵是用例驅動。用例是RUP方法論中一個非常重要的概念。簡單地說，一個用例就是系統的一個功能。在系統分析和系統設計中，用例被用來將一個複雜的龐大系統分割、定義成一個個小的單元，這個小的單元就是用例。然後以每個小的單元爲對象進行開發。按照RUP過程模型的描述，用例貫穿整個軟件開發的生命週期。在需求分析中，客戶或用戶對用例進行描述，在系統分佈和系統設計過程中，設計師對用例進行分析，在開發實現過程中，開發編程人員對用例進行實現，在測試過程中，測試人員對用例進行檢驗。
3）、以架構爲中心
RUP的第三大特徵是它強調軟件開發是以構架爲中心的。構架設計(ArchitecturalDesign)是系統設計的一個重要組成部分。在構架設計過程中，設計師(Architect)必須完成對技術和運行平臺的選取，整個項目的基礎框架( Framework)的設計，完成對公共組件的設計，如審計( Auditing)系統、日誌(Iog)系統、錯誤處理(Exception Handling)系統、安全(Security)系統等。設計師必須對系統的可擴展性( Extensibility)、安全性(Security)、可維護性( Maintainability)、可延拓性(Scalability)、可重用性(Reusability)和運行速度(Performance)提出可行的解決方案。
2．RUP各個階段
RUP中的軟件生命週期在時間上被分解爲4個順序的階段，分別是初始階段、細化階段、構建階段和交付階段。每個階段結束於一個主要的里程碑；每個階段本質上是兩個里程碑之間的時間跨度。在每個階段的結尾執行一次評估以確定這個階段的目標是否已經滿足，如果評估結果滿意，則允許項目進入下一個階段。其中每個階段又可以進一步分解迭代。一個迭代是一個完整的開發循環，產生一個可執行的產品版本，作爲最終產品的一個子集，產品增量式地發展，從一個迭代過程到另一個迭代過程，直到成爲最終的系統。
如圖1.1所示，RUP可用二維座標來描述。橫軸通過時間組織，是過程展開的生命週期特徵，體現開發過程的動態結構，用來描述它的術語主要包括週期、階段、迭代和里程碑；縱軸以內容來組織，體現開發過程的靜態結構，用來描述它的術語主要包括活動、產物、工作者和工作流。
1) 初始階段
初始階段的目標是爲系統建立商業案例並確定項目的邊界。爲了達到該目標必須識別所有與系統交互的外部實體，並在較高層次上定義交互的特性。這包括識別出所有用例並描述幾個重要的用例。本階段具有非常重要的意義，在這個階段中所關注的是整個項目進行中的業務和需求方面的主要風險。對於建立在已有系統基礎上的開發項目來講，初始階段可能很短。
在初始階段應該取得如下成果：
(1) 藍圖文檔，即關於項目的核心需求、關鍵特性、主約束的總體藍圖。
(2) 初始的用例模型(約佔總體的10%～20%)。
(3) 初始的項目術語表。
(4) 初始的商業案例，包括商業環境、驗收標準等。
(5) 初始的風險評估。
(6) 項目計劃。
(7) 一個或多個原型。
2) 細化階段
細化階段的目標是分析問題領域，建立堅實的體系結構基礎，制定項目計劃，消除項目中風險最高的因素。爲了達到該目標，必須在理解整個系統的基礎上，對體系結構作出決策，包括其範圍、主要功能和諸如性能等非功能需求，同時爲項目建立支持環境，包括創建開發案例，創建模板、工作準則並準備工具。
細化階段的成果包括：
(1) 用例模型。所有的用例和參與者都已被識別出，並完成大部分的用例描述。
(2) 補充非功能性要求以及與特定用例沒有關聯的需求。
(3) 軟件體系結構的描述。
(4) 可執行的軟件原型。
(5) 修訂過的風險清單和商業案例。
(6) 整個項目的開發計劃，該開發計劃應體現迭代過程和每次迭代的評價標準。
(7) 更新的開發案例。
(8) 初步的用戶手冊。
3) 構建階段
在構建階段，組件和應用程序的其餘功能被開發並集成爲產品，所有的功能都被徹底地測試。從某種意義上說，構建階段是一個製造過程，其重點爲管理資源及控制運作，從而降低成本、加速進度和優化質量。
構建階段的成果是可以交付給最終用戶的產品，它至少包括：
(1) 集成於適當操作系統平臺上的軟件產品。
(2) 用戶手冊。
(3) 當前版本的描述。
4) 交付階段
交付階段的重點是確保軟件對最終用戶是可用的。交付階段可以跨越幾次迭代，包括爲發佈做準備的產品測試，基於用戶反饋的少量的調整。在這一階段，用戶反饋應主要集中在產品調整、設置、安裝和可用性問題。
3. RUP核心工作流
1) 商業建模
商業建模工作流描述瞭如何爲新的目標組織開發一個構想，並基於這個構想在商業用例模型和商業對象模型中定義組織的過程、角色和責任。
2) 需求
需求工作流的目標是描述系統應該做什麼，並使開發人員和用戶就這一描述達成共識。爲了達到該目標，要對需要的功能和約束進行提取、組織、文檔化，最重要的是理解系統所解決問題的定義和範圍。
3) 分析設計
分析設計工作流是將需求轉化成系統的設計，爲系統開發一個健壯的結構，使其與實現環境相匹配。設計活動以體系結構設計爲中心，其結果是一個設計模型和一個可選的分析模型。設計模型是源代碼的抽象，由設計類和一些描述組成。設計類被組織成具有良好接口的設計包和設計子系統，而描述則體現了類的對象如何協同工作實現用例的功能。
4) 實施
實施工作流的目的包括以層次化的子系統形式定義代碼的組織結構，以組件的形式(源文件、二進制文件、可執行文件)實現類和對象，將開發出的組件作爲單元進行測試，集成單元使其成爲可執行的系統。
5) 測試
測試可通過可靠性、功能性和系統性的三維模型來進行。測試工作流要驗證對象間的交互作用，驗證軟件中所有組件的正確集成，檢驗所有的需求已被正確的實現，識別並確認缺陷在軟件部署之前被提出並處理。RUP提出的迭代方法是在整個項目中進行測試的，從而儘可能早地發現缺陷，從根本上降低了修改缺陷的成本。
6) 部署
部署工作流的目的是成功地生成版本並將軟件分發給最終用戶。部署工作流描述了那些與確保軟件產品對最終用戶具有可用性相關的活動，它包括：軟件打包、生成軟件本身以外的產品、安裝軟件、爲用戶提供幫助。在有些情況下，還可能包括計劃和生成beta測試版、移植現有的軟件和數據以及正式驗收。
7) 配置和變更管理
配置和變更管理工作流描繪瞭如何在多個成員組成的項目中控制大量的軟件產物。配置和變更管理工作流提供了準則來管理演化系統中的多個變體，跟蹤軟件創建過程中的版本。工作流描述瞭如何管理並行開發、分佈式開發，如何自動化創建工程，同時也闡述了對產品修改的原因、時間、人員進行記錄，依靠程序員主動、開放、高效的面對面交流來達成對需求、目標、設計實現的理解。
8) 項目管理
軟件項目管理平衡各種可能產生衝突的目標，管理風險，克服各種約束併成功交付使用戶滿意的產品。其目標包括：爲項目的管理提供框架，爲計劃、人員配備、執行和監控項目提供實用的準則，爲管理風險提供框架等。
9) 環境
環境工作流的目的是向軟件開發組織提供軟件開發環境，包括過程和工具。環境工作流集中於配置項目過程中所需要的活動，同樣也支持開發項目規範的活動，提供了逐步的指導手冊並介紹瞭如何在組織中實現過程。
3. 用例驅動爲核心
開發軟件系統的目的是要爲該軟件系統的用戶服務。因此，要創建一個成功的軟件系統，必須明白此軟件的用戶需要什麼。“用戶”這個術語所指並不僅僅侷限於人，還包括其它軟件系統。一個用例就是系統向用戶提供一個有價值的結果的某項功能。用例是軟件的功能性需求。所有用例結合起來就構成了“用例模型”，該模型描述系統的全部功能。用例模型取代了系統的傳統的功能規範說明。功能規範說明描述爲 “需要該系統做什麼？”，而用例驅動則是“需要該系統爲每個用戶做什麼？”因此，用例模型是從用戶的利益角度出發進行考慮，設計人員創建一系列用例模型，開發人員審查每個後續模型，以確保它們符合用例模型。測試人員將測試軟件系統的實現，以確保實現模型中的組件正確實現了用例。這樣，用例不僅啓動了開發過程，而且與開發過程結合在一起。
二、敏捷過程
傳統計劃驅動的開發方法往往不能獲得良好的效果，並且由於過分強調過程控制，因此在開發過程中產生大量的文檔，給開發人員帶來很多額外的工作量，因此被稱爲重量級方法。這種方法使程序員花費大量的開發時間在開發文檔的撰寫和維護上，而真正花在代碼上的時間較少，並且由於依賴過程控制，而不是程序員自我管理，導致開發過程管理複雜且低效，極大地阻礙了軟件開發效率。
1. 敏捷開發簡介
2001年是全球軟件行業具有歷史意義的一年，就在這一年，“敏捷聯盟”成立了，並發表了對傳統軟件開發過程具有顛覆意義的《敏捷宣言》:“通過開發軟件和幫助別人開發軟件，我們找到了一些更好的開發軟件的方式。通過這一工作，我們得出了這些價值：
● 個體和交互 勝過 過程和工具；
● 可以工作的軟件 勝過 面面俱到的文檔；
● 客戶合作 勝過 合同談判；
● 響應變化 勝過 遵循計劃。
2. 敏捷開發的特徵
敏捷方法具有如下兩個主要特徵：
(1) 開發採用適應性方法，經過多次小型迭代開發過程逐步逼近實際需求，從而爲客戶提供實際需要的軟件。
(2) 以人爲本。傳統計劃驅動方法企圖以文檔、過程爲核心，從而抹殺人的重要性。
3. 敏捷開發的價值與侷限
敏捷方法拋棄了繁瑣的文檔管理，依靠程序員主動、開放、頻繁的面對面的高效交流來達成對需求、目標、設計實現的理解。敏捷方法拋棄了機械、嚴格的過程控制，依賴程序員和開發團隊的高標準自我要求：嚴格的自律，團隊合作精神，個人高度自覺的主動性，責任感。
敏捷方法的高效和高質量實際上是以程序員的高素質和開發團隊的高度合作的開發文化爲基礎的。因此敏捷方法的實施前提是必須找到願意並有能力實施敏捷方法的團隊。XP的創始人Beck也曾建議有些情況是不適合採用XP方法的。
1.3軟件質量
一.概述
軟件質量具有多種定義。
ANSI/IEEE Std 729—1983定義軟件質量爲“與軟件產品滿足規定的和隱含的需求的能力有關的特徵或特性的全體”。
CMM對質量的定義是：
① 一個系統、組件或過程符合特定需求的程度；
② 一個系統、組件或過程符合客戶或用戶的要求或期望的程度。
M.J.Fisher定義軟件質量爲“所有描述計算機軟件優秀程度的特性的組合”。
因此，軟件質量是一個複雜的多層面概念。
軟件質量框架是由“質量特性—質量子特性—度量因子”構成的3層結構模型，如圖1.2所示。
二、CMM/CMMI
1. CMM
CMM是卡耐基—梅隆大學軟件工程研究院受美國國防部委託制定的軟件過程改良和評估模型，也稱爲SEI SW-CMM。該模型於1991年發佈，其核心是把軟件開發視爲一個過程，進行過程的監控和研究。CMM提供了一個軟件過程改進的框架，這個框架與軟件生命週期無關，與所採用的開發方法無關。
CMM爲軟件企業的過程能力提供了一個階梯式的進化框架，該框架共有5級，分別是初始級、可重複級、已定義級、已管理級和優化級。第一級實際上是一個起點，任何準備按CMM體系進化的企業都自然處於這個起點上，並通過這個起點向第二級邁進。除第一級外，每一級都設定了一組目標，如果達到了這組目標，則表明達到了這個成熟級別，可以向下一個級別邁進，如表1.1所示。
1) 初始級
在這個階段，軟件開發過程表現得非常隨意，偶爾會出現混亂的現象，只有很少的工作過程是經過嚴格定義的，開發成功往往依靠的是某個人的智慧和努力。此時的軟件機構基本沒有健全的軟件工程管理制度，其軟件過程完全取決於項目組的人員配備，具有不可預測性。人員變了過程也隨之改變。如果一個項目碰巧由一個傑出的管理者和一支有經驗、有能力的開發隊伍承擔，則這個項目可能是成功的。但是，更常見的情況是，由於缺乏健全的管理和周密的計劃，延期交付和費用超支的情況經常發生，結果大多數行動只是應付危機，而不是完成事先計劃好的任務。
2) 可重複級
這一階段已經建立了基本的項目管理過程，只需按部就班地設計功能、跟蹤費用，根據項目進度表進行開發。對於相似的項目，可以重用以前已經開發成功的部分。處於2級成熟度的軟件機構，針對所承擔的軟件項目已建立了基本的軟件管理控制制度。通過對以前項目的觀察和分析，可以提出針對現行項目的約束條件。項目負責人跟蹤軟件產品開發的成本和進度以及產品的功能和質量，並且識別出爲滿足約束條件所應解決的問題。此時，軟件的需求是條理化，而且其完整性是受控制的。軟件機構已經制定了項目標準，並且能確保嚴格執行這些標準。項目組與客戶及承包商已經建立起一個穩定的、可管理的工作環境。
3) 已定義級
在這一階段，軟件開發的工程活動和管理活動都是文檔化、標準化的，是被集成爲一個有組織的標準開發過程。所有項目的開發和維護都在這個標準基礎上進行定製。處於3級成熟度的軟件機構，有一個固定的過程小組從事軟件過程工程活動。過程小組可以利用過程模型進行過程例化活動，從而獲得一個針對某個特定的軟件項目的過程實例，並投入過程運作而開展有效的軟件項目工程實踐。同時，過程小組還可以推進軟件機構的過程改進活動。在該軟件機構內實施了培訓計劃，能夠保證全體項目負責人和項目開發人員具有完全承擔任務所要求的知識和技能。
4) 已管理級
這一階段已經對軟件開發過程和產品質量的測試細節有了很好的歸納，產品和開發過程都可以定量地分解和控制。
處於4級成熟度的軟件機構的過程能力可以概況爲：軟件過程是可度量的，軟件過程在可度量的範圍內運行。這一級的過程能力允許軟件機構在定量的範圍內預測過程和產品質量趨勢，在發生偏離時可以及時採取措施予以糾正，並且可以預期軟件產品是高質量的。
5) 優化級
這一階段通過建立開發過程的定量反饋機制，不斷產生新的思想，採用新的技術來優化開發過程。處於5級成熟度的軟件機構，可以通過對過程實例性能的分析和確定產生某一缺陷的原因，來防止再次出現這種類型的缺陷。通過對任何一個過程實例的分析所獲得的經驗教訓都可以成爲該軟件機構優化其過程模型的有效依據，從而使其它項目的過程實例得到優化。這樣的軟件機構可以通過從過程實施中獲得的定量的反饋信息，在採用新思想和新技術的同時測試它們，從而不斷地改進和優化軟件過程。
處於5級成熟度的軟件機構的過程能力可以概況爲：軟件過程是可優化的。這一級的軟件機構能夠持續不斷地改進其過程能力，既對現行的過程實例不斷地改進和優化，又藉助於所採用的新技術和新方法來實現未來的過程改進。
2. CMMI
CMMI是SEI於2000年發佈的CMM的新版本。CMMI (Capability Maturity Model Integration，能力成熟度模型集成)將各種能力成熟度模型，包括Software CMM、Systems Eng-CMM、People CMM和Acquisition CMM等，整合到同一架構中去，由此建立包括軟件工程、系統工程和軟件採購等在內的模型集成，以解決除軟件開發以外的軟件系統工程和軟件採購工作中的需求。
三、質量與測試
軟件測試和軟件質量是分不開的。測試是手段，質量是目的。軟件測試作爲一種輔助而且必需的手段，客觀反映某個時間段內的軟件質量。測試人員執行軟件測試，發現軟件BUG，反饋給開發人員進行修改，然後經過再次測試，以確認該BUG已被解決。測試人員重複此過程直至軟件符合最終用戶需求。在BUG產生之前，BUG的具體數量、位置、出現時間等都是未知數，測試人員根本就不知道。
測試可以發現BUG，但不能避免BUG的產生。QA團隊對項目進行近似完全的控制，通過建立標準和方法論，有條理地仔細監視和評價軟件開發過程，對發現的軟件缺陷提出解決建議，執行某些測試，從而從源頭上防止BUG的出現。
實現軟件質量保證主要有兩種途徑：一種是通過貫徹軟件工程各種有效的技術方法和措施使得儘量在軟件開發期間減少錯誤；另一種是通過分析和測試軟件來發現和糾正錯誤。
軟件測試屬於軟件控制，作爲軟件質量的重要保證，其和質量保證有如下4點區別，如表1.2所示。
通過實施CMM/CMMI，有助於改進軟件產品的質量，改進項目滿足預定目標能力，減少開發成本和週期，降低項目風險，提高組織過程能力，提高市場佔有率。實施不同等級的CMM/CMMI，對於按照每功能點來計算的軟件缺陷率的降低具有顯著的作用，如表1.3所示。
CMM/CMMI基於過程的軟件質量管理主要包括質量保證和質量控制兩大方面。軟件質量保證是由(相對)獨立的質量管理人員在項目的整個開發週期中對項目所執行的過程和產生的工作產品進行監督和檢查，確保其符合預定的要求。軟件質量保證的目的是確保過程得到有效的執行及推進過程改進，並就項目過程的執行情況和所構造的產品向管理者提供適當的可視性。軟件質量控制是指爲評價和驗證已開發的產品而執行的活動和技術，包括驗證產品是否滿足質量要素的要求，以及產品(包括生命週期的工作產品)是否具有接受的質量。
軟件質量控制所採取的主要技術是軟件測試。通過軟件測試，來驗證產品是否符合技術文檔預期的特性、功能和性能等要求，並識別產品的缺陷。
雖然目前在CMM/CMMI中沒有明確軟件測試作爲一個獨立的過程域，但是在CMM/CMMI很多地方都涉及了軟件測試內容。CMMI和軟件測試最主要的區別在於：CMMI是對於軟件過程的改進(包括軟件測試過程)；而軟件測試是針對項目結果的驗證，在測試時是從側面改進軟件質量的。例如，在CMMI的“確認”和“驗證”兩個過程域中，CMMI列出了以下實踐。
1.4測試和開發的關係
1．測試與開發各階段的關係
圖1.3給出了軟件測試與軟件開發各階段的關係，軟件測試在開發階段具有如下作用。
(1) 項目規劃階段：負責從單元測試到系統測試的整個測試階段的監控。
(2) 需求分析階段：確定測試需求分析、系統測試計劃的制定，評審後成爲管理項目。
(3) 詳細設計和概要設計階段：確保集成測試計劃和單元測試計劃完成。
(4) 編碼階段：由開發人員完成自己負責部分的測試代碼。當編寫工作項目較大時，由專人進行編碼階段的測試任務。
(5) 測試階段(單元、集成、系統測試)：依據測試代碼進行測試，並提交相應的測試狀態報告和測試結束報告。
2．測試與開發的並行性
圖1.4給出了軟件測試與軟件開發之間的並行關係。
3．完整的軟件開發流程
從圖1.5中可以看出，測試過程和開發過程貫穿軟件過程的整個生命週期，二者相輔相成，相互依賴，具體概括爲如下3個關鍵點：
(1) 測試過程和開發過程是同時開始、同時結束的，兩者保持同步的關係。
(2) 測試過程是對開發過程中階段性成果和最終產品進行驗證的過程，所以兩者相互依賴。前期，測試過程更多地依賴於開發過程；而後期，開發過程更多地依賴於測試過程。
(3) 測試工作的重點和開發工作的重點可能是不一樣的，兩者有各自的特點。
1.2軟件測試的基本概念
1.軟件測試的定義：
IEEE給出的測試定義：
在特定的條件下運行系統或構件，觀察或記錄結果，對系統的某個方面做出評價。（測評是評錯）
分析某個軟件項以發現和現存的和要求的條件之差別(即錯誤)並評價此軟件項的特性。（測試是做度量）
2.軟件測試的特徵：
可以從需求開始，而不僅僅是代碼
既是靜態活動也是動態活動
用來預防失效
有助於在軟件生命週期中儘早發現問題，以降低修復缺陷所需的成本
過程中應創建可重用的測試件
3.軟件測試的目的：
Glenford J. Myers提出:
測試是程序的執行過程，目的在於發現錯誤。
測試是爲了證明程序有錯,而不是證明程序無錯誤。
個好的測試用例在於能發現至今未發現的錯誤。
個成功的測試是發現了至今未發現的錯誤的測試
Bill Hetzelt在《軟件測試完全指南》中指出:
軟件測試的目的不僅僅是爲了發現軟件缺陷與錯誤，同時
也對軟件進行度量和評估，提高軟件質量。
現對軟件測試目的總結爲以下三點：
①以最少的人力、物力、時間找出軟件中潛在的各種錯誤和缺陷，通過修正錯誤和缺陷提高軟件質量，迴避潛在的軟件錯誤和缺陷給軟件造成的商業風險。
②通過分析測試過程中發現的問題可以幫助發現當前開發工作所採用的軟件過程的缺陷，以便進行軟件過程改進;同時通過對測試結果的分析整理,可修正軟件開發則，併爲軟件可靠性分析提供相關的依據。
③評價程序或系統的屬性,對軟件質量進行度量和評估,以驗證軟件的質量滿足用戶的需求,爲用戶選擇、接受軟件提供有力的依據。
| |
\.| |/
.\/
軟件測試的目的是工程性的,是以發現錯誤爲目的
4.軟件測試的關鍵問題（原則）
軟件測試是證僞而非證真
儘早地和不斷地進行軟件測試
重視無效數據和非預期使用習慣的測試
程序員應該避免檢查自己的程序
充分注意測試中的羣集現象（二八原則）
用例要定期評審
應當每一個測試結果做全面檢查
測試現場保護和資料歸檔
軟件測試的經濟型原則
5.軟件質量保證
軟件質量保證是貫穿軟件項目整個生命週期的有計劃和有系統的活動，經常針對整個項目質量計劃執行情況進行評估，檢查和改進，向管理者、顧客或其他方提供信任，確保項目質量與計劃保持一 致。
確保軟件項目的過程遵循了對應的標準及規範要求且產生了合適的文檔和精確反映項目情況的報告，其目的是通過評價項目質量建立項目達到質量要求的信心。軟件質量保證活動主要包括評審項目過程、審計軟件產品，就軟件項目是否真正遵循已經制定的計劃、標準和規程等，給管理者提供可視性項目和產品可視化的管理報告。
軟件測試與軟件質量：軟件測試是獲取度量值的一種重要手段。
1.5軟件測試的分類
1.單元測試
單元測試又稱模塊測試，針對軟件設計中的最小單位一程序模塊，進行正確性檢查的測試工作。單元測試需要從程序的內部結構出發設計測試用例。多個模塊可以平行地獨立進行單元測試。
單元定義: C中指一個函數，Java中 指一個類，在圖形化的軟件中,
單元測試的六個問題？
①什麼時候進行單元測試：編碼後，編譯通過後進行。
②由誰來做單元測試：白盒測試工程師或者開發工程師，最好不要白己做白己代碼的測試
③單元測斌的依據：源程序(代碼+註釋) +《詳細設計文檔》
④單元測試的通過標準：程序通過所有單元測試用例、語句的覆蓋率達到100%、分支的覆蓋率達到85%
⑤國內單元測斌的現狀：簡單+沒有單元測試計劃、單元測試用例和代碼覆蓋率的統計。
⑥如何進行單元測試：單元格測試主要用白盒測試，先靜態地檢查代碼是否符合規
範，然後動態運行代碼，檢查其實際運行結果，檢查程序的運行結果是否正確是一個最基本的要求，還要關注容錯處理，程序的邊界值處理等
2.集成測試
集成測試又叫組裝測試，通常在單元測試的基礎上，將所有程序模塊進行有序的、遞增的測試。重點測試不同模塊的接口部分。
1.什麼時候進行集成測試?
單元測試&集成測試同步進行，理論上先有單元測試。
2.由誰來做集成測試?
白金測試工程師或者開發工程師
3.集成測試的依據?
單元測試的模塊+《概要設計》文檔。
3.系統測試
指的是將整個軟件系統看爲一一個整體進行測試，包括對功能、性能、
以及軟件所運行的軟硬件環境進行測試。
目前系統測試主要由黑盒測試工程師在系統集成完畢後進行測試，前期主要測試系統的功能是否滿足需求，後期主要測試系統運行的性能是否滿足需求，以及系統在不同的軟硬件環境中的兼容性等。
4.驗收測試
驗收測試指按照項目任務書或合同、供需雙方約定的驗收依據文檔進行的對整個系統的測試與評審，決定是否接收或拒收系統。在系統測試的後期，以用戶測試爲主或有測試人員等質量保證人員共同參與的測試。
-
a測試:指的是指的是由用戶，測試人員、開發人員等共同參與的內部測試。
-
β測試:指的是內測後的公測，印完全交給最終用戶測試
-
正式的驗收測試
驗收測試的重要性：驗收簽字，收錢
5.靜態測試(static testing)
靜態測試是指不實際運行被測軟件，而只是靜態地檢查程序代碼、界面或文檔中可能存在的錯誤過程。
-
代碼測試: 主要測試代碼是否符合相應的標準和規範。
-
界面測試:主要測試軟件的實際界面與需求中的說明是否相
符
-
文檔測試:主要測試用戶手冊和需求說明是否真正符合用戶
的實際需求。
-
工具， (Logiscope) Telelogic,可以用作Java/C++等規範
6.動態測試
動態測試(dynamic testing)、 是指實際運行被測程序，輸入相應的測試數據，
檢查實際輸出結果和預期結果是否相符的過程。
-
動態測試方法爲結構和正確性測試
-
動態測試工具Robot、 QTP等
7.黑盒測試
指的是把被測的軟件看做一個黑金子，我們不關心盒子裏面的結構是什麼樣子的，只關心軟件的輸入數據和輸出數據。
7.1功能測試：是黑盒測試的一方面。它檢查軟件的功能是否符合客戶要求。
-
邏輯功能測試( logic function testing )
-
界面測試(UI testing)
-
易用性測試(usability testing)
-
安裝測試(instal lation testing)
-
兼容性測試(compatibility testing)
7.2性能測試(performance testing) :是軟件測試的高端領域，性能測試工程師的待遇和白盒測試工程師不相上下，通常我們所說的高級軟件測試工程師一般就是指性能測試或是白盒測試工程師。
-
時間性能(事務響應時間等)
-
空間性能(系統資源消耗)
-
一般性能測試
-
可靠性測試
-
負載測試
-
壓力測試
8.白盒測試
指的是把盒子打來，去研究裏面的源代碼和程序結構。
在軟件公司中，往往採用黑盒測試&白盒測試相結合的方式。
-
軟件的整體功能和性能進行黑盒測試
-
軟件的源代碼採用白盒測試
9.迴歸測試(regression testing)
是指軟件被修改後重新進行的測試，如重複執行上一個版本測試時的用例，是爲了保證對軟件所做的修改沒有引入新的錯誤而重複進行的測試。
10.冒煙測試(smoke testing)
是指在對一個新版本進行系統大規模的測試之前，先驗證一下軟件的基本功能是否實現，是否具備可測試性。
11.隨機測試(random testing)
是指測試中所有的輸入數據都是隨機生成的，其目的是模擬用戶的真實操作，並發現一些邊緣性的錯誤。
1.4軟件缺陷管理
1.目標：確保每個被發現的缺陷都能夠被有效的解決。(注意:這裏的解決不一定是被修復，也可以是其它的處理方式，如在下一版本修正或者不修正，但是每個bug的處理方式必須能在開發組織中達成一致。)
2.定義：
-
軟件未達到產品說明書中標明的功能。
-
軟件出現了產品說明書中指明的不會出現的功能。
-
軟件功能超出了產品說明書中指明的範圍。
-
軟件未達到產品說明書中指明應達到的目標。
-
軟件測試人員認爲軟件難以理解和使用、運行速度慢，或最終用戶認爲不好。
3.軟件缺陷屬性：
發現缺陷後，需要提交缺陷單，通常情況下，，缺陷單需而要包含以下的內容:
|
ID
|
描述信息(Description)
|
|
標題(Title)
|
重現步驟(Reproduce)
|
|
測試環境(Environment)
|
附件(Attachment)
|
|
嚴重等級(Severity)
|
測試人員(Created by)
|
|
優先級(Priority)
|
處理人員(Assign to)
|
|
類別(Category)
|
.......
|
|
狀態(Status)
|
|
4.軟件缺陷的嚴重程度：
描述因缺陷引起的故障對軟件產品影響的程度。通常劃分爲以下幾個級別:
按照CMM5中定義的規範，軟件缺陷分爲多個等級，分別爲致命、嚴重、一般和提示。
(1) 致命。致命性漏洞主要爲：內存泄漏、用戶數據丟失或被破壞、系統崩潰/死機/凍結、模塊無法啓動或異常退出、嚴重的數值計算錯誤、功能設計與需求嚴重不符、其它導致無法測試的錯誤和造成系統不穩定等情況。
(2) 嚴重。嚴重性漏洞主要爲：功能未實現、功能嚴重錯誤、系統刷新錯誤、語音或數據通信錯誤、輕微的數值計算錯誤、系統所提供的功能或服務受明顯的影響但不會影響到系統穩定性。
(3) 一般。一般性漏洞主要爲：操作界面錯誤(包括數據窗口內列名定義、含義是否一致)、邊界條件下錯誤、提示信息錯誤(包括未給出信息、信息提示錯誤等)、長時間操作無進度提示、系統未優化(性能問題)、光標跳轉設置不好、鼠標(光標)定位錯誤等。
(4) 提示。提示性漏洞主要爲：界面格式等不規範、輔助說明描述不清楚、操作時未給出用戶提示、可輸入區域和只讀區域沒有明顯的區分標誌、個別不影響產品理解的錯別字、文字排列不整齊等一些小問題及建議。
三種糾錯技術
糾錯先要查錯。查錯的工作量通常佔整個糾錯的90%以上。下面介紹幾種常用的查明程序錯誤時可能採用的工具和手段，這些方法能明顯提高查錯的效率。
1) 插入打印語句
在程序中插入暫時性的打印語句，是一種十分常見的查錯技術。這類打印語句的作用主要是顯示程序的中間結果或有關變量的內容。插入打印語句適用於任何高級語言編寫的程序。
2) 設置斷點
查錯的基本技術之一，就是在程序的可疑區設置斷點。每當程序執行到設置的斷點時，就會暫停執行，以便糾錯者觀察變量內容和分析程序的運行狀況。
3) 掩蔽部分程序
對可疑程序進行檢查時，常常要讓程序反覆執行。如果整個程序較長，可疑區僅佔其中的一小部分，則每次運行整個程序必將浪費許多時間和精力。在這種情況下，往往將不需要檢查的程序掩蔽起來，只讓可疑的部分程序反覆運行。
掩蔽無關程序可使用下述方法：
(1) 在要掩蔽的語句行加上註釋符。
(2) 把要掩蔽的程序段置入“常假”的選擇結構中，使其無法執行。
5.軟件缺陷優先級：
描述缺陷必須被修復的緊急程度。通常劃分爲以下幾個級別:
6.軟件缺陷的類別
類別描述缺陷所屬的類型，以便查找對應開發人員，以及後期缺陷分析。類別通常可以分爲以下幾種情況:
7.軟件缺陷狀態
狀態用於跟蹤缺陷處理過程及當前所處階段，常用狀態有以下情況:
根據項目具體特徵和管理需求，可以適當增加或者精簡缺陷狀態。
8.軟件缺陷生命週期（重點）
-
一般的，測試人員識別缺陷，其初始狀態是“新建”;
-
項目經理或技術領導分析缺陷，分配給合適的開發人員來解決，狀態流轉爲“待解決”;
-
指定的工程師解決缺陷，將其狀態跟蹤到“已解決”;
-
測試人員迴歸該缺陷，如果迴歸通過，則關閉缺陷，如果迴歸不通過，則重新打開該缺陷( "Reopen"狀態)。
9.常見的軟件缺陷管理
10.缺陷管理常見的問題
-
缺陷無法重現怎麼辦?
-
缺陷太多怎麼辦?
-
找不到缺陷怎麼辦?
-
如何減少無效缺陷的提交?
-
如何防止重複缺陷重複提交?
-
測試和開發如何客觀有效的進行缺陷溝通?
1.6軟件質量與軟件測試相關特性
1.軟件質量特性：軟件質量度量方法有多種，可以進一步分爲靜態質量特性和動態質量特性。
-
靜態質量特性：靜態質量特性包括結構化的、可維護的、可測試的代碼以及正確而又完整的文檔。
-
動態質量特性：軟件動態質量特性包括正確性、可靠性、完整性、一致性、易用性、性能等。
-
動態質量特性—正確性
-
軟件正確性:如果軟件針對其輸入域中的每個元素都能得到預期的結果,則稱該軟件是正確的。
-
輸入域:對軟件P的所有可能輸入的集合被稱作P的輸入域，或者輸入空間。
-
正確性是想說明軟件是無錯的，這是我們所追求的一個良好的願望，但並不是軟件測試的目標。
-
-
動態質量特性-可靠性
-
定義一:軟件可靠性是指軟件在給定時間間隔和給定條件下無故障運行的概率。 ( ANSI/IEEE729- 1983)
-
這裏的概率依賴於程序輸入的分佈情況，這種輸入分佈經常被稱作操作剖面( operational profile) ，是對軟件使用方式的數值描述。
-
根據該定義，軟件的可靠性會因操作剖面的不同而不同，這就意味着某些用戶可能覺得“這個軟件很糟糕”，而也有某些用戶可能會覺得“軟件很好用”。
-
-
定義二:可靠性是指軟件在預期環境下無故障運行的概率，
-
這裏的環境是指軟件運行所需的硬件及軟件要素，包括硬件設備、操作系統以及其它必需的應用程序。
-
這個定義與“誰使用這個軟件以及如何使用軟件”無關，而只與軟件功能正確性相關。由於沒有操作剖面的定義，整個輸入域被認爲是均勻分佈的
-
-
對比
-
定義一需要了解用戶操作剖面，如果能夠準確建立某類用戶的操作剖面，那麼就能夠準確計算出軟件針對該類用戶的可靠性。但是，用戶操作剖面本身是很難準確評估的。
-
定義二只需要用單個數值來表示軟件可靠性，非常具有吸引力，但是這個數值要適用於所有的用戶，這本身是不現實的。
-
-
-
動態質量特性-易用性
-
定義：是指軟件使用的難易程度。其本身是一個研究領域，有大量技術可用於易用性測試，心理學在易用性測試設計中也扮演着重要的角色。
-
-
完整性
-
定義：指得到軟件需求規格說明書或者用戶手冊中所有功能的可能性
-
-
一致性
-
定義：指軟件對常規慣例和假設的遵循程度。例如，用戶界面中所有按鈕遵從統一的顏色編碼規定。
-
-
性能
-
定義：可以簡單理解爲軟件完成規定任務所花費的時間。例如，--個編譯系統的性能需求可能會用編譯一組數值計算程序所需的最少平均時間來描述。
-
-
2.軟件測試的複雜性
舉例:測試三角形程序
輸入3個整數a、b和c， 作爲三角形的3條邊，通過程序判斷由這3條邊構成的三角形類型是等邊三角形、等腰三角形還是一般三角形，並打印出相應的信息。
需要測試用例:
(1) 3數相等 (9)含有零數據
(2) 3數中有2個數相等，比如AB相等 (10)含有負整數
(3) 3數中有2個數相等，比如BC相等 (11)少於3個整數
(4)3數中有2個數相等，比如AC相等 (12)含有非整數
(5) 3數均不相等 (13)含有非數字符
(6) 2數之和不大於第3數，比如最大數是A (14)2數之和等於第3數
(7)2數之和不大於第3數，比如最大數是B (15)輸入3個零
(8)2數之和不大於第3數，比如最大數是C (16)輸入3個負數
黑盒測試的複雜性：
①測試所需要的輸入量太大
②測試的輸出結果太多
③軟件實現的途徑太多
④軟件規格說明沒有一個客觀標準
白盒測試的複雜性：
白盒測試方法將被測對象看做一一個打開的盒子，允許人們檢查其的內部結構。測試人員根據程序內部的結構特性，設計和選擇測試用例，檢測程序的每條路徑是否都按照預定的要求正確地執行。
那麼從A點走到B點的所有路徑數至少有5^20+5^19+...+5^1,這是一個天文數字。
窮舉路徑測試看起來它同窮舉輸入測試一樣是不現實的。即使程序中每條路徑都測試過了，仍不能保證程序沒有故障。
-
窮舉路徑測試不能保證程序實現符合規格說明的要求。例如，如果要求編寫升序排序程序，結果程序被錯誤地編寫成按降序程序。這時，窮舉路徑測試是毫無用處的。
-
窮舉路徑測試不可能查出程序中因遺漏路徑而出現的錯誤。
-
窮舉路徑測試可能發現不了有關數據的故障。
3.軟件測試的經濟性
E.W .Dijkstra的一句名言對測試的不徹底性作了很好的註釋:“軟件測試只能證明故障的存在，但不能證明故障不存在”
軟件測試的總目標是充分利用有限的人力和物力資源，高效率、高質量地完成測試。爲
了降低測試成本，選擇測試用例時應注意遵守測試的“經濟性”原則:
第一，根據程序的重要性和一旦發生故障將造成的損失來確定它的測試等級;
第二，認真研究測試策略，以便能開發出儘可能少的測試用例，發現儘可能多的軟件故障。
1.7軟件測試充分性和和測試停止標註
1.軟件測試的充分性
給定一個程序P,針對程序的需求R,我們設計了k個測試用例，形成測試用例集T，問:
T足夠好嗎?
T可以對程序P進行完全測試嗎?
T是充分的嗎?
等等。這些問題，都表達一個思想:人們總想完全測試程序P,以期望在測試結束進行交付的時候，P中所有的錯誤都被發現並修正了。
"充分性”就是用來度量一個給定的測試集T是否能驗證軟件P滿足其需求R。充分性度量是相對於具體的測試充分性準則C的。當一個測試集T滿足準則C時，即認爲T相對於C是充分的。相反，如果T不能完全滿足C，那麼就認爲用例集T對於C是不充分的。因此，確定程序P的測試集T是否滿足充分性準則C，是依賴於準則自身的。
例1:
考慮編寫程序sumProduct,其需求如下:
R1:從標準輸入設備上輸入兩個正數x和y。
R2.1:當x<y時，求x與y之和，並在標準輸出設備上輸出x與y之和。
R2.2:如果x>=y,求x與y之積，並在標準輸出設備上輸出x與y之積。
假設測試充分性準則C1爲:
如果針對需求R中的每一個需求r，測試集T中至少有一個測試用例測試證明了P滿足r，則認爲測試集T對於程序P的需求R是充分的。
給定測試集T={t: <x=2，y=3>}。顯然，相對於準則C1來講T是不充分的,因爲T中的測試用例只測試了R1,和R2.1，沒有測試R2.2。
覆蓋域
測試集的充分性評估是由一個有限集來度量，根據所依賴的充分性準則，有限集中的元素由軟件需求或者代碼導出。對於每一個測試準則C，我們都可以得到一個有限集，稱之爲覆蓋域Ce。如果覆蓋域Ce僅依賴於被測軟件的代碼，則稱準則C爲一個白盒測試充分性準則;如語句覆蓋、分支覆蓋、路徑覆蓋等。如果覆蓋域Ce僅依賴於被測軟件的需求，則稱準則C是一個黑盒測試充分性準則。其他的測試充分性準側可能是白盒與黑盒之間。
測試覆蓋率
給定測試集T,覆蓋標準C，覆蓋域Ce,假設Ce包含n個元素(n>=0),我們說T覆蓋Ce,是指對於Ce中的每一個元素e,在T中都至少有一個測試用例測試了它。如果T覆蓋了Ce中所有的元素，則稱T相對於C是充分的;如果T只覆蓋了Ce中的k(k<n)個元素，則稱T相對於C是不充分的。分數k</n代表了T對C的充分度，也稱爲T對於C，P以及R的覆蓋率
測試充分性準則C2
如果軟件P中的每一條路徑都被遍歷至少一次，則認爲測試集T針對(P,R)是充分的。對於例1中的需求，假設程序P有且只有兩條路徑，一條應對與條件x<y,一條對應與條件x>=y。這兩條路徑分別記作p1,p2。
針對準則C2,得到覆蓋域Ce= {p1, p2}
使用準測C2來度量測試集T ={t: <x=2, y=3>}
對C2的覆蓋率，對P執行T中的每一個測試用例，因爲p1被執行了，因此T對於C2，P, R的覆蓋率爲1/2=0.5，T相對於測試準則C2是不充分的。
除了基於被測軟件需求、控制流、數據流這樣一些常規測試充分性評價準則外，還有其它一些測試充分性評價技術也得到廣泛研究和應用，如符號執行、變異測試也是用於評價測試優良程度的有效技術，它爲測試評價和測試增強提供了較爲嚴格的準則。
2.軟件測試終止準則
軟件消亡之前，如果沒有測試結束標準,那麼軟件測試就永無休止。軟件測試終止條件需要依據項目具體情況來制定，般而言，其遵循以下終止準則:
1.基於測試階段的原則
每個軟件都經過單元測試、集成測試、系統測試這幾個測試階段，我們可以對單元測試、集成測試、系統測試製定各自具體的測試結束標準，當每個階段的測試結束標準都符合時，我們認爲該軟件達到測試停止標準。
2.基於測試用例的原則
測試設計人員設計測試用例，並請項目組成員參與用例評審，一旦評審通過，就可以作爲後面測試結束的一個參考標準。比如測試過程中如果發現測試用例通過率太低，可以拒絕繼續測試，待開發人員修復後再繼續。在比如可以制定功能測試用例通過率100%，非功能性
測試用例通過率達到95%以上，即可允許正常測試結束。該準則的關鍵在於測試用例質量的把握。
3.基於缺陷收斂趨勢及缺陷修復率原則
可以通過軟件缺陷的趨勢圖的走向，來定測試是否可以結束;缺陷修復率也是常用的一個指標，如嚴重級別錯誤和主要級別錯誤要100%修復，較小缺陷修復率達850以上。
4.基於驗收測試的原則
即項目通過驗收測試，並得到驗收測試通過結論，即可結束該項目的測試活動。
5.基於覆蓋率的原則
如需求覆蓋率達100%，測試用例執行覆蓋率達100%，單 元測試中語句覆蓋率不低於85%等這些準則在軟件測試活動中都是比較常用的。
6.軟件項目暫停或終止，則測試活動也應響應暫停或終止
如在開發生命週期內出現重大估算、進度偏差，需要暫停調整或者終止項目，那麼測試活動也隨之暫停或終止，並備份相應測試數據。
思 考 與 習 題
一、選擇題
1．軟件本身的特點和目前軟件開發模式使隱藏在軟件內部的質量缺陷不可能完全避免，在下列關於導致軟件質量缺陷的原因的描述中，不正確的是 （ C ） 。
A. 軟件需求模糊以及需求的變更，從根本上影響着軟件產品的質量
B. 目前廣爲採用的手工開發方式難於避免出現差錯
C. 程序員編碼水平低下是導致軟件缺陷的最主要原因
D. 軟件測試技術具有缺陷
2．缺陷產生的原因是( D )。
A. 交流不充分及溝通不暢；軟件需求的變更；軟件開發工具的缺陷
B. 軟件的複雜性；軟件項目的時間壓力
C. 程序開發人員的錯誤；軟件項目文檔的缺乏
D. 以上都是
二、判斷題
1. 缺乏有力的方法學指導和有效的開發工具的支持，往往是產生軟件危機的原因之一。( √ )
2. 目前的絕大多數軟件都不適合於快速原型技術。( √ )
3. 在程序運行之前沒法評估其質量。( × )
4.下列哪些活動是項目
探索火星生命跡象( √ )
向部門經理進行月工作彙報( × )
開發新版本的操作系統。( √ )
每天的衛生保潔。( × )
組織超級女聲決賽。( √ )
一次集體婚禮。( √ )
三、簡答題
1. 什麼是軟件？軟件發展經過了哪幾個階段？
答:軟件是一系列按照特定順序組織的計算機數據和指令的集合。-般來，講軟件北劃分爲系統軟件，應用軟件和介於着兩者之間的中間件。其中系統軟件爲計算機使用提供最基本的功能，但是並不是針對某一特定領域，而應用軟件則恰好相反，不同的應用軟件更根據用戶和所服務的領域提供不同的功能。
20世紀50年代初期至60年代中期是軟件發展的第一階段(又稱程序設計階段);
第二階段從20世紀60年代中期到70年代末期是程序系統階段。
第三階段稱爲軟件工程階段，從20世紀70年代中期到80年代中期，由於微處理器的出現，分佈式系統廣泛應用，以軟件的產品化，系列化，工程化和標準化爲特徵的軟件產業發展起來，軟件開發有了可以遵循的軟件工程化的設計原則，方法和標準。
第四階段是從20世紀80年代中期至今，客戶端/度武器(C/S)體 繫結構，特別是Web技術和網絡分佈式對象技術法飛速發展，導致軟件體系結構向更加靈活的多層分佈式結構演變，CORBA,EJB,COM/DCOM 等三大分佈式的對象模型技術相繼出現。
2. RUP是什麼？具有什麼特徵？
答:RUP(Rational Unified Process)，統一軟件開發過程，統一軟件過程是一個面向對象且基於網絡的程序開發方法論。
1.迭代式開發——較之瀑布式開發，迭代開發更能規避風險，更好的獲取用戶需求。
2.管理需求——需求是動態變化的，對需求的管理應貫穿軟件生命週期的所有環節。需求管理包括三個活動：獲取、組織並記錄需求；評估需求變化及其影響；跟蹤、記錄需求的變更相關的決策與權衡的理由。
3.應用基於構件的構架——軟件系統很複雜，不同干係人（stakeholder，例如：用戶、分析師、開發人員、集成人員、測試人員、項目經理等）對軟件有不同的視角。建立並維護軟件構件有利於管理不同的視角，從而在整個迭代週期內控制迭代的過程。 而基於構件的構架則由於其柔性的結構、對複用的支持被Rational認爲是最佳的實踐。
4.可視化的建模——複雜的軟件通過UML這樣的建模語言進行抽象和可視化不但能夠簡化溝通，而且也能簡化開發人員對系統的理解。
5.持續不斷的驗證軟件質量——缺陷越早被發現被解決就越節約成本，因此應該在整個軟件生命週期內不斷驗證質量。
6.控制軟件變更——多人、分佈式的開發，如果不能控制版本和變更，開發必然陷入混亂，變更的控制是項目有序進行的必要條件。
RUP是可以剪裁的，他包含針對不同項目特徵進行剪裁的指南。同時RUP也是不斷演化的，Rational不斷在發佈RUP的新版本。
4. 軟件質量框架是什麼？包括什麼內容？
答:第一部分是前提，說明了軟件框架的適用範圍，以及適合的環境，和方法學一樣，沒有泛之四海皆准的方法學,所以軟件質量框架也需要一個上下文環境。
第二部分是價值觀，價值觀說明了軟件質量框架中強調的價值，在軟件框架的結構和實踐中，都將充分的的表現出一開始我們定義的價值。
第三部分是結構。結構定義了軟件質量框架的組成部分，以及軟件質量框架和開發過程之間的關係。
第四部分是文章中着墨最多的部分，即優秀實踐。優秀實踐通過具體、實際的分析、舉例，深入闡述了軟件質量框架的價值觀和結構。
5. CMM是什麼？其具體內容是什麼？CMMI與CMM的關係是什麼？
答: CMM是由美國軟件工程學會(Software Engineering Institute)制定的一套專門針對軟件產品的質量管理和質量保證標準。該標準最初是爲美國軍方選擇軟件產品提供商時評價軟件企業的軟件開發質量保證能力而制定,所以稱爲軟件企業能力成熟度模型(Capability Maturity Mode簡稱CMM)。該標準將軟件企業的能力成熟度劃分爲5個等級,級別越高表明該企業在提供合格軟件產品方面的能力越強。
軟件過程包括管理過程(軟件項目策劃、軟件項目管理)、組織過程(跨項目過程、培訓、基礎設施)、工程過程(需求分析、設計、編碼、測試)。CMM分爲五個等級:一級爲初始級， 二級爲可重複級，三級爲已定義級，四級爲己管理級，五級爲優化級。成熟度反映了軟件過程能力的大小，任何一個軟件機構的軟件過程必定屬於其中某個級別。除了第一級以外,每級成熟度又由若干
關鍵過程域構成。CMM結構中關鍵實踐描述了對關鍵過程域有效實施和制定化起重要的作用的基礎設施和活動，有5個共同特徵:執行約定、執行能力、進行的活動、測量和分析、驗證實施。
CMM:軟件能力成熟度模型，是對組織軟件過程能力的描述。
CMMI:能力成熟度模型集成，目的是幫助軟件企業對軟件工程過程進行管理和改進,增強開發與改進能力，從而能按時地、不超預算地開發出高質量的軟件。CMMI模型的前身是SW-CMM和SE-CMM，前者就是我們指的CMM。
CMMI與SW-CMM的主要區別就是:
一、覆蓋了許多領域;到目前爲止包括四個下面領域: ( 1)、軟件工程( SW-CMM); (2)、 系統工程( SE-CMM); (3)、 集成的產品和過程開發(IPPD-CMM); (4)、 採購(SS-CMM)。
二、CMMI有兩種表示方法,一種就是與CMM一樣的階段式表現方法(把CMMI中的若千個過程區域分成5個成熟度級別);另一種是連續式的表現方法(將CMMI中過程區域分爲四大類:過程管理、項目管理、工程以及支持)。
三、CMM2級有6個關鍵過程區域,在CMMI中增加了一個:度量與分析;CMM4級有2個關鍵過程區域，在CMMI中也是2個，只是名稱與內容有所改變;在CMM5級中有3個KPA,在CMMI中合併了，改爲2個。最顯著還是在CMM3級中，原來的7個KPA改爲14個。
6. 軟件測試與軟件開發具有什麼關係？
答: 1、沒有軟件開發就沒有測試，軟件開發提供軟件測試的對象。
2、軟件開發和軟件測試都是軟件生命週期中的重要組成部分
3、軟件開發和軟件測試都是軟件過程中的重要活動。
4、軟件測試是保證軟件開發產物質量的重要手段。