週末參加了testage(測試時代:
)組織的乙個專家討論會。主要討論測試自動化。說是專家討論會，我參加實在是慚愧，我對測試的理解實在是太淺薄了。只是因為在部落格上發表了一些謬論才收到邀請。想著可以幫助公司去接受一些新的思想，而自己也可以結識一些朋友，便去了。
對於測試時代的會議組織，我以為定位和思路還是非常準確的。只不過個人感覺會議組織可以更好一點。就當我對他的熱情反饋吧。可惜沒有當面說出來。
交流會來了很多公司的朋友。但是主講的人是用友的google的兩位朋友。他們說的主題都是關於**的自動化測試。其中用友用的是rft（rational functional tester），goolge用的是開源工具selenium
。
但最大的相同點還是在於google的朋友胡坤說的，自動化測試需要開發人員的加入。而用友的朋友也表明他們公司有乙個開發團隊在後面支援著rft的框架開發。我們公司碰巧也在這樣走，所以突然有一種強烈的認同感：自動化測試正在召喚優秀開發人員的加入。
微軟在這方面也早就走在了前頭。我有一位在微軟的同學yelz，所以在這方面有些許了解。他本人就曾經擔任過微軟的軟體測試開發工程師。當然不用說了，他本人是一位非常優秀的開發工程師。
這個從事理上講是顯然的：
自動化測試從根本上說，就是在構建乙個系統，這個系統能夠run另乙個系統。那麼，軟體開發幾乎是不可避免的。只不過有些框架可以做的好，能夠解決了一部分問題。
很多公司的測試人員，在軟體開發方面並不擅長。因此往往會有遇難而退的問題，致使自動化測試遲遲不能大面積應用起來。
很多行業軟體公司，對於測試的要求，往往是從專業上，而非軟體技術上的，成長路線比較狹隘。
管理層有可能比較短視，不願意投入開發力量。
並且開發和測試往往是兩個部門，互相之間不容易調配資源。
以上這些原因，最終導致了自動化需要開發，但卻得不到開發的現象。所以，測試部門一年一年地提出要做好自動化，卻又一年又一年地過去。
最終將希望寄託在市面上的軟體發展上。所以，沒出乙個新的自動化測試工具，大家都會非常熱鬧地去學習。這也說明了這塊市場的存在價值及發展空間。呵呵，想想我們公司的框架如果拿出去賣，還是有可能的。
分析出問題，就更加肯定了乙個事實：自動化測試是乙個組織問題，而不僅僅是乙個技術問題。公司要做好自動化，必須意識到這點，否則困難太大。畢竟，喜歡測試的開發，太少了。
自動化測試框架
可設計為五層 一 測試用例層 主要存放用例的指令碼，分為主指令碼和子指令碼。主指令碼用來控制各個子指令碼，實現指令碼間的資料傳遞。子指令碼是實現各個功能點的指令碼，同時也會提取出一些共用的方法，一般放在提取層中。主指令碼中可使用資料驅動來控制指令碼實現各種場景的流程，如silktest的test s...
自動化測試 web自動化測試
自動化 由機器裝置代替人為完成制定目標的過程 優點 提高工作效率 減少勞動力 產品規格同一標準 批量生產 自動化測試 讓程式代替人為去驗證程式功能的過程，即在預設條件下執行程式系統 流程確定 搭建自動化框架 編寫測試用例，將其轉化為soupui 介面 自動化測試指令碼 執行自動化測試指令碼 輸出執行...
測試自動化 自動化測試的定義
相關術語 automated testing test tool,automated testing test suite,automated testing test script等.具體參見 http en.wikipedia.org wiki test automation 推薦書籍 1 軟體...