《管理信息系統(tǒng)》管理信息系統(tǒng)的實施

管理信息系統(tǒng)的實施

系統(tǒng)實施的任務是實現(xiàn)系統(tǒng)設計階段提出的物理模型，按實施方案完成一個可以實際運行的信息系統(tǒng)，交付用戶使用。理解系統(tǒng)實施的工作內容；了解軟件測試的概念和方法；掌握系統(tǒng)轉換的方式。本章學習目標第六章管理信息系統(tǒng)的實施

6.1物理系統(tǒng)的實施6.2程序設計6.3軟件測試與調試6.4人員培訓6.5系統(tǒng)轉換第六章管理信息系統(tǒng)的實施

系統(tǒng)實施概述

系統(tǒng)實施的任務系統(tǒng)實施的任務是以系統(tǒng)設計方案為依據，按照系統(tǒng)實施方案進行具體的實現(xiàn)，最終組建出一個能夠實際運行的系統(tǒng)，交付用戶使用。具體任務包括：硬件準備、軟件準備、人員培訓、數(shù)據準備1、硬件準備

硬件準備包括計算機主機、輸入輸出設備、存儲設備、輔助設備（穩(wěn)壓電源、空調設備）、通信設備等。2、軟件準備

軟件包括系統(tǒng)軟件、數(shù)據庫管理系統(tǒng)以及一些應用軟件。第六章管理信息系統(tǒng)的實施3、人員培訓

主要指用戶培訓，包括主管人員和業(yè)務人員。4、數(shù)據準備

沒有一定的基礎數(shù)據的準備，系統(tǒng)調試就不能很好的進行。第六章管理信息系統(tǒng)的實施系統(tǒng)實施的工作流程第六章管理信息系統(tǒng)實施

系統(tǒng)實施的特點工作量大投入人力、物力多組織管理工作繁重第六章管理信息系統(tǒng)實施

系統(tǒng)實施的方法劃分版本的基本原則確定版本的規(guī)模實現(xiàn)復雜模塊的方法安排實現(xiàn)模塊的順序自頂向下的實現(xiàn)方法版本的劃分需要考慮以下幾個方面：(1)先實現(xiàn)控制部分，后實現(xiàn)執(zhí)行部分，先上層后下層。(2)根據開發(fā)力量、設備、培訓等方面的情況確定每個版本實現(xiàn)多少模塊、實現(xiàn)哪些模塊。(3)復雜的模塊分散在幾個版本中逐步實現(xiàn)。(4)兼顧功能模塊和數(shù)據庫的實現(xiàn)。(5)兼顧硬件、軟件、人員培訓方面的情況。

MIS物理系統(tǒng)的實施是計算機系統(tǒng)和通信網絡系統(tǒng)設備的訂購、機房的準備和設備的安裝調試等一系列活動。6.1.1選擇供應商的標準系統(tǒng)安裝主要是指對各種軟、硬件設備的購置、安裝以及整個系統(tǒng)調試運行選擇供應商的標準是：實力雄厚、信譽可靠、質優(yōu)價低、售后服務好6.1物理系統(tǒng)的實施6.1.2選擇安裝地點的思路

考慮系統(tǒng)對電纜、電話或數(shù)據通訊服務、工作空間和存儲、噪音和通訊條件及交通情況的要求例如，使用專門的地板，讓電纜通過地板孔道，連接中央處理機及各設備，保證安全；提供不中斷電源，以免丟失數(shù)據6.1物理系統(tǒng)的實施

編程（Coding）就是為系統(tǒng)各個模塊編寫程序。根據結構化方法設計了詳細方案，又有了高級語言，初級程序員都可以參加這一階段的工作。6.2程序設計⑴可維護性由于信息系統(tǒng)需求的不確定性，系統(tǒng)需求可能會隨著環(huán)境的變化而不斷變化，因此，就必須對系統(tǒng)功能進行完善和調整，為此，就要對程序進行補充或修改。此外，由于計算機軟硬件的更新?lián)Q代也需要對程序進行相應的升級。

程序設計的目標⑵可靠性：程序應具有較好的容錯能力。正常情況下能正確工作。意外情況下應便于處理，不至產生意外的操作，從而造成嚴重損失。

⑶可理解性：程序不僅要求邏輯正確，計算機能夠執(zhí)行，而且應當層次清楚，便于閱讀。

程序設計的目標⑷效率：程序能否有效地利用計算機資源程序效率的地位：已不像以前那樣舉足輕重了，因為硬件價格大幅度下降，而其性能卻不斷完善和提高。程序設計人員工作效率的地位日益重要。不僅能降低軟件開發(fā)成本；而且可明顯降低程序的出錯率，進而減輕維護人員的工作負擔。為了提高程序設計效率，應充分利用各種軟件開發(fā)工具。

程序設計的目標在過去的小程序設計中，主要強調程序的正確和效率。對于大型程序，人們則傾向于首先強調程序的可維護性、可靠性和可理解性，然后才是效率。注意程序效率、可維護性、可理解性三者之間的關系程序設計的基本要求程序的功能必須按照規(guī)定的要求，正確地滿足預期的需要程序內容清晰、明了、便于閱讀和理解程序結構嚴謹、簡捷、算法和語句選用合理，執(zhí)行速度快，節(jié)省機時程序和數(shù)據的存儲、調用安排得當，節(jié)省存儲空間程序適應性強。程序交付使用后，若應用問題或外界環(huán)境有了變化時，調整和修改程序比較簡便易行6.2程序設計

6.2程序設計1.程序設計的任務根據系統(tǒng)設計說明書中關于模塊的詳細描述和處理過程的描述，選擇合適的計算機語言來編制程序的工作。6.2程序設計程序設計的方法結構化程序設計方法程序設計就是處理過程的設計面向對象程序設計方法程序設計主要指對象的設計可視化編程工具或開發(fā)環(huán)境

