З чаго пачаць аўтаматызацыю тэстаў для існуючага вэб-сайта?

Андрэй пытаецца:

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

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


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

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


Любыя ідэі / прапановы будуць вельмі ўдзячныя.



Мой адказ:

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

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


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

Звязаныя:

1. Даследуйце

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

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


2. Збор метрык

Збярыце паказчыкі выкарыстання сайта ад групы маркетынгу і / або аналітыкі. Большасць кампаній усталёўваюць на сваім вэб-сайце «тэгі адсочвання», такія як Google Analytics, каб мець магчымасць адсочваць, як карыстальнікі выкарыстоўваюць сайт. Існуе мноства інфармацыі пра паводзіны карыстальніка і агульнае падарожжы карыстальнікаў якія можна атрымаць з гэтых сістэм сачэння.

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

3. Асноўныя сцэнарыі

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

Галоўная старонка -> Вынікі пошуку -> Падрабязнасці пра прадукт -> Уваход / рэгістрацыя кліента -> Рэквізіты аплаты -> Пацверджанне замовы


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

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

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

4. Павелічэнне ахопу

Нататка пра ахоп, тут я не кажу пра тэставае пакрыццё; у цэнтры ўвагі ахоп функцый .


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

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

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

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

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

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

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

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

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