文本講義成果51testingno

1、51 測試天地第二十五期：2012 年 4 月專業(yè)軟件測試軟件測試的軟件測試者的大舞臺主辦：上海博為峰軟件技術(shù)：51 測試天地編輯部主編：地址：云南北路 59 號1510 室副主編：張曉曉：200001編輯：青、波、：本期責任編輯：青傳真：投稿/意見反饋：editor主頁：目錄51 測試天地. 2目錄3刊首語4電信領(lǐng)域計費引擎自動化測試5體服務器的自動測試系統(tǒng)10使用 LoadRunner WinSocket 協(xié)議本地端口實現(xiàn)并發(fā)22ABC 項目的自動化測試方案27【淘測試專欄】質(zhì)量保障從 scrum 到開發(fā)自測36使用 Jenkins 構(gòu)建的云測試平臺39自行LoadRunner 的 soc

2、ket 協(xié)議性能測試45查找網(wǎng)絡瓶頸的55如何在 QTP Test 中調(diào)用 VBS 的類59要技術(shù)還是要業(yè)務63優(yōu)秀測試管理工具必備九大功能分析67軟件測試. 76測試工程師進階的 10 條箴言78自動化測試是一個的項目嗎？79351 測試天地第二十五期刊首語帶著淡淡的油菜花香，春天來了，51 測試天地第 25 期也如期與您見面了！4 月盛開的油菜花色彩非常豐富，田野抹上了一片翠綠、其間點點滴滴地透出了一絲絲的淡黃那是一種精力旺盛、生機勃勃的浪漫。油菜花有著頑強的生命力，花語含義是“加油”，寓意努力進取、積極向上的拼搏精神。假若把油菜花比作成為一個人，那么這個人便是一個有著一個天真浪漫的夢想，

3、并為這不停的追逐的人，他正如油菜花一樣，不是為這開放時的燦爛而驕傲，也不為這金黃色的花海而慨嘆。而懷著那顆童真的心，為這燦爛的加油。那么作為測試人的你追求的是什么？是提高測試技術(shù)還是增強業(yè)務知識？哪個更重要？敬請鎖定51 測試天地第二十五期雜志，內(nèi)容等待您的閱讀.在此，51 測試天地編輯部衷心感謝各位撰稿者的辛勤付出、各位測試精英提供的寶貴人生經(jīng)驗，同時感謝讀者朋友們的厚愛和支持，隨時登陸關(guān)注我們的網(wǎng)絡資訊。更加努力打造好這個交流平臺，帶來、更的內(nèi)容，希望51測試天地能成為每一位測試人的良師益友，為著同一個目標，努力、加油！讓我們做一株盛開的油菜花。 51 測試天地編輯部上海博為峰軟件技術(shù)二一

4、二年四月451 測試天地第二十五期電信領(lǐng)域計費引擎自動化測試作者：林摘要：計費系統(tǒng)一代代地升級變遷，測試都在重復地做著繁瑣的資費測試。歷代資費測試工具都在重復地造。計費引擎的測試經(jīng)驗能否一代代繼承下來？不僅是測試流程的積累， 全品牌的所有業(yè)務線數(shù)千個用。本文主要介紹電信領(lǐng)域，的是業(yè)務測試及測試框架的積累。代碼的測試，以往的測試工具的不適研發(fā)的計費引擎的資費自動測試工具。關(guān)鍵字：計費引擎；自動化測試；資費1、背景資費測試是計費系統(tǒng)測試關(guān)鍵的工作內(nèi)容，批價是計費引擎的功能，無論是系統(tǒng)的集成測試，還是 UAT 測試（用戶體驗測試，如撥測試）都需要覆蓋。通過資費測試可以發(fā)現(xiàn)資費配置、程序邏輯的缺陷，保

5、障計費引擎的質(zhì)量。稍微總結(jié)果了一下，資費測試的發(fā)展歷程，分為了以下幾個階段：手工測試計費引擎早期都是手工編寫所有測試用例，測試執(zhí)行，通過分析和日志來驗證測試結(jié)果。這種測試方式限制大，不僅執(zhí)行效率低，而且容易出錯， 難以完整覆蓋整個套餐上千個測試用例。另一方面，計費引擎處于研發(fā)階段時，資費測試很容易受到版本的影響。經(jīng)常要做資費回歸測試。半自動化測試首次做套餐的資費手工測試，保存用例數(shù)據(jù)，將通過的結(jié)果作為回歸測試的預期結(jié)果。下次做該套餐的回歸測試時，通過的用例數(shù)據(jù)，最后跟首次測試通過的結(jié)果對比。執(zhí)行首次測試時保存這種方法可以節(jié)省回歸測試的工作量，但是第一次測試套餐仍需要做手工測試，因此也無法做到套

6、餐的全自動化。測試僅需配置資費數(shù)據(jù)。測試工具自動完成測試用例生成、測試用例執(zhí)試結(jié)果比對等任務。551 測試天地第二十五期歷經(jīng)從興計費引擎測試的兩年的探索，設計了一套計費系統(tǒng)通用的資費測試工具。該工具基于通用性考慮，可以稍做修改后各版本的計費引擎。測試數(shù)據(jù)可以達到共享，如資費配置及用例配置。2、功能介紹2.1 功能介紹自動化資費測試工具作為一個完整的工具系統(tǒng)，在，根據(jù)資費測試的過程，分為以下各塊功能：2.2 資費簡易配置資費測試系統(tǒng)化、流資費簡易配置工具可以方便地進行全品牌套餐簡易配置、套餐資費疊加計算等功能。測試根據(jù)相應套餐的資費描述文檔，通過資費簡易配置工具生成套餐的資費字典。再根據(jù)實際的情

