2.5.2 Паттерн «Абстрактная фабрика»

2.5.3 Паттерн Singleton

2.6 Отладка и тестирование

В целом различаются дефекты программного обеспечения и сбои. В случае сбоя программа ведёт себя не так, как ожидает пользователь. Дефект - это ошибка / неточность, которая может быть (а может и не быть) следствием сбоя.

Общепринятая практика состоит в том, что после завершения продукта и до передачи его заказчику независимой группой тестировщиков проводится тестирование ПО. Эта практика часто выражается в виде отдельной фазы тестирования (в общем цикле разработки ПО), которая часто используется для компенсирования задержек, возникающих на предыдущих стадиях разработки. Другая практика состоит в том, что тестирование начинается вместе с началом проекта и продолжается параллельно созданию продукта до завершения проекта. Второй путь обычно требует больших трудозатрат, но качество тестирования при этом будет выше.

Уровни тестирования

* Модульное тестирование (юнит-тестирование) - тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция

* Интеграционное тестирование - проверяет, есть ли какие-либо проблемы в интерфейсах и взаимодействии между интегрируемыми компонентами - например, не передается информация, передаётся некорректная информация.

* Системное тестирование - тестируется интегрированная система на её соответствие исходным требованиям

* Альфа-тестирование - имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями / заказчиком на стороне разработчика. Часто альфа-тестирование применяется для законченного продукта в качестве внутреннего приёмочного тестирования. Иногда альфа-тестирование выполняется под отладчиком или с использованием окружения, которое помогает быстро выявлять найденные ошибки. Обнаруженные ошибки могут быть переданы тестировщикам для дополнительного исследования в окружении, подобном тому, в котором будет использоваться ПО.

* Бета-тестирование - в некоторых случаях выполняется распространение версии с ограничениями (по функциональности или времени работы) для некоторой группы лиц, с тем чтобы убедиться, что продукт содержит достаточно мало ошибок. Иногда бета-тестирование выполняется для того, чтобы получить обратную связь о продукте от его будущих пользователей.

Тестирование «белого ящика» и «чёрного ящика»

В терминологии профессионалов тестирования (программного и некоторого аппаратного обеспечения), фразы «тестирование белого ящика» и «тестирование черного ящика» относятся к тому, имеет ли разработчик тестов доступ к исходному коду тестируемого ПО, или же тестирование выполняется через пользовательский интерфейс либо прикладной программный интерфейс, предоставленный тестируемым модулем.

При тестировании белого ящика (англ. white-box testing, также говорят - прозрачного ящика), разработчик теста имеет доступ к исходному коду и может писать код, который связан с библиотеками тестируемого ПО. Это типично для юнит-тестирования (англ. unit testing), при котором тестируются только отдельные части системы. Оно обеспечивает то, что компоненты конструкции - работоспособны и устойчивы, до определенной степени.

При тестировании чёрного ящика (англ. black-box testing), тестировщик имеет доступ к ПО только через те же интерфейсы, что и заказчик или пользователь, либо через внешние интерфейсы, позволяющие другому компьютеру либо другому процессу подключиться к системе для тестирования. Например, тестирующий модуль может виртуально нажимать клавиши или кнопки мыши в тестируемой программе с помощью механизма взаимодействия процессов, с уверенностью в том, все ли идет правильно, что эти события вызывают тот же отклик, что и реальные нажатия клавиш и кнопок мыши. Как правило, тестирование чёрного ящика ведётся с использованием спецификаций или иных документов, описывающих требования к системе.

Если «альфа-» и «бета-тестирование» относятся к стадиям до выпуска продукта (а также, неявно, к объёму тестирующего сообщества и ограничениям на методы тестирования), тестирование «белого ящика» и «черного ящика» имеет отношение к способам, которыми тестировщик достигает цели.

Бета-тестирование в целом ограничено техникой чёрного ящика (хотя постоянная часть тестировщиков обычно продолжает тестирование белого ящика параллельно бета-тестированию). Таким образом, термин «бета-тестирование» может указывать на состояние программы (ближе к выпуску чем «альфа»), или может указывать на некоторую группу тестировщиков и процесс, выполняемый этой группой. Итак, тестировщик может продолжать работу по тестированию белого ящика, хотя ПО уже «в бете» (стадия), но в этом случае он не является частью «бета-тестирования» (группы / процесса).

Статическое и динамическое тестирование

Описанные выше техники - тестирование белого ящика и тестирование чёрного ящика - предполагают, что код исполняется, и разница состоит лишь в той информации, которой владеет тестировщик. В обоих случаях это динамическое тестирование.

При статическом тестировании программный код не выполняется - анализ программы происходит на основе исходного кода, который вычитывается вручную, либо анализируется специальными инструментами. В некоторых случаях, анализируется не исходный, а промежуточный код (такой как байт-код или код на MSIL).

Регрессионное тестирование

После внесения изменений в очередную версию, регрессионные тесты подтверждают, что сделанные изменения не повлияли на функциональность предыдущей версии. Регрессионное тестирование может выполняться как вручную, так и программой, автоматизирующий этот процесс.

