1、軟件工程導論課程設計報告公交車管理系統的設計與實現學生姓名：張勇學號:090403010063年級專業：09信息管理與信息系統指導教師：龍海第一章緒論第二章系統分析2.1. 組織結構分析2.2. 業務流程分析 2.3. 數據流程分析24系統需求分析2.5. 需求規格說明書2.6. 處理邏輯說明第三章可行性研究3.1引言3.2現行公交車管理概況3.3擬建立的信息系統3.4經濟可行性分析3.5技術可行性分析3.6社會可行性分析3.7可行性研究結論第四章系統設計4.1. 引言4.2. 系統設計方案第五章公交車管理系統的功能實現5.1登陸界面編碼設計5.2人員整體信息管理界面編碼設計5.3財務信息管理

2、界面編碼設計5.4客運信息查詢第六章系統測試計劃6.1. 引言6.2. 計:劃6.3. 測試設計說明6.4. 評價準則第七章總結第一章緒論針對公交車傳統作業流程中的種種弊端， 結合現代迅速發展的信息技術，我 運用所學的信息管理及系統分析與設計的知識開發出了公交車的管理信息系統。一個計算機管理系統必須有一個正確的設計指導思想，通過合理的選擇數據 結構，操作系統以及開發環境，構成一個完善的網絡系統，才能充分發揮計算機 信息管理優勢。現代化的車站售票是集預定車票、售票、退票、車次查詢、報表及其他各種服務，車站售票組織龐大，服務項目多，信息量大，要想提高勞動 生產，降低成本，提高服務質量和管理水平，進

3、而促進經濟效益，必須借助計算 機來進行現代化的信息管理。此系統包括四大塊：1、可行性研究報告：從系統的總統出發，對經濟、技術、社會、管理多方 面進行綜合分析，即經濟可行性分析、技術可行性分析、社會可行性分析和管理 可行性分析，是項目在開始階段必須進行的一項工作。2、系統分析報告：它反映的是系統分析階段調查分析的全部情況，是系統 分析員與用戶在一起，充分了解用戶需求后所編寫，作為后續開發工作的依據， 也是衡量一個信息系統優劣的依據。3、系統設計報告：在已獲準的系統分析報告的基礎上，結合實際條件，可 想而、合理地設計出得系統解決方案，是系統設計階段工作的成果的總結， 也是 系統實施階段的重要依據。

4、4、系統測試報告：將系統最主要的功能模塊進行逐一的檢測，對說明書中列舉的功能進行排查，對系統實現各功能的正常運行做充分的測試， 輸入合理及 不合理的測試數據檢驗功能的運行及出錯處理情況。此系統的開發，主要是給管理工作者帶來工作上的便利。 運用科學、系統的 方法有步驟、有目的、循序漸進的開發完成。第二章系統分析根據對用戶的需求，對公交車的業務活動的進行全面的調查分析， 詳細掌握 了相關工作流程，收集票據、賬單、報表等資料，分析現行系統的局限性和不足之處，并根據公交的條件，找出可行方案。2.1. 組織結構分析：公交車隊的高層領導由一名總隊長、 三名副隊長組成。總隊長負責總體事務 的決策，畐9隊長負

5、責主要事務的決策，三個副隊長分別負責客運部、售票部、糾 紛協調部、財務部。其具體職能如下：客運部主要職能是負責公交班次安排，負責司機行為規范，負責站點監督和 指導。售票部主要職能是負責售票員的售票，負責車票價格的協調與制定。糾紛協調部得主要職能是負責臨時突發事件，例如，乘客鬧事，交通堵塞，客車故障，交通事故等等。財務部主要職能是負責收銀，負責會計，負責財務分析，負責報表。22業務流程分析收費監控流程：根據系統中設定的路段收費標準，當公交駛入某收費路段售票員判斷車輛所 屬地，同時，售票員根據不同路段的不同價位在收費劃單中操作，根據收費單中的價格告知乘車顧客，并進行收費，乘客將公交車費交給售票員后