7、況，可以將疊加，生成套餐的資費字典。2.3 資費字典套餐的資費字典與基礎套餐繼續(xù)資費資費字典是套餐資費信息的配置文件。為測試用例生成工具提供費率信息， 計算用例的預期扣減結(jié)果。語音業(yè)務的資費字典配置比較復雜，因此，為了降低配置的難度，使用EXCEL 文件的形式保存。而其他業(yè)務的資費字典配置內(nèi)容較少，因此以文本形式保存。2.4 用例自動生成651 測試天地第二十五期測試根據(jù)測試的需要，設置資費測試工具的話單格式、用例的參數(shù)等，選擇資費字典，最后，生成資費自動化測試用例。2.5 資費測試自動調(diào)度資費自動化測試自動調(diào)度分為以下步驟：1、自動生成計費引擎輸入，如計費話單或者 DCC 報文。2、自動調(diào)試

8、執(zhí)行：（1）根據(jù)需要格式的套餐，配置訂購等參數(shù)，自動生成相關(guān)用戶資料并入庫。（2）將測試話單放入計費引擎的輸入目錄或者理。DCC 報文觸發(fā)業(yè)務處（3）根據(jù)用例的唯一標識，如 FILEID，自動獲取測試用例對應的計費引擎的輸出。（4）自動匹配2.6 分層設計結(jié)果與用例結(jié)果，給出差異。為了方便地積累資費庫、資費測試用例，將工具集設計成兩層結(jié)構(gòu)。邏輯層主要是實現(xiàn)業(yè)務測試的邏輯。文、用戶資料等。測試的實現(xiàn)細節(jié)，如引擎的輸入話單、報本層包括資費字典、資費簡易生成工具、用例自動生成工具的業(yè)務測試邏輯、自動調(diào)度工具的業(yè)務測試邏輯。實現(xiàn)層主要是實現(xiàn)引擎的測試細節(jié)，提供接口給邏輯層調(diào)用。如引擎的如何生成輸入話單

9、、調(diào)用什么工具發(fā)包、使用何種工具生成用戶資料等。本層包括：1） 用例生成工具中發(fā)包工具的用例配置、話單生成工具的用例配置、用例預期結(jié)果的字段信息等。2） 自動調(diào)度工具中所調(diào)用的造單工具（話單模生成工具）、報文模擬器（DCC報文工具）751 測試天地第二十五期3、總體處理流程注：圖例說明如下流程說明：1、測試2、測試配置資費字典。配置用戶數(shù)據(jù)，并使用引擎用戶數(shù)據(jù)到數(shù)據(jù)庫中。3、測試員操作用例生成工具，輸入資費配置字典，生成資費測試用例。并上傳到測試環(huán)境。851 測試天地第二十五期4、自動化調(diào)度工具資費測試用例，從引擎測試數(shù)據(jù)庫中用例對應的用戶，保存用戶對應的賬戶信息，如余額、累積量等。調(diào)用話單生

10、成工具或者報文工具生成并觸發(fā)引擎的輸入。5、等待引擎處理用例后，將讀出并，引擎數(shù)據(jù)庫，獲取用例執(zhí)行后賬戶信息，與測試用例的預期結(jié)果進行對比，最后輸出預期結(jié)果。4、亮點1） 提高計費引擎資費測試的效率與質(zhì)量。自動生成資費測試用例、自動執(zhí)行、自動比對，整個測試過程無需要人工參與。2） 通用性高通用性高，基于業(yè)務測試框架的理念進行設計。可適用于各種架構(gòu)計費引擎的資費測試。3） 易于積累資費用例庫可以很方便地積累資費庫。該系統(tǒng)應用于融合計費割接項目后，可以積累移動全業(yè)務的資費庫，后繼各項目的資費測試可以復用。4） 自動計算資費疊加和打折輕松地完成資費疊加的計算。降低測試的工作量，避免手工計算帶來的錯誤

11、。951 測試天地第二十五期作者簡介： 林，廣州從興電子開發(fā) 測試主管。從事軟件開發(fā)、測試等工作近 4 年。近年主要負責事計費引擎的測試管理，研究與探索計費系統(tǒng)的自動化測試。熟悉自動化測試在電信行業(yè)中的應用及推廣。目前已實現(xiàn) 省移動全品牌（ 、動感、神州行）等數(shù)百萬個資費測試用例的自動化測試。體服務器的自動測試系統(tǒng)作者：摘要：隨著網(wǎng)絡帶寬的日益增加，體應用的規(guī)模與范圍也日益擴大，如何測試評價體服務器的功能性與性能就成為一個亟待解決的問題。本文設計與實現(xiàn)了一種體服務器的自動測試系統(tǒng)。該系統(tǒng)通過輸入的測試任務，利用測試服務器與測試客戶端的兩層架構(gòu)對體服務器進試。該系統(tǒng)能夠測試幀數(shù)據(jù)的準確體服務器對

12、于 RTSP 協(xié)議的支持情況，接收和分析 RTP性，并且可以測試體服務器的性能。實驗表明，該系統(tǒng)具有良好的可用性，可以實現(xiàn)高效靈活的測試需求。1、引言目前，隨著移動增值業(yè)務的快速發(fā)展和第三代數(shù)字通信技術(shù)的實施，移動增值業(yè)務已經(jīng)不再僅僅局限于、彩信、彩鈴等窄帶業(yè)務，用戶對于在移動網(wǎng)絡環(huán)境下點播和的需求越來越迫切體技術(shù)作為在互聯(lián)網(wǎng)上實時傳輸音、如此的主要方式，成為一種在數(shù)據(jù)網(wǎng)絡上傳遞多數(shù)據(jù)的主流技術(shù)。體服務器的評估也顯體服務系統(tǒng)對于作為承載多基本業(yè)務的得由為重要。當前的體系統(tǒng)包含了多種網(wǎng)絡接入方式，多種軟件體系架構(gòu)，及多種應用場景如電視會議系統(tǒng)、網(wǎng)絡電視（IPTV）系統(tǒng)等。如何有效的測量各種系統(tǒng)所

