自動化測試框架的設計原則

1、前言:使用腳本語言來設計旦動化測試開發(fā)框架，是很多大型IT企業(yè)在進行自動化測試中所采用的方法，一 個好的自動化測試框架，可以大幅度提高測試人員自動化腳本開發(fā)的效率，可以提高自動化腳本開發(fā)的并行性 和可靠性。自動化測試框架設計的好與壞，直接關系到整個公司的測試水平，也關系到公司產品的發(fā)布周期和 發(fā)布質量。那么在設計一個自動化測試框架的時候，會面臨哪些問題？對這些問題，有什么解決方法，每一種 解決方法的優(yōu)劣又如何呢？我們在腳本開發(fā)長期的經驗中，看到了美國，中國；大型，小型等不同IT公司對于自動化測試框架設計 上的面臨的挑戰(zhàn)和相應的不同解決方法，這里結合我們的觀點，和大家一起探討一下。要選擇什么樣的

2、開發(fā)語言？常見的自動化框架開發(fā)語言有：C，C+，Java, TCL, Perl, Ruby, Python。使用C或者C+，對于整個自動化測試框架的執(zhí)行效率而言會有所提高。但是由于常見的測試流程對設 計到對大量字符串的處理能力，C或者C+在這些方面的支持并不完備。會導致整個開發(fā)流程的延長，更重 要的是，使用C或者C+，不能夠實現跨平臺。如果自動化框架只是在公司內部使用，不是商用產品的話， 不建議使用。Java的自動化測試框架主要還是面向對使用Java開發(fā)的產品的測試，并且主要使用在單元測試階段。對 于用其他語言開發(fā)并編譯的軟件產品，在測試方面提供的支持力度一般。如果是對于嵌入式系統(tǒng)的測試，就

3、更欠缺。在Web界面的測試方面，Java提供一定的支持。TCL是老牌的自動化測試語言。在80年代開始就在Motorola使用，后來被思科采納，并在自動化測試 領域得到了廣泛的應用。對于基于命令行來遠程控制的設備如路由器，交換機等的自動化測試領域應用非常成 熟。美中不足的是：TCL在設計之初是不支持面向對象的設計方法的，雖然后來出現了 iTCL來彌補不足，但 是常見的基于TCL的測試腳本開發(fā)還不是基于面向對象的。對腳本的可維護性和可復用性帶來了一些挑戰(zhàn)。Perl語言在設計之初也不支持面向對象，在網絡管理員的圈子里應用的很廣，被稱作是the duct tape of the Internet。在自

4、動化測試領域應用的范圍不是很廣泛。有一些IT廠家由于歷史的原因在使用Perl進行自動 化測試，但是也在慢慢向其他腳本開發(fā)語言轉型。Python作為一個腳本開發(fā)語言，它的使用者社區(qū)的技術水平比較高。相對來說，它的支持庫的代碼水平 也比較高。對于軟件開發(fā)的各個方面的第三方庫（如圖像處理，網絡通信，Web技術等）都有非常好的支持。 Python本質上就是面向對象的腳本語言。90年代以后成立的硅谷高科技公司，很多都使用Python作為他們 自動化測試的官方語言。在美國的群眾基礎非常好。社區(qū)也非常活躍。它的創(chuàng)始人還因此被Google招募旗下。Ruby是日本人發(fā)明的完全面向對象的腳本語言。它的使用者社區(qū)起

5、初主要在日本和臺灣的一些IT公司。在2006年左右，當Web的綜合開發(fā)框架Ruby on Rails出現后，在網站的開發(fā)社區(qū)中也開始流行開來。 Ruby語言也受到了大型IT公司的測試團隊的關注。在自動化測試領域得到了越來越廣泛的應用。有一些大型 公司正在由其他的腳本語言向Ruby轉換。作為一個自動化測試框架，一個設計原則就是快速成形，快速推廣，增量開發(fā)?？蚣艿幕竟δ芤R上可 用，并能迅速找到使用者，得到成功推廣的案例，形成自己的使用社區(qū)。并在此基礎上，按照社區(qū)使用人的需 求，進行增量開發(fā)，逐步擴大社區(qū)的用戶基數，并豐富框架的功能。在這個要求上，對編程語言的選擇有如下 兩點：1、Fast Pr

