Какво е тестване от край до край: Рамка за тестване E2E с примери

what is end end testing

Какво е тестване от край до край: Рамка за тестване E2E с примери

Тестването от край до край е методология за тестване на софтуер за тестване на поток на приложения от началото до края. Целта на тестването от край до край е да симулира реалния потребителски сценарий и да валидира тестваната система и нейните компоненти за интеграция и целостта на данните.

Никой не иска да бъде известен със своите грешки и небрежност, както е и при тестерите. Когато на тестерите се възлага заявление за тестване, от този момент те поемат отговорността и приложението действа и като платформа за показване на техните практически и технически познания за тестване.

Така че, за да го опишем технически, за да се гарантира, че тестването е извършено изцяло, е необходимо да се извърши „ Тестване от край до край ' .

В този урок ще научим какво е тестване от край до край, как се прави, защо е необходимо, какви са използваните матрици, как да създадем специфични тестови случаи от край до край и някои други важни аспекти. Също така ще научим за системното тестване и ще го сравним с теста End to End ..

Истински също => Обучение от край до край по проект на живо - Безплатно онлайн обучение за QA.

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

въпроси и отговори на интервю за техник за техническа помощ pdf

• Какво е тестване от край до край?
• Инструменти за тестване от край до край
  • • # 1) TestCraft
• Как работи тест от край до край?
• E2E Методи за изпитване
• Защо извършваме тестване E2E?
• E2E Testing Design Framework
• Включени показатели
• Заключение
  • Препоръчително четене

Какво е тестване от край до край?

Тестването от край до край е методология за тестване на софтуер за тестване на поток на приложения от началото до края. Целта на това тестване е да симулира реалния потребителски сценарий и да провери тестваната система и нейните компоненти за интеграция и целостта на данните.

Извършва се от началото до края при реални сценарии като комуникация на приложението с хардуер, мрежа, база данни и други приложения.

Основната причина за провеждането на това тестване е да се определят различни зависимости на приложение, както и да се гарантира, че точната информация се съобщава между различните системни компоненти. Обикновено се извършва след приключване на функционалното и системно тестване на всяко приложение.

Нека вземем пример за Gmail:

Цялостната проверка на акаунт в Gmail ще включва следните стъпки:

1. Стартиране на страница за вход в Gmail чрез URL.
2. Влизане в акаунт в Gmail чрез използване на валидни идентификационни данни.
3. Достъп до Inbox. Отваряне на прочетени и непрочетени имейли.
4. Съставяне на нов имейл, отговор или препращане на имейл.
5. Отваряне на Изпратени елементи и проверка на имейли.
6. Проверка на имейли в папката „Спам“
7. Излизане от приложението Gmail, като щракнете върху „излизане“

Инструменти за тестване от край до край

Препоръчан инструмент:

# 1) TestCraft

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

TestCraft е безкодова платформа за автоматизация на тестове Selenium. Неговата революционна AI технология и уникалното визуално моделиране позволяват по-бързо създаване и изпълнение на тестове, като същевременно елиминират режийните разходи за поддръжка на теста.

Тестерите създават напълно автоматизирани тестови сценарии без кодиране. Клиентите намират грешки по-бързо, пускат по-често, интегрират се с подхода CI / CD и подобряват цялостното качество на своите цифрови продукти. Всичко това създава пълно изживяване от край до край.

=> Посетете уебсайта TestCraft

Как работи тест от край до край?

За да разберем малко повече, нека разберем Как работи?

Вземетепримерна банковата индустрия. Сигурно малко от нас са опитвали Запаси. Когато притежателят на сметка Demat закупи която и да е акция, на брокера се дава определен процент от сумата. Когато акционерът продаде този дял, независимо дали получава печалба или загуба, определен процент от сумата отново се дава на брокера. Всички тези транзакции се отразяват и управляват в сметки. Целият процес включва управление на риска.

Когато разгледаме горния пример, като имаме предвид теста от край до край, ще открием, че целият процес включва множество числа, както и различни нива на транзакции. Целият процес включва много системи, които могат да бъдат трудни за тестване.

E2E Методи за изпитване

# 1) Хоризонтален тест:

Този метод се използва много често. Това се случва хоризонтално в контекста на множество приложения. Този метод може лесно да се появи в едно приложение на ERP (Enterprise Resource Planning). Вземете пример за уеб базирано приложение на система за онлайн поръчки. Целият процес ще включва сметки, състояние на запасите на продуктите, както и подробности за доставка.

# 2) Вертикален тест:

При този метод всички транзакции на всяко приложение се проверяват и оценяват от самото начало до края. Всеки отделен слой на приложението се тества, започвайки отгоре надолу. Вземете пример за уеб-базирано приложение, което използва HTML кодове за достигане до уеб сървъри. В такива случаи се изисква API за генериране на SQL кодове срещу базата данни. Всички тези сложни изчислителни сценарии ще изискват правилна проверка и специално тестване. По този начин този метод е много по-труден.

' Тестване на White Box ' както и ' Тестване на черна кутия ' и двете са свързани с това тестване. Или с други думи, можем да кажем, това е комбинацията от предимствата както на тестване на бяла кутия, така и на тестване на черна кутия. В зависимост от типа на разработвания софтуер, на различни нива, както техниките за тестване, т.е. тестването на бяла кутия и черна кутия, се използват както и когато е необходимо. По принцип тестът End to End изпълнява както функционален, така и архитектурен подход за всеки софтуер или програми за валидиране на системните функции.

Тестерите като проверка от край до край, защото писане на тестови случаи от потребител ' и в реалния сценарий, могат да избегнат двете често срещани грешки, т.е. ' липсва грешка ' и ' писане на тестови случаи, които не проверяват реални сценарии ' . Това осигурява на тестерите огромно чувство за постижение.

По-долу са включени няколко насоки, които трябва да се имат предвид при проектирането на тестовите случаи за извършване на този тип тестване:

• Тестовите случаи трябва да бъдат проектирани от гледна точка на крайния потребител.
• Трябва да се съсредоточи върху тестване на някои съществуващи функции на системата.
• Трябва да се вземат под внимание множество сценарии за създаване на множество тестови случаи.
• Трябва да се създадат различни набори от тестови случаи, за да се съсредоточат върху множество сценарии на системата.

Докато изпълняваме всякакви тестови случаи, подобен е случаят и с това тестване. Ако тестовите случаи са „Pass“, т.е. получаваме очаквания изход, казва се, че системата е преминала успешно от край до край тест. По същия начин, ако системата не дава желания резултат, се изисква повторно тестване на тестов случай, като се имат предвид областите на повреда.

Защо извършваме тестване E2E?

В настоящия сценарий, както е показано и на диаграмата по-горе, модерна софтуерна система се състои от нейната взаимовръзка с множество подсистеми. Това превърна модерните софтуерни системи в много сложни.

Тези подсистеми, за които говорим, могат да бъдат в рамките на една и съща организация или в много случаи могат да бъдат и на различни организации. Също така, тези подсистеми могат да бъдат донякъде подобни или различни от настоящата система. В резултат на това, ако има някаква повреда или повреда в която и да е подсистема, това може да повлияе неблагоприятно върху цялата софтуерна система, което води до нейния колапс.

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

• Запазете проверка и извършете проверка на системния поток.
• Увеличете областите на тестово покритие на всички подсистеми, свързани със софтуерната система.
• Открива проблеми, ако има такива с подсистемите и по този начин увеличава производителността на цялата софтуерна система.

По-долу са споменати няколко дейности, които са включени в процеса от край до край:

• Обстойно проучване на изискванията за извършване на това тестване.
• Правилно създаване на тестови среди.
• Обстойно проучване на хардуерните и софтуерните изисквания.
• Описания на всички подсистеми, както и на основната участваща софтуерна система.
• Избройте ролите и отговорностите за всички участващи системи и подсистеми.
• Методи за тестване, използвани при това тестване, както и стандарти, които се спазват, неговото описание.
• Проектиране на тестови случаи, както и матрица на изискванията за проследяване.
• Запишете или запишете входните и изходните данни за всяка система.

E2E Testing Design Framework

Ще разгледаме всичките 3 категории една по една:

# 1) Потребителски функции: Следните действия трябва да бъдат извършени като част от изграждането на потребителски функции:

