摘要: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 的白皮書，所以讀者一定覺得我有幫 Mercury 打廣告的嫌疑。不過撇開 Mercury 產品的內容，我覺得整個白皮書所講的效能測試部分，還是蠻有參考價值的，這也是我之所以會翻譯這篇文章的主要原因。資料來源：Mercury 前言在過去20年來，企業已經把過去軟體的使用轉變成為「數位化工作」。軟體被大量運用來增進工作效率與生產力。在全球化的經濟，軟體更成為提供協同運作以及資訊分享的新媒介。事實上，軟體已經變成是企業關鍵業務 (business-critical) 上資訊分享與交易處理的主要管道。在今天，企業已經脫離不了軟體，不管是電子郵件、 CRM (Customer Relationship Management) 到交易處理，軟體都可以視為是商業。同時，軟體的開發技術也變得非常成熟，相對的複雜程度也與日俱增，所帶來的影響就是軟體可能存在更多潛在問題，而且更難找出問題所在。再者，軟體不像是一部車子，壞了只要換個零件就可以了。軟體可能為了保持競爭優勢或是因為商業條件的改變，每週、每月、每年都在演化。所以企業必須對這一連串改變所造成的風險作有效的管理。我們可以看到軟體正以非常快速的步調在改變，複雜程度有如爆炸般的與日俱增，為整個軟體開發流程帶來巨大的風險。 什麼是效能測試？所謂的「效能測試」是在系統上線前用來測試 end-to-end 效能 (performance) 的一種測試方法，而 end-to-end 意味著效能測試是要從使用者的角度去驗證效能指標。所以效能測試解決方案 (solution) 應該提供： 使用最少的硬體資源，模擬成千上百的使用者與系統互動 從終端使用者 (end-user) 的角度量測系統回應時間 (response time) 能夠以一致的方式重複產生負載 監視待測系統的各個元件 提供強大的分析工具與報表產生器 自動化效能測試解決方案，通常使用四個主要元件來建立並執行效能測試。這四種主要元件為： 虛擬使用者產生器 (Virtual User Generator)：錄製使用者操作的業務流程 (business process) 以產生自動測試腳本 (script) 控制器 (Controller)：組織、驅動、管理並監視整個效能測試的執行 負載產生器 (Load Generator)：在測試過程中用來執行虛擬使用者 (virtual user) 產生負載 分析 (Analysis)：用來檢視、剖析、比較測試的結果 為何要自動化效能測試？自動化效能測試是一種手段，透過人、流程與技術，降低應用系統上線、升級以及更新 patch 的風險。在系統上線前，以預期上線後的負載進行測試，並量測其系統效能以及使用者經驗。一個好的效能測試可以回答以下的問題： 當預期數量的使用者同時上線時，系統的回應是否夠快？ 系統是否能夠負荷的了預期的負載，甚至在超出預期的負載下也能正常運作？ 系統是否能夠處理的了所有的商業交易？ 在預期的負載或是超出預期的負載下，系統是否穩定？ 在決定上線時，您能確保使用者將會有良好的使用經驗(如回應時間)？ 除此之外一個有效的效能測試，還能幫助您取得更多的資訊以便決定軟體是否可以交付部署，並且減少系統當機時間。透過自動化效能測試，可以將商業變化所造成的衝擊給量化，並藉此明瞭部署軟體的風險。 自動化效能測試流程 譯註：這張圖說明了整個效能測試的流程，非常具有參考價值喔！ 一般而言，自動化效能測試的流程分成四大階段：設計 (design)、建立 (build)、執行 (execute)、診斷與調優 (diagnose and tune)。每個階段都需要有不同的角色參與，以完成不同的工作。 在設計階段需要定義要執行效能測試的商業流程 (business process)、在一般以及尖峰時間需執行哪些商業流程、同一時間有多少的使用者上線、以及系統的效能指標如回應時間 (response time)。 在建立階段首先要建立整個測試環境，包含待測系統以及基礎建設 (infrastructure)，如網路。並透過自動化效能測試工具，建立測試腳本 (script) 與測試場景 (scenario)。 在執行階段則是執行測試場景，並監視系統效能。 而診斷與調優主要透過執行測試場景所蒐集到的效能數據，快速地找到問題與瓶頸，以便優化整個系統的效能。這個階段是需要配合執行階段一起反覆進行的。接下來將針對每一階段的工作做更詳細的說明，以確保效能測試的成功： 設計 (Design)在這個階段，效能測試團隊主要的工作是取得系統的效能需求，效能需求一般可分成四大類 - 商業 (business)、技術 (technical)、系統 (system)、團隊 (team)。從商業需求的角度，您可以透過與專家 (subject matter experts, SMEs) 開會的方式蒐集商業需求。這些專家可能是商業分析師 (business analusts) 或者是您的使用者。商業需求可能會以下列的方式呈現： Application overview：透過使用者示範的方式，讓效能測試團隊從高階的角度，清楚的知道系統是如何被使用。 Business Process List：一份列出在系統上會被使用者執行的關鍵商業流程清單。 Business Process Flows：針對清單上的每一個關鍵商業流程，將其操作步驟、螢幕畫面，寫成文件。 Transaction List：列出關鍵商業流程中，需要被量測效能的關鍵步驟，例如登入、新增訂單。......[阅读全文]

