《基于任務(wù)驅(qū)動(dòng)模式的軟件工程與UML建模技術(shù)》課件項(xiàng)目五

項(xiàng)目五軟件實(shí)現(xiàn)任務(wù)一軟件編碼

任務(wù)二軟件測試

任務(wù)一軟件編碼

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

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

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

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

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

操作一程序設(shè)計(jì)語言概述

人類所使用的語言稱為自然語言，它是以語音為物質(zhì)外殼、以詞匯為建筑材料、以語法為結(jié)構(gòu)規(guī)律而構(gòu)成的體系。與此類似，程序設(shè)計(jì)語言是以具有特定語義的符號為基本構(gòu)成單位，以語法為程序構(gòu)成規(guī)律，專門用于定義、組織并完成各種各樣的計(jì)算任務(wù)而形成的體系。程序設(shè)計(jì)語言是程序設(shè)計(jì)的基礎(chǔ)，了解程序設(shè)計(jì)語言的特點(diǎn)、分類、選擇原則，對于學(xué)習(xí)程序設(shè)計(jì)是非常必要的。

1．程序設(shè)計(jì)語言的組成

程序設(shè)計(jì)語言的基本成分包含數(shù)據(jù)成分、運(yùn)算成分、控制成分、函數(shù)。

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

運(yùn)算成分指明允許使用的運(yùn)算符號及運(yùn)算規(guī)則，一般包括算術(shù)運(yùn)算、關(guān)系運(yùn)算、邏輯運(yùn)算。

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

2．程序設(shè)計(jì)語言的分類

程序設(shè)計(jì)語言是指用來書寫計(jì)算機(jī)程序的語言，是人與計(jì)算機(jī)進(jìn)行信息通訊的工具。

程序設(shè)計(jì)語言目前多達(dá)上千種，常用的也有幾十種。眾多的程序設(shè)計(jì)語言如何進(jìn)行分類，目前眾說紛紜，多數(shù)人認(rèn)為程序設(shè)計(jì)語言分為四大類：面向機(jī)器的語言、面向過程的語言、面向?qū)ο蟮恼Z言和面向問題的語言。

1)面向機(jī)器的語言

面向機(jī)器的語言是針對特定的計(jì)算機(jī)而設(shè)計(jì)的語言，是不能獨(dú)立于機(jī)器的語言。如機(jī)器語言和匯編語言。

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

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

2)面向過程的語言

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

FORTRAN的全稱是FormulaTranslation，是一種編程語言。它是世界上最早出現(xiàn)的計(jì)算機(jī)高級程序設(shè)計(jì)語言，廣泛應(yīng)用于科學(xué)和工程計(jì)算領(lǐng)域。FORTRAN語言接近數(shù)學(xué)公式的自然描述，在計(jì)算機(jī)里具有很高的執(zhí)行效率，以其特有的功能在數(shù)值、科學(xué)和工程計(jì)算領(lǐng)域發(fā)揮著重要作用。

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

Pascal是一種計(jì)算機(jī)通用的高級程序設(shè)計(jì)語言。它由瑞士NiklausWirth教授于60年代末設(shè)計(jì)并創(chuàng)立。以法國數(shù)學(xué)家命名的Pascal語言現(xiàn)已成為使用最廣泛的基于DOS的語言之一，其主要特點(diǎn)有：嚴(yán)格的結(jié)構(gòu)化形式，豐富完備的數(shù)據(jù)類型，運(yùn)行效率高，查錯(cuò)能力強(qiáng)。

