【正文】 速度影響將會大于軟件的影響。 出錯處理設計 出錯輸出信息 出錯處理對策 如設置后備、性能降級、恢復啟動等。 示例(供參考)： 出錯輸出信息程序在運行時主要會出現(xiàn)兩種錯誤：由于輸入信息，或無法滿足要求時產(chǎn)生的錯誤，稱為軟錯誤。由于其他問題，如網(wǎng)絡傳輸超時等，產(chǎn)生的問題，稱為硬錯誤。對于軟錯誤，須在定票/領(lǐng)票操作成功判斷及輸入數(shù)據(jù)驗證模塊由數(shù)據(jù)進行數(shù)據(jù)分析，判斷錯誤類型，再生成相應的錯誤提示語句，送到輸出模塊中。對與硬錯誤，可在出錯的相應模塊中輸出簡單的出錯語句，并將程序重置。返回輸入階段。出錯信息必須給出相應的出錯原因，例：“該居民用戶的本月水費已收繳！”“數(shù)據(jù)庫連接錯誤，請查找原因后重新連接！”等。 出錯處理對策所有的客戶機及服務器都必須安裝不間斷電源以防止停電或電壓不穩(wěn)造成的數(shù)據(jù)丟失的損失。若真斷電時，客戶機上將不會有太大的影響，主要是服務器上：在斷電后恢復過程可采用 SQL SERVER 的日志文件，對其進行ROLLBACK 處理，對數(shù)據(jù)進行恢復。在網(wǎng)絡傳輸方面，可考慮建立一條成本較低的后備網(wǎng)絡，以保證當主網(wǎng)絡斷路時數(shù)據(jù)的通信。在硬件方面要選擇較可靠、穩(wěn)定的服務器機種，保證系統(tǒng)運行時的可靠性。 安全保密設計 數(shù)據(jù)安全性 數(shù)據(jù)保存、傳輸過程的安全性 登錄用戶的安全性 對用戶的身份驗證 操作安全性 對授權(quán)用戶權(quán)限的授予和回收。 系統(tǒng)安全性的其它考慮示例（供參考）： 數(shù)據(jù)安全性設計由于數(shù)據(jù)的傳輸上需要通過網(wǎng)絡傳輸，為了客戶資料進行保密，需要在網(wǎng)絡的傳輸過程中對數(shù)據(jù)進行加密。這個工作主要是在準備網(wǎng)絡包，及解開網(wǎng)絡包這兩個模塊完成，它們各對數(shù)據(jù)進行加密及解密還原工作。在加密算法選擇上將使用RSA 加密算法。具體算法可參照參考資料中《Computer Network》。 登錄用戶的安全性 系統(tǒng)設計了登錄界面，每個合法用戶有一個密碼，該密碼由用戶個人維護，從而實現(xiàn)對用戶的身份驗證 操作安全性 對授權(quán)用戶權(quán)限的授予和回收。如對查詢用戶（如經(jīng)營科長）沒有對水費手收繳模塊進行更新的權(quán)限；同理，該用戶在《月份水費收繳表》上沒有給定UPDATE權(quán)限。 維護設計說明為方便維護工作的設施，如代碼維護模塊等。示例（供參考）：維護方面主要為對服務器上的數(shù)據(jù)庫數(shù)據(jù)進行維護?？墒褂?SQL SERVER 的數(shù)據(jù)庫維護功能機制。例如，定期為數(shù)據(jù)庫進行Backup，維護管理數(shù)據(jù)庫死鎖問題和維護數(shù)據(jù)庫內(nèi)數(shù)據(jù)的一致性等。4 詳細設計從軟件開發(fā)的工程化觀點來看，在使用程序設計語言編制程序以前，需要對所采用算法的邏輯關(guān)系進行分析，設計出全部必要的過程細節(jié)，并給予清晰的表達，使之成為編碼的依據(jù)。這就是過程設計（詳細設計）的任務。過程設計也叫做詳細設計或程序設計，它不同于編碼或編程。在過程設計階段，要決定各個模塊的實現(xiàn)算法，并精確地表達這些算法。前者涉及所開發(fā)項目的具體要求和對每個模塊規(guī)定的功能。以及算法的設計和評價，后者需要給出適當?shù)乃惴枋?，為此應提供過程設計的表達工具。對于系統(tǒng)內(nèi)的每一個模塊，要逐個模塊給出以下的說明： 模塊一 模塊定義（1）模塊編號：按照命名規(guī)則，按照如下兩種情況命名：A）公用模塊，如打印驅(qū)動或打印報表公用程序，則可按照SXXX進行編號，其中，S(SHARE)表示公用，XXX為公用模塊的編號。b）私有模塊，一般而言屬于某個子系統(tǒng)的專有模塊，可按FXSXTX的方式進行編號。其中，F(xiàn)X，SX，TX分別表示第一、二、三級模塊的編碼（2）模塊名稱：此公用模塊的英文或中文名稱。（3）模塊功能：詳細列出此公用模塊的所有功能。 輸入項目所有輸入到該模塊的數(shù)據(jù)。 輸出項目所有從該模塊輸出的數(shù)據(jù)。 算法 模塊所選用的算法，給出算法的定義或描述。 程序邏輯 詳細描述模塊實現(xiàn)的算法，詳細設計工具可以分為三類：圖形工具、表格工具和語言工具。(1) 程序流程圖程序流程圖獨立于任何一種程序設計語言，比較直觀、清晰，易于學習掌握。但流程圖也存在一些嚴重的缺點。例如流程圖所使用的符號不夠規(guī)范，常常使用一些習慣性用法。特別是表示程序控制流程的箭頭可以不受任何約束，隨意轉(zhuǎn)移控制。這些現(xiàn)象顯然是與軟件工程化的要求相背離的。為了消除這些缺點，必須限定流程圖只能使用圖41所給出的五種基本控制結(jié)構(gòu)。圖41 流程圖的基本控制結(jié)構(gòu)Fig41 flow chart ‘s basic control structure (2) NS圖 Nassi和Shneiderman 提出了一種符合結(jié)構(gòu)化程序設計原則的圖形描述工具，叫做盒圖，也叫做NS圖。為表示五種基本控制結(jié)構(gòu)，在NS圖中規(guī)定了五種圖形構(gòu)件。參看圖52。圖42 NS圖的五種基本控制結(jié)構(gòu)Fig42 five kind of basic controls structure of NS chart (3) PAD圖PAD是Problem Analysis Diagram的縮寫，它是日本日立公司提出，由程序流程圖演化來的，用結(jié)構(gòu)化程序設計思想表現(xiàn)程序邏輯結(jié)構(gòu)的圖形工具?，F(xiàn)在已為ISO認可。PAD也設置了五種基本控制結(jié)構(gòu)的圖式，并允許遞歸使用。圖43 PAD的基本控制結(jié)構(gòu)Fig43 the basic control structure of PAD做為PAD應用的實例，圖44給出了圖43程序的PAD表示。PAD所描述程序的層次關(guān)系表現(xiàn)在縱線上。每條縱線表示了一個層次。把PAD圖從左到右展開。隨著程序?qū)哟蔚脑黾?，PAD逐漸向右展開。PAD的執(zhí)行順序從最左主干線的上端的結(jié)點開始，自上而下依次執(zhí)行。 每遇到判斷或循環(huán)，就自左而右進入下一層，從表示下一層的縱線上端開始執(zhí)行，直到該縱線下端，再返回上一層的縱線的轉(zhuǎn)入處。如此繼續(xù)，直到執(zhí)行到主干線的下端為止。圖44 PAD實例Fig44 PAD example此外，描述算法的工具還有判定樹和判定表，但由于這兩個工具只能表示靜態(tài)的算法而不能表達復雜的軟件邏輯，如循環(huán)、嵌套等，在使用的時候應該注意。 接口 限制條件 測試要點。 給出測試模塊的主要測試要求。下面以《火電土建工程質(zhì)量檢驗評定系統(tǒng)》為例進行說明（供參考）： 模塊名稱：分項工程驗評統(tǒng)計 功能描述：根據(jù)《火電工程施工質(zhì)量檢驗評定標準》提供的標準，將該分項工程各驗評項目的所有驗評數(shù)據(jù)進行統(tǒng)計分析計算，得出該分項工程的質(zhì)量優(yōu)良率和質(zhì)量評定等級，經(jīng)有關(guān)單位負責人審核簽字后提交給數(shù)據(jù)庫。 輸入數(shù)據(jù)有如下幾種形式：n 一類項目的檢驗項數(shù)及符合要求的項數(shù)n 二類項目的檢查項數(shù)、“優(yōu)良”項目數(shù)及優(yōu)良率n 三類項目的實測點數(shù)、“合格”點數(shù)及合格率 輸出數(shù)據(jù)有如下幾種形式：n 由上述三種數(shù)據(jù)最終統(tǒng)計得到的評定等級n 最后的復查意見，文本型 算法定義：1．評定等級“優(yōu)良”的定義：1） 一類觀感數(shù)據(jù)全部為達標驗收2） 二類數(shù)據(jù)的優(yōu)良率不小于50%3） 三類數(shù)據(jù)的優(yōu)良率不小于90%2 評定等級“合格”的定義：1）一類觀感數(shù)據(jù)全部為達標驗收2）二類數(shù)據(jù)的全部在“合格”以上3）三類數(shù)據(jù)的優(yōu)良率不小于70%3 評定等級“不合格”的定義：凡不符和合格標準中的任意一條，則該工程為不合格工程。YYNylnumber_2/number_2 = 0 and ylnumber_3/number_3 = 0YNylnumber_3/number_3 = 0YNpddj = 39。優(yōu)良39。pddj = 39。合格39。pddj = 39。不合格39。參見算法設計圖二圖55 二類、三類項目驗評數(shù)據(jù)全部非空時的算法number_2 0 and number_3 0YNFig55 the algorithm of two kinds or three kind of projects whenexamine data pletely nonfree 算法設計方案： number_2 0 and number_3 = 0YYNylnumber_2/ = 0PPddj = “優(yōu)良”Npddj=39。合格39。 pddj=39。優(yōu)良39。Nnumber_2 = 0 and number_3 0YYylnumber_3/ = 0Pddj = “不合格”pddj=39。合格39。NNylnumber_3/ = 0pddj=39。合格39。YNnumber_2 = 0 and number_3 = 0NY給定出錯信息“二類、三類項目沒有驗評，請給出驗評數(shù)據(jù)”圖56 二類、三類項目驗評數(shù)據(jù)部分或全部為空時的算法Fig56 the algorithm of two kinds or three kind of projects when examine data pletely nonfree or partial nonfree 模塊二。5 編碼 概述開發(fā)工具及編程腳本 簡述編程腳本的特點，不宜占用過多的篇幅。 腳本習慣說明 如變量的取名規(guī)則，全局變量說明等。 腳本 開發(fā)工具的控件、驅(qū)動事件、腳本。如果腳本量較大，則可作為附錄附在論文的后面。6 測試 測試原則及測試方法概述軟件測試是為了發(fā)現(xiàn)錯誤而不斷執(zhí)行程序的過程?；蛘哒f，軟件測試是根據(jù)軟件開發(fā)各階段的規(guī)格說明和程序的內(nèi)部結(jié)構(gòu)而精心設計一批測試用例（即輸入數(shù)據(jù)及其預期的輸出結(jié)果），并利用這些測試用例去運行程序，以發(fā)現(xiàn)程序錯誤的過程按順序逐個對測試項目做出說明。軟件測試過程應該遵循如下的原則：①盡早地和不斷地進行軟件測試。不應把軟件測試僅僅看作是軟件開發(fā)的一個獨立階段，而應當把它貫穿到軟件開發(fā)的各個階段中。堅持在軟件開發(fā)的各個階段的技術(shù)評審，這樣才能在開發(fā)過程中盡早發(fā)現(xiàn)和預防錯誤，把出現(xiàn)的錯誤克服在早期，杜絕某些發(fā)生錯誤的隱患。② 測試用例應由測試輸入數(shù)據(jù)和與之對應的預期輸出結(jié)果這兩部分組成。測試以前應當根據(jù)測試的要求選擇測試用例（Test case），用來檢驗程序員編制的程序，因此不但需要測試的輸入數(shù)據(jù)，而且需要針對這些輸入數(shù)據(jù)的預期輸出結(jié)果。③ 程序員應避免檢查自己的程序。程序員應盡可能避免測試自己編寫的程序，程序開發(fā)小組也應盡可能避免測試本小組開發(fā)的程序。如果條件允許，最好建立獨立的軟件測試小組或測試機構(gòu)。這點不能與程序的調(diào)試（debuging）相混淆。調(diào)試由程序員自己來做可能更有效。④ 在設計測試用例時，應當包括合理的輸入條件和不合理的輸入條件。合理的輸入條件是指能驗證程序正確的輸入條件，不合理的輸入條件是指異常的，臨界的，可能引起問題異變的輸入條件。軟件系統(tǒng)處理非法命令的能力必須在測試時受到檢驗。用不合理的輸入條件測試程序時，往往比用合理的輸入條件進行測試能發(fā)現(xiàn)更多的錯誤。⑤ 充分注意測試中的群集現(xiàn)象。在被測程序段中，若發(fā)現(xiàn)錯誤數(shù)目多，則殘存錯誤數(shù)目也比較多。這種錯誤群集性現(xiàn)象，已為許多程序的測試實踐所證實。根據(jù)這個規(guī)律，應當對錯誤群集的程序段進行重點測試，以提高測試投資的效益。⑥ 嚴格執(zhí)行測試計劃，排除測試的隨意性。測試之前應仔細考慮測試的項目，對每一項測試做出周密的計劃，包括被測程序的功能、輸入和輸出、測試內(nèi)容、進度安排、資源要求、測試用例的選擇、測試的控制方式和過程等，還要包括系統(tǒng)的組裝方式、跟蹤規(guī)程、調(diào)試規(guī)程，回歸測試的規(guī)定，以及評價標準等。對于測試計劃，要明確規(guī)定，不要隨意解釋。⑦ 應當對每一個測試結(jié)果做全面檢查。有些錯誤的征兆在輸出實測結(jié)果時已經(jīng)明顯地出現(xiàn)了，但是如果不仔細地全面地檢查測試結(jié)果，就會使這些錯誤被遺漏掉。所以必須對預期的輸出結(jié)果明確定義，對實測的結(jié)果仔細分析檢查，抓住征侯，暴露錯誤。⑧ 妥善保存測試計劃，測試用例，出錯統(tǒng)計和最終分析報告，為維護提供方便。測試過程按4個步驟進行，即單元測試、組裝測試、確認測試和系統(tǒng)測試。圖71顯示出軟件測試經(jīng)歷的4個步驟。圖61 軟件測試的過程Fig61 Software tests process軟件測試的種類大致可以分為人工測試和基于計算機的測試。而基于計算機的測試由可以分為白盒測試和黑盒測試。① 黑盒測試根據(jù)軟件產(chǎn)品的功能設計規(guī)格，在計算機上進行測試，以證實每個實現(xiàn)了的功能是否符合要求。這種測試方法就是黑盒測試。黑盒測試意味著測試要在軟件的接口處進行。就是說，這種方法是把測試對象看做一個黑盒子，測試人員完全不考慮程序內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程序的需求分析規(guī)格說明，檢查程序的功能是否符合它的功能說明。用黑盒測試發(fā)現(xiàn)程序中的錯誤，必須在所有可能的輸入條件和輸出條件中確定測試數(shù)據(jù)，來檢查程序是否都能產(chǎn)生正確的輸出。② 白盒測試根據(jù)軟件產(chǎn)品的內(nèi)部工作過程，在計算機上進行測試，以證實每種內(nèi)部操作是否符合設計規(guī)格要求，所有內(nèi)部成分是否已經(jīng)過檢查。這種測試方法就是白盒測試。白盒測試把測試對象看做一個打開的盒子，允許測試人員利用程序內(nèi)部的邏輯結(jié)構(gòu)及有關(guān)信息，設計或選擇測試用例，對程序所有邏輯路徑進行測試。通過在不同點檢查程序的狀態(tài)，確定實際的狀態(tài)是否與預期的狀態(tài)一致。以上是測試的內(nèi)容的概述，在論文中，要寫你用到的測試方法及過程。 測試項目測試用例（1） 模塊名稱。 （2） 操作過程及數(shù)據(jù)。 （3） 預期結(jié)果（4） 實際結(jié)果（5） 偏差（6） 用例類別下面以銀行業(yè)務《XXXXXX銀行帳務系統(tǒng)》進行說明，鑒于本用例是一個計劃用例，故沒有給出實際的測試結(jié)果。表61 系統(tǒng)測試案例tab61 system tests case模塊