【正文】 This paper start at the process of software testing , Give suggestion about critical software testing as test case、 excute testing 、 and bug. Test case: talking about the Standards and norms of test case .and how to use case tools Excese case: talking about how to use loadrunner ,and the method analyse the test results Bug: talking abour the Standards and norms of how to use teamtrack manage bug Key Words: Test case 、 testlink 、 loadrunner、 bug 、 teamtracker、 the management of bug 更多論文 1 1 導(dǎo)言 軟件測(cè)試的起源與發(fā)展 軟件測(cè)試的概念雖然是和軟件編程同時(shí)提出的，但發(fā)展速度卻遠(yuǎn) 遠(yuǎn)沒有編程技術(shù)快。整個(gè)項(xiàng)目對(duì)測(cè)試工作的規(guī)劃少、投資少，測(cè)試介入晚，常常是在形成代碼后，產(chǎn)品已經(jīng)基本完成時(shí)才進(jìn)行測(cè)試。但是對(duì)軟件測(cè)試目的的理解限于 “使自己確信產(chǎn)品能工作”。當(dāng)時(shí)也缺乏有效的測(cè)試方法，主要依靠“錯(cuò)誤推測(cè)（ Error Guessing）”來尋找軟件中的缺陷。 到了 20 世紀(jì) 70 年代，這個(gè)階段開發(fā)的軟件仍然不復(fù)雜，但人們已開始思考軟件開發(fā)流程的問題。 第三階段：軟件測(cè)試就是“找到軟件存在的缺陷” 以 Glenford (代表論著《 The art of Software Testing》 )為代表的部分業(yè)界權(quán)威對(duì)上述方法提出質(zhì)疑。 1979 年提出了他對(duì)軟件測(cè)試的定義：“測(cè)試是維發(fā)現(xiàn)錯(cuò)誤而執(zhí)行一個(gè)程序或者系統(tǒng)的過程”。人們將“質(zhì)量”的概念融入其中，軟件測(cè)試不再 單更多論文 2 純是一個(gè)發(fā)現(xiàn)錯(cuò)誤的過程，而且將測(cè)試作為軟件質(zhì)量保證（ SQA）的主要功能，包括軟件質(zhì)來能夠評(píng)價(jià)的內(nèi)容。 綜上所述，把軟件測(cè)試定義為：軟件測(cè)試是貫穿整個(gè)軟件開發(fā)生命周期， 對(duì)軟件產(chǎn)品（包括階段性產(chǎn)品）進(jìn)行驗(yàn)證和確認(rèn)的活動(dòng)過程，其目的是盡快地發(fā)現(xiàn)在軟件產(chǎn)品中所存在的各種問題與用戶需求、預(yù)先定義的不一致性。在軟件生命周期的需求分析階段，測(cè)試人 員參與需求調(diào)研。這也有助于更好的理解系統(tǒng)的需求。這部分的工作有助于設(shè)計(jì)測(cè)試計(jì)劃。當(dāng)系統(tǒng)分析員完成了需求分析，他將提交需求規(guī)格說明書。檢查文檔是否覆蓋了所有需求。 分析設(shè)計(jì)階段 測(cè)試計(jì)劃。在測(cè)試過程中有三種類型的測(cè) 試接話：系統(tǒng)測(cè)試計(jì)劃，集成測(cè)試計(jì)劃以及單元測(cè)試計(jì)劃。一般的計(jì)劃包含以下幾點(diǎn)：測(cè)試怎樣被發(fā)現(xiàn)、誰來做、測(cè)試什么、測(cè)試要花費(fèi)多長時(shí)間、測(cè)試覆蓋率是怎樣的。在系統(tǒng)實(shí)際階段，測(cè)試人員要理解系統(tǒng)是怎樣被實(shí)現(xiàn)的。如果不合理，問題在哪里，怎樣改進(jìn)等等。對(duì)一個(gè)復(fù)雜的系 統(tǒng)來說，他可以被分解成一些相對(duì)獨(dú)立的子系統(tǒng)。實(shí)際測(cè)試用例是一項(xiàng)非常細(xì)致的工作。 測(cè)試執(zhí)行階段 當(dāng)以上的準(zhǔn)備工作完成，系統(tǒng)開發(fā)也進(jìn)入到了尾期。每一個(gè)獨(dú)立的軟件部分要接受單元測(cè)試，若干個(gè)部分組合起來接受 集成 測(cè)試。當(dāng)然， 功能測(cè)試也是必不可少的，保證軟件的各個(gè)部分滿足需求的功能標(biāo)準(zhǔn)。單元測(cè)試一般都由程序員自己完成，可以這么說，程序員有責(zé)任編寫功能代碼，同時(shí)也有責(zé)任為自己的代碼編寫單元測(cè)試。經(jīng)常與單元測(cè)試聯(lián)系起來的另外一些開發(fā)活動(dòng)包括代碼走讀（ Code review），靜態(tài)分析（ Static analysis）和動(dòng)態(tài)分析（ Dynamic analysis） 集成測(cè)試。在 單元測(cè)試的基礎(chǔ)上，將所有模塊按照設(shè)計(jì)要求組裝為子系統(tǒng)或系統(tǒng)，進(jìn)行集成測(cè)試。程序在某些局部反應(yīng)不出來的問題，在全局上很可能暴露出來，影響功能的實(shí)現(xiàn)。以常用的自底向上的方法的集成方案為例： 步驟一：按照概要設(shè)計(jì)規(guī)格說 明，明確有 那些被測(cè)模塊。 步驟二：在步驟一的基礎(chǔ) 上，按時(shí)間線序關(guān)系，將軟件單元集成為模塊，并測(cè)試在集成過程中出現(xiàn)的問題。對(duì)于比較大的模塊，可以先將其中的 個(gè)個(gè) 軟件單元集成為子模塊，然后再集成為一個(gè)較大的模塊。檢查各自子系統(tǒng)是否能正常 工作 。 步驟四：將各個(gè) 系統(tǒng)集成為最終用戶系統(tǒng)， 測(cè)試 是否存在分系統(tǒng)能夠在最終用戶系統(tǒng)中 常工作。系統(tǒng)測(cè)試時(shí)將已經(jīng)確認(rèn)的軟件 產(chǎn)品、計(jì)算機(jī)硬件、外設(shè)、網(wǎng)絡(luò)等其它元素結(jié)合在一起，系統(tǒng)的各種安裝測(cè)試、功能策劃 、 確認(rèn)測(cè)試等結(jié)合的綜合測(cè)試，其目的是通過與系統(tǒng)的需求相比較，發(fā)現(xiàn)出 開發(fā)的系統(tǒng)與用戶需求不符或矛盾的地方。系統(tǒng)測(cè)試多用黑盒測(cè)試的方法。 性能測(cè)試 。中國軟件測(cè)試中心將性能測(cè)試概括為三個(gè)方面：應(yīng)用在客戶端性能的測(cè)試、應(yīng)用在網(wǎng)絡(luò) 上性能的測(cè)試和應(yīng)用在服務(wù)器段性能的測(cè)試。 驗(yàn)收測(cè)試。并且可以讓最終用戶將其用于執(zhí)行軟件的既定功能和任務(wù)。在測(cè)試過程中，由于對(duì)測(cè)試階段的人員沒有統(tǒng)一的管理測(cè)試用例、測(cè)試程序和方案沒有進(jìn)行相關(guān)的整理和有效的保存，當(dāng)后期發(fā)現(xiàn)問題進(jìn)行回歸測(cè)試時(shí)相關(guān)測(cè)試用例資更多論文 5 料往往無處可尋了，這就給回歸測(cè)試帶來了很大的問題，也會(huì)延誤軟件項(xiàng)目的 實(shí)際的開發(fā)進(jìn)度。也就是對(duì)軟件模塊的測(cè)試。這樣做的結(jié)果是在單元測(cè)試的過程中很難發(fā)現(xiàn)潛在的問題。這樣就增加了解決問題的難度，影響了軟件開發(fā)的進(jìn)度。而 且測(cè)試過程中的手工成本高、測(cè)試人員的隨意性、缺乏測(cè)試相關(guān)知識(shí)、人工操作的低效率、誤差大等因素都會(huì)直接影響到測(cè)試的結(jié)果與軟件的質(zhì) 量 。包括在一些開發(fā)機(jī)構(gòu)中，也存在測(cè)試人員“沒有技術(shù)含量”的偏見。在實(shí)際軟件中，對(duì)測(cè)試人員沒有進(jìn)行相關(guān)的培訓(xùn)，測(cè)試人員都缺乏一些相關(guān)的知識(shí)，缺乏對(duì)項(xiàng)目的構(gòu)架的了解。 問題五：測(cè)試缺陷管理效率低 大部分測(cè)試缺陷僅依賴人工處理，對(duì)軟件測(cè)試的管理是很麻煩的問題，甚至可以說是不能實(shí)現(xiàn)的。在這種狀況下，軟件測(cè)試的效率很低，會(huì)影響到整個(gè)開發(fā)的過程及進(jìn)度，而且也會(huì)贈(zèng)加整個(gè)開發(fā)的成本。所以軟件測(cè)試的問題也是必須要解決的問題。 對(duì)于問題一： 測(cè)試用例的書寫 標(biāo)準(zhǔn)能讓測(cè)試者統(tǒng)一而且清楚的管理測(cè)試用例，而 測(cè)試用例的管理工具不僅能有效的提高測(cè)試效率，而且對(duì)測(cè)試用例及相關(guān)文檔進(jìn)行保存 ，對(duì)以后的回歸測(cè)試提供良好的條件。 對(duì)于問題五：缺陷的管理工具能夠提高 bug 的管理和跟蹤效率，在開發(fā)的整個(gè)過程中減少成本，統(tǒng)一的缺陷標(biāo)準(zhǔn)保證了缺陷管理工作的有序進(jìn)行。并對(duì)測(cè)試情況記錄在測(cè)試用例管理軟件中，以便自動(dòng)生成測(cè)試結(jié)果文檔。按照測(cè)試用例配套準(zhǔn)備一組或若干組原始數(shù)據(jù)，以及標(biāo)準(zhǔn)測(cè)試結(jié)果。 另外，出正常數(shù)據(jù)外，還必須根據(jù)測(cè)試用例設(shè)計(jì)大量邊緣數(shù)據(jù)和錯(cuò) 誤數(shù)據(jù)。自動(dòng)測(cè)試的中心是編寫測(cè)試腳本。 成測(cè)試施設(shè)后需要對(duì)測(cè)試結(jié)果進(jìn)行評(píng)估， 并且編制測(cè)試報(bào)告。例：測(cè)試覆蓋率是多少、測(cè)試合格率是多少、重要測(cè)試合格率是多少，等等。采用測(cè)試用例做度量準(zhǔn)則更加準(zhǔn)確、有效。漏測(cè)反映了測(cè)試用例的覆蓋率不夠，應(yīng)立即補(bǔ)充相應(yīng)測(cè)試用例，最終達(dá)到逐步完善軟件質(zhì)量。 更多論文 8 試用例書寫規(guī)范 軟件測(cè)試用例的基本要素包括 ： 測(cè)試用例 ID、測(cè)試標(biāo)題、重要級(jí)別、測(cè)試輸入、操作步驟、預(yù)期結(jié)果 。定義測(cè)試用例編號(hào)，便于查找 測(cè)試用例，便于測(cè)試用例的跟蹤。比如 “ 測(cè)試用戶登錄時(shí)輸入錯(cuò)誤密碼時(shí)，軟件的響應(yīng)情況 ” 。一般來說，如果軟件需求的優(yōu)先級(jí)為 “ 高 ” ，那么針對(duì)該需求的測(cè)試用例優(yōu)先級(jí)也為 “ 高 ” ；反之亦然 。根據(jù)需求中的輸入條件，確定測(cè)試用例的輸入。 操作步驟： 提供測(cè)試執(zhí)行過程的步驟。 預(yù)期結(jié)果： 提供測(cè)試執(zhí)行的預(yù)期結(jié)果，預(yù)期結(jié)果應(yīng)該根據(jù)軟件需求中的輸出得出。 比如下面一個(gè)簡單的 測(cè)郵箱功能的 測(cè)試用例： 更多論文 9 測(cè)試用例的管理工具 Test link 介紹 TestLink 可以 管理整個(gè)測(cè)試過程， 它能夠動(dòng)態(tài)的收集和組織測(cè)試用例、跟蹤執(zhí)行后的測(cè)試結(jié)果、跟蹤獨(dú)立測(cè)試的準(zhǔn)確信息、獲取并詳細(xì)的報(bào)告測(cè)試結(jié)果、幫助用戶更好的管理整個(gè)測(cè)試 過程、自定義 TestLink 以適應(yīng)你的需求和測(cè)試過程。 圖 3 更多論文 12 case 的管理界面， 圖 5 是樹形結(jié)果的測(cè)試用例，右邊具體顯示某條測(cè)試用例的內(nèi)容，以及執(zhí)行的測(cè)試結(jié)果。當(dāng)這條測(cè)試用例執(zhí)行完以后需要在 result 下面 的 四個(gè)選項(xiàng)（ not run、 pass、blocked、 failed）選出 相應(yīng)的結(jié)果。 Pass：表示測(cè)試用例通過，即測(cè)試期望的結(jié)果與實(shí)際的結(jié)果一致。也可能是此條測(cè)試用例的功能當(dāng)前版本還沒實(shí)現(xiàn)。 此外如果這條測(cè)試用例是 Failed，需要在 TeamTrack issue Number 后面寫出 bug 的 ID 更多論文 13 3 Loadrunner 使用方法 LoadRunner 介紹 LoadRunner 是一種預(yù)測(cè)系統(tǒng)行為和性能的負(fù)載測(cè)試工具。通過使用 LoadRunner,企業(yè)能夠最大限度的縮短測(cè)試時(shí)間，優(yōu)化性能和加速應(yīng)用系統(tǒng)的發(fā)布周期。 LoadRunner 有下面三部分組成Virtual User Cenerator 用來錄制腳本、編輯腳本 ： controller 用來布置測(cè)試場(chǎng)景； Analysis 用來對(duì)測(cè)試結(jié)果進(jìn)行分析。 1） 計(jì)劃負(fù)載測(cè)試：定義性能測(cè)試要求，例如并發(fā)用戶數(shù)量、業(yè)務(wù)流程和所需相應(yīng)時(shí)間； 2） 創(chuàng)建 Vuser 腳本：將最終用戶活動(dòng)捕捉到自動(dòng)腳本中； 3） 定義場(chǎng)景：使用 LoadRunner Controller 設(shè)置測(cè)試環(huán)境； 4） 運(yùn)行場(chǎng)景：通過 LoadRunner Controller 驅(qū)動(dòng)、管理測(cè)試； 5） 監(jiān)視場(chǎng)景：通過 LoadRunner Controller 監(jiān)控測(cè)試； 6） 分析結(jié)果：使用 LoadRunner Analysis 創(chuàng)建圖和報(bào)告并評(píng)估性嫩。為執(zhí)行此操作， LoadRunner 用“虛擬用戶（ Vuser）”代替實(shí)際用戶。 LoadRunner 提供各種幫助來開發(fā) Vuser腳本的工具。每種 Vuser 技術(shù)都適合于特定體系結(jié)更多論文