如何自己開發軟體測試載入器？

標籤：

PS:這是我在網上看到的一篇文章，寫的挺好的，不光指的是測試載入器，對如何學習新的編程知識也有一定的啟發，希望和大家交流。^_^

如何自己開發軟體測試載入器？

序言：一說到自動化測試載入器，大家很多人都會想到的是QTP、LR或者selenium之類的工具，要大家一開始設計一個這樣的工具，其實確實很有難度，因為其包含的功能細節太過龐大。當年的我，開始設計開發工具的過程中，走了很多彎路，例如：做工具的介面技術的曆程，剛開始用tcl/tk指令碼語言，用tcl寫底層架構，用tk寫圖形介面，後來發現tk雖然構造圖形方便，但可拓展性實在太差。就開始學用java的swing寫介面，當時傻傻的從介面的布局，到介面的MVC架構，然後是各種圖形的資料結構都是自己一點一點寫出來的，但確實鍛煉了能力，後來就開始掌握一些現成的圖形架構，例如：java裡的RCP、python的WxPython和PyQT。到現在更喜歡的是簡單web架構，所以，現在將自己的工具開發之路簡單分享一下，希望過來人不要走我的彎路，這篇文章雖說是說工具開發之路，但更多的是是一種學習思路，而且這一段旅程還很漫長，我也繼續探索，也希望大家能得到一點啟示，互相學習。
　　一、自動化測試載入器淺析
　　在做自動化測試的這段日子裡，現在也單獨設計開發了一些公司對內和對外層級的工具，也設計開發過C/S和WEB方面的自動化測試平台，回首看來，從之前很簡陋的工具，到現在客戶應用層級的工具，真的頗覺時光飛逝。
1、介面自動化測試載入器，我們往往入門的時候都是用的商業或者開源的工具，例如：QTP、RFT之類，這些都是介面層級的自動化測試，介面自動化測試的有一定開發難度，但是確有不少的開源庫可以提供，你完全可以基於以上庫開發，或者有一些開源的工具很成熟了，你所做的就是基於以上進行一下更改。例如：測試java介面的工具就有aboot、swbot、mathron等開源工具，測試web介面的有selenium、watin等，測試移動端的有robotium、monkey等。要能二次開發這些工具，主要是需要理解抓取對象和回放的原理，然後是一些設定檔的處理，物件程式庫裡主要是XML的處理，一般錄製功能我覺得可以忽略。
2、白盒測試載入器，一些代碼層級的測試載入器，例如：對程式碼涵蓋範圍的分析、對代碼品質的分析等，這方面涉及較淺，就不隨便造次了。
3、介面自動化測試載入器，介面自動化測試載入器在開發的時候，首先需要明確業務介面類型，然後掌握一定的介面工具的應用方式，一般的介面工具都是會解析某種介面定義檔案，然後將介面檔案以介面的形式展現出來，可以通過對介面介面的操作：對某個介面填寫參數，然後發送到伺服器端，查看響應，或者直接get介面返回值。例如：SoapUI工具是針對WebService系統的測試，主要是解析WSDL介面定義檔案。Jmeter和LR也可以做介面測試載入器，例如：java介面和HTTP介面等。之前，開發過的介面工具包括：SNMP介面和corba介面工具，其原理也是解析mib和IOR介面定義檔案，然後可以對介面進行set與get操作。所以，開發這類的工具，一定要明確什麼是軟體介面、然後介面描述檔案是什麼，最後是如何去對介面進行操作，日誌和結果的展現等，還有一些就是額外的功能了，例如：錄製，將測試人員對介面的動作記錄下來，成為工作流程等。
4、效能自動化測試載入器，看到效能測試工具，大家很容易想到LR、Jmeter之類，這方面的工具，我用的較少，但是會基於自己公司內部的產品一些特殊效能情境方面的測試，會專門開發一些這樣的工具，例如：開發一個發送SNMP網路報文的工具，類比警示最大接收和並發效能，開發一個網元模擬器，能夠類比大量不同IP的網元，可以在公司網元管理器上測試同時管理的最大網元等。所以，效能測試首先要與業務情境相結合，然後掌握一定的效能基礎和指標，分析好相關的介面協議和需要類比的業務，就可以快速開發相應的工具了。
5、系統應用層級的自動化測試載入器，這種工具需要明確應用情境，即明確需求，例如：我之前開發一些部門內部工具集合，專門提供給測試人員進行指令碼錄製()、公司層級的有採集和巡檢工具。(對外支援)，這部分工具帶來的效益是很大的。所以說，千萬不要將自動化測試局限在測試方面，其實提高測試與開發的人員的效率、以及對公司產品的品質保障方面的工具都是能給公司帶來直接效益的。也許幾行代碼也是一個能提升效率的好的工具。
　　當然，還有很多方面的測試載入器，因瞭解有限，就無法一一列舉了，大家可以補充。
　　二、如何快速開發一個自動化測試載入器
1、定位自己，發現目標：首先要看，你是否對軟體開發感興趣，其實我們測試人員往往把開發看得太深，所以很容易就因為覺得困難而不敢開始，如果你對軟體確實有一些興趣，何嘗不試試，我們做的，不是要去開發一個多大的系統，我們的目標是能夠做提高我們工作效率的事情，讓我們的工作變得更高效、更有樂趣，學習知識的同時，還能帶來價值，何樂不為。
2、簡單開始，立即上手：首先，在工作中積極發現需求，需求不需要太大，有時候一個點即可，找到需求點後，你可以向領導提出來自己的想法，然後進行可行性分析和立項，另外，很多人都擔心因為不懂技術無法得到領導的認可，其實在首先最重要的是你的熱情和決心，然後自己平時簡單學一點入門知識就可以了，如果第一次嘗試開發一個工具，千萬不要一開始就把面鋪太大，很多時候，我們總會被漫天的資料給淹沒，天天在看書學習中渡過。我在公司帶著測試人員做自動化測試專案時，往往告訴他們的是，不用害怕，直接上手，不會了再反過來查詢資料或者諮詢別人，千萬不要一開始就拿著一本資料從頭學到尾，這是我們大學應試帶給我們的弊端，讓我們往往忽視了實踐中學習。當然，這是在有人帶的情況下，如果沒有人帶你，那麼你就找一個簡單的語言，開始從最簡單的實踐起，大學我不是學電腦專業的，當年工作是從tcl指令碼開始的，用tcl實現了簡單的線性測試指令碼、簡單的測試架構開發等等，當時我採取的策略就是明確需求，然後拿著教程，一點一點開始攻克，困難肯定是有的，挨過去就好了。
3、適合自己的流程才是好流程：我現在一般開發工具、平台都是採用流程為，需求分析+設計流程+設計模組+介面定義+開始開發，在開發中調整具體架構和細節。記得當年剛學到軟體建模的時候，很喜歡用UML來定義我的開發流程，結果後來發現，小型的系統和工具，採用這種方式其實更是浪費了時間，UML的主要好處是團隊溝通和互動，將系統抽象到大家都能理解的地步。所以，後來我明白了，不同的環境採用不同的流程，適合自己的開發流程才是好流程。
4、技術應用，步步深入：剛開始，不需要掌握多好的架構細節、多好的設計模式、多強的演算法、多好的分布式和並行，也許剛開始，只需要線性編程，一步一個腳印即可，也可以儘可能的使用一些現成的架構，不需要太專研到架構的細節中去，例如：RCP介面架構可以讓不用面對更少的介面布局的情況，讓你的工具介面和eclipse類似，或者C++的MFC足以讓你應對很多工具。當然，隨著後面的工具難度的加強，你需要開始積累自己的知識，例如：專門有一個自己的庫，包括收集和應用一些開源的庫，例如：作業調度庫、介面架構庫、持久層映射庫、日誌和結果處理庫等。還有一些自己的演算法和功能庫等。隨著後來，建議可以多看看web系統方面的東西，畢竟這是個趨勢。然後，多站在標準化和介面層次考慮問題。所以，我講究的是順其自然，踏踏實實，打好底層基礎，對待新技術和架構，少追風，多思考。這樣就會逐漸形成自己獨特見解。
5、抓准測試：一個工具開發過程中，你也需要進行版本管理和組態管理，你可以學會利用git和svn進行代碼管理，學會利用maven和ant進行build，學會在開發工具的同時也學會一些開發與測試自動化流程。而在測試過程中，因為開發的工具不是非常系統化，所以可以主要從功能點(按照需求列好功能點測試)、異常分析(例如：合法性測試、異常操作測試等)、相容性(之前寫的C/S工具，因作業系統不同會有一些問題，而B/S工具，會因為瀏覽器的問題，而出現一些展示方面的問題，所以需要明確應用和測試環境)
6、快速發布：千萬不要將工具做到很完美才想著發布，沒有什麼是完美，我們所做的就是利用迭代的思想，一步一步去完善。所以，定義好階段，快速發布，然後在發布中收集問題。畢
　　竟是內部使用，所以能夠及時反饋。

　　總結：不管測試也好，開發也好，大家都是為了提高效率，找到自己的價值感而努力，但是很多時候，我們往往有所想，而無所為，就是因為總是把很多事情想的太複雜或者太簡單，當然，這是我們每個人必須經曆的過程，而我覺得，我們需要做的就是尋找自己的樂趣，如果我們迷惑了，就應該果斷開始行動，只為相信我們做的事情是有價值的，積累的力量是很強悍的，在不知不覺中也許我們就挨過了很多困難，獲得了很多東西。另外，大家如果看到這篇文章，是否能夠也能留言分享一下各自在測試過程中自己開發和應用過的內部工具的想法和心得呢，或者說說自己的學習想法和迷惑吧，大家互相討論。

最後是我喜歡的一句話：

 How many times must a man look up before he can see the sky?   The answer, my friend, is blowing in the wind. 

如何自己開發軟體測試載入器？