• Списък на характеристиките на софтуерните системи и техните взаимосвързани подсистеми.
• За всяка функция следете извършените действия, както и входните и изходните данни.
• Намерете връзките, ако има такива между различните функции на Потребителите.
• Разберете естеството на различните потребителски функции, т.е. ако са независими или са за многократна употреба.

# 2) Условия: Следните дейности трябва да се извършват като част от строителните условия, базирани на потребителските функции:

• За всяка потребителска функция трябва да се подготви набор от условия.
• Времето, условията на данните и други фактори, които влияят на потребителските функции, могат да се разглеждат като параметри.

# 3) Тестови случаи: Следните фактори трябва да се имат предвид при изграждането на тестови случаи:

• За всеки сценарий трябва да се създаде един или повече тестови случаи за тестване на всяка функционалност на потребителските функции.
• Всяко едно условие трябва да бъде записано като отделен тест.

Включени показатели

Преминаване към следващите важни дейности или показатели, включени в това тестване :

1. Състояние на подготовката на тестовия случай: Това може да бъде проследено под формата на графика, за да представи напредъка на планираните тестови случаи, които са в процес на подготовка.
2. Седмично проследяване на напредъка на теста: Това включва седмично мъдро представяне на напредъка в изпълнението на тестовите случаи. Тя може да бъде отразена чрез процентно представяне за случаи на преминаване, неуспех, изпълнение, неизпълнение, невалидни и т.н.
3. Състояние и подробен доклад за дефекти: Отчетът за състоянието трябва да се изготвя ежедневно, за да показва състоянието на изпълнение на тестовия случай, както и откритите и регистрирани дефекти според тяхната сериозност. Седмично трябва да се изчислява процентът на отворените и затворените дефекти. Също така, въз основа на тежестта на дефекта и приоритета, състоянието на дефектите трябва да се проследява ежеседмично.
4. Тестова среда: Това проследява определената продължителност на времето на тестовата среда, както и действително използваното време на тестовата среда при извършване на това тестване.

Почти видяхме всички аспекти на това тестване. Сега нека разграничават ' Тестване на системата ' и ' Тестване от край до край ' . Но преди това нека ви дам основна идея за „Тестване на системата“, за да можем лесно да правим разлика между двете форми на тестване на софтуер .

Тестване на системата е формата на тестване, която включва поредица от различни тестове, чиято цел е да извърши пълното тестване на интегрираната система. Системното тестване е основно форма на тестване на черна кутия, където фокусът е върху външната работа на софтуерните системи от гледна точка на потребителя, като се отчитат реалните условия.

Тестването на системата включва:

• Тестване на напълно интегрирано приложение, включително основната система.
• Определете компонентите да взаимодействат помежду си и в системата.
• Проверете желания изход въз основа на предоставения вход.
• Анализирайки опита на потребителя, докато използва различни аспекти на приложението.

По-горе видяхме основното описание на тестването на системата, за да го разберем. Сега ще разгледаме разликите между „Тестване на системата“ и „Тестване от край до край“.

Заключение

Надявам се, че сте научили различни аспекти на тестовете от край до край, като неговите процеси, показатели и разликата между тестване на системата и тестване от край до край.

За всяка търговска версия на софтуера, потвърждението End to End играе важна роля, тъй като тества цялото приложение в среда, която точно имитира реални потребители като мрежова комуникация, взаимодействие с база данни и т.н.

Предимно тестът от край до край се извършва ръчно, тъй като разходите за автоматизиране на такива тестове са твърде високи, за да бъдат предоставени от всяка организация. Това е не само полезно за валидиране на системата, но може да се счита и за полезно за тестване на външна интеграция.

Уведомете ни, ако имате въпроси относно теста от край до край.

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

• Най-добри инструменти за тестване на софтуер 2021 г. (Инструменти за автоматизация на QA теста)
• Основни разлики между тестване на черна кутия и тестване на бяла кутия
• Изтегляне на eBook за тестване на Primer
• Функционално тестване срещу нефункционално тестване
• Учебна програма за курс за тестване на софтуер - подробен план за обучение на онлайн курс
• Какво е тестване за издръжливост при тестване на софтуер (примери)
• Тестване на черна кутия: задълбочен урок с примери и техники
• Какво е тестване на компоненти или тестване на модули (научете с примери)