結構化程序設計結構化程序設計包括以下四方面的內容：(1)限制使用GOTO語句只用順序結構、選擇結構、循環(huán)結構這三種基本結構就能表達任何一個只有一個入口和一個出口的程序邏輯。為實際使用方便，往往允許增加多分支結構、REPEAT型循環(huán)等兩三種結構。程序中可以完全不用GOTO語句。(2)逐步求精的設計方法在一個程序模塊內，先從該模塊功能描述出發(fā)，一層層地逐步細化，直到最后分解、細化成語句為止。結構化程序設計(3)自頂向下的設計、編碼和調試這是把逐步求精的方法由程序模塊內的設計推廣到一個系統(tǒng)的設計與實現(xiàn)。(4)主程序員制的組織形式這是程序人員的組織形式。程序資料員(或秘書)一人。其他技術人員按需要隨時加入組內。主程序員負責整體項目的開發(fā)，并負責關鍵部分的設計、編碼和調試。結構化程序設計作為這種組織形式中的一個程序員，為使自己的工作融人整個系統(tǒng)，與組內其他成員協(xié)調致地工作。必須嚴格遵守：①不使用可能干擾其他模塊的命令或函數(shù)；②按總體設計的要求傳遞參數(shù)，不隨意修改其內容與含義；③按規(guī)定的統(tǒng)一格式操作公用文件或數(shù)據庫；④按統(tǒng)一的原則使用標識符；⑤按統(tǒng)一要求編寫文檔；⑥保持程序風格的一致。面向對象的程序設計

面向對象程序設計在OOP方法中，一個對象即是一個獨立存在的實體，對象有各自的屬性和行為，彼此以消息進行通信。對象的屬性只能通過自己的行為來改變，實現(xiàn)了數(shù)據封裝，這便是對象的封裝性。而相關對象在進行合并分類后，有可能出現(xiàn)共享某些性質，通過抽象后使多種相關對象表現(xiàn)為一定的組織層次，底層次的對象繼承其高層次對象的特性，這便是對象的繼承性。另外，對象的某一種操作在不同的條件環(huán)境下可以實現(xiàn)不同的處理，產生不同的結果，這就是對象的多態(tài)性。可視化編程技術

主要思想：用圖形工具和可重用部件來交互地編制程序。它把現(xiàn)有的或新建的模塊代碼封裝于標準接口封包中，作為可視化編程編輯工具中的一個對象，用圖符來表示和控制。可視化編程一般基于事件驅動的原理。面向對象編程技術和可視化編程開發(fā)環(huán)境的結合，改變了應用軟件只有經過專門技術訓練的專業(yè)編程人員才能開發(fā)的狀況。它使軟件開發(fā)變得容易，由于大量軟件模塊的重用和可視控件的引入，技術人員在掌握這些技術之后，就能有效地提高應用軟件的開發(fā)效率，縮短開發(fā)周期，降低了開發(fā)成本，并且使應用軟件界面風格統(tǒng)一，有很好的易用性。程序的內部文檔

程序的“內部文檔”，指程序內部帶有的說明材料，用注釋語句書寫。程序適當加注釋后，閱讀時就不必再看其他說明材料了。因此，這是提高程序可閱讀性的有力手段。注釋可以出現(xiàn)在程序的任何位置，但要與程序結構配合起來，效果才好。注意以下幾點：(1)注釋必須與程序一致(2)注釋不是重復程序語句，而應提供從程序本身難以得到的信息。(3)對程序段作注釋，而不是對每個語句作注釋。

程序錯誤的分類

語法錯誤程序設計人員對程序設計語言的理解不夠，或程序設計基本功不扎實造成的結果。邏輯錯誤指那些雖然不違反系統(tǒng)規(guī)則，但是卻不合邏輯或不合題目語義的錯誤。程序設計語言的選擇語言的結構化機制與數(shù)據管理能力選用高級語言應該有理想的模塊化機制、可讀性好的控制結構和數(shù)據結構，同時具備較強的數(shù)據管理能力語言可提供的交互功能有較豐富的軟件工具開發(fā)人員的熟練程度軟件可移植性要求系統(tǒng)用戶的要求6.2程序設計

6.2程序設計軟件開發(fā)工具編程語言類數(shù)據庫類可視化編程類專業(yè)系統(tǒng)類客戶/服務器類［電子表格軟件開發(fā)工具］［數(shù)據庫管理系統(tǒng)提供的開發(fā)工具］［套裝軟件工具］［可視化圖形界面編程工具］⑴MSVisualFoxpro

⑵MSVisualBASlC

⑶PowerBuilder：例如：6.3.1軟件測試測試是指軟件產品生存周期內所有的檢查、評審和確認活動，如設計評審、系統(tǒng)測試。狹義上講，測試是對軟件產品質量的檢驗和評價，它一方面檢查軟件產品質量中存在的質量問題，同時對產品質量進行客觀的評價。測試的目的：軟件測試是以最少的時間和人力，系統(tǒng)地找出軟件中潛在的各種錯誤和缺陷為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程；測試是為了證明程序有錯，而不是證明程序沒有錯誤；一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試。整個生命周期不同階段可能的測試活動和測試技術:6.3軟件測試與調試1.軟件測試的特征挑剔性復雜性不徹底性經濟性6.3.1軟件測試6.3.1軟件測試2.測試基本原則測試隊伍的建立測試用例的設計測試數(shù)據的選擇測試功能的確定測試文檔的管理6.3.1軟件測試3.測試文檔測試計劃測試項目的名稱、目的、步驟、進度、測試用例測試用例={測試數(shù)據+期望結果}測試報告測試項目的名稱、實測結果與期望結果的比較、發(fā)現(xiàn)的問題、測試達到的效果測試結果={測試數(shù)據+期望結果+實際結果}6.3.1軟件測試4.測試步驟模塊測試是在每個單獨的模塊中進行，包括模塊界面、內部數(shù)據結構、獨立路徑錯誤處理和邊界條件等項目集成測試將各模塊集中，形成一個完整的軟件，對該軟件進行測試6.3.1軟件測試系統(tǒng)測試將被測軟件放在系統(tǒng)環(huán)境中進行測試驗收測試用戶參與的測試，對系統(tǒng)的最后確認測試種類1）靜態(tài)測試：目的是通過對程序靜態(tài)結構的檢查，找出編譯時不能發(fā)現(xiàn)的錯誤。靜態(tài)分析器分析（自動方式）代碼評審（人工方式）：代碼會審、走查、辦公桌檢查2）動態(tài)測試：是把事先設計好的測試用例作用于被測程序，比較測試結果和預期的結果是否一致，如果不一致，則說明被測程序可能存在錯誤。黑盒測試白盒測試6.3.1軟件測試通過運行軟件來檢驗軟件的動態(tài)行為和運行結果的正確性約可找出30～70%的邏輯設計錯誤