C語言是一種通用的、面向過程式的編程語言，廣泛用于系統(tǒng)與應(yīng)用軟件的開發(fā)。于1969年至1973年間，為了移植與開發(fā)UNIX操作系統(tǒng)，由丹尼斯·里奇與肯·湯普遜，以B語言為基礎(chǔ)，在貝爾實(shí)驗(yàn)室設(shè)計(jì)、開發(fā)出來的，因?yàn)榫哂懈咝А㈧`活、功能豐富、表達(dá)力強(qiáng)和較高的可移植性等特點(diǎn)，在程序員中備受青睞，2000年起成為使用最為廣泛的編程語言。C語言是結(jié)構(gòu)式語言，其顯著特點(diǎn)是代碼及數(shù)據(jù)的分隔化，即程序的各個(gè)部分除了必要的信息交流外彼此獨(dú)立，這種結(jié)構(gòu)化方式可使程序?qū)哟吻逦阌谑褂?、維護(hù)以及調(diào)試。C語言是以函數(shù)形式提供給用戶的，這些函數(shù)可方便地調(diào)用，并具有多種循環(huán)、條件語句控制程序流向，從而使程序完全結(jié)構(gòu)化。C語言的適用范圍廣泛，適合于多種操作系統(tǒng)，如Windows、DOS、UNIX等，也適用于多種機(jī)型。C語言對編寫需要進(jìn)行硬件操作的場合，優(yōu)于其他高級語言，有一些大型應(yīng)用軟件也是用C語言編寫的。

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

3)面向?qū)ο蟮恼Z言

從1985年迄今，是面向?qū)ο蟮某绦蛟O(shè)計(jì)語言的產(chǎn)生和發(fā)展階段。面向?qū)ο笳Z言借鑒了20世紀(jì)50年代的人工智能語言LISP，引入了動(dòng)態(tài)綁定的概念和交互式開發(fā)環(huán)境的思想,同時(shí)借鑒了始于20世紀(jì)60年代的離散事件模擬語言SIMULA67,引入了類的要領(lǐng)和繼承，其最終成形于20世紀(jì)70年代的Smalltalk。面向?qū)ο笳Z言的發(fā)展有兩個(gè)方向：一種是純面向?qū)ο笳Z言，如Smalltalk、EIFFEL、Java、C#等；另一種是混合型面向?qū)ο笳Z言，即在過程式語言及其他語言中加入類、繼承等成分，如C++、Objective-C等。

Java是一種可以撰寫跨平臺(tái)應(yīng)用軟件的面向?qū)ο蟮某绦蛟O(shè)計(jì)語言，是由SunMicrosystems公司于1995年5月推出的Java程序設(shè)計(jì)語言和Java平臺(tái)(即JavaEE、JavaME、JavaSE)的總稱。Java自面世后就非常流行，發(fā)展迅速，對C++語言形成了有力沖擊。Java技術(shù)具有卓越的通用性、高效性、平臺(tái)移植性和安全性，廣泛應(yīng)用于個(gè)人PC、數(shù)據(jù)中心、游戲控制臺(tái)、科學(xué)超級計(jì)算機(jī)、移動(dòng)電話和互聯(lián)網(wǎng)，同時(shí)擁有全球最大的開發(fā)者專業(yè)社群。在全球云計(jì)算和移動(dòng)互聯(lián)網(wǎng)的產(chǎn)業(yè)環(huán)境下，Java更具備了顯著優(yōu)勢和廣闊前景。Java是一種簡單的、跨平臺(tái)的、面向?qū)ο蟮摹⒎植际降?、解釋的、健壯的、安全的、結(jié)構(gòu)的、中立的、可移植的、性能很優(yōu)異的多線程的、動(dòng)態(tài)的語言。當(dāng)1995年SUN推出Java語言之后，全世界的目光都被這個(gè)神奇的語言所吸引。

C++是在C語言的基礎(chǔ)上開發(fā)的一種集面向?qū)ο缶幊?、泛型編程和過程化編程于一體的編程語言。它應(yīng)用較為廣泛，是一種靜態(tài)數(shù)據(jù)類型檢查的、支持多重編程的通用程序設(shè)計(jì)語言。它支持過程化程序設(shè)計(jì)、數(shù)據(jù)抽象、面向?qū)ο笤O(shè)計(jì)、制作圖標(biāo)等多種程序設(shè)計(jì)風(fēng)格。C++語言的主要特點(diǎn)表現(xiàn)在兩個(gè)方面，一是盡量兼容C，二是支持面向?qū)ο蟮姆椒?。它保留了C的簡潔、高效的接近匯編語言的特點(diǎn)，同時(shí)對C的類型系統(tǒng)進(jìn)行了改革的擴(kuò)充，因此C++比C更安全，C++的編譯系統(tǒng)能檢查出更多的類型錯(cuò)誤。另外，由于C語言的廣泛使用，因而極大地促進(jìn)了C++的普及和推廣。

4)面向問題的語言

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

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

3．程序設(shè)計(jì)語言的選擇

選擇程序設(shè)計(jì)語言是軟件編碼階段必須考慮的一個(gè)關(guān)鍵問題。程序設(shè)計(jì)語言的選擇需要根據(jù)組織和項(xiàng)目的實(shí)際情況做出選擇，這里給出幾個(gè)原則和依據(jù)：

(1)系統(tǒng)的應(yīng)用領(lǐng)域。

(2)系統(tǒng)用戶的要求。

(3)軟件的執(zhí)行環(huán)境。

(4)目標(biāo)系統(tǒng)的性能要求。

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

(6)軟件的可移植性。

(7)工程規(guī)模。

操作二編碼規(guī)范

編碼規(guī)范是軟件公司制訂的一套統(tǒng)一標(biāo)準(zhǔn)的代碼編寫規(guī)則，用于規(guī)范開發(fā)人員在軟件編碼中的代碼編寫。優(yōu)秀的程序員在代碼編寫中應(yīng)該注意執(zhí)行編碼規(guī)范。

編碼規(guī)范的重要性包括：

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

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

(3)有助于代碼審查。代碼審查可以及時(shí)糾正一些錯(cuò)誤，而且可以對開發(fā)人員的代碼規(guī)范作出監(jiān)督，團(tuán)隊(duì)的代碼審查同時(shí)也是一個(gè)很好的學(xué)習(xí)機(jī)會(huì)，對成員的進(jìn)步也是很有益的。但是，開發(fā)隨意的編碼加重了審查的工作量及難度，并且使得代碼審查工作沒有根據(jù)，浪費(fèi)了大量的時(shí)間卻收效甚微。編碼規(guī)范不僅使得開發(fā)統(tǒng)一，減少審查工作量，而且讓代碼審查有據(jù)可查，大大提高了審查效率和效果，同時(shí)代碼審查也有助于編碼規(guī)范的實(shí)施。

操作三編碼工具

編碼工具是用于輔助程序員用某種程序設(shè)計(jì)語言編制源程序，并對源程序進(jìn)行翻譯，最終轉(zhuǎn)換成可執(zhí)行的代碼的工具軟件。

1．IDE開發(fā)工具

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

IDE多被用于開發(fā)HTML應(yīng)用軟件。例如，許多人在設(shè)計(jì)網(wǎng)站時(shí)使用IDE(如HomeSite，DreamWeaver，F(xiàn)rontPage等)，因此很多項(xiàng)任務(wù)可自動(dòng)生成。IDE除集成了代碼編輯、代碼生成、界面設(shè)計(jì)、調(diào)試、編譯等功能外，目前還融合了建模功能。

2．配置管理工具

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

任務(wù)二軟件測試

操作一軟件測試概念

1．軟件測試定義

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

(1)軟件測試是為了發(fā)現(xiàn)錯(cuò)誤而執(zhí)行程序的過程。

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

在如何明確質(zhì)量保障和軟件測試的責(zé)任方面，各個(gè)機(jī)構(gòu)有不同的做法，這取決于該機(jī)構(gòu)的大小和該機(jī)構(gòu)的商務(wù)結(jié)構(gòu)。有時(shí)候，該工作由一個(gè)小組或者個(gè)人來負(fù)責(zé)。常見的辦法是項(xiàng)目組包括了測試人員和開發(fā)人員，他們在一起合作工作，由項(xiàng)目負(fù)責(zé)人來對質(zhì)量保障進(jìn)行總負(fù)責(zé)。

2．軟件測試術(shù)語

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

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

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

軟件缺陷生命周期(SWDefectLifecycle)：包括報(bào)告、確認(rèn)、修正、驗(yàn)證、關(guān)閉等階段。

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

缺陷跟蹤系統(tǒng)(DTS)：管理軟件缺陷的整個(gè)生命周期的工具。靜態(tài)測試與動(dòng)態(tài)測試(StatisticTestingAndDynamicTesting)：不執(zhí)行/執(zhí)行程序進(jìn)行的測試。

白盒測試與黑盒測試(WhiteBoxTestingandBlackBoxTesting)：測試軟件代碼結(jié)構(gòu)的測試；不關(guān)心軟件代碼結(jié)構(gòu)，以軟件輸入和輸出來測試軟件功能的測試。

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

軟件里程碑(SWMilestone)：軟件項(xiàng)目開發(fā)的各個(gè)關(guān)鍵過程。

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

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

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

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

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

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

原則：

(1)盡早進(jìn)行軟件測試，以在早期發(fā)現(xiàn)和報(bào)告軟件缺陷；

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

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

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

2)軟件測試的局限性

(1)不可能完全測試一個(gè)程序。完全測試一個(gè)程序意味著在測試結(jié)束時(shí)，再也沒有未發(fā)現(xiàn)的軟件錯(cuò)誤。而不可能完全測試一個(gè)程序的原因如下：

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

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

③用戶界面問題(及相應(yīng)的設(shè)計(jì)問題)太復(fù)雜，不可能進(jìn)行完全測試。

(2)不可能測試到程序?qū)θ魏慰赡茌斎氲捻憫?yīng)。

若要測試程序?qū)θ魏慰赡茌斎氲捻憫?yīng)，對程序必須執(zhí)行的測試有以下幾種：

①要對所有有效的輸入進(jìn)行測試；

②要對所有無效的輸入進(jìn)行測試；

③要對所有編輯過的輸入進(jìn)行測試；

④要對所有輸入時(shí)機(jī)的變化情況進(jìn)行測試。

由上可知，程序通過輸入可以接收的可能值非常之多，因此無法測試到程序?qū)θ魏慰赡茌斎氘a(chǎn)生的響應(yīng)。

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

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

軟件測試就是敲敲鍵盤、動(dòng)動(dòng)鼠標(biāo)，很容易，誰都能干。

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

軟件開發(fā)完成后再進(jìn)行軟件測試。

軟件發(fā)布后如果發(fā)現(xiàn)質(zhì)量問題，那是軟件測試人員的錯(cuò)。

軟件自動(dòng)測試效率高，將取代軟件手工測試。

軟件測試是測試人員的事情，與程序員無關(guān)。

項(xiàng)目進(jìn)度吃緊時(shí)少做些測試，時(shí)間富裕時(shí)多做測試。

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

4．軟件測試類型

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

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

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

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

1)靜態(tài)測試

靜態(tài)測試包括代碼檢查、靜態(tài)結(jié)構(gòu)分析、代碼質(zhì)量度量等。它可以由人工進(jìn)行，充分發(fā)揮人的邏輯思維優(yōu)勢，也可以借助軟件工具自動(dòng)進(jìn)行。

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

(2)靜態(tài)結(jié)構(gòu)分析：靜態(tài)結(jié)構(gòu)分析主要是以圖形的方式表現(xiàn)程序的內(nèi)部結(jié)構(gòu)，例如函數(shù)調(diào)用關(guān)系圖、函數(shù)內(nèi)部控制流圖。其中，函數(shù)調(diào)用關(guān)系圖以直觀的圖形方式描述一個(gè)應(yīng)用程序中各個(gè)函數(shù)的調(diào)用和被調(diào)用關(guān)系；控制流圖顯示一個(gè)函數(shù)的邏輯結(jié)構(gòu)，它由許多節(jié)點(diǎn)組成，一個(gè)節(jié)點(diǎn)代表一條語句或數(shù)條語句，連接結(jié)點(diǎn)的叫邊，邊表示節(jié)點(diǎn)間的控制流向。

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

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

(1)同一程序內(nèi)的代碼書寫是否為同一風(fēng)格；

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

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

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

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

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

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

(8)數(shù)組和字符串的下標(biāo)是否為整數(shù)；

(9)數(shù)組和字符串的下標(biāo)是否在范圍內(nèi)(不“越界”)；

(10)進(jìn)行數(shù)組的檢索及其他操作中，是否會(huì)出現(xiàn)“漏掉一個(gè)”的情況；

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

(12)為變量賦予不同類型的值的情況下，賦值是否符合數(shù)據(jù)類型的轉(zhuǎn)換規(guī)則；

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

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

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

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

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

(18)數(shù)據(jù)結(jié)構(gòu)在函數(shù)和子程序中的引用是否明確定義了其結(jié)構(gòu)；

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

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

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

(22)數(shù)值計(jì)算是否會(huì)出現(xiàn)溢出(向上)的情況；

(23)數(shù)值計(jì)算是否會(huì)出現(xiàn)溢出(向下)的情況；

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

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

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

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

(28)比較是否正確；

(29)是否存在分?jǐn)?shù)和浮點(diǎn)數(shù)的比較；

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

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

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

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

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

(35)是否存在永不執(zhí)行的循環(huán)；

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

(37)循環(huán)變量是否在循環(huán)內(nèi)被錯(cuò)誤地修改；

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

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

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

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

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

(43)常量是否被作為形式參數(shù)進(jìn)行傳遞。

2)動(dòng)態(tài)測試

動(dòng)態(tài)測試包括功能與接口測試、覆蓋率分析、性能分析、內(nèi)存分析等。

(1)功能與接口測試：這部分的測試包括各個(gè)單元功能的正確執(zhí)行、單元間的接口，包括單元接口、局部數(shù)據(jù)結(jié)構(gòu)、重要的執(zhí)行路徑、錯(cuò)誤處理的路徑和影響上述幾點(diǎn)的邊界條件等內(nèi)容。

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

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

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

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

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

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

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

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

(5)是否每一組測試數(shù)據(jù)都得到了執(zhí)行；

(6)每一組測試數(shù)據(jù)的測試結(jié)果是否與預(yù)期結(jié)果一致；

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

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

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

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

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

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

(13)產(chǎn)生輸入/輸出錯(cuò)誤時(shí)，系統(tǒng)是否進(jìn)行檢測并處理；

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

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

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

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

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

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

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

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

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

(23)組合框是否能夠進(jìn)行下拉多項(xiàng)選擇；

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

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

(26)多項(xiàng)列表框是否能夠進(jìn)行多數(shù)據(jù)項(xiàng)選擇；

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

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

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

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

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

(32)復(fù)選框組內(nèi)是否允許多個(gè)復(fù)選框(包括全部可選)可選；

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

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

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

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

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

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

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

(40)文件或外設(shè)不存在的情況下是否存在相應(yīng)的錯(cuò)誤處理；

(41)軟件是否嚴(yán)格地遵循外設(shè)的讀寫格式；

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

(43)產(chǎn)生的文件和數(shù)據(jù)表的格式是否正確；

(44)產(chǎn)生的文件和數(shù)據(jù)表的計(jì)算結(jié)果是否正確；

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

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

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

3)白盒測試

白盒測試是指在測試時(shí)能夠了解被測對象的結(jié)構(gòu)，可以查閱被測代碼內(nèi)容的測試工作。它需要知道程序內(nèi)部的設(shè)計(jì)結(jié)構(gòu)及具體的代碼實(shí)現(xiàn)，并以此為基礎(chǔ)來設(shè)計(jì)測試用例。如下例程序代碼：讀了代碼之后可以知道，先要檢查一個(gè)字符串是否為空，然后再根據(jù)播放器當(dāng)前的狀態(tài)來執(zhí)行相應(yīng)的動(dòng)作?？梢赃@樣設(shè)計(jì)一些測試用例：如果字符串(文件)為空的話會(huì)出現(xiàn)什么情況；如果此時(shí)播放器的狀態(tài)是文件剛打開，會(huì)是什么情況；如果文件已經(jīng)在播放，再調(diào)用這個(gè)函數(shù)會(huì)是什么情況。也就是說，根據(jù)播放器內(nèi)部狀態(tài)的不同，可以設(shè)計(jì)很多不同的測試用例，這些是在純粹做黑盒測試時(shí)不一定能做到的事情。

白盒測試的直接好處就是知道所設(shè)計(jì)的測試用例在代碼級上哪些地方被忽略掉，它的優(yōu)點(diǎn)是能幫助軟件測試人員增大代碼的覆蓋率，提高代碼的質(zhì)量，發(fā)現(xiàn)代碼中隱藏的問題。白盒測試的缺點(diǎn)有：

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

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

(3)系統(tǒng)龐大時(shí)，測試開銷會(huì)非常大。

4)黑盒測試

黑盒測試顧名思義就是將被測系統(tǒng)看成一個(gè)黑盒，從外界取得輸入，然后再輸出，整個(gè)測試基于需求文檔，看是否能滿足需求文檔中的所有要求。黑盒測試要求測試者在測試時(shí)不能使用與被測系統(tǒng)內(nèi)部結(jié)構(gòu)相關(guān)的知識或經(jīng)驗(yàn)，它適用于對系統(tǒng)的功能進(jìn)行測試。黑盒測試的優(yōu)點(diǎn)有：

(1)比較簡單，不需要了解程序內(nèi)部的代碼及實(shí)現(xiàn)；

(2)與軟件的內(nèi)部實(shí)現(xiàn)無關(guān)；

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

(4)基于軟件開發(fā)文檔，所以也能知道軟件實(shí)現(xiàn)了文檔中的哪些功能；

(5)在做軟件自動(dòng)化測試時(shí)較為方便。

黑盒測試的缺點(diǎn)有：

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

(2)自動(dòng)化測試的復(fù)用性較低。

5．練習(xí)

(1)靜態(tài)測試、動(dòng)態(tài)測試有什么區(qū)別？

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

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

操作二軟件測試過程

1．軟件測試過程概述

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

1)測試過程管理理念

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

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

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

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

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

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

“全過程測試”有助于及時(shí)應(yīng)對項(xiàng)目變化，降低測試風(fēng)險(xiǎn)，同時(shí)對測試過程的度量與分析也有助于把握測試過程，調(diào)整測試策略，便于測試過程的改進(jìn)。

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

軟件測試與軟件開發(fā)是緊密結(jié)合的，但并不代表測試是依附于開發(fā)的一個(gè)過程，測試活動(dòng)是獨(dú)立的，這正是H模型所主導(dǎo)的思想。“獨(dú)立的、迭代的測試”著重強(qiáng)調(diào)了測試的就緒點(diǎn)，也就是說，只要測試條件成熟，測試準(zhǔn)備活動(dòng)完成，測試的執(zhí)行活動(dòng)就可以開展。所以，我們在遵循盡早測試、全面測試、全過程測試?yán)砟畹耐瑫r(shí)，應(yīng)當(dāng)將測試過程從開發(fā)過程中適當(dāng)?shù)爻橄蟪鰜恚鳛橐粋€(gè)獨(dú)立的過程進(jìn)行管理，時(shí)刻把握“獨(dú)立的、迭代的測試”的理念，減小因開發(fā)模型的繁雜給測試管理工作帶來的不便。對于軟件過程中不同階段的產(chǎn)品和不同的測試類型，只要測試準(zhǔn)備工作就緒，就可以及時(shí)開展測試工作，把握產(chǎn)品質(zhì)量。

2)測試過程管理實(shí)踐

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

(1)策劃測試過程。依據(jù)傳統(tǒng)的方法，將系統(tǒng)測試作為軟件開發(fā)的一個(gè)階段，系統(tǒng)測試執(zhí)行工作將在上述三個(gè)階段完成后開展。很明顯，這樣做不利于Bug的及時(shí)暴露，有些缺陷可能會(huì)埋藏至后期發(fā)現(xiàn)，這時(shí)的修復(fù)成本將大大提高。我們依據(jù)“獨(dú)立和迭代”的測試?yán)砟?，在本系統(tǒng)中，對測試過程進(jìn)行獨(dú)立的策劃，找出測試準(zhǔn)備就緒點(diǎn)，在就緒點(diǎn)及時(shí)開展測試。

該系統(tǒng)的三個(gè)階段具有相對的獨(dú)立性，在每一階段完成時(shí)所提交的階段產(chǎn)品具有相對的獨(dú)立性，可以作為系統(tǒng)測試準(zhǔn)備的就緒點(diǎn)。故而，在該系統(tǒng)開發(fā)過程中，系統(tǒng)測試組計(jì)劃開展三階段的系統(tǒng)測試，每個(gè)階段系統(tǒng)測試具有不同的側(cè)重點(diǎn)，目的在于更好地配合開發(fā)工作盡早發(fā)現(xiàn)軟件Bug，降低軟件成本。軟件開發(fā)與系統(tǒng)測試過程的關(guān)系如圖5-2所示。

實(shí)踐證明，這種做法起到了預(yù)期的效果，與開發(fā)過程緊密結(jié)合而又相對獨(dú)立的測試過程，有效地于早期發(fā)現(xiàn)了許多系統(tǒng)缺陷，降低了開發(fā)成本，同時(shí)也使基于復(fù)雜開發(fā)模型的測試管理工作更加清晰明了。圖5-2軟件開發(fā)與系統(tǒng)測試關(guān)系圖

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

(3)變更控制。變更控制體現(xiàn)的是“全過程測試”理念。在軟件開發(fā)過程中，變更往往是不可避免的，變更也是造成軟件風(fēng)險(xiǎn)的重要因素。在本系統(tǒng)測試中，僅第一階段就發(fā)生了7次需求變更，調(diào)整了兩次進(jìn)度計(jì)劃。依據(jù)“全過程測試”理念，測試組密切關(guān)注開發(fā)過程，跟隨進(jìn)度計(jì)劃的變更調(diào)整測試策略，依據(jù)需求的變更及時(shí)補(bǔ)充和完善測試用例。由于充分的測試準(zhǔn)備工作，在測試執(zhí)行過程中，沒有廢棄一個(gè)測試用例，測試的進(jìn)度并沒有因?yàn)樽兏艿竭^多影響。

(4)度量與分析。對測試過程的度量與分析同樣體現(xiàn)了“全過程測試”理念。對測試過程的度量有利于及時(shí)把握項(xiàng)目情況，對過程數(shù)據(jù)進(jìn)行分析，很容易發(fā)現(xiàn)優(yōu)勢劣勢，找出需要改進(jìn)的地方，及時(shí)調(diào)整測試策略。

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

所有這些度量都是對測試全過程進(jìn)行跟蹤的結(jié)果，是及時(shí)調(diào)整測試策略的依據(jù)。對測試過程的度量與分析能有效提高測試效率，降低測試風(fēng)險(xiǎn)。同時(shí)，度量與分析也是軟件測試過程可持續(xù)改進(jìn)的基礎(chǔ)。表5-1測試數(shù)據(jù)覆蓋率與Bug發(fā)現(xiàn)率對應(yīng)表

3)測試過程可持續(xù)改進(jìn)

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

4)軟件測試過程模型

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

V模型指出，單元和集成測試應(yīng)檢測程序的執(zhí)行是否滿足軟件設(shè)計(jì)的要求；系統(tǒng)測試應(yīng)檢測系統(tǒng)功能、性能的質(zhì)量特性是否達(dá)到系統(tǒng)要求的指標(biāo)；驗(yàn)收測試確定軟件的實(shí)現(xiàn)是否滿足用戶需要或合同的要求。

但V模型存在一定的局限性，它僅僅把測試作為在編碼之后的一個(gè)階段，是針對程序進(jìn)行的尋找錯(cuò)誤的活動(dòng)，而忽視了測試活動(dòng)對需求分析、系統(tǒng)設(shè)計(jì)等活動(dòng)的驗(yàn)證和確認(rèn)的功能。

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

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

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

H模型揭示了一個(gè)原理：軟件測試是一個(gè)獨(dú)立的流程，貫穿產(chǎn)品整個(gè)生命周期，與其他流程并發(fā)地進(jìn)行。H模型指出軟件測試要盡早準(zhǔn)備，盡早執(zhí)行。不同的測試活動(dòng)可以是按照某個(gè)次序先后進(jìn)行的，但也可能是反復(fù)的，只要某個(gè)測試達(dá)到準(zhǔn)備就緒點(diǎn)，測試執(zhí)行活動(dòng)就可以開展。

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

2．軟件測試過程

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

測試計(jì)劃→測試設(shè)計(jì)→測試開發(fā)→測試執(zhí)行→測試評估

1)測試計(jì)劃

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

①測試計(jì)劃經(jīng)常是等到開發(fā)周期后期才開始實(shí)行，使得沒有時(shí)間有效地執(zhí)行計(jì)劃；

②測試計(jì)劃的組織者可能缺乏Client/Server測試經(jīng)驗(yàn)；

③測試的量度和復(fù)雜性可能太大，沒有自動(dòng)化工具，很難計(jì)劃和控制。

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

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

①測試需求是測試設(shè)計(jì)和開發(fā)測試用例的基礎(chǔ)，分成單元可以更好地進(jìn)行設(shè)計(jì)；

②詳細(xì)的測試需求是用來衡量測試覆蓋率的重要指標(biāo)；

③測試需求包括各種測試實(shí)際和開發(fā)以及所需資源。

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

①效率假設(shè)：即測試隊(duì)伍的工作效率。對于功能測試，這主要依賴于應(yīng)用的復(fù)雜度，窗口的個(gè)數(shù)，每個(gè)窗口中的動(dòng)作數(shù)目。對容量測試，主要依賴于建立測試所需數(shù)據(jù)的工作量大小。

②測試假設(shè)：為了驗(yàn)證一個(gè)測試需求所需的測試動(dòng)作數(shù)目。

③應(yīng)用的維數(shù)：應(yīng)用的復(fù)雜度指標(biāo)。例如要加入一個(gè)記錄，測試需求的維數(shù)就是這個(gè)記錄中域的數(shù)目。

④所處測試周期的階段：有些階段主要工作都在設(shè)計(jì)，有些階段主要是測試執(zhí)行。

(4)測試策略。

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

測試策略包括：

①要使用的測試技術(shù)和工具；

②測試完成標(biāo)準(zhǔn)；

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

(5)測試資源。

①人力資源。

測試經(jīng)理：為測試項(xiàng)目提供總體方向，負(fù)責(zé)開發(fā)測試計(jì)劃、征集并監(jiān)督測試人員、申請系統(tǒng)資源、監(jiān)視并匯報(bào)工作進(jìn)程、測試評估、測試需求的分解。

測試工程師：負(fù)責(zé)設(shè)計(jì)和開發(fā)。其中，設(shè)計(jì)需要對被測軟件有詳細(xì)了解，具有分解測試需求的技能、選擇在C/S環(huán)境下用來驗(yàn)證測試需求的技術(shù)；開發(fā)需要熟悉SQA、VB和腳本語言。

測試工程師：負(fù)責(zé)測試執(zhí)行和記錄結(jié)果。需要能夠安裝系統(tǒng)，具備網(wǎng)絡(luò)知識，能夠初始化數(shù)據(jù)庫和其他初始條件。重要的是診斷能力。測試系統(tǒng)管理者：每個(gè)測試項(xiàng)目指定的專人，負(fù)責(zé)管理SQASuite，包括在服務(wù)器上安裝存儲(chǔ)庫，安裝打印機(jī)連接，執(zhí)行備份，以及其他維護(hù)工作。管理者必須高度熟悉SQA，并具有網(wǎng)絡(luò)工作經(jīng)驗(yàn)。

②系統(tǒng)資源。包括安裝SQASuite的硬件和軟件環(huán)境，以及數(shù)據(jù)庫服務(wù)器，該服務(wù)器必須專用于測試工作，能夠重置某些初始值，包括系統(tǒng)日期和時(shí)間等。

(6)測試過程步驟。

編寫測試計(jì)劃的流程如下：

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

②定義測試策略，包括測試策略項(xiàng)(例子)、測試階段(如系統(tǒng)測試)、測試類型(如功能測試)、測試技術(shù)(如75%自動(dòng)測試，25%手工測試)、完成標(biāo)準(zhǔn)(如95%測試用例通過并且最高級缺陷全部解決)、特殊考慮(如測試必須在上午進(jìn)行)。

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

A.確定軟件提供的主要商業(yè)任務(wù)；

B.對每個(gè)商業(yè)任務(wù)，確定完成該任務(wù)所要進(jìn)行的交易；

C.確定從數(shù)據(jù)庫信息引出的計(jì)算結(jié)果；

D.對于對時(shí)間有要求的交易，確定所要求的時(shí)間和條件。這些條件包括數(shù)據(jù)庫大小、機(jī)器配置、交易量以及網(wǎng)絡(luò)擁擠情況；

E.確定會(huì)產(chǎn)生重大意外的壓力測試，包括：內(nèi)存、硬盤空間、高的交易率；

F.確定應(yīng)用需要處理的數(shù)據(jù)量；

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

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

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

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

④估計(jì)測試工作量，可用下述公式進(jìn)行計(jì)算：

測試工作量?=?∑(每個(gè)測試的時(shí)間*每個(gè)需求的測試的數(shù)目*測試需求的數(shù)目)(測試設(shè)計(jì)、開發(fā)、….)

⑤確定資源，包括人力資源、系統(tǒng)資源及服務(wù)器名稱。

⑥時(shí)間進(jìn)度安排時(shí)：

A.進(jìn)度安排可采用MSProject工具進(jìn)行；

B.進(jìn)度分階段進(jìn)行，如寫測試計(jì)劃階段、設(shè)計(jì)用例階段、編寫用例階段、搭建環(huán)境、執(zhí)行測試階段、總結(jié)階段；

C.任務(wù)分配按時(shí)間、人員進(jìn)行，分配到個(gè)人。

2)測試設(shè)計(jì)

(1)測試設(shè)計(jì)的問題主要包括：

①不做測試設(shè)計(jì)，測試過程也是胡亂建立的；

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

③測試過程沒有采用最好的技術(shù)來檢驗(yàn)WindowsC/S結(jié)構(gòu)的測試需求。

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

①選擇與測試需求的實(shí)質(zhì)部分最相關(guān)的測試用例；

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

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

①商業(yè)函數(shù)一般與數(shù)據(jù)庫有關(guān)，要測試數(shù)據(jù)庫的變化，有幾種方法：

A.如果數(shù)據(jù)庫的改變會(huì)反映在一個(gè)列表框中，那么就要選擇驗(yàn)證列表框內(nèi)容的測試用例；

B.還可以檢查交易完成后的確認(rèn)對話框?？梢詸z查對話框的標(biāo)題。圖像比較也可以檢查確認(rèn)對話框，但圖像比較容易受其他因素影響；

C.修改腳本，SQABASIC提供了強(qiáng)大的數(shù)據(jù)庫支持。

②各種不同的域選擇相應(yīng)的測試用例進(jìn)行驗(yàn)證。

③用戶界面測試使用對象狀態(tài)測試用例。

④性能標(biāo)準(zhǔn)使用等待狀態(tài)測試用例。⑤壓力下的操作。

⑥訪問控制。

⑦配置測試不能選擇圖像測試用例(與分辨率有關(guān))和文件測試用例(與驅(qū)動(dòng)器有關(guān))。

⑧安裝選項(xiàng)和驗(yàn)證。

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

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

輸入：被測軟件、基于測試需求的測試設(shè)計(jì)

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

目標(biāo)：

A.創(chuàng)建可以重用的測試過程和測試用例；

B.維護(hù)測試過程、測試用例與相關(guān)測試需求的一一對應(yīng)。

3)測試開發(fā)

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

①測試開發(fā)很亂，與測試需求或測試策略沒有對應(yīng)性；

②測試過程不可重復(fù)或不可重用；

③測試過程被作為一個(gè)編程任務(wù)來執(zhí)行，導(dǎo)致腳本太長，不能滿足軟件移植性的要求。

(2)錯(cuò)誤處理。當(dāng)測試過程發(fā)生錯(cuò)誤時(shí)，有幾種解決辦法：

①跳轉(zhuǎn)到別的測試過程；

②調(diào)用一個(gè)能夠清除錯(cuò)誤的過程；

③退出過程，啟動(dòng)另一個(gè)；

④退出過程和應(yīng)用程序，重新啟動(dòng)啟動(dòng)Windows，在失敗的地方重新開始測試。

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

①建立開發(fā)環(huán)境；

②錄制腳本，步驟為：

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

B.錄制初始化過程；

C.錄制導(dǎo)航過程，把前面的過程串起來；

D.測試和調(diào)試測試過程；

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

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

G.回到D，重復(fù)測試和調(diào)試測試過程。

4)測試執(zhí)行

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

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

②測試結(jié)果的捕獲沒有系統(tǒng)性，而且沒有查看或調(diào)查；

③缺陷報(bào)告必須用手工加入缺陷跟蹤系統(tǒng)。

(2)錯(cuò)誤分類有：

①測試用例失?。赫ｅe(cuò)誤。

②腳本命令失?。寒?dāng)測試過程不能執(zhí)行錄制過程中的某個(gè)功能時(shí)，會(huì)產(chǎn)生這種錯(cuò)誤，如鼠標(biāo)單擊按鈕或選擇菜單項(xiàng)等。它也能指示是缺陷還是測試過程的設(shè)計(jì)問題。

③致命錯(cuò)誤：導(dǎo)致測試停止，這種情況最好重啟Windows。

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

①建立測試系統(tǒng)；

②準(zhǔn)備測試過程；

③運(yùn)行初始化過程；

④執(zhí)行測試；

⑤從終止的測試恢復(fù)；

⑥驗(yàn)證預(yù)期結(jié)果；

⑦調(diào)查突發(fā)結(jié)果；

⑧記錄缺陷日記。

5)測試評估

測試評估的目標(biāo)為：

(1)量化測試進(jìn)程；

(2)生成缺陷和測試覆蓋率的總結(jié)報(bào)告。

測試評估的問題有：

(1)沒有把測試覆蓋率作為報(bào)告測試進(jìn)程的根據(jù)，使得不知測試是否結(jié)束；

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

(3)不使用專門的軟件工具進(jìn)行數(shù)據(jù)輸入任務(wù)和相應(yīng)的評估活動(dòng)，使得這些任務(wù)變得繁重累人。測試覆蓋率：評估測試完成多少的標(biāo)準(zhǔn)。

缺陷評估：評估軟件質(zhì)量的重要指標(biāo)，通常評估模型假設(shè)缺陷的發(fā)現(xiàn)是呈泊松分布的；嚴(yán)格的缺陷評估要考察在測試過程中發(fā)現(xiàn)缺陷的間隔時(shí)間長短。評估要