6、，售票員將撕 一張已打印好的交款憑證給顧客。如果售票員工作失誤，多撕了、少撕了或者撕錯了憑證，可以繼續給下一位 乘客交款憑證（少撕的憑證可以即時補給），先完成收費工作，然后要將廢票的 票據出示給監控員，監控員依據廢票的票據號進行廢票的處理工作 （監控員只是 登記廢票的票據號，做一個刪除登記，不能徹底刪除），處理完后記錄廢票信息。每天每班車工作完成后，售票員將收費單和剩余收款憑證交至會計人員進行 審核，確定無誤后登記，每日會計統計出日報表和客人流數據交給收銀員；月末收銀員審核過數據后將月報表、年報表交至財務部由財務分析員對這些報表數據 進行分析，以便做好進一步的規劃預算，同時還需將月報表、年報表

7、和客流量匯 總表及時交給總隊長。其業務流程圖如圖：222會計記賬流程：會計人員根據售票員提供的剩余憑證和收費劃單及監控員提供的作廢憑證在電腦上進行登記賬單，形成日報表，再將日報表交由收銀員審核，審核通過則 收銀員根據會計做的日報表，月末形成月報表，年末形成年報表。不通過，則返 回日報表給會計令其糾正。其業務流程圖如圖：23數據流程分析財務管理流程：每天每班車工作完成后，售票員將收費單和剩余收 款憑證交至會計人員進行審核，確定無誤后登記，每日會計統計出日報表和客人 流數據交給收銀員；月末收銀員審核過數據后將月報表、 年報表交至財務部由財 務分析員對這些報表數據進行分析，以便做好進一步的規劃預算，

8、同時還需將月 報表、年報表和客流量匯總表及時交給總隊長。數據字典（一）數據流的描述數據流編號：D-1數據流名稱：購票單簡述：由工作人員幫助乘客填好購票單數據流來源：乘客數據流去向：登記處審核處理數據項組成：乘客名稱+票價+車票類型+經手人+購買時間數據流量：約8張/日高峰流量：約15張/日數據流編號：D-2數據流名稱：收款憑證簡述：經登記處填好的收款憑證數據流來源：登記處審核處理數據流去向：售票員數據項組成：乘客名稱+票價+車票類型+經手人+購買時間數據流量：約8張/日高峰流量：約15張/日數據流編號：D-3數據流名稱：收費單簡述：由售票員填好的收費單數據流來源：售票員數據流去向：會計人員審核

9、登記處理數據項組成：乘客名稱+票價+車票類型+經手人+購買時間數據流量：約2張/周高峰流量：約4張/周（二）處理邏輯的描述處理邏輯編號：P-1處理邏輯名稱：購票單審核簡述：審核購票單輸入的數據流：購票單處理描述：審核購票單，填寫收款憑證輸出的數據流：收款憑證處理頻率：8次/日處理邏輯編號：P 2 處理邏輯名稱：會計人員審核登記處理簡述：根據收費單將數據記入日報表輸入的數據流：收費單處理描述：根據收費單將數據記入日報表，并更新相關數據輸出的數據流：客流數據處理頻率：8次/日（三）數據存儲的描述數據存儲編號：F-2數據存儲名稱：匯總臺賬簡述：記錄車票銷售的情況數據存儲組成：銷售數量+乘客名稱+票價

10、+車票類型+經手人+購買時間 關鍵字：乘客名稱+票價相關聯的處理：P 1，P 2，P 3（四）外部實體的描述外部實體編號：S-1外部實體名稱：售票員簡述：填寫收費單輸入的數據流：D2, D3, D 4輸出的數據流：D22.4. 系統需求分析241計算機和處理器處理器800MHz以上（如果開啟視頻至少1GHz）內存128MB以上（如果開啟視頻至少 256MB）243硬盤安裝需要100MB的硬盤空間，運行需要 50MB空余空間244顯示器最小800 x 600 （建議使用1024 x 768）屏幕分辨率瀏覽器計算機上應該安裝了 Microsoft In ternet Explorer 6或更高版本