摘要: Automated Testing：A Silver Bullet? 譯注：「美國人深信月圓之夜狼人出沒。殺死狼人的唯一方法是，以銀製的子彈貫穿它的心臟。所以，There is no silver bullet 的意思是：沒有致命、有效、一擊中的的方法。」(感謝 Jeff 指正、Areca Chen 提供典故！) 一般在提到自動化測試時，通常會有下列的迷失： 我們可以將所有的測試自動化 自動化測試可以提高生產力，讓我們以更少的人力完成所有的測試 測試自動化很簡單( 通常為 capture/play )，所以我們不需要任何教育訓練 測試自動化可以減輕我們的工作負擔 我們不需要作測試計劃就可以開始自動測試 自動化測試會使原本的測試人員變成多餘的 我們不需要花費時間在設計測試個案了為了要釐清上述的迷失，就必須了解『什麼是自動化測試？』以及『自動化測試到底可以幫您作什麼？』，當您對自動化測試有一定程度的了解之後，才能真正發揮自動化測試的好處。 自動化測試不是銀質子彈 ( Silver Bullet )？自動化測試 - 或者說是實施自動化測試的策略與工具 - 只是測試人員工具箱 ( toolbox ) 中的一把大榔頭，在這裡我特別強調自動化測試只是工具箱中的工具，而避免提及用自動化測試來取代人工測試，因為人工測試是無法取代的。當然毫無疑問的自動化測試是很有威力的工具，只要您運用得當，工具也會為您帶來極大的好處，關鍵在於何時 ( when ) 以及如何 ( how ) 使用它。 我們有足夠的時間作完整的測試嗎？到底我們有沒有足夠的時間可以作完整的測試？我想答案是"沒有"。因為有太多狀況要測試，例如不同的資料、平台、作業系統、設定等等，而實際的情形是，隨著交貨的時限越來越接近，分配給測試的時間總是第一優先被壓縮掉，結果專案經理與測試人員，大量刪減測試個案，甚至到最後已經刪減過的測試計劃，還是沒有足夠的時間可以完成所有測試，然後，軟體就出貨了。有多少的軟體是經過完整的測試才出貨的？很多團隊是以下列的條件來判斷是否該出貨了： 我們是否還有時間？ 我們是否還有預算？ 我們是否還有資源？ 我們是否還有可樂與比薩？由於測試的工作被任意刪減，開發團隊完全不知道交付出去的軟體品質到底如何 ( 通常是品質低落 )，而最後的結果是需要花更多的成本去解決問題。當開發團隊面對這樣子兩難 ( 時程與品質 ) 的處境時，自動化測試能不能幫我們解決這樣的問題呢？讓我們繼續往下探討吧。 自動化測試可以幫助我們作什麼？在您計劃開始導入自動化測試之前，您應該清楚瞭解自動化測試的定義，以下是一些常聽到對自動化測試的描述： 在測試時完全不需要人去介入 錄製測試腳本 ( script ) 測試工具 不知道有時候人們在解釋自動化測試時，常常只注意到測試腳本 ( script ) 的錄製或撰寫，這樣的看法真的是太小看自動化測試了。以下對自動化測試的定義是來自 Quality Engineering 社群的定義：自動化測試就是利用策略、工具以及產出等，減少人工介入非技術性 ( unskilled )、重複性 ( repetitive )、冗長 ( redundant ) 的測試活動。根據這樣的定義，以下列出一些自動化測試的方法： 方法 說明 範例 範本 ( Template ) 文件的範本，通常含版面格式與指引方針 ( Guideline ) 如測試個案或測試計劃範本，通常是由文件範本或是工具所產生 測試腳本 ( Scripts ) 透過可執行的程式碼，執行測試的動作，程式碼可能是工具產生或是手動撰寫 如 Visual Test scripts、Rational Robot scripts 等 映像檔 ( Images ) 透過壓縮檔案或備份方式，快速建置或回覆測試環境 如用 Ghost 備份測試環境 巨集 ( Macros ) 以巨集的方式執行測試相關工作 如透過 Excel 巨集產生或管理測試資料 批次檔 ( Batch ) 以作業系統批次檔方式執行測試相關工作 如使用 DOS......[阅读全文]