13、提供的業(yè)務支撐能力就成為一個有待研究的問題，此類問題直接關(guān)系到各體系統(tǒng)的優(yōu)越性、實用性以及其革新意義的展現(xiàn)。并且當前的各個體系統(tǒng)都評價。不斷升級的需求，對于系統(tǒng)升級前后的兼容性、一致性也需要給出由于音頻、信號很難量化表示，目前對體服務器的測試方法一般還通過 STB （Set-Top-Box，機是通過人工“察言觀色”的方式完成，即測試頂盒） 或 Web 頁面與體服務器建立連接，由測試發(fā)起測試，并對測試結(jié)果進行，分析系統(tǒng)的工作情況。但是由人工來測試工作量將非常大，并且人工測試也很難提取服務器的各種性能響應參數(shù)，驗證檢查力度不夠，測試有效性低，不夠全面，可維護和可擴展性差，測試效果不理想。這里列舉幾

14、個常見的問題實例：1051 測試天地第二十五期1）手工測試過程中，大量的精力花在輸入數(shù)據(jù)、執(zhí)試用例，系統(tǒng)的音輸出是否正常上，無法集中精力到關(guān)鍵問題，如提高測試的有效性，編寫更好的測試用例等。2）由于采用人工的方式，所以無法對系統(tǒng)的性能指標進行量化分析。3） 測試工作中許多操作是重復性的、非智力性的和非創(chuàng)造性的，并要求準確細致地完成，對于重復性手工測試很難保證每一次測試的效率與有效性。4） 如果有大量（如幾千）的測試用例，需要在短時間內(nèi)（如 1 天）完成， 手工測試幾乎不可能做到為解決手工測試存在的問題，我們很自然的就想到了自動化測試。自動化測試的優(yōu)點有很多，如快速、可靠、可重復性、可重用性等等

15、，這些優(yōu)點使得自動化測試在要方法。體服務器測試過程中的地位不斷提高，成為評價體服務器的重本文研究的主題就是如何設計實現(xiàn)體服務器的自動化測試系統(tǒng)，達到快速量化的判定體系統(tǒng)的目的。該測試系統(tǒng)包括以：2、在體操作功能測試；體數(shù)據(jù)有效性正確性驗證； 體系統(tǒng)性能測試。體技術(shù)概述及研究現(xiàn)狀體（Streaming Media）技術(shù)出現(xiàn)之前，人們?nèi)粝霃木W(wǎng)絡上影片， 了這一必須先將影視文件到本地，然后進行。體技術(shù)的出現(xiàn)個限制，它可以讓用戶不需要將整個影音文件到用戶，而是一邊邊。所以體是指在數(shù)據(jù)網(wǎng)絡上按時間先后次序傳輸和的連續(xù)音、視頻數(shù)據(jù)流。體數(shù)據(jù)流具有 3 個特點：連續(xù)性、實時性、時序性，即其數(shù)據(jù)流具有嚴格的前

16、后時序關(guān)系。這種提供一邊一邊的服務系統(tǒng)稱為體服務系統(tǒng)。所以對于體服務系統(tǒng)的評價需要測試系統(tǒng)的數(shù)據(jù)，丟包率，比特率等指標；不僅如此為不斷提升移動環(huán)境業(yè)務的服務質(zhì)量，需要通過不斷提升服務器能力，提升終端能力，增加傳輸和編碼效率等辦法來多方面地提升整個移動體系統(tǒng)的性能。而提升系統(tǒng)性能的前提是對目前系統(tǒng)性能可以進行準確地測試和評價。目前，對體服務器的測試多關(guān)注與體服務器的性能測試。體服務器性能測試指標主要有最大并發(fā)流數(shù)目、帶寬波動、丟包率和平均響應時間等，1151 測試天地第二十五期其中最大并發(fā)流數(shù)目是關(guān)注的最多的。最大并發(fā)流數(shù)目是指體服務器能夠支持的有效的、能夠同時正常的最大用戶數(shù)目傳統(tǒng)的體性能測試

17、方法分為兩種：一種是基于現(xiàn)網(wǎng)，按照實際的用戶分布設定用戶模型進行性能測試；另外一種是采用真實客戶端進試。但在實施上述技術(shù)方案的過程會遇到上述體性能測試方法存在一些缺陷，例如基于現(xiàn)網(wǎng)實際用戶分布來設定用戶模型的測試方法對于體服務器的性能測試比較準確，但不具備擴展性，當該服務器變換使用地點或者場景時，之前測試得到的性能結(jié)果并不能適用于新場景。采用真實客戶端的測試方法對于服務能力較小的體服務器可以適用，但對于支持較大用戶數(shù)目的體服務器，要搭建并操作這么多的客戶端進試，是不可能的。另外，上述測試方法只關(guān)注體服體務器本身的性能，沒有考慮終端和體服務器的交互性能，沒有從整個系統(tǒng)提供的服務著眼來進試；所以亟

18、待發(fā)展一種通用性更好的測試工具，適用于不同的使用場景，具有廣泛的通用性。3、由于體自動化測試系統(tǒng)設計體業(yè)務是一種寬帶業(yè)務，對于網(wǎng)絡帶寬、抖動、延遲和丟包率較高的要求，因此，尤其是在業(yè)務忙碌的時段內(nèi)，客戶端在使用體服務時，可能會產(chǎn)生黑屏、馬賽克、圖像停格、聲音時斷時續(xù)等現(xiàn)象。為了解決體在時出現(xiàn)的問題，尋找影響試。體業(yè)務品質(zhì)的問題，需要對體業(yè)務進最原始最簡單的測試方法，即讓大量的測試在不同時段、不同地點點播體，并下所遇到的黑屏、馬賽克、圖像停格、聲音時斷時續(xù)等現(xiàn)象，最后將數(shù)據(jù)作匯總統(tǒng)計。該測試方法費時費力，測試必須一直仔細的盯著畫面，很容易疏忽掉一些細節(jié)，且測試數(shù)據(jù)的統(tǒng)計工作也相當繁瑣。為解決現(xiàn)有

