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

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

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

6.1物理系統(tǒng)的實(shí)施6.2程序設(shè)計(jì)6.3軟件測試與調(diào)試6.4人員培訓(xùn)6.5系統(tǒng)轉(zhuǎn)換第六章管理信息系統(tǒng)的實(shí)施

系統(tǒng)實(shí)施概述

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

硬件準(zhǔn)備包括計(jì)算機(jī)主機(jī)、輸入輸出設(shè)備、存儲(chǔ)設(shè)備、輔助設(shè)備（穩(wěn)壓電源、空調(diào)設(shè)備）、通信設(shè)備等。2、軟件準(zhǔn)備

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

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

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

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

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

MIS物理系統(tǒng)的實(shí)施是計(jì)算機(jī)系統(tǒng)和通信網(wǎng)絡(luò)系統(tǒng)設(shè)備的訂購、機(jī)房的準(zhǔn)備和設(shè)備的安裝調(diào)試等一系列活動(dòng)。6.1.1選擇供應(yīng)商的標(biāo)準(zhǔn)系統(tǒng)安裝主要是指對(duì)各種軟、硬件設(shè)備的購置、安裝以及整個(gè)系統(tǒng)調(diào)試運(yùn)行選擇供應(yīng)商的標(biāo)準(zhǔn)是：實(shí)力雄厚、信譽(yù)可靠、質(zhì)優(yōu)價(jià)低、售后服務(wù)好6.1物理系統(tǒng)的實(shí)施6.1.2選擇安裝地點(diǎn)的思路

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

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

程序設(shè)計(jì)的目標(biāo)⑵可靠性：程序應(yīng)具有較好的容錯(cuò)能力。正常情況下能正確工作。意外情況下應(yīng)便于處理，不至產(chǎn)生意外的操作，從而造成嚴(yán)重?fù)p失。

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

程序設(shè)計(jì)的目標(biāo)⑷效率：程序能否有效地利用計(jì)算機(jī)資源程序效率的地位：已不像以前那樣舉足輕重了，因?yàn)橛布r(jià)格大幅度下降，而其性能卻不斷完善和提高。程序設(shè)計(jì)人員工作效率的地位日益重要。不僅能降低軟件開發(fā)成本；而且可明顯降低程序的出錯(cuò)率，進(jìn)而減輕維護(hù)人員的工作負(fù)擔(dān)。為了提高程序設(shè)計(jì)效率，應(yīng)充分利用各種軟件開發(fā)工具。

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

6.2程序設(shè)計(jì)1.程序設(shè)計(jì)的任務(wù)根據(jù)系統(tǒng)設(shè)計(jì)說明書中關(guān)于模塊的詳細(xì)描述和處理過程的描述，選擇合適的計(jì)算機(jī)語言來編制程序的工作。6.2程序設(shè)計(jì)程序設(shè)計(jì)的方法結(jié)構(gòu)化程序設(shè)計(jì)方法程序設(shè)計(jì)就是處理過程的設(shè)計(jì)面向?qū)ο蟪绦蛟O(shè)計(jì)方法程序設(shè)計(jì)主要指對(duì)象的設(shè)計(jì)可視化編程工具或開發(fā)環(huán)境

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

面向?qū)ο蟪绦蛟O(shè)計(jì)在OOP方法中，一個(gè)對(duì)象即是一個(gè)獨(dú)立存在的實(shí)體，對(duì)象有各自的屬性和行為，彼此以消息進(jìn)行通信。對(duì)象的屬性只能通過自己的行為來改變，實(shí)現(xiàn)了數(shù)據(jù)封裝，這便是對(duì)象的封裝性。而相關(guān)對(duì)象在進(jìn)行合并分類后，有可能出現(xiàn)共享某些性質(zhì)，通過抽象后使多種相關(guān)對(duì)象表現(xiàn)為一定的組織層次，底層次的對(duì)象繼承其高層次對(duì)象的特性，這便是對(duì)象的繼承性。另外，對(duì)象的某一種操作在不同的條件環(huán)境下可以實(shí)現(xiàn)不同的處理，產(chǎn)生不同的結(jié)果，這就是對(duì)象的多態(tài)性?？梢暬幊碳夹g(shù)

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

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

程序錯(cuò)誤的分類

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

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

⑵MSVisualBASlC

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

基本特征是在對(duì)軟件進(jìn)行分析、檢查和測試，不實(shí)際運(yùn)行被測試的軟件約可找出30～70%的邏輯設(shè)計(jì)錯(cuò)誤

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

白盒測試方案時(shí)，測試者必須檢查程序的內(nèi)部結(jié)構(gòu)，從檢查程序的邏輯著手，對(duì)所有邏輯路徑進(jìn)行測試，得出測試數(shù)據(jù)。白盒測試的主要方法:邏輯驅(qū)動(dòng)、路徑測試等，主要用于軟件驗(yàn)證，檢驗(yàn)語法錯(cuò)誤、編譯錯(cuò)誤、性能問題、邏輯問題、判定條件問題、編程規(guī)范等。

白盒測試白盒測試

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

白盒測試白盒測試

缺點(diǎn)

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

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

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

123

白盒測試白盒測試