基本特征是在對軟件進行分析、檢查和測試，不實際運行被測試的軟件約可找出30～70%的邏輯設計錯誤

代碼會審是由一組人通過閱讀、討論和爭議對程序進行靜態(tài)分析的過程。會審小組由組長、2～3名程序設計和測試人員及程序員組成。會審小組在充分閱讀待審程序文本、控制流程圖及有關要求、規(guī)范等文件基礎上，召開代碼會審會，程序員逐句講解程序的邏輯，并展開熱烈的討論甚至爭議，以揭示錯誤的關鍵所在。需要注意兩點：一是在代碼審查時，必須要檢查被測軟件是否通過編譯，只有正確了之后才進行代碼會審；二是一定要保證有足夠的時間讓測試小組對問題進行充分的討論，只有這樣才能有效地提高測試效率，避免走彎路。6.3.1軟件測試白盒測試時，測試者清楚被測試程序的內部結構。它從程序的邏輯結構人手，按照一定的原則來設計測試用例，設定測試數(shù)據。黑盒測試時，測試者把被測程序看成一個黑盒，完全用不著關心程序的內部結構。設計測試用例時，僅以程序的外部功能為根據。測試中標常見病錯誤種類:功能錯誤系統(tǒng)錯誤過程錯誤編碼錯誤6.3.1軟件測試測試用例：為達到最佳的測試效果或高效的揭露隱藏的錯誤而精心設計的少量測試數(shù)據，稱之為測試用例。測試用例可以被定義為如下6元組：測試索引測試環(huán)境測試輸入測試操作預期結果評價標準兼顧合理的輸入和不合理的輸入數(shù)據不僅檢查程序是否實現(xiàn)預期功能，還應檢查程序是否作了不該做的事6.3.1軟件測試測試用例的用途：在開始實施測試之前設計好測試用例，可以避免盲目測試并提高測試效率。測試用例的使用令軟件測試的實施重點突出、目的明確。在軟件版本更新后只需修正少部分的測試用例便可展開測試工作，降低工作強度、縮短項目周期。功能模塊的通用化和復用化使軟件易于開發(fā)，而相對于功能模塊的測試用例的通用化和復用化則會使軟件測試易于開展，并隨著測試用例的不斷精化其效率也不斷攀升。6.3.1軟件測試

白盒測試方案時，測試者必須檢查程序的內部結構，從檢查程序的邏輯著手，對所有邏輯路徑進行測試，得出測試數(shù)據。白盒測試的主要方法:邏輯驅動、路徑測試等，主要用于軟件驗證，檢驗語法錯誤、編譯錯誤、性能問題、邏輯問題、判定條件問題、編程規(guī)范等。

白盒測試白盒測試

優(yōu)點知道所設計的測試用例在代碼級上哪些地方被忽略掉幫助軟件測試人員增大代碼的覆蓋率，提高代碼的質量，發(fā)現(xiàn)代碼中隱藏的問題

白盒測試白盒測試

缺點

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

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

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

123

白盒測試白盒測試

測試用例的設計語句覆蓋法測試用例覆蓋路徑A=2B=0X=3aceA>1ANDB=0X=X/AA=2ORX>1X=X+1是a是否bcdeace白盒測試判斷覆蓋法序號測試用例覆蓋路徑12A=3B=0X=1acdA=2B=1X=3abeA>1ANDB=0X=X/AA=2ORX>1X=X+1是a是否bcdeacdabe白盒測試條件覆蓋法A>1ANDB=0X=X/AA=2ORX>1X=X+1是a是否bcde判斷條件取值A>1A≤1TFB=0B≠0TFA=2A≠2TFX>1X≤1TF白盒測試條件判斷條件取值條件記為條件1A>1A≤1TFT1F1條件2B=0B≠0TFT2F2條件3A=2A≠2TFT3F3條件4X>1X≤1TFT4F4條件一條件二設計的測試用例子序號測試用例覆蓋路徑條件記為1A=2B=0X=4aceT1T2T3T42A=1B=1X=1abdF1F2F3F43A=2B=0X=1acdT1T2T3F44A=1B=1X=2abeF1F2F3T4白盒測試設計測試用例白盒測試條件組合覆蓋法A>1ANDB=0X=X/AA=2ORX>1X=X+1是a是否bcde第一判斷式1A>1B=03A≤1B=02A>1B≠04A≤1B≠0第二判斷式5A=2X>17A≠2X>16A=2X≤18A≠2X≤1設計的測試用例序號測試用例覆蓋路徑覆蓋條件組合1A=2B=0X=4ace1,52A=2B=1X=1abd2,63A=1B=0X=2abe3,74A=1B=1X=1abd4,8設計的測試用例白盒測試白盒測試路徑覆蓋法a→b→da→c→ea→b→ea→c→dA=1B=1X=1A=1B=1X=2A=3B=0X=1A=2B=0X=4A>1ANDB=0X=X/AA=2ORX>1X=X+1是a是否bcde黑盒測試也稱功能測試或數(shù)據驅動測試，它是在已知產品所應具有的功能，通過測試來檢測每個功能是否都能正常使用。它只檢查程序功能是否按照需求規(guī)格說明書的規(guī)定正常使用，程序是否能適當?shù)亟邮蛰斎霐?shù)鋸而產生正確的輸出信息，并且保持外部信息（如數(shù)據庫或文件）的完整性。黑盒測試發(fā)現(xiàn)的錯誤類型有：功能不對或遺漏、界面錯誤、數(shù)據結構或外部數(shù)據庫訪問錯誤、性能錯誤、初始化和終止錯誤等。黑盒測試方法主要有等價類劃分、邊界值分析、因—果圖、錯誤推測等，主要用于軟件確認測試?！昂诤小狈ㄊ歉F舉輸入測試，只有把所有可能的輸入都作為測試情況使用，才能以這種方法查出程序中所有的錯誤。黑盒測試黑盒測試

優(yōu)點黑盒測試的優(yōu)點比較簡單，不需要了解程序內部的代碼及實現(xiàn)

與軟件的內部實現(xiàn)無關

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

基于軟件開發(fā)文檔，所以也能知道軟件實現(xiàn)了文檔中的哪些功能黑盒測試黑盒測試

缺點不可能覆蓋所有的代碼，覆蓋率較低。