19、測試方法對體服務器測試不方便的技術(shù)問題，本文研究并提出一種3.1體自動化的測試系統(tǒng)。體自動化測試系統(tǒng)設計框架現(xiàn)有的體服務器多數(shù)是通過支持RTSP/RTP/RTCP 協(xié)議來實現(xiàn)體服務的，所以從外部測試體服務器的功能與性能，就是測試體服務器對于RTSP/RTP/RTCP 協(xié)議的支持能力。我們通過模擬 RTSP/RTP/RTCP 協(xié)議與體服務器進行交互，從而完成對體服務器的測試任務。其中 RTSP（Real TimeStreaming Protocol，實時體協(xié)議），是用于支持體會話的協(xié)議，控1251 測試天地第二十五期制實時體會話的會話建立，暫停和關(guān)閉等操作。RTP（Real-timeTransp

20、ort Protocol，實時傳輸協(xié)議），用于傳輸音等實時多數(shù)據(jù)。RTCP（RTPControlProtocol，RTP、傳輸抖動等。協(xié)議），用于RTP 傳輸?shù)馁|(zhì)量，如丟包、從體系結(jié)構(gòu)上看，RTP/RTCP 用于具體的數(shù)據(jù)傳輸，RTSP 是會話協(xié)議，用于一個會話中的一個或多個流的傳輸。體自動測試系統(tǒng)的框架也是基于這系結(jié)構(gòu)，需要建立對于 RTP/RTCP數(shù)據(jù)的體服務器體服務器與測試，體單獨并且對于 RTSP 協(xié)議的消息交互進行與測試。按照內(nèi)容的方式，分成單播和組播服務。單播就是當客戶端向的請求，建立一個單獨的數(shù)據(jù)通道，體服務器向這個客戶端它所申請的一個數(shù)數(shù)據(jù)包拷貝。組播的方式就是服務器利用 IP

21、 組播技術(shù)個客戶端據(jù)包，多個客戶端共享同一數(shù)據(jù)包。我們的自動化測試系統(tǒng)設計框架通過客戶端的配置支持這兩種服務方式。體自動測試系統(tǒng)的整體框架如下圖所示：1351 測試天地第二十五期基于本文描述的體自動化測試系統(tǒng)設計框架，所有的測試任務都可以在測試服務器中集中部署與配置，各個測試客戶端通過與測試服務器通信獲取的測試任務并自行執(zhí)行，執(zhí)行完成后將所收集的測試數(shù)據(jù)給測試服務器，最后由測試服務器進行數(shù)據(jù)分析與匯總，形成統(tǒng)一的輸出結(jié)果。測試服務器負責測試任務的部署與配置，以及測試結(jié)果的數(shù)據(jù)分析與輸出。我們可以通過測試服務器的配置模塊完成各種測試用例的設計與配置，然后通過任務管理模塊進行任務的分發(fā)與啟動。測試

22、服務器端的數(shù)據(jù)分析模塊匯總測試客戶端收集到的各種測試數(shù)據(jù)進行分析，并生成分析報表交由輸出模塊進行輸出。測試客戶端負載具體測試任務的執(zhí)行。首先測試客戶端從測試服務器那里獲得測試任務，交由 RTSP 模塊與 RTP 模塊執(zhí)行，并且收集測試過程中測試數(shù)據(jù)， 執(zhí)行完成后將測試數(shù)據(jù)傳送給測試服務器。3.2 RTSP 消息的測試通常體終端內(nèi)含有一個體器，它通過網(wǎng)絡連接點播體等服務請求。這些服務請求對應進、快退、暫停、停止、錄制等操作功能。體服務系統(tǒng)主要是通過響應這些操作請求提供體服務，體自動化測試系統(tǒng)需要模擬這些操作，并檢查這些操作的響應來效性。體服務的有目前絕大多數(shù)體服務系統(tǒng)的部分采用的是 RTSP 協(xié)

23、議，它可以體數(shù)據(jù)在 IP 網(wǎng)絡上的，同時提供用于音頻和流的操作功能，如快進、快退、暫停、等，所以。體自動化測試系統(tǒng)需要能夠模擬RTSP 消息對體服務器進行體自動化測試系統(tǒng)通過任務管理模塊得到每個測試任務，并且通過配置模塊構(gòu)造每個測試任務的 RTSP 消息序列以及各個 RTSP 消息的詳細數(shù)據(jù)。然后按照任務的要求客戶端這些 RTSP 消息與被測的體服務器進行通信。在整個任務期間，測試系統(tǒng)可以維護當前任務的會話連接信息。具體的 RTSP 消息支持如下表所述。1451 測試天地第二十五期方法方向功能DESCRIBEC->S從服務器檢索流的描述或?qū)ο?。ANNOUNCEC->S, S->

24、;C服務器與客戶端之間進行通知。GET_PARAMETERC->S, S->C獲得流或流設置參數(shù)值。OPTIONSC->S, S->C從服務器檢索支持的方法。體自動化測試系統(tǒng)并沒有限定各種方法的具體使用場景與使用的功能，可以根據(jù)具體的測試任務以及體服務器對于 RTSP 協(xié)議的支持與擴展，通過配置模塊自行靈活定義所需的RTSP 消息。但是消息序列受到 RTSP 協(xié)議的規(guī)定， 不同的消息序列可能對應不同的響應結(jié)果。3.3 RTP 流的測試體服務器通過 RTP 協(xié)議封裝音頻和過捕獲的 RTP 流并分析這些 RTP 流來流。體自動化測試系統(tǒng)通體服務器的性能。RTP 流中封裝的是

