Агульныя памылкі аўтаматызацыі тэстаў

У гэтым артыкуле мы разгледзім некаторыя найбольш распаўсюджаныя памылкі аўтаматызацыі тэстаў і тое, як яны перашкаджаюць арганізацыям дамагчыся поспеху ў аўтаматызацыі тэстаў.

Не цяжка ўявіць перавагі аўтаматызаванага тэсціравання разам з распрацоўкай прадукту - больш хуткія выпускі, павелічэнне ахопу тэстаў, частае выкананне тэстаў, больш хуткая зваротная сувязь з камандай распрацоўшчыкаў, каб назваць некалькі, але многія арганізацыі не зрабілі гэтага альбо ўжо ўстойлівы ў інвеставанні ў аўтаматызацыю выпрабаванняў.



Памылковыя ўяўленні пра аўтаматызацыю тэстаў

Магчыма, самым складаным і складаным аспектам любой спробы аўтаматызацыі тэстаў з'яўляецца разуменне абмежаванняў аўтаматызаванага тэсціравання і пастаноўка рэалістычных мэтаў і чаканняў, каб пазбегнуць расчараванняў. Маючы гэта на ўвазе, давайце паглядзім некаторыя найбольш распаўсюджаныя непаразуменні і міфы пра аўтаматызацыю тэстаў:


Аўтаматызаванае тэсціраванне лепш, чым ручное

Спасылаючыся на паведамленне ў блогу Майкла Болтана Тэставанне супраць праверкі , аўтаматызаванае тэсціраванне на самай справе не з'яўляецца тэставаннем. Гэта праверка фактаў. Калі мы маем разуменне сістэмы, мы можам забяспечыць гэта разуменне формамі праверак, а затым, запускаючы аўтаматызаваныя праверкі, мы пацвярджаем сваё разуменне. З іншага боку, тэставанне - гэта расследаванне, пры якім мы імкнемся атрымаць новую інфармацыю пра выпрабаваную сістэму шляхам даследавання.

Тэставанне патрабуе ад чалавека абгрунтаванага меркавання адносна зручнасці выкарыстання сістэмы. Мы можам выявіць анамаліі, калі не чакалі. Мы не павінны паблажліва ставіцца да таго ці іншага, бо для атрымання разумення якасці заяўкі неабходны абодва спосабы.


Дасягненне 100% аўтаматызаванага тэсціравання

Падобна таму, як не існуе практычнага спосабу 100-адсоткавага ахопу тэстаў (з-за бясконцых магчымых перастановак), тое ж самае тычыцца і аўтаматызацыі тэстаў. Мы можам павялічыць ахоп тэстаў, запусціўшы аўтаматызаваныя тэсты з вялікай колькасцю дадзеных, большай колькасцю канфігурацый, якія ахопліваюць цэлы шэраг аперацыйных сістэм і браўзэраў, але дасягненне 100% усё яшчэ нерэальная мэта. Калі гаворка ідзе пра аўтаматызаванае тэсціраванне, большая колькасць тэстаў не абавязкова азначае больш высокую якасць альбо большую ўпэўненасць. Усё залежыць ад таго, наколькі якасна распрацаваны тэст. Замест таго, каб імкнуцца да поўнага ахопу, сканцэнтруйцеся на найбольш важнай сферы функцыянальнасці, якая мае вырашальнае значэнне для бізнесу.



Хуткая рэнтабельнасць інвестыцый

Пры рэалізацыі рашэння для аўтаматызацыі тэстаў існуюць іншыя ўзаемазвязаныя мерапрыемствы па распрацоўцы, чым проста стварэнне сцэнарыяў тэставых прыкладаў. Звычайна неабходна распрацаваць структуру, якая можа падтрымліваць спецыяльныя аперацыі, карысныя і значныя для бізнесу, такія як выбар тэставых выпадкаў, справаздачнасць, кіраванне дадзенымі і г.д.

Распрацоўка платформы - гэта самастойны праект, які патрабуе кваліфікаваных распрацоўшчыкаў і патрабуе часу для стварэння. Нават калі дзейнічае цалкам функцыянальная структура, сцэнары аўтаматызаванай праверкі спачатку займаюць больш часу, чым выкананне аднаго і таго ж тэсту ўручную. Таму, калі нам патрабуецца хуткая зваротная сувязь па новай функцыі, якая толькі што была распрацавана, праверка яе ўручную звычайна хутчэй, чым аўтаматызацыя тэсту. Аднак ROI вяртаецца ў доўгатэрміновай перспектыве, калі нам трэба выконваць адны і тыя ж тэсты праз рэгулярныя прамежкі часу.

