自動化測試應該如何開展呢?當時在論壇上回復了一下，現在放到博客，稍微調整一下。 首先，敏捷開發并不是部分同學想象中的那樣，沒有文檔沒有需求，開發來了就干，干幾個月就丟給客戶一個版本讓他們用去。我們公司一般6個星期是一個release周期，在這6個星期里面，可以做的事情是非常多的。 需求，需求通常來自于PM，在一個release周期的開始，QA通常沒太多事情需要做，比較輕松，這個時候一個比較重要的工作就是跟PM溝通當前release里面的一些feature的情況。在這個時候，QA可以做一些自動化測試的準備。例如在某個release周期里，我知道在接下來的測試當中我需要頻繁地比較CSV文件，那么作為QA就應該在項目還不是很緊張的時候，就開始準備自動化測試的腳本，例如剛才說的這個CSV文件比較工作。 開始開發，如果公司是實時TDD開發，那么這個時候QA可以做的事情大概有2個，幫助開發寫單元測試用例，并且實施自動化測試(主要是單元測試)，另一個是review(雖然不是自動化測試的內容)。如果不是采用TDD開發，那么QA做的事情跟上一個階段的做的差不多。 正式提交測試，OK，這個時候是我們QA比較忙的時候，有可能出現幾個情況，1. 跟我的預想一樣，我真的需要一個CSV文件比較工作，并且只需要這一個工具，并且我已經完成了，那么就可以進行測試了。2. 可能有一些新的自動化測試需求跑出來了，例如每天晚上自動比較幾萬個CSV文件并且把測試結果發給相關的人，這時候作為QA，在考慮資源允許的情況下，應該盡早完成這個工具，而不是每天晚上爬起來看結果。 發布完畢以后，回過頭來看工具，是否有值得改進的地方，是否能夠改進一下就能夠給整個Team使用。 以上算是一個release周期里面的一些微觀的工作，宏觀上來說需要做點什么事情呢? 現在提到的敏捷開發，都有一個很突出的特點，就是產品快速交付給客戶，為了快速交付這個目的，公司里面每個團隊都作出了努力，那么具體到QA團隊，肯定就是要在保持測試質量得到保證的前提下，盡可能地縮減測試所需要的時間，使得產品按時按質交付。要達到這個目的，總靠一些AD-HOC的工作(例如剛才提到的突然寫個CSV比較工具)是不可能達到要求的，那應該如何進行呢? 敏捷開發也是開發，產品不是孫悟空，不會某一天就從石頭里面爆出來了。在產品開發的前期(例如0.1, 0.2版本之類)，盡可能地想辦法搭建一個自動化回歸測試的框架，這個框架的特點有：1. 快速完成回歸測試; 2.能夠快速地添加測試用例并且跑起來;3.能夠隨著產品的演化而不斷改進(不能是那種用1~2個release就要扔的東西);4.維護的成本要低(在一個release周期里面如果自動化測試需求有變化，不應該需要超過1個星期的時間才能改好，當然翻天覆地的變化除外) 綜上所述， 我認為在敏捷開發里面的自動化測試是有2條路線，并且這2條路是并行的，缺一不可 至少一個自動化回歸測試框架，保證release前能夠對產品進行覆蓋較為全面的回歸測試 工作中*不斷地*開發自動化測試工具，提高自己的生產率 以上兩點的目的很簡單，就是要在保持產品質量處于一個較高水平的情況下，幫助公司盡可能地快速交付新版本的產品。 Tags: 敏捷測試, 自動化測試
一.29, 2010 in 自動化測試, 軟件測試 4 Comments
內部自動化測試交流有感 上周公司組織了一個交流會，主題是關于自動化測試，這個已經在公司引起高層們足夠重視的話題，說是交流會，其實我更覺得是個成果展示會，本人代表CORE QA跟大家分享了一下我們組內自動化測試的一些情況，并且在做的過程中的一些經驗。我是第一個，下面是VI的自動化測試，VI主要是跟Video播放器結合的比較緊密，最后是UI同事的介紹。我從頭到尾都參與，所以說說的我感受吧。 CORE這邊測試的特點就是，針對MRM系統的后臺進行測試，肩帶來說就是模擬各種跟后臺打交道的“程序”的工作，進行測試。我們測試有以下特點： 直接跟后臺程序交互，基本沒有現成的開源或者商業工具可以支持自動化測試快速開展 測試驗證結果大多數是后臺的輸入，也就是前臺或者是第三方系統的輸入，所以驗證的方法不能簡單地觀察輸出結果，同時需要知道后臺的輸出拿到別的系統能否正常工作 牽涉到數據遷移或者數據重處理的時候，QA需要直接讀取生產環境的數據進行校驗 由于以上特點，所以我們的自動化測試85%都是自己開發工具來做，常用的腳本語言是Python，經常用到的一些模塊包括讀取MySQL的MySQLdb;csv模塊;re模塊;總得原則就是把重復性強，容易引入錯誤的工作都寫成小工具。并且盡可能使用已有的成熟的庫，而不是自己重復發明輪子。例如我們的前端頁面使用了web.py輕量級框架，JSON庫。到目前為止，我自己感覺我們的自動化測試還是做的不錯的，主要是以下幾點 簡單。說起自動化測試，可能有部分人，或者說是外行的人吧，都覺得這個東西非�？�，人只要倒杯咖啡看著電腦執行測試就好了。但是其實實用有效的自動化測試并不是說看起來有多酷，而是這個東西能把人從重復勞動中解放出來。 強大。我剛到公司的時候，已經有600多個回歸測試跑在自動化框架上，我當時就覺得已經挺不錯的，因為這個自動化測試是由大概4~5個不同的人做的，我以前在MySpace的時候SOA大概有300個CASE，不過那都是我一個人做的，相比較而言FreeWheel應該是更好。 持續改進。雖然我剛到公司的時候自動化測試已經存在并且也算是行之有效，但是任何系統都是有可改進的空間的，我把前端UI改了一下，很高興可以幫助大家縮短了找問題的時間 全面�；旧纤械哪K都有自己的一堆自動化測試工具。 引用一句我非常喜歡的英語：So far so good。那下面我想做什么事情呢? 自動化測試其實不是測試，只是重復運行測試用例而已。真正的測試用的是腦，而不是工具，工具只是輔助我們的工作的 自動化測試是危險的，不要看到所有回歸測試都通過了，就高枕無憂 手動測試才是根本 希望能給大家灌輸一些思想，如果發現自己在重復做一件事情，那么應該停下來，想想有什么辦法能夠讓自己停止重復，盡可能自己解決問題，培養自己的動手能力 看看有沒有一些開源工作能讓現在的工作做的更加好 下面說說對VI TEAM自動化測試介紹的一點感覺吧，VI和CORE有點兒相似，就是都是用的自己開發的自動化工具，而沒用應用了太多開源工具，我個人覺得這里面原因有2個 VI的測試面向Video播放器的SDK，也是一個后臺，所以也沒有太多現成的工具 用戶怎么用我們的SDK?就是調用接口，跟CORE面對的問題相似 估計由于經常跟XML打交道，所以VI的自動化測試用到很多XML文件作為配置。由于隔行如隔山，所以沒有看懂里面的一些玄機，總的來說就是跟我們CORE有點相似。 我們CORE和VI一樣，這些工具如果跳出了這個公司，基本上就不能應用到其他地方，這也是對整個系統來說的底層部分做自動化測試的特點：高度定制化，通用性低，自己開發居多 最后就是UI的介紹，終于等到一個看得懂的啦。 UI那邊就是大量使用開源工具，這個也是很有道理的 UI的自動化測試實施難度比后臺程序的自動化要大 現有的UI自動化測試非常豐富 那我們的UI是怎么做的呢?首先UI的同事用了一個持續集成的工具hudson作為一個顆粒度比較粗的測試用例管理工具，hudson作為自動化測試的主心骨，QA們可以在hudson上觸發自動化測試的運行，運行完了以后可以看到測試結果，并且，利用了hudson的分布式結構，由多個測試機來執行測試，達到了很好的資源調配。對瀏覽器的控制方面，用了Selenium，會上沒有問UI是否利用了Selenium的多瀏覽器支持，從演示上來看應該只做的Firefox的。他們的分工很明確，分了專門做功能測試的QA和專門做自動化測試工具開發的SDET，SDET主要是負責寫RUBY代碼，封裝并且暴露了一些通用的方法給QA使用，并且同時使用了Cucumber作為一個DSL，QA是用Cucumber來做自動化測試的一些描述，Cucumber的作用就是對功能測試的QA屏蔽了底層RUBY腳本，對上就是“翻譯”功能測試QA的意圖，“翻譯”成RUBY。說一下我覺得的優點： 分開了自動化測試工具開發和自動化測試實施 使用了大量開源工具，提高效率 而且都是業界常用工具，對以后跳槽幫助不小(嘿嘿) One click automation (只需要點一下hudson) 一些工具帶來的制約 一次只能運行一批測試，不能重跑單個測試 個人覺得使用XPATH作為對象的識別并不是一個好的選擇 總得來說大家都各有特色，并且都做得挺好，并且都有不少可以提高的空間。多點交流的確能帶來不少靈感。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