25、體服務所需的音頻流和流，其中音都是通過特定的壓縮技術(shù)對音流進行編碼，目前流傳輸中最為重要的編標準有國際電聯(lián)的 H.261、H.263，運動靜止圖像組的 M-JPEG 和國際標準化組織運動圖像組的 MPEG 系列標準。這些標準都采用幀作為每一幅畫面的單位，為了支持多種協(xié)議的編碼格式，本文論述的體自動化測試系統(tǒng)不直接按照各種協(xié)議分析幀數(shù)據(jù)，而是對所有的協(xié)議采用統(tǒng)一的處理方法，這樣增加了測試系統(tǒng)的通用性。具體的方法，按照 PTS 建立每一幀的索引，對每一幀的數(shù)據(jù)應用 MD5 算法流中相同幀進行一次 MD5 校產(chǎn)生信息摘要；然后對接收的流與預存的驗，從而得出結(jié)論當前幀是否完全。RTP 流中另一個重要的

26、指標為丟包率，由于數(shù)據(jù)的編碼和加密后將數(shù)據(jù)壓縮到 RTP 數(shù)據(jù) 統(tǒng)計 RTP 包的個數(shù)中得到丟包率。本文論述的流中每個 RTP 包必須順序傳送來計算丟包率。體服務器需要經(jīng)過對體，所以測試系統(tǒng)無法從簡單的體自動化測試系統(tǒng)根據(jù) RTP具體的方法，根據(jù)當前 RTP 包的序號下一個 RTP 包的序號，如果 RTP包的序號不符合，則丟包加一；然后在根據(jù)新的 RTP 包的序號下一個 RTP包的序號。在數(shù)據(jù)流結(jié)束時，根據(jù)丟包數(shù)與總的 RTP 包數(shù)計算丟包率。這樣丟包率數(shù)據(jù)同時也可以反映數(shù)據(jù)傳輸?shù)膩y序問題。1551 測試天地第二十五期PAUSEC->S臨時停止流，而不服務器。PLAYC->S啟動

27、SETUP 分配流的數(shù)據(jù)。RECORDC->S啟動 SETUP 分配流的數(shù)據(jù)。SETUPC->S讓服務器給流分配，啟動 RTSP 會話。SET_PARAMETERC->S, S->C指定流或流設置參數(shù)值。TEARDOWNC->S流的，RTSP 會話停止。體自動化測試系統(tǒng)采用分級分析的策略，測試不同任務的需要，按照不同的分析級別給出不同詳細程度的測試結(jié)果分析。具體的，體自動化測試系統(tǒng)采用如下表的三層分級策略級別，即活躍級，探測級，完整級。其中完整級提供最詳細的 RTP 包分析結(jié)果，這一級對它所包含的全部幀數(shù)據(jù)進行信息分析，可用于需要對體服務器進行詳細的功能測試；探測

28、按照設定的抽樣間隔對整個 RTP 流進行抽樣檢測，可用于性能測試及穩(wěn)定性測試等需要消耗較高資源的測試任務；活躍級檢查 RTP 包的，丟包率，比特率等基本信息的分析，可用于測試等消耗很高的測試任務。完整級與探測級需要使用預先設定的體源，這樣才能比較客戶端接收到的 RTP 流中的幀數(shù)據(jù)是否完全正確。3.4 性能測試性能測試主要是測試被測的體服務器在預期用戶量或者打用戶量情況下系統(tǒng)的穩(wěn)定性、可靠性和響應時間。本測試系統(tǒng)通過逐漸增加并發(fā)流的數(shù)目的方法觀察各個性能參數(shù)的變化從而得出服務器的最大服務能力。目前本測試系統(tǒng)對于1） 最大并發(fā)流數(shù)目：2） 聚合輸出帶寬：體服務器的性能參數(shù)定義如下：體服務器可以長

29、時間支持的客戶端數(shù)目。體服務器的總的帶寬。3） 請求響應時延：從用戶發(fā)出 RTSP 點播開始到接收第一個 RTP 數(shù)據(jù)包之間的時間間隔。4） 丟包率：客戶端接收到的不連續(xù)的數(shù)據(jù)包的比率。測試系統(tǒng)通過多線程的客戶端以及可以配置多個客戶端這些靈活的方案實現(xiàn)對體服務器的測試。體自動化測試系統(tǒng)實現(xiàn)4、4.1 測試服務器的實現(xiàn)1651 測試天地第二十五期級別功能粒度活躍級檢查 RTP 包的，丟包率，比特率等基本信息基本探測級需設定采樣率；除統(tǒng)計活躍級的信息外，還需要按照采樣率分析關(guān)鍵幀的數(shù)據(jù)。較詳細完整級除統(tǒng)計活躍級的信息外，還要對所有的幀進行分析。詳細本文所述的測試服務器完成測試任務的管理與測試數(shù)據(jù)的

30、統(tǒng)計分析工作。它由主線程、調(diào)度線程、配置線程、定時線程和輸出線程組成。主線程完成其他線程的創(chuàng)建工作，然后輪詢是否有新的任務，如果監(jiān)測到新的任務，交由配置線程新任務的各種配置參數(shù)。調(diào)度線程負責將新的測試任務分配給某個測試客戶端進行執(zhí)行。定時線程會定時觸發(fā)分析線程測試客戶端送上來的測試結(jié)果進行分析。最后交由輸出線程保存測試結(jié)果的磁盤文件中。分析線程需要根據(jù)測試任務的需要根據(jù)不同的測試級別進行分析，當進行完整級的測試分析時會消耗較大的 CPU 與內(nèi)存，所以使用時間片強制使得分析線程讓出系統(tǒng)使得測試服務器可以響應外部的輸入，并且可以使用定時器使得分析線特定的時間繼續(xù)分析測試數(shù)據(jù)。測試服務器的內(nèi)部線程實

