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