項目五軟件實現任務一軟件編碼

任務二軟件測試

任務一軟件編碼

什么是程序？程序是用程序設計語言表示的計算機解題算法或計算機解題任務。什么是程序設計呢？程序設計是將解題任務轉變成程序的過程。NellDale等人則指出：程序就是要求計算機執行的指令序列，程序設計就是如何計劃、安排計算機必須遵循的操作步驟順序的過程。

編碼就是把軟件設計結果翻譯成用某種程序設計語言書寫的程序。編碼是對設計的進一步具體化。編碼過程中所選用的程序設計語言的特點及編碼風格，將對程序的可靠性、可讀性、可測試性和可維護性產生深遠的影響。軟件測試是在軟件投入生產性運行之前，運用科學的方法盡可能多地發現軟件中存在的錯誤。它是保證軟件質量的關鍵步驟，它是對軟件規格說明、設計和編碼的最后復審。而通過測試發現錯誤并不是最終目的，還必須診斷并改正錯誤，這就是調試。調試是測試階段最困難的工作。統計資料表明，軟件測試的工作量往往占軟件開發總工作量的40%以上，在極端情況下，可能更多。因此，必須高度重視軟件測試工作，絕不要以為寫出程序之后軟件開發工作就接近完成了。

通常把編碼和測試統稱為實現。在計算機科學與技術學科中，程序設計語言是每一位希望步入這門信息科學最主要的基礎學科光輝殿堂的學生首先要學習的課程之一。伴隨著計算機的產生和發展，程序設計語言也歷經約半個世紀的滄桑歲月。自從1957年FORTRAN語言問世以來，人類已經創造了數以百計的各種各樣的程序設計語言，它們又被籠統地稱為計算機語言或者高級語言。在這些程序設計語言中，有些曇花一現，有些流傳至今，如FORTRAN、COBOL、BASIC、Pascal、C、Ada、C++、Java、ML等至今仍然被人們用于科學計算、商業服務、教學研究、網絡應用等各個領域。了解什么是程序設計語言，了解程序設計語言的各個發展階段以及這些階段又有哪些代表性的程序設計語言，了解這些特定的程序設計語言的產生、發展歷史和演變狀況，這些對于學習程序設計語言來講是非常必要的。

嚴格說來，計算機語言包括機器語言、匯編語言和高級語言這三類語言。如果不涉及匯編語言，程序設計語言往往就是指高級語言。從某種意義上講，計算機語言從機器語言發展到匯編語言，標志著人類與計算機首次有了基于符號的共同語言，即這種語言(匯編語言)是人類(借助助記符)和計算機(借助匯編程序)都能夠理解的語言，它也是人類將符號引入程序設計的開始。由于匯編語言與機器的指令系統直接相關，不同指令系統的計算機有著不同的匯編語言，因此，在匯編語言中數據類型和數據結構具有典型的面向機器的特點，如：用DB、DW、DD等分別定義字節、字和雙字，用標號來定義符號地址。匯編語言缺乏類似數學語言那樣面向問題的數據類型，使得編程者要具備比較好的計算機硬件基礎才能進行匯編語言程序設計，這無疑限制了計算機的廣泛使用和發展。高級語言從產生之日起，就將面向問題的數據類型的概念引入程序設計，通過將數據分類成為字符型、整型、浮點型等不同的類型，來刻畫、描述不同類型的數據。從某種意義上講，從匯編語言到高級語言的發展過程，是人類在程序設計方面從面向機器的數據類型向面向問題的數據類型—或從沒有面向問題的數據類型向有面向問題的數據類型——的一次飛躍。而高級語言的產生、發展、演變，及各種各樣高級語言的興起，實質上就是高級語言數據類型的不斷完善、不斷擴充、不斷復雜化和多樣化以及對客觀實體描述能力不斷增強的一個過程。

機器語言是機器指令的集合。機器指令指計算機的CPU能夠識別并處理的二進制代碼，由這些二進制代碼組成的二進制代碼串稱為機器程序。以把立即數5傳送到累加器的操作為例，在以80X86為CPU的計算機中的二進制代碼是B80005，在以Z80為CPU的計算機中的二進制代碼是3E05。匯編語言是一種使用助記符的語言。助記符是一些縮寫的英文單詞，這些縮寫的英文單詞都有特定的操作含義，如MOV或LD表示傳送，ADD表示加法運算等。因此，匯編語言是一種面向機器的計算機語言。用匯編語言編寫的程序稱為匯編語言程序或源程序。將匯編語言程序翻譯成機器語言程序(也稱為目標程序)的程序稱為匯編程序。仍以把立即數5傳送到累加器的操作為例，在以80X86為CPU的計算機中的匯編語言程序是：MOVAX，5。而在以Z80為CPU的計算機中的匯編語言程序是：LDA，5。如果認為高級語言就是我們所要討論的程序設計語言，那么，什么是程序設計語言？正如將物體向不同平面投影可以得到不同的平面圖形一樣，不同的人從不同的角度對程序設計語言有不同的理解：計算機的使用者認為程序設計語言是操縱計算機的工具，程序員則認為它是程序員之間的相互通信和交流的方法，喜歡數學和算法的人則認為它是算法的符號表示。按照RaviSethi的觀點，一門通用的程序設計語言應該是能夠為各種各樣的用戶提供服務的語言。盡管對程序設計語言的理解和定義多種多樣，但是按照一般比較流行的觀點，可以認為：程序設計語言是由一些符號所構成，這些符號被用于定義、組織并完成各種各樣的計算任務。

操作一程序設計語言概述

人類所使用的語言稱為自然語言，它是以語音為物質外殼、以詞匯為建筑材料、以語法為結構規律而構成的體系。與此類似，程序設計語言是以具有特定語義的符號為基本構成單位，以語法為程序構成規律，專門用于定義、組織并完成各種各樣的計算任務而形成的體系。程序設計語言是程序設計的基礎，了解程序設計語言的特點、分類、選擇原則，對于學習程序設計是非常必要的。

1．程序設計語言的組成

程序設計語言的基本成分包含數據成分、運算成分、控制成分、函數。

數據成分是程序語言的數據類型。數據是程序操作的對象，包括常量和變量、全局量和局部量。數據類型有基本類型(如整型、字符型等)、特殊類型(如空類型)、構造類型(如數組、結構、聯合)、指針類型等。

運算成分指明允許使用的運算符號及運算規則，一般包括算術運算、關系運算、邏輯運算。

控制成分指明語言允許表述的控制結構，包括順序結構、選擇結構和循環結構。參見教材中講述的C(C++)提供的控制語句。函數是程序模塊的主要成分，是一段具有獨立功能的程序。函數的使用涉及3個概念：函數定義、函數聲明和函數調用。函數調用時實參與形參之間交換信息的方法有傳值調用和引用調用兩種。

2．程序設計語言的分類

程序設計語言是指用來書寫計算機程序的語言，是人與計算機進行信息通訊的工具。

程序設計語言目前多達上千種，常用的也有幾十種。眾多的程序設計語言如何進行分類，目前眾說紛紜，多數人認為程序設計語言分為四大類：面向機器的語言、面向過程的語言、面向對象的語言和面向問題的語言。

1)面向機器的語言

面向機器的語言是針對特定的計算機而設計的語言，是不能獨立于機器的語言。如機器語言和匯編語言。

機器語言也稱為低級語言，是用二進制代碼表示的計算機能直接識別和執行的一種機器指令的集合。它是計算機的設計者通過計算機的硬件結構賦予計算機操作功能的一種語言。機器語言具有靈活、直接執行和速度快等特點。用機器語言編寫程序，編程人員首先要熟記所用計算機的全部指令代碼和代碼的涵義。手編程序時，程序員得自己處理每條指令和每一數據的存儲分配和輸入輸出，還得記住編程過程中每步所使用的工作單元處在何種狀態。這是一件十分繁瑣的工作。編寫程序花費的時間往往是實際運行時間的幾十倍或幾百倍，而且，編出的程序全是些0和1的指令代碼，直觀性差，還容易出錯。除了計算機生產廠家的專業人員外，絕大多數的程序員已經不再去學習機器語言了。