Больш высокі ўзровень выяўлення дэфектаў пры дапамозе аўтаматызаваных праверак

Хаця многія пастаўшчыкі і вырабы для аўтаматызацыі тэстаў, якія пастаўляюцца ўласнымі вадкасцямі, вельмі дасканалыя і здольныя выконваць складаныя аперацыі, яны ніколі не змогуць скласці канкурэнцыю інтэлекту чалавечага выпрабавальніка, які можа выявіць нечаканыя анамаліі ў дадатку падчас вывучэння альбо выкананне набору сцэнарыяў тэстаў супраць сістэмы, якая выпрабоўваецца. Як ні дзіўна, але людзі чакаюць, што аўтаматызаванае тэставанне выявіць шмат памылак з-за нібыта павялічанага ахопу тэстаў, але на самой справе гэта не так.


Сапраўды, аўтаматызаваныя тэсты добра ўлоўліваюць праблемы рэгрэсіі - пасля таго, як у існуючую базу кода была дададзена новая функцыя, нам неабходна пераканацца, што мы не парушылі бягучую функцыянальнасць і нам патрэбная гэтая інфармацыя хутка, - але колькасць праблем з рэгрэсіяй, у большасці выпадкаў, як правіла, значна менш, чым новая функцыянальнасць, якая распрацоўваецца.

Яшчэ адзін момант, пра які трэба памятаць, - гэта тое, што аўтаматызаваныя праверкі правяраюць толькі тое, што было запраграмавана праверыць чалавекам, які напісаў сцэнар. Сцэнарыі такія ж добрыя, як і чалавек, які іх напісаў. Усе аўтаматызаваныя праверкі могуць з радасцю прайсці, але асноўныя недахопы могуць застацца незаўважанымі, што можа стварыць ілжывае ўражанне аб якасці прадукту. Па сутнасці, праверка можа даказаць наяўнасць дэфектаў, але не можа даказаць іх адсутнасць.

Патрабуецца толькі аўтаматызацыя модульных выпрабаванняў

Такім чынам, калі верагоднасць выяўлення дэфектаў большая пры тэставанні новых функцый, чаму б нам не запусціць нашы аўтаматызаваныя тэсты супраць новай функцыянальнасці па меры яе распрацоўкі? Ну, гэта некалькі тычыцца каманд, якія займаюцца TDD .

Распрацоўшчыкі спачатку пішуць адзінкавы тэст, назіраюць за яго няўдачай, а потым пішуць дастатковую колькасць кода, каб прайсці модульны тэст, і цыкл паўтараецца да таго часу, пакуль не будзе забяспечана прадугледжаная функцыянальнасць. Па сутнасці, гэтыя аўтаматызаваныя модульныя тэсты правяраюць новую функцыянальнасць, і з цягам часу яны ўтвараюць пакет рэгрэсіі блокаў, які неаднаразова выконваецца па меры паступлення новай функцыянальнасці.


Але ў гэтым ёсць засцярога. У той час як TDD настойліва рэкамендуецца і з'яўляецца моцнай практыкай распрацоўкі ў галіне стварэння якасці ад падставы, адзінкавыя тэсты добра выяўляюць толькі памылкі праграміста, а не збоі. Існуе значна большы аспект тэсціравання, які адбываецца, калі ўсе кампаненты звязаны паміж сабой і ўтвараюць сістэму.

На самай справе ў большасці арганізацый большасць аўтаматызаваных праверак праводзіцца на ўзроўні сістэмнага інтэрфейсу. Аднак аўтаматызаваная праверка сцэнарыяў для карыстацкага інтэрфейсу або сістэмы падчас распрацоўкі функцый у лепшым выпадку з'яўляецца няпростай задачай, паколькі новая функцыянальнасць, як правіла, няўстойлівая (падвяргаецца шматлікім зменам) падчас распрацоўкі. Акрамя таго, чаканая функцыянальнасць можа быць вядомая пазней, таму марнаваць час на аўтаматызацыю змены функцыянальнасці не рэкамендуецца.

Мы патрабуем толькі аўтаматызацыі карыстацкага інтэрфейсу

