Papat saka limang pelamar QA pengin sinau cara nggarap tes otomatis. Ora kabeh perusahaan bisa ngrampungake kepinginan penguji manual sajrone jam kerja. Wrike nganakake sekolah otomatisasi kanggo karyawan lan nyadari kepinginan iki kanggo akeh. Aku melu ing sekolah iki persis minangka siswa QA.
Aku sinau carane bisa karo Selenium lan saiki independen ndhukung nomer tartamtu saka autotes karo sakbenere ora bantuan njaba. Lan, adhedhasar asil pengalaman bebarengan lan kesimpulan pribadi, aku bakal nyoba golek rumus kanggo sekolah otomatisasi sing paling cocog.
Pengalamane Wrike nata sekolah
Nalika kabutuhan sekolah otomatis dadi cetha, organisasi kasebut tiba ing Stas Davydov, pimpinan teknis otomatisasi. Sapa maneh kajaba dheweke bisa nerangake kenapa dheweke nggawe inisiatif iki, apa dheweke entuk asil lan apa dheweke getun wektu sing ditindakake? Ayo menehi lantai:
- Ing 2016, kita nulis framework anyar kanggo autotests lan digawe supaya dadi gampang kanggo nulis tes: langkah normal katon, struktur dadi luwih dingerteni. We teka munggah karo idea: kita kudu ndherek saben wong sing pengin nulis tes anyar, lan kanggo nggawe iku luwih gampang kanggo ngerti, kita nggawe seri saka ceramah. Kita bebarengan nggawe rencana topik, saben dosen mangsa njupuk siji lan nyiapake laporan.
- Apa kesulitan sing dialami siswa?
- Utamane, mesthi, arsitektur. Ana akeh pitakonan babagan struktur tes kita. Ing saran, akeh sing ditulis babagan topik iki lan kita kudu nganakake ceramah tambahan kanggo nerangake kanthi luwih rinci.
- Apa sekolah mbayar?
- Ya, mesthi. Thanks kanggo dheweke, akeh wong sing melu nulis tes, lan, rata-rata, ing rumah sakit, kabeh wong wiwit luwih ngerti apa autotests, carane ditulis lan cara diluncurake. Beban ing insinyur otomasi uga wis suda: saiki kita nampa panjaluk luwih sithik kanggo mbantu nganalisa tes, amarga panguji lan pangembang wis wiwit ngrampungake iki ing meh kabeh kahanan. Ya, ana sawetara kaluwihan internal kanggo departemen: kita entuk pengalaman ing presentasi lan ceramah, amarga sawetara insinyur otomatis wis bisa nggawe presentasi ing konferensi, lan uga nampa set video lan presentasi sing kuat kanggo para pendatang anyar.
Atas jenenge dhewe, aku bakal nambah manawa komunikasi antarane departemen kita wis disederhanakake nganti tingkat sing gampang banget. Contone, saiki aku ora perlu mikir babagan kasus lan ing tingkat atomisitas apa sing bakal diotomatisasi. AkibatΓ©, kabeh pihak sing kasengsem ngurus jangkoan tes, sing terus berkembang. Ora ana sing nuntut sing ora mungkin saka wong liya.
UmumΓ©, pengaruh ing karya tim mesthi positif. Mungkin kanca-kanca sing maca artikel iki uga mikir babagan tumindak sing padha? Banjur saran bakal prasaja: iku worth yen tes otomatis dadi prioritas kanggo sampeyan. Sabanjure, kita bakal ngomong babagan pitakonan sing luwih rumit: carane ngatur kabeh iki kanthi bener, supaya biaya kabeh pihak minimal lan output maksimal.
Tips kanggo ngatur
Sekolah iki migunani, nanging, minangka Stas ngakoni, ana sawetara kangelan, kang perlu kanggo ngatur ceramah tambahan. Lan minangka mahasiswa anyar sing mbandhingake aku-ing-ora ngerti lan aku-saiki aku ngrumusake langkah-langkah ing ngisor iki kanggo nggawe, miturut pendapatku, cara sing cocog kanggo ngajar penguji supaya ngerti tes otomatis.
Langkah 0. Nggawe kamus
Mesthi, langkah iki dibutuhake ora mung kanggo QA. Nanging, aku pengin nggawe eksplisit: basis kode otomatis kudu disimpen ing wangun sing bisa diwaca. Basa pemrograman - paling ora basa, lan saka iki sampeyan bisa miwiti nyilem.
Iki minangka gambar tampilan tugas kanthi jeneng unsur kasebut. Bayangake sampeyan lagi nyoba taskview minangka kothak ireng lan durung nate ndeleng Selenium sajrone urip sampeyan. Apa kode iki nindakake?
(Spoiler - tugas dibusak liwat ngaso atas jenenge admin, lan banjur kita weruh sing ana rekaman iki ing stream.)
Langkah iki mung ndadekake basa QAA lan QA luwih cedhak. Luwih gampang kanggo tim otomasi kanggo njlentrehake asil lari; penguji manual kudu kurang gaweyan kanggo nggawe kasus: bisa digawe kurang rinci. Nanging, saben wong ngerti saben liyane. We nampa winnings malah sadurunge latihan nyata diwiwiti.
Langkah 1. Baleni frasa
Ayo diterusake podo karo basa. Nalika kita sinau ngomong minangka bocah, kita ora miwiti saka etimologi lan semantik. Kita mbaleni "ibu", "tuku dolanan", nanging aja langsung menyang akar Proto-Indo-Eropa saka tembung kasebut. Dadi ing kene: ora ana gunane nyilem menyang jero banget fitur teknis autotes tanpa nyoba nulis sing bisa digunakake.
Iku muni sethitik counterintuitive, nanging bisa.
Ing pawulangan pisanan, iku worth menehi basis carane nulis autotests langsung. Kita mbantu nyiyapake lingkungan pangembangan (ing kasusku, Intellij IDEA), nerangake aturan basa minimal sing perlu kanggo nulis cara liya ing kelas sing wis ana nggunakake langkah-langkah sing ana. Kita nulis siji utawa loro tes karo wong-wong mau lan menehi peer, kang aku format kaya iki: cabang saka master, nanging sawetara tes wis dibusak saka iku. Mung katrangane sing isih ana. Kita njaluk penguji kanggo mulihake tes kasebut (ora liwat show diff, mesthi).
AkibatΓ©, wong sing ngrungokake lan nindakake kabeh bakal bisa:
- sinau kanggo nggarap antarmuka lingkungan pangembangan: nggawe cabang, hotkeys, commits lan push;
- nguasai dasar-dasar struktur basa lan kelas: ing ngendi kanggo nglebokake injeksi lan ing ngendi ngimpor, kenapa anotasi dibutuhake, lan apa jenis simbol sing ditemokake ing kana, saliyane langkah-langkah;
- ngerti prabΓ©dan antarane tumindak, ngenteni lan mriksa, ngendi kanggo nggunakake apa;
- sok dong mirsani prabΓ©dan antarane autotests lan manual mriksa: ing autotests sampeyan bisa narik siji utawa liyane handler tinimbang nindakake tumindak liwat antarmuka. Contone, ngirim komentar langsung menyang backend tinimbang mbukak taskview, milih input, ngetik teks lan ngeklik tombol Kirim;
- ngrumusake pitakonan sing bakal dijawab ing langkah sabanjure.
Titik pungkasan iku penting banget. Jawaban iki bisa gampang diwenehake sadurunge, nanging minangka prinsip piwulang sing penting yaiku jawaban tanpa pitakonan sing dirumusake ora dieling-eling lan ora digunakake nalika pungkasane dibutuhake.
Luwih becik yen ing wektu iki insinyur otomatis saka tim QA menehi tugas kanggo nulis sawetara tes ing perang lan ngidini dheweke subcommit menyang cabang.
Apa ora kanggo menehi:
- kawruh sing luwih jero babagan fungsi lingkungan pangembangan lan basa pamrograman dhewe, sing mung dibutuhake nalika nggarap cabang kanthi mandiri. Ora bakal dieling-eling, sampeyan kudu nerangake kaping pindho utawa kaping telu, nanging kita ngormati wektu insinyur otomatis, ta? Conto: ngrampungake konflik, nambah file menyang git, nggawe kelas saka awal, nggarap dependensi;
- kabeh sing ana gandhengane karo xpath. Serius. Sampeyan kudu ngomong babagan iki kanthi kapisah, sapisan lan banget konsentrasi.
Langkah 2. Njupuk dipikir nyedhaki ing grammar
Ayo elinga screenshot taskview saka langkah #0. Kita duwe langkah sing disebut checkCommentWithTextExists. Penguji kita wis ngerti apa sing ditindakake langkah iki lan kita bisa ndeleng ing jero langkah kasebut lan ngrusak sethithik.
Lan ing njero kita duwe:
onCommentBlock(userName).comment(expectedText).should(displayed());Where onCommentBlock punika
onCommonStreamPanel().commentBlock(userName);Saiki kita sinau ngomong ora "tuku dolanan", nanging "tuku dolanan saka toko Detsky Mir, dumunung ing lemari biru ing rak katelu saka ndhuwur." Perlu diterangake manawa kita nuduhake unsur kanthi urutan, saka unsur sing luwih gedhe (stream -> blok karo komentar saka wong tartamtu -> bagean blok iki ing ngendi teks kasebut lenggah).
Ora, isih durung wektu kanggo ngomong babagan xpath. Cukup sebutno sedhela sing kabeh instruksi iki diterangake dening wong-wong mau lan warisan liwat wong-wong mau. Nanging kita kudu ngomong babagan kabeh matcher lan waiters iki; padha hubungane khusus kanggo langkah iki lan perlu kanggo ngerti apa sing kedados. Nanging aja kakehan: siswa sampeyan bisa nyinaoni pratelan sing luwih rumit dhewe mengko. Paling kamungkinan, kudu, waitUntil, ditampilake ();, ana ();, ora (); kudu cukup.
Peer wis jelas: cabang sing isi sawetara langkah sing dibutuhake kanggo sawetara tes wis dibusak. Ayo testers mulihake lan nggawe roto dadi ijo maneh.
Kajaba iku, yen tim tes ora mung duwe fitur anyar ing pakaryane, nanging uga sawetara koreksi bug, sampeyan bisa njaluk dheweke langsung nulis tes kanggo bug kasebut lan ngeculake. Paling kamungkinan, kabeh unsur wis diterangake, mung sawetara langkah bisa ilang. Iki bakal dadi latihan sing sampurna.
Langkah 3. Kecemplung lengkap
Minangka lengkap bisa kanggo tester sing arep terus nindakake tugas langsung. Pungkasan, kita kudu ngomong babagan xpath.
Pisanan, ayo jelasake manawa kabeh onCommentBlock lan komentar kasebut diterangake dening dheweke.
Total:
"//div[contains(@class, βstream-panelβ)]//a[contains(@class,'author') and text()='{{ userName }}β]//div[contains(@class,'change-wrapper') and contains(.,'{{ text }}β)]"Urutan crita iku penting banget. Pisanan, kita njupuk xpath sing ana lan nuduhake carane tab unsur ngemot siji lan mung siji unsur. Sabanjure, kita bakal ngomong babagan struktur: nalika sampeyan kudu nggunakake WebElement, lan nalika sampeyan kudu nggawe file kapisah kanggo unsur anyar. Iki bakal ngidini sampeyan luwih ngerti warisan.
Sampeyan kudu kanthi tegas nyatakake yen unsur siji minangka tampilan tugas kabeh, ngemot unsur anak - kabeh stream, sing ngemot unsur anak - komentar sing kapisah, lsp. Unsur anak ana ing unsur induk ing kaca lan ing struktur kerangka autotes.
Ing wektu iki, pamirsa kudu ngerti carane diwarisake lan apa sing bisa dilebokake sawise titik ing onCommentBlock. Ing titik iki, kita nerangake kabeh operator: /, //, ., [] lan liya-liyane. Kita nambah kawruh babagan panggunaan menyang beban @class lan liya-liyane sing perlu.
Siswa kudu ngerti carane nerjemahake xpath kanthi cara iki. Kanggo nggabungake - sing bener, peer. Kita mbusak deskripsi unsur kasebut, supaya bisa mulihake karya tes kasebut.
Kenapa dalan tartamtu iki?
Kita ngirim ora overload wong karo kawruh Komplek, nanging kita kudu nerangake kabeh bebarengan, lan iki dilema angel. Path iki bakal ngidini kita pisanan nggawe pamireng takon lan ora ngerti soko lan njawab wong-wong mau ing wayahe sabanjurΓ©. Yen sampeyan ngomong babagan kabeh arsitektur, banjur nalika topik langkah utawa xpath dianalisis, bagean sing paling penting bakal dilalekake amarga ora bisa dingerteni.
Nanging, sawetara sampeyan bakal bisa nuduhake pengalaman babagan carane proses bisa dioptimalake luwih akeh. Aku bakal seneng maca saran sing padha ing komentar!
Source: www.habr.com