自動化測試的好處

<!--[if!supportLists]-->第1章<!--[endif]-->自動化測試的好處回歸測試，降低測試成本對于產(chǎn)品型的軟件或生命周期長的項目，經(jīng)常會有新功能的開發(fā)或需求的變動，對于新發(fā)布的軟件功能，大部分都和上一個版本相近或相同，這些功能如果在上一個版本之前已經(jīng)實現(xiàn)了自動化測試，那么新發(fā)布的版本中，這部分功能就可以自動化測試實現(xiàn)，避免了重復(fù)測試的成本，也確保了軟件的質(zhì)量。提高測試效率一些測試用例手工測試是比較繁瑣的，比如話單或協(xié)議字段的檢查，如果是人工檢查將是一件既繁瑣又耗時還容易出錯的工作，如果是自動化測試，測試就會變得輕松和容易很多。對于檢查點很多的測試用例，如果手工執(zhí)行一步都需要停下來檢查好幾個復(fù)雜的檢查點，測試的效率自然是非常低，使用自動化測試，設(shè)置好了輸入條件和預(yù)期結(jié)果，只要點擊按鈕運行一下腳本就知道了復(fù)雜的測試結(jié)果。易于發(fā)現(xiàn)軟件的改動自動化測試腳本可以重復(fù)執(zhí)行，容易發(fā)現(xiàn)軟件的任何變動。比如修復(fù)了一個TR后，引起原功能的改動，執(zhí)行相同的腳本，可以通過測試輕易發(fā)現(xiàn)問題。充分利用資源自動化測試可以不需要人在現(xiàn)場的情況下自動執(zhí)行，發(fā)布了一個新版本的軟件后，可以在白天的上班時間進(jìn)行新功能的手工測試，原有功能的自動化測試可以在晚上或周末執(zhí)行，第二天上班就可以看到執(zhí)行的結(jié)果。這樣充分利用時間資源，提高測試的效率，也避免了開發(fā)和測試之間的等待。性能測試在一些壓力大的性能測試中，人工是很難模擬的。在沒有引入自動化測試工具之前，為了測試并發(fā)，研發(fā)中心再加上公司的其它部門上千號人在研發(fā)經(jīng)理的口令“1一、2—、3!”的號召下，大家同時按下同一個按鈕。這樣的測試，雖然是模擬了并發(fā)，但需要消耗相當(dāng)大的成本，想要測試一次也不容易。在性能測試中使用自動化測試，可以輕易模擬并發(fā)，為性能壓力測試提供了更好的方法。將精力投入更有意義的測試自動化測試減輕了很多重復(fù)的工作，我們有更多的時間去思考如何提高軟件的質(zhì)量，制定詳細(xì)的測試計劃，精心設(shè)計測試用例，構(gòu)建更復(fù)雜的測試。對于我來說，這是自動化測試給我?guī)淼淖畲蟮暮锰?。自動化測試的好處有很多，但并不意味著自動化測試可以取代手工測試，也不意味著任何的系統(tǒng)都適合自動化測試。自動化測試的意義并不是取代人在測試中的位置，而是將人從重復(fù)繁瑣的工作中解放出來，做更有價值的測試工作。<!--[if!supportLists]-->第2章<!--[endif]-->自動化測試基本原則<!--[if!supportLists]-->2.1<!--[endif]-->適合做自動化測試的軟件很多公司都知道自動化測試可以提高測試的效率，但在知道這個道理的公司中大部分的公司都是以手工測試為主的，原因可能有很多，但最大的影響因素就是自動化測試的成本。如果自動化測試的成本比手工測試的成本還大或者并沒有比自動化測試占有太大的優(yōu)勢，公司自然不會選擇自動化測試了。是否做自動化測試，主要看成本的投入和效果的產(chǎn)出是否值得。1、 不適合做自動化測試的系統(tǒng)1） 系統(tǒng)業(yè)務(wù)邏輯和交互過于復(fù)雜如果系統(tǒng)業(yè)務(wù)邏輯和交互過于復(fù)雜，要實現(xiàn)自動化測試的成本非常高，工具開發(fā)和腳本編寫的時間可能遠(yuǎn)遠(yuǎn)大于手工測試，這個系統(tǒng)就沒有自動化測試的必要。2） 項目周期過短如果系統(tǒng)的生命周期很短（半年內(nèi)），即使很容易實現(xiàn)自動化測試，但自動化測試的使用率只有很短的時間或很有限的次數(shù)，這樣的自動化測試也沒有必要。因為前期腳本的編寫和后期的維護(hù)都需要很多的時間，雖然自動化測試在功能測試的過程或回歸測試的過程會節(jié)省一些時間，但如果自動化測試的腳本只是很短的生命周期，自動化測試的成本就非常的高了。3） 系統(tǒng)需求頻繁變動對于功能不穩(wěn)定的系統(tǒng)，會由于這些不穩(wěn)定因素導(dǎo)致自動化測試失敗，自動化的測試結(jié)果也就變得不可信，這類型的系統(tǒng)也不適合使用自動化測試。2、 適合做測試化測試的系統(tǒng)適合做自動化測試的系統(tǒng)，通常是一些生命周期比較長的項目或產(chǎn)品，且系統(tǒng)功能實現(xiàn)自動化測試也較為容易，這樣的項目使用自動化測試必然可以節(jié)省很多的資源和成本。特別是一些在今后的幾年間需要不斷開發(fā)和維護(hù)的項目，需要重復(fù)的進(jìn)行大量的回歸測試，如果有完善的自動化測試腳本，回歸測試就可以節(jié)省大量的時間和精力了。對于一些增量式的產(chǎn)品，白天手工測試新功能，晚上或周末利用自動化測試腳本回歸測試，可以達(dá)到資源使用的最優(yōu)化，用很少的時間和很少的資源做很多的事情。簡而言之，是否值得使用自動化測試，就要看它是否具有自動化測試的特點和高的投資回報率。<!--[if!supportLists]-->2.2<!--[endif]-->開始自動化測試的時機(jī)如果是新的自動化測試工具的開發(fā)或研究，最好預(yù)留一個比較充裕的時間，時間太趕很難設(shè)計出精品。如果想在功能測試階段使用自動化測試，那么自動化測試架構(gòu)的設(shè)計最好能夠與代碼實現(xiàn)同步，否則如果等代碼實現(xiàn)提交測試之后再做自動化測試工具的開發(fā)或研究，在功能測試或回歸測試的過程中就被動了很多。關(guān)于在項目的什么階段開始自動化測試，由項目決定，對于需求相對穩(wěn)定并且是基于成熟的架構(gòu)上開發(fā)的系統(tǒng)，自動化測試腳本最好在功能測試開始之前編寫，在功能測試階段就可以使用已經(jīng)編寫好的腳本做功能測試了。但我們平時遇到的項目，有很多是需求變化比較大的，或者是一些不夠成熟的系統(tǒng)，這樣的系統(tǒng)如果在功能測試之前編寫好的腳本，很有可能不能在系統(tǒng)上正確運行，大多還是需要手工執(zhí)行才可以測試，甚至?xí)诠δ軠y試完后系統(tǒng)跟功能測試之前的系統(tǒng)會有非常大的區(qū)別。對于這樣的項目，自動化測試開始得越早項目的成本就越大，最好在系統(tǒng)的架構(gòu)或需求相對穩(wěn)定后再做自動化測試。對于一些需要錄制GUI界面的功能的自動化測試，在頁面的功能相對穩(wěn)定之后再做自動化測試性價比會比較高，因為頁面是最容易變動的部分，而且任何一個控件的修改都會導(dǎo)致自動化工具不能識別控件，導(dǎo)致很多自動化測試腳本會跟著做大量的修改，增加了維護(hù)的成本。當(dāng)然，因為頁面變化而引起的腳本的改動的大小，也跟自動化測試的架構(gòu)和寫腳本的功力有密切的關(guān)系。對于一些協(xié)議或接口相關(guān)的功能測試（比如：XML或socket接口等），是較為容易實現(xiàn)自動化測試的，封裝好底層的協(xié)議提供給自動化測試腳本調(diào)用，即使是協(xié)議會有變化，改動起來還是很簡單的，維護(hù)的成本相對較低?？偟膩碚f，在軟件功能達(dá)到相對的穩(wěn)定，沒有嚴(yán)重錯誤和邏輯錯誤后開始自動化測試，性價比是比較高的。<!--[if!supportLists]-->2.3<!--[endif]-->自動化測試的覆蓋率自動化測試的覆蓋率是很多管理層所關(guān)心的，很多項目或產(chǎn)品的自動化測試目標(biāo)之一就是自動化測試的覆蓋率。從管理的角度來說，100%的自動化目標(biāo)只是一個從理論上可能達(dá)到的，但是實際上達(dá)到100%的自動化的代價是十分昂貴的。自動化測試覆蓋率越高，測試腳本的維護(hù)成本也就越大。由于對每一個構(gòu)建版本的需求變化的復(fù)雜度，你將花費更多的時間在變更測試用例上以使他們能夠正確的運行。自動化測試的覆蓋率的大小與自動化測試的成本有著很大的聯(lián)系。自動化測試的覆蓋率為多少比較恰當(dāng)，也要看被測試系統(tǒng)的性質(zhì)和測試的階段。在自動化測試設(shè)計的階段，可以考慮先實現(xiàn)冒煙測試的測試用例自動化，冒煙測試的功能一般是系統(tǒng)的主要功能，是自動化測試設(shè)計必須首先實現(xiàn)的，而且通過實現(xiàn)這些功能，也可以檢驗自動化測試的架構(gòu)是否合理。在功能測試的前期，自動化測試腳本的覆蓋率最好只是一些關(guān)鍵的并且是相對穩(wěn)定的功能的測試自動化，用于冒煙測試或關(guān)鍵功能測試。系統(tǒng)穩(wěn)定后，如果系統(tǒng)是一個生命周期很長的系統(tǒng)，且測試的功能很容易實現(xiàn)自動化測試，這樣的系統(tǒng)的自動化測試覆蓋率可以考慮在80%以上。但如果是一些時間很趕的項目，或者是一些比較難實現(xiàn)自動化測試的功能，也就沒有追求高的自動化測試的覆蓋率的必要。隨著測試案例的增加，維護(hù)的成本也會相應(yīng)增加，特別是一些GUI的測試，自動化比率越高，維護(hù)腳本的成本也就越高。不要追求在很短的時間實現(xiàn)自動化測試，也不要追求100%的自動化測試覆蓋率,積累經(jīng)驗循序漸進(jìn)的自動化測試，效果會更好。<!--[if!supportLists]-->第3章<!--[endif]-->自動化測試實現(xiàn)基本策自動化測試與軟件開發(fā)本質(zhì)上是一樣的，利用自動化測試工具，經(jīng)過測試需求分析，設(shè)計出自動化測試用例，從而搭建自動化測試的框架，設(shè)計與編寫自動化腳本，驗證測試腳本的正確性，最終完成自動化測試測試腳本（即主要功能為測試的應(yīng)用軟件）。<!--[if!supportLists]-->3.1<!--[endif]-->測試系統(tǒng)需求分析任何測試的基礎(chǔ)都是被測系統(tǒng)的功能，不管是手工的功能測試還是自動化測試或者是性能測試，都是基于系統(tǒng)的功能展開的。當(dāng)測試項目滿足了自動化的前提條件，并確定在該項目中需要使用自動化測試時，我們便開始進(jìn)行自動化測試需求分析。此過程需要確定自動化測試的范圍以及相應(yīng)的測試用例、測試數(shù)據(jù)，并形成詳細(xì)的文檔，以便于自動化測試框架的建立。很多公司都是將自動化測試和功能測試劃分成兩個不同的team，自動化測試team的同事實現(xiàn)自動化測試工具的開發(fā)，功能測試team的同事向自動化測試team的同事提需求，自動化測試team的同事編寫代碼實現(xiàn)自動化測試工具的功能后提交給功能測試team的同事使用，這是當(dāng)前非常常見的自動化測試的模式，畢竟每個人都有自己擅長的技能，某個人也不可能面面俱到，通過這樣的一種方式可能使自動化測試的門檻變得更低一些。自動化測試工具的開發(fā)和自動化測試的使用的確是可以由不同的角色去承擔(dān)，不過作為自動化架構(gòu)設(shè)計的人員，應(yīng)該是對系統(tǒng)的功能或需求非常熟悉，同時具有良好的設(shè)計和開發(fā)能力，才可以設(shè)計出適合測試系統(tǒng)的自動化測試架構(gòu)，否則開發(fā)出來的自動化測試工具就只是簡單的一個工具，某種程度上會增加維護(hù)的成本。漂亮的自動化測試架構(gòu)的設(shè)計是一個漸進(jìn)的過程，但這個漸進(jìn)是基于對功能熟悉的基礎(chǔ)上，全盤考慮之后一點一點的搭建起來的。<!--[if!supportLists]-->3.2<!--[endif]-->自動化測試工具的選擇很多測試的同行或以前的老同事都會問，你們用什么自動化測試工具？幾年前入門測試時跟著老前輩寫自動化測試工具，后來因為興趣偶爾玩一下當(dāng)時流行的自動化測試工具，再到現(xiàn)在毫無選擇工具的余地設(shè)計自動化測試架構(gòu)，越來越發(fā)覺自動化測試工具真的沒有那么的重要。工具始終是工具，思想和架構(gòu)才是自動化測試的核心，同樣的工具不同的人使用會出現(xiàn)完全不一樣的結(jié)果，而且，不管是什么樣的自動化測試工具，原理都有異曲同工之處。所以，不需要把工具看得那么重要，而是把怎樣使用工具，怎樣利用工具為你服務(wù)放在首位。也就是你的思想位于工具之上。但是，是不是這就意味著測試工具一點也不重要呢？當(dāng)然不是，遇上不穩(wěn)定或不友好的測試工具，可能會浪費大量的時間在調(diào)試工具上，也可能會出現(xiàn)因為工具不穩(wěn)定導(dǎo)致測試結(jié)果的不可信任，那么自動化測試不是提高測試效率反而是阻礙了測試的進(jìn)度了。關(guān)于工具的選擇或開發(fā)，基本的原則為：1）首先，能夠滿足項目的需求，容易擴(kuò)展，可以滿足系統(tǒng)任何重要功能的自動化測試；2）其次，友好易用，容易上手，為測試人員提供較為低的門檻；3）當(dāng)然最重要的是它的穩(wěn)定性，是否不需要人工干預(yù)就能穩(wěn)定地批量運行所有的自動化測試腳本，并且能夠產(chǎn)出準(zhǔn)確的測試報告;4）最后，還有一點就是它的性價比是否值得，免費的軟件對公司來說當(dāng)然是最好：）市場上有很多測試工具，在這些測試工具中，puretest是一個性價比很高的自動化測試工具。它容易入門，易于擴(kuò)展，使用簡單，運行穩(wěn)定，基本上可以滿足任何包括GUI、協(xié)議和業(yè)務(wù)邏輯的測試。<!--[if!supportLists]-->3.3<!--[endif]-->自動化測試架構(gòu)設(shè)計自動化測試架構(gòu)的設(shè)計是整個自動化測試的靈魂核心，它的好壞關(guān)系到自動化測試的成敗。從系統(tǒng)的基本功能入手，設(shè)計自動測試架構(gòu)，這是軟件測試的關(guān)鍵一步。架構(gòu)的好與壞很重要，它影響到系統(tǒng)的擴(kuò)展、維護(hù)和使用，如果想要系統(tǒng)容易擴(kuò)展和維護(hù)，一定要多花心思在設(shè)計上。很多同行問我使用什么測試工具，我會告訴他們，用什么測試工具其實并不那么重要，不同的人使用同樣的測試工具，會做出效果完全不一樣的自動化測試，那是因為他們的架構(gòu)不同，設(shè)計比工具重要得多。怎樣的自動化測試架構(gòu)才算是一個好的架構(gòu)？首先是容易擴(kuò)展，能夠滿足現(xiàn)在的功能需求，也能滿足以后需要測試的功能的需求。第二，容易維護(hù)，當(dāng)業(yè)務(wù)流程、接口或頁面變動的時候，只需要做一些簡單的修改就可以實現(xiàn)。第三，可讀性強(qiáng)，別人能夠容易讀懂和接手維護(hù)。第四，容易使用，項目組的其他人想要使用的時候能夠簡單地搭建和運行。第五，有統(tǒng)一的編碼規(guī)范、存儲規(guī)范和編寫風(fēng)格。第六，方便調(diào)試，當(dāng)腳本運行出現(xiàn)問題的時候，可以方便跟蹤問題產(chǎn)生的根源。第七，結(jié)構(gòu)清晰，測試用例與測試工具和代碼分離。最后，是最重要的一點，是腳本具有很高的可信性以及自動運行的穩(wěn)定性。在設(shè)計架構(gòu)之前，首先要熟悉測試系統(tǒng)以及這個測試系統(tǒng)需要測試的功能有哪些類型，每種測試類型在測試架構(gòu)中是否都可以滿足。在設(shè)計架構(gòu)時，可以選擇覆蓋系統(tǒng)基本功能的smoketest測試用例來做基本的測試用例，在實現(xiàn)這些基本的測試用例的自動化測試過程中，對架構(gòu)進(jìn)行完善?；镜淖詣踊瘻y試框架實現(xiàn)之后，再回顧一下是否測試系統(tǒng)中需要實現(xiàn)自動化的測試用例，測試架構(gòu)都可以滿足需求，如果不可以滿足則需要繼續(xù)做進(jìn)一步的開發(fā)，如果測試架構(gòu)可以滿足需求，接下來可以讓其他的同事使用，收集改進(jìn)的建議對測試架構(gòu)進(jìn)行完善和改進(jìn)。好的測試架構(gòu)，是要使用的人覺得舒服。自動化測試架構(gòu)設(shè)計的時候的一些基本的策略:<!--[if!supportLists]-->1、<!--[endif]-->自動化測試腳本與自動化測試架構(gòu)的代碼分離，自動化測試架構(gòu)的代碼實現(xiàn)自動化測試的基本功能，自動化測試腳本包含業(yè)務(wù)邏輯。<!--[if!supportLists]-->2、<!--[endif]-->設(shè)計清晰的腳本和配置文件的存放目錄。<!--[if!supportLists]-->3、<!--[endif]-->數(shù)據(jù)驅(qū)動<!--[if!supportLists]-->1)<!--[endif]-->測試系統(tǒng)相關(guān)的配置、模擬器的配置等系統(tǒng)級的配置用系統(tǒng)級配置文件存放，不要把這些值寫死在腳本或代碼中，否則當(dāng)測試系統(tǒng)的環(huán)境變化的時候相應(yīng)的維護(hù)成本也會很高。<!--[if!supportLists]-->2)<!--[endif]-->測試系統(tǒng)所使用到的一些規(guī)范定義取值，定義在配置文件中，在腳本中需要使用的時候引用變量定義，這樣即使規(guī)范定義改變了也不需要修改腳本，只要簡單的修改配置文件即可；如果外部規(guī)范定義和內(nèi)部的定義取值不一樣，最好有對應(yīng)的mapping定義表。<!--[if!supportLists]-->3)<!--[endif]-->測試數(shù)據(jù)的數(shù)據(jù)模型如果比較復(fù)雜，最好也在配置文件中對數(shù)據(jù)模型以及字段的取值進(jìn)行定義，方便在腳本中創(chuàng)建數(shù)據(jù)時使用。<!--[if!supportLists]-->4)<!--[endif]-->協(xié)議或Schema或話單的格式，在配置文件中定義，當(dāng)協(xié)議的格式改動的時候，只需要修改配置文件即可。<!--[if!supportLists]-->5)<!--[endif]-->腳本中盡量少用常量，輸入?yún)?shù)、腳本運行時提取的值、測試結(jié)果的對比等，都可以使用變量，避免腳本的常量寫死后引起的維護(hù)工作。<!--[if!supportLists]-->4、<!--[endif]-->測試數(shù)據(jù)準(zhǔn)備<!--[if!supportLists]-->1)<!--[endif]-->測試數(shù)據(jù)準(zhǔn)備，有兩種類型，一類是腳本運行前事先可以準(zhǔn)備好的數(shù)據(jù)，這種類型的數(shù)據(jù)，可以在自動化測試前自動創(chuàng)建好并保存到文件中提供給測試腳本使用；另一類是腳本運行時要創(chuàng)建的特殊數(shù)據(jù)，這些數(shù)據(jù)可以在腳本運行的過程中調(diào)用基礎(chǔ)腳本進(jìn)行創(chuàng)建。<!--[if!supportLists]-->2)<!--[endif]-->公用的數(shù)據(jù)，如果在腳本運行的過程中被修改，在該腳本運行結(jié)束后需要恢復(fù)到原樣，避免因為公用數(shù)據(jù)的修改引起其它腳本運行失敗。<!--[if!supportLists]-->5、<!--[endif]-->模塊化：對基礎(chǔ)腳本進(jìn)行封裝，一些可以公用的腳本單獨封裝給其余的測試腳本調(diào)用，當(dāng)公用的業(yè)務(wù)邏輯改變的時候，只需要修改基礎(chǔ)腳本，而不需要對所有的測試腳本進(jìn)行改動。<!--[if!supportLists]-->6、<!--[endif]-->提供自動化腳本編寫模版，新寫的腳本只需要在模版的基礎(chǔ)上做很小的改動就可以實現(xiàn)功能，可以節(jié)省腳本編寫的時間和降低腳本編寫的門檻。<!--[if!supportLists]-->3.4<!--[endif]-->自動化測試腳本編寫自動化測試腳本的編寫功力很重要，寫得好的腳本，可以減少維護(hù)的工作量。自動化測試腳本一般由測試的輸入、業(yè)務(wù)邏輯、測試輸出和測試結(jié)果驗證幾部分組成。自動化腳本的編寫，要注意全局的把握和review，不同的人會有不同的風(fēng)格，稍不注意就會問題多多。在自動化腳本編寫前，給相關(guān)同事提供技術(shù)和架構(gòu)的培訓(xùn)，培訓(xùn)的內(nèi)容包括被測試系統(tǒng)的基本功能介紹、自動化測試工具的架構(gòu)、自動化測試的配置說明、自動化測試的編寫原則、自動化腳本編寫示例等。自動化測試腳本的例子也很重要，建議在腳本編寫前對系統(tǒng)準(zhǔn)備實現(xiàn)自動化測試的功能進(jìn)行分類，由資深的自動化測試工程師根據(jù)每個分類都先寫一個例子并且review通過后作為這些功能的自動化測試腳本的編寫模板，其余的同事可以參照例子按照自動測試架構(gòu)編寫規(guī)范寫腳本。編寫腳本時應(yīng)該注意腳本的可重用性和可維護(hù)性，如果腳本中充滿了硬編碼的值，這些值應(yīng)該被參數(shù)化，否則腳本僅僅適用于一個測試情況，腳本還應(yīng)該加入條件判斷、循環(huán)等結(jié)構(gòu)，以便增強(qiáng)測試腳本的靈活性。在編寫腳本的時候必然會遇到技術(shù)問題或業(yè)務(wù)問題，需要有資深的工程師或TL協(xié)助解決，并且在整體的架構(gòu)上全局把握。腳本編寫完成后，需要有一個抽查Review的過程，挑幾個典型的腳本review一下，看看是否存在不足的地方，然后改進(jìn)。<!--[if!supportLists]-->3.5<!--[endif]-->自動化測試腳本測試當(dāng)每一個測試用例所形成的腳本通過測試后，并不意味著執(zhí)行多個甚至所有的測試用例就不會出錯。輸入數(shù)據(jù)以及測試環(huán)境的改變，都會導(dǎo)致測試結(jié)果受到影響甚至失敗。而如果只是一個個執(zhí)行測試用例，也僅能被稱作是半自動化測試，這會極大的影響自動化測試的效率，甚至不能滿足夜間自動執(zhí)行的特殊要求。自動化測試腳本最基本的原則是測試結(jié)果可信，也就是在批處理運行這些腳本的時候，該測試通過的就測試通過，該測試失敗的就測試失敗，如果出現(xiàn)本應(yīng)該失敗的腳本在運行的時候通過了或本應(yīng)該通過的腳本在運行時失敗了，測試結(jié)果就變得不可信了，自動化測試也就失去它本應(yīng)該有的意義。因此，腳本的