【正文】 HR 管理對任何管理者而言都是一項全新的挑戰(zhàn)， HR 工作者必須深入了解知識工作者的需求，體察企業(yè)的戰(zhàn)略和通曉企業(yè)的產(chǎn)品和 服務，從而找到自己的位置。大力發(fā)展信息技術，改變傳統(tǒng)管理模式，充分利用資源，提 高企業(yè)效益成為目前大多數(shù)企業(yè)的發(fā)展目標。因此開發(fā)該系統(tǒng)在技術力量方面是可行的。利用計算機對企業(yè)的人力資源進行管理，使人事管理人員從日?，嵥楣芾砉ぷ髦械玫浇饷摚玫膮f(xié)調(diào)企業(yè)人才，大大的提高了人才的利用率，使企業(yè)人才的能力得以更充分的發(fā)揮。 可擴充性。代碼結構要簡單，要盡量縮短代碼的長度，以方便輸入，提高處理效率，并且便于記憶，減少讀寫的差錯。代碼的結構，類型，編碼格式必須嚴格統(tǒng)一，以便于計算機處理。 ，能快速實現(xiàn)多項數(shù)據(jù)輸入和庫存數(shù)據(jù)的查詢。 (1)本系統(tǒng)的數(shù)據(jù)庫表 描述如下： 各字段的參數(shù)如表 31 所示 。設計器中可以實時反映變更 ,XAML 中智能感知功能可以提高開發(fā)效率。熟練 Microsoft Office Access(2張 )的軟件設計師和資料分析師利用它來開發(fā)應用軟件，而一些不熟練的程序員和非程序員的 進階用戶 則能使用它來開發(fā)簡單的應用軟件。 （ 1）員工編號：員工編號是員工的唯一標識，代碼結構采用 XXYYZZ000 XX YY ZZ 000 年份 月份 日期 序號 代碼前部分是員工進入公司的具體日期，后部分是順序序號。 因為此類代碼設計在數(shù)據(jù)庫查詢時實現(xiàn)復雜，故系統(tǒng)實現(xiàn)時一律采用順序碼。Persist Security Info=False Public userID As String = 39。標志，判斷用戶是否合法 ,False表示非法 ,True表示合法 Public Function RunSelectSQL(ByVal sSQLString As ) As DataView () 39。訪問數(shù)據(jù)庫 ，把數(shù)據(jù)讀到數(shù)據(jù)集 OledbDS里。本變量的作用，保存 RunSelectSQL()方法返回的結20 果 [即從數(shù)據(jù)庫讀到的數(shù)據(jù) ] Private Sub txbUserId_LostFocus(ByVal sender As Object, ByVal e As ) Handles Try 39。判斷用戶 ID是否存在 If = 0 Then 39。獲得用戶的密碼級用戶名 = (0)(密碼 ) = (0)(姓名 ) = (0)(姓名 ) End If Catch ex As Exception MsgBox() End Try End Sub Private Sub btnClear_Click(ByVal sender As , ByVal e As ) Handles () End Sub 21 End Class 主界面窗體代碼截圖 圖 42 圖 43 2.“機構設置情況”窗體 frm Department 設計、代碼及運行界面。 圖 43 23 圖 44 其窗體代碼如下： Public Class frmDepartment Private dvList As DataView Private Sub InitTree(ByRef nodes As TreeNodeCollection, ByVal sParentIndex As Integer) Try Dim tmpNode As TreeNode Dim absIndex As String Dim dvTemp As DataView = 選出數(shù)據(jù)源中 ParentIndex為 sParentIndex的數(shù)據(jù)行 24 Dim dataRows() As DataRow = (ParentIndex=39。) 39。添加節(jié)點 (tmpNode) 39。 ( ) dvList = 織機構編碼表 .DefaultView InitTree(, 1) 39。 str amp。 圖 45 26 圖 46 其窗體代碼如下： Public Class frmDepartMentInfo Private Sub 組織機構編碼表 BindingNavigatorSaveItem_Click(ByVal sender As , ByVal e As ) Handles 組織機構編碼表 () () (編碼表 ) End Sub Private Sub frmDepartMentInfo_Load(ByVal sender As , ByVal e As ) Handles 39。 測試的定義及目的 軟件測試就是在軟件投入運行前 ,對軟件的需求分析，設計規(guī)格說明和編碼的最終復審，是保證軟件質(zhì)量的關鍵步驟。 測試的原則 對于相對復雜的產(chǎn)品或系統(tǒng)來說 ,ZeroBug 是一種理想 ,GoodEnough 是我們的原則 。目前狀況唯一可用的答案是 :制定最低通過標準和測試內(nèi)容 ,然后具體問題具體分析 。 是界面測試中經(jīng)常出現(xiàn)的幾種 Bug： 錯別字 ， 即界面中的標題或者文本內(nèi)容中出現(xiàn)了錯別字 。 通常是因為程序中的控制錯誤或是程序開發(fā)人員對程序沒有進行認真的自測 ， 導致出現(xiàn)這種 Bug。 標題相近的程序及模塊 ， 把標題弄混 。 錄入功能中 ， 需要注意的是前臺設置的數(shù)值長度是否大于后臺數(shù)值長度 ， 以及前臺與后臺的數(shù)據(jù)結構是否相符 ， 很多時候錄入功能無法實現(xiàn)是由于這些原因 。 另外 ， 在刪除多條 記錄的時30 候 ,要注意連續(xù)選中的幾條記錄是否真正都被刪除了 ， 即如果再按照這種查詢方式查詢 ， 是否還能查詢出來 .有的時候需要在數(shù)據(jù)庫中設一個標志位 ， 而不是真正的物理刪除 。 需求測試 針對需求測試 ， 測試中很重要的一個環(huán)節(jié) 。 性能測試 測試在軟件的質(zhì)量保證中起著重要的作用 。引用某些控件 ,實現(xiàn)了程序中未實現(xiàn)的功能的同時 ， 也容易引發(fā)新的 Bug。 功能測試 ： 對網(wǎng)站的幾大功能模塊逐一測試 ,盡最大可能發(fā)現(xiàn)起潛在的錯誤。 32 第六章 總結 經(jīng)過兩個月艱苦卓絕的努力 ， 總于完成了本畢業(yè)設計 。 以后要多多注意這方面的事情 。 參考文獻 [1]、 周占文， 《 人力資源管理 》 [M] 電子工業(yè)出版社 2021 [2]、 陳剛 吳煥明， 《 人力資源管理方法 》 [M] 廣東經(jīng)濟出版社 2021 [3]、 魯曉東， JSP 軟件工程案例精解，電子工業(yè)出版社， 2021 年， 78210 33 [4]、 丁鵬， STRUTS 技術解密及 WEB 開發(fā)實例，清華大學 出版社， 2021 年，295323 [5]、 李小 喆 ， SQLServer 2021 管理及應用系統(tǒng)開發(fā) [M]．人民郵電出版社，2021， 17168 。 致謝 在整個畢業(yè)設計過程中我遇到了種種困難，通過我的努力和 老師、同學及朋友的幫助，終于克服困難，完成了畢業(yè)設計。 本來已經(jīng)耳熟能詳?shù)拇a ， 一到 IDE 中書寫 ,卻提筆忘字 ， 這充分的反應了我平時的基本功不扎實 ， 常用代碼的不熟練 .給我以后的工作敲響了警鐘 ， 有了努力的方向 。 需求測試 : 根據(jù)求分析 的內(nèi)容 ,測試網(wǎng)站是否和當初的設計一樣。由于一些模塊被修改了對其他模塊造成了影響而出現(xiàn)了新的 Bug， 發(fā)現(xiàn)這些 Bug 要求我們對程序整體的結構有 基本的了解 ,清楚模塊之間的一些聯(lián)系。 測試中其 他 注 意的地方 時常有這樣的情況發(fā)生 ， 每個模塊都能單獨工作 ,但這些模塊集成在一起之后卻不能正常工作 。 要針對需求測試 ， 首先就要 對項目的需求和業(yè)務有一定的了解 ， 這些需求很多時候是在實現(xiàn)增查 ， 修改這些 基本功能之上 ， 針對項目和相關業(yè)務所作的一些邏輯上的控制 。 關于修改功能的測試 ,主要是看修改 確認后是否數(shù)據(jù)真正已被修改了 。 測試刪除功能中需要注意的是單擊“刪除” 按鈕后 ,一般會出現(xiàn)提示信息 ,詢問是否確定刪除 。 功能測試 顧名思義 ， 功能測試主要是測試程序模塊是否實現(xiàn)了設計中所有要求的功能 。 這種情況基本上是由于開發(fā)人員使用一些專業(yè)術語 ， 并且混雜著自己的理解出現(xiàn) Bug， 主要是由于開發(fā)過程中團隊合作沒又明確的分工 ,沒有統(tǒng)一的規(guī)范用語 。 出 現(xiàn)了一些根本讀不懂的內(nèi)容 ， 一般多出現(xiàn)在程序的提示信息和一些較長的文本中 。 29 界面測試 界面測試是測試過程中比較簡單直觀的一種測試方法 ,只要細心地按界面要求核對就行了 。不充分的測試是不負責任的 ， 過分的測試是一種資源的浪費 ， 同樣也是一種不負責任的表現(xiàn) 。 測試的目的在于將軟件設計時設計者與程序開發(fā)者之間理解不一致的地方，功能與需求不一 致的地方，不符合邏輯思維的情況都反映給質(zhì)量控制部門 ,由質(zhì)量控制部門調(diào)配需求部門統(tǒng)一作出一個明確解答，再由開發(fā)人員進行修改和補充。 您可以根據(jù)需要移動或移除它 。 End Sub End Class 3.“機構詳細信息維護”窗體 frm department