摘要: Totally Data-Driven Automated Testing 原文：Totally Data-Driven Automated Testing By Keith Zambelich Sr. Software Quality Assurance Analyst, Automated Testing Evangelist 作者簡介作者目前為 Automated Testing Specialists, Inc. 這家公司的總裁兼執行長，主要從事自動化測試導入的顧問工作，而且本身也是 Mercury Interactive 認證的 WinRunner CPS(Certified Product Specialist)。 摘要「軟體測試自動化」已經被許多的軟體測試專家驗證是可行的，並且反覆的運用在許多軟體開發過程中。大多數參與軟體測試的專家也同意自動化測試不只是值得的同時也是必要的。在軟體測試的市場上有許多針對使用者介面(GUI)應用程式所開發的自動化測試工具，而且其中有些工具所提供的功能，已經足夠滿足軟體測試自動化的需求。但是，我們卻看到越來越多的公司，在購買自動化測試工具之後才發現，實施一個符合成本效益(cost-effective)的自動化測試解決方案(solution)原比其所呈現的還困難。我們會常常聽到一些抱怨，像是"看軟體測試工具廠商做起來好像很容易，但是當我們的人自己做的時候卻完全不是那麼一回事！"、"事實上我們已經花了六個月的時間在導入自動化測試，但是大部分的測試卻還是停留在人工測試的階段！"或是"要讓整個自動化測試運作起來所花費的時間實在太長了，還不如使用原本的人工測試所花的時間更短！"。通常最後的結局是"另一個錯誤的採購！"，自動化測試工具從此被束之高閣了。本文的目的是跳脫學術理論，透過作者本身的經驗，以更直覺、忠實的態度來討論自動化測試的議題，讓讀者能夠清楚的瞭解，要成功實施符合成本效益的自動化測試，到底需要哪些條件的配合。 何謂自動化測試？簡而言之，所謂的自動化測試就是將您現有的手動測試流程給自動化。而且要實施自動化測試的公司或組織，本身必須要有一套「正規(formalized)」的手動測試流程。而這個正規的手動測試流程至少要包含以下的條件： 詳細的測試個案(test cases)：從商業功能規格或設計文件而來的測試個案，包含可預期的(predictable)的預期結果(expected result)。 獨立的測試環境(test environment)：包含可回覆測試資料的測試環境，以便在應用軟體每次變動後，都可以重複執行測試個案。假如您目前的測試流程並未包含上述條件，即使您導入了自動化測試，也不會得到多大的好處。所以，假如您的測試方法(testing methodology)只是將應用軟體移轉到一群由「使用者」或「專家級使用者(subject matter experts)」組成的測試團隊，然後任由他們去敲擊鍵盤執行測試工作。那我建議您先把自動化測試放一邊，把「建立一個有效的測試流程」當成您目前首要的工作。因為要自動化一項不存在的流程是完全沒有意義的。自動化測試最實際的應用與目的是自動化回歸測試(regression testing)。也就是說，您必須要有用來儲存詳細測試個案的資料庫，而且這些測試個案是可以重複執行於每次應用軟體被變更後，以確保應用軟體的變更沒有產生任何因為不小心所造成的影響。「自動化測試腳本(script)」同時也是一段程式。為了要更有效的開發自動測試腳本，您必須和一般軟體開發的過程一樣，建立制度以及標準。要更有效的運用自動化測試工具，您至少要有一位受過良好訓練的技術人員，換句話說，您至少要有一位程式設計師(programmer)。 自動化測試的成本效益(Cost-Effective)首先我要告訴您的是，自動化測試是非常昂貴的(這違反了工具廠商灌輸給您的觀念)，而且自動化測試不會取代手動測試或是幫助您縮編(down-size)您原本的測試團隊。對於您的測試流程，您應該將自動化測試看成是附加的選項。 譯註：也就是說即使沒有自動化測試工具，您應該也可以將測試做的很好，工具只是幫您做得更快更多，而且讓您有更多的時間花在設計好的測試個案上。 根據 Cem Kanner 的一篇文章 「Improving the Maintainability of Automated Test Suites」 (www.kaner.com)，要建立一個自動化測試個案，包含開發、測試、撰寫文件，所花費的時間大約是手動測試個案的3到10倍之多(甚至還要更久)。特別是當您選擇使用「錄製/播放(大部份自動化測試工具都提供此功能)」的方式作為您建立測試腳本的主要方法時，這個公式更是能成立。也就是說只透過「錄製/播放」的方式建立自動化測試所能得到的效益是最少的。投入自動化測試可以是有效益的，只要您能把握以下的原則(common sense)並將其應用到導入的過程當中： 為您公司或組織選擇一個最符合您測試需求的自動化測試工具。 瞭解不是所有的測試都適合或直得自動化。例如將過度複雜的測試自動化可能會花費更多的成本，那您就要考量值不值得將其自動化。切記，將自動化的重點放在主要的測試個案上。 只有會重複執行的測試才需要自動化。只做一次的測試那就免了吧！ 避免只使用「錄製/播放」的方式實施自動化，因為這個方式可能會潛藏著陷阱，而且就長期的考量，這也是最浪費時間的自動化方式。不過您可以使用「錄製/播放」的功能，觀察自動化測試工具如何在您的應用軟體上執行測試，這或許對於您在發展測試腳本時會有幫助。 採用「資料驅動(data-driven)」的自動化測試方法，將測試的「輸入資料/預期結果」與測試腳本分開，如此一來，您可以開發更通用(generic)的測試腳本，然後只要更新「輸入資料/預期結果」的資料就可以了。接下來我會介紹二種非常有用的資料驅動測試方法。 錄製/播放的神話每一家自動化測試工具廠商都會告訴你，他們的工具非常容易使用，所以非技術背景的測試人員，只需要簡單錄製測試的操作過程，然後播放錄製好的測試腳本，就可以輕鬆自動化所有的測試。這樣的說法要為自動化測試工具被束之高閣的結果負大部分的責任。假如可以，我倒是很願意看到說這些話的業務人員，真的在實際的測試上，使用他們自己所賣的工具，然後看看自動化測試是否就如同他們所形容般的如此簡單。為什麼自動化測試不能單單只靠「錄製/播放」來完成呢？以下幾點將告訴您為什麼： 透過錄製建立的腳本，裡面的資料基本上都是 hard-coded 的，當應用軟體變動時，意味這些 hard-coded 的資料可能也需要修改。 維護這些錄製的腳本，成本是非常高的，高到幾乎不能接受。 透過錄製建立的腳本，不是很可靠，甚至在應用軟體完全沒有變動的情況下直接播放，也可能因為一些例外狀況而出現無法執行的問題。 假如錄製時測試人員使用了錯的資料，那腳本就必須重新錄製。 當軟體變動時，要重新錄製腳本。 所有的測試腳本都必須是在應用程式可以正確執行時才能錄製，假如在錄製過程中發現 bug (錄製的過程也可以看成是作手動測試)，測試人員必須回報 bug，而且等到 bug 解決了，整個錄製腳本的動作才能在繼續下去。在這樣的情況下，您可以好好的思考一下，你到底是在測試什麼？經過2~3個月這樣沒有實質效益的嘗試後，測試人員終究會發現自動化測試並非如工具廠商所形容的簡單，然後他們會放棄自動化測試，重新回到原本手動測試的作法。而工具廠商對他們也不再關心了，畢竟他們的工作是賣工具而不是作軟體測試。 可行的自動化測試方法就長期的效益上，我們不會將「錄製/播放」當成是我們自動化測試的策略，接下來就讓我們討論以下二種真正有效益的自動化測試的方法論(methodlogies)： Function Decomposition「Function Decomposition」的主要概念在於將所有測試個案分解成最基本的動作，如 User-Defined Function、Business Function 腳本，並建立可以獨立執行的共用腳本，如 Sub-routine、Utility 腳本。而這些基本腳本可能包含以下動作： Navigation (e.g. "Access Payment Screen from Main Menu") Specific (Business) Function (e.g. "Post a Payment") Data Verification (e.g. "Verify Payment Updates Current Balance") Return Navigation (e.g. "Return to Main Menu")......[阅读全文]