為了擺脫機器語言編程的困難，20世紀50年代初期，基于助記符的程序設計語言—匯編語言問世。程序員可以通過諸如MOV、ADD、SUB等以縮寫英文單詞為助記符的方式來表示傳送、加、減等的操作。直到1956年FORTRAN問世以前，匯編語言是唯一的一種程序設計語言。在這個階段，建立了程序設計中子程序以及早期數據結構方面的基礎概念。匯編語言的實質和機器語言是相同的，都是直接對硬件進行操作，只不過指令采用了英文縮寫的標識符，更容易識別和記憶。它同樣需要編程者將每一步具體的操作用命令的形式寫出來。匯編程序通常由三部分組成：指令、偽指令和宏指令。匯編程序的每一句指令只能對應實際操作過程中的一個很細微的動作，例如移動、自增，因此匯編源程序一般比較冗長、復雜、容易出錯，而且使用匯編語言編程需要有更多的計算機專業知識。但匯編語言的優點也是顯而易見的，用匯編語言所能完成的操作不是一般高級語言所能夠實現的，而且源程序經匯編生成的可執行文件不僅比較小，而且執行速度很快。

2)面向過程的語言

從1956年到1984年近30年間，面向過程的程序設計語言取得了巨大發展，它是當時程序設計的主要工具。面向過程的語言適用于各種計算機并能解決各種題目的語言，它是獨立于機器的。使用面向過程的語言，用戶不僅要告訴計算機“做什么”，而且還要告訴計算機“如何做”，需要詳細地描述解題過程，因此稱為面向過程的語言，即為過程化語言，如Pascal語言、C語言、ADA語言等。

FORTRAN的全稱是FormulaTranslation，是一種編程語言。它是世界上最早出現的計算機高級程序設計語言，廣泛應用于科學和工程計算領域。FORTRAN語言接近數學公式的自然描述，在計算機里具有很高的執行效率，以其特有的功能在數值、科學和工程計算領域發揮著重要作用。

COBOL(CommonBusinessOrientedLanguage)是數據處理領域應用最為廣泛的程序設計語言，是第一個廣泛使用的高級編程語言。在企業管理中，數值計算并不復雜，但數據處理信息量卻很大。為專門解決企業管理問題，1959年，由美國的一些計算機用戶組織設計了專用于商務處理的計算機語言COBOL，并于1961年由美國數據系統語言協會公布。經不斷修改、豐富完善和標準化，目前COBOL已發展為多種版本。

Pascal是一種計算機通用的高級程序設計語言。它由瑞士NiklausWirth教授于60年代末設計并創立。以法國數學家命名的Pascal語言現已成為使用最廣泛的基于DOS的語言之一，其主要特點有：嚴格的結構化形式，豐富完備的數據類型，運行效率高，查錯能力強。

C語言是一種通用的、面向過程式的編程語言，廣泛用于系統與應用軟件的開發。于1969年至1973年間，為了移植與開發UNIX操作系統，由丹尼斯·里奇與肯·湯普遜，以B語言為基礎，在貝爾實驗室設計、開發出來的，因為具有高效、靈活、功能豐富、表達力強和較高的可移植性等特點，在程序員中備受青睞，2000年起成為使用最為廣泛的編程語言。C語言是結構式語言，其顯著特點是代碼及數據的分隔化，即程序的各個部分除了必要的信息交流外彼此獨立，這種結構化方式可使程序層次清晰，便于使用、維護以及調試。C語言是以函數形式提供給用戶的，這些函數可方便地調用，并具有多種循環、條件語句控制程序流向，從而使程序完全結構化。C語言的適用范圍廣泛，適合于多種操作系統，如Windows、DOS、UNIX等，也適用于多種機型。C語言對編寫需要進行硬件操作的場合，優于其他高級語言，有一些大型應用軟件也是用C語言編寫的。

Ada是一種表現能力很強的通用程序設計語言，它是美國國防部為克服軟件開發危機，耗費巨資，歷時近20年研制成功的。它被譽為第四代計算機語言的成功代表。與其他流行的程序設計語言不同，它不僅體現了許多現代軟件的開發原理，而且將這些原理付諸實現。因此，Ada語言的使用可大大改善軟件系統的清晰性、可靠性、有效性、可維護性。Ada語言的重要特征就是其嵌入式風格、模塊化設計、編譯檢查、平行處理、異常處理及泛型編程。Ada在1995年加入了對面向對象設計的支持，包括動態分配等。

3)面向對象的語言

從1985年迄今，是面向對象的程序設計語言的產生和發展階段。面向對象語言借鑒了20世紀50年代的人工智能語言LISP，引入了動態綁定的概念和交互式開發環境的思想,同時借鑒了始于20世紀60年代的離散事件模擬語言SIMULA67,引入了類的要領和繼承，其最終成形于20世紀70年代的Smalltalk。面向對象語言的發展有兩個方向：一種是純面向對象語言，如Smalltalk、EIFFEL、Java、C#等；另一種是混合型面向對象語言，即在過程式語言及其他語言中加入類、繼承等成分，如C++、Objective-C等。

Java是一種可以撰寫跨平臺應用軟件的面向對象的程序設計語言，是由SunMicrosystems公司于1995年5月推出的Java程序設計語言和Java平臺(即JavaEE、JavaME、JavaSE)的總稱。Java自面世后就非常流行，發展迅速，對C++語言形成了有力沖擊。Java技術具有卓越的通用性、高效性、平臺移植性和安全性，廣泛應用于個人PC、數據中心、游戲控制臺、科學超級計算機、移動電話和互聯網，同時擁有全球最大的開發者專業社群。在全球云計算和移動互聯網的產業環境下，Java更具備了顯著優勢和廣闊前景。Java是一種簡單的、跨平臺的、面向對象的、分布式的、解釋的、健壯的、安全的、結構的、中立的、可移植的、性能很優異的多線程的、動態的語言。當1995年SUN推出Java語言之后，全世界的目光都被這個神奇的語言所吸引。

C++是在C語言的基礎上開發的一種集面向對象編程、泛型編程和過程化編程于一體的編程語言。它應用較為廣泛，是一種靜態數據類型檢查的、支持多重編程的通用程序設計語言。它支持過程化程序設計、數據抽象、面向對象設計、制作圖標等多種程序設計風格。C++語言的主要特點表現在兩個方面，一是盡量兼容C，二是支持面向對象的方法。它保留了C的簡潔、高效的接近匯編語言的特點，同時對C的類型系統進行了改革的擴充，因此C++比C更安全，C++的編譯系統能檢查出更多的類型錯誤。另外，由于C語言的廣泛使用，因而極大地促進了C++的普及和推廣。

4)面向問題的語言

面向問題的語言也是獨立于計算機的語言，利用這種語言解題，不僅擺脫了計算機內部邏輯的限制，而且不必關心問題的解法和解題的過程，只需要指出問題、輸入數據和輸出形式，就能得到所需要的結果。面向問題的語言與面向過程的語言之間的區別就是不需要告訴計算機“如何做”，即不需要描述解題過程。因此，面向問題的語言又稱為非過程化語言或陳述性語言，如報表語言、判定語言、SQL(StructuredQueryLanguage)語言等。

SQL語言是數據庫查詢和操縱語言，也是一種程序設計語言，可直接使用數據庫管理系統，用于存取數據以及查詢、更新和管理關系數據庫系統，同時也是數據庫腳本文件的擴展名。SQL是高級的非過程化編程語言，允許用戶在高層數據結構上工作，它不要求用戶指定對數據的存放方法，也不需要用戶了解具體的數據存放方式，所以具有完全不同底層結構的不同數據庫系統，可以使用相同的SQL作為數據輸入與管理的接口。SQL語句可以嵌套，這使它具有極大的靈活性和強大的功能。

