Wednesday, February 13, 2008
Saturday, November 18, 2006
看看 Mercury 自動化功能測試已經發展到什麼程度。
傳統自動化測試的限制
軟體的自動化測試在過去一段時間中有長足的進步。每個世代的產品都成功解決了某些重要的挑戰，但是同時也引進了不同的問題等待解決。
第一代的自動化測試大概在15年前開始，透過硬體的方式錄製鍵盤的輸入並播放，但缺少檢查點（checkpoint）的功能，而且測試腳本很難維護。
第二代的自動化測試則大約在10年前開始的，這時已經由硬體轉變成透過軟體錄製/播放（capture/playback）的方式產生測試腳本（script），並且也增加了檢查點的功能，可以對軟體做驗證，測試的範圍也比硬體方式的自動化方式大了許多。比較大的問題是測試腳本也是一種程式語言，所以測試人員也需要懂程式語言，換句話說就是要會寫程式。而且當軟體有變動時，測試腳本也需要同步更新，這對測試人員來說是一大挑戰，測試人員常常就是整個測試腳本再重新錄製一遍。
在2001年開始了第三代的自動化測試稱為「測試框架（test framework）」，主要是把測試腳本給抽象化（abstraction）（註：如Keyword-Driven Test），讓非技術人員（如系統分析師、使用者等）即使不懂測試腳本，不會寫程式的情況下，也可以使用自動化測試工具建立自動化測試個案。
第四代
Mercury Business Process Testing：專注於業務需求的自動化測試
Friday, July 28, 2006
假如你同時使用微軟的 Visual Studio 2005 開發軟體以及 Mercury Quality Center 管理 defect，那就可以在 Mercury Quality Center Add-in page 下載這個 add-in。安裝之後就可以直接在 Visual Studio 2005 IDE 中直接處理 Quality Center 上的 Defect，不需要再另外開瀏覽器了！！
圖一 直接在 Visual Studio 2005 中就可以處理 Quality Center 系統中的 defects
圖二 也可以在 Visual Studio 2005 中直接創建一個 defect 到 Quality Center 系統中！
Thursday, May 19, 2005
ViewState 是 ASP.NET 用來存放網頁上伺服器端控制項 (server control) 狀態的一個隱藏欄位，所以當你檢視你的 ASP.NET 網頁原始檔，會發現一個 "__VIEWSTATE" 的隱藏欄位，其值是一堆看不懂的字元，就如同下列的例子。
<INPUT type="hidden" name="__VIEWSTATE"
value="dDwxNTgzOTU2ODA7dDw7bDxpPDE+Oz47bD
x0PDtsPGk8MT47PjtsPHQ8QDA8cDxwPGw8UGFnZU
NvdW50O18hSXRlbUNvdW50O18hRGF0YVNvdXJjZ
Ul0ZW1Db3VudDtEYXRhS2V5czs+O2w8aTwxPjtpPD
g+O2k8OD47bDw+Oz4+Oz47Ozs7Ozs7OztAMDxAMD
xwPGw8SGVhZGVyVGV4dDtEYXRhRmllbGQ7U29yd
EV4cHJlc3Npb247UmVhZE9ubHk7PjtsPHB1Yl9pZDtwd=="/>
當使用 LoadRunner VuGen 錄製含有 ViewState 的 ASP.NET網站應用時，就會需要做關聯 (Correlation)。
其關聯的範例腳本如下：
web_reg_save_param("MyViewState","LB=\"__VIEWSTATE\" value=\"","RB=\"",LAST);
假如 ASP.NET 網頁上的控制項一多，ViewState 會變得很大，所以通常也會需要使用 web_set_max_html_param_len 函數將參數 (Parameter) 的長度給適度地放大：
web_set_max_html_param_len("2048");
其他關於 ViewState 的參考資料：ViewState: All You Wanted to Know
Thursday, January 06, 2005
有人提到不清楚什麼是 LoadRunner？LoadRunner 是一套做效能測試的工具，比較詳細的說明可以參考下面這篇白皮書：
自動化效能測試白皮書
類似的工具有：
假如你想更了解 LoadRunner 的話，可以從 LoadRunner Tutorial 開始：
- LoadRunner 8 Tutorial
- 安裝 LoadRunner 8
- 認識 LoadRunner 8 的元件
- LoadRunner 常用的術語
- LoadRunner 流程
- 熟悉 Mercury Tour 範例網站
- 先體驗一下 LoadRunner 的威力
- To be continue...
當錄製腳本時，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
Tuesday, November 09, 2004
註：原圖來自於 dilbert.com 於 2003/01/09 及 2003/01/10 刊載的漫畫，但原網站已經移除原圖的鏈結。 現在的圖則是 link 到 http://baby.homeip.net/patrick/ 的 blog 上的。
Tuesday, November 02, 2004
最近又發現 wiki 這個東西，可以讓一群人集體創作，例如wiki百科全書。
突然有個想法，想用wiki來集體翻譯使用手冊，不過後來考慮到版權的問題，想想還是作罷。
從想要將「oldsidney 學習筆記」換成blog開始，已經試了WordPress(blog)、xoops、osCommerce、CooCooWakka(wiki)這些東西，覺得open source的資源真是豐富。看來可以好好考慮學習PHP與MySQL(雖然open source不等於PHP+MySQL)，除了資源豐富之外，容易建置也是另一個吸引我的主要因素。
假如我有一個軟體開發團隊，我想可以用blog讓整個團隊的成員一起來知識分享，並透過xoops建立整個團隊的入口網(portal)，然後用wiki讓每個成員針對自己負責的部份，寫使用手冊。最後甚至還可以用 osCommerce 來將產品賣出去。
這樣的想法不知道行不行得通？
Thursday, October 28, 2004
！喔的倒顛是都料資的來出查連，字鍵關入輸倒顛要只不，elgooG 的倒顛，站網的趣有個一
http://www.alltooflat.com/geeky/elgoog/
Monday, October 25, 2004
最近把「oldsidney 學習筆記」換到其它的 hosting，換過去後應該不會有被擋掉的問題了，所以大陸的讀者應該可以訪問到「oldsidney 學習筆記」了。
除了換 hosting 之外，也順便把整個網站換成了 WordPress Blog，以後發表文章就更方便囉！
另外還有 ezMoney 的網站也一併建起來了。
Monday, October 11, 2004
GMail Icon Maker
另外 liu 提醒：怕这个网站供给不纯，用这个功能来收集大家的邮件地址。所以用的时候自己小心了
只要在上面這個網頁輸入你的 GMail 的 username，就會幫你產生出屬於你個人的 GMail email address 小圖示。
例如我的 GMail 信箱：
Friday, October 01, 2004
基本上這篇文章原本就是 Mercury 的白皮書，所以讀者一定覺得我有幫 Mercury 打廣告的嫌疑。不過撇開 Mercury 產品的內容，我覺得整個白皮書所講的效能測試部分，還是蠻有參考價值的，這也是我之所以會翻譯這篇文章的主要原因。
資料來源：Mercury
|
自動化效能測試是一種手段，透過人、流程與技術，降低應用系統上線、升級以及更新 patch 的風險。在系統上線前，以預期上線後的負載進行測試，並量測其系統效能以及使用者經驗。一個好的效能測試可以回答以下的問題：
- 當預期數量的使用者同時上線時，系統的回應是否夠快？
- 系統是否能夠負荷的了預期的負載，甚至在超出預期的負載下也能正常運作？
- 系統是否能夠處理的了所有的商業交易？
- 在預期的負載或是超出預期的負載下，系統是否穩定？
- 在決定上線時，您能確保使用者將會有良好的使用經驗(如回應時間)？
除此之外一個有效的效能測試，還能幫助您取得更多的資訊以便決定軟體是否可以交付部署，並且減少系統當機時間。透過自動化效能測試，可以將商業變化所造成的衝擊給量化，並藉此明瞭部署軟體的風險。
詳全文
Friday, September 24, 2004
如果你的團隊沒有專門的測試人員(至少每兩到三個程式人員要配一名), 你要不是推出問題很多的產品, 就是浪費錢叫時薪100美元的程式人員去做測試員(時薪30美元)做的事. 省測試員絕對不是真省, 這實在是再明顯不過了. 我實在很驚訝很多人卻還認不清這一點！
以下是由約耳談軟體列出不需要測試人員的五大藉口：
1. Bug 是由懶散的程式設計人員造成的
2. 我的軟體就放在網路上，所以要修正很容易
3. 我的客戶會替我做測試
4. 好的測試人員都不想當測試人員
5. 我請不起測試人員
原文
Eric Gunnerson 解釋了先行測試開發的概念，並提供操作範例來說明如何將這個準則實際運用到應用程式中。
詳全文
Friday, September 17, 2004
使用 Rational Robot 實現自動化測試 (簡體中文-IBM)
在過去的數年中，通過使用自動化的測試工具對軟體的品質進行保障的例子已經數不勝數。到現在為止自動化測試工具已經足夠完善了，我們完全可以通過在軟體的測試中應用自動化的測試工具來大幅度的提供軟體測試的效率和品質。在使用自動化的測試工具的時候我們建議儘早的開始測試的工作，這樣可以使修改錯誤更加的容易和廉價，並且可以減少更正錯誤對軟體發展週期的影響。下圖顯示了手工測試與自動化測試的比較。這個測試案例中包括1750個測試用例和700多個錯誤。
你的組織為自動化測試做好準備了嗎？(簡體中文-IBM)
本文關注於一個實施自動化測試框架的組織的主要方面和影響。本文的意圖是提供一些能夠成功的實施自動化測試的指導方針。