#Python #Unittest #Selenium #Automation
tässä viestissä käydään läpi, miten verkkosovelluksen yksikkötestaus Pythonissa tarkistetaan toiminnallisuuden oikeellisuus. Vau! Tuossa lauseessa on kourallinen ammattikieltä: yksikkötesti, verkkosovellus ja toiminnallisuustestaus.
tarkastelimme edellisessä viestissä Python-ohjelmaa testaavaa yksikköä. Kannustamme sinua käymään sen läpi, jos et tunne yksikkötestausta.
mikä on yksikkötesti?
yksikkö on ohjelman tai sovelluksen pienin testattava osa.
joten yksikkötesteillä testataan ohjelmallisesti jokainen testattava komponentti.
voit yksikkötestata backend-ohjelman tai frontend-ohjelman, kuten web-sovelluksen.
taustaohjelmalle kirjoitettaisiin yksikkötesti jokaiselle funktiolle tai menetelmälle koodiin, koska ne ovat loogisesti pienimpiä yksiköitä.
kuitenkin, frontend, tunnistat erilaisia toimintoja, jotka haluat tarkistaa ja kirjoittaa yksikkötestit sen mukaisesti.
tässä viestissä mennään testaamaan frontend-ohjelmaa eli verkkosovellusta.
mikä on verkkosovellus?
mikä tahansa verkkoselaimella, kuten Chromella, Firefoxilla tai Safarilla toimiva sovellus.
kaikilla verkkosovelluksilla on yksi yhteinen piirre — ne näkyvät loppukäyttäjille HTML-sivulla (Hypertext Markup Language). HTML on yksinkertaisesti muotoilukieli kuvaamaan, miten asiat pitäisi järjestää. Se on yksinkertaisesti tekstitiedosto.
selaimet saavat tämän HTML-sivun ja tulkitsevat tunnisteet (esim.pää, vartalo, href, taulukko jne.) jotta näyttää kaunis sivu sinulle.
verkkosovellukset toimivat client-server-arkkitehtuurissa, jossa web-palvelin isännöi haluamaasi sisältöä ja web-selain toimii asiakkaana.
What is functionality testing?
kuten nimikin kertoo, funktionaalista testauskoodia kirjoitettaessa tavoitteena on testata sovelluksen toimivuutta. Toisin sanoen, haluat varmistaa, että sovellus noudattaa toiminnallisia eritelmiä.
on olemassa muunlaisia testejä, kuten suorituskykytestejä, turvatestejä (penetraatio) ja käyttäjän hyväksyttävyystestejä.
kirjoittamasi funktionaalinen testikoodi voidaan sisällyttää niin sanottuun regressiotestiin, joka suoritetaan määräajoin, jotta varmistetaan, että vanha toiminnallisuus ei murru uuden kehityksen vuoksi.
tämän viestin lopussa ymmärrät alla mainitun koko koodin.
älä lannistu, jos koet tämän olevan liikaa. Tavoitteena tämä viesti on dissect tämä ja näyttää, miten voit ymmärtää tämän koodin ja sitten kirjoittaa oman!
seuraavassa kaaviossa esitetään korkean tason lähestymistapa web-sovelluksen (sivun) automaattiseen testaamiseen.
testien kirjoittamiseen käytämme unittest – nimistä testikehystä. Se on hyvin samanlainen JUnit Java tai nunit.Net.
unittestin avulla voit ryhmitellä alustuskoodin asetustoiminnoksi ja puhdistaa koodin tin a tearDown-funktioksi.
seuraavassa kaaviossa esitetään kokonaislähestymistapa yksikkötestauksen taustalla.
kuten yllä olevasta kaaviosta näkyy, testisarja koostuu yhdestä tai useammasta testitapauksesta.
testitapauksessa voi olla yksi tai useampi testi. Tässä viestissä aiomme keskittyä testitapaukseen, jossa on yksi testi. Näytämme lopussa, miten samaan testitapaukseen voi lisätä lisää testejä sekä luoda testisarjan.
kuten aiemmin mainittiin, jokaisessa testitapauksessa on setUp (suorita alussa) ja tearDown (suorita lopussa) – menetelmät alustuksen ja puhdistuksen suorittamiseksi.
yllä oleva koodinpätkä näyttää yksikkötestitapauksen rakenteen.
rivi 1: tuo tarvittavat kirjastot. Meidän tapauksessamme käytämme selenium-ja unittest-kirjastoja.
rivi 3: luot MyTestCase-nimisen luokan, joka ulottuu unittestiin.Test case-Luokka. Sanomme, että unittest.TestCase on vanhempainluokka ja MyTestCase on lapsiluokka.
rivi 4: lisäämme alustuskoodin asetustapaan. Sinun täytyy käyttää tarkka menetelmä nimi antaa unittest tietää, että olet lisäämässä alustuskoodi täällä. Kun suoritat tämän testin, tämä menetelmä suoritetaan ensin.
rivi 7: näytetesti, jonka haluamme sisällyttää testijuttuun.
rivi 10: Toinen näytetesti, joka meillä on testijutussamme.
rivi 16: lisäämme siivouskoodimme tämän tearDown-menetelmän sisään. Päinvastoin setUp menetelmä, tearDown menetelmä saa suoritetaan viimeinen.
joten metodin kutsumisjärjestys on:
setUp > test1 > test2 > … > tearDown
rivi 20: tämän mukaan pääohjelma alkaa tästä paikasta.
rivi 21: näin suoritat testijutun.
nyt on aika saada käsiimme se varsinainen testi, jonka halusimme tehdä. Muistuttaa, että haluamme testata, jos Google search box palauttaa vähintään 5 tuloksia tietyn hakusanan.
katsotaan ensin asetustapa:
tässä koodinpätkässä luomme Chrome-selaimen ajurin.
selenium Chrome-ajuri pitää ladata täältä, jos sitä ei vielä ole. Tätä kirjoitettaessa Chromesta on myös versio 74. Koska Chrome-selaimeni on versio 73, latasin version 73 tätä harjoitusta varten.
linjat 2 ja 3 luovat Chrome-vaihtoehdon ja antavat selenium webdriverin tietää, että emme halua tehdä selainta näkyväksi, kun suoritamme testin.
jos tätä vaihtoehtoa ei lisätä, testi juuttuu kohtaan, jossa selain aukeaa.
nyt katsotaan tearDown-metodia:
me yksinkertaisesti puhdistaa kuljettaja kutsumalla lopettaa () menetelmä.
vihdoin on aika kurkistaa testiin, jonka haluamme sisällyttää tähän testijuttuun. Muista, että voimme testata (assert), jos palattujen hakutulosten määrä on suurempi tai yhtä suuri kuin 5.
rivi 1: Testimenetelmä alkaa sanalla ”testi”.
linja 3: Kuorma www.google.com web-sivu osaksi kuljettaja (huomaa, että itse.ohjain luodaan asennuksen aikana).
linja 6: Etsi hakukentän HTML elementin nimi ”q”. Sinun täytyy tarkastaa HTML-sivu, jotta tunnistaa tämän.
rivi 7: Tee hakuruutu tyhjäksi, jos on olemassa oletusarvoja.
rivi 10: täytä hakuruutu hakusanalla ”automatisoitu testaus”.
rivi 11: lähetä hakukysely Googlelle.
rivi 14: XPath identifying Search result headings.
rivi 17: odota 10 sekuntia, kunnes Googlen tulosivu on ladattu.
rivi 20: Hae kaikki hakutulosten otsikot rivillä 14 määritellyn Xpathin avulla.
linjat 25 ja 26: Hakutulosten otsikot ovat itse asiassa luettelo ja iteroimme niiden läpi tulostaaksemme näytölle. Lisäsimme nämä kaksi riviä vain esittelytarkoituksessa. Yleensä testiskripteissä ei ole tulostusnäyttöjä, koska kukaan ei ole käytettävissä tuijottamaan näyttöä nähdäkseen tällaisen tulosteen automatisoituna.
rivi 30: tätä varsinaista vakuuttelua me teemme. assertGreater on unittestissä määritelty menetelmä.TestCase luokka, jonka avulla voimme tarkistaa, onko jokin lähtö on suurempi kuin jotkut arvo.
unittest.TestCase itse asiassa tarjoaa meille joukon tällaista menetelmää tarkistaa tasa-arvo, suurempi kuin, vähemmän kuin, jne. riippuen siitä, mitä haluat puolustaa. Seuraavassa taulukossa on joitakin yhteisiä assert menetelmiä käytettävissä.
kuten alussa on esitetty, Voit kirjoittaa testitapauksen vetoamalla koodissasi seuraavaan:
unittest.main()
komentoriville voit kirjoittaa tiedoston nimen, jota käytit testitapauksen tallentamiseen.
python google_search_test.py
siinä ajetaan setUp (), sitten test_result_count () ja lopuksi tearDown ().
tuloste on samankaltainen kuin seuraavassa:
jos jokin testi epäonnistuu, näet EPÄONNISTUMISVIESTIN yhdessä epäonnistuneen testimenetelmän kanssa.
se on ensimmäinen onnistunut seleeni / unittest – Testitapauksesi. Onnitteluni! Se on tärkeä virstanpylväs.
Bonus
jos sinulla on höyryä, kehottaisin sinua seuraamaan loput, jotta pääset vielä syvemmälle Selenium/unittest base web-sovelluksen automatisoituun testaukseen.
sanotaan, että haluat testata, onko otsikko yhtä kuin ”Google”.
testikoodi näyttää seuraavalta:
def test_header(self):
self.driver.get("http://www.google.com")
self.assertEqual("Google", self.driver.title)
nyt koko testijuttu näyttää tältä:
class GoogleSearchTest(unittest.TestCase):
def setUp(self): def test_header(self): def test_result_count(self): def tearDown(self):
if __name__ == "__main__":
unittest.main()
oletetaan, että yllä olevat tulostusnäytöt kommentoidaan. Kun suoritat päivitetyn testitapauksen, sinun pitäisi saada tuloste seuraavasti:
test_header (__main__.GoogleSearchTest) ... ok
test_result_count (__main__.GoogleSearchTest) ... ok----------------------------------------------------------------------
Ran 2 tests in 13.799s
OK
se kertoo tehneensä kaksi testiä ja molemmat ovat onnistuneet.
sanotaan, että vaihdan assertevalisen tilan ensimmäisessä testissä seuraavaan:
self.assertEqual("Microsoft", self.driver.title)
mitähän täällä tapahtuisi?
kyllä, arvasit oikein. Ensimmäinen koe epäonnistuu omana itsenään.ohjain.title on yhtä kuin Google, ei Microsoft.
saat seuraavan kaltaisen ulostulon:
test_header (__main__.GoogleSearchTest) ... FAIL
test_result_count (__main__.GoogleSearchTest) ... ok
====================================================================
FAIL: test_header (__main__.GoogleSearchTest)
--------------------------------------------------------------------
Traceback (most recent call last):
File "google_search_test.py", line 19, in test_header
self.assertEqual("Microsoft", self.driver.title)
AssertionError: 'Microsoft' != 'Google'
- Microsoft
--------------------------------------------------------------------
Ran 2 tests in 14.011s
FAILED (failures=1)
yllä oleva ulostulo kertoo, että vain yksi testi onnistui ja epäonnistunut.
kun kirjoitat koejuttujasi ensimmäistä kertaa, saatat kohdata tämänkaltaisia tilanteita.
olettaen, että testitapauksesi on oikea, tunnistat koodissa olevat virheet ja saat asianomaiset Kehittäjät korjaamaan ongelman ja tekemään uusintatestin.
jos tämä virhe tapahtuu regressiotestissä, tämä vika otetaan käyttöön olemassa olevan koodipohjan päälle tehdyn uuden ohjelmistokehityksen vuoksi.
tämä osoittaa, että uudessa koodipohjassa on jotain vikaa, joka pitää korjata, jotta vanha toiminnallisuus toimii. Jälleen, Kehittäjät täytyy huolehtia siitä.
miten olisi monta koetapausta? Sanotaan, että meillä on TestCase1 ja TestCase2, joissa jokaisessa on useita testejä.
voit luoda niin sanotun testisarjan ja ajaa sen testijuoksulla seuraavasti:
suite = unittest.TestSuite()
suite.addTest(unittest.makeSuite(TestCase1))
suite.addTest(unittest.makeSuite(TestCase2))
runner = unittest.TextTestRunner()
runner.run(suite)
yllä oleva koodi suorittaa kaikki testit TestCase1: ssä ja sen jälkeen TestCase2: ssa.
siinä kaikki tältä päivältä. Toivottavasti se auttaa.