自動化測試的復用性較低。黑盒測試黑盒測試等價類劃分等價類劃分法的基本思想：是將所有可能的輸入數(shù)據(有效的和無效的)劃分成若干個等價的子集(稱為等價類)，使得每個子集中的一個典型值在測試中的作用與這一子集中所有其它值的作用相同.可從每個子集中選取一組數(shù)據來測試程序等價類劃分等價類劃分有兩種情況合理等價類：測試模塊是否實現(xiàn)了規(guī)定的功能和性能不合理等價類：測試模塊是否能夠拒絕無效輸入，被測試對象在運行條件錯誤時的可靠性如何等價類劃分劃分等價類規(guī)則如果輸入條件代表一個范圍，可定義一個有效等價類和兩個無效等價類

例如，輸入條件規(guī)定：項數(shù)可從1到999

1999

有效等價類無效等價類

>999無效等價類

<1等價類劃分劃分等價類規(guī)則如果輸入條件代表一個范圍，可定義一個有效等價類和兩個無效等價類如果輸入條件代表集合的某個元素，則可定義一個有效等價類和一個無效等價類等價類劃分劃分等價類規(guī)則如果輸入條件代表一個范圍，可定義一個有效等價類和兩個無效等價類如果輸入條件代表集合的某個元素，則可定義一個有效等價類和一個無效等價類例：北京地區(qū)的電話號碼前為“010”。則，有效等價類（以“010”開頭的電話號碼）；無效等價類（不以“010”開頭的電話號碼）等價類劃分劃分等價類規(guī)則如規(guī)定了輸入數(shù)據的一組值，則每個允許的輸入值是一個有效等價類，并有一個無效等價類(所有不允許的輸入值的集合)例：某個待測程序的輸入參數(shù)“職稱”的輸入值可以是助教、講師、副教授、教授四種。則，有效等價類（取四個職稱中的一個值）；無效等價類（四個職稱之外的任意值）等價類劃分劃分等價類規(guī)則如果規(guī)定了輸入數(shù)據必須遵守的規(guī)則，則可劃分符合規(guī)則等價類和一個違反規(guī)則的等價類。例：如果程序對不同職稱有不同的處理方案，如“住房分配”程序。則，有效等價類（四個職稱每個值為一類）；一個無效等價類（四個職稱之外的任意值）。等價類劃分劃分等價類規(guī)則如果規(guī)定了輸入數(shù)據是整型，則可劃分出正整數(shù)、零、負整數(shù)三個等價類如已劃分的等價類各元素在程序中的處理方式不同，則應將此等價類進一步劃分成更小的等價類等價類劃分用等價類劃分法設計測試用例步驟劃分等價類形成等價類表，每一等價類規(guī)定一個唯一的編號設計一測試用例，使其盡可能多地覆蓋尚未覆蓋的有效等價類，重復這一步驟，直到所有有效等價類均被測試用例所覆蓋設計一新測試用例，使其只覆蓋一個無效等價類，重復此步驟直到所有無效等價類均被覆蓋等價類劃分用等價類劃分法設計測試用例步驟例，某城市電話號碼由三部分組成地區(qū)碼：空白或3位數(shù)字前綴：非‘0’或‘1’開頭的三位數(shù)字后綴：4位數(shù)字第一步：電話號碼等價類劃分輸入條件地區(qū)碼前綴后綴第一步：電話號碼等價類劃分輸入條件有效等價類地區(qū)碼

空白(1)3位數(shù)字(2)前綴從200到999之間的3位數(shù)字(3)后綴4位數(shù)字(4)第一步：電話號碼等價類劃分輸入條件有效等價類無效等價類地區(qū)碼空白(1)3位數(shù)字(2)有非數(shù)字字符(5)少于3位數(shù)字(6)多于3位數(shù)字(7)前綴從200到999之間的3位數(shù)字(3)有非數(shù)字字符(8)起始位為‘0’

(9)起始位為‘1’

(10)少于3位數(shù)字(11)多于3位數(shù)字(12)后綴4位數(shù)字(4)有非數(shù)字字符(13)少于4位數(shù)字(14)多于4位數(shù)字(15)第二步：確定測試用例對表中4個有效等價類可共用下面兩個測試用例測試數(shù)據

測試范圍期望結果()276-2345等價類(1)(3)(4)有效(635)805-9321等價類(2)(3)(4)有效第二步：確定測試用例對表中11個無效等價類應選擇11個測試用例測試數(shù)據

測試范圍期望結果(20A)123-4567無效等價類(5)無效(33)234-5678無效等價類(6)無效(7777)345-6789無效等價類(7)無效………黑盒法邊界值測試被測試子域測試內點測試外點邊界值測試不是從某等價類中隨便挑一個作為代表，而是使這個等價類的每個邊界都要作為測試條件邊界值測試設計測試用例原則如輸入條件代表以a和b為邊界的范圍，測試用例應包含a、b、略大于a和略小于b的值邊界值測試設計測試用例原則例：每日保險扣除額在0～1165.25元則：應設計測試用例使其恰好產生0元和1165.25元的結果,此外還應考慮設計結果為負值或>1165.25元的測試用例。

(如:-0.01元和1165.26元)邊界值測試設計測試用例原則如輸入條件代表一組值，測試用例應當執(zhí)行其中的最大值和最小值，還應測試略大于最大值和略小于最小值的值邊界值測試設計測試用例舉例例：郵件收費規(guī)定1～5kg收費2元則：應設計測試用例:

0.9，1，5，5.1kg

或0.99，1，5，5.01kg例：一個數(shù)據庫表可有1～255個記錄則：應設計測試用例:

1個、255個、0個、256個記錄邊界值測試設計測試用例原則如程序數(shù)據結構有預定的邊界，應測試其邊界的數(shù)據項如輸出條件規(guī)定了取值范圍，取邊界上下浮動值做測試用例黑盒法錯誤推測測試基本思想：列舉出程序中可能有錯和容易出錯的情況，并且根據它們選擇測試方案如對一個數(shù)據庫表進行操作，需要特別檢查的情況有：表為空、表中只有一個記錄綜合策略黑盒法為主、白盒法為輔任何情況下都應該使用邊界值測試設計測試用例必要時采用等價分類法補充用例必要時再用錯誤推測法補充用例對照程序邏輯，檢查設計用例的邏輯覆蓋標準。根據程序可靠性要求，補充用例使之達到規(guī)定的覆蓋標準黑盒測試練習程序TRI讀入三個整數(shù)值，這三個整數(shù)代表同一個三角形三條邊的長度，程序根據這三個值判斷三角形屬于等腰、等邊、還是一般三角形。使用黑盒方法設計測試用例黑盒測試要測試的情況–

