什么是自動(dòng)化測用踩？
做測試好幾年了婉称，真正學(xué)習(xí)和實(shí)踐自動(dòng)化測試一年，自我感覺這一個(gè)年中收獲許多贤牛。一直想動(dòng)筆寫一篇文章分享自動(dòng)化測試實(shí)踐中的一些經(jīng)驗(yàn)惋鹅。終于決定花點(diǎn)時(shí)間來做這件事兒。
首先理清自動(dòng)化測試的概念殉簸，廣義上來講闰集，自動(dòng)化包括一切通過工具（程序）的方式來代替或輔助手工測試的行為都可以看做自動(dòng)化，包括性能測試工具（loadrunner般卑、jmeter）,或自己所寫的一段程序武鲁，用于生成1到100個(gè)測試數(shù)據(jù)。狹義上來講蝠检，通工具記錄或編寫腳本的方式模擬手工測試的過程沐鼠，通過回放或運(yùn)行腳本來執(zhí)行測試用例，從而代替人工對系統(tǒng)的功能進(jìn)行驗(yàn)證叹谁。
當(dāng)然饲梭，我們更普遍的認(rèn)識(shí)把“自動(dòng)化測試”看做“?基于產(chǎn)品或項(xiàng)目UI層的自動(dòng)化測試”。
分層的自動(dòng)化測試
這個(gè)概念最近曝光度比較高本慕，傳統(tǒng)的自動(dòng)化測試更關(guān)注的產(chǎn)品UI層的自動(dòng)化測試排拷，而分層的自動(dòng)化測試倡導(dǎo)產(chǎn)品的不同階段（層次）都需要自動(dòng)化測試。
相信測試同學(xué)對上面的金字塔并不陌生锅尘，這不就是對產(chǎn)品開發(fā)不同階段所對應(yīng)的測試么监氢！我們需要規(guī)范的來做單元測試同樣需要相應(yīng)的單元測試框架布蔗，如java的Junit、testNG浪腐，C#的NUnit纵揍，python的unittest、pytest等议街，幾乎所有的主流語言泽谨，都會(huì)有其對應(yīng)的單元測試框架。
集成特漩、接口測試對于不少測試新手來說不太容易理解吧雹，單元測試關(guān)注代碼的實(shí)現(xiàn)邏輯，例如一個(gè)if分支或一個(gè)for循環(huán)的實(shí)現(xiàn)涂身；那么集成雄卷、接口測試關(guān)注的一是個(gè)函數(shù)、類（方法）所提供的接口是否可靠蛤售。例如丁鹉，我定義一個(gè)add()函數(shù)用于計(jì)算兩個(gè)參數(shù)的結(jié)果并返回，那么我需要調(diào)用add()并傳參悴能，并比較返回值是否兩個(gè)參數(shù)相加揣钦。當(dāng)然，接口測試也可以是url的形式進(jìn)行傳遞漠酿。例如冯凹，我們通過get方式向服務(wù)器發(fā)送請求，那么我們發(fā)送的內(nèi)容做為URL的一部分傳遞到服務(wù)器端记靡。但比如Web?service?技術(shù)對外提供的一個(gè)公共接口谈竿，需要通過soapUI?等工具對其進(jìn)行測試。
UI層的自動(dòng)化測試摸吠，這個(gè)大家應(yīng)該再熟悉不過了空凸，大部分測試人員的大部分工作都是對UI層的功能進(jìn)行測試。例如呀洲，我們不斷重復(fù)的對一個(gè)表單提交，結(jié)果查詢等功能進(jìn)行測試啼止，我們可以通過相應(yīng)的自動(dòng)化測試工具來模擬這些操作道逗，從而解放重復(fù)的勞動(dòng)。UI層的自動(dòng)化測試工具非常多献烦，比較主流的是QTP滓窍，Robot?Framework、watir巩那、selenium等吏夯。
為什么要畫成一個(gè)金字塔形此蜈，則不是長方形?或倒三角形呢？?這是為了表示不同階段所投入自動(dòng)化測試的比例噪生。如果一個(gè)產(chǎn)品從沒有做單元測試與接口測試裆赵，只做UI層的自動(dòng)化測試是不科學(xué)的，從而很難從本質(zhì)上保證產(chǎn)品的質(zhì)量跺嗽。如果你妄圖實(shí)現(xiàn)全面的UI層的自動(dòng)化測試战授，那更是一個(gè)勞民傷財(cái)?shù)呐e動(dòng)，投入了大量人力時(shí)間桨嫁，最終獲得的收益可能會(huì)遠(yuǎn)遠(yuǎn)低于所支付的成本植兰。因?yàn)樵酵蠈樱渚S護(hù)成本越高瞧甩。尤其是UI層的元素會(huì)時(shí)常的發(fā)生改變钉跷。所以，我們應(yīng)該把更多的自動(dòng)化測試放在單元測試與接口測試階段進(jìn)行肚逸。
既然UI層的自動(dòng)化測試這么勞民傷財(cái)，那我們只做單元測試與接口測試好了彬坏。NO!因?yàn)椴还苁裁礃拥漠a(chǎn)品朦促，最終呈現(xiàn)給用戶的是UI層。所以栓始，測試人員應(yīng)該更多的精力放在UI層务冕。那么也正是因?yàn)闇y試人員在UI層投入大量的精力，所以幻赚，我們有必要通過自動(dòng)化的方式幫助我們“部分解放”重復(fù)的勞動(dòng)禀忆。
在自動(dòng)化測試中最怕的是變化，因?yàn)樽兓闹苯咏Y(jié)果就是導(dǎo)致測試用例的運(yùn)行失敗落恼，那么就需要對自動(dòng)化腳本進(jìn)行維護(hù)箩退；如何控制失敗，降低維護(hù)成本對自化的成敗至關(guān)重要佳谦。反過來講戴涝，一份永遠(yuǎn)都運(yùn)行成功的自動(dòng)化測試用例是沒有價(jià)值。
至于在金字塔中三種測試的比例要根據(jù)實(shí)際的項(xiàng)目需求來劃分钻蔑。在《google測試之道》一書啥刻，對于google產(chǎn)品，70%的投入為單元測試咪笑，20%為集成可帽、接口測試，10%為UI層的自動(dòng)化測試窗怒。
我為什么要做自動(dòng)化測試映跟？
根據(jù)51testing的《中國軟件測試從業(yè)人員調(diào)查報(bào)告》蓄拣，手工測試占到的89%?，相對開發(fā)來說申窘，測試的門檻底弯蚜，薪資普遍較底，所要求的知識(shí)面雖然有一定廣度剃法，但缺乏深度碎捺。這是測試的普遍現(xiàn)狀。
正因?yàn)槭止y試人門檻不高贷洲，使大量的畢業(yè)生收厨，甚至是非專業(yè)人員涌入這個(gè)行業(yè)。從而增加了這個(gè)行業(yè)的激烈競爭优构。對于工作幾年扔處于手工測試的人員來說都會(huì)有強(qiáng)列的危機(jī)感诵叁。由于工作的技術(shù)含量不高，薪資的漲幅遇到瓶頸钦椭，另一方面受到新進(jìn)入者的威脅拧额，同樣的工作公司花5K招來的人就可以做，那么就不會(huì)花8K的招彪腔。
好吧侥锦，這個(gè)問題不應(yīng)該出現(xiàn)討論技術(shù)的話題中，但他的確是大多測試人員不得不面對的一個(gè)問題德挣。所以恭垦，從測試人員自身的發(fā)展來說，我其實(shí)非常需要通過自動(dòng)化技術(shù)來增加自己有競爭力格嗅。當(dāng)然番挺，做到一定年限測試人員會(huì)選擇轉(zhuǎn)管理或其它崗位，這又是另一個(gè)話題了屯掖。
從測試行業(yè)的發(fā)展來說玄柏，國內(nèi)產(chǎn)品由于產(chǎn)品特點(diǎn)，世界級的產(chǎn)品不多懂扼，技術(shù)含量相對不高禁荸，質(zhì)量要求相對要求不高，外包國外項(xiàng)目阀湿，測試人力成本低廉赶熟，所以需要大量的手工測試人員。
所以陷嘴，在不遠(yuǎn)的未來映砖，我認(rèn)為純的工手測試人員的需求是遞減，公司更需要更高技術(shù)能力的測試灾挨。質(zhì)量需要測試邑退，測試行為永遠(yuǎn)不會(huì)消失竹宋，但純的手工測試人員是否消失是有可能的。
好吧地技，你可以說測試多朝陽的行業(yè)蜈七，我純屬在危言聳聽。不管未來如何莫矗，我們都需要提升自身的技能對吧飒硅！
什么項(xiàng)目適合做自動(dòng)化測試？
假如你已經(jīng)決定要學(xué)習(xí)自動(dòng)化測試了作谚，如何學(xué)習(xí)是要面臨的下一個(gè)問題三娩？這個(gè)問題以被測試產(chǎn)品為出發(fā)點(diǎn)進(jìn)行分析，假如你所學(xué)的技術(shù)不能得到應(yīng)用（驗(yàn)證）妹懒，將會(huì)使你的學(xué)習(xí)過程寸步難行雀监。
首先考考慮產(chǎn)品是否適合做自動(dòng)化測試。這方法比較普遍的共識(shí)是從三個(gè)方面進(jìn)行權(quán)衡眨唬。
軟件需求變動(dòng)不頻繁
測試腳本的穩(wěn)定性決定了自動(dòng)化測試的維護(hù)成本筋搏。如果軟件需求變動(dòng)過于頻繁嫌吠，測試人員需要根據(jù)變動(dòng)的需求來更新測試用例以及相關(guān)的測試腳本流酬，而腳本的維護(hù)本身就是一個(gè)代碼開發(fā)的過程蓉驹，需要修改、調(diào)試搂橙，必要的時(shí)候還要修改自動(dòng)化測試的框架，如果所花費(fèi)的成本不低于利用其節(jié)省的測試成本笛坦，那么自動(dòng)化測試便是失敗的区转。
項(xiàng)目中的某些模塊相對穩(wěn)定，而某些模塊需求變動(dòng)性很大版扩。我們便可對相對穩(wěn)定的模塊進(jìn)行自動(dòng)化測試废离，而變動(dòng)較大的仍是用手工測試。
項(xiàng)目周期較長
由于自動(dòng)化測試需求的確定礁芦、自動(dòng)化測試框架的設(shè)計(jì)蜻韭、測試腳本的編寫與調(diào)試均需要相當(dāng)長的時(shí)間來完成。這樣的過程本身就是一個(gè)測試軟件的開發(fā)過程柿扣，需要較長的時(shí)間來完成肖方。如果項(xiàng)目的周期比較短，沒有足夠的時(shí)間去支持這樣一個(gè)過程未状，那么自動(dòng)化測試便成為笑談俯画。
自動(dòng)化測試腳本可重復(fù)使用
自動(dòng)化測試腳本的重復(fù)使用要從三個(gè)方面來考量，一方面所測試的項(xiàng)目之間是否很大的差異性（如C/S系統(tǒng)和B/S系統(tǒng)的差異）司草；所選擇的測試工具是否適應(yīng)這種差異艰垂；最后泡仗，測試人員是否有能力開發(fā)出適應(yīng)這種差異的自動(dòng)化測試框架。
選擇什么工具進(jìn)行自動(dòng)化測試
假如你已經(jīng)確認(rèn)了XX項(xiàng)目適合做自動(dòng)化測試猜憎，那么接下來你要做的就是選測試工具了娩怎。
首先要先確認(rèn)你所測試的產(chǎn)品是桌面程序（C/S）還是web應(yīng)用（B/S）。
桌面程序的工具有：QTP胰柑、AutoRunner
web應(yīng)用的工具有：QTP截亦、AutoRunner、Robot?Framework旦事、watir魁巩、selenium
由于B/S架構(gòu)的諸多優(yōu)勢，早幾年前大量C/S架構(gòu)的應(yīng)用轉(zhuǎn)為B/S結(jié)構(gòu)姐浮。從而也推動(dòng)了web開發(fā)與測試技術(shù)的發(fā)展谷遂。假如，被測試有產(chǎn)品是C/S架構(gòu)的卖鲤，那么推薦QTP肾扰，QTP在UI自動(dòng)化測試領(lǐng)域占到了一半的試用率。所以蛋逾，足以說明QTP在自動(dòng)化領(lǐng)域強(qiáng)大集晚，易用性等。學(xué)習(xí)主流的工具也可以使你獲得更多的機(jī)會(huì)区匣。市面上關(guān)于QTP的書籍也非常豐富偷拔。當(dāng)然，要想學(xué)好QTP亏钩，你必須要掌握VBS腳本語言莲绰。
如果，被測產(chǎn)品是B/S結(jié)構(gòu)姑丑，那么推薦selenium蛤签，為什么不是QTP或其它工具？因?yàn)閟elenium對B/S應(yīng)用支持很好栅哀，更重要的一點(diǎn)震肮，它支持多語言的開發(fā)，真正的試用selenium留拾，你所要掌握的不僅僅是一個(gè)工具而已戳晌，你還需要學(xué)習(xí)一門語言。我為什么要選擇selenium间驮？還要學(xué)一門語言躬厌，這無疑增加了我的學(xué)習(xí)成本。增加成本的同時(shí)，也增加的你的競爭力扛施，而且鸿捧，在這個(gè)過程中你不單單只是學(xué)會(huì)了一個(gè)自動(dòng)化工具而已，你完全可以使用所學(xué)的語言去做更多的事情疙渣。
好吧匙奴！假如你決定試用selenium了之后，你又面臨了一個(gè)新的問題妄荔，選擇一門語言泼菌。selenium是支持java、python啦租、ruby哗伯、php、C#篷角、JavaScript?焊刹。
從語言易學(xué)性來講，首選ruby恳蹲，python
從語言應(yīng)用廣度來講虐块，首選java、C#嘉蕾、php贺奠、
從語言相關(guān)測試技術(shù)成度（及?資料）來講：ruby?,python?,java
或者你可以考慮整個(gè)技術(shù)團(tuán)隊(duì)主流用什么語言，然后選擇相應(yīng)的語言错忱。
selenium?用前須知
OK儡率！經(jīng)過上的過程，我相信你一定做出的相應(yīng)的選擇以清，如果你選擇的是selenium?工具喉悴，那么接著往下閱讀。
首選你在開始selenium之前玖媚，需要花一到兩個(gè)月時(shí)間去學(xué)一門語言，這里是根據(jù)沒有語言基礎(chǔ)的同學(xué)而定的婚脱。我推薦ruby?,python?,java?任意一門語言來進(jìn)行學(xué)習(xí)今魔。
當(dāng)然，已經(jīng)如果有很好的語言基礎(chǔ)略過這個(gè)環(huán)節(jié)障贸，或者你的豐富的java編程能力错森，那么學(xué)習(xí)python?可能只需要幾天時(shí)間或更短。
假如篮洁，你已經(jīng)搞定了一門語言的基礎(chǔ)涩维，接下來你需要先了解selenium?，selenium?并不是單純的一個(gè)工具，他是一組工具的集合瓦阐，而且蜗侈，他還有1.0與2.0之分，當(dāng)然3.0也已經(jīng)到來睡蟋。
selenium?也不是簡單一個(gè)工具踏幻，而是由幾個(gè)工具組成，每個(gè)工具都有其特點(diǎn)和應(yīng)用場景戳杀。
selenium?IDE
selenium?IDE?是嵌入到Firefox瀏覽器中的一個(gè)插件该面，實(shí)現(xiàn)簡單的瀏覽器操作的錄制與回放功能。那么什么情況下用到它呢信卡？
快速的創(chuàng)建bug重現(xiàn)腳本隔缀，在測試人員的測試過程中，發(fā)現(xiàn)了bug之后可以通過IDE將重現(xiàn)的步驟錄制下來傍菇，以幫助開發(fā)人員更容易的重現(xiàn)bug猾瘸。
IDE錄制的腳本可以可以轉(zhuǎn)換成多種語言，從而幫助我們快速的開發(fā)腳本桥嗤，關(guān)于這個(gè)功能后而用到時(shí)再詳細(xì)介紹须妻。
selenium?Grid
Selenium?Grid是一種自動(dòng)化的測試輔助工具，Grid通過利用現(xiàn)有的計(jì)算機(jī)基礎(chǔ)設(shè)施泛领，能加快Web-app的功能測試荒吏。利用Grid，可以很方便地同時(shí)在多臺(tái)機(jī)器上和異構(gòu)環(huán)境中并行運(yùn)行多個(gè)測試事例渊鞋。其特點(diǎn)為：
·?并行執(zhí)行
·?通過一個(gè)主機(jī)統(tǒng)一控制用例在不同環(huán)境绰更、不同瀏覽器下運(yùn)行。
·?靈活添加變動(dòng)測試機(jī)
selenium?RC
selenium?RC?是selenium?家族的核心工具锡宋，selenium?RC?支持多種不同的語言編寫自動(dòng)化測試腳本儡湾，通過selenium?RC?的服務(wù)器作為代理服務(wù)器去訪問應(yīng)用從而達(dá)到測試的目的。
selenium?RC?使用分Client?Libraries和selenium?Server执俩，Client?Libraries庫主要主要用于編寫測試腳本徐钠，用來控制selenium?Server的庫。
Selenium?Server負(fù)責(zé)控制瀏覽器行為役首，總的來說尝丐，Selenium?Server主要包括3個(gè)部分：Launcher、Http?Proxy衡奥、Core爹袁。其中Selenium?Core是被Selenium?Server嵌入到瀏覽器頁面中的。其實(shí)Selenium?Core就是一堆JS函數(shù)的集合矮固，就是通過這些JS函數(shù)失息，我們才可以實(shí)現(xiàn)用程序?qū)g覽器進(jìn)行操作。Launcher用于啟動(dòng)瀏覽器，把selnium?Core加載到瀏覽器頁面當(dāng)中盹兢，并把瀏覽器的代理設(shè)置為Selenium?Server?的Http?Proxy邻梆。
selenium?2.0
搞清了selenium?1.0?的家族關(guān)系，selenium?2.0?是把WebDriver?加入到了這個(gè)家族中蛤迎；簡單用公式表示為：
selenium?2.0?=?selenium?1.0?+?WebDriver
需要強(qiáng)調(diào)的是确虱，在selenium?2.0?中主推的是WebDriver?，WebDriver?是selenium?RC?的替代品替裆，因?yàn)?selenium?為了向下兼容性校辩，所以selenium?RC?并沒有徹底拋棄，如果你使用selenium開發(fā)一個(gè)新自動(dòng)化測試項(xiàng)目辆童，強(qiáng)列推薦使用WebDriver?宜咒。那么selenium?RC?與webdriver?主要有什么區(qū)別呢？
selenium?RC?在瀏覽器中運(yùn)行JavaScript應(yīng)用把鉴，使用瀏覽器內(nèi)置的JavaScript?翻譯器來翻譯和執(zhí)行selenese命令（selenese?是selenium命令集合）故黑。
WebDriver通過原生瀏覽器支持或者瀏覽器擴(kuò)展直接控制瀏覽器。WebDriver針對各個(gè)瀏覽器而開發(fā)庭砍，取代了嵌入到被測Web應(yīng)用中的JavaScript场晶。與瀏覽器的緊密集成支持創(chuàng)建更高級的測試，避免了JavaScript安全模型導(dǎo)致的限制怠缸。除了來自瀏覽器廠商的支持诗轻，WebDriver還利用操作系統(tǒng)級的調(diào)用模擬用戶輸入。
如果是新項(xiàng)目直接學(xué)習(xí)webdriver?就OK了揭北，RC是過時(shí)技術(shù)扳炬。
selenium學(xué)習(xí)路線
配置你的測試環(huán)境，真對你所學(xué)習(xí)語言搔体，來配置你相應(yīng)的selenium?測試環(huán)境恨樟。selenium?好比定義的語義---“問好”，假如你使用的是中文疚俱，為了表術(shù)問好劝术，你的寫法是“你好”，假如你使用的是英語呆奕，你的寫法是“hello”夯尽。?所以，同樣有語義在不同的語言下會(huì)有不同的寫法（語法）登馒。
接著你需要熟悉webdriver?API?，API就是selenium?所定義一方法咆槽，用于定位陈轿，操作頁面上的各種元素。
先學(xué)習(xí)元素的定位，selenium?提供了id麦射、name蛾娶、class?name、?tag?name潜秋、link?text蛔琅、partial?link?text、?xpath峻呛、css罗售、等定位方法。xpath和css功能強(qiáng)大語法稍微復(fù)雜钩述，在這其間你可能還需要了解更多的前端知識(shí)寨躁。xml?,javascript等。
定位元素的目的是為了操作元素牙勘，接就要學(xué)習(xí)各種元素有操作职恳，輸入框，下拉框方面，按鈕點(diǎn)擊放钦，文件上傳、下載恭金，分頁操禀，對話框，警告框...等等蔚叨。
經(jīng)過一段時(shí)間的學(xué)習(xí)床蜘，你可以游刃有余的模擬手工測試來操作頁面上的各種元素了。接著你需要做的就是把這些“用例”組織起來蔑水，統(tǒng)一來跑邢锯。
那么你需要做的就是學(xué)習(xí)并使用單元測試框架，單元測試框架本身就解決了用例的組織與運(yùn)行搀别。
當(dāng)你寫了一些“測試用例”?之后丹擎，你會(huì)發(fā)現(xiàn)用例中有大量重復(fù)的操作，能不能寫到一個(gè)單獨(dú)的文件中歇父，需要的時(shí)候調(diào)用這些操作蒂培？當(dāng)然可以，運(yùn)用你的編程能力來實(shí)現(xiàn)這一點(diǎn)將非常簡單榜苫。然后护戳，你又發(fā)現(xiàn)每個(gè)用例中都有一些數(shù)據(jù)，這些數(shù)據(jù)也是一樣的垂睬，但如果變化了修改起來非常麻煩媳荒，你也可以把他寫到一個(gè)單獨(dú)的文件中進(jìn)行讀取抗悍。
接著你又遇到了新的疑問，我寫的腳本（用例）都是流水式的钳枕，我怎么知道用例運(yùn)行失敗還是成功缴渊。那么就需要在腳本中加一些驗(yàn)證與斷言。
接著你又有了更多的想法鱼炒，單元測試框架的log太簡陋了衔沼，能不能生成一張漂亮的測試報(bào)告出來。我能不能定時(shí)的來跑這個(gè)腳本昔瞧。能不能把每一次跑腳本的測試結(jié)果直接發(fā)到我的郵箱指蚁。能不能......
為解決這些問題，你不得不學(xué)習(xí)更多的編程技術(shù)硬爆，然后你的“測試結(jié)構(gòu)”會(huì)功能越來越強(qiáng)大欣舵，越來越靈活。產(chǎn)生了一定的通用性和移植性缀磕。一個(gè)有模有樣的自動(dòng)化測試框架誕生了缘圈。
假如，有一天你不再做UI的自動(dòng)化測試了袜蚕，你會(huì)發(fā)現(xiàn)你去做單元測試?或接口測試基本沒什么難度糟把。開發(fā)個(gè)測試工具之類的也不在話下，感謝selenium吧牲剃！順便也感謝一下我吧遣疯！