3．程序設計語言的選擇

選擇程序設計語言是軟件編碼階段必須考慮的一個關鍵問題。程序設計語言的選擇需要根據組織和項目的實際情況做出選擇，這里給出幾個原則和依據：

(1)系統的應用領域。

(2)系統用戶的要求。

(3)軟件的執行環境。

(4)目標系統的性能要求。

(5)程序員的知識水平。

(6)軟件的可移植性。

(7)工程規模。

操作二編碼規范

編碼規范是軟件公司制訂的一套統一標準的代碼編寫規則，用于規范開發人員在軟件編碼中的代碼編寫。優秀的程序員在代碼編寫中應該注意執行編碼規范。

編碼規范的重要性包括：

(1)促進團隊合作。一個項目大多都是由一個團隊來完成，如果沒有統一的編碼規范，那么每個人的代碼必定會風格迥異。即使是分工十分明晰、同一模塊不由多個人同時開發的情況，整合代碼時也會問題重重。大多數情況下，并非程序中有復雜的算法或是復雜的邏輯，而是不同人員的不同代碼風格導致代碼可讀性大大降低。統一的風格可使代碼可讀性大大提高，顯然地，規范的代碼在團隊的合作開發中是非常有益而且必要的。

(2)降低維護成本。隨著項目經驗的累積，會越來越重視后期維護的成本，而開發過程中的代碼質量直接影響著維護的成本，因此，我們不得不從開發時便小心翼翼。在上文中曾提到，規范的代碼大大提高了程序的可讀性，因此可讀性高的代碼維護成本必然會大大降低。但是，維護工作不僅僅是讀懂原有代碼，還需要在原有代碼基礎上作出修改，統一的風格有利于長期的維護。另外，好的代碼規范會對方法的度量、類的度量以及程序耦合性作出約束，這樣就不會出現需要修改一個上千行的方法或者去擴展一個沒有接口的類的情況。規范的代碼對程序擴展性的提高，無疑也是對維護人員的極大便利。

(3)有助于代碼審查。代碼審查可以及時糾正一些錯誤，而且可以對開發人員的代碼規范作出監督，團隊的代碼審查同時也是一個很好的學習機會，對成員的進步也是很有益的。但是，開發隨意的編碼加重了審查的工作量及難度，并且使得代碼審查工作沒有根據，浪費了大量的時間卻收效甚微。編碼規范不僅使得開發統一，減少審查工作量，而且讓代碼審查有據可查，大大提高了審查效率和效果，同時代碼審查也有助于編碼規范的實施。

操作三編碼工具

編碼工具是用于輔助程序員用某種程序設計語言編制源程序，并對源程序進行翻譯，最終轉換成可執行的代碼的工具軟件。

1．IDE開發工具

IDE，即IntegratedDevelopmentEnvironment，是“集成開發環境”的英文縮寫，是一類可以輔助開發程序的應用軟件，一般包括代碼編輯器、編譯器、調試器和圖形用戶界面工具，就是集成了代碼編寫功能、分析功能、編譯功能、debug功能等的開發軟件套，所有具備這一特性的軟件或者軟件套(組)都可以叫做IDE。如微軟的VisualStudio系列，Borland的C++Builder、Delphi系列等。該程序可以獨立運行，也可以和其他程序并用，例如，BASIC語言在微軟辦公軟件中可以單獨使用，也可以在微軟Word文檔中編寫WordBasic程序。IDE為用戶使用VisualBasic、Java和PowerBuilder等現代編程語言提供了方便。不同的技術體系有不同的IDE。比如可以稱為C++、VB、C#等語言的集成開發環境，所以可以叫做IDE。同樣，Borland的JBuilder也是一個IDE，它是Java的IDE。ZendStudio、EditPlus、UltraEdit每個都具備基本的編碼、調試功能，所以每一個都可以稱做IDE。

IDE多被用于開發HTML應用軟件。例如，許多人在設計網站時使用IDE(如HomeSite，DreamWeaver，FrontPage等)，因此很多項任務可自動生成。IDE除集成了代碼編輯、代碼生成、界面設計、調試、編譯等功能外，目前還融合了建模功能。

2．配置管理工具

軟件配置管理(ConfigurationManagement)是通過技術或行政手段對軟件產品及其開發過程和生命周期進行控制、規范的一系列措施。常用的配置管理工具有：VSS，SVN，Clearcase等。

任務二軟件測試

操作一軟件測試概念

1．軟件測試定義

比較常見的兩種對軟件測試的定義為：

(1)軟件測試是為了發現錯誤而執行程序的過程。

(2)軟件測試是根據軟件開發階段的規格說明和程序的內部結構而精心設計的一批測試用例(即輸入數據及預期的輸出結果)，并利用這些測試用例去運行程序，以發現錯誤的過程。綜上，軟件測試就是在受控制的條件下對系統或應用程序進行操作并評價操作結果的過程。也就是說，如果用戶面對著應用程序的A界面，在使用硬件B的時候做C操作，那么D結果應該出現。所謂受控制的條件應該包括正常條件和非正常條件。在測試中，應該故意地去促使錯誤的發生，也就是事情在不該出現的時候出現或者在應該出現的時候沒有出現。從本質上說，軟件測試是“探測”。

在如何明確質量保障和軟件測試的責任方面，各個機構有不同的做法，這取決于該機構的大小和該機構的商務結構。有時候，該工作由一個小組或者個人來負責。常見的辦法是項目組包括了測試人員和開發人員，他們在一起合作工作，由項目負責人來對質量保障進行總負責。

2．軟件測試術語

軟件質量(SWQuality)：軟件的功能和性能滿足用戶需要的程度。

軟件Build：用于測試的軟件中間版本程序。

軟件缺陷(SWDefect/Bug/Error)：軟件的功能/性能/界面/文檔與軟件需求文檔和用戶的需要不一致的現象。

軟件缺陷生命周期(SWDefectLifecycle)：包括報告、確認、修正、驗證、關閉等階段。

測試用例(TestCase)：包含輸入條件、執行步驟和測試期望的正確結果的文檔。

缺陷跟蹤系統(DTS)：管理軟件缺陷的整個生命周期的工具。靜態測試與動態測試(StatisticTestingAndDynamicTesting)：不執行/執行程序進行的測試。

白盒測試與黑盒測試(WhiteBoxTestingandBlackBoxTesting)：測試軟件代碼結構的測試；不關心軟件代碼結構，以軟件輸入和輸出來測試軟件功能的測試。

回歸測試與冒煙測試(RegressionTestingAndSmokeTesting)：在新的軟件Build上驗證修正的缺陷是否不再現；在大規模測試前，快速執行的基本功能測試。

軟件里程碑(SWMilestone)：軟件項目開發的各個關鍵過程。

3．軟件測試的目的與局限性

1)軟件測試的目的與原則

目的(如圖5-1所示)：

(1)尋找軟件的缺陷(Bug)；

(2)跟蹤修正軟件缺陷(Bug)；

(3)驗證修正的軟件缺陷(Bug)。

原則：

(1)盡早進行軟件測試，以在早期發現和報告軟件缺陷；

(2)全程測試，測試過程貫穿于整個項目的生命周期；

(3)測試獨立于開發，開發人員不能測試自己的軟件；

(4)軟件的缺陷驅動開發(基本代碼完成后愈加明顯)。圖5-1軟件測試的目的

2)軟件測試的局限性

(1)不可能完全測試一個程序。完全測試一個程序意味著在測試結束時，再也沒有未發現的軟件錯誤。而不可能完全測試一個程序的原因如下：

①可能的輸入范圍太大，根本無法窮盡測試；

②程序中可運行的路徑太多，根本無法窮盡測試；

③用戶界面問題(及相應的設計問題)太復雜，不可能進行完全測試。

(2)不可能測試到程序對任何可能輸入的響應。

若要測試程序對任何可能輸入的響應，對程序必須執行的測試有以下幾種：

①要對所有有效的輸入進行測試；

