Меню

Изпълнение на теста при тестване на софтуер: Точен процес и план с пример

test execution software testing

Опитайте Нашия Инструмент За Премахване На Проблемите

Точен процес и планирайте да изпълните тестови случаи с реални примери.

Днес, в нашия Мини курс за тестване на софтуер , ние напредваме в последния етап на STLC, който е Изпълнение на теста .

Можете да разгледате списъка с всички уроци, публикувани в тази безплатна QA серия за обучение на тази страница: Обучение за тестване на софтуер от край до край по проект на живо.

Изпълнението на теста е без съмнение най-важната и „случваща се“ фаза в STLC а също и целия жизнен цикъл на разработката. Причината е - приносът и работата на всеки екип / член на екипа се потвърждават тук:

Изпълнение на теста при тестване на софтуер

  • Правилно ли е интерпретирал бизнес анализаторът изискванията?
  • Екипът на разработчика превърнал ли е бизнес изискванията във функционални изисквания и в крайна сметка да прави правилен код?
  • Проектирали ли са архитектът на данни и администраторите на данни правилните системи отзад?

Е, изпълнението на теста е мястото, където ще бъдат намерени всички отговори на тези въпроси. Това ни прави QA герои на целия процес на изграждане на софтуер, нали? :)

Изпълнението на теста също е „Тестовата“ част на SDLC.

въпроси и отговори на интервю за бизнес анализатор ppt

След като тестовите случаи бъдат написани, споделени с BAs и Dev екипа, прегледани от тях, промените се съобщават на екипа за QA (ако има такива), екипът за QA прави необходимите поправки - Фазата на тестване е завършена. Приготвянето на тестовите случаи не означава, че можем да започнем тестовото изпълнение. Трябва да имаме готово приложението, освен всичко друго.

Какво ще научите:

Указания за изпълнение на теста

Нека сега направим списък на всички неща, които са важни за разбирането на фазата на тестване:

# 1) The изграждане (кодът, който е написан от екипа на разработчика, е пакетиран в това, което е посочено към компилация - това не е нищо друго, освен инсталиращ се софтуер (AUT), готов за внедряване в QA среда.), който се разполага (с други думи, инсталира се и направени достъпни) за QA средата е един от най-важните аспекти, които трябва да се случат, за да започне Изпълнението на теста.

# две) Изпълнението на теста се случва в QA среда . За да сте сигурни, че работата на екипа за разработчици върху кода не е на едно и също място, където екипът за QA тества, общата практика е да има специална Dev и QA среда. (Има и производствена среда за хостване на приложението на живо).

Това е основно за запазване на целостта на приложението на различни етапи от жизнения цикъл на SDLC. В противен случай в идеалния случай и трите среди са еднакви по природа.

# 3) Размер на тестовия екип не е постоянна от началото на проекта. Когато планът за тестване е стартиран, екипът може просто да има ръководител на екипа. По време на фазата на тестовото проектиране на борда се качват няколко тестера. Изпълнението на теста е фазата, когато екипът е в максималния си размер.

# 4) Изпълнението на теста също се случва в поне 2 цикъла (3 в някои проекти). Обикновено във всеки цикъл ще бъдат изпълнени всички тестови случаи (целият набор от тестове). Целта на първия цикъл е да идентифицира всички блокиращи, критични дефекти и повечето от големите дефекти.

Целта на втория цикъл е да се идентифицират оставащите високи и средни дефекти, да се коригират пропуските в сценариите и да се получат резултати.

# 5) Тестовото изпълнение се състои от- Изпълнение на тестовите скриптове + поддръжка на тестовия скрипт (правилни пропуски в скриптовете) + отчитане (дефекти, състояние, показатели и т.н.) Следователно, при планирането на тази фаза графици и усилията трябва да бъдат оценени като се вземат предвид всички тези аспекти, а не само изпълнението на скрипта.

# 6) След приключване на тестовия скрипт и внедряването на AUT - и преди изпълнението на теста да започне, има междинна стъпка. Това се нарича „Преглед на готовността за изпитване (TRR)“ . Това е нещо като преходна стъпка, която ще завърши фазата на проектиране на теста и ще ни улесни в изпълнението на теста.

За информация относно тази стъпка и примерен „Контролен списък за проверка на готовността за тест“, вижте тази връзка: Контролен списък за тестване на софтуер

# 7) В допълнение към TRR, има още няколко допълнителни проверки, преди да гарантираме, че можем да продължим с приемането на текущата компилация, която е внедрена в QA среда за изпълнение на теста.

Това са Тестове за дим и здрав разум . Подробна информация за това какво е това е на: Какво е тест за дим и здрав разум?

# 8) След успешното завършване на TRR, Smoke and Sanity тестовете, тестовият цикъл официално започва.

какво е добро безплатно почистване на компютър

# 9) Изследователско тестване ще се извърши, след като компилацията е готова за тестване. Целта на този тест е да се увери, че критичните дефекти са отстранени, преди да започнат следващите нива на тестване. Това изследователско тестване се извършва в приложението без никакви тестови скриптове и документация. Също така помага при запознаването с AUT.

