jspsql學生考勤系統的設計與實現畢業論文-資料下載頁

【導讀】師的指導下進行的研究工作及取得的成果。盡我所知，除文中特別加。而使用過的材料。均已在文中作了明確的說明并表示了謝意。除了文中特別加以標注引用的內容外，本論文。不包含任何其他個人或集體已經發表或撰寫的成果作品。究做出重要貢獻的個人和集體，均已在文中以明確方式標明。全意識到本聲明的法律后果由本人承擔。同意學校保留并向國家有關部門或機構送交論文的復印件和電子版，允許論文被查閱和借閱。本人授權大學可以將本學位。印或掃描等復制手段保存和匯編本學位論文。涉密論文按學校規定處理。本系統總體上由三大功能模塊：請假系統模塊、考勤系統模塊、后臺管。系統涉及到高校三大類用戶：學生、任課老師、系統管理員。頁面模塊化、信息發布的動態生成、靜態頁面顯示等技術開發。理員三類用戶功能的設計與實現。

　　

【正文】 管理員主 界面的設計與實現 添加教師 界面的設計與實現 教師管理 界面的設計與實現 添加學生 界面的設計與實現 學生管理 界面的設計與實現 教師審核與查看 界面的設計與實現 教師點名 界面的設計與實現 學生請假 界面的設計與實 現 學生考勤信息查看 界面的設計與實現 第 7 章 軟件測試 引言 在開發軟件的過程中，人們使用了許多保證軟件質量的方法分析、設計和實現軟件，但難免還會在工作中犯錯誤。這樣，在軟件產品中就會隱藏許多錯誤和缺陷，尤其是對規模大、復雜性高的軟件更是如此。所以，必須進行認真、計劃、徹底的軟件測試。 測試方案 黑盒測試 黑盒測試，又稱為功能測試。對于軟件測試而言，黑盒測試把程序看成一個黑盒子，完全不考慮程序的內部結構和處理過程。也就是說，黑盒測試是在程序接口進 行的測試，它只檢查程序功能是否能按照規格說明書的規定正常使用，程序是否能適當地接收輸入數據產生正確的輸出信息，并且保持外部信息（如數據庫或文件）的完整性。該測試方案的設計技術主要有：等價劃分、邊界值分析以及錯誤推測法等。 白盒測試 白盒測試的前提是可以把程序看成裝在一個透明的白盒子里，也就是完全了解程序的結構和處理過程。這種方法按照程序內部的邏輯測試程序，檢驗程序中的每條通路是否能按預定要求正確工作。故白盒測試又被稱為是結構測試。該測試方案的設計技術主要有邏輯覆蓋法等。 其它測試方案 除了以上兩種測試方案外，還有其它的測試方案。包含所有可能情況的測試稱為窮盡測試。對于實際程序而言，窮盡測試通常是不可能做到的。因為不可能對每一種可能的情況都進行測試。 本系統所采用測試方案 基于以上測試方法 ,本人選取的是模塊測試和系統測試，模塊測試部分由本人程序設計過程中自主完成，系統測試部分由同學模擬各種用戶登錄代為完成。 測試過程 用戶登陸測試 用戶登陸測試是測試系統訪問的安全性，以及各個頁面的設計的安全性，測試方案如下（表 61）所示： 表 61 用戶類型 用戶名 密碼 空密碼 錯誤密碼 /用戶名 錯誤類型 學生 2020202122 2020202122 否 否 否 任課老師 041002 123456 否 否 否 班主任 048001 123456 否 否 否 院系領導 xinxi_02 123456 否 否 否 學校領導 school 123456 否 否 否 說明：上表中的“否”表示拒絕訪問，沒有通過系統的身份驗證。“是” 表示可以訪問系統。 通過上表反復測試黑盒測試可知，系統用戶在登陸安全方面不存在問題，用戶必須選擇正確的類型，使用正確的用戶名、密 碼方能使用此系統。 頁面使用安全測試 此測試過程主要是測試系統各個頁面的安全性，即在用戶沒有登錄的情況直接在瀏覽器地址中輸入要打開的用戶頁面，或者用戶以正確的用戶名和密碼進入系統后，直接在瀏覽器地址中輸入別的用戶的頁面，測試各頁面是否不需要用戶登錄就可使用，或者是否可以繞過身份驗證。 第 一 步 ： 在 用 戶 沒 登 陸 系 統 的 情 況 下 ， 直 接 在 瀏 覽 器 中 輸 入 此地址是學生用戶首頁的完全地址，看是否能打開操作。測試結果：提示用戶還沒登陸的錯誤信息。依次測試別的頁面，別的用戶，測試結果都是：提示用戶還沒登陸的錯誤信息。 第二步：以學生正確的用戶我和密碼進入學生系統后，在瀏覽器中輸入任課老師首頁地址： 看是否能繞過身 份驗證，打開別的用戶的頁面。測試結果：提示沒有權限的錯誤信息。用同樣的方法測試別的頁面，別的用戶都得到了同樣的測試結果：提示沒有權限的錯誤信息。 測試結果：通過以上測試可知，系統各個頁都有很好的安全性，每個頁面都不允許用戶在沒有登陸的前提下訪問，用戶在登陸后，也不充許用戶訪問別的用戶類型的頁面，即不能繞過身份驗證。 學生用戶測試 一、 請假系統測試 請假系統是學生用戶的核心功能，由于涉及的用戶比較多，此部分的測試是在幾個同學的配合下完成，主要完成以下幾個測試： 1． 空值測試：在請假開始時間、結束時間、請假原 因都為空或部分為空的情況下，直接點提交數據在線請假。測試結果：系統拒絕提交數據，并能正確的做出相應的提示，如 **不能為空的錯誤信息。 2． 錯誤的時間選擇測試：在開始時間與結束時間選擇的時間，把結束時間選擇一個開始時間以前的時間，然后提交數據。測試結果：提示時間選擇錯誤的提示信息。 3． 超前請假測試：開始時間選擇一個與當前時間相差一個大于 7 天的日期請假。測試結果：提示只能提前 7 天請假的錯誤信息。 4． 超后請假測試：在開始時間中選擇一個當前系統時間以前開始日期請假。測試結果：提示不能請過去時間的假的錯誤信息。 5． 超長時間請假 測試：在開始時間與結束時間中，選擇一個相差 30 的日期請假。測試結果：提示不能請大于 30 天的請假。 6． 重復請假測試：先申請一條當天日期的請假，申請成功后，再申請一條今天到明天兩天的請假。測試結果：提示不能重復請假的錯誤信息。 7． 小于 4 天的請假測試：開始時間與結束時間之差小于四天的請假測試。測試結果： 提交數據后，在等待審批的請假記錄中出現一條新的記錄，并顯示了申請時間，班主任審批處顯示了“等待批假”的提示信息，而院系審批處沒有顯示“等待批假”的提示信息。 8． 大于 4 天的請假測試：開始時間與結束時間之差大于四天的請假測試 ：測試結果：提交數據后，在等待審批的請假記錄中，班主任審批處以及院系領導審批處都提示“等待批假“的提示信息。 9． 班主任批假測試：班主任進入系統后，測試審批學生請假。測試結果：小于四天的請假，班主任若同意了請假，則學生記錄成功記錄中出現了請假成功的記錄。班主任同意的請假中同時也出現了此條記錄。若不同意請假，則提示此學生請假失敗。大于四天的請假，班主任若同意了請假，則出現等待院系審批的提示信息。 10． 院系批假測試：院系領導進入系統后，大于四天的記錄，且班主任同意請假的記錄出現在了等待審批的請假記錄中。測試結果：同意請 假，則學生、班主任、院系領導用戶中同時出現請假成功信息，不同意請假，則學生、班主任、院系領導同時出現請假失敗的信息。 二、修改密碼測試 1． 空值測試：在不輸入原始密碼、新密碼、確認密碼或部分為空的情況下，直接點擊修改密碼。測試結果：提示請輸入原始密碼的錯誤信息。 2． 錯誤原始密碼測試：輸入錯誤原始密碼，新密碼、確認密碼一致的測試。測試結果：提示原始密碼不正確的錯誤信息。 3． 確認密碼不正確的測試：輸入正確的原始密碼，而確認密碼不正確的測試。測試結果：提示確認密碼不正確的錯誤信息。 任課老師用戶測試 一、考勤管 理測試 1． 正確提示登記測試：進入指定的登記頁面，修改系統日期看是否能根據系統日間的變化，顯示出上過課，但學沒登記的提示信息。測試結果：若當前日期為 20200530，則本學期在 20200530 前的所有不沒登記的考勤信息自動列出來，而且能自動識別課表安排的單 /雙周。更換時間，都能得到正確的結果。 2． 考勤登記測試：進入指定頁面后，一個學生在當天上課時已經請假成功了，任課老師提交數據時選擇此學生曠課。測試結果：在考勤統計信息和詳細信息中，出現了此學生請假的出勤信息。 班主任用戶測試 1．班級信息測試 測試一個班主任是否可以同時帶多個班級、每個學期帶不同的班。測試結果：班主任能同時帶多個班級，每學期可帶不同的班級。 2．考勤信息測試： 測試班主任是否可以查看本班學生本學期考勤統計信息及詳細信息。測試結果：班主任能查看本班學生本學期考勤統計信息及詳細信息。 院系領導 /學校領導用戶測試 一、考勤信息測試 1． 空值查詢測試：在查詢學生考勤信息頁面中，不輸入查詢條件進行查詢測 試。測試結果：提示必須有一個查詢件的錯誤信息。 2． 單條件下查詢測試：查詢條件在只有學號或姓名的情況下進行查詢。測試結果：系統列出了所有相 關記錄，如姓名中只有一個“王”字，那么全院/全校所有姓名中有“王”字的學生信息都全部列出來，并都可以查看詳細考勤信息 總 結 通過幾個月的努力，高校學生考勤管理系統中的兩大功能模塊：請假系統和考勤系統在指導老師的全心指導下，在同學的積極配合與幫助下，基本功能順利完成。在數據庫的開發方面，我學到了不少關于 JSP和 SQL Server 2020 的知識。開發時遇到了許多的困難，但是通過自己的努力，還有老師同學們的幫助，最終還是迎刃而解了。 這次畢業設計完全是按照軟件工程學的方法來進行設計和開發的。在開發過 程中，認真調查分析了用戶的需求，及時準備了詳細的文檔資料，這讓我在開發過程中少走了許多彎路。本次設計開發的系統較為龐大，涉及的用戶較多，數據庫設計比較復雜，使我深刻地體會到軟件開發是一項集體項目，單靠一個人就想解決所有的問題是不太實際的。在本次畢業設計中，我和同學共同實現了高校學生考勤管理系統的全部功能，很好的鍛煉了我的團隊協作意識，這對我以后的學習、工作有很大的幫助。 同時，在這次設計中，我也發現了自己的很多不足。首先，對 JSP的掌握還不是很全面，對于數據庫管理系統的操作運用也不夠熟練，以至于在系統開發過 程中經常碰到一些疑難問題不能快速的解決。其次，就是在準備系統設計文檔時，沒有反復推敲、驗證，以至于在開發過程中出現幾次由于數據庫設計不合理，修改數據庫，而幾乎修改所有程序代碼的情況。再者，是對整個軟件開發的把握能力有待于進一步提高，以及對網頁設計的諸多方面知識也待進一步學習，這些都是我今后應該注意和提高的。 參考文獻 參考的資料有以下： [1] 肖金秀 JSP程序設計教程 北京：冶金工業出版社 [2] 孫曉龍 JSP動態網站技術入門與提高 北京：人民郵電出版社 [3] 楊學瑜 JSP入門與提高 北京： 清華大學出版社 [4] 魯曉東 JSP軟件工程案例精解 北京：電子工業出版社 [5] 印旻 Java 語言與面向對象程序設計 北京：清華大學出版社 [6] 皮德常 Java 2簡明教程 北京：清華大學出版社 [7] 薩師煊 王珊編著，《數據庫系統概論》，高等教育出版社 [8] 張海藩 編著 《軟件工程導論》，清華大學出版社 [9] 賽奎春 JSP 工程應用與項目實踐 北京：機械工業出版社 [10] 汪孝宜 JSP 數據庫開發實例精粹 北京：電子工業出版社 [11] 魏茂軍 JSP 案例開發 北京：中國水利水電 出版社 [12] 黃明 JSP 信息系統設計與開發實例 北京：機械工業出版社 [13] 屈輝立 JSP 網站編程教程 北京：北京希望電子出版社 [14] 孫衛琴 Tomcat 與 Java Web 開發技術詳解 北京：電子工業出版社 [15] 張桂元 Struts 開發入門與項日實踐 北京：人民郵電出版社 參考網站： 一、 java 官方網站 二、 Tomcat 官方網站 致 謝 在這段日子里，指導教師 XXX，以及身邊的同學給了我很多的幫助及耐心的教導。在此，對所有給我支持與幫助的老師與同學衷心的道一聲“謝謝 ” !如果沒有你們的幫助，我的課題肯定不能如此順利迅速的完成。 附 錄 附錄一：文獻資料 原文 J2EE WEB 應用架構分析 架構概述 J2EE 體系包括 java server pages(JSP) ,java SERVLET, enterprise bean，WEB service 等技術。這些技術的出現給電子商務時代的 WEB 應用程序的開發提供了一個非常有競爭力的選擇。怎樣把這些技術組合起來形成一個適應項目需要的穩定架構是項目開發過程中一個非常重要的步驟。完成這個步驟可以形成一個主要里程碑基線。形成這個基線有很多好處： 各種因數初步確定：為了形成架構基線，架構設計師要對平臺（體系）中的技術進行篩選，各種利弊的權衡。往往架構設計師在這個過程中要閱讀大量的技術資料，聽取項目組成員的建議，考慮領域專家的需求，考慮贊助商成本（包括開發成本和運行維護成本）限額。一旦架構設計經過評審，這些因數初步地就有了在整個項目過程中的對項目起多大作用的定位。 定向技術 培訓：一旦架構師設計的架構得到了批準形成了基線，項目開發和運行所采用的技術基本確定下來了。眾多的項目經理都會對預備項目組成員的技術功底感到擔心；他們需要培訓部門提供培訓，但就架構師面對的技術海洋，項目經理根本就提不出明確的技術培訓需求。怎不能夠對體系中所有技術都進行培訓吧！有了架構里程碑基線，項目經理能確定這個項目開發會采用什么技術，這是提出培訓需求應該是最精確的。不過在實際項目開發中，技術培訓可以在基線確定之前與架構設計并發進行。 角色分工：