31、現(xiàn)如下圖所示4.2 測試客戶端的實現(xiàn)本文所述的對于標準的 RTP 與 RTSP 協(xié)議支持在體自動化測試系統(tǒng)的客戶端進行實現(xiàn)。客戶端采用多線程的結(jié)構(gòu)，由一個主線程完成各個線程的建立和初始化，并從服務器端獲得任務，在共享內(nèi)存中設置一個模擬過程。一個 RTSP線程讀共享內(nèi)存，發(fā)現(xiàn)有新令，則它將該命令按照 RTSP 協(xié)議的格式，經(jīng)過網(wǎng)絡到話，則 RTSP 線體服務器。若 RTSP 線程與體服務器建立起一個新的會接收到的體服務器地址寫入共享內(nèi)存。RTP 線程池中的1751 測試天地第二十五期某個線程監(jiān)測到這個新的體服務器地址，就會從這個服務器接收 RTP 數(shù)據(jù)包，并且將數(shù)據(jù)信息保存下來。當會話接收后，主

32、線送給測試服務器的數(shù)據(jù)分析模塊進行分析。測試客戶端的內(nèi)部線程實現(xiàn)如下圖所示：這個任務的測試數(shù)據(jù)發(fā)4.3 自動化測試系統(tǒng)的部署本文所述的體自動化測試系統(tǒng)，基于測試服務器與測試客戶端的實現(xiàn)，能夠支持分布式的部署。在具體部署測試時，可以根據(jù)測試的力進行靈活的部署配置。體服務器的能當測試的體服務器系統(tǒng)可以支持多臺服務器同時提供體服務，可以將測試服務器與測試客戶端部署在不同的硬件服務器，并且可以部署多個測試客戶端用于測試不同的服務器。當測試的體服務器為單服務器或者提供的并發(fā)負載能力較低時，可以將測試服務器與測試客戶端部署在同一個硬件服務器。由于單個測試客戶端就可以支持與多個體服務器建立體服務會話連接，所

33、以一般情況下，單臺測試服務器就可以支持對含有多個體服務器的體服務系統(tǒng)進試。1851 測試天地第二十五期5、體自動化測試系統(tǒng)結(jié)果為了驗證體自動化測試系統(tǒng)的有效性，本測試系統(tǒng)對 Live555體服務器的業(yè)務性能進行了測試。使用的測試環(huán)境是一臺 Linux 服務器，所有的網(wǎng)絡環(huán)境都使用局域網(wǎng)，且沒有其它網(wǎng)絡應用的干擾。體服務器的硬件配置為 DELL-PowerEdge-R710 ，8CPU， 4GRAM。操為 Linux，內(nèi)核為 linux-66 0-0.21-smp。整個測試過程中體服務器提供服務的所有數(shù)據(jù)從硬盤中，采用固定碼率方式傳輸清，2 個標清體數(shù)據(jù)。我們提供了 4 個不同碼

34、率的體文件，其中 2 個高的碼率為 2Mb/s。，的碼率為 4Mb/s，標清第一部分，我們測試測試的結(jié)果。體服務器對于 RTSP 消息的支持情況。下表顯示了1951 測試天地第二十五期方法是否支持說明DESCRIBESUPPORTOPTIONSSUPPORTANNOUNCESUPPORTSETUPSUPPORTPLAYSUPPORTPAUSESUPPORTRECORDUNSUPPORTTRARDOWNSUPPORTSET_PARAMETERSUPPORT只用于報告是否工作，沒有實際設置任何參數(shù)。GET_PARAMETERSUPPORT只用于報告是否工作，沒有實際獲取任何參數(shù)。第二部分，我們測試

35、示了測試結(jié)果。體服務器對于體數(shù)據(jù)傳輸?shù)闹С帜芰ΑＯ卤盹@第二部分，我們測試續(xù)時間為 1 小時。體服務器的性能。下表顯示了測試結(jié)果，測試的持從測試結(jié)果可以看出，體服務器支持除錄制功能外的所有功能。在系統(tǒng)充足時，系統(tǒng)可以很好的支持快進快退功能。體服務器的帶寬使用率隨著客戶端的數(shù)目呈線性增長。體服務器在客戶端數(shù)目上升到 230 時，系統(tǒng)的丟包率顯著上升的客戶端數(shù)目上升到 320 時，系統(tǒng)的丟包率已超過 2.5%，顯著影響了體服務的體驗。6、結(jié)論隨著體服務的越來越廣泛的應用，如果全面的評測這些成為一個迫切需要解決的問題。本文提出了一種自動化測試體服務系統(tǒng)，系統(tǒng)能夠根據(jù)輸入的測試任務執(zhí)試，并能夠統(tǒng)計分析測

36、定服務器的各性能指標，這在很大程度上為體服務器提供的客觀的量化依據(jù)。2051 測試天地第二十五期客戶端數(shù)目聚合輸出帶寬 Kb/s丟包率%202512150K0.2212534875K0.38222559731K0.4232585850K0.7322813085K2.6測試內(nèi)容丟包率幀的正確率1 倍速0%100%2 倍速0%100%4 倍速0%100%8 倍速0%100%32 倍速0%100%-8 倍速0%100%-32 倍速0%100%標清 1 倍速0%100%標清 2 倍速0%100%標清 4 倍速0%100%標清 8 倍速0%100%標清 32 倍速0%100%標清-8 倍速0%100%標

37、清-32 倍速0%100%目前的體自動化測試系統(tǒng)還不支持基于網(wǎng)頁形式的體服務，也不支持基于 SIP 等其它協(xié)議的動化測試系統(tǒng)，以及支持體服務器需要研究建立基于網(wǎng)頁形式的自協(xié)議。的體2151 測試天地第二十五期使用LoadRunner WinSocket 協(xié)議本地端口實現(xiàn)并發(fā)作者：摘要：本文描述了如何使用 LoadRunner 的 WinSocket 協(xié)議實現(xiàn)負載機本地端口，模擬實際項目中端等待請求報文的并發(fā)場景。：LoadRunner；WinSocket 協(xié)議；本地端口；推送正文一、項目概要2010 年中旬筆者進入某項目進行性能測試，項目使用嵌 SQL 的C 開發(fā)，服務器和客戶端之間使用 so

