【正文】 所以我再次感謝老師和我的同學們。老師認真負責的工作態(tài)度、嚴謹?shù)闹螌W風格，使我深受啟發(fā)；開發(fā)的同時，和同學們之間的相互探討也使我獲益匪淺。在設(shè)計時，由于時間和能力有限，還有部分的功能沒有實現(xiàn)，希望以后能夠慢慢地發(fā)現(xiàn)問題，改正問題，力求將系統(tǒng)做得越來越完美 、 實用?，F(xiàn)在開發(fā)出來的軟件對數(shù)據(jù)庫的操作還不夠穩(wěn)定，異常處理做的還很欠缺。 當然在設(shè)計中還有很多不足的地方。 力求對數(shù)據(jù)庫操作的安全與穩(wěn)定，盡量避免數(shù)據(jù)庫操作異常，并要保證查詢的快速無誤。設(shè)計中力求界面友好、簡潔，易于操作。基于該系統(tǒng)的一些設(shè)計，下面對系統(tǒng)做一個總結(jié)。在這幾個月的開發(fā)過程中，學到了許多有關(guān)數(shù)據(jù)庫管理軟件設(shè)計的 知識 ，也對管理信息系統(tǒng)有了更加全面而深刻的認識。 測試結(jié)果：學生考情管理系統(tǒng)的登陸頁面的瓶頸為 215人，建議配置更好的服務(wù)器，之后再進行系統(tǒng)上線。 圖 事務(wù)通過率 事務(wù)的通過率在 0:55分鐘變?yōu)?0，事務(wù)通過數(shù)為 0，服務(wù)器沒有響應(yīng)。 測試 HTML報告 :測試結(jié)果 \ 測試結(jié)果： 225同時并發(fā)訪問服務(wù)器，事務(wù)響應(yīng)時間邊長， 0:55時事務(wù)的通過率變?yōu)?0，已經(jīng)超 出了系統(tǒng)的瓶頸人數(shù)，說明系統(tǒng)的瓶頸在 200225人之間。 測試場景四： 225人并發(fā)登陸系統(tǒng) 圖 平均事務(wù)相應(yīng)時間 40 隨并發(fā)訪問人數(shù)減少，但是平均事務(wù)響應(yīng)時間依然很長，頁面響應(yīng)速度變慢。 圖 事務(wù)通過率 事務(wù)的通過率在 2:00分鐘變?yōu)?0，事務(wù)通過數(shù)為 0，服務(wù)器沒有響應(yīng)。 測試 HTML報告 :測試結(jié)果 \ 測試結(jié)果： 300同時并發(fā)訪問服務(wù)器，事務(wù)響應(yīng)時間邊長， 2:30時事務(wù)的通過率變?yōu)?0，已經(jīng)超出了系統(tǒng)的瓶頸人數(shù)，說明系統(tǒng)的瓶頸在 200300人之間。 測試場景二： 300人并發(fā)登陸系統(tǒng) 圖 平均事務(wù)相應(yīng)時間 38 因為并發(fā)訪問人數(shù)增多，平均事務(wù)響應(yīng)時間 變 長，頁面的響應(yīng)速度變慢。 圖 事務(wù)通過率 事務(wù)的通過率較高，沒有出現(xiàn)失敗的事務(wù)。 本系統(tǒng)所采用測試方案 性能測試 測試過程 測試目的：驗證服務(wù)器可以同時接受多少用戶進行并發(fā)訪問，查找系統(tǒng)的瓶頸。 國際化測試 使用每種可能的國際輸入類型，針對任何區(qū)域性或 區(qū)域設(shè)置 檢查產(chǎn)品的功能是否正常， 軟件國際化 測試的重點在于執(zhí)行國際字符串的輸入 /輸出功能。 本地化測試 的目的是測試特定目標區(qū)域設(shè)置 的 軟件本地化 質(zhì)量。主要是根據(jù)測試者的經(jīng)驗對 軟件 進行功能和性能抽查。利用黑盒測試法進行動態(tài)測試時，需要測試軟件產(chǎn)品的功能，不需測試軟件產(chǎn)品的內(nèi)部結(jié)構(gòu)和處理過程 白盒測試 白盒測試也稱結(jié)構(gòu)測試或邏輯驅(qū)動測試，它是按照 程序 內(nèi)部的結(jié)構(gòu) 測試程序 ，通過測試來檢測產(chǎn)品內(nèi)部動作是否按照設(shè)計規(guī)格說明書的規(guī)定正常進行，檢驗程序中的每條通路是否都能按預(yù)定要求正確工作 其他測試方案 性能測試 性能測試是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統(tǒng)的各項性能指標進行測試。 35 第 5 章 軟件測試 軟件測試 是軟件開發(fā)過程中的一個重要組成部分，是貫穿整個軟件開發(fā)生命周期、對軟件產(chǎn)品（包括階段性產(chǎn)品）進行驗證和確認的活動過程，其目的是盡快盡早地發(fā)現(xiàn)在軟件產(chǎn)品中所存在的各種問題 —— 與用戶需求、預(yù)先定 義的不一致性。 2． 不同天數(shù)的審批，對應(yīng)的只有不同的菜單，但審批操作是一樣的 ， 如下圖 34 ： 圖 不同角色的不同菜單圖 3． 審批過程，擁有菜單的人都一樣的操作方法，如下圖 ： 圖 審批過程 注： （ 1） 審核結(jié)果：通過、不通過。 （ 1） 學生請假列表的主列表，實現(xiàn)字段：申請時間、申請?zhí)鞌?shù)、申請人、申請原因、審批人、審批狀態(tài)（后兩項等到老師審批完成后顯示），列表如下圖 ： 圖 申請主列表 （ 2） 申請請假步驟如下圖 ： 圖 申請請假步驟 注：請假類型：病假、事假、喪假、婚假、公假、其他。 根據(jù)學生用戶請假的需求，學生三天內(nèi)的請假（包括三天）只需班主任批準后就可生效 ； 四天（包括四天） 至 15天 的請假，必須先由 學院領(lǐng)導(dǎo)審批 同意 ；如果請假天數(shù)大于 15天，必須由 學校 審批 同意。如下圖 ： 圖 添加已存在課程步驟 （ 4） 點擊“添加請假者”或者“添加曠課者”的前提是：已經(jīng)選擇了班級，然后才有該班學生信息。模塊設(shè)計簡單，只需錄入每節(jié)課的信息。 4. 查詢操作以及頁面，點擊提交后，跳轉(zhuǎn)到主列表得到結(jié)果集，操作如下圖 ： 圖 查詢步驟以及按鈕 這一模塊的設(shè)計是為了方便后期的統(tǒng)計查詢做準備。 圖 課程信息列表頁面 2． 添加步驟以及頁面，如下圖 ： 圖 添加課程信息步驟以及頁面 注：課程類型：其他、專業(yè)課、選修課、公共課、公共選修課、專業(yè)選修課。管理員重置密碼步驟下圖 ，其余用戶一樣的操作過程： 圖 管理員重置密碼步驟 課程管 理的設(shè)計與實現(xiàn) 設(shè)計課程管理這一模塊的主要目的是方便考勤記錄，在后面的考勤管理模塊會具體體現(xiàn)。 （ 2） 用戶查詢 :不同角色的用戶查詢結(jié)果相同，即管理員和老師可以看見所有人信息，學生沒有這個菜單，如下圖 ： 圖 管理員以及教師使用用戶查詢的界面 （ 3） 密碼重置：不同角色擁有不同權(quán)限。 正確的操作如下圖 ： 圖 新增一個學生信息步驟圖 點擊“提交”按鈕時，彈出如下圖提示框： 圖 提交按鈕彈 出的提示框 修改、詳情的操作如同 。如下圖 ： 當前用戶如果是管理員，可以 對任意一個用戶進行增刪改查操作。 當用戶是學生時，此時當前用戶只有查看詳情的權(quán)力。 圖 基本信息界面 用戶管理界面的設(shè)計與實現(xiàn) 用戶管理分為用戶維護、用戶查詢、密碼重置三部分。將最基礎(chǔ)的學院或者系的信息和班級信息或者學工辦信息以及班級學生信息整合 在此模塊，方便管理操作。 圖 主界面 23 當 LoginAction的 execute方法返回的 success值為 false時，不調(diào)用 getMenus方法，只通過 alert 方法提示用戶。當用戶名或者密碼有一個不匹配時， LoginAction將 msg 儲存信息： 用戶名或密碼錯誤！ 并返回到登錄界面給出相應(yīng)提示；當用戶名和密碼都匹配時，初始化當前在線人數(shù) onlineUserList，然后將獲取到的userInfo對象填充到 LoginInfo中并且調(diào)用 createLoginLog方法（初始化登錄日志為其添加一條記錄），將 success（ success默認為 false）賦值給 success并返回。 （ 2） 當用戶名和密碼都不為空時，然后通過 ajax將用戶名和密碼提交到LoginAction的 execute方法。 }。 return false。 return false。 return false。, async : true, // 異步 data : $(loginForm).serialize(), // 獲取數(shù)據(jù) timeout : 30000, success : function(data) { //2.（ 1 if ( == true) { = 39。, cache : false, dataType : 39。, //2 type : 39。 $.ajax({ url : 39。 } 21 //窗口最大化 (0,0)。 } //驗證密碼是否為空 if ($(password)[0].value == ) { alert(請輸入密碼 )。 圖 登 錄界面 ： // 1 function submitUser() { //驗證用戶名是否為空 if ($(userid)[0].value == ) { alert(請輸入用戶名 )。此界面對用戶身份沒有設(shè)置相對應(yīng)的權(quán)限，當所有用戶成功進入系統(tǒng)時，統(tǒng)一顯示主界面，但區(qū)別用戶身份的是菜單。 數(shù)據(jù)庫表的創(chuàng)建 根據(jù)數(shù)據(jù)庫需求的分析，建立如下基本數(shù)據(jù)表。 請假信息表：請假原因、請假理由、 請 假天數(shù)、申請時間、申請人、審批人、審批結(jié)果等。 課程表：課程編碼、課程名稱等。 院辦 /學工辦 /班級表：部門名稱、部門類型、部門負責人等。 菜 單表：菜單名稱、上級菜單編碼、排序號、菜單類別、菜單動作、是否葉子節(jié)點、是否在用等。 代碼分類：代碼分類名稱、代碼分類描述、排序、在用標志等。 數(shù)據(jù)庫邏輯設(shè)計 根據(jù)系統(tǒng)功能設(shè)計的要求以及功能模塊的劃分，對于系統(tǒng)數(shù)據(jù)庫，可以列出以下主要的數(shù)據(jù)表以及數(shù)據(jù)表項： 按 鈕表：按鈕名稱、按鈕圖片路徑、是否啟用等。以下主要用第二種方法： 打開 MySQL，登錄之后，選擇 [新建數(shù)據(jù)庫 ]命令，給數(shù)據(jù)庫起名為 lzcu。 總體結(jié)構(gòu)圖 根據(jù)系統(tǒng)功能的要求，高校學生考勤管理系統(tǒng)各個模塊之間的層次結(jié)構(gòu)如圖 所示： 注：文中所提到的教師包括（任課教師、班主任、院校領(lǐng)導(dǎo)） 注：用戶包括 （ 學生、任課教師、班主任、院領(lǐng)導(dǎo)、校領(lǐng)導(dǎo) ） 頁面主體 功能菜單 Banner Bottom 7 圖 系統(tǒng)功能結(jié)構(gòu)示意圖 系統(tǒng)功能流程圖 （ 1） 主功能流程如圖 所示 圖 主功能流程圖 （ 2）各個模塊功能細化如下圖 、 、 所示 開始 用戶登錄 基礎(chǔ)信息管理 權(quán)限管理 課程管理 考勤記錄 請假管理 統(tǒng)計查詢 退出系統(tǒng) 結(jié)束 高校學生考勤管理系統(tǒng) 請 假 系 統(tǒng) 考 勤 系 統(tǒng) 后 臺 管 理 統(tǒng) 計 查 詢 8 圖 權(quán)限管理功能細化 基礎(chǔ)信息管理功能細化 管理員 權(quán)限管理 管理員 角色管理 按鈕管理 菜單增刪改 按鈕權(quán)限細化 按鈕增刪改查 角色分配權(quán)限 用戶分配角色 角色增刪改 教師 管理員 基礎(chǔ)信息 管理員 管理員 用戶管理 教師 所有用戶 教師 班級增刪改 學工辦增刪改 院系增刪改 用戶增刪改 用戶密碼重置 用戶查詢 所有用戶 管理員 教師 其他各模塊功能細化 考勤記錄 考勤增刪改查 教師 教師 課程管理 教師 請假管理 學生 請假審核 請假申請 課程增刪改 9 請假模塊細化 注：條件是指三天以上十五天以內(nèi)的請假要通過院領(lǐng)導(dǎo)的審批，超過十五天的請假就得要通過校領(lǐng)導(dǎo)。 —— 顯示頁面格式化數(shù)據(jù)頁面主體區(qū)顯示的內(nèi)容，將依據(jù)頁 面在系統(tǒng)中的作用而定。本系統(tǒng)各用戶的頁面設(shè)計如圖 所示 ： 頁面設(shè)計圖 區(qū) —— 可以在此展示系統(tǒng)標識、頁面歸屬等信息。 S2SH 以 Spring為核心部件，向上集成 Struts2，向下集成 Hibernate，充分發(fā)揮了三者各自的優(yōu)勢，具有很好的低耦合，擴展性和復(fù)用性。 S2SH 框架是由 Struts Spring 和 Hi