6、ototype （馬上就可以用）2、可擴展第一點，對于解釋執(zhí)行的腳本語言來說，是非常適合的，解釋執(zhí)行的腳本語言可以再有限的代碼量內開發(fā) 出盡可能豐富的功能，而不用擔心內存分配與釋放等其他編譯執(zhí)行語言需要考慮的問題。而面向對象有可以滿 足第二點的要求。所以，如果選擇自動化框架的腳本語言，推薦Python和Ruby。業(yè)界常用的控制庫的設計方法和工具有哪些？既然是自動化測試，就涉及到對遠程的被測試對象進行無人值守的自動化控制與測試。需要自動化復現測 試人員的手動操作步驟和結果判斷步驟。而對于遠程被測對象的控制，可以分為1、命令行（CLI）控制2、圖形用戶界面（GUI）控制CLI的控制主要是使用Exp

7、ect的遠程控制庫。Expect庫在TCL上最先開發(fā)，后來也被移植到了 Perl， Ruby 和 Python 上?？刂茍D像界面的工具分為控制Web瀏覽器的工具和控制窗口的工具。具體應用的時候又可以分為開源和 商用工具兩個方面：常用Web瀏覽器自動化控制商用工具：WinrunnerQIBSilktestIBM Rational Robot常用的Web瀏覽器自動化控制開源工具：SeleniumAutoITIE AutomateRuby Waitr推薦使用工具的原則是無論使用商用還是開源的自動化測試工具，都需要可以支持標準的腳本編程語言： TCL, Perl, Ruby, Python。這樣，可以

8、保證自動化測試體系不會鎖定在某一個測試工具上。一個測試框架最基本功能是什么？既然是一個測試框架，很多設計人員喜歡把一大堆的東西都塞在里面，為測試框架增添很多的功能。實際 上，一個測試框架應該在兩個核心功能上做好文章，其他的都是次要的輔助功能：1、強力的執(zhí)行引擎：真正做到無人值守2、良好的報表生成和管理功能所謂強力的執(zhí)行引擎，是指一個自動化測試框架在批量執(zhí)行腳本的情況下，不論遇到什么情況，如腳本運 行錯誤，腳本質量錯誤，測試環(huán)境異常，被測設備死機或者掛起等，都要有能力重新清理測試環(huán)境，使測試環(huán) 境恢復到最初始的狀態(tài)，并執(zhí)行接下來需要執(zhí)行的腳本。也就是說，一個好的測試引擎，能夠做到24小時7 天的

9、無人值守的運行，而不會中途因為任何的非物理異常而退出。良好的報表生成功能是指一個測試框架要有分布式的對腳本的結果的收獲和呈現的能力。很多情況下，腳 本是并發(fā)執(zhí)行的，就像一下子種了一大塊田，而當腳本執(zhí)行完畢，也就是莊稼成熟的時候，如何對腳本執(zhí)行的 結果進行快速收割，并捆綁好，整齊劃一，讓人對結果一目了然。更重要的是，要需要能夠提供針對不同版本 的相同自動化腳本執(zhí)行日志的比較。并能夠對這些報表進行搜索和排序，這些都需要一個很好的報表生成和 管理功能。要不要IDE開發(fā)環(huán)境？很多人問，一個自動化測試框架，如果沒有一個集成開發(fā)環(huán)境，開進行腳本的開發(fā)和調試，那還叫做自動 化測試框架么？實際上，這里面有一個

10、對自動化測試框架理解的誤區(qū)。而這個誤區(qū)，在沒有真正做過完整的軟 件測試發(fā)布流程之前，是一個腳本開發(fā)人員不會了解的。一個自動化測試框架的目的到底是什么？很多人一下子回答不上來。而在多年的實踐中，我們了解到，一 個自動化測試的最重要的目的，或者說它存在的理由是：縮短產品的測試周期。企業(yè)之所以愿意在自動化測試 框架上投入人力和物力，主要原因還是因為自動化框架可以大規(guī)模的驅動自動化測試腳本的并行執(zhí)行，并能夠 在短時間之內獲取到測試結果。并根據測試結果生成完整的測試報告。而這個測試報告時一個軟件版本能否發(fā) 布的重要的質量依據。越早拿到整個測試報告，產品的發(fā)布周期就會縮短。Time to Market的時