測試用例的設(shè)計(jì)語句覆蓋法測試用例覆蓋路徑A=2B=0X=3aceA>1ANDB=0X=X/AA=2ORX>1X=X+1是a是否bcdeace白盒測試判斷覆蓋法序號(hào)測試用例覆蓋路徑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(chǔ)>1A≤1TFB=0B≠0TFA=2A≠2TFX>1X≤1TF白盒測試條件判斷條件取值條件記為條件1A>1A≤1TFT1F1條件2B=0B≠0TFT2F2條件3A=2A≠2TFT3F3條件4X>1X≤1TFT4F4條件一條件二設(shè)計(jì)的測試用例子序號(hào)測試用例覆蓋路徑條件記為1A=2B=0X=4aceT1T2T3T42A=1B=1X=1abdF1F2F3F43A=2B=0X=1acdT1T2T3F44A=1B=1X=2abeF1F2F3T4白盒測試設(shè)計(jì)測試用例白盒測試條件組合覆蓋法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設(shè)計(jì)的測試用例序號(hào)測試用例覆蓋路徑覆蓋條件組合1A=2B=0X=4ace1,52A=2B=1X=1abd2,63A=1B=0X=2abe3,74A=1B=1X=1abd4,8設(shè)計(jì)的測試用例白盒測試白盒測試路徑覆蓋法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ù)據(jù)驅(qū)動(dòng)測試，它是在已知產(chǎn)品所應(yīng)具有的功能，通過測試來檢測每個(gè)功能是否都能正常使用。它只檢查程序功能是否按照需求規(guī)格說明書的規(guī)定正常使用，程序是否能適當(dāng)?shù)亟邮蛰斎霐?shù)鋸而產(chǎn)生正確的輸出信息，并且保持外部信息（如數(shù)據(jù)庫或文件）的完整性。黑盒測試發(fā)現(xiàn)的錯(cuò)誤類型有：功能不對(duì)或遺漏、界面錯(cuò)誤、數(shù)據(jù)結(jié)構(gòu)或外部數(shù)據(jù)庫訪問錯(cuò)誤、性能錯(cuò)誤、初始化和終止錯(cuò)誤等。黑盒測試方法主要有等價(jià)類劃分、邊界值分析、因—果圖、錯(cuò)誤推測等，主要用于軟件確認(rèn)測試。“黑盒”法是窮舉輸入測試，只有把所有可能的輸入都作為測試情況使用，才能以這種方法查出程序中所有的錯(cuò)誤。黑盒測試黑盒測試

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

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

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

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

缺點(diǎn)不可能覆蓋所有的代碼，覆蓋率較低。

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

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

1999

有效等價(jià)類無效等價(jià)類

>999無效等價(jià)類

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

空白(1)3位數(shù)字(2)前綴從200到999之間的3位數(shù)字(3)后綴4位數(shù)字(4)第一步：電話號(hào)碼等價(jià)類劃分輸入條件有效等價(jià)類無效等價(jià)類地區(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)第二步：確定測試用例對(duì)表中4個(gè)有效等價(jià)類可共用下面兩個(gè)測試用例測試數(shù)據(jù)

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

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

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

0.9，1，5，5.1kg

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

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

正常的不等邊三角形–

正常的等邊三角形–

正常的等腰三角形–

三條邊不構(gòu)成三角形–

一條邊的長度為０–

兩條邊的長度為０–

三條邊全為０–

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

輸入數(shù)據(jù)不全–

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

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

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

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

(3)過程錯(cuò)誤主要指算術(shù)運(yùn)算錯(cuò)誤、邏輯錯(cuò)誤等。

(4)數(shù)據(jù)錯(cuò)誤數(shù)據(jù)結(jié)構(gòu)、實(shí)體、屬性錯(cuò)誤，參數(shù)與控制數(shù)據(jù)混淆等。

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

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

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

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

ENDIFENDWHILEENDTESTDRIVER

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

ELSE

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

ENDIFENDTESTSTUB

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

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

兩種方法的比較缺點(diǎn)：1.需要驅(qū)動(dòng)程序2.要在功能測試前進(jìn)行大量測試

自底向上測試

缺點(diǎn)：1.需專門編寫程序模擬模塊

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

缺點(diǎn)

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

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

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

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

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

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

3.軟件測試步驟測試計(jì)劃

測試計(jì)劃的內(nèi)容

五制定衡量測試成功與完成的準(zhǔn)則。

四建立用于計(jì)劃和進(jìn)行測試以及報(bào)告測試結(jié)果的規(guī)程和標(biāo)準(zhǔn)；

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

二確定每項(xiàng)測試活動(dòng)的進(jìn)度和職責(zé)；

一建立每個(gè)測試階段的目標(biāo)；

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

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

3.軟件測試步驟

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

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

微軟的測試工作

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

測試計(jì)劃

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

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

測試計(jì)劃的內(nèi)容測試方法描述定義測試軟件產(chǎn)品時(shí)使用的測試方法；描述每一種特定的測試方法可以覆蓋哪些測試范圍。測試進(jìn)度表定義測試?yán)锍瘫?；定義當(dāng)前里程碑的詳細(xì)測試進(jìn)度。測試計(jì)劃

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

測試用例開發(fā)

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

微軟的測試工作

Bug跟蹤過程

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

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

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

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

Bug的不同處理方式

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

Bug的不同處理方式

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

開發(fā)工程師已經(jīng)修正了相應(yīng)的程序代碼，該Bug不會(huì)出現(xiàn)了。可推遲

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

設(shè)計(jì)問題

該Bug與程序?qū)崿F(xiàn)無關(guān)，其所表現(xiàn)出來的行為完全符合設(shè)計(jì)要求，對(duì)此應(yīng)提交給程序經(jīng)理處理。

無需修正

該Bug的重要程度非常低，根本不會(huì)影響程序的功能，項(xiàng)目組沒有必要在這些Bug上浪費(fèi)時(shí)間。

帕雷托分析

你相信嗎？

80%的軟件錯(cuò)誤是由20%的代碼引起的

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

20％的模塊包含80％的錯(cuò)誤

20％的錯(cuò)誤消耗80％的修改成本

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

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

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

對(duì)分查找法基本思路：