how translate manual test cases into automation scripts
Ово ће бити основни чланак 'како да' и није специфичан за било који алат за аутоматизацију. У основи, оно што овде покушавам је да срочим процес размишљања који иде у стварање случаја теста аутоматизације. Као и увек, надам се да ће ово бити корисно за све вас.
Како дизајнирати тест случаја или скрипте за аутоматизацију?
Аутоматизација увек следи ручно тестирање. Обично би се један или више кругова ручног тестирања већ извео на АУТ. То подразумева да случајеви ручног тестирања већ постоје и да су извршени најмање једном.
На пример, претпоставимо да је следеће ваше Ручни тест случај . То је једноставно пријављивање на веб локацију Гмаил.цом. Ово изгледа довољно једноставно, зар не? Како ово постаје скрипта за аутоматизацију? (кликните на слику за увећање)
Шта ћете научити:
Како превести овај ручни тест у скрипту за аутоматизацију?
Следе смернице које ћемо следити да бисмо постигли превод у скрипту за аутоматизацију:
# 1) Стање АУТ: Предуслов колоне није ништа друго него одређено стање позадине које треба поставити за одређени корак који треба извршити. Ово је посебно важно у два сценарија:
- Да бисте започели тест: У овом случају, потребан нам је прегледач који је доступан и покренут. (Доступност корисничког имена и лозинке рјешаваће се за кратко вријеме). Сад, како написати исту ствар у свету аутоматизације? Узмите у обзир КТП. Можете да покренете прегледач помоћу програмских изјава или да користите дијалог „подешавање снимања и покретања“ да бисте подесили својства. Правилно подешавање ових својстава је веома важно. То је често разлог зашто ће одређени део кода радити у машини, а неће радити у осталим.
- Да бисте извршили одређени корак : Да би се извео корак 2, потребно је извршити и довршити корак 1. Да бисмо то урадили ручно, можемо само да сачекамо док се изврши корак и страница се у потпуности учита. Користите синхронизацију или сачекајте изјаве у скрипти за аутоматизацију да сачекате док се жељено стање не оствари.
Белешка: Када покрећете исти код за више скупова података, желели бисте да будете сигурни да враћате АУТ у стање које би требало да буде пре почетка следеће итерације.
# 2) Кораци тестирања
Кораке ручног тестирања можемо сврстати у 3 категорије:
- Унос података : Кораци за унос података су место где уносите неке информације као улаз у свој АУТ.
- Промена корака АУТ стања : ови кораци су ти који ће довести до промене на вашем АУТ. То може укључивати одлазак на нову страницу, одређено поље је видљиво, оквир за уређивање који се може уређивати итд.
- Комбинација : како само име говори, ово је комбинација оба наведена типа. Узмите случај поља за потврду, када је укључено, одређено поље ће бити активно. У том случају у поље за потврду уносите вредност „Тачно“, а то такође доводи до стања вашег АУТ.
У горе наведеном тест случају постоје само кораци типа 1 и 2.
- Тип 1: кораци испитивања 2 и 3
- Тип 2: Испитни кораци 1 и 4
Предуслов за стварање скрипте за аутоматизацију помоћу било ког алата је провести неко време у анализирању алата као и АУТ. Покушајте да видите како обојица међусобно комуницирају. На пример, КТП има 3 начина снимања и сваки ради на другачији начин.
Ако знате како идентификује објекте, знали бисте који ћете користити и боље их користити. Ако имате веб апликацију у којој КТП може лако да идентификује објекте, можете да користите уобичајени режим. Ако не, можда ћете морати да користите аналогне методе или методе ниског нивоа.
Кораци аутоматизације:
- Кораци за унос података се не разликују у методама аутоматизације и ручним методама. Све што радите је да унесете податке. Начин на који референцирате поље је другачији. Будући да ће то бити машина која изводи кораке, морамо само да се побринемо да се упутимо на поља у АУТ на начин који алат разуме. То значи да морате да користите његов логички назив као што се користи у коду.
- За промену корака АУТ / комбинација у ручном сценарију извршите радњу (кликом или провером или уносом) и потврђујући промену једним потезом. Али у сценарију аутоматизације то није могуће. Зато морамо бити сигурни да смо додали кораке за акцију и валидацију / верификацију.
- Коментари ради читљивости.
- Изјаве за отклањање грешака - ово је посебно важно у коме креирате и тестирате сам тест. Покушајте да често користите оквире за поруке за изношење различитих вредности у различитим фазама извршавања теста. Ово ће вам пружити видљивост у тесту као што ништа друго не би.
- Излазне изјаве - до пишите у резултате или на било које друго спољно место попут бележнице или екцел листа.
# 3) Верификација и валидација
Без верификације и валидације намера тестирања је изгубљена. Типично ћете морати да користите контролну тачку (не мора да значи и уграђену). Дакле, за изградњу логике мораћете да користите пуно условних изјава, као и изјаве петље.
Важна ствар коју треба узети у обзир је - атрибут на основу којег заснивате свој В&В не би требало да буде двосмислен. На пример, за успешно пријављивање потражите приказ странице пријемног сандучета, а не број нових е-адреса, јер то није константна вредност.
Дакле, морате одабрати нешто истинито сваки пут кад се сет операција догоди - без грешке.
# 4) Тест подаци
Следе нека од питања на која бисте могли одговорити у складу са захтевима за податке о тестирању:
- Где га сместити?
- Да хардцоде или не?
- Питања безбедности?
- Питања поновне употребљивости?
Када се осврнете на скрипту за ручно тестирање, приметићете да је расположивост података о тесту, корисничког имена и лозинке један од предуслова да се тест уопште започне.
# 5) Резултати
За случај ручног теста, резултат сваког корака можете ставити у колону „Стварни резултат“. Датотека резултата алата за аутоматизацију садржи резултат сваког корака када се изврши.
Алати за аутоматизацију данас имају врло робусне функције извештавања. Међутим, можда ћете ипак морати да прилагодите Резултати теста . Дакле, укључите кораке за често писање у датотеку резултата, тако да ћете тачно знати шта се дешавало док се извршавало извршење.
Ако алат који користите не подржава записивање у датотеку резултата коју генерише, добра идеја је да уз сваки тест буде повезан барем Екцел лист или бележница како бисте у току коментарисали статус извршења.
# 6) Пост Операције
Када завршите са тестирањем, не морате изричито напомињати у свом случају ручног тестирања да бисте затворили прегледач или затворили АУТ итд. Као тестер, то бисте радили марљиво. У случају случаја аутоматизације, ове кораке можете да укључите у своју скрипту. Чишћење - то ја називам овим активностима. Убијте све везе које сте створили. Затворите све апликације. Ослободите меморију.
Користећи ове смернице, преводим наш случај ручног теста у КТП тест скрипту која користи ВБ скриптовање. Резултат је следећи: (кликните на слику за увећање)
Прођите кроз сваки корак
Корак 1: Предуслов. Програмски покрећемо ИЕ са УРЛ-ом Гмаил.цом.
Корак 2 и 7: Изјава о синхронизацији. Као што смо горе разговарали, ово је важно како би се осигурало да АУТ дође у жељено стање пре него што следи извршење следећег корака.
Корак 3 и 4: Унос података. Сви подаци су кодирани у скрипту. Иако није препоручљиво, то је почетак.
Корак 5: Промена корака АУТ. Корак 5 укључује клик на дугме Пријави се. Неће вам требати В&В када се ова изјава изврши. То је зато што постоји наредна изјава и ако то може да се покрене; то значи онај пре него што је био успешан. Али ако сте изузетно вредни, овде можете да га укључите.
бесплатно преузимање софтвера за часовник запослених
Корак 6 и 8: Коментари
Корак 9 и 11: Условна изјава. В & В / Цхецкпоинт. Покушавамо да утврдимо да ли је пријава била успешна провером да ли постоји веза до пријемног сандучета на резултујућој страници. Ако пажљиво бележите, тражи се веза са унутрашњим текстом, „инбок. *“. Дакле, без обзира на било који број нових е-порука (које су променљиве), ако имате на располагању везу до улазног сандучета (која је увек константа), то значи да је контролна тачка прошла.
Корак 10: Оквир за поруке. Ради видљивости
Кораци 12 и 13: Ово су активности чишћења. Одјављујете се са налога и затварате прегледач.
Закључак
Дакле, видите како се лако развија скрипта за аутоматизацију када имате добро написану ручну скрипту и скуп основних смерница које треба следити. Пошто ово није чланак који се тиче оквири , Клонио сам се функција, фактора поновне употребљивости, параметризације итд. Тест скрипта је основни градивни блок, лако је импровизовати скрипту када имате основе у праву.
Да ли постоје неки други фактори које узимате у обзир, неки други начин који вам је лакши или нека смерница која вам је тешко следити? Обавестите ме о повратним информацијама у коментарима.
Ову поруку написао је члан СТХ тима Свати Сеела. Има више од 9 година искуства са ручним и аутоматизацијским тестирањем рада са разним МНЦ-има. Она је такође наш инструктор за Курс за КА тестирање софтвера . Ако сте заинтересовани за овај курс да бисте проверили предстојећи распоред серија овде .
ПРЕВ Туториал |. | СЛЕДЕЋА Лекција
Препоручено читање
- Процес тестирања аутоматизације у 10 корака: Како започети тестирање аутоматизације у својој организацији
- Зашто нам је потребан оквир за аутоматизацију испитивања?
- Изазови ручног и аутоматизованог испитивања
- Како се разликује планирање теста за ручне и аутоматизационе пројекте?
- Како одлучити која врста тестирања је потребна за пројекат? - Ручно или аутоматизација
- Шта је испитивање аутоматизације (ултимативни водич за покретање аутоматизације теста)
- КТП Фрамеворкс - Тест Аутоматион Фрамеворкс - Примери вођени кључним речима и линеарни оквири - КТП водич # 17
- 10 најбољих стратегија аутоматизације и најбоље праксе