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