【正文】 生的聯(lián)動性缺陷，這樣才能保證測試的完整性與正確性。 系統(tǒng)測試策略 功 能測 試主要目標是為了檢查軟件是否完成需求規(guī)定的功能，要求每個“功能用例”都已完全經(jīng)過測試。主要技術方法是用“合法的”和“非法的”數(shù)據(jù)，執(zhí)行每一個測試用例，用“合法的”測試數(shù)據(jù)，測試結果是正確的；用“非法的”測試數(shù)據(jù)，系統(tǒng)將顯示出錯或警告的提示信息。測試人員編寫的功能測試用例要經(jīng)過評審，明確定義功能測試的通過準則，確保功能測試覆蓋所有的路徑，使之對合理和不合理的輸入都能鑒別和響應。執(zhí)行功能測試的結果要跟蹤、評審。 回 歸 測 試回歸測試是對軟件修改后重新測試先前的測試以保證修改的正確性。對本系統(tǒng)的回歸測試包含兩部分：回歸本次未作變動的功能點，以確保原有功能的有效性。回歸開發(fā)修復后的缺陷，保證新版本的正確性。 性 能 測 試性能測試是驗證系統(tǒng)是否達到用戶提出的性能指標，同時發(fā)現(xiàn)系統(tǒng)中存在的性能瓶頸，起到優(yōu)化系統(tǒng)的目的。目前，本項目的性能測試主要集中在新增功能點的性能測試。當新功能點需要與后臺進行交互時，需要進行大量用戶并發(fā)訪問該功能點和對大數(shù)據(jù)量進行讀取，修改，更新，刪除的性能測試。 安 裝測 試安裝測試是保證軟件在正常情況和異常情況的不同條件下，例如，進行首次安裝、升級、完整的或自定義的安裝都能進行安裝。除此之外，為了防止新版本系統(tǒng)在發(fā)布之后出現(xiàn)重大缺陷，還需要進行相應的回退測試，保證更新后的新版本系統(tǒng)能正?；赝酥辽弦粋€版本。 本章小結本章以村鎮(zhèn)銀行信貸系統(tǒng)的概述為出發(fā)點，詳細的介紹了村鎮(zhèn)銀行信貸系統(tǒng)的各個組成模塊及業(yè)務流程。隨后在村鎮(zhèn)銀行信貸系統(tǒng)的測試章節(jié)中，主要介紹了該系統(tǒng)在更新升級版本是所用的測試策略。浙江大學碩士學位論文 第4章 Quality Center在信貸系統(tǒng)功能測試中的應用第4章 Quality Center在信貸系統(tǒng)功能測試中的應用 村 鎮(zhèn)銀 行信 貸系 統(tǒng)軟 件模 塊測 試用 例 測 試用 例設 計原 則測試用例是為了實現(xiàn)測試有效性的一種常用工具，好的測試用例可以在測試過程中重復利用。測試用例(Test Case)是為了選定目的(如考察特定程序路徑或驗證是否符合特定的需求)而設計的測試數(shù)據(jù)及與之相關的測試規(guī)程的一個特定的集合，或稱為有效地軟件缺陷的最小測試執(zhí)行單元。測試用例的內(nèi)容包括測試目標、測試環(huán)境、輸入數(shù)據(jù)、測試步驟、預期結果、測試腳本等，并形成文檔。不同類別的軟件，測試用例是不同的。不同于諸如系統(tǒng)、工具、控制、游戲軟件，管理軟件的用戶需求更加不統(tǒng)一，變化更大、更快。在軟件測試中，由于工作量過大，一般不采用窮舉測試，這樣就必須精心設計測試用例。也就是要從數(shù)量極大的可用測試用例中精心地挑選少量的測試數(shù)據(jù)，使得采用這些測試數(shù)據(jù)能夠達到最佳的測試效果，或者說它們能夠高效率地把隱藏的錯誤揭露出來。所以在測試用例設計時，要遵循一些基本的原則：盡量避免含糊的測試用例含糊的測試用例給測試過程帶來困難，甚至會影響測試的結果。在測試過程中，測試用例的狀態(tài)是唯一的，通過情況下，在執(zhí)行測試過程中，良好的測試用例一般會有三種狀態(tài)：通過(Pass)、未通過(Failed)、以及未測試過(No Run)，如果測試未通過，一般會有測試的(Bug)報告進行聯(lián)系；如未進行測試，則需要說明原因，因此，清晰的測試用例使測試人員在測試過程中不會出現(xiàn)模棱兩可的情況，不能說這個測試用例部分通過，部分未通過，或者是從這個測試用例描述中不能找到問題。盡量將具有相類似功能的測試用例抽象并歸類軟件測試過程是無法進行窮舉測試的，因此，對相類似的測試用例的抽象過程顯得尤其重要，一個好測試用例應該是能代表一組或者一系列的測試過程。盡量避免冗長和復雜的測試用例這樣做的目的主要目的是保證驗證結果的唯一性，在測試過程執(zhí)行過程中，確保測試用例的輸出狀態(tài)唯一性，從而便于跟蹤和管理。在一些很長和復雜的測試用例設計過程中，需要將測試用例進行合理的分解，從而保證測試用例的準確性。在某些時候，當測試用例包含很多不同類型的輸入或者輸出，或者測試過程的邏輯復雜而不連續(xù)，此時需要對測試用例進行分解。功能測試的測試用例的設計主要有以下幾種方法：等價類劃分法是把所有可能的輸入或輸出情況的數(shù)據(jù)進行評估，然后劃分到多個子集中進行測試，然后從每一個子集中選取少數(shù)具有代表性的數(shù)據(jù)作為測試用例，即將所有可能的輸入數(shù)據(jù)(包括有效的或者無效的)劃分成若干個等價類。邊界值分析法邊界值分析法是對輸入的邊界值進行測試，在測試過程中，經(jīng)常在邊界值出現(xiàn)問題；很多開發(fā)人員在邊界值的處理不好。所以，大量的錯誤發(fā)生在輸入或者輸出數(shù)據(jù)為邊界值的時候。邊界值分析方法設計測試用例主要考慮的因素是要選取剛剛小于、等于、剛剛大于的邊界的值作為測試數(shù)據(jù)。因果圖法因果圖是利用圖解法去分析各種輸入數(shù)據(jù)組合的情況，然后進行測試用例的設計，是用來檢查輸入條件的各種組合的情況。錯誤推測法錯誤推測法主要依賴于測試人員的經(jīng)驗、直覺去檢查和推測程序中各種可能存在的錯誤，從而有針對性地去設計測試用例。在這個測試用例的設計方法是通過測試人員的推測能力去考慮程序中所有可能出現(xiàn)錯誤或者容易出錯的地方，從而去測試相應的測試用例。例如有些在一些頁面數(shù)據(jù)顯示過多時，程序可能會出現(xiàn)讀取不了數(shù)據(jù)，有時還可能導致 500 Internal Sever Error 的錯誤。功能圖法功能圖法是根據(jù)所有的輸入、輸出以及狀態(tài)來形成實現(xiàn)功能圖的測試用例的依據(jù)。測試用例由一系列的狀態(tài)以及在每個狀態(tài)中必須依靠輸入和輸入數(shù)據(jù)滿足的一系列條件組成。 信 貸系 統(tǒng)軟 件模 塊測 試用 例設 計流 程信貸系統(tǒng)模塊測試用例設計的流程包括以下幾個關鍵步驟()：需求分析和高層次的設計是測試用例設計的第一步。這個階段輸入的是用戶的需求。需求分析的目的是確保測試的覆蓋率是足夠的，測試需求(例如：在用戶需求提到的所有功能點都在測試范圍)都應該在測試用例中覆蓋。測試用例設計，即使用合適的測試模板對測試用例進行編寫工作。QA活動(對于內(nèi)部的檢查)，在測試用例設計的初稿編寫完，將通過自我檢查和內(nèi)部檢查，通常是自己測試協(xié)調(diào)員或者測試人員交互檢查測試用例的覆蓋率和測試用例編寫的正確與否。測試用例的修改，當測試用例在檢查時發(fā)現(xiàn)了需要修改的問題，將由測試用例編寫本人對測試用例實行修改，更新測試用例的版本。測試用例的結束(在內(nèi)部的檢查結束后)，沒有再次發(fā)現(xiàn)問題，就意味著測試用例的結束。一個測試用例設計流程圖，有三個角色的人參與到測試用例編寫的過程，其中包括測試人員、測試協(xié)調(diào)員、用戶。在這三種參與測試用例編寫的角色中，測試人員除了負責測試用例的編寫工作外，還會參與測試用例的自我檢查和內(nèi)部檢查，并進行測試用例的修改。測試協(xié)調(diào)員主要是負責內(nèi)部檢查的工作，保證測試人員編寫的測試用例符合測試的要求，并保證測試用例的質(zhì)量。用戶主要是參與外部的檢查，當測試人員和測試協(xié)調(diào)員認為測試用例符合測試要求后，用戶將參與到測試用例的檢查。主要的流程是測試人員對需求進行分析和對比，然后寫完 Traceablity Matrix(TM)，然后將寫完的TM進行內(nèi)部的檢查；如果沒有發(fā)現(xiàn)測試用例需求修改的地方，測試用例將進行外部的檢查，即是提交給用戶進行檢查，外部用戶檢查通過后，就進行測試用例 SignOff；然后將測試用例上傳到QC，可以進行測試用例的執(zhí)行階段。測試用例需求進行修改的情況有以下幾種：第一種是測試用例在內(nèi)部檢查不通過，發(fā)現(xiàn)要修改的地方；第二種情況是測試用例在外部檢查時發(fā)現(xiàn)要修改的測試用例；第三種的情況是需求的變更后，但是又不需要增加新的測試用例，例如該更新后的需求，只需要在原來的測試用例基礎上加多一個步驟就可以測試，或者修改某個步驟，因此將原有的測試用例按變更后的需求進行修改。在測試用例的流程中，QC 使用的時間是發(fā)生在測試用例不再需要修改，符合了需求覆蓋的要求，可以準備進入執(zhí)行測試的時候。圖4. 1測 試用 例設 計流 程 村 鎮(zhèn)銀 行信 貸系 統(tǒng)模 塊測 試用 例的需 求分 析編 寫需求分析和高層次的設計是測試用例設計的第一步。這個階段輸入的是用戶的需求。需求分析的目的是確保測試的覆蓋率是足夠的，測試需求(例如：在用戶需求提到的所有功能點都在測試范圍)都應該在測試用例中覆蓋。Traceability Matrix(TM)是在測試用例覆蓋率上最好的輸出文件。TM文件包括列出了所有測試需求、相關的測試用例個數(shù)和每個測試用例的目標。每個測試需求和每個測試用例之間的關系都已經(jīng)列在TM里。當需求改變的時候，TM 也將進行更新還反應需求的變更；從而相應的測試用例也會隨著TM的更新進行修改。在信貸系統(tǒng)模塊中，我們在確定了測試的需求的基礎上，在測試用例設計中，將測試需求細分到第一個步；然后按測試用例設計流程進行設計TM。 村 鎮(zhèn)銀 行信 貸系 統(tǒng)用 例設 計 測 試用 例設 計測試用例設計，首先要設計測試用例的結構，本次設計的功能測試用例的內(nèi)容主要分為三個方面：一是被測試的軟件產(chǎn)品的相關信息；二是測試用例和人員的基本信息；三是測試過程描述及測試結果和問題描述信息，即是測試用例的結構模板中必須包括以下幾個關鍵的信息：Test Case name、Step No.、PreCondition、Objective、Step Description、Expected result、Test case designer。由于本系統(tǒng)的所有測試用例將會通過 QC上傳工具上傳到 QC 的Test Plan中，所以測試用例的模板在結合測試用例要求的基礎上，按照QC的要求進行編寫，即每列的格式按照QC的要求在Excel表格中編寫測試用例。 Q C的T es t P lan對測 試用 例的管 理在QC中，特有的功能模塊是Test Plan，該模塊是在線管理測試用例，除了可以在線查看測試用例，還允許在線修改和刪除過期的測試用例，當測試用例的修改(例如測試用名字)，這些信息的修改將會直接反應在另一個模塊 Test lab 中，可以讓測試人員在執(zhí)行測試時知道更新的測試用例。除此外，在 Test Plan 中的各個組成的項中，各個項目可以根據(jù)實現(xiàn)的要求進行選取需要的測試用例到 Test Lab 去執(zhí)行測試用例。用Test Plan 管理測試用例，不僅可以方便所有人員對測試用例的使用，還方便測試人員容易執(zhí)行并查看測試用例。當一個項目完成后，這些測試用例將可以被再次重用，可以避免測試人員流失后，測試用例會隨之流失。QC有用戶權限的管理，不同級別的人可以擁有不同權限?？梢韵拗品潜卷椖康哪承y試人員去修改或者刪除測試用例。從而保證了測試用例的完整性。為了實現(xiàn)QC對測試用例管理，首先我們要將本地已經(jīng)寫好的測試用例通過一個自帶的QC上傳工具，將已經(jīng)寫好的測試用例上傳到 QC，以便測試的執(zhí)行及測試用例的管理。由于本系統(tǒng)的所有測試用例都嚴格按照 QC 的規(guī)范進行編寫在 Excel中，我們只需求寫清楚測試用例所放的位置