正常的不等邊三角形–

正常的等邊三角形–

正常的等腰三角形–

三條邊不構成三角形–

一條邊的長度為０–

兩條邊的長度為０–

三條邊全為０–

輸入數(shù)據中包含負整數(shù)–

輸入數(shù)據不全–

輸入數(shù)據中包含非整數(shù)型數(shù)據2.軟件測試基本原則嚴格按照測試計劃來測試盡早并不斷地進行測試程序員應盡可能避免檢查自己的程序測試用例應當兼顧合理的輸入條件和不合理的輸入條件測試用例應包括輸入數(shù)據和預期的輸出結果兩部分測試用例應當兼顧有用功能和無用功能全面檢查每個測試結果,保留測試用例充分注意測試中的集群現(xiàn)象注意回歸測試的關聯(lián)性注意遵守“經濟性”原則6.3.1軟件測試3.軟件測試步驟

6.3.1軟件測試規(guī)范化的測試過程與內容包括如下內容：擬定測試計劃：測試的內容、進度安排、測試所需的環(huán)境和條件、測試培訓安排等。編制測試大綱：明確詳細地規(guī)定了在測試中針對系統(tǒng)的每一項功能或特性所必須完成的基本測試項目和測試完成的標準。無論是自動測試還是手動測試，都必須滿足測試大綱的要求。設計和生成測試用例：產生測試設計說明文檔，其內容主要有：被測項目、輸入數(shù)據、測試過程、預期輸出結果等。實施測試：測試的實施階段時由一系列的測試周期組成的。生成測試報告：對測試進行概要說明，列出測試的結論，指出缺陷和錯誤，另外，給出一些建議。例如，可采用的修改方法，各項修改預計的工作量等。3.軟件測試步驟錯誤種類

測試中可能發(fā)現(xiàn)的錯誤按其性質可分為：

(1)功能錯誤由于處理功能說明不夠完整或不夠確切，致使編程時對功能有誤解而產生的錯誤(2)系統(tǒng)錯誤指與外部接口錯誤、子程序調用錯誤、參數(shù)使用錯誤等。

(3)過程錯誤主要指算術運算錯誤、邏輯錯誤等。

(4)數(shù)據錯誤數(shù)據結構、實體、屬性錯誤，參數(shù)與控制數(shù)據混淆等。

(5)編程錯誤語法錯誤、邏輯錯誤、編程書寫錯誤等。錯誤種類

程序錯誤一般包括數(shù)據缺陷控制缺陷計算缺陷接口缺陷輸入／輸出缺陷存儲管理缺陷異常處理缺陷等類型3.軟件測試步驟單元測試:單元測試是對源程序中的每一個程序單元進行測試，驗證每個模塊是否滿足系統(tǒng)設計說明書的要求?？墒褂冒缀袦y試方法測試單元的內部結構，使用黑盒測試方法測試單元的功能和可觀測的行為。3.軟件測試步驟單元測試主要從模塊的5個特征進行檢查：（1）模塊接口測試。對被測的模塊，信息能否正常無誤地流入和流出。例如，用被測模塊的輸入參數(shù)和形式參數(shù)在個數(shù)、屬性、單位上是否一致；調用其他模塊時所給的實際參數(shù)和被調模塊的形式參數(shù)在個數(shù)、屬性、單位上是否一致；全局變量在各模塊中的定義和用法是否一致；輸入是否僅改變了形式參數(shù)。（2）局部數(shù)據結構測試。在模塊工作過程中，其內部的數(shù)據能否保持其完整性，包括內部數(shù)據的內容、形式及相互關系不發(fā)生錯誤。例如，變量的說明是否合適；是否使用了尚未賦值或尚未初始化的變量；是否出現(xiàn)上溢、下溢或地址異常的錯誤等。3.軟件測試步驟單元測試主要從模塊的5個特征進行檢查：（3）路徑測試。模塊的運行能否達到滿足特定的邏輯覆蓋。（4）錯誤處理測試。模塊工作中發(fā)生了錯誤，其中的出錯處理設施是否有效。例如，在對錯誤進行處理之前，系統(tǒng)已經對錯誤條件干預；出錯的提示信息不足以確定錯誤或確定造成錯誤的原因；錯誤的描述難于理解等。（5）邊界測試。在為限制數(shù)據加工而設置的邊界處，模塊是否能夠正常工作。3.軟件測試步驟單元測試過程由于每個模塊在整個軟件中并不是孤立的，在對每個模塊進行單元測試時，也不能完全忽視它們和周圍模塊的相互聯(lián)系。為模擬這一聯(lián)系，在進行單元測試時，需設置若干輔助測試模塊。輔助模塊有兩種：一種是驅動模塊，用以模擬被測模塊的上級模塊；另一種是樁模塊，用以模擬被測模塊工作過程中所調用的模塊。在測試過程中，需要對整個測試過程進行有效的管理，保證測試質量和測試效率。3.軟件測試步驟3.軟件測試步驟驅動模塊：是模擬待測模塊X的調用模塊，其作用是將測試數(shù)據傳送給待測模塊X，并顯示待測模塊X的結果AXY………………待測模塊X驅動集成測試：3.軟件測試步驟樁模塊：作用是模擬待測模塊X的下層模塊E。其作用是接受待測模塊X的控制并模擬下層模塊E的功能AXY……………待測模塊X樁1集成測試：E例：下圖是新生管理子系統(tǒng)的功能層次圖：3.軟件測試步驟新生基本信息管理招生數(shù)據導入報到預處理新生報到管理新生信息查詢與統(tǒng)計預分學號班級編排寢室安排預處理查詢現(xiàn)場報到處理欠費查詢統(tǒng)計報到情況統(tǒng)計新生比例分布高考成績統(tǒng)計考例：下圖是新生管理子系統(tǒng)的功能層次圖：要測試“新生信息查詢與統(tǒng)計”模塊，由于它不是獨立運行的程序，需要有一個驅動模塊來調用它，驅動模塊要說明必需的變量、接收測試數(shù)據----模擬總控模塊來調用它。另外還需要準備樁模塊來代替被調用的子模塊（新生比例分布、高考成績統(tǒng)計），對于多個子模塊可以用一個樁模塊來代替。在測試時，用控制變量DISCOUNT—TYPE標記是新生比例分布還是高考成績統(tǒng)計。新生基本信息管理招生數(shù)據導入報到預處理新生報到管理新生信息查詢與統(tǒng)計預分學號班級編排寢室安排預處理查詢現(xiàn)場報到處理欠費查詢統(tǒng)計報到情況統(tǒng)計新生比例分布高考成績統(tǒng)計。

