軟件測試自動化測試淺談 自動化測試工具
本文為本人個人結合自己在公司中的實踐情況談的一些感想，歡迎討論，但不想理論。哎，實在是本人理論功底不好，而且懶于辯論。從初中開始，語文就沒很好過- -！
自動化測試從廣義上來說包括自動化功能測試、自動化性能測試、自動化安全測試、自動化單元測試等等。而我們日常常說的自動化測試一般是指自動化功能測試，本文主要也是從自動化功能測試角度考慮。
【正文】
說起自動化測試的強大，很多人起先的了解來自于測試論壇或者說來自于自動化測試工具廠商對工具的介紹。咱們先來看一段我因為需要而寫的一段有關自動化測試的描述（不代表本人真實想法，這是因為有需要才為之的）：
自動化測試就是通過模擬手動測試步驟，執行用某種程序設計語言編制的測試程序，控制被測軟件的執行，完成全自動或半自動測試的過程。自動化測試解決了功能測試不僅耗時且高成本的問題。采用自動化測試，企業可以將重點放在改進自動業務過程方面。開發和QA組可以增加測試過程的速度和精確度。整個IT部門可以獲得更高的投資回報，而且降低了大量風險。
這段話，個人感覺或許對于像微軟這些大公司而言是對的，但就目前中國軟件企業現狀來說，自動化測試是不是像這段話說的這樣真的很難說。單不說我們的定制項目戰略與大公司的通用產品戰略的差距，就我們公司的質量意識也能使這段話失效。就說以下這點，進行了程序修改后，需要對程序進行比較全面的測試這點，我們的很多公司就不做。原因很簡單，上級認為這沒有必要、而且是浪費時間，另一點，定制項目的利潤可比通用產品少得多得多，哪有那么多錢讓我們認真測試呢。而定制項目好像還是我們的主流。
對于自動化測試，有這么一句總結的定義“利用程序測試程序”。這句話很簡練吧，自動化測試歸根到底也確實是這么個味道。利用工具、利用軟件、利用小腳本等等都可以進行自動化測試。本人一直認為自動化測試是一種技術，是一種能力。既然是一種技術，那就不應該用太固定的框框把它限死了。應該是做到隨需所用、依需而定。既然是一種能力，就應該用發散的思維去發揮它更多更大的作用。就像閱讀這個能力，誰說一定要先劃定中心思想，誰說一定要精讀，更沒人說一定要用三遍閱讀法哦。閱讀當然得根據讀者的目的以及所讀文章的特點，甚至是讀者的水平來確定讀此文章的方法。自動化測試也一樣，不一定要用在回歸測試上，也不一定要用在集成測試上。有時甚至可以寫個小腳本用在解決功能人員測試難的小問題上。這不也是很好的自動化測試嘛。
關于自動化測試工具，廠商說的可以說基本不可信。說什么“錄制/回放”就可以實現，“簡單得很”。要真相信這個，那你自動化測試的失敗也會“快得很”。當然，微軟所吹噓的，要自己編程序來進行自動化測試，而不應該想著使用自動化測試工具來實現自動化測試。這個觀點對于微軟來說，應該是正確的。但是得看看微軟什么現狀：就微軟的產品，有哪個自動化測試工具能支持得了全自動化測試的？再說了，微軟的產品是全世界在賣，那質量要求高，而且利潤更高，有的是錢請牛人來編寫自動化測試程序。而且微軟的人才也是我們這些公司不可企盼的。因此，如果有好的工具，甚至小工具或開源工具，只要能更好的解決公司中的問題，那何樂而不為呢？
可以毫不客氣的說，想要進行自動化測試，那還真得會編碼。就拿易用性方面名聲不錯的QTP來說，要是不會編寫VBScript腳本，要是不會綜合應用QTP內置的對象和函數，要是不了解QTP支持的擴展，那么就是對QTP這個工具沒有很深入的了解，那么如何做到能靈活應用呢。要是真碰到特殊問題，那很容易就GameOver了。我曾經拿幾個自動化測試工具（如QTP9.2版、RFT7.1版、TestComplete5.0版）試了試一些基本的標準html頁面的功能。有的沒法完全回放成功，而如果要進行一些特殊的判斷或處理，那“錄制”基本就不可能了。而且，即使錄制的都能成功回放，那能說明這就實現了自動化測試嘛？自動化測試重點還是在測試，要實現的是測試的目的，而不是在于幾個工具的使用上。
自動化測試是一種技術、是一種能力，它不是綁定在某種工具上的。在實際的實踐中，發現一些自動化測試人員，在熟練掌握一個自動化測試工具后，非常的高興，而且有點炫耀的味道。于是乎，本人就問他：“你以為會這個工具，你就會自動化測試了嗎？你最多就算會這個工具，或精通這個工具，跟自動化測試無關�！保ū救苏f話較直，總喜歡實話實說- -�。�。這里要說的是，要注意自動化測試不是工具的必然。如果只是把自動化測試定位在一兩個工具上，那這個人到頭來可能會的不是自動化測試技術，而是工具。當然如果要直接從自動化測試技術入手，可能學起來會沒有感觀認識，而且進入那個自動化測試思維大門較難。因此，一般的學習和進階方法可以如下：找一個或兩個比較容易實現自動化測試的工具，進行深入的學習，并在項目中進行實踐，等有一定實踐經驗后，自然會有一定的認識的。而這時就需要自己的思維脫離這些自動化測試工具，進而思考自動化測試技術的方方面面。然后當然就是可以試用其他的測試工具（強調一下，不要以為只有測試工具才能用于自動化測試，其他工具也可以的，只要那個工具提供的功能滿足應用的需求，那就可以了），或自己編碼實現一個小型工具（自動化測試人員是需要編程技術的），或直接用腳本語言編寫執行程序等等。這時就是要根據要測試的內容能隨心所欲的應用自動化測試了。
接下來根據幾個網友的討論，談點有關自動化測試框架的認識吧。在開展自動化測試時，沒有必要去深究自動化測試框架到底是什么，要怎么定義。因為這個定義的話，估計還沒人敢說他有標準的定義。而且即使有標準的框架要求，那我根據公司的自動化測試需要，加入一些東西也是可以的嘛。在應用自動化測試框架方面，個人感覺還是不要跟風的好。有人總喜歡有什么好的框架或功能齊全的框架，就要拿來用。當然并不是說這些框架不好，也不是說不能用。只是說在用時，請考慮一下，自己目前用這些框架真的好嘛？如果剛開展自動化測試，就拿封裝度很高的框架來套上，這不僅會增加學習量（框架是要學習的），而且會使測試人員只對框架有概念，而對于原版的工具生疏，要真是碰到框架不好解決的問題，那到時就不好辦了。個人感覺，適用自己公司自動化測試要求的框架是比較好的框架。這個框架，可以是開源的，可以是自己開發的，甚至前期可以就幾個文件夾或者規范要求或者再加幾個共享文件、幾個通用腳本等等。
自動化測試也是需要比較完備的規范的，不僅需要腳本規范，也需要適用公司的自動化測試流程規范。只有有了腳本規范，才能使合作開發的腳本更像一個整體，使后期的腳本維護相對容易些。自動化測試流程規范是相當重要的。流程規范需要確定如何與手工測試人員交互，如何獲取需求，如何產生測試用例，如何開發自動化測試程序，如何使用自動化測試，如何分析結果等等。如果這些沒有確定好，很容易使自動化測試不流暢，甚至于“破產”。
公司中要實行自動化測試，上級領導和現有開發測試人員對質量的意識很重要。舉個碰到過的小例子：系統在發布前，按理應該要進行比較完備的回歸測試的。但目前的現狀就是只進行簡單跑跑看看。這對于手工測試來說，時間不太多。而如果用自動化測試來實現了比較完備的回歸測試，時間也不見得比手工測試少，因為手工測試沒有進行完備的回歸測試呀。在對這點的認識上，手工測試人員和上級認為自動化測試確實沒有節省時間，也沒有產生效益（因為發現的問題幾乎沒有）。后來我只問了一句：“難道你們認為在發布前也應該找出一堆BUG嗎？難道質量保證是沒有效益的嗎？”。在后來的自動化測試實現中，我當然是拒絕再為這種之前測試就不完備，而且還不被上級和手工測試人員所承認的功能實現自動化測試了。因為這很容易讓上級和手工測試人員感覺自動化測試也就這樣，還不如手工測試得了。久而久之，自動化測試基本就會被拋棄了。
文章來源于領測軟件測試網 http://www.kjueaiud.com/