Рассмотрим подробнее маппинг одного из классов в приложении. Для примера возьмём класс Content - сами записи, размещённые в блоге. Над объявлением класса мы видим две аннотации:
@Entity - показывает, что это сущность и Hibernate мог начать маппинг.
@Table(name = "content") - указание на название таблицы в базе данных.
У каждого геттера есть свои аннотации. В основном они сильно не отличаются. Например, для поля title имеем такую аннотацию:
@Column(name = "id") - она указывает на название поля в базе данных. Иногда приходится указывать тип данных явно, для этого используется еще один параметр. Например, для поля content. В базе оно имеет тип данных TEXT, а в классе тип данных string. Hibernate не может сделать неявное преобразование. Поэтому надо указать columnDefinition = "TEXT".
Также в базе данных у нас есть таблицы связки. Для того чтобы Hibernate корректно получал данные из базы требуется описать эти таблицы. У поста есть таблица связка пост-тег. Список постов в сущности Student аннотирован с помощью @ManyToMany. Далее следует аннотация @JoinTable, которая определяет таблицу и поля для связи. Параметр name указывает название таблицы (post_tags). Параметр joinColumns указывает на поле, которое используется для прямой связи (идентификатор content_id). Параметр inverseJoinColumns указывает на поле, которое используется для обратной связи (идентификатор tag_id). Для указания столбцов связи из таблицы используется аннотация @JoinColumn. Сущность тега Tag описана "зеркально".
3.2 Клиентская часть системы
3.2.1 Разработка интерфейса
Веб-интерфейс относится к интерфейсу системы, к которому можно обратиться по протоколу передачи гипертекста (HTTP). Это
· графический пользовательский интерфейс (GUI), который позволяет пользователю взаимодействовать с системой с помощью веб-браузера, или
· веб-сервис, который позволяет системе предоставлять данные или функциональные возможности другим системам.
Примерами веб-интерфейсов являются API Google, который позволяет программному обеспечению получать доступ к возможностям поисковой системы через SOAP и WSDL, или встроенный веб-сервер маршрутизатора DSL, который позволяет пользователю вносить изменения в конфигурацию устройства.
Дизайн играет важную роль в привлечении внимания пользователей сети Интернет к определенной Web-странице. При разработке дизайна Web-страницы прежде всего нужно учитывать особенности восприятия целевой аудитории. При этом оформление должно соответствовать содержанию Web-страницы. Универсального решения в области разработки дизайна Web-страниц не существует.
Все Web-страницы одного сервера должны быть оформлены в едином стиле. Это создаст дополнительное представление о сайте.
Дизайн Web-страниц предполагает разработку следующих элементов:
· цвет;
· шрифт;
· графика;
· компоновка.
При этом сеть Интернет налагает некоторые ограничения на возможности оформления Web-страниц, к ним относятся: время загрузки Web-страниц, пропускная способность канала передачи данных, размер графических файлов, совместимость браузеров, передача цветовой палитры и др.
Единая цветовая гамма Web-страниц способствует быстрому и полному восприятию содержания. Как правило, лучшая комбинация цветов для чтения - белый фон и черный текст.
Можно использовать фоновый цвет для отдельных символов текста, что дает вероятность создавать интересные композиции для заголовков, подписей к рисункам. Однако не следует изменять цвета ссылок, поскольку пользователь может решить, что уже посещал их раньше и не нашел ничего интересного. Сайт должен иметь интерфейс, позволяющий посетителю легко ориентироваться в его ресурсах. Визуальное выделение информационных блоков, контрастные ссылки, интуитивно понятное расположение управляющих элементов.
Интерфейс сайта для пользователя разделен на файлы jsp. Каждый файл отвечает за вывод определенной части страницы. Файл может подключать внутри себя другие файлы.
Рисунок 3.1 - Блок-схема алгоритма вывода меню
· Index.jsp - главная страница сайта изображена на рисунке 3.2.
· Login.jsp - страница авторизации.
· Register.jsp - страница регистрации.
· Contact.jsp - страница обратной связи изображена на рисунке 3.3.
Рисунок 3.2 - Главная страница сайта
Рисунок 3.3 - Страница обратной связи
Интерфейс сайта для администратора также разделен на файлы jsp.
· Index.jsp - главная страница панели управления.
· Settings.jsp - страница настроек сайта. На этой странице можно добавлять и удалять администраторов приложения.
· Users.jsp - раздел панели управления в котором можно просматривать и редактировать список пользователей на сайте.
· Content.jsp - раздел панели управления в котором можно просматривать и редактировать список статей на сайте
· Authors.jsp - раздел панели управления в котором можно просматривать и редактировать список авторов и их статей.
4. Тестирование
4.1 Методика тестирования
Тестирование программного обеспечения -- это расследование, проводимое с целью предоставления заинтересованным сторонам информации о качестве тестируемого программного продукта или услуги. Тестирование программного обеспечения может также предоставить объективное, независимое представление о программном обеспечении, чтобы позволить бизнесу оценить и понять риски внедрения программного обеспечения. Методы тестирования включают процесс выполнения программы или приложения с целью обнаружения программных ошибок (ошибок или других дефектов) и проверки того, что программный продукт пригоден для использования.
Тестирование программного обеспечения включает выполнение программного компонента или системного компонента для оценки одного или нескольких свойств, представляющих интерес. Как правило, эти свойства указывают степень, в которой тестируемый компонент или система:
· соответствует требованиям, которыми руководствуется его проектирование и разработка,
· правильно реагирует на все виды входов,
· выполняет свои функции в приемлемые сроки,
· это достаточно удобно,
· может быть установлен и запущен в предполагаемой среде, и
· достигает общего результата, которого желают заинтересованные стороны.
4.1.1 Модульное тестирование серверной части
В компьютерном программировании модульное тестирование - это метод тестирования программного обеспечения, с помощью которого отдельные блоки исходного кода, наборы одного или нескольких модулей компьютерной программы вместе со связанными данными управления, процедурами использования и операционными процедурами тестируются для определения их пригодности для использования.
Модульные тесты, как правило, представляют собой автоматические тесты, написанные и выполняемые разработчиками программного обеспечения для обеспечения того, чтобы раздел приложения (известный как «модульный») соответствовал своему дизайну и вел себя как задумано. В процедурном программировании единица может быть целым модулем, но чаще это отдельная функция или процедура. В объектно-ориентированном программировании единица часто представляет собой целый интерфейс, такой как класс, но может быть отдельным методом. Написав сначала тесты для самых маленьких тестируемых модулей, а затем составные варианты поведения между ними, можно создать комплексные тесты для сложных приложений.
Чтобы изолировать проблемы, которые могут возникнуть, каждый контрольный пример должен быть проверен независимо. Такие заменители, как заглушки методов, фиктивные объекты, подделки и тестовые наборы, могут использоваться для помощи в тестировании модуля в изоляции.
Во время разработки разработчик программного обеспечения может кодировать критерии или результаты, которые, как известно, являются хорошими, в тест для проверки правильности устройства. Во время выполнения контрольных примеров каркасы регистрируют тесты, которые не соответствуют ни одному из критериев, и сообщают о них в виде сводки.
Написание и ведение модульных тестов можно ускорить с помощью параметризованных тестов (PUT). Это позволяет выполнять один тест несколько раз с разными наборами ввода, тем самым уменьшая дублирование кода теста. В отличие от традиционных модульных тестов, которые обычно являются закрытыми методами и тестируют инвариантные условия, PUT принимают любой набор параметров. PUT были поддержаны TestNG, JUnit и его аналогом .Net, XUnit. Подходящие параметры для модульных тестов могут быть предоставлены вручную или, в некоторых случаях, автоматически генерироваться рамкой теста. В последние годы была добавлена ??поддержка написания более мощных (модульных) тестов, использующих концепцию теории. Параметризованный тест использует одни и те же шаги выполнения с несколькими предварительно определенными наборами ввода. Теория - это тестовый пример, который выполняет те же самые шаги, но входные данные могут быть предоставлены методом генерирования данных во время выполнения.
4.1.2 Тестирование верстки серверной части
Тестирование верстки приложения проходит вручную и состоит из 2 этапов:
1. Визуальное тестирование. У современного тестировщика есть множество помощников в виде различных инструментов, стандартов и стайлгайдов (инструкций об общепринятых обозначениях кнопок и визуальных эффектов на сайтах). Опираясь на них, можно качественно и быстро протестировать продукт в целом и верстку в частности. Начнем с тестирования внешнего вида страницы. В первую очередь сравним имеющуюся страницу с макетом. Блоки должны совпадать с макетом идеально, для текста же существует допустимый зазор в 5 рх. Для измерения таких деталей существует инструмент PerfectPixel: достаточно наложить полупрозрачный макет на итоговое решение - и мы сразу увидим различия, ежели таковые имеются. После проверки общей картинки переходим к деталям. Разобраться со шрифтами поможет, например, What Font. Проверить многообразие цветов - Color Zilla. Убедиться в правильности написания контента - Spell Checker.
2. Валидация HTML кода. Большинство страниц в World Wide Web написаны на компьютерных языках (таких как HTML), которые позволяют авторам веб-страниц структурировать текст, добавлять мультимедийный контент и указывать, какой внешний вид или стиль должен иметь результат. Что касается каждого языка, у них есть своя собственная грамматика, словарь и синтаксис, и каждый документ, написанный на этих компьютерных языках, должен следовать этим правилам. Языки (X) HTML для всех версий вплоть до XHTML 1.1 используют машиночитаемые грамматики, называемые DTD, механизм, унаследованный от SGML. Однако так же, как тексты на естественном языке могут содержать орфографические или грамматические ошибки, документы, использующие языки разметки, могут (по разным причинам) не следовать этим правилам. Процесс проверки того, действительно ли документ следует правилам для языка (-ов), который он использует, называется валидацией, а инструмент, используемый для этого, является валидатором. Документ, который успешно проходит этот процесс, называется действительным.
Важно помнить, что страница должна отвечать техническим стандартам:
· кодировка UTF-8 (либо другая оговоренная в ТЗ);
· стандарт HTML;
· стандарт CSS (стоит отметить, что в этой проверке предупреждения допустимы, а ошибки - нет).
· Первый пункт можно легко проверить в самом браузере с помощью инструментов разработчика на вкладке Elements.
В правильности соблюдения стандарта написания кода мы можем убедиться с помощью сервисов от w3.org: достаточно написать адрес страницы в специально отведенное поле и запустить проверку. Все, что не попадает под «стандарты», будет обозначено словом ERROR.
4.1.3 Системное тестирование
Системное тестирование -- это тестирование, проводимое на полностью интегрированной системе для оценки соответствия системы ее указанным требованиям.
В качестве входных данных для тестирования системы используются все интегрированные компоненты, прошедшие интеграционное тестирование. Целью интеграционного тестирования является обнаружение любых несоответствий между модулями, которые объединены вместе (так называемые сборки). Системное тестирование направлено на обнаружение дефектов как внутри «сборок», так и внутри системы в целом. Фактический результат -- это поведение, производимое или наблюдаемое при тестировании компонента или системы. Системное тестирование выполняется на всей системе в контексте спецификаций функциональных требований (FRS) или спецификации системных требований (SRS), или обоих. Тестирование системы проверяет не только дизайн, но также поведение и даже ожидания клиента. Он также предназначен для тестирования до и за пределами, определенных в спецификации (требованиях) программного или аппаратного обеспечения.
Пример разработанного тест-кейса:
Тест-кейс № 1. Создание дубликата аккаунта.
Шаги:
1. Зайти на сайт
2. Перейти на страницу регистрации и ввести следующие данные:
a. Имя: Test
b. Электронная почта: test@test.com
c. Имя пользователя: test
d. Пароль и подтверждение пароля: test123456
3. Нажать на кнопку «создать аккаунт»
4. На главной странице сайта нажать кнопку «выход»
5. Повторить пункт 2
Ожидаемый результат:
Выделение полей «электронная почта» и «логин» красной рамкой и появление сообщения об ошибке рядом с каждым полем. Тест-кейсы были разработаны на все критичные функции приложения.
4.2 Результаты тестирования
Тестирование проводится локально на компьютере разработчика, затем на удаленном сервере приложений. Модульное тестирование запускается внутри интегрированной среды разработки IntelliJ IDEA 2018. Вся бизнес логика приложения покрыта тестами. Все тесты прошли успешно.
Первая часть тестирования верстки клиентской части - визуальное тестирование не выявило дефектов. Вторая часть - валидация проводилась через официальный сервис W3C (validator.w3.org). Валидатор не выявил ошибок HTML кода. Тестирование верстки клиентской части пройдено успешно.
Рисунок 4.1 - Результаты валидации HTML кода
Во время системного тестирования вручную были проверены все тест-кейсы. Дефектов выявлено не было. Системное тестирование пройдено успешно.