②要對所有無效的輸入進行測試；

③要對所有編輯過的輸入進行測試；

④要對所有輸入時機的變化情況進行測試。

由上可知，程序通過輸入可以接收的可能值非常之多，因此無法測試到程序對任何可能輸入產生的響應。

(3)不可能測試到程序每一條可能的執行路徑。如狀態之間變化。

(4)無法找出所有設計錯誤。如規格說明“2?+?2?=?5”。思考與討論：

軟件測試就是敲敲鍵盤、動動鼠標，很容易，誰都能干。

軟件測試很難，無法保證測試有效性。

軟件開發完成后再進行軟件測試。

軟件發布后如果發現質量問題，那是軟件測試人員的錯。

軟件自動測試效率高，將取代軟件手工測試。

軟件測試是測試人員的事情，與程序員無關。

項目進度吃緊時少做些測試，時間富裕時多做測試。

軟件測試是沒有前途的工作，只有程序員才是軟件高手。

4．軟件測試類型

按照比較的方式，一般把測試分為靜態測試與動態測試，白盒測試與黑盒測試等。另外，常見的軟件測試類型還有：

BVT(BuildVerificationTest)是在所有開發工程師都已經檢入自己的代碼、項目組編譯生成當天的版本之后進行，主要目的是驗證最新生成的軟件版本在功能上是否完整，主要的軟件特性是否正確，如無大的問題，就可以進行相應的功能測試。BVT的優點是時間短，驗證了軟件的基本功能；缺點是該種測試的覆蓋率很低，因為運行時間短，不可能把所有的情況都測試到。

ScenarioTests，即基于用戶實際應用場景的測試。在做BVT、功能測試的時候，可能測試主要集中在某個模塊，或比較分離的功能上。而當用戶使用這個應用程序的時候，各個模塊是作為一個整體來使用的，那么在做測試的時候，就需要模仿用戶真實的使用環境，即：用戶會有哪些用法，會用這個應用程序做哪些事情，操作會是一個怎樣的流程。加了這些測試用例后，再與BVT、功能測試配合，就能使軟件整體都能符合用戶使用的要求，這就是ScenarioTests。ScenarioTests的優點是關注了用戶的需求，缺點是有時候難以模仿用戶真實的使用情況。

SmokeTest，是在測試中發現問題(Bug)后，由開發人員修復Bug，隨后為明確修復是否真的解決了程序的Bug或者是否會對其他模塊造成影響，而針對此問題進行的專門測試。在很多情況下，做SmokeTest的原因是開發人員在試圖解決一個問題的時候，可能只集中考慮了一開始的那個問題，而忽略了其他的問題，這就可能引起新的Bug，造成了其他功能模塊一系列的連鎖反應。SmokeTest的優點是節省測試時間，防止build失敗，缺點是覆蓋率還是比較低。此外，常見的軟件測試類型還包括：ApplicationCompatibilityTest(兼容性測試)，主要目的是為了兼容第三方軟件，確保第三方軟件能正常運行，用戶不受影響；AccessibilityTest(軟件適用性測試)，是確保軟件對于某些殘疾人士也能正常的使用，但優先級比較低；還有FunctionalTest(功能測試)、SecurityTest(安全性測試)、StressTest(壓力測試)、PerformanceTest(性能測試)、RegressionTest(回歸測試)、Setup/UpgradeTest(安裝升級測試)等。

1)靜態測試

靜態測試包括代碼檢查、靜態結構分析、代碼質量度量等。它可以由人工進行，充分發揮人的邏輯思維優勢，也可以借助軟件工具自動進行。

(1)代碼檢查：代碼檢查包括代碼走查、桌面檢查、代碼審查等，主要檢查代碼和設計的一致性，代碼對標準的遵循、可讀性，代碼的邏輯表達的正確性，代碼結構的合理性等方面。通過代碼檢查，可以發現違背程序編寫標準的問題，及程序中不安全、不明確和模糊的部分，找出程序中不可移植的部分、違背程序編程風格的問題，包括變量檢查、命名和類型審查、程序邏輯審查、程序語法檢查和程序結構檢查等內容。在實際使用中，代碼檢查比動態測試更有效率，能快速找到缺陷，發現30%～70%的邏輯設計和編碼缺陷。代碼檢查看到的是問題本身而非征兆，但是代碼檢查非常耗費時間，而且代碼檢查需要知識和經驗的積累。代碼檢查應在編譯和動態測試之前進行，在檢查前，應準備好需求描述文檔、程序設計文檔、程序的源代碼清單、代碼編碼標準和代碼缺陷檢查表等。

(2)靜態結構分析：靜態結構分析主要是以圖形的方式表現程序的內部結構，例如函數調用關系圖、函數內部控制流圖。其中，函數調用關系圖以直觀的圖形方式描述一個應用程序中各個函數的調用和被調用關系；控制流圖顯示一個函數的邏輯結構，它由許多節點組成，一個節點代表一條語句或數條語句，連接結點的叫邊，邊表示節點間的控制流向。

(3)代碼質量度量：ISO/IEC9126國際標準所定義的軟件質量包括功能性、可靠性、易用性、效率、可維護性和可移植性六個方面。軟件的質量是軟件屬性的各種標準度量的組合。

針對軟件的可維護性，目前業界主要存在三種度量參數：Line復雜度、Halstead復雜度和McCabe復雜度。其中Line復雜度以代碼的行數作為計算的基準；Halstead以程序中使用到的運算符與運算元數量作為計數目標(直接測量指標)，然后可以據此計算出程序容量、工作量等；McCabe復雜度一般稱為圈復雜度(CyclomaticComplexity)，它將軟件的流程圖轉化為有向圖，然后以圖論來衡量軟件的質量。McCabe復雜度包括圈復雜度、基本復雜度、模塊設計復雜度、設計復雜度和集成復雜度。靜態測試的要點如下：

(1)同一程序內的代碼書寫是否為同一風格；

(2)代碼布局是否合理、美觀；

(3)程序中函數、子程序塊分界是否明顯；

(4)注釋是否符合既定格式；

(5)注釋是否正確反映代碼的功能；

(6)變量定義是否正確(長度、類型、存儲類型)；

(7)是否引用了未初始化變量；

(8)數組和字符串的下標是否為整數；

(9)數組和字符串的下標是否在范圍內(不“越界”)；

(10)進行數組的檢索及其他操作中，是否會出現“漏掉一個”的情況；

(11)是否在應該使用常量的地方使用了變量(例：數組范圍檢查)；

(12)為變量賦予不同類型的值的情況下，賦值是否符合數據類型的轉換規則；

(13)變量的命名是否相似；

(14)是否存在聲明過但從未引用，或者只引用過一次的變量；

(15)在特定模塊中所有的變量是否都顯式聲明過；

(16)非(15)描述的情況下，是否可以理解為該變量具有更高的共享級別；

(17)是否為引用的指針分配了內存；

(18)數據結構在函數和子程序中的引用是否明確定義了其結構；

(19)計算中是否使用了不同數據類型的變量；

(20)計算中是否使用了數據類型相同但長度不同的變量；

(21)賦值的目的變量是否小于賦值表達式的值；

(22)數值計算是否會出現溢出(向上)的情況；

(23)數值計算是否會出現溢出(向下)的情況；

(24)除數是否可能為零；

(25)某些計算是否會丟失計算精度；

(26)變量的值是否超過有意義的值；

(27)計算式的求值順序是否容易讓人感到混亂；

(28)比較是否正確；

(29)是否存在分數和浮點數的比較；

(30)如果存在(29)的描述情況，精度問題是否會影響比較；

(31)每一個邏輯表達式是否都得到了正確表達；

(32)邏輯表達式的操作數是否均為邏輯值；

(33)程序中的Begin…End和Do…While等語句中，End是否對應；

(34)程序、模塊、子程序和循環是否能夠終止；

(35)是否存在永不執行的循環；

(36)是否存在多循環一次或少循環一次的情況；

