【正文】 們安排合適的資源和進度，避免可能的風險，有助于實現(xiàn)以下目標：（1）確定現(xiàn)有項目的信息和應(yīng)測試的軟件構(gòu)件。（2）列出推薦的測試需求。（3）推薦可采用的測試策略。（4）確定測試所需的時間和資源，以保證其可獲得性和有效性。（5）確立每個測試階段的測試完成及測試成功的標準和實現(xiàn)的目標。 定義軟件測試的標準　組織者在指定范圍內(nèi)選擇軟件測試遵循的標準，并結(jié)合本軟件系統(tǒng)的具體要求，使之貫徹到整個軟件測試的計劃、實現(xiàn)和管理過程之中[8]。 測試實施策略的制定測試策略描述當前測試項目的目標和所采用的測試方法。這個目標不是測試計劃的目標，而是針對某個應(yīng)用軟件系統(tǒng)或程序、具體的測試項目要達到的預(yù)期結(jié)果，包括在規(guī)定的時間內(nèi)哪些測試內(nèi)容要完成、軟件產(chǎn)品的特性或質(zhì)量在哪些方面得到確認。 測試計劃的要點（1）計劃的目的：項目的范圍和目標，各階段的測試范圍、技術(shù)約束和管理特點。（2）項目估算：使用的歷史數(shù)據(jù)、評估技術(shù)作為工作量、成本、時間的估算依據(jù)。（3）風險計劃：測試可能存在的風險分析、識別以及風險的回避監(jiān)控和管理。（4）計劃的日程：項目工作分解結(jié)構(gòu)，并采用時限圖、甘特圖等方法制定時間和資源表。（5）項目資源：對人員、硬件和軟件等資源的組織和分配，人力資源是重點，而且和日程安排聯(lián)系緊密。（6）跟蹤和控制機制：質(zhì)量保證和控制、變更管理和控制。 測試的基礎(chǔ) 測試的目標測試是為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程，好的測試方案是極可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯誤的測試方案，成功的測試是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn)的錯誤的測試。 白盒測試和黑盒測試測試任何產(chǎn)品都有兩種方法：如果已經(jīng)知道了產(chǎn)品應(yīng)該具有的功能，可以通過測試來檢驗是否每個功能都能正常使用；如果知道產(chǎn)品內(nèi)部工作過程，可以通過測試來檢驗產(chǎn)品內(nèi)部動作是否按照規(guī)格說明書的規(guī)定正常進行。前一個方法稱為黑盒測試，后一個方法稱為白盒測試。白盒測試，所關(guān)注的是：測試用例執(zhí)行的程度或覆蓋程序邏輯結(jié)構(gòu)的程度，也可以認為是邏輯覆蓋測試。具體方法有五個，按其邏輯覆蓋的從弱到強依次為：語句覆蓋（面）、判定/分支覆蓋（線）、條件覆蓋（點）、判定/條件覆蓋（點線結(jié)合）、多重條件覆蓋（點線組合）。黑盒測試也稱功能測試，它是通過測試來檢測每個功能是否都能正常使用。它只檢查程序功能是否按照需求規(guī)格說明書的規(guī)定正常使用，程序是否能適當?shù)亟邮蛰斎霐?shù)據(jù)而產(chǎn)生正確的輸出信息。黑盒測試著眼于程序外部結(jié)構(gòu)，不考慮內(nèi)部邏輯結(jié)構(gòu)，主要針對軟件界面和軟件功能進行測試。 測試的原則軟件測試從不同的角度出發(fā)會派生出兩種不同的測試原則，從用戶的角度出發(fā)，就是希望通過軟件測試能充分暴露軟件中存在的問題和缺陷，從而考慮是否可以接受該產(chǎn)品，從開發(fā)者的角度出發(fā)，就是希望測試能表明軟件產(chǎn)品不存在錯誤，已經(jīng)正確地實現(xiàn)了用戶的需求，確立人們對軟件質(zhì)量的信心。中國軟件評測中心的測試原則就是從用戶和開發(fā)者的角度出發(fā)進行軟件產(chǎn)品測試的，通過的測試，可以為用戶提供放心的產(chǎn)品，并對優(yōu)秀的產(chǎn)品進行認證。 測試用例設(shè)計 等價類測試用例設(shè)計驗證管理員的規(guī)格說明在圖書借閱管理系統(tǒng)中對管理員的信息的規(guī)定：“管理員帳號可以是任意數(shù)字、字母的組合，帳號長度為68個字符。管理員密碼可以為字母和數(shù)字的組合，密碼長度要求為620個字符”。用等價類劃分的方法得到上述規(guī)格說明的要求，建立輸入等價類表格。 管理員帳號等價類表輸入條件有效等價類無效等價類管理員帳號組成數(shù)字（1），字母（2）非數(shù)字或字母（3）管理員字符個數(shù)68個（4）0個（5），8個（6）下面選取了6個測試用例，其中前兩個覆蓋了所有的有效等價類，其他的覆蓋了4個無效等價類。輸入：abc123 }覆蓋（1），（2），（4）等價類輸入：001001 }覆蓋（1），（4）等價類輸入：ab1234 }管理員帳號有非法字符，覆蓋（3）等價類輸入：空 }管理員帳號為0個字符，覆蓋（5）等價類輸入：123455q6q7q5 }管理員帳號多于8個字符，覆蓋（6）等價類 管理員密碼等價類表輸入條件有效等價類無效等價類管理員密碼組成數(shù)字（1），字母（2）非數(shù)字或字母（3）管理員密碼字符個數(shù)620個（4）0個（5），20個（6）下面選取了4個測試用例，其中第一個覆蓋了所有的有效等價類，其他的覆蓋了3個無效等價類。輸入：abc123 }覆蓋（1），（2），（4）等價類輸入：qqs*123 }密碼有非法字符，覆蓋（3）等價類輸入：空 }密碼為0個字符，覆蓋（5）等價類輸入：123456asdaaasdfghhhfssee }密碼多于20個字符，覆蓋（6）等價類 邊界值測試用例設(shè)計圖書借閱的規(guī)格說明：輸入文件由圖書的借書信息組成，其中重要信息組成如下：（1）圖書編號。這是圖書的唯一編號，一般由數(shù)字或字母組成，長度為8個字符。（2）讀者帳號。這是讀者的唯一帳號，一般數(shù)字或字母組成，長度為68個字符。（3）借書量。是指讀者當前所借書的數(shù)量與未還書的數(shù)量之和。一個讀者最多只能借5本書，否則不可借閱。根據(jù)輸入條件和邊界條件所選擇的測試用例。 圖書借閱的測試用例輸入條件測試用例圖書編號無編號圖書編號只有一個字符圖書編號有8個字符圖書編號有非數(shù)字或字母的字符讀者帳號無帳號讀者帳號只有一個字符讀者帳號有6個字符讀者帳號有8個字符讀者帳號有非數(shù)字或字母的字符借書量借書量為0借書量為1借書量為5借書量為6借書量中含有非數(shù)字字符 功能圖法測試用例設(shè)計管理員查詢圖書信息的功能圖。其規(guī)格說明如下。 圖書查詢功能圖其規(guī)格說明如下。（1）初始時要求管理員進行登錄。（2）進入登錄界面后要求管理員輸入其貼號和密碼信息。（3）后臺數(shù)據(jù)庫對管理員的信息進行比對。若相同，則可以入系統(tǒng)進行查詢操作；若不同，則管理可以重新進行登錄。（4）管理員輸入要查詢商品的信息后，后臺數(shù)據(jù)庫檢查表中是否有與其對應(yīng)的記錄，若沒有管理員可以重新輸入查詢信息；否則顯示相應(yīng)的查詢結(jié)果。根據(jù)功能圖和規(guī)格說明，設(shè)計出了測試用例。 圖書查詢測試用例 軟件可靠性 基本定義1．軟件可靠性1983年美國IEEE計算機學(xué)會對“軟件可靠性”作出了明確定義，此后該定義被美國標準化研究所接受為國家標準，1989年我國也接受該定義為國家標準。該定義包括兩方面的含義：一是在規(guī)定的條件下，在規(guī)定的時間內(nèi)，軟件不引起系統(tǒng)失效的概率；二是在規(guī)定的時間周期內(nèi)，在所述條件下程序執(zhí)行所要求的功能的能力。2．軟件的可用性軟件可用性的一個定義是：軟件可用性是程序在給定的時間點，按照規(guī)格說明書的規(guī)定，成功地運行的概率?？煽啃院涂捎眯灾g的主要差別是可靠性意味著在0到t這段時間間隔內(nèi)系統(tǒng)沒有失效，而可用性只意味著在時刻t，系統(tǒng)是正常運行的。因此，如果在時刻t系統(tǒng)是可用的，則有下述種種可能：在0到t這段時間內(nèi)，系統(tǒng)一直沒失效（可靠）；在這段時間內(nèi)失效了一次，但是又修復(fù)了；在這段時間內(nèi)失效了兩次修復(fù)了兩次如此反復(fù)進行。如果在一段時間內(nèi)，軟件系統(tǒng)故障停機時間分別為td1，td2…，正常運行時間分別為：tu1， tu2….，則系統(tǒng)的穩(wěn)態(tài)可用性，如式（）所示。 Ass=Tup/(Tup+Tdown) ()Tup為成功運行的時間總和；Tdown為失敗的時間總和。如果引人系統(tǒng)平均無故障時間MTTF和平均維修時間MTTR的概念，則（）式將會改變，如式（）所示。 Ass=MTTF/（MTTF＋MTTR） () 估算平均無故障時間的方法軟件的平均無故障時間MTTF是一個重要的質(zhì)量指標，往往作為對軟件的一項要求，由用戶提出來。為了估算 MTTF，首先引入一些有關(guān)的量。在估算MTTF的過程中使用下述符號表示有關(guān)的數(shù)量：——————測試之前程序中錯誤總數(shù)；——————程序長度（機器指令總數(shù)）；————————測試（包括調(diào)試）時間；——————在0至期間發(fā)現(xiàn)的錯誤數(shù)； ————在0至期間改正的錯誤數(shù)；經(jīng)驗表明，平均無故障時間與單位長度程序中剩余的錯誤數(shù)成反比，如式（）所示。 MTTF＝1/(K*(Et/ItEc/It)) ()其中K為常數(shù)，它的值應(yīng)該根據(jù)經(jīng)驗選取。美國的一些統(tǒng)計數(shù)字表明，K的典型值是200。估算平均無故障時間的公式，可以評價軟件測試的進展情況。 MTTF和ASS的估算對圖書借閱管理系統(tǒng)進行為期8天的集成測試，平均每天測試4個小時。在測試期間記錄了數(shù)據(jù)如下：（1）在測試之前程序存在40條錯誤。（2）程序中指令的長度為35000行。（3）測試了8天每天4個小時共32小時，期間維護了5次共花費4小時。（4）在測試期間發(fā)現(xiàn)并改正了37條錯誤。綜合上述測試數(shù)據(jù)。Ass= Tup/(Tup+Tdown)=32/(32+4)=。MTTF＝1/(200*(40/3500037/35000))=58小時結(jié) 論經(jīng)過一段時間的設(shè)計和開發(fā)，圖書借閱管理系統(tǒng)基本開發(fā)完畢，系統(tǒng)功能基本符合借閱管理的需求，其主要功能如下。管理員正確登錄后，能夠執(zhí)行圖書管理、出版社管理、圖書類別管理、讀者注冊、讀者管理、借書、還書、罰款、報表顯示以及對圖書、出版社、圖書類別、讀者、借書信息、還書信息、罰款信息等進行查詢，并且可以實現(xiàn)模糊查詢，其中每個管理模塊都包括對該信息的添加、修改、刪除功能。讀者成功登錄后，可以查看圖書的借閱規(guī)則，對圖書進行簡單查詢和復(fù)合查詢，查看自己所借過的圖書、未還的圖書、罰款的圖書及罰款金額等信息。由于時間比較緊迫，該系統(tǒng)還有些不足之處，比如有的報表只能實現(xiàn)將數(shù)據(jù)庫中對應(yīng)表的全部信息顯示出來，沒有實現(xiàn)按日期查詢信息、按月份統(tǒng)計罰款金額等。因為對圖書館的調(diào)研不夠精確，所以有些問題沒有考慮到，導(dǎo)致有些已實現(xiàn)的功能不夠周全，有些出錯處理不夠恰當?shù)榷喾矫鎲栴}，還需要進一步的完善。對于一些復(fù)雜的代碼還需要進一步的修改，使之更加簡捷易懂。致 謝大學(xué)的生活很美好，也很值得留戀。在這里，找到了良師益友，也學(xué)到了在別處學(xué)不到的知識。隨著畢業(yè)設(shè)計的完成，隨之而來的便是畢業(yè)，意味著和同學(xué)、老師分開，真的有很多不舍。在做畢業(yè)設(shè)計的過程中，經(jīng)常會遇到問題，有些自己解決不了很是苦惱，就會向同學(xué)和老師請教，他們總會很耐心的給以幫助。老師在檢查程序時，總是耐心地指出程序中明顯的不足，使我明白怎樣去改正，完善系統(tǒng)的功能。田丹老師在給我檢查畢業(yè)論文時，批注寫的很仔細，寫明了需要修改的地方，使我更加方便地對論文進行改正。老師那溫和的態(tài)度和深厚的學(xué)術(shù)修養(yǎng)使我終身難忘，真的很感謝老師耐心的指導(dǎo)和同學(xué)熱心的幫助。 感謝信息系的每位老師，每一次課他們都很認真地對待，很耐心地講解。感謝我的母?！吧蜿柪砉ご髮W(xué)”，美麗的校園、莊嚴的教學(xué)樓、干凈的教室、“篤實、勵學(xué)、圖強”的校訓(xùn)我將永遠銘記于心。參考文獻[1] Server :P2028.[2] SERVER :P60123. [3] .:P1326.[4] C.:P932.[5] .:P300315. [6] 薩師煊 :P203242[7] 覃征 楊利英.《軟件項目管理》.:P7089[8] :P6675附 錄附錄A VS2005 IntroductionToday, the enterprises to be successful, we must face up to build and maintain increasingly plex information technology (IT) solutions to needs. In addition, they also help of new technologies to expand their business functions, and develop new business opportunities. Since the IT departments have received technical support tasks that moment, they will bee the most critical role in business strategy.Companies want from their IT investments in the project to obtain the maximum profits, which means that IT departments need increasing pressure, the sooner the better to plete the work. Because of the higher pursuit of costeffectiveness, making predictability of demand for IT projects is growing. However, this often result in cumbersome processes and monitoring of cost consumption, it is only fees should be shifted to a different question. Opportunity t