【正文】 與之對應的預期輸出結果這兩部分組成。(3)程序員應避免檢查自己的程序。(4)在設計測試用例時，應當包括合理的輸入條件和不合理的輸入條件。(5)充分注意測試中的群集現(xiàn)象。(6)嚴格執(zhí)行測試計劃，排除測試的隨意性。(7)應當對每一個測試結果做全面檢查。(8)妥善保存測試計劃，測試用例，出錯統(tǒng)計和最終分析報告，為維護提供方便。 測試的方法依據(jù)前面所說的測試對象，我們把測試劃分為幾個方面來進行測試。登錄測試是測試中直觀的測試方法，輸入登錄時所需的信息就可以了，但是也會有以下幾種會報錯的地方，如果所輸入的用戶名和密碼不匹配，則會出現(xiàn)提示窗口，請重新輸入；若輸入的用戶名不存在，系統(tǒng)也會彈出提示對話框，提示所輸入的用戶名不存在，請重新輸入用戶名。 界面測試界面測試是測試過程中比較簡單直觀的一種測試方法，只要細心地按界面要求核對就行了?？蛇@塊往往是程序開發(fā)人員容易忽視和遺漏的地方，也是常常出Bug的地方。 下面是界面測試中經(jīng)常出現(xiàn)的幾種Bug：(1)錯別字，即界面中的標題或者文本內(nèi)容中出現(xiàn)了錯別字。這種Bug如果測試人員不細心，很難找出來，可能會出現(xiàn)在提示信息或界面中。(2)出現(xiàn)了一些根本讀不懂的內(nèi)容，一般多出現(xiàn)在程序的提示信息和一些較長的文本中。這種情況基本上出現(xiàn)在拼起來顯示的提示中，頁面的簡單陳述是通過變量拼組起來的，通過程序將字一個一個地輸出來。通常是因為程序中的控制錯誤或是程序開發(fā)人員對程序沒有進行認真的自測，導致出現(xiàn)這種Bug。(3)程序員自創(chuàng)的詞語，雖然意思對，但不符合界面的標準及需求。這種情況基本上是由于開發(fā)人員使用一些專業(yè)術語，并且混雜著自己的理解出現(xiàn)Bug，主要是由于開發(fā)過程中團隊合作沒有明確的分工，沒有統(tǒng)一的規(guī)范用語。(4)頁面類似的內(nèi)容中，明顯有字體，字號不同的情況，使界面整體風格看上去不一致，這種情況只出現(xiàn)在沒有樣式表定義的情況下，或是已經(jīng)定義的樣式表，開發(fā)人員在開發(fā)過程中沒有調(diào)用。(5)標題相近的程序及模塊，把標題弄混。這種情況多是因為業(yè)務方面的定義名稱很相似或很類似，并且業(yè)務實體方面也很類似，開發(fā)人員在開發(fā)過程中忽略了開發(fā)名稱和模塊，只單獨地實現(xiàn)其功能。 功能測試顧名思義，功能測試主要是測試程序模塊是否實現(xiàn)了設計中所有要求的功能。功能測試中需要注意的有：(1)查詢功能中，基本上按單一查詢條件進行查詢的，要對沒有查詢出結果的異常情況進行處理；(2)錄入功能中，需要注意的是前臺設置的數(shù)值長度是否大于后臺數(shù)值長度，以及前臺與后臺的數(shù)據(jù)結構是否相符，很多時候錄入功能無法實現(xiàn)是由于這些原因。還有就是必須錄入的字段的設置是否有誤。(3)測試刪除功能中需要注意的是單擊“刪除”按鈕后，若刪除成功，則會彈出一個對話框，顯示所刪除的內(nèi)容刪除成功。另外，在刪除多條記錄的時候，要注意連續(xù)選中的幾條記錄是否真正都被刪除了，即如果再按照這種查詢方式查詢，是否還能查詢出來。有的時候需要在數(shù)據(jù)庫中設一個標志位，而不是真正的物理刪除。所以在下一次查詢中，可能還會被查詢出來，這主要是因為在查詢條件中沒有將標志位考慮在內(nèi)。(4)關于添加功能的測試，主要是看添加確認后是否所輸入的數(shù)據(jù)在數(shù)據(jù)庫表中是沒有出現(xiàn)的。若添加的數(shù)據(jù)在數(shù)據(jù)庫已經(jīng)存儲了，則添加失敗。若成功，則彈出對話框，添加的數(shù)據(jù)成功。這是最基本的功能，需要注意的是看是否能把已經(jīng)添加的數(shù)據(jù)也添加成功了。(5)信息錄入的測試，主要是看錄入時，所輸入的時間、課程名和一些基本信息在信息管理表中是否存在，若不存在，則信息錄入操作將失敗，不能進行信息的錄入。 需求測試針對需求測試，是測試中很重要的一個環(huán)節(jié)。因為需求是在軟件設計，開發(fā)乃至軟件測試中重要的依據(jù)。要針對需求測試，首先就要對項目的需求和業(yè)務有一定的了解。這些需求很多時候是在實現(xiàn)增，刪，查，改這些基本功能之上，針對項目和相關業(yè)務所作的一些邏輯上的控制。這就要求程序員在設計和編碼的時候要去充分理解考慮需求。性能測試在軟件的質量保證中起著重要的作用。通常我們把性能指標全部歸結到硬件，操作系統(tǒng)和開發(fā)環(huán)境上，而忽略了代碼本身性能上的考慮。性能需求指標中，穩(wěn)定性，并訪支撐能力以及安全性都很重要，作為程序員需要評估該模塊在系統(tǒng)運營中所處的環(huán)境，將要受到的負荷壓力以及各種潛在的危險和惡意攻擊的可能性。 測試中其他要注意的地方時常有這樣的情況發(fā)生，每個模塊都能單獨工作，但這些模塊集成在一起之后卻不能正常工作。其主要原因是，模塊相互調(diào)用時接口會引入許多新問題。這就要求在進行程序設計和編碼的時候要盡可能地從整體考慮。 錯誤本身出現(xiàn)在程序設計階段，并非由于程序員編碼造成的問題。這就要求我們無論是在開發(fā)還是測試階段，對需求或程序設計存在疑問，應及時提出，及時解決。由于一些模塊被修改了，對其他模塊造成了影響而出現(xiàn)了新的Bug。發(fā)現(xiàn)這些Bug要求我們對程序整體的結構有基本的了解，清楚模塊之間的一些聯(lián)系。 課堂考勤信息系統(tǒng)的測試在完成編碼的工作以后，根據(jù)以上的方法和步驟進行了如下的測試： 界面測試：反復點擊界面上的按鈕及菜單，使界面風格盡可能的統(tǒng)一； 功能測試：對系統(tǒng)的幾大功能模塊逐一測試，盡最大可能發(fā)現(xiàn)其潛在的錯誤； 性能測試：測試程序的運行速度，以及程序的安全性； 需求測試：根據(jù)需求分析的內(nèi)容，做出對部門進行管理的附加功能以及個性化的系統(tǒng)管理功能，給用戶帶來更大的方便； 通過這幾方面的測試，及時修正了系統(tǒng)中存在的問題，提高了系統(tǒng)的性能。第七章 總 結整個課堂考勤管理考試系統(tǒng)主要包括上面所寫的模塊及功能，基本上能夠覆蓋了課堂考勤日常管理中的主要操作。由于時間、所學以及精力的關系，該系統(tǒng)還處于原型設計階段，許多預想的模塊還沒有能夠及時添加進去。系統(tǒng)的設計的部分也有些模塊還可以更好的進行完善。 系統(tǒng)中需要改進的問題 本課堂考勤管理系統(tǒng)的設計和分析到目前為止還只是一個初始階段，在這段時間的設計過程中，許多的不足。l 系統(tǒng)只提供了鍵盤和鼠標的輸入，沒有提供條碼掃描的輸入。l 系統(tǒng)沒有提供打印輸出的功能，如果需要打印還需借助其他的軟件。l 系統(tǒng)沒有提供用戶的工作日志和操作記錄。l 系統(tǒng)中的一些模塊的功能的基本信息中并不全面，還有很多涉及到信息管理的要素沒有添加進去。l 系統(tǒng)只是提供了一個簡單的功能，與現(xiàn)代化的課堂考勤管理還有一定的差距。l 系統(tǒng)中的某些功能并沒有真正的達到系統(tǒng)功能的方便、快捷。l 系統(tǒng)的一些模塊的功能是理論化的，在實際中還有許多更復雜的情況并沒有考慮進去。在以后實際作用過程中還有很多地方需改進。 展望對于一個學校的課堂考勤管理來說，該系統(tǒng)還只是一個雛形，沒有完成的事情還很多。有了現(xiàn)有的系統(tǒng)原型，還要與學校進行溝通，根據(jù)錄入的信息來對課堂考勤進行操作，有了請求才開始對課堂考勤進行操作，將他們實際操作中發(fā)現(xiàn)的問題考慮進去，在課堂考勤與課堂考勤之間需要進行調(diào)撥，逐步改進上面談到的一些不足點，完善整個系統(tǒng)。另外，還需參照學校的其他系統(tǒng)，開發(fā)出與其他系統(tǒng)的接口。這樣才能這正的令學校的管理系統(tǒng)達到完善，為學校提供更多的便利。結 束 語參 考 文 獻[1] 張海藩、軟件工程導論(第五版)、北京:清華大學出版社、2008；[2] 王瑞、于速、 Studio 2010數(shù)據(jù)庫系統(tǒng)開發(fā)完全手冊、人民郵電出版社、2006；[3] 姜曉東、C、北京、 機械工業(yè)出版社、 2011年1月；[4] C Web編程、 北京 、人民郵電出版社、 2002年10月第一版；[5] Chris 、C Web編程、北京人民郵電出版社、2002年第一版；[6]王珊、數(shù)據(jù)庫系統(tǒng)概論(第四版)、高等教育出版社、2006年5年第四版；[7]陳英學、 、 北京希望電子出版社、2001年； [8]劉楊等編著、突破C編程實例五十講、中國水利水電出版社、2002年；[9]閃四清、 數(shù)據(jù)庫系統(tǒng)原理與應用、清華大學出版社、2001年；[10] 李真文、SQL Server 2000 Developer’s Guide 開發(fā)人員指南、北京希望電子出版社、2001年.