(37)循環變量是否在循環內被錯誤地修改；

(38)多分支選擇中，索引變量是否能超過可能的分支數；

(39)如果出現(38)中描述問題，該情況是否能夠得到正確處理；

(40)子程序接受的參數類型、大小、次序是否和調用模塊相匹配；

(41)全局變量的定義和用法在各個模塊中是否一致；

(42)是否修改了只作為輸入用的參數；

(43)常量是否被作為形式參數進行傳遞。

2)動態測試

動態測試包括功能與接口測試、覆蓋率分析、性能分析、內存分析等。

(1)功能與接口測試：這部分的測試包括各個單元功能的正確執行、單元間的接口，包括單元接口、局部數據結構、重要的執行路徑、錯誤處理的路徑和影響上述幾點的邊界條件等內容。

(2)覆蓋率分析：覆蓋率分析主要對代碼的執行路徑覆蓋范圍進行評估，語句覆蓋、判定覆蓋、條件覆蓋、條件/判定覆蓋、修正條件/判定覆蓋、基本路徑覆蓋都是從不同要求出發，為設計測試用例提出依據的。

(3)性能分析：代碼運行緩慢是開發過程中一個重要問題。一個應用程序運行速度較慢，程序員不容易找到是在哪里出現了問題，如果不能解決應用程序的性能問題，將降低并極大地影響應用程序的質量，于是查找和修改性能瓶頸成為調整整個代碼性能的關鍵。目前性能分析工具大致分為純軟件的測試工具、純硬件的測試工具(如邏輯分析儀和仿真器等)和軟硬件結合的測試工具三類。

(4)內存分析：內存泄漏會導致系統運行的崩潰，尤其對于嵌入式系統這種資源比較匱乏、應用非常廣泛，而且往往又處于重要部位的系統，將可能導致無法預料的重大損失。通過測量內存使用情況，我們可以了解程序內存分配的真實情況，發現對內存的不正常使用，在問題出現前發現征兆，在系統崩潰前發現內存泄露錯誤、內存分配錯誤，并精確顯示發生錯誤時的上下文情況，指出發生錯誤的原由。

(5)連接方式：在嵌入式軟件測試中，測試系統Host與被測試系統Target的連接有直接連接和通過仿真器連接兩種方式。直接連接是Host與Target通過串口、并口或網口直接連接。動態測試的要點如下：

(1)測試數據是否具有一定的代表性；

(2)測試數據是否包含測試所用的各個等價類(邊界條件、次邊界條件、空白、無效)；

(3)是否可能從客戶那邊得到測試數據；

(4)不可從客戶處獲得測試數據時，所用的測試數據是否具有實際的意義；

(5)是否每一組測試數據都得到了執行；

(6)每一組測試數據的測試結果是否與預期結果一致；

(7)文件的屬性是否正確；

(8)打開文件的語句是否正確；

(9)輸入/輸出語句是否與格式說明書所描述的一致；

(10)緩沖區大小與記錄長度是否匹配；

(11)使用文件前是否已打開了文件；

(12)文件結束條件是否存在；

(13)產生輸入/輸出錯誤時，系統是否進行檢測并處理；

(14)輸出信息中是否存在文字書寫錯誤和語法錯誤；

(15)控件尺寸是否大小適宜；

(16)控件顏色是否符合規約；

(17)控件布局是否合理、美觀；

(18)控件TAB順序是否從左到右，從上到下；

(19)數字輸入框是否接受數字輸入；

(20)在(19)中接受數字輸入的情況下，數字是否按既定格式顯示；

(21)數字輸入框是否拒絕字符串和“非法”數字的輸入；

(22)組合框是否能夠進行下拉選擇；

(23)組合框是否能夠進行下拉多項選擇；

(24)對于可添加數據組合框，添加數據后數據是否能夠得到正確顯示和進行選擇；

(25)列表框是否能夠進行選擇；

(26)多項列表框是否能夠進行多數據項選擇；

(27)日期輸入框是否接受正確的日期輸入；

(28)日期輸入框是否拒絕錯誤的日期輸入；

(29)日期輸入框在日期輸入后是否按既定的日期格式顯示日期；

(30)單選組內是否有且只有一個單選鈕可選；

(31)如果單選組內無單選鈕可選，這種情況是否允許存在；

(32)復選框組內是否允許多個復選框(包括全部可選)可選；

(33)如果復選框組內無復選框可選，這種情況是否允許存在；

(34)文本框及某些控件拒絕輸入和選擇時，顯示區域是否變灰或按既定規約處理；

(35)密碼輸入框是否按掩碼的方式顯示；

(36)?Cancel之類的按鈕按下后，控件中的數據是否清空復原或按既定規約處理；

(37)?Submit之類的按鈕按下后，數據是否得到提交或按既定規約處理；

(38)異常信息表述是否正確；

(39)軟件是否按預期方式處理錯誤；

(40)文件或外設不存在的情況下是否存在相應的錯誤處理；

(41)軟件是否嚴格地遵循外設的讀寫格式；

(42)畫面文字(全角、半角、格式、拼寫)是否正確；

(43)產生的文件和數據表的格式是否正確；

(44)產生的文件和數據表的計算結果是否正確；

(45)打印的報表是否符合既定的格式；

(46)錯誤日志的表述是否正確；

(47)錯誤日志的格式是否正確。

3)白盒測試

白盒測試是指在測試時能夠了解被測對象的結構，可以查閱被測代碼內容的測試工作。它需要知道程序內部的設計結構及具體的代碼實現，并以此為基礎來設計測試用例。如下例程序代碼：讀了代碼之后可以知道，先要檢查一個字符串是否為空，然后再根據播放器當前的狀態來執行相應的動作。可以這樣設計一些測試用例：如果字符串(文件)為空的話會出現什么情況；如果此時播放器的狀態是文件剛打開，會是什么情況；如果文件已經在播放，再調用這個函數會是什么情況。也就是說，根據播放器內部狀態的不同，可以設計很多不同的測試用例，這些是在純粹做黑盒測試時不一定能做到的事情。

白盒測試的直接好處就是知道所設計的測試用例在代碼級上哪些地方被忽略掉，它的優點是能幫助軟件測試人員增大代碼的覆蓋率，提高代碼的質量，發現代碼中隱藏的問題。白盒測試的缺點有：

(1)程序運行會有很多不同的路徑，不可能測試所有的運行路徑；

(2)測試基于代碼，只能測試開發人員做的對不對，而不能知道設計的正確與否，可能會漏掉一些功能需求；

(3)系統龐大時，測試開銷會非常大。

4)黑盒測試

黑盒測試顧名思義就是將被測系統看成一個黑盒，從外界取得輸入，然后再輸出，整個測試基于需求文檔，看是否能滿足需求文檔中的所有要求。黑盒測試要求測試者在測試時不能使用與被測系統內部結構相關的知識或經驗，它適用于對系統的功能進行測試。黑盒測試的優點有：

(1)比較簡單，不需要了解程序內部的代碼及實現；

(2)與軟件的內部實現無關；

(3)從用戶角度出發，能很容易地知道用戶會用到哪些功能，會遇到哪些問題；

(4)基于軟件開發文檔，所以也能知道軟件實現了文檔中的哪些功能；

(5)在做軟件自動化測試時較為方便。

黑盒測試的缺點有：

(1)不可能覆蓋所有的代碼，覆蓋率較低，大概只能達到總代碼量的30%；

(2)自動化測試的復用性較低。

5．練習

(1)靜態測試、動態測試有什么區別？

(2)測試類型有哪些？對這些測試類型做詳細分類。

(3)白盒測試的特點是什么？

操作二軟件測試過程

1．軟件測試過程概述

軟件測試過程是一種抽象的模型，用于定義軟件測試的流程和方法。眾所周知，開發過程的質量決定了軟件的質量，同樣的，測試過程的質量將直接影響測試結果的準確性和有效性。軟件測試過程和軟件開發過程一樣，都遵循軟件工程原理，遵循管理學原理。隨著測試過程管理的發展，軟件測試專家通過實踐總結出了很多很好的測試過程模型。這些模型將測試活動進行了抽象，并與開發活動有機地進行了結合，是測試過程管理的重要參考依據。

