Меню

Как да тествате приложенията на JAVA - Съвети с примерни тестови случаи (част 1)

how test java applications tips with sample test cases

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

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

Това е серия от три части за тестване на JAVA приложения.

  1. В тази статия ще научим компонентите на J2EE и подхода за ръчно тестване за приложение J2EE.
  2. Във втория ще разгледаме Автоматизирано тестване подход за тестване на J2EE приложения и
  3. В третия ще разгледаме изчерпателен списък с инструменти, които са на разположение за тестване на J2EE приложения.

Тестване на JAVA приложения

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

Нека започнем с преглед на J2EE приложенията

ДА СЕ Java уеб приложението се състои от няколко компонента, всеки от които има важна цел. MVC , което е съкращение от Model View Controller, е най-популярният и често използван модел на архитектурен дизайн.

Преди да се научим да тестваме, нека да преминем накратко през различни компоненти на приложение J2EE.

J2EE ПРИЛОЖЕНИЕ Тестване 1

  • Клиент / браузър иска уеб адрес с URL адрес.
  • JSP (Java Server Pages) - JSP е технология от страна на сървъра, предназначена да представя данни на потребителя. Той поддържа показването на динамично съдържание с помощта на специални тагове, наречени JSP тагове, които помагат за вмъкване на Java код в HTML страници. (Статичният HTML винаги показва едно и също съдържание). По време на изпълнение JSP се преобразува в Servlet. Тук обикновено не се пише бизнес логика.
  • JSF (Java Server Faces) - JSF е компонент на рамка за изглед за ефективен дизайн на потребителския интерфейс.
  • Javascript / Jquery - са скриптови езици, използвани за проверка от страна на клиента на изгледа / екрана.
  • Сервлет - Servlet проверява данните, получени от входа, избира подходящия бизнес логически код и предава стойностите на Bean кода.
  • Enterprise Java Bean (EJB) - Тук обикновено се пише и обработва цялата бизнес логика. След това компонентът извиква кода, за да прочете, напише или актуализира базата данни. След като операциите с базата данни приключат, отговорът се прехвърля обратно към сървлета, който от своя страна избира подходящия JSP за показване на резултатите.
  • WebServices - Уеб услугите са компоненти на приложение, които се изпълняват на отделен сървър и комуникират по HTTP протокол.
  • База данни - съхранява всички данни на приложението.

Моля, обърнете внимание, че не всички уеб приложения следват JSP -> Servlet -> EJB -> Модел на база данни . Понастоящем повечето приложения на J2EE са написани с рамка като Struts, Spring или Hibernate. Дизайнът на приложенията варира за всяко изискване в зависимост от размера на приложението, разходите, времето за разработка, ресурсите и размера на екипа.

Тестване на приложението JAVA / J2EE

Нека сега да преминем към тестване на цялото J2EE приложение. Това се прави в няколко стъпки.Например, помислете, че имаме три екрана:

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

Потребителският интерфейс (Потребителски интерфейс) за тези три екрана е разработен с JSP / HTML и проверките, извършени чрез JavaScript. Тъй като това е примерно приложение, логиката е в Servlet и DAO (Обект за достъп до данни). DAO е клас за свързване към базата данни.

По-долу са примерните екрани:

J2EE ПРИЛОЖЕНИЕ Примери за тестване

Приложение за тестване на J2EE Пример 2

J2EE ПРИЛОЖЕНИЕ Пример за тестване 3

Ръчно тестване на Java приложения:

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

# 1) ИЗПИТВАНЕ НА JAVA UNIT

Единичното тестване е вид тестване при което потребителят трябва да тества най-малкия от кодовите фрагменти за точност, коректност и отговаряне на изискванията.

Нека вземемпример за екрана за вход. Екранът за вход има две текстови полета: потребителско име и парола и има два бутона: подаване и отмяна.

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

По-долу е даден примерен формат на тестов случай за екрана за вход.