11、間就會縮短， 企業(yè)就會早一點占領市場。從這個角度看，一個集成的開發(fā)環(huán)境并不能夠滿足企業(yè)的這方面的需求。一個集成開發(fā)環(huán)境會加快腳本的 開發(fā)速度和調試速度，但是并不能夠加快腳本的執(zhí)行速度。所以，在一些業(yè)界比較優(yōu)秀的自動化測試框架里面， 并沒有提供集成開發(fā)環(huán)境和調試環(huán)境。如果想開發(fā)腳本，使用UltraEdit, Vim或者Emacs就可以了。調試使 用基本的腳本語言調試出錯功能就可以了。所以我們說，自動化測試框架的開發(fā)，也涉及到整個自動化測試活動的開展的績效評估有冰山效應。如果 不能得到最終的測試報告，IDE環(huán)境設計的再好，也看不到績效：動化回舟測試雌自動化倒本開發(fā)培訓、 I自動化測鹽框架的弁發(fā)與維

12、機自動化腳赤質皇評估AP!仍W）設計與實現自劫頒!試床的雄護失敗腳本的ObugCLU 也從這個角度來說，一個自動化測試框架的設計的成功，應該是重執(zhí)行和測試結果的收獲的生產效率，而不 是偏重開發(fā)環(huán)境的好壞和腳本開發(fā)的生產效率。是分布式測試框架還是統(tǒng)一的測試框架好？這是自動化測試框架設計中面臨了又一個測試抉擇。分布式的測試框架，有點像早期的軟件開發(fā)，微軟的方式，就是每個人一套軟件。每個人一個測試框架。 這個測試框架是由測試人員獨享的。他在這個測試框架上執(zhí)行測試用例，收獲測試結果。統(tǒng)一的測試框架，有點類似于當今Web2.0的概念，是以提供服務，而不是軟件為主的。整個公司的測試 人員都同意到一個服務器

13、上去提交測試任務，這個統(tǒng)一的測試框架會有自己的任務調度功能，優(yōu)先級處理功能 等來統(tǒng)一執(zhí)行提交的測試任務，并把測試結果返回給提交相應測試任務的測試人員。通常，是有一個Web界 面的人機接口。那么，是一人一套框架好呢？還是大家共用一個框架好呢？在設計原則上，并沒有優(yōu)劣之分。雖然有人說， Web2.0的方式是大勢所趨，云計算已經成為了趨勢。一個統(tǒng)一的基于客戶端服務器架構的自動化測試框架會 便于管理，便于跟蹤，但是，統(tǒng)一的框架需要復雜的進度調度和測試環(huán)境的協(xié)調（共用使用物理測試環(huán)境所造 成的沖突）。相對來說，一個人一套自動化測試框架的設計方法直接，實現簡單，部署容易，管理花費少?？?以讓大家很快的用起

14、來，能夠早的看到測試結果。而對自動化測試框架來說，越快看到結果（測試結果）越能 得到管理層的支持和投資。所以，在項目初期的時候，建議可以使用一個測試工程師一套框架的方法，在大家等候使用起來以后，在 把這套框架移植到統(tǒng)一的服務器上去。做一個漸進式的，逐步演化的測試框架，而不是在項目一開始就設計一 個一個高，大，全的自動化測試框架，讓大家等的望眼欲穿。自動化測試框架中API設計原則有哪些？API的封裝的好壞涉及到腳本的開發(fā)效率和可維護性。有經驗顯示，相對于設計水平一般的API，一套好 的自動化測試API可以提高自動化腳本的開發(fā)效率2-3倍，一般來講，需要進行三層封裝：總的來說，自動化框架中設計的好的API有兩個原則要把握：隱藏測試設備的復雜性，針對測試邏輯提供統(tǒng)一的接口。熟悉軟件測試的工程師都知道，測試當中，是 需要使用很多輔助測試設備的，這些設備，有可能是PC上的運行的測試軟件，有可能是專用的測試設備。而 很多時候，不同的測試設備往往都是做同樣的測試活動。如簡單的Web頁面自動化就可以使用QTP， Winrunner，Selenium等。封裝的好的API，應該能夠隱藏底層使用的測試工