四、軟體工程與軟體測試
4.1軟體工程簡介
4.1.1什麼是軟體工程
隨著軟體工程學科的發展，人們對計算機軟體的認識逐漸深入。軟體工作的範圍不僅僅局限在程序編寫，而是擴展到了整個軟體生命周期，如軟體基本概念的形成、需求分析、設計、實現、測試、安裝部署、運行維護，直到軟體被更新和替換新的版本。
軟體工程還包括很多技術性的管理工作，例如過程管理、產品管理、資源管理和質量管理，在這些方面也逐步地建立了標準活規範。
4.1.2軟體的生命周期
4.1.3軟體工程的研究領域
至少包括人員管理、項目管理、可行性分析、需求分析、系統設計、編碼、測試、質量管理和配置管理等。
4.1.4軟體工程的發展歷史
4.1.5軟體工程化概念的提出
20世紀60年代，「軟體危機」就已經出現。針對「軟體危機」，人們提出了軟體工程化的概念。軟體工程的概念首次出現在1968年的NATO（北大西洋公約組織）會議上。
4.1.6「軟體工程」
20世紀70年代，「軟體工廠」的概念出現，主要圍繞軟體過程和軟體復用展開研究，是軟體工程思想得到進一步的深化和提高。
這一時期主要提出了「面向對象」的編程思想，軟體測試在這一階段有了新的挑戰，尤其是單元測試方法的改變。
4.1.7軟體過程管理
軟體不是一個人研發出來的，而是一大幫人一起研發出來的，因此需要溝通、協作，需要大家遵循一定的流程和做事的方式，這就是「軟體過程」。
著名的「瀑布模型」嘗試從軟體過程的角度解決「軟體危機」。認為只要把軟體生命周期（軟體從「生」到「死」）按嚴格的階段劃分之後就能實現軟體開發過程的工程化：
4.1.8軟體過程相關方法和工具
圍繞著軟體過程，軟體專家們提出了各種具體的軟體過程實踐方法和思想，各大軟體廠商也提供了支持這些方法和思想的工具。
例如：微軟的VSTS（Visual Studio Team Suite）就是基於名為MSF（Microsoft Solution Framework）軟體過程的思想和方法的一套支持工具。
4.1.9軟體工程發展的新趨勢
敏捷軟體工程師哲學理念和一系列開發指南的綜合。
4.1.10軟體工程的目的
軟體工程的目的是提高軟體的質量和生成率，最終實現軟體的工業化生成。
4.2軟體開發模式
軟體開發模式是軟體工程研究的重要領域。軟體測試與軟體的開發模式息息相關。在不同的開發模式中，測試的作用有細微的差別，測試人員應該充分理解軟體的開發模式，以便找准自己在其中的位置和角色定位，以便於充分發揮測試人員的價值。
4.2.1常見的軟體開發模式
主要有以下3類：
線性模型、漸進式模型、變換模型。
4.2.2線性模型
最具代表性的是「瀑布模型」。
業界流行的說法是「集成之日就是爆炸之日」。
4.2.3漸進式模型
最具代表之一的是「螺旋模型」，這對於那些規模龐大、複雜度高、風險大的項目尤其適合。
增量開發能顯著降低項目風險，結合軟體持續構建機構，構成了當今流行的軟體工程最佳實踐之一。
增量開發模型，鼓勵用戶反饋，在每個迭代過程中，促使開發小組以一種循環的、可預測的方式驅動產品的開發。
目前很多軟體過程所說的迭代開發，實際上都是增量開發和迭代開發的結合。
4.2.4變形模型
註：在每一次迭代原型出來後，測試人員都需要從原型界面、系統主要功能、性能等方面對原型進行評審。
4.2.5軟體開發模式的發展
4.2.6RUP的歷史
業界普遍認為，開發負責的軟體項目必須採用基於UML的、以架構為中心的、用例驅動與風險驅動相結合的迭代式增量開發過程，這一過程通常被稱為RUP（Rational Unified Process，Pational統一過程）。
為什麼叫Rational統一過程呢？這就要從RUP的創始人Ivar Jacobson講起了。
現代軟體開發之父Ivar Jacobson博士被認為是深刻影響或改變了整個軟體工業開發模式的幾位世界級大師之一。他是模塊和模塊結構、用例、現代業務工程、Rational統一過程等業界主流方法、技術的創始人。Ivar Jacobson博士與Grady Booch和James Rumbaugh一道共同創建了UML建模語言，被業界譽為UML支付。Ivar Jacobson的用例驅動方法對整個OOAD行業影響深遠，他因此而成為業界的一面「旗幟」。
1987年，Ivar Jacobson離開愛立信公司，創立了Object System公司，吸納了增量迭代思想，開發出Objectory過程。
1991年，愛立信收購了Object System。
1995年，Rational公司又從愛立信收購了Objectory ，Jacobson 與Grady Booch、James Rumbaugh一起開發了UML，這期間Objectory過程逐漸進化為Rational統一過程（RUP）。
2003年，IBM收購了Rational公司。
4.2.7RUP過程模型下的軟體測試
強調6項最佳實踐：
（1）迭代地開發軟體（Develop Iteratively）。
（2）管理需求（Manage Requirements）。
（3）應用基於構件的構架（Use Component Architectures）。
（4）為軟體建立可視化的模型（Model Visually,UML）。
（5）不斷地驗證軟體的模型（Continuously Verify Quality）。
（6）控制軟體的變更（Manage Change）。
4.2.8RUP工具
IBM Rational 提供了RUP相關支持工具。
4.2.9「重型」過程VS.「輕量」過程
由於以RUP為代表的統一過程在很多時候過於煩瑣，實施成本太高，並且對需求的變化反映不夠敏捷，因此，敏捷過程越來越受歡迎。
敏捷過程是一系列輕量的過程模型的總稱，其代表是XP（極限編程）模型。
RUP將系統開發分為若干次迭代，每次迭代都包括需求、分享、設計、實現、測試等工作流。每個工作流都規定了輸入工件、輸出工件、參與角色、工作流的具體活動內容。
RUP被稱為重型軟體過程模型，它包含幾十個角色、上千份文檔製品、並和Rational的系列工具緊密結合。這樣的重量級過程被業界戲稱為「大象」級過程，考慮到成本因素，一般小型的軟體團隊很難遵循這樣的過程。
4.2.10敏捷運動
2001年，以Kent Beck、Alistair Cockburn、Ward Cunningham、Martin Fowler等人為首的「輕量」過程派聚集在猶他州的Snowbird，決定把「敏捷」（Agile）作為新的過程家族的名稱。
在會議上，他們提出了《敏捷宣言》。
4.2.11極限編程（XP）
基於敏捷的核心思想和價值目標，XP要求項目團隊遵循13個核心實踐：
團隊協作（Whole Team）、規劃策略（Planning Game）、結對編程（Pair Programming）、測試驅動開發（Test-Driven Development）、重構（Refactoring）、簡單設計（Simple Design）、代碼集體所有權（Collective Ownership）、持續集成（Continuous Integration）、客戶測試（Customer Tests）、小型發布（Small Releases）、每周40小時工作制（40-Hour Week）、編碼規範（Coding Standard）、隱喻（Metaphor）。
4.2.12XP中軟體測試
XP強調測試先行，以單元測試驅動開發過程的實踐，因此良好的測試思維和單元測試技術是這一實踐的基礎。
XP強調小版本迭代開發、重構和持續集成，因此對於測試的頻率提出了更高的要求，需要測試與開發的緊密協作，以及高效率的測試執行（例如自動化的測試）。
4.2.13XP工具
包括XP計劃、性能測試、構建工具、驗收測試工具、單元測試工具等。
4.3不同軟體開發模式下的軟體測試
按照軟體工程的兩大流派，可以分成「流程派」和「個體派」。「流程派」以CMM和ISO為代表，強調按既定的流程工作。
「個體派」以新興的敏捷開發為代表，強調人在過程中發揮的價值。
4.3.1CMM和ISO中的軟體測試
「流程派」強調形式文檔的制度、規範和模板，嚴格按照制度辦事，按照要求形成必要的記錄，檢查、監督和持續改善。因此測試人員在實施這樣的流程改進方式的組織中工作，需要注意按照測試流程定義的模板進行，填寫必要的測試記錄和報告，度量測試的各個方面是否符合要求。
4.3.2CMM與軟體測試
4.3.3ISO與軟體測試
ISO 9000質量標準體系在20世紀70年代由歐洲首先採用的，後來在美國和世界各地迅速發展起來。很多企業都熱衷於ISO認證。
ISO基於PDCA的循環提出了測量、分析和改進的重要性，使用測試作為軟體測量的重要手段。它要求測試人員得到有關授權才能進行測試活動，應該得到充分的培訓和指導，確保測試人員有足夠的能力對軟體產品進行測試。
ISO非常強調缺陷的控制，包括對缺陷的修改進行回歸測試和驗證，對缺陷進行分析和評審，確保缺陷在交付使用前得到控制，並確保對缺陷指定了糾正預防措施，形成預防機制，防止缺陷的再次出現。
軟體企業使用ISO進行過程管理和改進應該參考ISO 9000-3標準。主要內容：合同評審、需求規格說明、開發計劃、質量計劃、設計和實現、測試和確認、驗收、複製 交付和安裝、維護。
需要注意的是ISO 9000-3是指南，而不是認證的準則。
4.3.4敏捷開發中的軟體測試
在敏捷開發中，測試是整個項目組「車頭燈」，它告訴大家現在到哪了，正在往哪個方向走。測試員為項目組提供豐富的信息，使項目組基於這些可靠的信息做出正確的決定。
在敏捷項目中，測試人員不再做出發布的決定。不只是有測試員來保證質量，而是由整個項目組中的每一個人對質量負責。測試員不再跟開發人員糾纏錯誤，而是幫助開發人員找到目標。
敏捷測試需要更多地考慮的內容：
更多地採用探索性測試方法。
更多地採用上下文驅動的測試方法論。
更多地採用敏捷自動化測試原則。
敏捷測試認為要持續地測試，不斷地回歸測試，快速測試。測試人員需要多借鑒上下文驅動測試的方法，適當採用自動化的方式加快測試的速度。
2.快速啟動Excel
如果想在啟動系統自動運行Excel，可以這樣操作:
1.雙擊「我的電腦」圖標，進入Windows目錄，依次打開「Start MenuPrograms啟動」文件夾;
2.打開Excel所在的文件夾，用滑鼠將Excel圖標拖到「啟動」文件夾，這時Excel的快捷方式就被複制到「啟動」文件夾中，下次啟動Windows就可快速啟動Excel了。
如果Windows系統已啟動，你可用以下方法快速啟動Excel:
方法一:單擊「開始→文檔」命令里的任一Excel工作簿即可。
方法二:用滑鼠從「我的電腦」中將Excel應用程序拖到桌面上，然後從快捷菜單中選擇「在當前位置創建快捷方式」，以後啟動時只需雙擊快捷方式即可。
TAG:Smpidus之TDT |