Парады па аўтаматызацыі выпрабаванняў і лепшыя практыкі

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

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

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




Кіраўніцтва супраць аўтаматызаванага - Тэставанне супраць праверкі

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

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




Аўтаматызацыя рэгрэсійных тэстаў

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

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



Дызайнерскія выпрабаванні перад іх аўтаматызацыяй

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

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


Акрамя таго, не варта скарачаць аб'ём тэсціравання, каб прымусіць яго працаваць ці прайсці яго.



Выдаліце ​​нявызначанасць з аўтаматызаваных тэстаў

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

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

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


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



Праверце аўтаматызаваныя тэсты на сапраўднасць

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

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

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




Не аўтаматызуйце няўстойлівую функцыянальнасць

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

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

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



Не чакайце магіі ад тэставай аўтаматызацыі

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


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



Не спадзявайцеся толькі на аўтаматызацыю - сцеражыцеся здаць тэсты

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

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

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



Імкненне да хуткай зваротнай сувязі

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

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

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



Зразумець кантэкст

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

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

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

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

На ўзроўні карыстацкага інтэрфейсу мы аўтаматызуем сцэнарыі, а не гісторыі.



Не аўтаматызуйце кожны тэст

100% тэставае пакрыццё немагчыма, бо камбінацый можа быць мільёны. Мы заўсёды выконваем падмноства магчымых тэстаў. Той жа прынцып распаўсюджваецца на аўтаматызаванае тэсціраванне.

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

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

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

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



Выкарыстоўвайце тэставыя метады ў аўтаматызацыі тэстаў

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



Не аўтаматызуйце хаос

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

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

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

Ці ёсць у вас якія-небудзь парады па аўтаматызацыі выпрабаванняў, якія трэба дадаць у гэты спіс?

Цікавыя Артыкулы