11、，但是不一定要設置為默認瀏覽器。2.4.6I nternet 連接互聯網接入（寬帶接入效果最佳，無線接入質量降低，模擬線路不建議使用） 管理人員的支持管理人員對該系統充分理解與支持，并要求其員工進行系統操作培訓。2.5. 需求規格說明書引言2.5. 1.1編寫目的目的是提高工作效率，節約人力資源，并作為軟件設計人員設計依據和使用單 位的驗收標準。預期的讀者是軟件設計人員還有組織高層人員。2.5.1.2 背景此待開發系統的名叫公交車信息管理系統，是公交車高層管理人員提出需要開發此項目，進行研究開發，供車隊指定工作人員使用。2.5.1.3 定義Xm： XML( Extensible Markup

12、Language )即可擴展標記語言，它與 HTML一樣，都是 SGML（Sta ndard Gen eralized Markup Lan guage,標準通用標記語言）。Xml是In ternet環境中跨平臺的，依賴于內容的技術，是當前處理結構化 文檔信息的有力工具。擴展標記語言XML是一種簡單的數據存儲語言，使用一系 列簡單的標記描述數據，而這些標記可以用方便的方式建立， 雖然XML占用的空 間比二進制數據要占用更多的空間，但 XML極其簡單易于掌握和使用。XML與 Access,Oracle和SQL Server等數據庫不同，數據庫提供了更強有 力的數據存儲和分析能力，例如：數據索引、

13、排序、查找、相關一致性等，XML僅僅是展示數據。事實上XML與其他數據表現形式最大的不同是：他極其簡單。 這是一個看上去有點瑣細的優點，但正是這點使XML與眾不同。XML與 HTM的設計區別是：XML是用來存儲數據的，重在數據本身。而 HTM L是用來定義數據的，重在數據的顯示模式。XML的簡單使其易于在任何應用程序中讀寫數據，這使XML很快成為數據交 換的唯一公共語言，雖然不同的應用軟件也支持其它的數據交換格式， 但不久之 后他們都將支持XML那就意味著程序可以更容易的與 Windows Mac OS, Linu x以及其他平臺下產生的信息結合，然后可以很容易加載XML數據到程序中并分 析他

14、，并以XML格式輸出結果。任務概述2.521目標本系統通過強大的網絡技術給組織的工作人員帶來方便，本系統能實現客運 管理、售票管理、協調糾紛管理、財務管理，提高工作人員的工作效律，為工作 人員提供了極大方便，即使不出門也可以進行工作上的處理。用戶特點最終用戶可分為操作人員、維護人員。 其中，操作人員要求對計算機有一 定了解的人員。維護人員要求對本系統有較深的了解， 同時對系統相關信息及工 作流程有所了解的技術人員。本系統需要在資源的動態更新，這時候也是本系統 最需要維護的時候，所以在這時候要對本系統進行必要的檢修，防止數據出錯2.5. 2.3假定與約束設計的約束或實現約束描述在設計或實現應用系

15、統時應遵守的限制條件。其并不是要取代設計（實現）過程，只是說明用戶或環境強加給項目的限制條件項目投入的最晚時間。需求規定2.531對功能的規定輸入輸出輸入限制輸出限制并行用戶數支持終端數后臺處理用戶登錄執勤登錄賬號密碼文本首頁漢字、 數字、 英文字 母小于255小于255進入首頁界面進入工作中心管理模塊進入指定工作界面數據更新文本列表存儲后臺管理登錄注冊文本文本存儲修改文本文本修改， 存儲查詢文本列表文本列表查詢，輸出資源 添加、 刪除文本文本存儲，修改對性能的規定a. 精度要求查詢切換之間的時間控制以秒為單位，輸入數據為文本，無精度要求。 查詢數據能夠符合用戶的要求，沒有冗余數據。輸出數據精

16、度要求為盡量符合資 源特征。b. 時間特性要求i . 響應時間：小于2秒；ii. 更新處理時間：即時更行；iii. 數據的轉換和傳送時間：小于2秒；C.靈活性可在任意平臺下運行，當操作方式、數據結構、與其它軟件接口等發生變化 時，設計的軟件要基本無調整，靈活性非常大。但資源需放到指定位置，需及時 更新索引。2.533輸入輸出要求輸入數據類型，具體要求見上表，輸出為資源列表。數據管理能力要求需要管理的文卷和記錄大約有100來份，占用內存大致1MB故障處理要求a. 如果界面打不開或是登錄失敗，應檢查系統防火墻是否關閉，更新索引。b在輸入數據不符合定義時提示正確類型并重；新輸入；c數據在數據庫中已有