3.軟件測試步驟下面是偽碼編寫的驅動模塊和樁模塊。驅動模塊的偽碼：TESTDRIVERWHILE未到文件尾部讀取輸入信息

IF輸入信息是調用“新生信息查詢與統(tǒng)計”模塊調用“新生信息查詢與統(tǒng)計”模塊

ENDIFENDWHILEENDTESTDRIVER

3.軟件測試步驟樁模塊的偽碼：TESTSTUBIFDISCOUNT—TYPE=“新生比例分布”輸出“新生比例分布模塊”

ELSE

輸出“高考成績統(tǒng)計模塊”

ENDIFENDTESTSTUB

3.軟件測試步驟集成測試:集成測試是將已測試過的模塊組合成子系統(tǒng)，重點測試各模塊之間接口和聯(lián)系。它所測試的內容包括：單元間的接口以及集成后的功能。使用黑盒測試方法測試集成的功能，并且對以前的集成進行回歸測試。

3.軟件測試步驟集成測試方法：一種是分別測試各個模塊，再把這些模塊組合起來進行整體測試，這種方法稱為非增量式集成。非增量式集成可以對模塊進行并行測試，能充分利用人力，加快工程進度。但這種方法容易混亂，出現(xiàn)錯誤不容易查找和定位。另一種是把一個要測試的模塊組合到已測試好的模塊中，測試完后再將一個需要測試的模塊組合進來測試，逐步把所有模塊組合在一起，并完成測試。該方法稱為增量式集成。增量式測試的范圍是一步步擴大的，所以錯誤容易定位，而且已測試的模塊可在新的條件下進行測試，程序測試得更徹底。增量式測試有自頂向下的增量方式和自底向上的增量方式兩種測試方法。3.軟件測試步驟1)自頂向下的增量方式模塊按程序的控制結構，從上到下的組合方式。再增加測試模塊時有先深度后寬度和先寬度后深度兩種次序。如圖所示的自頂向下組合示例中，先深度后寬度的方法是把程序結構中的一條主路徑上的模塊相組合。3.軟件測試步驟1)自頂向下的增量方式測試順序可以是M1→M2→M5→M6→M3→M7→M4。先寬度后深度的方法是把模塊按層次進行組合，測試順序是M1→M2→M3→M4→M5→M6→M7。自頂向下的增量方式可以較早地驗證控制和判定點，如果出現(xiàn)問題能夠及時糾正。在測試時不需要編寫驅動模塊，但需要樁模塊。另外，如果高層，模塊依賴性很大，需要返回大量信息，在用樁模塊代替時，樁模塊的編寫就復雜，必然會增加開銷。這時可以用下面的自底向上的增量方式。3.軟件測試步驟2)自底向上的增量方式自底向上的增量方式是從最底層的功能模塊開始，邊組合邊測試，從下向上地完成整個程序結構的測試。例如，在圖7.4所示的“新生基本信息管理”系統(tǒng)中，在單元測試的基礎上，從最底層模塊開始，按功能組合模塊，從下到上的進行測試。這樣的測試方式可以較早地發(fā)現(xiàn)底層關鍵性模塊出現(xiàn)的錯誤。在測試時不需要編寫樁模塊，但需要驅動模塊。另外，對程序中的主要控制錯誤發(fā)現(xiàn)較晚。3.軟件測試步驟集成測試

兩種方法的比較缺點：1.需要驅動程序2.要在功能測試前進行大量測試

自底向上測試

缺點：1.需專門編寫程序模擬模塊

2.難以全面測試每個模塊3.一些邏輯條件不能被測試自頂向上測試

缺點

比較集成測試確認測試通過集成測試后，軟件已完全組裝起來，接口方面的錯誤也已排除，確認測試即可開始。確認測試應檢查軟件能否按合同要求進行工作，即是否滿足系統(tǒng)說明書中的確認標準。首先要進行有效性測試以及軟件配置評審，然后進行驗收測試和安裝測試，在通過了鑒定之后，才能成為可交付的軟件。確認測試的步驟：3.軟件測試步驟1)確認測試標準實現(xiàn)軟件確認要通過一系列黑盒測試。確認測試同樣需要制訂測試計劃和過程，測試計劃應規(guī)定測試的種類和測試進度，測試過程則定義一些特殊的測試用例，旨在說明軟件與需求是否一致。無論是計劃還是過程，都應該著重考慮軟件是否滿足合同規(guī)定的所有功能和性能，文檔資料是否完整、準確，人機界面和其他方面（例如，可移植性、兼容性、錯誤恢復能力和可維護性等）是否令用戶滿意。確認測試的結果有兩種可能，一種是功能和性能指標滿足軟件需求說明的要求，用戶可以接受；另一種是軟件不滿足軟件需求說明的要求，用戶無法接受。項目進行到這個階段才發(fā)現(xiàn)嚴重錯誤和偏差一般很難在預定的工期內改正，因此必須與用戶協(xié)商，尋求一個妥善解決問題的方法。

3.軟件測試步驟2)配置復審確認測試的另一個重要環(huán)節(jié)是配置復審。復審的目的在于保證軟件配置齊全、分類有序，并且包括軟件維護所必須的細節(jié)。3.軟件測試步驟3.軟件測試步驟

測試：由用戶在開發(fā)環(huán)境下模擬實際操作環(huán)境運行程序系統(tǒng)目的是評價軟件產品的功能、可用性、可靠性、性能和支持，系統(tǒng)的界面的特色方法是由開發(fā)者在場記錄系統(tǒng)出錯情況及使用中存在的問題3.軟件測試步驟

