【正文】 主窗體啟動時，首先打開“登錄”對話框。如果不能通過身份驗證，則不能進入系統(tǒng)。 基本信息管理模塊包括客戶信息管理、客房類型管理和客房信息管理?？蛻粜畔⒕庉嫶绑w可以用來添加和修改用戶的基本信息，窗體名稱為FrmCustEdit,窗體的FrmCustEdit中包含的控件以及其屬性如表44所示，該表介紹了所有的控件屬性。表44窗體FrmCustEdit中包含的控件及其屬性對象名屬性屬性值/說明ComboCustType客戶類型，用戶可以輸入新數(shù)據(jù)或選擇已有數(shù)據(jù)TxtOrgName客戶單位txtName客戶姓名Option1Caption男Option2Caption女ComboLevle客戶等級txtForm國籍戶籍ComboIdtype證件類型TxtCustId證件編號TxtPostcode郵政編碼TxtAddr通信地址txtOffice單位電話TxtMobile移動電話TxtHome住宅電話Txtjob職務Cmd_OkCaption確定Cmd_CancleCaption取消。 客戶信息管理窗體的名稱為FrmCustMan。在窗體FrmCustMan中，使用DataGrid控件來顯示客戶數(shù)據(jù)，使用ADO Data控件為其提供數(shù)據(jù)源。窗體中主要的控件及其屬性如表45所示。表45窗體FrmCustMan中包含的控件及其屬性對象名屬性屬性值/說明ComboType客戶類型ComboSearch選擇查詢條件類型txtSearch輸入查詢條件Cmd_SearchCaption查詢Adodc1為客戶信息表格提供數(shù)據(jù)源DataGrid1顯示客戶信息的表格Cmd_AddCaption添加Cmd_ModiCaption修改Cmd_DelCaption刪除Cmd_ExitCaption退出。 客戶信息管理窗體布局客戶信息選擇窗體名為FrmCustSlt，它的功能是提供客戶列表。 窗體FrmCustSlt的界面布局客房類型信息編輯窗體可以用來添加和修改客房類型信息，窗體名稱為FrmRoomTypeEdit。 窗體FrmRoomTypeEdit的布局客房類型信息管理的名稱為FrmRoomTypeMan。在窗體FrmRoomTypeMan中使用DataGrid控件來顯示客房類型數(shù)據(jù)，使用ADO Data控件為其提供數(shù)據(jù)源。 客房信息編輯窗體可以用來添加和修改客房信息，窗體名稱為FrmRoomEdit。 。 客房信息管理窗體的名稱為FrmRoomMan。在窗體FrmRoomManzho中使用DataGrid控件來顯示客房數(shù)據(jù)，使用ADO Data控件為其提供數(shù)據(jù)源。 前臺接待管理可以實現(xiàn)以下功能：(1) 預訂客房管理(2) 入住登記管理(3) 續(xù)住登記管理(4) 退房登記管理客房預訂信息編輯窗體的名稱為FrmOrderRoomEdit，該表設計起來比較復雜，涉及的主要模塊后再進行詳細的設計才能保證窗體的完整性。 窗體FrmOrderRoomEdit的布局客戶預定信息管理窗體為FrmOrderMan，窗體的布局如圖412所示。 窗體FrmOrderMan的布局客房預定明細信息查看窗體的名稱為FrmOrderListShow，布局很簡單，使用了ADO空間進行數(shù)據(jù)庫連接操作，主要是可以查看預訂的記錄信息，并且可以顯示用戶的編號信息。 窗體FrmOrderListShow的布局客房入住信息編輯窗體的名稱為FrmRegEdit。 客房入住信息管理窗體的名稱為FrmRegMan。 續(xù)住登記信息編輯窗體的名稱為FrmAddEdit。 續(xù)住登記信息管理窗體為FrmAddMan。 退房登記信息編輯窗體的名稱為FrmLeaveEdit。 當單擊確定按鈕時觸發(fā)Cmd_OK_Click事件，程序將修改后的入住登記信息保存到表Registration中，然后將登記記錄的狀態(tài)更新為2，即已退房。退房登記信息管理窗體為FrmLeaveMan。 收銀統(tǒng)計管理模塊可以實現(xiàn)以下功能：實收房款管理客戶消費統(tǒng)計表實收款統(tǒng)計表實收房款信息編輯窗體的名稱為FrmFRoomEdit。 實收房款信息管理窗體的名稱為FrmPayFRoomMan。 窗體FrmPayFRoomMan的布局在窗體中FrmPayFRoomMan中，可以分別查看“已退房”和“已結款”對于已結款記錄可以取消結款?？蛻粝M統(tǒng)計表的名稱為FrmStatusCustomer。 實收款統(tǒng)計表窗體名稱為FrmStatusPay。 根據(jù)用戶類型不同，用戶管理模塊的功能也不相同。可以包含以下情形：Admin用戶可以創(chuàng)建普通用戶，對普通用戶的用戶名和密碼進行修改，刪除普通用戶；Admin用戶也可以修改自身的密碼；普通用戶只能修改自身的用戶名和密碼。用戶信息編輯窗體可以用來添加和修改用戶信息。 登錄窗體的控件屬性可以按照表46所示進行設置界面簡單，功能強大。表46 登錄窗體包含的控件和屬性對象名屬性屬性值Lable1Caption用戶名Lable2Caption密碼Lable3Caption確認密碼txtUserNameText空txtPwdText空PasswordChar*txtPwd2Text空PasswordChar*Cmd_OkCaption確定Cmd_CancleCaption取消用戶管理窗體的名稱為FrmUserMan,可以顯示用戶信息，并且有用戶列表可以執(zhí)行添加用戶，修改用戶，刪除用戶等功能。 窗體FrmUserMan的布局窗體中的主要屬性如表47所示。表47窗體FrmUserMan中主要的控件和屬性對象名屬性屬性值DataList1BoundColumnUserNameListFieldUserNameRowSourceAdoUserListIblUserNameCaption空IblUserTypeCaption空Cmd_AddCaption添加用戶Cmd_ModiCaption修改用戶Cmd_DelCaption刪除用戶Cmd_BackCaption返回在主界面中單擊“系統(tǒng)用戶管理”/“用戶管理”菜單，將打開用戶管理窗體，代碼如下：Private Sub mn_user_Click（） ‘如果當前用戶為Admin，則打開用戶管理窗體If Format（，“”）=“admin”Then ElseMsgBoc“沒有權限”End IfEnd Sub只有admin用戶才能進入“用戶管理”窗口。在主界面中單擊“系統(tǒng)用戶管理”/“修改密碼”菜單項，將打開密碼窗體，代碼如下：Private Sub mn_pwd_Click（） ‘如果當前用戶是普通用戶，則打開用戶編輯窗體，編輯自己的用戶信息With FrmUserEdit.OriUser=.txtUserName=.txtPass=.TxtPass2=.Modify=True.Show1End WithEnd Sub用戶只能修改自己的密碼，當前用戶的信息在登錄時被保存的CurUser對象中。第5章 性能測試與分析測試軟件的經(jīng)典策略是，從“小型測試開始”，逐步過度到“大型測試”。用軟件測試的專用術語，就是從單元測試開始，逐步進入集成測試，最后進行確認測試和系統(tǒng)測試。對于傳統(tǒng)的軟件系統(tǒng)測試來說，單元測試集中測試最小的可編譯的程序單元（過程模塊），一旦把這些單元測試完之后，就把她們集中到程序結構中去；在集中過程中還進行一系列系統(tǒng)作為一個整體測試，以發(fā)現(xiàn)軟件需求錯誤。測試面向對象軟件的策略與上述策略基本相同，但也有許多新特點。當考慮面向對象的軟件時，單元的概念改變了?！胺庋b”導致了類和對象的定義，這意味著類和類的實例（對象）包括了屬性（數(shù)據(jù)）和處理這些數(shù)據(jù)的操作（也成為方法或服務）?，F(xiàn)在，最小可測試單元是封裝起來的類和對象。一個類可以包含一組不同的操作，而一個特定的操作也可能存在于一組不同的類中。因此，對于面向對象的軟件來說，單元的測試的含義發(fā)生了很大的變化。測試面向對象的軟件時，不能再孤立的測試單個操作，而應該把操作作為類的一部分來測試。例如，假設有一個類層次，操作X在超類中定義并被一組子類繼承，每個子類都使用操作X，但是，X調用子類中定義的操作并處理子類的私有屬性。由于在不同的子類中使用操作X的環(huán)境有微妙的差別，因此有必要在每個子類的語境中測試操作X。這就說明，當測試面向對象軟件時，傳統(tǒng)的單元測試方法是不適用的，不能再在“真空”中（即孤立地）測試單個測試。面向對象軟件的集成測試主要有下述兩種不同的策略。(1) 基于線程測試(thread based testing)。這種策略把響應系統(tǒng)的一個輸入或一個事件所需要的那些類集成起來。分別集成并測試每個線程，同時應用回歸測試以保證沒有副作用產(chǎn)生。(2) 基于使用的測試(use based testing)。這種方法首先測試幾乎不使用服務器類的那些類（獨立類），把獨立類都測試完成之后，再測試使用獨立類的下一個層次的類（稱為依賴類）對依賴類的測試一個層次一個層次的持續(xù)進行下去，直到把整個軟件系統(tǒng)構造完為止。功能測試的主要內容是按實際操作的數(shù)據(jù)向系統(tǒng)的各個功能模塊輸入數(shù)據(jù)，檢測輸出結果是否符合預期要求。在對各個模塊的測試完成后對整個系統(tǒng)作一個完整的測試，以檢驗各模塊在聯(lián)合運行時運行結果是否符合預期要求。在實際測試中，打開歷史客人的資料大概需要5~10秒，為一名客人辦理入住需要5~10秒，統(tǒng)計一個客人的費用情況小于10秒。由于時間倉促，此系統(tǒng)的規(guī)劃雖然定位為小型，但功能基本實現(xiàn)了酒店前臺管理的所有重要功能，而在實際工作中卻少人力、物力資源。因此，系統(tǒng)雖然完成了大部分的功能，但不少與其它系統(tǒng)的接口（門鎖系統(tǒng)、公安出入境資料管理系統(tǒng)、餐飲娛樂系統(tǒng)等）而未能有時間實現(xiàn)。其它一些比較不重要的輔助性、完善性的功能也未能在短短的畢業(yè)設計所限定的時間內實現(xiàn)。因為系統(tǒng)還在不斷地加入新功能以及修改現(xiàn)有問題，所以在系統(tǒng)的評測部分并沒有詳盡的測試報告，而本文中的內容也并未能完全表達整個系統(tǒng)的功能發(fā)展狀態(tài)?；诒鞠到y(tǒng)要求的開發(fā)時間比較短，開發(fā)力量有限，有些隱性的問題在調試的過程中還沒有出現(xiàn)，希望通過用戶反饋回來的信息，作出調整，及時修正錯誤、完善所需