17、備份，系統出錯時可以靠數據庫恢復其他專門要求2.6. 處理邏輯說明由于最底層數據流程圖中的加工不能再通過子圖做進一步的描述，因此必須有處理邏輯說明來定義底層數據流圖中的加工。如：售票員收費對在不同路段， 乘客到達目的的不同路程收取不同票價。 在此處我們用判斷樹法來表示售票員售票過程。第三章可行性研究此可行性研究報告是在制定項目前對公交管理項目實施的可能性、 有效性、 技術方案及技術政策進行具體、深入、細致的技術論證和經濟評價，報告的主要 內容如下：3.1引言目的：為了更加便于公交車系統的管理，提高工作效率，尤其是完善 財務管理與提高公交財務會計等的管理。背景：現行的公交體系仍舊是一個不完整的、

18、分散的、相互競爭的沒 有統一的系統。3.2現行公交車管理概況組織目標與戰略：提高公交員工的工作效率，盡可能減少成本提高效益， 以最小的成本獲取最大的收益。通過建立一個完善的公交管理信息系統，利用先 進的設備提高記賬效率，完善工資核算體系，明確分工，明確各個司機的路線， 對不遵守路線規則惡意競爭者予以懲處，以建立一個完善，和諧，系統，高效的 公交車管理信息系統。存在的主要問題：記賬只是傳統的手工記賬，設備也是簡單的計算器。 司機之間有相互的競爭，司機經常不遵守發車秩序和時間，經常誤點、踩點。公 交監控幾乎沒有，只是落后的人工監控。3.3擬建立的信息系統簡要說明：建立一個高效率的集賬務管理系統，員

19、工管理系統，工資 管理系統和監控獎懲系統于一體的信息系統。對組織的意義和影響：提高了公交工作效率，員工工作熱情，完善了 對司機員工的監管，公交秩序井然，服務質量提高，收益大大增加，成本減少， 使得凈利潤增加。3.4經濟可行性分析支出（包括系統開發費用和系統運行費用）系統開發費用:a人員費用。b. 硬件設備費,c. 軟件費用d. 耗材費用假定本系統運行期為5年，每年系統耗費如下：a. 系統維護費。b. 設備維護費。c. 消耗材料費。收益本系統獲得的直接經濟效益可以從以下幾個方面計算。a. 提高工作效率，減少工作人員。本系統投入運行后，可以提高人力資源管理、財務預算管理、車輛運行管理，累計可以提高

20、工作效率10%。b. 及時獲取信息，減少決策失誤。提高工作人員上班的準時性，減少車次延 誤的可能；分析年數據信息，及時推出相關政策，以提高工作效益。c. 直觀了解每班車次的客流，便于以后做統計報表，分析趨勢，作出最優決卒J策Od. 提高工作效率，減少工作人員的工作量。3.5技術可行性分析技術可行性分析已經學習了 SQL SERVER，對網絡技術和操作系統也有系統的了解，有些 成員熟悉計算機原理，能解決常見的硬件故障和硬件選擇。而且，網上有許多關 于VISUL BASIC編程的資料和SQL SERVER方面的資料。所以從技術上來說，此次開發是可行。3.6社會可行性分析社會法律政策可行性：目前已有

21、很多成功開發公交車管理信息系統的 先例，社會需要公交車管理的現代化和信息化。此信息系統開發和運行并不違背國家的法律政策。362社會公共環境可行性：公交所走路線的公路都是符合質量要求的，顧 客也多。操作可行性：此信息系統所采用的操作和工作方式符合工作人員和讀 者的日常習慣，而且操作方便靈活，簡單、便于學習。綜上所述，該系統具有社會可行性。3.7可行性研究結論通過經濟、技術、社會等方面的可行性分析，可以確定本系統的開發完全必 要，而且是可行的，可以進行開發。第四章系統設計將設計過程中所形成的各種文檔資料進行編輯處理，編寫成系統設計報告， 主要內容和格式如下：4.1. 引言目的：為了更加便于公交車系

22、統的管理，提高工作效率，尤其是完善 財務管理與提高公交財務會計等的管理。背景：現行的公交體系仍舊是一個不完整的、分散的、相互競爭的沒 有統一的系統。4.2. 系統設計方案4.2.1 系統總體結構設計公交管理系統集合了原本車隊的四個子系統：客運管理，售票管理，糾紛協調管理，財務管理。車隊的管理人員可以同時查詢和了解四個子系統的工作情況， 使得車隊的管理層能夠更好的了解和監督工作情況，保證工作高效進行。在子系統中有自己的管理模塊。模塊功能圖如圖：客運管理公交管理系統人員管理車輛管理日耗油管理維修管理421.1 客運管理公交人員管理該模塊針對公交管理系統的基層工作人員和管理層工作人員的基本信息進 行

