Tags: 敏捷測試, 自動化測試, 軟件測試
DSL與自動化測試 – 用Python實現簡單的DSL
二.03, 2010 in python, 自動化測試 2 Comments
自動化測試，一個在測試領域中被廣為熟知，也是被談論最多的概念之一。DSL (Domain Specific Language)，一種高度抽象，用于某個特定領域下編程語言。軟件測試在大多數情況下都是對某個特定行業的軟件系統進行測試，所以這兩者應該可以很好的結合起來，事實上也是這樣的，QTP里面的keyword view，其實就是DSL的一個實現。DSL一般可以分為兩個大的類型，分別是External DSL 和 Internal DSL (引用自Martin Fowler)。External DSL 一般來說是跟其實現語言不一樣的 DSL，常見的External DSL 有：SQL和XML配置文件;而Internal DSL 一般來說就是該DSL使用某個現成的編程語言(就是所謂的host language)，然后對host language進行一些改造而成。 我們在測試中會遇到很多問題，其中一些問題，幾乎是所有公司所有團隊都會遇到的，例如測試覆蓋率不夠，測試的時間不夠等等。面對這些問題，自動化測試自然而然地成為解決這些問題的首選方法。但是自動化測試真的就是銀彈麼?不見得!以前曾經在ASP.NET QA 的博客中給他們留言，請教過關于自動化測試的事情，我記得其中有一個回復是說，在某個release中過度地使用自動化測試，一切東西都想實現自動化測試，而忽略了產品本身的功能、特性的關注，結果就是超高的自動化測試覆蓋率，但是很差的產品質量。大家都去實現自動化測試了，誰來做功能點的覆蓋呢?某些領域的專家(SME)，他們可能對測試技術是一無所知的，要把這些領域專家和測試實施結合起來，DSL就是一個比較好的橋梁。 我在工作中遇到的問題是，我需要測試一個類似UV(獨立用戶訪問數)統計的系統，統計UV的方法其實就是根據_uid cookie的值來判斷這個用戶在某段時間內訪問過我們的系統多少次，訪問了哪些站點，進行了什么樣的行為。其中有2個地方比較麻煩，第一就是在測試過程中要不斷地拷貝cookie，這樣拷來拷去兩三次以后很容易就混亂，出錯;第二就是需要記錄訪問哪些站點，這些站點都只是ID，也是需要不斷地修改請求，測試時間長了也是很容易出錯。所以我就打算在原來的測試工具基礎上，實現一個簡單的Internal DSL。先看成品： @tc def uniq_inventory_case01(): test= testTool() test.user(’a').view(’asset55100002′).anetwork(’55100′).onsite(’site55100503′).snetwork(’55100′).dnetwork(’55100′).times(1).go() test.user(’b').view(’asset55100002′).anetwork(’55100′).onsite(’site55100503′).snetwork(’55100′).dnetwork(’55100′).times(2).go() test.user(’b').view(’asset55100002′).anetwork(’55100′).onsite(’site55100504_noad’).snetwork(’55100′).dnetwork(’55100′).times(4).go() 實例化一個testTool對象，然后就是指定哪個用戶：user(‘a’)或者user(‘b’)，看的視頻的ID：view(‘asset55100002′)，這個視頻屬于哪個CRO呢?anetwork(’55100′);放在哪個網站呢?onsite(‘site55100503′);網站是誰的呢?snetwork(’55100′);誰是分發者呢?dnetwork(’55100′);看了多少次呢?times(4);最后一個有點兒丑陋的go()。 像這樣子一句話里面N個方法連著用，就叫Method Chaining，Method Chaining通�？梢宰尨a變得更加人性化，讀起來更加容易。但是使用Method Chaining通常會遇到一個問題，就是很難判斷就是到了哪個方法才是終結呢?是不是有些方法的調用是可選的，有些是必選的呢?其中一個解決方法就是我用到的，放一個.go()方法在最后，作為終結方法。要實現Method Chaining，其實只需要頂一個類，對于需要做連接的方法，最后都返回這個類的實例。例如： def view(self, assetid): if assetid: self.asset_id = assetid return self def anetwork(self, networkid): if [...]
Tags: DSL, python, 自動化測試
自動化測試中的sleep
三.16, 2009 in 自動化測試 2 Comments
最近在修改公司現有的一個自動化測試框架，里面用了很多time.sleep()方法，看著不是很爽，為什么我覺得sleep方法在自動化測試中不應該過多的使用呢，我甚至覺得應該盡可能避免sleep方法的使用，sleep可以作為增加自動化測試穩定性的手段，但是不能依賴sleep來讓自動化系統穩定。 舉個例子，如果一個UI的自動化測試，需要等待某個頁面load完成以后才進行操作，那么需要對那個頁面是否已經Load完成進行判斷，而不應該sleep(x)，x是一個magic number，有時候1、2秒就足以，有時候它卻不知道有多大，因為已經超時了!那如果我們在check頁面狀態之前做一個短時間的sleep，那么在某些場合下可以增加這個自動化測試的穩定性，但是最終整個自動化測試的腳本是不會依賴于這個sleep的語句來達到穩定的。 在做自動化測試的時候，最常見的兩種判斷就是1. 某程序已經成功啟動，某頁面已經加載完畢。 2. 某程序已經正常關閉，某服務已經順利停止。 回到實際的工作，我要判斷被測的程序是否已經正常啟動，可以用系統提供的一些工具，或者調用一些接口，例如SNMP命令，或者是調用一下Lua腳本等，如果他們都返回我們期望的數據，那么可以認為程序已經成功啟動了。反之，如果前面的這些命令出錯了，那么我也可以認為程序已經是關閉了的。 要實現自動化測試，就必須要讓測試代碼每時每刻都掌握著被測系統的狀態，sleep方法會讓自動化測試腳本的行為變得詭異。
Tags: 自動化測試
四.26, 2009 in .NET, 自動化測試 Leave a Comment
自己動手創建Web測試驗證規則 ”Web測試”是由一系列 HTTP 請求組成，通過發出 HTTP 請求在協議層工作的測試類型。在VSTS中自帶了若干個預先定義好的驗證規則，例如在返回的頁面上尋找某些字符，返回的文檔中是否包含某些Tag，等等。前一段時間在測試一個安全過濾器，這個過濾器的基本功能就是過濾用戶輸入中的一些有可能構成安全隱患的內容，例如
文章來源于領測軟件測試網 http://www.kjueaiud.com/
