【正文】 17 圖一 事務性能摘要圖 圖二 平均 事務相應時間圖 平均事務相應時間圖描述事務在整個方案運行期間的相應時間很長。 事務性能摘要圖描述了方案執(zhí)行期間每個事 務的最短響應時間、平均相應時間和最常相應時間的摘要。使用“事務性能摘要圖，可 以確定在案中執(zhí)行期間相應時間過長的事務。還可以在窗格中拖動圖。單擊左窗格中的“＋”號以展開圖樹，請選擇“視圖” “隱蔽可用圖”，或者單擊“可用圖”列表右上角的Ｘ按鈕。“方案組”窗格下將顯示默認圖； 3)雙擊改圖，使其最大化。要啟動聯(lián)機監(jiān)視器，請執(zhí)行下列操作： 1)啟動方案。 選擇下列選項之一； Ａ同時停止所有的 Vuser；同時停止方案中的所有 Vuser； Ｂ停止 X 個：在指定時間段內(nèi)停止一定數(shù)目的 Vuser 2)單擊“確定”關閉計劃生成器并保存設置。 2)要設置方案的持續(xù)時間，請單擊“持續(xù)時間”選項卡。 1)要指示 loadrunner 在開始加載 Vuser 之前對它們進行初始化，請選中“加壓之前初始化所有的 Vuser”。 注意 ：方案運行時， 您可以在方案中田間 Vuser 組／腳本，然后啟用他們。 計劃方案 使用計劃生成器，可以同過下列方式控制方案的執(zhí)行 限制方案的持續(xù)時間－〉在方案中逐漸運行 Vuser－〉在反案中逐漸停止Vuser．要為方案設置計劃選項，請執(zhí)行下列操作： 1)選擇“按方案計劃”選項 2)要確定方案開始的方式，請單擊“加壓”選項卡。 更多論文 15 Controller 測試方案設計 方案開始時間 打開“延遲方案開始時間”對話框， 可以在其中延遲方案的開始時間。Actions 類包含三個方法： init、 Actions 和 end。要顯示波一部 分，請在左窗格中突出顯示該部分的名稱。 運行多次迭代的 Vuser 腳本時，只有腳本的 Actions 部分重復，而 Vuserinit和 Vuserend 部分將不重復，可以使用 VuGen 腳本編輯器來顯示并編輯每個腳本部分的內(nèi)容。 每個 Vuser 腳本都至少包含三部分： Vuserinit、 一個或多個 Actions 及Vuserend．錄制前和錄制期間，可以選擇腳本中 VeGen 要插入已錄制函數(shù)的部分。錄制業(yè)務流程是， VeGen 生成一個由函 數(shù)構(gòu)成的 Vuser 腳本。要驗證是否正確運行，請以單獨模式運行該腳本。然后配置運行時設置。 LoadRunner 為您提供了大量錄制 Vuser 腳本工具。相 反， CUIVuser 腳本只有一個部分，并且是用 TSL（測試腳本語言）編寫的。 Vuser 腳本的結(jié)構(gòu)和內(nèi)容因 Vuser 類型的不同而不同。例如，可以使用 WebVuser 模擬用戶操作 Web 瀏覽器、使用 Tuxedo Vuser 模擬 Tuxedo 客戶端與 Tuxedo 應用程序服務器之間的通信、使用 RTE Vuser 操作終端仿真器。 LoadRunner 提供了多種 Vuser 技術(shù)，通過 這些技術(shù)可以在使用不同類型的客戶端 /服務器體系結(jié)構(gòu)時生成 服務負載。 Vuser執(zhí)行的操作使用 Vuser 腳本描述的。 Vu Gen 腳本開發(fā) LoadRunner 可以模擬一個數(shù)千用戶同時使用客戶端 /服務器系統(tǒng)的環(huán)境。 用 LoadRunner 進行負載測試的流程通常有五個階段組成：計劃、腳本創(chuàng)建、場景定義、場景執(zhí)行和結(jié)果分析。 LoadRunner 能支持廣泛的協(xié)議和技術(shù)，功能比較強大，可以為特殊環(huán)境提供特殊的解決方案。通過模擬千萬用和實施并發(fā)負載及實行能檢測來確認和查找問題，能過對整個企業(yè)架構(gòu)進行測試。 Failed：表示測試的預期結(jié)果與是結(jié)果不一致，測試人員需要報 bug。 Blocked：表示這條測試用例被阻塞，可能是測試用例已經(jīng)過期，不適合現(xiàn)在的系統(tǒng)。 Not run:表示這條測試用例還沒有被執(zhí)行。 圖 5 說明： 人員需要在 notes 下面的框里標出測試環(huán)境（包括被測軟件的目前版本號 測試使用的機型、測試的服務器版本號、以及當前使用機型的版本號等等） 。 Test case 18999:P1發(fā)送一個有標題和內(nèi)容的郵件 Steps： (標題為：郵件 內(nèi)容：郵件 ) Expected results: （標題為：郵件 內(nèi)容：郵件） 更多論文 10 它的主要特點為： Web 方式訪問、測試計劃中的每個產(chǎn)品的測試都遵循測試流程、用戶可以自定義角色（如測試組長，測試員等等）、關鍵字的作用用于支持深層次的測試組織、測試可以根據(jù)優(yōu)先級派給測試員，提供測試報告、支持將文檔到處成 HTML ， WORD 或是 EXCEL 的格式 、可以直接通過這個工具將測試報告郵件發(fā)出 Test Link 的使用方法 testlink,進入頁面 （如圖 1） 圖 1 ，就進入了 測試用例管理界面 （如圖 2） 更多論文 11 圖 2 3 在 test run 中選擇所要執(zhí)行的項目某個階段的名字， 然后選擇 Execute test case ， 點擊進入下一步 ，進入 case 的操作界面 （如 圖 3） 。如果在實際測試過程中，得到的實際測試結(jié)果與預期結(jié)果不符，那么測試不通過；反之則測試通過。對于復雜的測試用例，測試用例的輸入需要分為幾個步驟完成，這部分內(nèi)容在操作步驟中詳細列出。測試用例的輸入對軟件需求當中的輸入有很大的依賴性，如果軟 件需求中沒有很好的定義需求的輸入，那么測試用例設計中會遇到很大的障礙。 測試輸入： 提供測試執(zhí)行中的各種輸入條件。 重要級別： 定義測試用例的優(yōu)先級別，可以籠統(tǒng)的分為 “ 高 ” 和 “ 低 ” 兩個級別。 測試標題： 對測試用例的描述，測試用例標題應該清楚表達測試用例的用途。 用例 ID： 測試用例的編號有一定的規(guī)則，比如系統(tǒng)測試用例的編號這樣定義規(guī)則： PROJECT1ST001 ，命名規(guī)則是項目名稱＋測試階段類型（系統(tǒng)測試階段）＋編號。而已有相應測試用例，則反映實施測試或變更處理存在問題。 通過收集缺陷 ，對比測試用例和缺陷數(shù)據(jù)庫，分析確證是漏測還是缺陷復現(xiàn)。以前統(tǒng)計基準是軟件模塊或功能點，顯得過于粗糙。判斷軟件測試是否完成、衡量測試質(zhì)量需要一些量化的結(jié)果。如果說軟件編程必須有設計規(guī)格說明書，那么測試腳本的設計說明書就是測試用例。 “設計規(guī)格說明書” 為提高測試效率，軟件測試已大力發(fā)展自動測試。尤其像測試報表的正確性，按章測試用例規(guī)劃準備測試數(shù)據(jù)是十分必須的。 在我們的時間中測試數(shù)據(jù)與測試用例是分離的。 更多論文 7 2 測試用例 測試用例的在測試中的 重要性 測試用例在實施測試時測試用例作為測試的標準，測試人員一定要按照測試用例嚴格按用例項目和測試步驟逐一 實施 測試。 更多論文 6 對于問題三：對于傳統(tǒng)的手工測試，目前有很多公司研發(fā)了先進的測試工具 ，目前最被廣泛使用的大多是 mecursy 公司的產(chǎn)品 ， 本文 針對目前流行的性能測試工具 loadrunner 作出詳 細的介紹以及使用說明 以及結(jié)果的分析 。 本文不一一的對這些問題提出解決方案，只是針將對軟件測試中 比較關鍵的 問題，如 問題一、問題三、以及問題五提出解決方法 。 軟件測試在 軟件開發(fā)過程中起著關鍵 的作用， 也 是提高軟件產(chǎn)品的質(zhì)量的 重要途徑。對于成千上萬個測試用例的管理、對測試中產(chǎn)生的缺陷的跟蹤的工作量是非常巨大。在測試的過程中往往缺乏計劃性，使得軟件在測試過程中未能得到充分的檢查，這也直接影響了軟件的質(zhì)量。從整體認識上就輕視測試的工作。 問題四：對測試的要求不夠嚴格 很多人都認為軟件測試就是安裝運行程序。 問題三： 缺少測試工具 手工測試過多 傳統(tǒng)的測試大多還是以手工為主，測試人員根據(jù)需求規(guī)格說明書與測試對象進行比對。而當這些潛在的問題出現(xiàn)時往往是在最后綜合測試階段。在實際開發(fā)的項目的過程中，考慮到開發(fā)人員對軟件本身的了解以及節(jié)省項目開發(fā)時間，單元測試基本上都是由開發(fā)人員自行測試。 問題二：單元測試階段常常采用開發(fā)人員自行測試方法 單元測試是對軟件基本組成單元的測試。 軟件測試中的普遍問題 及解決方案 問題一： 測試用例、方案的利用率低 軟件測試是通過有效的測試用例來對軟件進行反復的檢查和測試的。驗收測試的目的是要對軟件產(chǎn)品在目標用戶的工作環(huán)境中作進一步的矯正，確保軟件準備就緒。通常情況下，三方面有效并且 合理的結(jié)合可以達到對系統(tǒng)全面性能的分析和 瓶頸的預測。性能測試在軟件的質(zhì)量保證中起著重要的作用，它包括 的測試內(nèi)容豐富多樣。按照系統(tǒng)測試用例逐個設施，記錄測試結(jié)果。從而提出更加完善的方案。 系統(tǒng)測試。同樣，可能需要測試人員開發(fā)少量的驅(qū)動模塊來驅(qū)動被測子系統(tǒng)。 步驟三：將各個軟件模塊成為子系統(tǒng)（或分系統(tǒng)）。這里，可能需要測試人員開發(fā)一些驅(qū)動模塊來驅(qū)動集成活動中形成的被測模塊。在熟悉被測模塊性質(zhì)的基礎之上對被測模塊進行分層，然后排出測試活動的先后關系，更多論文 4 制定測試進度計劃。 集成測試過程：制定集成測試計劃，設計集成測試，實施集成測試，執(zhí)行集成測試以及評估集成測試。實踐表明，一些模塊能都單獨的工作，當并不能保證連起來也能正常工作。集成測試，也叫組裝測試或聯(lián)合測試。執(zhí)行單元測試，就是為了證明這段代碼的行為和我們期望的一致。 單元測試。 當所有的 軟件產(chǎn)品完成，系統(tǒng)測試是保證整個系統(tǒng)符合用戶需求。測試人員可以根據(jù)先前的策劃斯計劃和測試用例逐個實施測試。而且測試用例設計要考慮一下幾點：覆蓋率（要達到最大 的覆蓋軟件系統(tǒng)功能的功能點）、數(shù)量（一個多于半年的開發(fā)周期，用例 不得低于 4000）、使用管理工具軟件。正確的劃分子系統(tǒng)可以降低測試的復雜性，減少重復與冗余，更加方便設計測試用例。 更多論文 3 開發(fā)階段 當我們在計劃測試時， 需要將整個系統(tǒng)分解。整個階段的開發(fā)文檔包括概要