23、管理，基層工作人員基本信息包括姓名、性別、所屬部門、聯系方式，管理層 工作人員的基本信息除了包括姓名、性別、所屬部門、聯系方式等以外，還記錄 該工作人員的登錄密碼、編號和級別，方便權限管理。在模塊中可實現對信息的 增加，修改，刪除，查詢，打印等功能。公交車信息管理該模塊針對車隊里的13輛公交車的基本信息進行管理，包括車型，發動機 類型，重量，載客數，功率，車牌號，車輛制造廠。在模塊中可實現對信息的增 加，修改，刪除，查詢，打印等功能。耗油管理該模塊針對車隊的13輛車每輛每日的耗油量信息管理，需每日更新。維修管理該模塊針對車隊的13輛公交車的維修狀況進行管理。記錄每次維修的基本 信息，包括維修車

24、輛車牌號，維修部位，維修日期，維修地點，維修費。421.2售票管理票價管理該模塊針對不同路段的售票價格進行管理。收費管理該模塊記錄著售票員的日常工作，每個售票員一日有十班次，記錄包括每個 班次的人流數、每班次售出的每種票價的票數、 每班次收入總數，最后統計出整 日的人流、票數、總收入。廢票管理該模塊記錄了再收費過程中由于操作失誤而產生的作廢車票信息，底層員工無權處理，高權限監督管理人員方可進行處理。糾紛協調管理意外事故處理管理該模塊記錄每次事故處理的基本信息，包括事故發生時間、地點、肇事人、 事故發生原因、事故處理支出。乘客反饋管理該模塊記錄任何乘客們的反饋以及提出的有益建議。財務管理收銀管理

25、該模塊由收銀員進行操作，記錄著每個售票員的每班次的收入， 同時也記錄 了每個班次的人流數、每班次售出的每種票價的票數。 每日最后一班車后，收銀 員要作出最后統計每個售票員一日的工作情況， 包括整日的人流、票數、總收入。1提示)提示)messagebox（系統登錄密碼錯誤，請重新輸入！,64,二二 thisform.textl.setfocus n=n-1elsethisform.textl.e nabled=.f.thisform.text2.e nabled=.f. ma ndl.e nabled=.f.messagebox（系統登錄密碼嚴重錯誤，請退出系統!,64, en difen di

26、fen difen dif5.2人員整體信息管理界面編碼設計增加記錄：thisform.grid1.e nabled=.t.sele工作人員表appe nd bla nkthisform.refresh刪除記錄：if messagebox（確定要刪除該條記錄嗎？,1+32,信息）=1select工作人員表deletethisform.refreshelseen dif修改記錄：thisform.grid1.e nabled=.t.thisform.refresh查詢記錄：thisform.grid1.e nabled=.T.thisform.refresh5.3財務信息管理界面編碼設計5.4客

27、運信息查詢sele * from 客車信息表 in to cursor tempthisform.grid1.colu mncoun t=-1thisform.grid1.recordsource=temp第六章系統測試計劃系統設計完成后，還有一項重要的工作，那就是系統測試和調試，找出不足， 進行系統完善。系統測試報告的主要內容和格式如下：6.1. 引言編寫目的對項目進行測試，詳細記錄測試過程，對軟件的質量進行評估，同時提供了 更正系統漏洞的依據。定義A. 黑盒測試：黑盒測試也稱功能測試，它是通過測試來檢測每個功能是否都 能正常使用。在測試中，把程序看作一個不能打開的黑盒子， 在完全不考慮程序

28、 內部結構和內部特性的情況下，在程序接口進行測試，它只檢查程序功能是否按 照需求規格說明書的規定正常使用，程序是否能適當地接收輸入數據而產生正確 的輸出信息。黑盒測試著眼于程序外部結構，不考慮內部邏輯結構，主要針對軟 件界面和軟件功能進行測試。B. 白盒測試：白盒測試也稱結構測試或邏輯驅動測試，它是按照程序內部的結構測試程序，通過測試來檢測產品內部動作是否按照設計規格說明書的規定正 常進行，檢驗程序中的每條通路是否都能按預定要求正確工作。這一方法是把測試對象看作一個打開的盒子，測試人員依據程序內部邏輯結構相關信息， 設計 或選擇測試用例，對程序所有邏輯路徑進行測試，通過在不同點檢查程序的狀態，