38、cket 傳輸報文。被測程序從功能上分為兩組，一組進行申請，一組進行。數(shù)據(jù)庫所有登錄的客戶端信息（包括申請組和組），定時輪詢所有端當前狀態(tài)，并將申請端提交上來的任務推送至某個空閑的端，同時更改該端狀態(tài)為“中”，通過后授權(quán)端將信息返回服務器，數(shù)據(jù)庫修改信息，一個完整完成。在服務器和客戶端之間，服務器不是等待客戶端的連接，而是主動推送任務。因此需要使用 LoadRunner 模擬端并發(fā)接收服務器推送的任務，同時并發(fā)將完成的任務再返回給服務器端。簡單事例圖如下：2251 測試天地第二十五期二、問題描述項目性能測試使用 LoadRunner 同時模擬申請客戶端和客戶端的并發(fā)。申請端到服務器之間屬于常見

39、的“請求-響應”模式，申請端主動發(fā)起閑的態(tài)的請求，服務器端響應請求。但端和服務器之間則正相反，各空請求后輪詢數(shù)據(jù)庫中空閑狀端本地指定端口，服務器在接收到端，并和某一空閑端指定端口建立連接，端到本機指定端口的連接后開始從服務器端接收端。信息，處理并將信息返回給服務器LoadRunner 模擬申請端并發(fā)時，線程產(chǎn)生的 Vuser 會在本機隨機開立端口，一個 Vuser 對應一個端口與服務器端進行連接。而 LoadRunner 模擬端的并發(fā)則很難處理，由于測試環(huán)境所限，不能申請多臺 Agent 或使用 IP功能，因此只能通過我們曾經(jīng)嘗試在一臺編寫或其他途徑處理。上模擬 2 個 Vuser本地同一端口

40、：lrs_create_socket("socket0","TCP","LocalHost=:5555","Backlog=50", LrsLastArg );lrs_accept_connection("socket0", "socket1");lrs_send("socket1","buf0",LrsLastArg);但使用 Controller 執(zhí)行僅有 1 個 Vuser 執(zhí)行，失敗的 Vuser log 中顯

41、示“socketAddress already in use.”：2351 測試天地第二十五期LoadRunner 不本機多線程同時同一端口。于是我們還嘗試使用循環(huán)方式獲取本地同一端口連接的請求，如果報端口占用錯誤則循環(huán)取端口上的：doi =，直至獲lrs_create_socket("socket0","TCP","LocalHost=:5555","Backlog=50",LrsLastArg );/本機端口并建立 socket 連接=while(i!=0);doi = i+1; sprint

42、f(socket,"socket%d",i);ReturnValue = lrs_accept_connection("socket0",socket);/將 socket0 的連接成不同的 socket 標識=while(ReturnValue=0);2451 測試天地第二十五期for(j=1; j<i; j+)sprintf(socket,"socket%d",j); lrs_send(socket,"buf0",LrsLastArg ); lrs_close_socket(socket);但在 Cont

43、roller 中并發(fā)執(zhí)行時會報大量的“socket Address already in use.” 錯誤，并且生成非常大的日志文件，僅有一個 Vuser 可以獲取到多個本地端口連接，Vuser 最后還會報求。接超時的錯誤。顯然這樣的結(jié)果依然不符合測試要為此我詢問過一些對 LoadRunner 原理熟悉的高人，均表示在 LoadRunner下不能實現(xiàn)多進程同一端口，可嘗試編寫一個服務器程序配合 LoadRunner對同一端口的+并發(fā)。鑒于編程能力有限，因此決定采取其他方法解決，和開發(fā)協(xié)商修改服務器端程序。三、問題解決與開發(fā)協(xié)商，將服務端應用程序的推送部分修改為推送到不同端口：根據(jù)的 ID 不同