測試：由系統(tǒng)一個或多個用戶在實際操作環(huán)境中運行系統(tǒng)目的是評價系統(tǒng)的可支持性，包括文檔的完整性、用戶培訓和支持、使用系統(tǒng)的能力和滿意程度方法是開發(fā)者不在測試現(xiàn)場，由用戶記錄的問題可能是系統(tǒng)存在的錯誤，也可能是用戶的主觀認定系統(tǒng)測試系統(tǒng)測試是對整個系統(tǒng)進行總的功能、性能等方面的測試。將已經確認的軟件、硬件等其他元素結合在一起，進行系統(tǒng)的各種集成測試和技術測試。其目的是通過與系統(tǒng)的需求相比較，發(fā)現(xiàn)所開發(fā)的系統(tǒng)與用戶需求不符或矛盾的地方。1)系統(tǒng)測試需求獲取系統(tǒng)測試需求所確定的是測試的內容，即測試的具體對象。系統(tǒng)測試需求主要來源于需求規(guī)格說明書。在分析測試需求時，可應用以下幾條一般規(guī)則：測試需求必須是可觀測、可測評的行為。如果不能觀測或測評的測試需求，就無法對其進行評估，以確定需求是否已經滿足。

3.軟件測試步驟在每個用例或系統(tǒng)的補充需求與測試需求之間不存在一對一的關系。用例通常具有多個測試需求；有些補充需求將派生一個或多個測試需求，而其他補充需求（如市場需求或包裝需求）將不派生任何測試需求。在需求規(guī)格說明書中每一個功能描述將派生一個或多個測試需求，性能描述、安全性描述等也將派生出一個或多個測試需求。2)系統(tǒng)測試策略測試策略用于說明某項特定測試工作的一般方法和目標。系統(tǒng)測試策略主要針對系統(tǒng)測試需求確定測試類型及如何實施測試的方法和技術。3.軟件測試步驟系統(tǒng)測試的測試類型一般包括：功能測試（FunctionalTesting）性能測試（PerformanceTesting）負載測試（LoadTesting）強度測試（StressTesting）容量測試（VolumeTesting）安全性測試（SecurityTesting）配置測試（ConfigurationTesting）故障恢復測試（RecoveryTesting）安裝測試（InstallationTesting）文檔測試（DocumentationTesting）用戶界面測試（GUITesting）3.軟件測試步驟［功能測試］功能測試是系統(tǒng)測試中最基本的測試，它不管軟件內部的實現(xiàn)邏輯，主要根據軟件需求規(guī)格說明和測試需求列表，驗證產品的功能實現(xiàn)是否符合需求規(guī)格。功能測試主要發(fā)現(xiàn)以下錯誤：是否有不正確或遺漏的功能？功能實現(xiàn)是否滿足用戶需求和系統(tǒng)設計的隱藏需求？能否正確地接受輸入？能否正確地輸出結果？［性能測試］對于那些實時和嵌入式系統(tǒng)，軟件部分即使?jié)M足功能要求，也未必能夠滿足性能要求，雖然從單元測試起，每一測試步驟都包含性能測試，但只有當系統(tǒng)真正集成之后，在真實環(huán)境中才能全面、可靠地測試運行性能系統(tǒng)性能測試是為了完成這一任務。性能測試有時與強度測試相結合，經常需要其他軟硬件的配套支持。3.軟件測試步驟［安全性測試］安全測試檢查系統(tǒng)對非法侵入的防范能力。安全測試期間，測試人員假扮非法入侵者，采用各種辦法試圖突破防線。下面列舉一些安全性測試的例子：想方設法截取或破譯口令；專門定做軟件破壞系統(tǒng)的保護機制；故意導致系統(tǒng)失敗，企圖趁恢復之機非法進入；試圖通過瀏覽非保密數(shù)據，推導所需信息。3.軟件測試步驟［恢復測試］恢復測試是檢驗系統(tǒng)從軟件或者硬件失敗中恢復的能力，即采用各種人工干預方式使軟件出錯，而不能正常工作，從而檢驗系統(tǒng)的恢復能力。下面列舉一些恢復測試的例子：當供電出現(xiàn)問題時的恢復恢復程序的執(zhí)行對選擇的文件和數(shù)據進行恢復恢復處理日志方面的能力通過切換到一個并行系統(tǒng)來進行恢復3.軟件測試步驟［安裝測試］系統(tǒng)驗收之后，需要在目標環(huán)境中進行安裝。安裝測試的目的是保證應用程序能夠被成功地安裝，它重點考慮以下方面：應用程序是否可以成功地安裝在以前從未安裝過的環(huán)境中？應用程序是否可以成功地安裝在以前已有的環(huán)境中？配置信息定義正確嗎？考慮到以前的配置信息嗎？在線文檔安裝正確嗎？安裝應用程序是否會影響其他的應用程序嗎？對于該應用程序來說，計算機資源是否充足？安裝程序是否可以檢測到資源的情況并做出適當?shù)姆磻?.軟件測試步驟

編寫測試文檔，該文檔應該描述要執(zhí)行的軟件測試及測試的結果，主要包括以下部分：測試計劃：測試計劃是測試工作的指導性文檔，它規(guī)定測試活動的范圍、方法、資源和進度，明確正在測試的項目、要測試的特性、要執(zhí)行的測試任務、每個任務的負責人，以及與計劃相關的風險。其主要內容包括測試目標、測試方法、測試范圍、測試資源、測試環(huán)境和工具、測試體系結構、測試進度表等。

3.軟件測試步驟測試計劃

測試計劃的內容

五制定衡量測試成功與完成的準則。

四建立用于計劃和進行測試以及報告測試結果的規(guī)程和標準；

三確定工具、設施和測試庫的可用性；

二確定每項測試活動的進度和職責；

一建立每個測試階段的目標；

編寫測試文檔，該文檔應該描述要執(zhí)行的軟件測試及測試的結果，主要包括以下部分：測試用例：測試用例是數(shù)據輸入和期望結果組成的對，其中“輸入”是對被測軟件接收外界數(shù)據的描述，“期望結果”是對于相應輸入軟件應該出現(xiàn)的輸出結果的描述，測試用例還應明確指出使用具體測試案例產生的測試程序的任何限制。測試用例可以被組織成一個測試系列，即為實現(xiàn)某個特定的測試目的而設計的一組測試用例。