29、 確定實際的狀態是否與預期的狀態一致。6.2計劃軟件說明名稱功能輸入輸出系統登錄測試判別用戶身份是否合法用戶名、密碼、權限顯示相應子系統財務管理測試財務流入支出管理財務收支信息修改、添加、刪除財務信息職工信息查詢測試職工各種信息職工號所需查詢的職工相關信息會員測試幫助市民公交卡充值、查詢用戶id和公交卡id公交卡余額顯示，修 改、添加、刪除會員信 息客運信息測試查詢客運的信息公交車牌號、查詢日期該公車的司機與搭檔用戶、管理員管理測試管理用戶管理員登錄系統查詢、添加、刪除、修改、鎖定用戶622測試內容測試1:名稱：系統登錄測試目的：測試系統操作界面內容：輸入用戶名、密碼、權限，檢查用戶是否合理、

30、合法測試2:名稱：財務管理測試目的：測試公交系統財務管理功能內容：查詢、添加、刪除、修改每日財務信息測試3：名稱：職工信息查詢測試目的：測試系統查詢職工工資、職位等信息內容：輸入職工號和密碼，進行職工信息查詢測試4：名稱：會員測試目的：會員公交卡充值功能和查詢余額修改信息功能內容：輸入會員身份證和公交卡號，進行公交卡充值和查詢測試5：名稱：客運信息測試目的：明確公交負責人，查詢公交出問題時由誰負責內容：查詢出所要查詢的日期的公交是那個職工負責測試6：名稱：用戶、管理員管理測試目的：測試用戶、管理員的管理功能內容：添加、刪除、修改用戶、管理員信息623測試1 （系統登錄測試）參與單位：軟件開發人

31、員被測試的部位：登錄界面進度安排測試日期：6.232條件測試人員：編寫者進行該功能模塊的測試測試軟件：采用黑盒測試的方法，由人工設計測試用例, 進行測試。包括合理的數據及不合理的數據測試資料需求規格說明書概要設計說明書詳細設計說明書測試培訓測試2 （財務管理測試）參與單位：軟件開發人員被測試的部位：會計人員模塊的財務管理功能進度安排測試日期：6.2.4.2 條件測試人員：編寫者進行該功能模塊的測試對該功能模塊一次對該功能模塊一次測試軟件：采用黑盒測試的方法，由人工設計測試用例, 進行測試。包括合理的數據及不合理的數據6.243測試資料需求規格說明書概要設計說明書詳細設計說明書6.244測試培訓

32、測試3 （職工信息查詢測試）進度安排測試日期：6.2.5.2 條件測試人員：編寫者進行該功能模塊的測試測試軟件：采用黑盒測試的方法，由人工設計測試用例, 進行測試。包括合理的數據及不合理的數據測試資料需求規格說明書概要設計說明書詳細設計說明書測試培訓測試4 （會員測試）進度安排測試日期：6.2.6.2 條件測試人員：編寫者進行該功能模塊的測試測試軟件：采用黑盒測試的方法，由人工設計測試用例, 進行測試。包括合理的數據及不合理的數據測試資料需求規格說明書概要設計說明書詳細設計說明書對該功能模塊一次對該功能模塊一次測試培訓627測試5 （會員測試）627.1進度安排測試日期：627.2條件測試人員

33、：編寫者進行該功能模塊的測試測試軟件：采用黑盒測試的方法，由人工設計測試用例，對該功能模塊一次 進行測試。包括合理的數據及不合理的數據測試資料需求規格說明書概要設計說明書詳細設計說明書測試培訓測試6 （用戶、管理員測試）進度安排測試日期：6.2.8.2 條件測試人員：編寫者進行該功能模塊的測試測試軟件：采用黑盒測試的方法，由人工設計測試用例，對該功能模塊一次 進行測試。包括合理的數據及不合理的數據628.3測試資料需求規格說明書概要設計說明書詳細設計說明書測試培訓6.3.測試設計說明測試1 （系統登錄測試）對于系統登錄測試應該既要考慮到用戶身份的合法性驗證也要考慮到用戶 身份的不合法性驗證。6