44、，將推送到不同端口上，這樣就實現(xiàn)了在同一臺上模擬多個Vuser，不同 Vuser本地不同端口。lrs_create_socket("socket0", "TCP", "LocalHost=Param_port", "Backlog=20",LrsLastArg);/對本地端口進行參數(shù)化，端和Vuser ID 對應=i = lrs_accept_connection("socket0","socket1");lrs_receive("socket1", &q

45、uot;buf10", LrsLastArg);/ 接收數(shù)據(jù)= lrs_save_searched_string("socket1",NULL,"Param_Test1","LB=<Test1>","RB=</ Test1>",1,0,-1);lrs_save_searched_string("socket1",NULL,"Param_Test2","LB=< Test2>","RB=</ Te

46、st2>",1,0,-1);2551 測試天地第二十五期lrs_save_searched_string("socket1",NULL,"Param_Test3","LB=< Test3>","RB=</ Test3>",1,0,-1);/從真正接收到的數(shù)據(jù)而非 buffer 中保存指定字段=lrs_send("socket1","buf11" , LrsLastArg);/將上幾條語句中獲取的參數(shù)放到 buf11 中給服務器=lrs_

47、disable_socket("socket1", DISABLE_SEND_RECV);lrs_close_socket("socket1");經(jīng)過如上的器上并發(fā)接收LoadRunner修改后，可以實現(xiàn) LoadRunner 在一臺機信息，處理并返回應用服務器。但使用 lrs_accept_connection()socket 連接時會有一些延遲，速度不穩(wěn)定，同時也存在長時間得不到socket 連接的情況，需要注意 a這樣在 LoadRunner 里通過et 和 receive 的超時設置。變通方式實現(xiàn)接收任務的并發(fā)還是第一次，通過這個項目了解了 Lo

48、adRunner 中 socket 協(xié)議的幾個常用函數(shù)，并證實可以在單臺上接收服務器發(fā)過來的并發(fā)。性能測試上學無止境。2651 測試天地第二十五期作者簡介：，51testingWinRunner 版版主，ID：dionysus，目前在中國農(nóng)業(yè)測試中心工作，負責行內(nèi)業(yè)務系統(tǒng)性能測試。曾在廣聯(lián)達軟件技術(shù)擔任測試工程師，負責自動化功能測試；北京海輝軟件擔任測試組長， 負責 Adobe 公司 Connect 系列的 L10n 和 G11n 測試。ABC 項目的自動化測試方案作者：自動化測試應該如何開展呢？自動化測試方案如何撰寫呢？自動化測試難道就只能做功能自動化？自動化測試難道只能用用 QTP 之類的

49、商業(yè)工具嗎？自動化測試難道就是用用 QTP 寫點嗎？想玩自動化測試學 QTP 行嗎？如果你正在疑惑，如果你正在懷疑什么是自動化測試，如何開展自動化測試，開展自動化測試需要干那些事。那么我偷工減料后整理的這個方案，也以幫到您，也以給您提個醒。自動化測試絕不像工具廠商，描述的那個，點點按鈕，生成代碼，回放測試那樣就能滿足各種測試要求，而實際情況又是那樣的呢， 感觸是自動化測試其前期的調(diào)研工作將耗費你大半的時間，而自動化測試的與否，恰好是由這個時間決定的。雖然我這個方案是個大雜燴，而且還是開源的，但請相信工具相同之處，而決定于其實施的，在于你的思想。要知道用 White 之前，我也是不知道 Whit

50、e 的。廢話就不多說了：思想有多遠，測試就有多遠！ 一、背景ABC 項目是公司數(shù)據(jù)生產(chǎn)平臺，其穩(wěn)定性和兼容性是整個公司生產(chǎn)經(jīng)營的保證。在前期雖然已經(jīng)過了由 Loadrunner 進行的性能測試。但 Loadrunner 也只能模擬生產(chǎn)情況，而達不到真實用戶生產(chǎn)使用的情況，故采用自動化測試技術(shù)以達到完全真實模擬用戶生產(chǎn)的情況。具體目的為：1.1 為了真實模擬 ABC 項目_A 系統(tǒng)常用操作，測試 ABC 項目_A 系統(tǒng)在多個客戶端同時使用時，服務器和客戶端是否能達到性能、穩(wěn)定性要求；1.2 為了測試ABC 項目_B 系統(tǒng)在多個客戶端同時使用時，是否能達到性能、穩(wěn)定性要求；1.3 為了測試ABC

51、項目_C 系統(tǒng)在多個客戶端同時使用時，是否能達到性能、穩(wěn)定性要求；1.4 為了測試 ABC 項目在真實的 100 臺電腦功能的兼容性情況的要求； 經(jīng)過前期的需求調(diào)研和對 ABC 項目軟件功能的特點分析可知，ABC 項目由.net4.0 開發(fā)，且基于 C/S 架構(gòu)而構(gòu)造?；谏厦娴男枨罂芍?，本次自動化模擬需要簡單運行，不需要經(jīng)過類似于 QTP 的復雜安裝和環(huán)境準備。據(jù)技術(shù)調(diào)研可2751 測試天地第二十五期知，White 類庫基于 UIAutomation 技術(shù)可以實現(xiàn)驅(qū)動.Net4.0 構(gòu)造的軟件，故本次自動化的模擬將采用 White 類庫。二、執(zhí)行前提條件基本功能已通過測試，且頁面關(guān)鍵控件未發(fā)

52、現(xiàn)較大變化。如果頁面中的關(guān)鍵控件發(fā)生較大變化，需要通知我們。三、目的真實模擬 ABC 項目常用操作，測試 ABC 項目在多個客戶端同時使用時， 服務器和客戶端是否能達到性能、穩(wěn)定性要求；并且可兼顧重要基本功能的回歸測試（涉及到業(yè)務邏輯的部分，必須經(jīng)過人工測試）。且滿足以下需求：3.1 為了真實模擬 ABC 項目_A 系統(tǒng)常用操作，測試 ABC 項目_A 系統(tǒng)在多個客戶端同時使用時，服務器和客戶端是否能達到性能、穩(wěn)定性要求；3.2 為了測試ABC 項目_B 系統(tǒng)在多個客戶端同時使用時，是否能達到性能、穩(wěn)定性要求；3.3 為了測試ABC 項目_C 系統(tǒng)在多個客戶端同時使用時，是否能達到性能、穩(wěn)定性

53、要求；3.4 為了測試 ABC 項目在真實的 100 臺電腦功能的兼容性情況的要求；四、自動化測試需求1、編寫一個自動登陸 ABC 項目、執(zhí)行業(yè)務場景的自動化；2、自動化使用簡單，可在多臺不同配置的客戶端上使用；3、最好可以配置業(yè)務場景中相對的步驟是否執(zhí)行；4、最好可以驗證業(yè)務場景各個步驟執(zhí)行的結(jié)果是否正確；5、6、自動化執(zhí)行過程中，客戶端 CPU 和內(nèi)存占用情況；多機連合測試過程中，服務器端的相關(guān)的情況。7、可兼顧重要功能的回歸測試。8、滿足附件中的業(yè)務規(guī)則場景要求。五、的整體架構(gòu)1、選用的工具或類庫根據(jù)前期的調(diào)研，由于使用的用戶數(shù)比較多，用戶期望可以更傻瓜式，并且配置簡單，所以選用開源自動化工具 White 來開發(fā)。另外，該工具需要.Net3.52851 測試天地第二十五期的平臺（W