S.No.Тестов случайочакван резултатДействителен резултатPass / Fail
4Потребителят въвежда потребителско име с повече от 10 знакаСъобщение за грешка
Трябва да се покаже „Потребителското име не трябва да бъде повече от 10 знака“		Съобщението за грешка не се показваФАЙЛ
единПотребителят проверява външния вид на етикетите Потребителско име, ПаролаЕтикетите трябва да бъдат написани правилно и да се показват с нормален размер шрифтПотребителското име и паролата на етикета се показват правилноПРОХОД
двеПотребителят проверява външния вид на бутона
Изпращане и отмяна		Бутоните трябва да се показват с правилното имеБутоните Submit и Cancel се показват правилноПРОХОД
3Потребителят проверява цвета на фона на екранаФормата за вход трябва да бъде в бяла таблица, а екранът да е със сив фонВъншният вид на екрана не отговаря на изискванията.ФАЙЛ
4Потребителят оставя текстовото поле за потребителско име като празноТрябва да се покаже съобщение за грешка „Потребителското име не може да бъде празно“Показва се съобщение за грешка „Потребителското име не може да бъде празно“ПРОХОД
5Потребителят въвежда някаква стойност в текстовото поле за потребителско име и оставя текстовото поле за парола като празноТрябва да се покаже съобщение за грешка „Паролата не може да бъде празна“Показва се съобщение за грешка „Паролата не може да бъде празна“ПРОХОД
6Потребителят въвежда потребителското име като „abcd“, а паролата като „xxxx“Съобщение за грешка
„Невалидна комбинация от пароли за потребителско име“
трябва да се покаже		Съобщение за грешка
„Невалидна комбинация от пароли за потребителско име“
се показва		ПРОХОД
5Потребителят въвежда потребителско име като „testuser” и парола като „парола” и натиска бутона SubmitПотребителят трябва да може да види „Екран с подробности за служителите“Показва се екранът с подробности за служителитеПРОХОД

Докато таблицата изброява някои от тестовите случаи, по-долу е пълният списък:

  • Проверете за изключение, включително изключение на NULL указател
  • Проверете дали NULLS не са разрешени за потребителско име и парола
  • Проверете дали потребителското име / паролата е в правилния формат
  • Проверете дали номерата не са разрешени за потребителско име
  • Проверете дали в Потребителско име не са разрешени специални знаци
  • Проверете дали е въведена правилната комбинация от потребителско име и парола, след което приложението ви отвежда до следващия екран, т.е.екран с информация за служителя
  • Проверете дали въведеното потребителско име е с правилна дължина
  • Проверете дали текстовото поле за потребителско име позволява само максималния брой символи, посочени за това поле
  • Проверете дали полето за парола, ако е посочено в изискванията, се вижда като * при въвеждане
  • Проверете дали паролите са чувствителни към малки и големи букви
  • Проверете дали потребителското име не е чувствително към регистъра
  • Проверете дали страницата за вход не помни потребителското име или паролата, дори и след излизане
  • Проверете дали бутонът Submit и Cancel работи според изискванията
  • Ако използвате приложението за първи път, проверете дали потребителското име има разрешение за влизане в приложението
  • Изтрийте комбинация от потребителско име / парола от базата данни и проверете дали комбинацията не може да влезе отново
  • За всички горепосочени случаи проверете дали са показани съответните съобщения за грешка при проверка
  • Проверете дали етикетите и бутоните са на правилното място на екрана и дали показват правилно текста
  • Проверете дали появата на екрана отговаря на изискванията
  • Проверете дали се обработват изключения
  • Проверете дали се извършва регистриране за необходимите действия

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

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

Прочетете също=> Примерни готови за използване тестови случаи и тестови сценарии за тестване на уеб приложения.

# 2) ИЗПИТВАНЕ НА ИНТЕГРАЦИЯ

При интеграционното тестване отделните модули се интегрират и тестват заедно за коректност.

как да направите дълбоко копие на масив java -

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

