【正文】 軟件中，貸款管理和貸后管理是重要的組成部分，因此需要及時的更新版本，以此來滿足用戶日益增長的需求，這兩個子模塊的開發(fā)周期基本為半個月到一個月，每個開發(fā)周期都會增加一定數(shù)量的新功能以滿足用戶需求和提高產品功能。在測試階段，將重復的性能測試，回歸測試，功能點測試進行管理，可以有效的減少測試人員的工作量，使得測試人員可以將精力集中在新增功能點的驗收測試中，進一步的提高測試的效率，以此來保證軟件質量滿足用戶的需求。具體表現(xiàn)為：軟件測試行業(yè)中各種軟件測試的方法、技術和標準都還在探索階段；少數(shù)幾個專業(yè)化第三方軟件測試機構的出現(xiàn)。軟件測試不是軟件開發(fā)的最后階段，而是貫穿于軟件項目的整個生命周期。信息產業(yè)部和國家質檢總局領導成立了國家級計算機軟件產品質量檢測機構——中國軟件評測中心，省和直轄市單位也專門成立了各自的軟件評測中心。如：2002年美國EMC公司宣布成立EMC微軟 Windows測試中心，負責測試微軟產品在存儲網絡環(huán)境中的應用，同時也進行 Windows 平臺上存儲網絡的適應性測試及模擬客戶環(huán)境測試；美國 IDG InfoWorld 測試中心成立多年以來，已經成為全球軟件產品的品質測試和評估的首選機構及高品質軟件產品的權威推薦機構。 第四章Quality Center在信貸系統(tǒng)功能測試中的應用：通過對信貸功能測試，進行測試用例設計，及所采用的功能測試流程；并在測試中使用 Quality Center 去實現(xiàn)整個測試的過程。隨著這一定義被廣泛使用， 人們發(fā)現(xiàn)了定義中存在的不足，于是在 1983年， IEEE 在軟件工程標準術語中提出并調整了對軟件測試的定義，即“使用人工或自動的手段來運行或測試某個系統(tǒng)的過程，其目的在于驗證它是否滿足規(guī)定的需求或弄清預期結果與實際結果之間的差別”。它一方面檢查軟件產品質量和存在的問題，同時對軟件產品質量進行客觀的評價。因為程序最終是由用戶來使用的,而在程序中存在著許多預料不到的問題,可能沒有被發(fā)現(xiàn)出來,許多隱藏的錯誤只有在特定條件下才能顯露出來。一般談到軟件測試目的時,人們都會引用Grenford J. Myers在《The Art of Software Testing》—書中的觀點:1．軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。 實踐證明，缺陷發(fā)現(xiàn)的越早，修改缺陷的成本就越低。軟件使用過程中出現(xiàn)的錯誤不完全是編程人員在編碼階段引入的，大部分都是在程序設計階段和需求分析階段就遺留下來的。3． 軟件測試應追溯需求。 在軟件測試過程中大部分情況下窮舉測試是不可能實現(xiàn)的。5． 關注群集現(xiàn)象：充分應用二八定理 統(tǒng)計表明，在進行了測試后，被測試程序中匯總殘留的缺陷數(shù)目和程序中已發(fā)現(xiàn)的缺陷數(shù)目相比較，大部分都成正比。所以在測試過程中，如果發(fā)現(xiàn)某一模塊或程序比其他模塊或程序有更多缺陷，應當考慮對這部分模塊或程序花更多的時間更全面和深入的進行測試。7． 必須確定預期輸出結果進行軟件測試過程中，必須確定好預期輸出，通過輸入操作和輸入數(shù)據以及系統(tǒng)環(huán)境，可以給出一個正確的測試結果，如果測試用例中沒有給出預期測試結果，那么就無法驗證系統(tǒng)執(zhí)行是否正確，這樣很有可能會遺漏缺陷。 軟件測試的分類從不同的角度來考慮，軟件測試可以有不同的劃分方法，對測試進行分類可以更好的明確不同軟件測試過程中，需要完成的工作有哪些。通過輸入數(shù)據得到實際輸出結果，依照需求規(guī)格說明書中對該功能的描述來判斷實際輸出結果和預期結果是否相一致，從而檢驗系統(tǒng)功能實現(xiàn)是否正確，以及功能實現(xiàn)的可靠性、有效性等。2．靜態(tài)測試和動態(tài)測試這種分類是從是否執(zhí)行程序的角度來劃分的。通過輸入相應的測試用例和數(shù)據，檢查運行結果是是否符合預期要求，從而檢驗程序的正確性和有效性，并分析系統(tǒng)的效率和健壯性等性能。4．單元測試、集成測試、確認測試、系統(tǒng)測試和驗收測試這種分類是從軟件測試的階段來劃分的。檢測多個模塊連接在一起后能否正常工作是這一階段的主要測試目標。它是在軟件產品交付用戶正式使用前的最后一道工序。件測試V模型。同時軟件測試模型也有所發(fā)展出現(xiàn)了 W模型、H模型、X模型等。在W模型中，強調軟件測試是貫穿整個軟件開發(fā)周期，而不再是開發(fā)編碼完成后才進行的工作。2. 需求分析與系統(tǒng)設計階段測試人員需要對需求設計說明書進行確認，并驗證需求設計說明書的內容是否符合用戶需求。5. 編碼階段：測試人員需要根據單元測試計劃及方案和單元測試用例，對開發(fā)完成的模塊進行單元測試，并記錄和跟蹤軟件缺陷。9. 軟件系統(tǒng)測試總結階段：測試人員需要編寫該軟件系統(tǒng)的測試總結，包括測試過程情況描述，缺陷情況描述以及測試結果等。在這里，運行一個程序并不需要對理解其內部結構。2． 每項功能符合實際要求。功能測試一般須在完成集成測試后進行，而且是針對應用系統(tǒng)進行測試。2） 功能測試是個數(shù)據與測試用例分離，也即是一個將測試數(shù)據與測試邏輯(步驟)分開，簡化測試用例的過程，在執(zhí)行用例時才選擇相應的數(shù)據。 功能測試目的功能測試，在單元測試中的功能測試是保證測試的每個獨立模塊在功能上是正確的，在單元測試中主要采用白盒測試。測試的附帶收獲是，它能夠證明軟件的功能性能與需求說明是相符合的。因此，測試不僅僅是一種技術，不僅僅是開發(fā)完成后的驗證活動，真正要做好測試，更需要建立起一套測試管理體系。軟件測試管理是一種活動，可以對各階段的測試計劃，測試用例，測試流程，測試文檔等進行跟蹤、管理并記錄其結果。測試管理包含的內容有：測試框架、測試計劃與組織、測試過程管理、測試分析與缺陷管理。2. 方便任務的異地處理。測試經理或者開發(fā)經理可以通過該項將任務分發(fā)給不同的人員；并可以在軟件管理工具實時跟蹤員工的進度，從而及時發(fā)現(xiàn)問題。QC 對測試管理包括以下四個部分的內容：明確需求：對需求進行分析，得出測試需求，確定測試范圍，建立需求，通過用戶提交的需求，經常需求分析人員、開發(fā)人員和測試人員審核后，提交到 QC 的需求管理；還可以產生報告和圖表幫助測試人員分析測試需求，檢查需求以確保它們在測試范圍內。還可以生成報告和圖表去觀看測試結果，確定在測試執(zhí)行中的缺點是否被發(fā)現(xiàn)，哪些測試用例不能被執(zhí)行。 本章小結本章重點介紹了軟件測試的基本定義及流程，功能測試的概念及目的，介紹了軟件測試工具QC的基本概況和測試管理，為我們整個測試提供理論及技術支持?？蛻粜畔⒐芾硎峭ㄟ^對包括客戶基本信息。客戶信用管理是一個子系統(tǒng)，其主要包括對客戶信用評定、統(tǒng)一授信、貸款黑名單管理等功能。定量指標的計算采取兩位小數(shù)，客戶評級不僅包括正常新建客戶也包括存量原有客戶的評級，同時也需要對評級進行調整。 擔 保 管 理模 塊擔保管理主要由擔保人管理、抵押物管理、質押物管理三個業(yè)務組成。 貸 后管 理模 塊貸后管理業(yè)務主要分為五級分類、貸后檢查以及黑名單管理等子業(yè)務。風險資產管理的不良資產管理又分為置換不良貸款臺賬和置換不良貸款流水。破產企業(yè)管理提供用戶查詢相關破產企業(yè)等相關客戶的信息，同時，可以將破產企業(yè)添加到當前系統(tǒng)中，記錄相關破產企業(yè)的信息。相應權限的操作員進入呆賬核銷審批界面，該界面將展現(xiàn)當前該操作員待審批的業(yè)務列表，操作員勾選要審批的業(yè)務，進入審批頁面后，填寫處理意見和呆賬認定信息即可完成審批功能。 統(tǒng) 計查 詢模 塊統(tǒng)計查詢提供查詢信貸業(yè)務的歷史審批信息。操作員根據客戶名稱和客戶類型查看客戶的歷史放貸信息及明細。業(yè)務辦理主要包括信貸業(yè)務的全過程，如手里業(yè)務，進行調查分析、審核資料、審批業(yè)務，進行合同簽訂、發(fā)放貸款，進行資料變更、貸款催收等，同時變更主要涉及到擔保物、期限等同時對于問題類貸款，村鎮(zhèn)銀行要進行資產保全管理。目前村鎮(zhèn)銀行信貸系統(tǒng)的開發(fā)周期基本為一個月到一個半月，每個開發(fā)周期都會增加一定數(shù)量的新功能以滿足用戶需求和提高產品功能。由于村鎮(zhèn)銀行信貸系統(tǒng)中各個子系統(tǒng)之間存在一定的關聯(lián)關系，所以在測試階段，測試人員必須對各個模塊有所認識，預先考慮到可能發(fā)生的聯(lián)動性缺陷，這樣才能保證測試的完整性與正確性。執(zhí)行功能測試的結果要跟蹤、評審。 性 能 測 試性能測試是驗證系統(tǒng)是否達到用戶提出的性能指標，同時發(fā)現(xiàn)系統(tǒng)中存在的性能瓶頸，起到優(yōu)化系統(tǒng)的目的。除此之外，為了防止新版本系統(tǒng)在發(fā)布之后出現(xiàn)重大缺陷，還需要進行相應的回退測試，保證更新后的新版本系統(tǒng)能正?；赝酥辽弦粋€版本。測試用例(Test Case)是為了選定目的(如考察特定程序路徑或驗證是否符合特定的需求)而設計的測試數(shù)據及與之相關的測試規(guī)程的一個特定的集合，或稱為有效地軟件缺陷的最小測試執(zhí)行單元。在軟件測試中，由于工作量過大，一般不采用窮舉測試，這樣就必須精心設計測試用例。盡量將具有相類似功能的測試用例抽象并歸類軟件測試過程是無法進行窮舉測試的，因此，對相類似的測試用例的抽象過程顯得尤其重要，一個好測試用例應該是能代表一組或者一系列的測試過程。功能測試的測試用例的設計主要有以下幾種方法：等價類劃分法是把所有可能的輸入或輸出情況的數(shù)據進行評估，然后劃分到多個子集中進行測試，然后從每一個子集中選取少數(shù)具有代表性的數(shù)據作為測試用例，即將所有可能的輸入數(shù)據(包括有效的或者無效的)劃分成若干個等價類。因果圖法因果圖是利用圖解法去分析各種輸入數(shù)據組合的情況，然后進行測試用例的設計，是用來檢查輸入條件的各種組合的情況。功能圖法功能圖法是根據所有的輸入、輸出以及狀態(tài)來形成實現(xiàn)功能圖的測試用例的依據。需求分析的目的是確保測試的覆蓋率是足夠的，測試需求(例如：在用戶需求提到的所有功能點都在測試范圍)都應該在測試用例中覆蓋。測試用例的結束(在內部的檢查結束后)，沒有再次發(fā)現(xiàn)問題，就意味著測試用例的結束。用戶主要是參與外部的檢查，當測試人員和測試協(xié)調員認為測試用例符合測試要求后，用戶將參與到測試用例的檢查。圖4. 1測 試用 例設 計流 程 村 鎮(zhèn)銀 行信 貸系 統(tǒng)模 塊測 試用 例的需 求分 析編 寫需求分析和高層次的設計是測試用例設計的第一步。Traceability Matrix(TM)是在測試用例覆蓋率上最好的輸出文件。當需求改變的時候，TM 也將進行更新還反應需求的變更；從而相應的測試用例也會隨著TM的更新進行修改。 村 鎮(zhèn)銀 行信 貸系 統(tǒng)用 例設 計 測 試用 例設 計測試用例設計，首先要設計測試用例的結構，本次設計的功能測試用例的內容主要分為三個方面：一是被測試的軟件產品的相關信息；二是測試用例和人員的基本信息；三是測試過程描述及測試結果和問題描述信息，即是測試用例的結構模板中必須包括以下幾個關鍵的信息：Test Case name、Step No.、PreCondition、Objective、Step Description、Expected result、Test case designer。除此外，在 Test Plan 中的各個組成的項中，各個項目可以根據實現(xiàn)的要求進行選取需要的測試用例到 Test Lab 去執(zhí)行測試用例?？梢韵拗品潜卷椖康哪承y試人員去修改或者刪除測