1)測試過程管理理念

生命周期模型為我們提供了軟件測試的流程和方法，為測試過程管理提供了依據。但實際的測試工作是復雜而繁瑣的，可能不會有哪種模型完全適用于某項測試工作。所以，我們應該從不同的模型中抽象出符合實際現狀的測試過程管理理念，依據這些理念來策劃測試過程，以不變應萬變。當然測試管理牽涉的范圍非常地廣泛，包括過程定義、人力資源管理、風險管理等，本節僅介紹幾條從過程模型中提煉出來的、對實際測試有指導意義的管理理念。

(1)盡早測試。“盡早測試”是從W模型中抽象出來的理念。我們說測試并不是在代碼編寫完成之后才開展的工作，測試與開發是兩個相互依存的并行的過程，測試活動在開發活動的前期已經開展。

“盡早測試”包含兩方面的含義：第一，測試人員早期即參與軟件項目，及時開展測試的準備工作，包括編寫測試計劃、制定測試方案以及準備測試用例；第二，盡早地開展測試執行工作，一旦代碼模塊完成就應該及時開展單元測試，一旦代碼模塊被集成為相對獨立的子系統，便可以開展集成測試，一旦有Build提交，便可以開展系統測試工作。由于及早地開展了測試準備工作，測試人員能夠于早期了解測試的難度、預測測試的風險，從而有效提高了測試效率，規避測試風險，同時測試人員可盡早發現軟件缺陷，大大降低Bug修復成本。但是需要注意，“盡早測試”并非盲目地提前測試活動，測試活動開展的前提是達到必需的測試就緒點。

(2)全面測試。軟件是程序、數據和文檔的集合，那么對軟件進行測試，就不僅僅是對程序的測試，還應包括軟件“副產品”的“全面測試”，這是W模型中一個重要的思想。需求文檔、設計文檔作為軟件的階段性產品，直接影響到軟件的質量。階段產品質量是軟件質量的量的積累，不能把握這些階段產品的質量將導致最終軟件質量的不可控。

“全面測試”包含兩層含義：第一，對軟件的所有產品進行全面的測試，包括需求、設計文檔、代碼、用戶文檔等；第二，軟件開發及測試人員(有時包括用戶)全面地參與到測試工作中，例如對需求的驗證和確認活動，就需要開發人員、測試人員及用戶的全面參與，畢竟測試活動并不僅僅是保證軟件運行正確，同時還要保證軟件滿足用戶的需求。“全面測試”有助于全方位把握軟件質量，盡最大可能排除造成軟件質量問題的因素，從而保證軟件滿足質量需求。

(3)全過程測試。在W模型中充分體現的另一個理念就是“全過程測試”。雙V字過程圖形象地表明了軟件開發與軟件測試的緊密結合，這就說明軟件開發和測試過程會彼此影響，因此要求測試人員對開發和測試的全過程進行充分的關注。“全過程測試”包含兩層含義：第一，測試人員要充分關注開發過程，對開發過程的各種變化及時做出響應，例如開發進度的調整可能會引起測試進度及測試策略的調整，需求的變更會影響到測試的執行等；第二，測試人員要對測試的全過程進行全程的跟蹤，例如建立完善的度量與分析機制，通過對自身過程的度量，及時了解過程信息，調整測試策略。

“全過程測試”有助于及時應對項目變化，降低測試風險，同時對測試過程的度量與分析也有助于把握測試過程，調整測試策略，便于測試過程的改進。

(4)獨立的、迭代的測試。我們知道，軟件開發瀑布模型只是一種理想狀況，為適應不同的需要，人們在軟件開發過程中摸索出了如螺旋、迭代等諸多模型，這些模型中需求、設計、編碼工作可能重疊并反復進行，這時的測試工作將也是迭代和反復的。如果不能將測試從開發中抽象出來進行管理，勢必使測試管理陷入困境。

軟件測試與軟件開發是緊密結合的，但并不代表測試是依附于開發的一個過程，測試活動是獨立的，這正是H模型所主導的思想。“獨立的、迭代的測試”著重強調了測試的就緒點，也就是說，只要測試條件成熟，測試準備活動完成，測試的執行活動就可以開展。所以，我們在遵循盡早測試、全面測試、全過程測試理念的同時，應當將測試過程從開發過程中適當地抽象出來，作為一個獨立的過程進行管理，時刻把握“獨立的、迭代的測試”的理念，減小因開發模型的繁雜給測試管理工作帶來的不便。對于軟件過程中不同階段的產品和不同的測試類型，只要測試準備工作就緒，就可以及時開展測試工作，把握產品質量。

2)測試過程管理實踐

本部分以一個實際項目系統測試過程(不對單元測試和集成測試過程進行分析)的幾個關鍵過程管理行為為例，來闡述上文中提出的測試理念。在一個構件化ERP項目中，由于前期需求不明確，開發周期相對較長，為了對項目進行更好的跟蹤和管理，項目采用增量和迭代模型進行開發。整個項目開發共分三個階段完成：第一階段實現進銷存的簡單功能和工作流；第二階段實現固定資產管理、財務管理，并完善第一階段的進銷存功能；第三階段增加辦公自動化的管理(OA)。該項目每一階段的工作是對上一階段成果的一次迭代完善，同時將新功能進行了一次疊加。

(1)策劃測試過程。依據傳統的方法，將系統測試作為軟件開發的一個階段，系統測試執行工作將在上述三個階段完成后開展。很明顯，這樣做不利于Bug的及時暴露，有些缺陷可能會埋藏至后期發現，這時的修復成本將大大提高。我們依據“獨立和迭代”的測試理念，在本系統中，對測試過程進行獨立的策劃，找出測試準備就緒點，在就緒點及時開展測試。

該系統的三個階段具有相對的獨立性，在每一階段完成時所提交的階段產品具有相對的獨立性，可以作為系統測試準備的就緒點。故而，在該系統開發過程中，系統測試組計劃開展三階段的系統測試，每個階段系統測試具有不同的側重點，目的在于更好地配合開發工作盡早發現軟件Bug，降低軟件成本。軟件開發與系統測試過程的關系如圖5-2所示。

實踐證明，這種做法起到了預期的效果，與開發過程緊密結合而又相對獨立的測試過程，有效地于早期發現了許多系統缺陷，降低了開發成本，同時也使基于復雜開發模型的測試管理工作更加清晰明了。圖5-2軟件開發與系統測試關系圖

(2)把握需求。在本系統開發過程中，需求的獲取和完善貫穿每個階段，對需求的把握很大程度上決定了軟件測試是否能夠成功。系統測試不僅需要確認軟件是否正確實現功能，同時還要確認軟件是否滿足用戶的需要。依據“盡早測試”和“全面測試”原則，在需求的獲取階段，測試人員參與到了對需求的討論之中。測試人員與開發人員及用戶一起討論需求的完善性與正確性，同時從可測試性角度為需求文檔提出建議。這些建議對開發人員來說，是從一個全新的思維角度提出的約束。同時，測試組結合前期對項目的把握，很容易制定出完善的測試計劃和方案，將各階段產品的測試方法及進度、人員安排進行了策劃，使整個項目的進展有條不紊。實踐證明，測試人員早期參與需求的獲取和分析，有助于加深測試人員對需求的把握和理解，同時也大大促進需求文檔的質量。在需求人員把握需求的同時，可于早期制定項目計劃和方案，及早準備測試活動，大大提高了測試效率。

(3)變更控制。變更控制體現的是“全過程測試”理念。在軟件開發過程中，變更往往是不可避免的，變更也是造成軟件風險的重要因素。在本系統測試中，僅第一階段就發生了7次需求變更，調整了兩次進度計劃。依據“全過程測試”理念，測試組密切關注開發過程，跟隨進度計劃的變更調整測試策略，依據需求的變更及時補充和完善測試用例。由于充分的測試準備工作，在測試執行過程中，沒有廢棄一個測試用例，測試的進度并沒有因為變更而受到過多影響。