34、.3.1.1 控希 9根據用戶不同的身份權限可以先人工輸入一些數據， 然后根據不同的權限對 系統登錄進行測試。631.2輸入、輸出根據不同的輸入，可以得出不同的輸出結果，其結果可以如下表所示:輸入輸出用戶名密碼權限進入公開公交網頁admin管理員登錄失敗，輸入錯 誤admi管理員登錄失敗，輸入錯 誤admiadmin管理員登錄成功，進入管理員模塊111111職工登錄失敗，輸入錯 誤001職工登錄失敗，輸入錯 誤001111111職工登錄成功，進入職工登錄模塊631.3過程根據不同的身份，輸入各自的用戶名和密碼，包括密碼和用戶名分別為空的 情況，對系統登錄模塊進行測試。如果輸入錯誤，則登錄失敗；

35、輸入成功，則登 錄成功；其中如果用戶名和密碼都為空，則默認為是普通市民進入公交網頁。測試2 （財務管理測試）6.3.2.1 控制輸入權限，進入賬號和密碼，對財務進行查詢，修改，刪除等等。輸入、輸出5.323過程運行系統，進入財務人員模塊，進行財務信息查詢和修改、刪除，測試財務 查詢功能。測試3 （職工信息管理測試）對職工信息管理的各項功能，包括職工各種信息的添加、刪除、修改進行測 試，以及對部門分類的添加、刪除、修改進行測試。6.3.3.1 控制根據職工所需的信息對職工管理系統進行錄入操作，并且可以添加職工職位 分類。同時也可以對職工信息進行修改和刪除操作。6.332輸入、輸出職工號姓名性別出

36、生日期職稱所屬部門輸入001張三男10/05/70司機客運部輸出添加成功職工號姓名性別出生日期職稱所屬部門輸入102黃安男06/30/88會計財務部輸出添加成功6.3.3.3 過程運行系統，進入管理員模塊，對圖書管理及圖書分類管理進行測試。測試4 （會員測試）5.3.4.1 控制會員登陸系統，通過用戶id和公交卡id，會員可以進行公交卡充值余額查詢，從而以測試會員功能。6.342輸入、輸出輸入輸出用戶id公交卡id用戶編號不能為空19900721公交卡編號不能為空19900020此用戶不存在19900721200305191此卡號不存在19900721200305190001登錄成功6.343

37、過程運行系統，進入用戶模塊，查詢余額，充值公交卡，測試充值功能。測試5 （客運信息測試）6.3.5.1 控希 9在管理員模塊對公交車負責人進行測試，其中包括公交車牌號和日期正確和 不正確的情況。輸入、輸出輸入、輸出輸入、輸出輸入、輸出輸入錯誤輸入、輸出輸入錯誤輸入、輸出還書成功6.3.5.3 過程運行系統，進入管理員模塊，輸入公交車牌號和值班日期進行負責人測試。 測試6 （用戶、管理員管理測試）6.3.6.1 控制運行管理員模塊對用戶和管理員進行管理，其中包括添加、刪除、修改、鎖定普通用戶以及查看用戶借書情況，也可以添加、刪除、修改管理員信息以及修 改密碼。6.362輸入、輸出添加用戶測試：輸

38、入輸出用戶名密碼qqqq用戶名重復3密碼不能為空3用戶名不能為空33添加用戶成功修改用戶測試:輸入輸出修改前修改后用戶名密碼是否鎖定用戶名密碼是否鎖疋33未鎖疋34未鎖疋修改成功33未鎖疋43未鎖疋修改成功33未鎖疋44鎖定修改成功33未鎖疋44鎖定修改成功添加管理員測試:輸入輸出用戶名密碼確認密碼11已存在的名字admi密碼不能為空admin用戶名不能為空admiadmin確認密碼不能為空admiadminadmin添加成功修改密碼測試:輸入輸出原密碼確認原密碼新密確認新密碼碼adminadminadmin1a兩次密碼不同admina原密碼錯誤adminadminadmin1adm ini密碼修改成功5.363過程運行系統，進入管理員模塊，對用戶管理和管理員管理進行測試，包括添加、 刪除成功和不成功的測試。6.4.評價準則范圍此測試可將系統最主要的功能模塊進行逐一的檢測，對說明書中列舉的功能 進行排查，對系統實現各功能的正常運行