3.軟件測試步驟缺陷報告：缺陷報告是編寫在需要調查研究的測試過程期間發(fā)生的任何事件，即記錄軟件缺陷。其主要內容包括缺陷編號、題目、狀態(tài)、提出、解決、所屬項目、測試環(huán)境、缺限報告執(zhí)行步驟、期待結果、附件等。在報告缺陷時，一般要講明缺限的嚴重性和優(yōu)先級。其中嚴重性表示軟件的惡劣程度，反映其對產品和用戶的影響；優(yōu)先級表示修復缺陷的重要程度和應該何時修復。測試總結報告：該文檔列出測試中發(fā)現(xiàn)的和需要調查的所有失敗情況。從測試總結報告中，開發(fā)人員對每次失效進行分析并區(qū)分優(yōu)先次序，進而為系統(tǒng)和模型中的變化進行設計。

3.軟件測試步驟

案例研究微軟的測試工作微軟的測試工作

基本情況測試在微軟公司是一項非常重要的工作，微軟公司在此方面的投入是非常巨大的。微軟對測試的重視表現(xiàn)在工程開發(fā)隊伍的人員構成上，微軟的項目經理、軟件開發(fā)人員和測試人員的比例基本是1：3：3。對于測試的重視還表現(xiàn)在最后產品要發(fā)布的時候，此產品的所有相關部門都必須簽字，而測試人員則具有絕對的否決權。

微軟的測試工作

測試計劃測試計劃是測試人員管理測試項目，在軟件中尋找Bug的一種有效的工具。測試計劃主要有兩個作用：評判團隊的測試覆蓋率以及效率，讓測試工作很有條理的逐步展開；有利于與項目經理、開發(fā)人員進行溝通。

測試計劃

測試文檔測試人員在編寫測試計劃之前，應獲得以下文檔：程序經理編寫的產品功能說明書或產品開發(fā)計劃；程序經理或開發(fā)人員提供的開發(fā)進度表。測試計劃

測試計劃的內容測試目標和發(fā)布條件給出清晰的測試目標描述定義產品的發(fā)布條件待測產品范圍軟件主要特性/功能說明特性/功能測試一覽測試計劃

測試計劃的內容測試方法描述定義測試軟件產品時使用的測試方法；描述每一種特定的測試方法可以覆蓋哪些測試范圍。測試進度表定義測試里程碑；定義當前里程碑的詳細測試進度。測試計劃

測試計劃的內容測試資源和相關的程序經理/開發(fā)工程師定義參與測試的人員；描述每位測試人員的職責范圍；給出與測試有關的程序經理/開發(fā)工程師的相關信息。配置范圍和測試工具給出測試時使用的所有計算機平臺列表；描述測試覆蓋了哪些硬件設備；測試時使用的主要測試工具。微軟的測試工作

測試用例開發(fā)

一個好的測試用例就是有一個合理的概率來找到Bug，不要冗余，要有針對性，一個測試只針對一件事情。測試用例開發(fā)中主要使用的技術有等價類劃分，邊界值的分析，ErrorGuessingTesting。

微軟的測試工作

Bug跟蹤過程

測試工程師向項目組報告該Bug的位置、表現(xiàn)、當前狀態(tài)等信息，項目組在Bug數(shù)據庫中添加該Bug的記錄

開發(fā)經理對已發(fā)現(xiàn)的Bug進行集中討論，根據Bug對產品的影響來評估其優(yōu)先級，制定Bug的修正策略

開發(fā)工程師對特定的Bug進行處理，找出代碼中的錯誤原因，修改代碼，重新生成產品版本

測試人員對處理后的結果進行測試，工程師驗證Bug是否已被修正并確定開發(fā)人員有無在改代碼時引入新Bug1234微軟的測試工作

Bug的不同處理方式

在某些情況下，Bug已處理并不意味著Bug已經被修正。開發(fā)工程師可以推遲Bug的修正時間，也可以在分析之后告知測試工程師這實際上不是一個真正的Bug。

Bug的不同處理方式

Bug的狀態(tài)已修正

開發(fā)工程師已經修正了相應的程序代碼，該Bug不會出現(xiàn)了?？赏七t

該Bug的重要程度較低，不會影響當前應提交版本的主要功能，可安排在下一版本中再行處理。

設計問題

該Bug與程序實現(xiàn)無關，其所表現(xiàn)出來的行為完全符合設計要求，對此應提交給程序經理處理。

無需修正

該Bug的重要程度非常低，根本不會影響程序的功能，項目組沒有必要在這些Bug上浪費時間。

帕雷托分析

你相信嗎？

80%的軟件錯誤是由20%的代碼引起的

20％的模塊消耗80％的資源

20％的模塊包含80％的錯誤

20％的錯誤消耗80％的修改成本

20％的模塊占用了80％的執(zhí)行時間

80%的商業(yè)利潤是由20%的客戶帶來的微軟的測試工作1.軟件調試過程6.3.2軟件調試1.5.4MIS的結構從技術角度來看，查找錯誤的難度在于：現(xiàn)象與原因所處的位置可能相距甚遠。當其它錯誤糾正時，此錯誤所表現(xiàn)的現(xiàn)象可能會暫時消失，但并未實際排除?，F(xiàn)象實際上是由一些非錯誤原因（如舍入不精確）引起的。現(xiàn)象可能是由于一些不容易發(fā)現(xiàn)的人為錯誤引起的。錯誤是由于時序問題引起的，與處理過程無關?，F(xiàn)象是由于難于精確再現(xiàn)的輸入狀態(tài)引起?，F(xiàn)象可能是周期出現(xiàn)的，在嵌入式系統(tǒng)中常常遇到。6.3.2軟件調試6.3.2軟件調試調試方法試探法基本思路：先分析錯誤的表現(xiàn)形式，猜想程序故障的大致位置，然后使用一些簡單、常用的糾錯技術，獲取可疑區(qū)域的有關信息，判斷猜想是否正確。經過多次試探，找到錯誤根源跟蹤法基本思路：正向跟蹤的思路是沿著程序的控制流，從頭開始跟蹤，逐步檢查中間結果，找到最先出錯的地方

基本思路：反向跟蹤的思路是從發(fā)現(xiàn)錯誤癥狀的地方開始回溯，即人工沿著程序的控制流往回追蹤程序代碼，一直到找出錯誤的位置或確定故障的范圍為止。

對分查找法基本思路：