(4)度量與分析。對測試過程的度量與分析同樣體現了“全過程測試”理念。對測試過程的度量有利于及時把握項目情況，對過程數據進行分析，很容易發現優勢劣勢，找出需要改進的地方，及時調整測試策略。

在ERP項目中，我們在測試過程中對不同階段的Bug數量進行了度量，并分析測試執行是否充分。如圖5-3所示，通過分析我們得出：相同時間間隔內發現的Bug數量呈收斂狀態，測試是充分的。在Bug數量收斂的狀態下結束細測是恰當的。圖5-3軟件開發與系統測試關系圖測試中，我們對不同功能點的測試數據覆蓋率和發現問題數進行度量，以便分析測試用例的充分度與Bug發現率之間的關系。如表5-1所示，對類似模塊進行對比發現：某一功能點上所覆蓋的測試數據組越多，Bug的用例發現率越高。因此，如果再結合工作量、用例執行時間等因素進行統計分析，便可以找到適合實際情況的測試用例書寫粒度，從而幫助測試人員判斷測試成本和收益間的最佳平衡點。

所有這些度量都是對測試全過程進行跟蹤的結果，是及時調整測試策略的依據。對測試過程的度量與分析能有效提高測試效率，降低測試風險。同時，度量與分析也是軟件測試過程可持續改進的基礎。表5-1測試數據覆蓋率與Bug發現率對應表

3)測試過程可持續改進

測試技術發展到今天，已經存在諸多可供參考的測試過程管理思想和理念，但信息技術發展一日千里，新技術不斷涌現，這就注定測試過程也需要不斷地改進。我們提倡基于度量與分析的可持續過程改進方法(本書不做詳細論述)。在這種方法中，對現狀的度量被制度化，并作為過程改進的基礎，組織可以自定義需要度量的過程數據，將收集來的數據加以分析，以找出需要改進的因素，在不斷的改進中，同步地調整需要度量的過程數據，使度量與分析始終為了過程改進服務，而過程改進也包含對度量和分析的改進。

4)軟件測試過程模型

(1)V模型。V模型最早是由PaulRook在20世紀80年代后期提出的，旨在改進軟件開發的效率和效果。Ｖ模型反映出了測試活動與分析設計活動的關系。在圖5-4中，從左到右描述了基本的開發過程和測試行為，非常明確地標注了測試過程中存在的不同類型的測試，并且清楚地描述了這些測試階段和開發過程期間各階段的對應關系。圖5-4軟件測試V模型

V模型指出，單元和集成測試應檢測程序的執行是否滿足軟件設計的要求；系統測試應檢測系統功能、性能的質量特性是否達到系統要求的指標；驗收測試確定軟件的實現是否滿足用戶需要或合同的要求。

但V模型存在一定的局限性，它僅僅把測試作為在編碼之后的一個階段，是針對程序進行的尋找錯誤的活動，而忽視了測試活動對需求分析、系統設計等活動的驗證和確認的功能。

(2)W模型。W模型由Evolutif公司公司提出，相對于V模型，W模型增加了軟件各開發階段中應同步進行的驗證和確認活動。如圖5-5所示，W模型由兩個V字型模型組成，分別代表測試與開發過程，圖中明確表示出了測試與開發的并行關系。圖5-5軟件測試W模型

W模型強調，測試伴隨著整個軟件開發周期，而且測試的對象不僅僅是程序，需求、設計等同樣要測試，也就是說，測試與開發是同步進行的。W模型有利于盡早地、全面地發現問題，例如，需求分析完成后，測試人員就應該參與到對需求的驗證和確認活動中，以盡早地找出缺陷所在，同時，對需求的測試也有利于及時了解項目難度和測試風險，及早制定應對措施，這將顯著減少總體測試時間，加快項目進度。但W模型也存在局限性。在W模型中，需求、設計、編碼等活動被視為串行的，同時，測試和開發活動也保持著一種線性的前后關系，上一階段完全結束，才可正式開始下一個階段工作。這樣就無法支持迭代的開發模型。對于當前軟件開發復雜多變的情況，W模型并不能解除測試管理面臨的困惑。

(3)?H模型。V模型和W模型均存在一些不妥之處。如前所述，它們都把軟件的開發視為需求、設計、編碼等一系列串行的活動，而事實上，這些活動在大部分時間內是可以交叉進行的，所以，相應的測試之間也不存在嚴格的次序關系，同時，各層次的測試(單元測試、集成測試、系統測試等)也存在反復觸發、迭代的關系。為了解決以上問題，有專家提出了H模型。它將測試活動完全獨立出來，形成了一個完全獨立的流程，將測試準備活動和測試執行活動清晰地體現出來，如圖5-6所示。圖5-6軟件測試H模型這個示意圖僅僅演示了在整個生產周期中某個層次上的一次測試“微循環”。圖中標注的其他流程可以是任意的開發流程，例如，設計流程或編碼流程。也就是說，只要測試條件成熟了，測試準備活動完成了，測試執行活動就可以(或者說需要)進行了。

H模型揭示了一個原理：軟件測試是一個獨立的流程，貫穿產品整個生命周期，與其他流程并發地進行。H模型指出軟件測試要盡早準備，盡早執行。不同的測試活動可以是按照某個次序先后進行的，但也可能是反復的，只要某個測試達到準備就緒點，測試執行活動就可以開展。

(4)其他模型。除上述幾種常見模型外，業界還流傳著其他幾種模型，例如X模型、前置測試模型等。X模型提出針對單獨的程序片段進行相互分離的編碼和測試，此后通過頻繁的交接和集成最終合成為可執行的程序。前置測試模型體現了開發與測試的結合，要求對每一個交付內容進行測試。這些模型都針對其他模型的缺點提出了一些修正意見，但本身也可能存在一些不周到的地方。所以在測試過程管理中，正確選取過程模型是一個關鍵問題。

2．軟件測試過程

軟件測試過程按軟件生命周期來劃分測試的生命周期，顯示如下：

測試計劃→測試設計→測試開發→測試執行→測試評估

1)測試計劃

(1)測試計劃的問題主要有以下幾個：

①測試計劃經常是等到開發周期后期才開始實行，使得沒有時間有效地執行計劃；

②測試計劃的組織者可能缺乏Client/Server測試經驗；

③測試的量度和復雜性可能太大，沒有自動化工具，很難計劃和控制。

(2)測試需求。測試計劃最關鍵的一步就是將軟件分解成單元，寫成測試需求。

測試需求有很多分類方法，最普通的一種就是按照商業功能分類。把軟件分解成單元元件有幾個好處：

①測試需求是測試設計和開發測試用例的基礎，分成單元可以更好地進行設計；

②詳細的測試需求是用來衡量測試覆蓋率的重要指標；

③測試需求包括各種測試實際和開發以及所需資源。

(3)怎樣估計測試工作量。

①效率假設：即測試隊伍的工作效率。對于功能測試，這主要依賴于應用的復雜度，窗口的個數，每個窗口中的動作數目。對容量測試，主要依賴于建立測試所需數據的工作量大小。

②測試假設：為了驗證一個測試需求所需的測試動作數目。

③應用的維數：應用的復雜度指標。例如要加入一個記錄，測試需求的維數就是這個記錄中域的數目。

④所處測試周期的階段：有些階段主要工作都在設計，有些階段主要是測試執行。

(4)測試策略。

測試策略描述測試工程的總體方法和目標，描述目前在進行哪一階段的測試(單元測試、集成測試、系統測試)以及每個階段內在進行的測試種類(功能測試、性能測試、壓力測試等)。

測試策略包括：

①要使用的測試技術和工具；

②測試完成標準；

③影響資源分配的特殊考慮，例如測試與外部接口或者模擬物理損壞、安全性威脅。

