随笔 - 30, 评论 - 266, 引用 - 2 |
|||
导航关于标签每月存档
最新留言
广告 |
2008年02月13日 常有人問我有沒有專門在講效能測試的書，就是這一本了！！
Performance Testing Guidance for Web Applications from MSDN. Download the Performance Testing Guidance for Web Applications Guide 微軟全球技術支援中心 – 邱英瑞 – Jacky Chiou：有一些VS2008, VS2005 Team Test 的使用與功能介紹 posted on 2008-02-13 17:37:00 by oldsidney 评论(2) 阅读(4043) 2006年11月18日 看看 Mercury 自動化功能測試已經發展到什麼程度。 傳統自動化測試的限制 軟體的自動化測試在過去一段時間中有長足的進步。每個世代的產品都成功解決了某些重要的挑戰，但是同時也引進了不同的問題等待解決。 第一代的自動化測試大概在15年前開始，透過硬體的方式錄製鍵盤的輸入並播放，但缺少檢查點（checkpoint）的功能，而且測試腳本很難維護。 第二代的自動化測試則大約在10年前開始的，這時已經由硬體轉變成透過軟體錄製/播放（capture/playback）的方式產生測試腳本（script），並且也增加了檢查點的功能，可以對軟體做驗證，測試的範圍也比硬體方式的自動化方式大了許多。比較大的問題是測試腳本也是一種程式語言，所以測試人員也需要懂程式語言，換句話說就是要會寫程式。而且當軟體有變動時，測試腳本也需要同步更新，這對測試人員來說是一大挑戰，測試人員常常就是整個測試腳本再重新錄製一遍。
在2001年開始了第三代的自動化測試稱為「測試框架（test framework）」，主要是把測試腳本給抽象化（abstraction）（註：如Keyword-Driven Test），讓非技術人員（如系統分析師、使用者等）即使不懂測試腳本，不會寫程式的情況下，也可以使用自動化測試工具建立自動化測試個案。 posted on 2006-11-18 15:33:00 by oldsidney 评论(9) 阅读(6115) Mercury 在 Quality Center 8.0 時就推出 Business Process Testing，到現在已經進步到 9.0 的版本了。會什麼 Mercury 發展出 Business Process Testing 呢？Business Process Testing 的好處在哪？要如何使用Business Process Testing？我將在以下的文章為大家做個介紹。 傳統UI自動化測試的限制 軟體的自動化測試在過去一段時間中有長足的進步。每個世代的產品都成功解決了某些重要的挑戰，但是同時也引進了不同的問題等待解決。 第一代的自動化測試大概在15年前開始，透過硬體的方式錄製鍵盤的輸入並播放，但缺少檢查點（checkpoint）的功能，而且測試腳本很難維護。 第二代的自動化測試則大約在10年前開始的，這時已經由硬體轉變成透過軟體錄製/播放（capture/playback）的方式產生測試腳本（script），並且也增加了檢查點的功能，可以對軟體做驗證，測試的範圍也比硬體方式的自動化方式大了許多。比較大的問題是測試腳本也是一種程式語言，所以測試人員也需要懂程式語言，換句話說就是要會寫程式。而且當軟體有變動時，測試腳本也需要同步更新，這對測試人員來說是一大挑戰，測試人員常常就是整個測試腳本再重新錄製一遍。 以下為Mercury WinRunner測試腳本的範例
在2001年開始了第三代的自動化測試稱為「測試框架（test framework）」，主要是把測試腳本給抽象化（abstraction）（註：如Keyword-Driven Test），讓非技術人員（如系統分析師、使用者等）即使不懂測試腳本，不會寫程式的情況下，也可以使用自動化測試工具建立自動化測試個案。 舉個 Mercury QuickTest Professional Keyword-Driven Test的測試腳本為例子，測試人員不管是錄製、編輯或是看到的測試腳本都是以「click the “OK” button」這樣的關鍵字所呈現的。
「測試框架」確實是增加了測試團隊的生產力，但是還是有些缺點： n 以Keyword方式建立的測試腳本還是在測試步驟的層次，當設計一個複雜的商業流程測試個案可能還是需要大量的Keyword。對測試人員而言還是需要耗費大量的時間。 n 「測試框架」對於測試人員而言，只是測試腳本長得不再像是程式原始碼，而像是在Excel中填入Keyword罷了，其實還是在寫測試腳本。 n 支援「測試框架」的自動化測試工具通常與之前的測試工具做法不同，例如不提供錄製的功能，而限制了其彈性。再者，測試人員在使用這類工具時也常常不知其所以然，在不瞭解內部的運作下，很難對Keyword做客製化。 n 「測試框架」即使已經被抽象化了，但是其層次還是停留在「步驟」的層次，尚未提升到「業務流程」的層次，迫使測試人員在建立測試腳本時，還是需要以「程式人員」的思考方式建立測試腳本，而不是以「業務人員」的角度來建立測試腳本。 n 「測試框架」的測試腳本沒有與測試文件建立關聯性，測試人員還是需要花費大量的工時在建立與維護測試文件的工作上。 從上面的問題，可以看出「測試框架」這樣的方式，對於具備技術背景的測試人員也許還 OK，但是對沒有技術背景的測試人員如（業務人員或是使用者），還是有其使用上的困難。 Mercury Business Process Testing – 是一種轉變而非一種新技術 Mercury很快地意識到這些挑戰，並非只有單單改進第三代自動化測試工具就能解決，需要的是一個全新的方式。所以從測試腳本的設計、自動化、維護以及文件化做一個全面且根本的進化，進而發展出第四代的自動化測試工具「Mercury Business Process Testing」 。 相較於Keyword-Driven Testing，Business Process Testing的抽象化層次更高，到達了「業務流程」的層次。 以下的例子可以看出一個有登入動作的測試個案，使用Keyword-Driven Testing的方式，至少需要4個步驟：開啟應用程式登入視窗、輸入帳號、輸入密碼、按下OK按鈕來完成登入的動作。但是以Business Process Testing的方式，登入的動作就成為一個可以接受以帳號、密碼為參數而且可以重複使用的業務流程元件。
Business Process Testing的優點 使用Business Process Testing的自動化測試主要有以下的優點： n 透過非技術性、元件化、以業務流程層次的方式設計測試個案，讓業務人員以及一般使用者也可以參與自動化測試的工作。 n 業務元件可以被不同的測試個案所使用，加快建立自動化測試腳本的時間，並降低維護的成本。 n 建立或維護測試腳本時也會同時更新測試個案文件，大大縮短維護測試文件的時間。 如何Mercury Business Process Testing Business Process Testing需要Mercury Quality Center與QuickTest Professional配合才能運作。同時測試團隊中也需要二種角色，一是熟悉QuickTest Professional測試工具的人員（Automation Engineer），負責建立並維護Application Area、物件庫（object repository）、library files、recovery scenarios，另外也需要負責對Business Component進行除錯的工作；另一是非常熟悉業務流程的人員（Subject Matter Expert），透過Quality Center介面，設計Business Component以及Business Process Test並運用Application Area將其自動化。 使用Business Process Test的流程如下：
建立Business Component 首先建立一個名為Login的Business Component，並且填入相關資訊，如Summary、Pre-Condition、Post-Condition，讓想要使用此Business Component的人員知道其目的、用途以及使用條件與限制。
輸入測試步驟 點選上方的Design Steps，開始輸入測試步驟，含Step Name、Description、Expected Result。
點選New Step將其餘的測試步驟也一併輸入，最後可以看到此Busniess Component的執行步驟如下。
建立Business Process Test 點選Mercury Quality Center的Test Plan，建立一個名為「預定機位」的Business Process Test。
輸入此測試個案的描述。
將Business Component加入Business Process Test中 在Test Script點選Select Component，將剛剛建立的Busniess Component依序以滑鼠拖拉到中間的區塊。此Business Process Test由Login、Create Order、Update Order、Logout 4個Business Component所組成。
將Business Component自動化 再回到Business Components將其轉成自動化測試腳本，在Design Steps點選QuickTest Keyword-Driven，將此Business Components轉成QuickTest Keyword-Driven類型的測試腳本。Business Components支援三種類型的腳本：QuickTest Keyword-Driven、QuickTest Scripted、WinRunner。
轉成QuickTest Keyword-Driven腳本後，點選Automation就可以看到其Keyword-Driven的腳本，目前都還是ManualStep。
選擇Application Area。這個Application Area內含測試物件（Test Object）、Keyword steps、函式庫等等。
將Keyword-Driven步驟加入Business Component中 直接在Keyword View上透過選取Item、Operation、輸入Value的方式建立Keyword-Driven腳本。 第一個步驟為執行Flight Reservation程式，在Item欄位就不是選取Test Object，而是選取Operation，然後在Operation欄位選擇OpenApp表示此步驟是要執行一個程式，同時在Value欄位輸入這個程式的路徑，這樣第一個步驟就完成了。 在Item選取Login Diaglog的Test Object，然後在Operation選取Activate，表示此步驟為開啟登入視窗，Value欄位則不需要輸入任何值。
選取AgentName的EditBox，Operation則是Set，表示要在Agent Name這個EditBox輸入資料，至於要輸入什麼資料就直接輸入在Value欄位中。
在Value欄位輸入mercury。
以相同的方式加入其他的步驟，完成後整個Business Component的執行腳本如下。
也同步更新了Business Component的Design Steps（可惜不是中文）。
連登入視窗的畫面也加進去方便要使用Busniess Component的測試人員更容易瞭解此元件的操作畫面。
到此這個Login的Business Component已經完成，而且可以被其他的Business Process Test使用了。 Business Component除錯 當完成Business Component的自動畫腳本後，通常會試著執行看看此Business Component是否可以順利執行，假如執行有任何問題則可以進行除錯，看看是不是Test Object選錯了還是Value值給錯了。
參數化 由於Business Component可以被其他的Business Process Test重複使用，所以通常也會將輸入資料設定為參數的方式來輸入。例如Login可以設定其接受帳號與密碼二個參數，而且在使用時，可以輸入多組的帳號密碼，然後當執行不同的Iteration時就會使用不同的帳號密碼作登入的動作。以下畫面在設定Login Component在此Business Process Test所使用的帳號密碼參數值。
在Test Script的Input出現了剛剛輸入的參數值。
執行Business Process Test 最後就可以執行Business Process Test並且檢視測試結果了。
以上是Mercury Business Process Testing的使用方法。 參考文件 n Mercury White Paper：Mercury Business Process Testing：Test Automation Focused on Your Business n Mercury Business Process Testing Tutorial n Mercury Business Process Testing User's Guide posted on 2006-11-18 15:23:00 by oldsidney 评论(2) 阅读(3451) 2006年07月28日 假如你同時使用微軟的 Visual Studio 2005 開發軟體以及 Mercury Quality Center 管理 defect，那就可以在 Mercury Quality Center Add-in page 下載這個 add-in。安裝之後就可以直接在 Visual Studio 2005 IDE 中直接處理 Quality Center 上的 Defect，不需要再另外開瀏覽器了！！
posted on 2006-07-28 00:09:00 by oldsidney 评论(9) 阅读(7565) 2005年05月19日 ViewState 是 ASP.NET 用來存放網頁上伺服器端控制項 (server control) 狀態的一個隱藏欄位，所以當你檢視你的 ASP.NET 網頁原始檔，會發現一個 "__VIEWSTATE" 的隱藏欄位，其值是一堆看不懂的字元，就如同下列的例子。
當使用 LoadRunner VuGen 錄製含有 ViewState 的 ASP.NET網站應用時，就會需要做關聯 (Correlation)。 其關聯的範例腳本如下：
假如 ASP.NET 網頁上的控制項一多，ViewState 會變得很大，所以通常也會需要使用 web_set_max_html_param_len 函數將參數 (Parameter) 的長度給適度地放大：
其他關於 ViewState 的參考資料：ViewState: All You Wanted to Know posted on 2005-05-19 00:25:00 by oldsidney 评论(3) 阅读(4935) 2005年01月06日 有人提到不清楚什麼是 LoadRunner？LoadRunner 是一套做效能測試的工具，比較詳細的說明可以參考下面這篇白皮書： 類似的工具有：
假如你想更了解 LoadRunner 的話，可以從 LoadRunner Tutorial 開始：
posted on 2005-01-06 16:45:00 by oldsidney 评论(5) 阅读(18926) 2004年12月28日 當錄製腳本時，VuGen會攔截client端（瀏覽器）與server端（網站伺服器）之間的對話，並且通通記錄下來，產生腳本。在VuGen的Recording Log中，您可以找到瀏覽器與伺服器之間所有的對話，包含通訊內容、日期、時間、瀏覽器的請求、伺服器的回應內容等等。腳本和Recording Log最大的差別在於，腳本只記錄了client端要對server端所說的話，而Recording Log則是完整紀錄二者的對話。
當執行腳本時，您可以把VuGen想像成是一個演員，它偽裝成瀏覽器，然後根據腳本，把當初真的瀏覽器所說過的話，再對網站伺服器重新說一遍，VuGen企圖騙過服務器，讓服務器以為它就是當初的瀏覽器，然後把網站內容傳送給VuGen。 所以紀錄在腳本中要跟伺服器所說的話，完全與當初錄製時所說的一樣，是寫死的（hard-coded）。這樣的作法在遇到有些比較聰明的伺服器時，還是會失效。這時就需要透過「關聯（correlation）」的做法來讓VuGen可以再次成功地騙過伺服器。 如何在 LoadRunner 腳本中做關聯 (Correlation): Part1 如何在 LoadRunner 腳本中做關聯 (Correlation): Part2 如何在 LoadRunner 腳本中做關聯 (Correlation): Part3 如何在 LoadRunner 腳本中做關聯 (Correlation): Part4 posted on 2004-12-28 18:06:00 by oldsidney 评论(4) 阅读(5202) 2004年11月09日
註：原圖來自於 dilbert.com 於 2003/01/09 及 2003/01/10 刊載的漫畫，但原網站已經移除原圖的鏈結。 現在的圖則是 link 到 http://baby.homeip.net/patrick/ 的 blog 上的。 posted on 2004-11-09 15:47:00 by oldsidney 评论(4) 阅读(4015) 2004年11月02日 最近又發現 wiki 這個東西，可以讓一群人集體創作，例如wiki百科全書。 突然有個想法，想用wiki來集體翻譯使用手冊，不過後來考慮到版權的問題，想想還是作罷。 從想要將「oldsidney 學習筆記」換成blog開始，已經試了WordPress(blog)、xoops、osCommerce、CooCooWakka(wiki)這些東西，覺得open source的資源真是豐富。看來可以好好考慮學習PHP與MySQL(雖然open source不等於PHP+MySQL)，除了資源豐富之外，容易建置也是另一個吸引我的主要因素。 假如我有一個軟體開發團隊，我想可以用blog讓整個團隊的成員一起來知識分享，並透過xoops建立整個團隊的入口網(portal)，然後用wiki讓每個成員針對自己負責的部份，寫使用手冊。最後甚至還可以用 osCommerce 來將產品賣出去。 這樣的想法不知道行不行得通？ posted on 2004-11-02 10:03:00 by oldsidney 评论(10) 阅读(4452) 2004年10月28日 posted on 2004-10-28 13:57:00 by oldsidney 评论(40) 阅读(17036) 2004年10月25日 最近把「oldsidney 學習筆記」換到其它的 hosting，換過去後應該不會有被擋掉的問題了，所以大陸的讀者應該可以訪問到「oldsidney 學習筆記」了。 除了換 hosting 之外，也順便把整個網站換成了 WordPress Blog，以後發表文章就更方便囉！ 另外還有 ezMoney 的網站也一併建起來了。 posted on 2004-10-25 16:00:00 by oldsidney 评论(3) 阅读(3615) 2004年10月01日
自動化效能測試是一種手段，透過人、流程與技術，降低應用系統上線、升級以及更新 patch 的風險。在系統上線前，以預期上線後的負載進行測試，並量測其系統效能以及使用者經驗。一個好的效能測試可以回答以下的問題：
除此之外一個有效的效能測試，還能幫助您取得更多的資訊以便決定軟體是否可以交付部署，並且減少系統當機時間。透過自動化效能測試，可以將商業變化所造成的衝擊給量化，並藉此明瞭部署軟體的風險。 posted on 2004-10-01 15:00:00 by oldsidney 评论(4) 阅读(4747)
posted on 2004-10-01 14:56:00 by oldsidney 评论(1) 阅读(6197) 另外 liu 提醒：怕这个网站供给不纯，用这个功能来收集大家的邮件地址。所以用的时候自己小心了 只要在上面這個網頁輸入你的 GMail 的 username，就會幫你產生出屬於你個人的 GMail email address 小圖示。 例如我的 GMail 信箱： posted on 2004-10-01 10:35:00 by oldsidney 评论(13) 阅读(6421) 2004年09月24日 如果你的團隊沒有專門的測試人員(至少每兩到三個程式人員要配一名), 你要不是推出問題很多的產品, 就是浪費錢叫時薪100美元的程式人員去做測試員(時薪30美元)做的事. 省測試員絕對不是真省, 這實在是再明顯不過了. 我實在很驚訝很多人卻還認不清這一點！ 以下是由約耳談軟體列出不需要測試人員的五大藉口： posted on 2004-09-24 10:49:00 by oldsidney 评论(21) 阅读(6757) |
||
|
Powered by: Joycode.MVC引擎 0.5.1.8 Copyright © oldsidney 學習筆記 |
|||