У запуску аўтаматызаваных праверак на ўзроўні карыстацкага інтэрфейсу і сістэмы ёсць значэнні. Мы бачым, што адчувае карыстальнік пры ўзаемадзеянні з дадаткам; мы можам праверыць скразныя патокі і 3рдпартыйная інтэграцыя, калі мы не маглі праверыць інакш; мы таксама можам прадэманстраваць тэсты для кліентаў і канчатковых карыстальнікаў, каб яны маглі адчуць пакрыццё тэсту. Аднак спадзяванне выключна на аўтаматызаваныя праверкі на ўзроўні карыстацкага інтэрфейсу мае свае праблемы.

Карыстацкі інтэрфейс пастаянна змяняецца для паляпшэння візуальнага дызайну і зручнасці выкарыстання, а аўтаматызаваныя праверкі не атрымліваюцца з-за змяненняў карыстацкага інтэрфейсу, а не змяненняў функцыянальных магчымасцей, і стварае ілжывае ўражанне пра стан прыкладання.


Аўтаматызаваныя праверкі карыстацкага інтэрфейсу таксама значна больш павольныя па хуткасці выканання, чым на ўзроўні блока альбо API, і таму цыкл зваротнай сувязі з камандай павольны. Можа прайсці некалькі гадзін, перш чым дэфект будзе заўважаны і паведамлены распрацоўшчыкам. І калі нешта адбываецца не так, аналіз першапрычыны займае больш часу, таму што не так проста зразумець, дзе знаходзіцца памылка.

Важна разуменне кантэксту кожнага тэсту і таго, на якім узроўні тэст павінен быць аўтаматызаваны. Аўтаматызацыя тэстаў павінна быць часткай дзейнасці па распрацоўцы, таму за аўтаматызацыю тэстаў адказвае ўся каманда, у якой распрацоўшчыкі пішуць выкананне модульных тэстаў, распрацоўшчыкі праграмнага забеспячэння ў тэставай форме выконваюць і падтрымліваюць прыёмныя выпрабаванні ў API і / або карыстацкім інтэрфейсе.

Страта веры і даверу да тэставай аўтаматызацыі

Гэты апошні - не міф пра аўтаматызацыю тэстаў, а пабочны эфект, калі аўтаматызацыя тэстаў ідзе не так. Вы марнуеце шмат гадзін на распрацоўку ідэальнага рашэння для аўтаматызацыі тэстаў, выкарыстоўваючы лепшыя інструменты і лепшыя практыкі, але калі аўтаматызаваныя праверкі не дапамагаюць камандзе, гэта нічога не варта.

Калі каманда не мае бачнасці і ведаў пра тое, што аўтаматызавана і выконваецца, яны альбо выпускаюць са страху перад невядомым, альбо дублююць свае спробы рэгрэсійнага тэсціравання. Калі аўтаматызаваныя праверкі няўстойлівыя, павольныя, даюць перыядычныя вынікі, гэта можа збянтэжыць каманду больш, чым забеспячэнне ахоўнай сеткай і павышэннем упэўненасці.


Не бойцеся выдалення аўтаматызаваных праверак, якія заўсёды даюць збой або даюць супярэчлівыя вынікі. Замест гэтага імкнецеся да чыстага і надзейнага набору тэстаў, якія могуць даць правільныя ўказанні на здароўе прыкладання.



Выснова

Тэставая аўтаматызацыя - гэта доўгатэрміновая інвестыцыя. Для распрацоўкі і падтрымання асноў аўтаматызацыі тэстаў і аўтаматызаваных сцэнарыяў спатрэбіцца час і вопыт. Аўтаматызацыя тэстаў - гэта не аднаразовая праца, калі вы дастаўляеце рашэнне і пускаеце яго ў дзеянне. Ён мае патрэбу ў пастаянным кантролі і абнаўленні.

Замест таго, каб імкнуцца замяніць ручныя кантролі якасці або чакаць, што аўтаматызаваныя праверкі выявяць мноства дэфектаў, мы павінны замест гэтага прыняць на сябе перавагі, якія гэта прыносіць камандзе, напрыклад, вызваліць час кантролю якасці для больш даследчых выпрабаванняў, дзе шанцы на выяўленне дэфектаў максімальны, альбо выкарыстанне аўтаматызаваных скрыпты для стварэння тэставых дадзеных, якія можна выкарыстоўваць для ручнога тэсціравання.

Разуменне абмежаванняў і рэалістычныя чаканні важныя для пераадолення гэтых міфаў пра аўтаматызацыю тэстаў.