Покрытие кода

Покрытие кода, по своей сути, является тестированием методом белого ящика. Тестируемое ПО собирается со специальными настройками или библиотеками и / или запускается в особом окружении, в результате чего для каждой используемой (выполняемой) функции программы определяется местонахождение этой функции в исходном коде. Этот процесс позволяет разработчикам и специалистам по обеспечению качества определить части системы, которые, при нормальной работе, используются очень редко или никогда не используются (такие как код обработки ошибок и т.п.). Это позволяет сориентировать тестировщиков на тестирование наиболее важных режимов.

Тестировщики могут использовать результаты теста покрытия кода для разработки тестов или тестовых данных, которые расширят покрытие кода на важные функции.

Как правило, инструменты и библиотеки, используемые для получения покрытия кода, требуют значительных затрат производительности и / или памяти, недопустимых при нормальном функционировании ПО. Поэтому они могут использоваться только в лабораторных условиях.

При отладке и тестировании веб-представительства и административной подсистемы были использованы методы динамического тестирования: метод «белого ящика», регрессионное тестирование, альфа-тестирование, системное тестирование.

3. Организационный раздел

3.1 Размещение ресурсов сайта

Для того чтобы пользователи могли иметь постоянный доступ к сайту, требуется разместить его на круглосуточно доступном хосте. Предполагаемая загрузка сайта невелика, поэтому производительность сервера не имеет решающего значения.

Требования к серверу:

• поддержка Windows-хостинга на платформе IIS;

• поддержка ASP.NET 2.0;

• поддержка MS Ajax Extensions;

• поддержка MS SQL Server 2005;

• возможность простого управления сайтом;

• объём жесткого диска под сайт и ресурсы на хосте ~100 мб;

• стоимость услуг, согласованная с заказчиком.

Также для доступа к ресурсам SQL-сервера необходима возможность прямого удалённого соединения с базой данных.

Всем этим требованиям удовлетворяет хостинг от русской компании Inform-telecom, на котором в настоящий момент размещён и функционирует сайт.

3.2 Работа с административной подсистемой

Для управления содержимым базы данных используется административная подсистема. Её интерфейс достаточно прост в использовании, несмотря на сложное внутреннее устройство, поэтому специальной инструкции не требуется, приведу только основные принципы.

После запуска административной подсистемы у пользователя есть выбор действия - настройка параметров соединения и редактирование собственно данных.

1) Настройка параметров соединения

В этом диалоге пользователю предлагается ввести информацию, на основе которой будет создана строка соединения с базой данных. Впоследствии эта информация будет сохранена в персонализованном хранилище (другие Windows-пользователи не получат доступа к ней). Сразу же можно проверить работоспособность подключения, нажав на кнопку «Тест». Будет реализована попытка создать тестовое подключение ADODB, о результатах которой будет выведено соответствующее окно:

2) Редактирование данных базы.

Для этих целей предусмотрен единообразный интерфейс, основанный на взимозаменяемых компонентах. Сравните изображения на двух рисунках:

Видно, что поменялось только количество и названия столбцов в списке и элемент управления, позволяющий вводить данные.

Назначения кнопок внизу зависит от того, выделен ли элемент.

- Удалить выбранное - удаляет выбранную запись из базы. Умышленно не поддерживается каскадное удаление, то есть задействованная запись удалена не будет, но будет выведено предупреждающее сообщение;

- Сохранить (если не выбран элемент списка) - охраняет новый элемент со введёнными значениями полей. Если некоторые обязательные значения не введены или некорректны, выводится соответствующее сообщение;

- Изменить (если выбран элемент списка) - вместо сохранения новой записи введённые значения считаются данными для модифицирования старой, выделенной;

- Добавить новое (если выбран элемент списка) - снимет выделение и очищает поля ввода.

Для редактирования расписания есть специализированный редактор, созданный для более удобного визуального восприятия. Работа с ним интуитивно понятна.

Заключение

Под руководством моего дипломного руководителя мной была проделана большая подготовительная работа и работа собственно над созданием веб-представительства. Были достигнуты следующие цели:

· исследована предметная область;

· приняты решения, позволяющие создание и легко расширяемой и изменяемой структуры веб-представительства;

· разработаны схемы данных;

· разработаны алгоритмы работы;

· выполнена программная реализация веб-интерфейса;

· выполнена программная реализация административной подсистемы, позволяющей осуществлять управление ресурсами веб-представительства;

· выполнена отладка и тестирование;

· веб-представительство запущено в работу.

Список литературы

1. Э. Гамма, Р. Хелм, Р. Джонсон, Д. Влиссидес. Приёмы объектно-ориентированного проектирования. Паттерны проектирования.

2. Эндрю Троелсен. Язык программирования С# 2005 и платформа.NET 2.0

3. Т. Нортроп, Ш. Уилдермьюс, Б. Райан Основы разработки приложений на платформе Microsoft.NET Framework.

4. Рейли Д. Создание приложений Microsoft ASP.NET

Страницы: 1, 2, 3, 4, 5, 6