# 10) Подобно на другите фази на STLC, работата също е разделена между членовете на екипа във фазата на тестовото изпълнение. Разделението може да се основава на модула или на броя на тестовите случаи или нещо друго, което може да има смисъл.

# единадесет) Първичният резултат от фазата на изпълнение на теста е под формата на отчети, предимно т.е. доклад за дефекти и доклад за състояние на изпълнение на теста. Подробният процес за докладване може да бъде намерен на Отчети за тестови изпълнения.

Нови колони в тестови случаи Документ

Документът Test Case вече трябва да бъде разширен със следните две колони - Състояние и действителен резултат .

( Забележка : За изпълнение на тестови проекти на живо добавихме и актуализирахме тези колони с резултати от тестовото изпълнение в електронната таблица за тестови случаи, предоставена за изтегляне по-долу)

# 1) Графа за състояние

Изпълнението на теста не е нищо друго освен използване на тестовите стъпки на AUT, предоставяне на тестови данни (както е посочено в документа за тестовия случай) и наблюдение на поведението на AUT, за да се види дали отговаря на очаквания резултат или не.

Ако очакваният резултат не е изпълнен, той може да се тълкува като дефект. И състоянието на тестовия случай става „Неуспешно“ и ако се постигне очаквания резултат, състоянието е „Издържано“. Ако тестовият случай не може да бъде изпълнен поради някакви причини (съществуващ дефект или среда, която не се поддържа), състоянието ще бъде „Блокирано“.

Състоянието на тестовия случай, който предстои да бъде изпълнен, може да бъде зададено на Без изпълнение / неизпълнено или може да остане празно.

  • За тестов случай с множество стъпки, ако даден резултат (в средата на стъпките на тестовия случай) очакваният резултат не е изпълнен, състоянието на тестовия случай може да бъде зададено на „Fail“ точно там и не е необходимо да се изпълняват следващите стъпки.
  • Състоянието „Неуспешно“ може да бъде обозначено в червен цвят, ако искате незабавно да обърнете внимание на него.

# 2) Колона с действителен резултат

Това е пространство, където ние, тестерите, можем да запишем какво е отклонението в очаквания резултат. Когато очакваният резултат е изпълнен (или тестов случай, чийто статус е „Pass“), това поле може да остане празно. Защото, ако очакваният резултат е изпълнен, това означава действителният резултат = очакван резултат, което означава, че пренаписването му в колоната на действителния резултат ще бъде повторение и излишък.

Екранна снимка на отклонението може да бъде прикрепена към тази колона за по-голяма яснота какъв е проблемът.

Резултати от тестовото изпълнение за проект OrangeHRM Live

Нека сега вземем OrangeHRM и да извършим тестовото изпълнение въз основа на горепосочените указания.

Ето няколко забележки:

  • Разширеният шаблон за тест.
  • Изследващите тестове, както е посочено, трябва да се извършват без тестови скриптове. Така че, моля не се колебайте да тествате приложението паралелно, както сметнете за добре.
  • Поради ограниченията, които имаме при представянето на проекта на живо под формата на четимо съдържание - в примерния шаблон за изпълнение на тестове е показан само ограничен брой тестови случаи / функционалност на приложението OrangeHRM. Отново, моля, попитайте повече за най-практичното изживяване.
  • Комплектите за тестове Sanity и Smoke също са добавени към документа, за да ви дадат представа за това какъв вид тестови случаи се разглеждат за тези етапи.
  • Дефектите все още не се регистрират, въпреки че състоянието на някои тестови случаи е зададено на „Неуспешно“. Това е така, защото регистрирането на дефектите е следващото най-важно / често се работи по аспект от живота ни като тестери. И така, искаме да се справим подробно с него в следващата статия.

Тестови случаи с резултати от изпълнението:

=> Щракнете тук, за да изтеглите документа за изпълнение на тест.

какво да правя с bin файлове

Съдържа - Резултат от изпълнение на тестови казуси, димни тестове, тестове за здравословно състояние, изследователски тест - електронни таблици

И накрая, ако инструмент за управление на теста е бил използван за създаване и поддържане на тестовия случай, същото може да се използва и за изпълнение на теста. Използването на инструмент улеснява отчитането, но в противен случай процесът на изпълнение на тестовите случаи е същият. Моля, разгледайте тази статия, за да получите представа за как да използвам HP ALM за изпълнение на тестови случаи .

(Щракнете върху изображението за увеличен изглед)

ALM за резултат от теста

Това ни води до края на друг интересен сегмент от процеса на тестване. В следващата и последната статия на това безплатен онлайн курс за тестване на софтуер за QA , ще разгледаме подробно дефектите; завършете теми като „кога да спрете тестването“, показатели и QA подписване.

=> QA Training Day 6: Проследяване на грешки, тестови показатели и тестов изход

Моля, уведомете ни как се справяме и следете следващата статия.

Препоръчително четене

^