(5)測試資源。

①人力資源。

測試經理：為測試項目提供總體方向，負責開發測試計劃、征集并監督測試人員、申請系統資源、監視并匯報工作進程、測試評估、測試需求的分解。

測試工程師：負責設計和開發。其中，設計需要對被測軟件有詳細了解，具有分解測試需求的技能、選擇在C/S環境下用來驗證測試需求的技術；開發需要熟悉SQA、VB和腳本語言。

測試工程師：負責測試執行和記錄結果。需要能夠安裝系統，具備網絡知識，能夠初始化數據庫和其他初始條件。重要的是診斷能力。測試系統管理者：每個測試項目指定的專人，負責管理SQASuite，包括在服務器上安裝存儲庫，安裝打印機連接，執行備份，以及其他維護工作。管理者必須高度熟悉SQA，并具有網絡工作經驗。

②系統資源。包括安裝SQASuite的硬件和軟件環境，以及數據庫服務器，該服務器必須專用于測試工作，能夠重置某些初始值，包括系統日期和時間等。

(6)測試過程步驟。

編寫測試計劃的流程如下：

①確定工程：收集相應信息，如是否已創建文檔，以及文檔的版本/日期、需求詳述、功能詳述、項目計劃、設計詳述、原型及用戶手冊。

②定義測試策略，包括測試策略項(例子)、測試階段(如系統測試)、測試類型(如功能測試)、測試技術(如75%自動測試，25%手工測試)、完成標準(如95%測試用例通過并且最高級缺陷全部解決)、特殊考慮(如測試必須在上午進行)。

③分解軟件，寫測試需求，即：分析各種信息，反復檢查并理解各種信息，和用戶交流，理解他們的要求。針對本系統，可以按照以下步驟執行：

A.確定軟件提供的主要商業任務；

B.對每個商業任務，確定完成該任務所要進行的交易；

C.確定從數據庫信息引出的計算結果；

D.對于對時間有要求的交易，確定所要求的時間和條件。這些條件包括數據庫大小、機器配置、交易量以及網絡擁擠情況；

E.確定會產生重大意外的壓力測試，包括：內存、硬盤空間、高的交易率；

F.確定應用需要處理的數據量；

G.確定需要的軟件和硬件配置，通常情況下，不可能對所有可能的配置都測試到，因此要選擇最有可能產生問題的情況進行測試，包括：最低性能的硬件、幾個有兼容性問題的軟件并存、客戶端機器通過最慢的LAN/WANF連接訪問服務器；

H.確定其他與應用軟件沒有直接關系的商業交易，包括管理功能(如啟動和退出程序)、配置功能(如設置打印機)、操作員的愛好(如字體、顏色)、應用功能(如訪問Email或者顯示時間和日期)；

I.確定安裝過程，包括定置從哪安裝、定制安裝、升級安裝；

J.確定沒有隱含在功能測試中的用戶界面要求，排除大多界面在功能測試中被測試到時，還有沒測到的情況，如操作與顯示的一致性、使用快捷鍵等，同時確定界面遵從合理標準，如按鈕大小、標簽等，并把需求組織成層次圖。

④估計測試工作量，可用下述公式進行計算：

測試工作量?=?∑(每個測試的時間*每個需求的測試的數目*測試需求的數目)(測試設計、開發、….)

⑤確定資源，包括人力資源、系統資源及服務器名稱。

⑥時間進度安排時：

A.進度安排可采用MSProject工具進行；

B.進度分階段進行，如寫測試計劃階段、設計用例階段、編寫用例階段、搭建環境、執行測試階段、總結階段；

C.任務分配按時間、人員進行，分配到個人。

2)測試設計

(1)測試設計的問題主要包括：

①不做測試設計，測試過程也是胡亂建立的；

②測試設計不詳細，不是基于可量度的測試策略，例如測試計劃覆蓋一個集合或者測試需求的一個子集；

③測試過程沒有采用最好的技術來檢驗WindowsC/S結構的測試需求。

(2)測試用例的選擇規則為：

①選擇與測試需求的實質部分最相關的測試用例；

②選擇的測試用例應該不容易受到應用程序的改變的影響。

(3)下面是選擇測試用例的幾點具體規則：

①商業函數一般與數據庫有關，要測試數據庫的變化，有幾種方法：

A.如果數據庫的改變會反映在一個列表框中，那么就要選擇驗證列表框內容的測試用例；

B.還可以檢查交易完成后的確認對話框。可以檢查對話框的標題。圖像比較也可以檢查確認對話框，但圖像比較容易受其他因素影響；

C.修改腳本，SQABASIC提供了強大的數據庫支持。

②各種不同的域選擇相應的測試用例進行驗證。

③用戶界面測試使用對象狀態測試用例。

④性能標準使用等待狀態測試用例。⑤壓力下的操作。

⑥訪問控制。

⑦配置測試不能選擇圖像測試用例(與分辨率有關)和文件測試用例(與驅動器有關)。

⑧安裝選項和驗證。

(4)編寫測試設計的步驟如下所示：①編寫測試用例。

測試用例分為手工測試用例和自動化測試用例，下面主要介紹自動化測試用例編寫過程。

輸入：被測軟件、基于測試需求的測試設計

輸出：測試過程和測試用例

目標：

A.創建可以重用的測試過程和測試用例；

B.維護測試過程、測試用例與相關測試需求的一一對應。

3)測試開發

(1)測試開發的問題包括：

①測試開發很亂，與測試需求或測試策略沒有對應性；

②測試過程不可重復或不可重用；

③測試過程被作為一個編程任務來執行，導致腳本太長，不能滿足軟件移植性的要求。

(2)錯誤處理。當測試過程發生錯誤時，有幾種解決辦法：

①跳轉到別的測試過程；

②調用一個能夠清除錯誤的過程；

③退出過程，啟動另一個；

④退出過程和應用程序，重新啟動啟動Windows，在失敗的地方重新開始測試。

(3)測試開發的步驟如下：

①建立開發環境；

②錄制腳本，步驟為：

A.錄制模塊測試過程和與測試需求最低層對應的測試用例；

B.錄制初始化過程；

C.錄制導航過程，把前面的過程串起來；

D.測試和調試測試過程；

E.修改測試過程(可選)；

F.建立外部數據集合(如果測試過程是用來循環一套輸入和輸出數據，就需要建立數據集合)；

G.回到D，重復測試和調試測試過程。

4)測試執行

(1)測試執行的問題有：

①自動化測試沒有有效地利用，使得手工測試太多；

②測試結果的捕獲沒有系統性，而且沒有查看或調查；

③缺陷報告必須用手工加入缺陷跟蹤系統。

(2)錯誤分類有：

①測試用例失敗：正常錯誤。

②腳本命令失敗：當測試過程不能執行錄制過程中的某個功能時，會產生這種錯誤，如鼠標單擊按鈕或選擇菜單項等。它也能指示是缺陷還是測試過程的設計問題。

③致命錯誤：導致測試停止，這種情況最好重啟Windows。

(3)測試執行的具體步驟為：

①建立測試系統；

②準備測試過程；

③運行初始化過程；

④執行測試；

⑤從終止的測試恢復；

⑥驗證預期結果；

⑦調查突發結果；

⑧記錄缺陷日記。

5)測試評估

測試評估的目標為：

(1)量化測試進程；

(2)生成缺陷和測試覆蓋率的總結報告。

測試評估的問題有：

(1)沒有把測試覆蓋率作為報告測試進程的根據，使得不知測試是否結束；

(2)沒有做缺陷評估，缺陷評估是量度軟件可行性的重要指標；

(3)不使用專門的軟件工具進行數據輸入任務和相應的評估活動，使得這些任務變得繁重累人。測試覆蓋率：評估測試完成多少的標準。

缺陷評估：評估軟件質量的重要指標，通常評估模型假設缺陷的發現是呈泊松分布的；嚴格的缺陷評估要考察在測試過程中發現缺陷的間隔時間長短。評估要