В этом учебном пособии мы расскажем о компонентах Java-приложений и различных видах тестирования, которые необходимо проводить для обеспечения высокого качества ПО.
Подпишитесь на наш ТЕЛЕГРАМ КАНАЛ ПО АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ
Содержание
- Обзор J2EE-приложений
- Тестирование J2EE-приложений на JAVA
- Ручное тестирование Java-приложений
- Заключение
Обзор J2EE-приложений
Веб-приложение на Java состоит из нескольких компонентов, каждый из которых выполняет свою важную функцию. MVC (Model-View-Controller) является наиболее популярным и часто используемым архитектурным паттерном.
Прежде чем перейти к тестированию, давайте кратко рассмотрим различные компоненты J2EE-приложения:
- Клиент (браузер) запрашивает веб-адрес сайта с помощью URL.
- JSP (Java Server Pages) – это технология на стороне сервера, предназначенная для представления данных пользователю. Она поддерживает динамическое отображение данных с помощью специальных тегов, называемых JSP-тегами. JSP-теги помогают вставить Java-код в страницы HTML. Во время выполнения JSP преобразуется в Servlet. Бизнес-логика здесь обычно не пишется.
- JSF (Java Server Faces) – это фреймворк для создания пользовательского интерфейса.
- Servlet -это компонент веб-приложения, который обрабатывает данные, полученные от пользователя, выбирает соответствующий код бизнес-логики и передает данные в компонент Bean.
- Enterprise Java Bean (EJB) – здесь обычно пишется вся бизнес-логика. Bean вызывает соответствующий код для чтения, записи или обновления базы данных. После завершения операций с базой данных ответ передается обратно в Servlet, который, в свою очередь, выбирает соответствующий JSP для отображения результатов.
- Веб-сервисы – это компоненты приложения, которые работают на отдельном сервере и обмениваются данными по протоколу HTTP.
- База данных хранит все данные приложения.
Обратите внимание, что не все веб-приложения следуют модели JSP -> Servlet -> EJB -> база данных. Большинство J2EE-приложений в настоящее время пишутся с использованием фреймворков, таких как Struts, Spring и Hibernate. Архитектура приложений может быть разной. Она зависит от размера приложения, стоимости, времени разработки и ресурсов.
Тестирование J2EE-приложений на JAVA
Теперь перейдем к тестированию J2EE-приложений. Это делается в несколько этапов. Рассмотрим пример, когда у нас в приложении есть три экрана:
- вход в систему
- отображение всех сотрудников организации
- экран изменения/добавления/удаления сотрудника.
Пользовательский интерфейс (UI) для этих трех экранов разрабатывается с помощью JSP/HTML, а валидация выполняется с помощью JavaScript. Логика приложения находится в сервлете и DAO (Data Access Object). DAO – это класс для подключения к базе данных.
Ниже приведены примеры экранов:
Ручное тестирование Java-приложений
Во время ручного тестирования тестировщик готовит тест-кейсы из подробного проектного документа и старается охватить все возможные сценарии и фрагменты кода.
1. Модульное тестирование JAVA
Юнит-тестирование – это вид тестирования, при котором разработчики проверяют свой код на правильность и соответствие требованиям.
Рассмотрим пример экрана входа в систему. Экран имеет два текстовых поля: имя пользователя и пароль, а также две кнопки: “Отправить” и “Отменить”.
Тестовые сценарии должны охватить все циклы и условные операторы. Ниже приведены общие тест-кейсы, которые тестировщик может выполнить вручную при тестировании экрана входа в систему. Результаты затем записываются в документ с тест-кейсами. Например:
| № | Тест-кейс | Ожидаемый результат | Фактический результат | Pass/Fail |
|---|---|---|---|---|
| 1 | Тестировщик проверяет поля “Имя пользователя”, “Пароль” | Надписи полей должны отображаться правильно и иметь нормальный размер шрифта. | Имя пользователя и пароль отображаются правильно | Pass |
| 2 | Тестировщик проверяет кнопки “Отправить” и “Отменить” | Кнопки должны отображаться с правильным названием | Кнопки “Отправить” и “Отменить” отображаются правильно | Pass |
| 3 | Тестировщик проверяет цвет фона экрана | Форма входа должна находиться на белом фоне | Внешний вид экрана не соответствует требованиям. | Fail |
| 4 | Тестировщик оставляет текстовое поле имени пользователя пустым | Должно появиться сообщение об ошибке “Имя пользователя не может быть пустым”. | Сообщение об ошибке “Имя пользователя не может быть пустым” отображается | Pass |
| 5 | Тестировщик вводит некоторое значение в текстовое поле имени пользователя и оставляет поле с паролем пустым | Должно появиться сообщение об ошибке “Пароль не может быть пустым”. | Сообщение об ошибке “Пароль не может быть пустым” отображается | Pass |
| 6 | Тестировщик вводит имя пользователя как “abcd” и пароль как “xxxx” | Должно отобразиться сообщение об ошибке “Неверное сочетание имени пользователя и пароля”. | Сообщение об ошибке “Неверное сочетание имени пользователя и пароля” отображается. | Pass |
| 7 | Тестировщик вводит имя пользователя, состоящее более чем из 10 символов | Должно отобразиться сообщение об ошибке “Имя пользователя не должно превышать 10 символов”. | Сообщение об ошибке не отображается | Fail |
| 8 | Пользователь вводит имя пользователя как “testuser” и пароль как “password” и нажимает на кнопку “Отправить” | Пользователь должен увидеть экран сведений о сотруднике. | Отображается экран сведений о сотруднике | Pass |
Тест-кейсы для тестирования экрана входа
В таблице перечислены лишь некоторые из тест-кейсов. Вот полный список:
- Проверить, не разрешены ли NULLS для имени пользователя и пароля.
- Проверить правильность формата имени пользователя/пароля.
- Проверить, не разрешены ли цифры для имени пользователя.
- Проверить, не разрешены ли специальные символы в имени пользователя.
- Если введена правильная комбинация имени пользователя и пароля, приложение переводит вас на следующий экран, т.е. экран информации о сотруднике.
- Проверить, правильно ли введено имя пользователя.
- Проверить, допускает ли поле с именем пользователя превышение максимального количества символов, указанного для этого поля.
- Проверить, отображается ли поле пароля в виде “*” при заполнении.
- Проверить чувствительность пароля к регистру.
- Проверить чувствительность имени пользователя к регистру.
- Проверить, не запоминает ли страница входа имя пользователя и пароль после выхода из приложения.
- Проверить, работают ли кнопки “Отправить” и “Отменить” в соответствии с требованиями.
- Если пользователь использует приложение впервые, проверить, что у него есть разрешение на вход в приложение.
- Удалить пользователя из базы данных и проверить, не может ли этот пользователь снова войти в систему.
- Для всех вышеперечисленных случаев проверить, отображаются ли соответствующие сообщения об ошибках валидации.
- Проверить, находятся ли кнопки в нужном месте экрана, и правильно ли они отображают текст.
- Проверить, соответствует ли внешний вид экрана требованиям.
- Проверить, обрабатываются ли исключения.
Просмотрев эти тест-кейсы, вы можете понять, что в основном имеете дело с тестированием полей, кнопок, функциональности и валидации определенного экрана. Это верно, поскольку модульное тестирование относится к проверке каждого фрагмента кода и компонента приложения.
Обратите внимание, что вышеприведенные тест-кейсы являются лишь примерами, а реальные тестовые сценарии готовятся на основе конкретного проекта.
2. Интеграционное тестирование
Интеграционное тестирование – это проверка того, как отдельные модули взаимодействуют друг с другом и работают вместе.
Пусть каждый из трех экранов в приведенном выше примере разработан тремя разными членами команды. Теперь, когда они закончили модульное тестирование, пришло время собрать весь код вместе и проверить, хорошо ли он работает. Интеграционное тестирование проводится для того, чтобы убедиться, что данные правильно передаются с одного экрана на другой.
Вот несколько примеров интеграционных тестов для Employee Application:
- Проверить, не обновляют/удаляют/вставляют ли другие модули какие-либо записи в базу данных без необходимости.
- Пусть имеется поле статуса сотрудника, в котором при добавлении указывается ‘New’, при изменении – ‘Updated’, а при удалении – ‘Deleted’. Несмотря на то, что два или три экрана могут использовать одно и то же поле статуса, важно убедиться, что оно не обновляется неправильно.
- Проверить, соответствуют ли размер экрана и внешний вид требованиям после интеграции.
- Проверить, что при нажатии на кнопку Submit управление переходит к следующему экрану.
- Проверить, что при нажатии на кнопку Cancel происходит отмена выполненного действия.
- Если задействованы внешние приложения (веб-сервисы), нужно проверить, способно ли наше приложение выполнять запросы и получать данные от этих приложений.
3. Системное тестирование
При системном тестировании все приложение проверяется на функциональность и соответствие требованиям.
Вероятно, возникает вопрос: “Если Unit-тестирование каждого компонента прошло успешно, а совместная работа компонентов была проверена во время интеграционного тестирования, то зачем проводить системное тестирование?” Можно сказать, что цель системного тестирования – намеренно нарушить работу приложения.
Сценарий №1
Допустим, вы разрабатываете новое приложение для учета сотрудников с использованием фреймворка, например, Struts. В вашей компании есть еще несколько приложений, работающих на разных серверах. Однако все они вызывают один и тот же веб-сервис для получения адреса и номера телефона определенного сотрудника.
Во время интеграционного тестирования вы должны проверить, способно ли ваше приложение обратиться к веб-сервису и получить ответ. Но что, если проблема в самом веб-сервисе? Что, если веб-сервис не отвечает на редкие запросы? Вдруг веб-сервис выдает исключения для определенных форматов адресов при возврате данных?
Сценарий №2
Ваше приложение для сотрудников готово. Вы добавляете сотрудника, и приложение генерирует номер сотрудника #1001. Вы изменяете, удаляете, обновляете, добавляете, изменяете, удаляете, добавляете, добавляете, изменяете, удаляете и, наконец, добавляете еще одного сотрудника. Что, если его номер снова будет #1001?
Сценарий №3
Предположим, что два пользователя одновременно используют приложение. Оба начинают работать с одним и тем же сотрудником, и один из них удаляет его. Что произойдет, если другой пользователь сможет продолжить модификацию сведений об этом же сотруднике, так как данные о нем хранятся в сессии?
Ниже перечислены некоторые важные аспекты системного тестирования:
- Обеспечение безопасности данных.
- Убеждение в том, что приложение соответствует всем бизнес-функциям.
- Проверка того, хорошо ли приложение работает как конечный продукт – проверка неработающих ссылок, управления сессиями, куки, логов, обработки исключений, валидации.
4. Тестирование производительности
Этот вид тестирования проводится, когда большое количество пользователей используют приложение одновременно или в базе данных большой объем данных, или и то, и другое. Что нужно проверить в таких случаях?
- Не зависает ли приложение, если несколько пользователей входят в систему одновременно
- Хорошо ли приложение обрабатывает все потоки в многопоточной среде проверить.
- Достаточно ли памяти выделено, выполняется ли сборка мусора и нет ли “out of memory” исключений в приложениях, где создается большое количество объектов.
Заключение
В этой статье мы рассмотрели компоненты J2EE-приложений. Мы также рассказали, как вручную выполнять модульное, интеграционное, функциональное и системное тестирование для каждого из компонентов приложения.
Поделитесь своими мыслями в комментариях ниже.
Перевод статьи «How to Test JAVA Applications – Tips with Sample Test Cases (Part 1)».