測試是軟件製造過程中很重要的一個環節,
很多NB的廠家爲了宣傳自己的質量或者效率或者技術,都喜歡鼓吹自動化測試.
啥是自動化?
啥能自動化?
爲啥要自動化?
啥時候不要自動化?
很多傢伙沒考慮清楚這幾個問題就走向了大規模分佈式雲自動化測試的不歸路.
目前IT業產品無非分爲:
1.c/s產品,以windows平臺爲主,unix系列和手機平臺佔少數
2.b/s產品,以ie和firefox爲主,chrome和safari佔少數
我就說說這兩種產品類型的自動化測試.
1.啥是自動化?
這篇文章針對的自動化是指模擬手工測試人員的動作和指令,
對測試行爲的記錄和回放.
這個測試要和單元測試,接口測試甚至性能測試區分開來.
這是功能測試的自動化,不是代碼和接口級別的,這兩種很容易自動去跑測試任務,
更不是性能測試,性能測試不太需要自動化,那個需要有人認真的冷靜的觀察,自動化了反而不好.
2.啥能自動化?
a.c/s產品:
用過qtp麼?用過autoit麼?用過ahk麼?
知道窗體,知道控件,知道消息麼?
如果都有了解,那就大概能知道什麼東西可以自動化測試了.
上面說過,自動化測試主要是模擬功能測試人員的行爲,
從程序上實現這種行爲就是:
識別控件,發送消息,監聽事件,判斷結果.
其中最難的是識別控件,不是說技術上難,所有的技術都是簡單的!
是有的控件就是不能識別,你又有什麼辦法?
MS很人性化,他的sdk很多很多控件幾乎都可以識別,
而如果你們自己公司的一款c/s產品的控件無法識別,那你就要思考你們公司和MS的差距了,
爲啥自己寫的控件無法識別?
因爲你們的規範太差,或者不夠人性,或者就根本不考慮可測試性,
在程序上來說就是沒有實現: IAccessible接口!
這個接口是幹嘛的?如果不知道,你需要去了解一下MSAA(Microsoft Active Accessibility)
如果沒有實現這個標準的接口,當然就很難用QTP或者AutoIT這種常規的測試工具去測試了(開發時留了鉤子的除外),
也就是說這個產品從設計的時候就沒有考慮到自動化測試的可測性,那還做個屁的自動化?
如果決定要對一個產品做自動化測試,那請在設計的時候就考慮周全,
不要爲了節省開發人員的工時而不實現IAccessible接口,
卻要求測試人員能夠做自動化的測試.
我經常聽到不專業的傢伙說,我們要對這個或那個產品做自動化測試,但哥哥,你能不能先考慮一下這玩意到底能不能做自動化測試啊?
b.b/s產品,
知道watir或者watix麼?知道selenium嗎?甚至知道LoadRunner也行啊,道理都是相通.
再不行,知道如何attach一個瀏覽器進程,然後獲得它的JavaScript引擎的console麼?
如果知道這些,那也就瞭解一個b/s產品做自動化測試的大概原理了.
b/s做自動化測試比c/s更通用點,因爲瀏覽器上的按鈕都比較好識別,
工具以watir爲例,
Watir的IE對象是通過WIN32OLE獲得InternetExplorer.Application這個Windows系統對象,通過起內置的各種方法比如打開一個頁面,訪問一個url,就可以控制瀏覽器的行爲.而InternetExplorer.Application是怎麼對一個頁面操作的,這個我不清楚,只知道它提供這些接口,而Watir又包了一層接口給使用者.
再看一下FireWatir的FireFox對象,它和IE對象不同, FireFox對象不是通過WIN32OLE方法得到系統瀏覽器對象的,而是通過在FireFox瀏覽器上安裝jssh的插件,獲得瀏覽器的JavaScript引擎的訪問權,從而通過當前運行頁面的JavaScript來控制頁面動作的.
從FireFox發散出去,我猜InternetExplorer.Application對外開放的接口也可能就是通過InternetExplorer.Application封裝了它的JavaScript引擎來實現的.
我們知道了b/s產品自動化執行的原理後,我們就可以知道,只要JavaScript能處理的動作,我們都可以通過自動化來模擬.
但PM或者要求測試進行自動化的人,他一定要知道哪些是JavaScript做不來的,
比如Flash,比如SilverLight,這些產品目前還沒有直接開放對象的接口給JavaScript,這就不能做自動化測試.
3.爲啥要自動化測試?
這個問題很簡單,因爲要提高效率,降低出錯率,減少重複勞動,降低成本.
提高效率:代碼執行測試比人工執行更快.
降低出錯率:計算機的行爲比人類的行爲更單一,多次執行很少會出現不同的結果.
減少重複勞動:自動化測試主要是迴歸測試,就是將以往主要的測試腳本或者叫回歸測試腳本跑一邊,員工對重複勞動是沒有興趣的,而計算機不會有抵觸情緒.
降低成本:自動化測試的時間可以在員工下班之後,而如果要求員工在下班後還工作那是不人性不和諧的.
4.啥時候不要自動化?
有的東西可測試有的東西不可測試,把不可測試變成可測試是需要成本的,
自動化測試的代碼更多的依賴於界面的UI和文案,而UI和文案是多變的,所以維護自動化測試的代碼也是需要成本的,
如果我們把一個手工測試人員當作一個進程(因爲一臺電腦上的b/s或者c/s產品正常的時候只會有一個用戶在使用),但自動化測試要求更快更高效率的時候,會希望自動化測試用例能夠併發進行,也就是同時需要多臺自動化測試的客戶端,這些客戶端是需要調度和管理的,這就還需要一個管理平臺,同時負責測試環境的維護,開發代碼的及時更新與部署,以及自動化測試數據的自動生成,這些也都要成本的.
而自動化測試帶來的收益是否會大於這個成本是需要好好考慮的,甚至是需要找一兩個項目去實踐的.
就我個人來看,一箇中小公司,人肉測試的成本要小於自動化測試的成本.尤其是在這個小行業還沒有被重視和深入挖掘的現在.
我瞭解過一些很大的公司的一些自動化測試框架,
這些東西聽起來真得很嚇人,但如果你自己問下去,他們說不出個所以然,
其中絕大多數都是用了這個東東那個東東,然後整體包裝一下,
底層實現的細節他們都不瞭解,並沒有掌握核心技術,
只掌握工具的使用是膚淺的,正應了那句話"無他,唯手熟耳"
很多NB的廠家爲了宣傳自己的質量或者效率或者技術,都喜歡鼓吹自動化測試.
啥是自動化?
啥能自動化?
爲啥要自動化?
啥時候不要自動化?
很多傢伙沒考慮清楚這幾個問題就走向了大規模分佈式雲自動化測試的不歸路.
目前IT業產品無非分爲:
1.c/s產品,以windows平臺爲主,unix系列和手機平臺佔少數
2.b/s產品,以ie和firefox爲主,chrome和safari佔少數
我就說說這兩種產品類型的自動化測試.
1.啥是自動化?
這篇文章針對的自動化是指模擬手工測試人員的動作和指令,
對測試行爲的記錄和回放.
這個測試要和單元測試,接口測試甚至性能測試區分開來.
這是功能測試的自動化,不是代碼和接口級別的,這兩種很容易自動去跑測試任務,
更不是性能測試,性能測試不太需要自動化,那個需要有人認真的冷靜的觀察,自動化了反而不好.
2.啥能自動化?
a.c/s產品:
用過qtp麼?用過autoit麼?用過ahk麼?
知道窗體,知道控件,知道消息麼?
如果都有了解,那就大概能知道什麼東西可以自動化測試了.
上面說過,自動化測試主要是模擬功能測試人員的行爲,
從程序上實現這種行爲就是:
識別控件,發送消息,監聽事件,判斷結果.
其中最難的是識別控件,不是說技術上難,所有的技術都是簡單的!
是有的控件就是不能識別,你又有什麼辦法?
MS很人性化,他的sdk很多很多控件幾乎都可以識別,
而如果你們自己公司的一款c/s產品的控件無法識別,那你就要思考你們公司和MS的差距了,
爲啥自己寫的控件無法識別?
因爲你們的規範太差,或者不夠人性,或者就根本不考慮可測試性,
在程序上來說就是沒有實現: IAccessible接口!
這個接口是幹嘛的?如果不知道,你需要去了解一下MSAA(Microsoft Active Accessibility)
如果沒有實現這個標準的接口,當然就很難用QTP或者AutoIT這種常規的測試工具去測試了(開發時留了鉤子的除外),
也就是說這個產品從設計的時候就沒有考慮到自動化測試的可測性,那還做個屁的自動化?
如果決定要對一個產品做自動化測試,那請在設計的時候就考慮周全,
不要爲了節省開發人員的工時而不實現IAccessible接口,
卻要求測試人員能夠做自動化的測試.
我經常聽到不專業的傢伙說,我們要對這個或那個產品做自動化測試,但哥哥,你能不能先考慮一下這玩意到底能不能做自動化測試啊?
b.b/s產品,
知道watir或者watix麼?知道selenium嗎?甚至知道LoadRunner也行啊,道理都是相通.
再不行,知道如何attach一個瀏覽器進程,然後獲得它的JavaScript引擎的console麼?
如果知道這些,那也就瞭解一個b/s產品做自動化測試的大概原理了.
b/s做自動化測試比c/s更通用點,因爲瀏覽器上的按鈕都比較好識別,
工具以watir爲例,
Watir的IE對象是通過WIN32OLE獲得InternetExplorer.Application這個Windows系統對象,通過起內置的各種方法比如打開一個頁面,訪問一個url,就可以控制瀏覽器的行爲.而InternetExplorer.Application是怎麼對一個頁面操作的,這個我不清楚,只知道它提供這些接口,而Watir又包了一層接口給使用者.
再看一下FireWatir的FireFox對象,它和IE對象不同, FireFox對象不是通過WIN32OLE方法得到系統瀏覽器對象的,而是通過在FireFox瀏覽器上安裝jssh的插件,獲得瀏覽器的JavaScript引擎的訪問權,從而通過當前運行頁面的JavaScript來控制頁面動作的.
從FireFox發散出去,我猜InternetExplorer.Application對外開放的接口也可能就是通過InternetExplorer.Application封裝了它的JavaScript引擎來實現的.
我們知道了b/s產品自動化執行的原理後,我們就可以知道,只要JavaScript能處理的動作,我們都可以通過自動化來模擬.
但PM或者要求測試進行自動化的人,他一定要知道哪些是JavaScript做不來的,
比如Flash,比如SilverLight,這些產品目前還沒有直接開放對象的接口給JavaScript,這就不能做自動化測試.
3.爲啥要自動化測試?
這個問題很簡單,因爲要提高效率,降低出錯率,減少重複勞動,降低成本.
提高效率:代碼執行測試比人工執行更快.
降低出錯率:計算機的行爲比人類的行爲更單一,多次執行很少會出現不同的結果.
減少重複勞動:自動化測試主要是迴歸測試,就是將以往主要的測試腳本或者叫回歸測試腳本跑一邊,員工對重複勞動是沒有興趣的,而計算機不會有抵觸情緒.
降低成本:自動化測試的時間可以在員工下班之後,而如果要求員工在下班後還工作那是不人性不和諧的.
4.啥時候不要自動化?
有的東西可測試有的東西不可測試,把不可測試變成可測試是需要成本的,
自動化測試的代碼更多的依賴於界面的UI和文案,而UI和文案是多變的,所以維護自動化測試的代碼也是需要成本的,
如果我們把一個手工測試人員當作一個進程(因爲一臺電腦上的b/s或者c/s產品正常的時候只會有一個用戶在使用),但自動化測試要求更快更高效率的時候,會希望自動化測試用例能夠併發進行,也就是同時需要多臺自動化測試的客戶端,這些客戶端是需要調度和管理的,這就還需要一個管理平臺,同時負責測試環境的維護,開發代碼的及時更新與部署,以及自動化測試數據的自動生成,這些也都要成本的.
而自動化測試帶來的收益是否會大於這個成本是需要好好考慮的,甚至是需要找一兩個項目去實踐的.
就我個人來看,一箇中小公司,人肉測試的成本要小於自動化測試的成本.尤其是在這個小行業還沒有被重視和深入挖掘的現在.
我瞭解過一些很大的公司的一些自動化測試框架,
這些東西聽起來真得很嚇人,但如果你自己問下去,他們說不出個所以然,
其中絕大多數都是用了這個東東那個東東,然後整體包裝一下,
底層實現的細節他們都不瞭解,並沒有掌握核心技術,
只掌握工具的使用是膚淺的,正應了那句話"無他,唯手熟耳"