Ето някои примерни тестови случаи за интеграция за пример за приложение на служител:

  • Проверете дали потребителят е влязъл и сесията са еднакви във всички останали нови интегрирани екрани
  • Проверете дали другите модули не актуализират / изтриват / вмъкват ненужен запис в базата данни
  • Нека има поле за статус на служител, което казва „Ново“ при добавяне, „Актуализирано“ при модификация и „Изтрито“ при изтриване. Въпреки че два или три екрана могат да използват едно и също поле за състояние, важно е да се уверите, че полето не се актуализира погрешно.
  • Проверете дали заглавката, долният колонтитул, размерът на екрана и външният вид отговарят на изискванията след интеграцията
  • Проверете дали при щракване върху бутоните Submit контролът се прехвърля на следващия екран
  • Проверете дали при щракване върху бутона Отказ извършеното действие е отменено

В допълнение, общите тестови случаи за интеграция за приложение J2EE могат да бъдат:

  • Проверете потока от данни, обект, XML или сесия от край до край. Проверете за коректност.
  • Проверете дали сесията се управлява правилно от всеки от модулите
  • Ако са включени външни приложения (уеб услуги), проверете дали приложението ви е в състояние да осъществява повиквания и да извлича данни обратно от приложението

# 3) ИЗПИТВАНЕ НА СИСТЕМАТА

При системното тестване цялото приложение се тества за функционалност и пълнота по отношение на изискванията. Вероятно би било по-лесно да попитате, когато се извършва модулно тестване на всеки компонент и кодовите компоненти също се комбинират и тестват заедно по време на интеграционното тестване, какво може да бъде различно при системното тестване? Не е неточно да се каже, че идеята в System Testing е да разбие приложението :)

Сценарий # 1: Разработвате ново приложение за служители с рамка;например, Подпори. Има и няколко други приложения, работещи на различни сървъри във вашата организация. Всички те обаче се обаждат на една и съща уеб услуга, за да извлекат адреса и телефонния номер на конкретно лице.

По време на теста за интеграция бихте проверили дали приложението ви може да осъществи повикване към уеб услугата и дали можете да получите отговор. Но какво, ако има проблем в самата уеб услуга? Или уеб услугата не реагира на някои редки входове? В нашия случай уеб услугата може да отнеме само служител с макс. 6 знака. Или уеб услугата изхвърля изключения за определени формати на адрес, докато се връща. Това е външно, но също е част от системното тестване.

Сценарий # 2 : Вашето заявление за служител е попълнено. Добавяте служител и той генерира номер на служител # 1001. Вие модифицирате, изтривате, актуализирате, добавяте, модифицирате, изтривате, добавяте, добавяте, добавяте, модифицирате, изтривате и след това накрая добавяте друг. Ами ако номерът на новия служител отново е # 1001?

Сценарий # 3 : Да приемем, че двама потребители използват приложението едновременно. И двамата започват да работят върху един и същ служител, един изтрива. Какво ще стане, ако другият потребител е в състояние да продължи с модификацията на същите служители, както се съхранява в сесията?

По-долу са дадени някои важни аспекти на системното тестване:

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

# 4) ИЗПИТВАНЕ НА ЕФЕКТИВНОСТТА

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

  • Ако няколко потребители влизат едновременно, проверете дали приложенията не се мотаят / сриват
  • Ако в базата данни е налице голямо количество данни - проверете дали мрежите на екрана за търсене не отнемат много време за изпълнение на заявки преди изтичането на сесията
  • В многонишкова среда проверете дали приложението може да се справи добре с всички нишки
  • В приложения, при които се създават голям брой обекти, проверете дали е разпределена достатъчна памет, обработва ли се събирането на боклук и дали няма изключения извън паметта

Заключение

В тази статия разгледахме общ преглед на приложение J2EE. Видяхме също как ръчно да изпълняваме Unit, Integration, Functional и System тестване за всеки от компонентите на приложението с пример.

В следваща статия , ще видим как тестването на автоматизацията може да бъде от полза за големи J2EE приложения.

За автора: Това е статия за гости от Padmavaty S. С общо 7+ години опит в тестването на софтуер, тя има богат опит в тестването на Java, J2EE, MVC и Struts framework.

Уведомете ни, ако работите по тестване на JAVA приложения. Споделете своя опит и въпроси в коментари по-долу.

PREV Урок | СЛЕДВАЩ урок

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

^