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

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

"Новинки" (товары, недавно поступившие в продажу);

"Специальные предложения" (товары, на которые по каким-либо причинам снижены цены);

"Товары дня" (самые модные товары);

"Лидеры продаж" (наиболее покупаемые товары).

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

7. Расчёт стоимости и вывод цен должен осуществляться минимум в двух валютах, гривнах и долларах.

8. В электронном магазине могут быть и информационные разделы:

с данными о магазине (сфера деятельности, адрес, контактные телефоны и т.д.);

с информацией по доставке товара;

с информацией по скидкам;

новости магазина;

статьи (системы управления новостями и статьями предоставляют возможность использовать Интернет магазин как настоящий информационный портал);

прочая полезная информация.

9. Рассылка новостей. Посетитель имеет возможность подписаться (и отписаться) на новости Интернет магазина. После подписки покупателю периодически высылается информация о новинках магазина.

10. Обратной, невидимой покупателю, стороной Интернет магазина является система управления. Вход в систему администрирования осуществляется только после ввод администратором логина и пароля (логин и пароль администратор может менять). Администратор имеет возможность полностью управлять содержимым Интернет магазина:

добавлять или удалять товары, описания и фотографии к ним, изменять их стоимость, уровень скидок;

редактировать разделы магазина (новости, статьи, вопросы и ответы, отзывы и вопросы к товарам и пр.);

редактировать специальные разделы магазина (новинки, специальные предложения, товары дня, лидеры продаж);

редактировать контактную информацию Интернет магазина;

редактировать содержание заголовков и текстов писем, отправляемых покупателю при регистрации и покупке товара;

составлять и рассылать письма с новостями магазина подписчикам;

просматривать историю заказов и статистику покупателей;

изменять курс валюты на витрине магазина.

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

11. Аккуратная работа с цветом. Правильно примененный цвет может, например, передавать тонкие различия между однородными элементами. Неправильно примененный цвет может мешать работать с программой.

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

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

3.5 Описание web-страниц и их функциональность

Интерфейс приложения можно разделить на две составляющие:

1) Интерфейс пользователя:

Главная страница - на ней находятся: поиск, и навигация по каталогам;

Страница каталога - позволяет перемещаться внутри категорий;

Страница прайс-листа - на данную страницу можно попасть кликнув на кнопку в хедере страницы. Данная страница аналогична каталогу, только в виде таблицы и отображением товаров;

Страница информации о товаре - предоставляет информацию о товаре (фотография и детальное описание), возможность оценки товара и возможность перенести товар в корзину кликнув на соответствующую ссылку;

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

Страница информации о покупателе - позволяет ввести информацию о покупателе - ФИО, адрес, телефон и т.д. Поля отмеченные красной звездочкой являются обязательными для заполнения. После заполнения данной страницы заказ будет полностью выполнен по нажатию на кнопку "Оформить заказ".

2) Интерфейс администратора

Форма авторизации - в ней администратор вводит логин и пароль для попадания на страницу администрирования сайта;

На главной странице администратора находится общая информация о магазине - количество полученных заказов за промежутки времени (сегодня, вчера, в этом месяце и всего), а также информация о продуктах (общее количество продуктов, сколько из них продаются, количество категорий продуктов). С главной страницы можно попасть на страницу "Каталог", страницу полученных заказов и на страницу настроек;

Страница "Каталог" - делится на:

Страница Категории и товары - позволяет администратору создавать/редактировать/удалять категории и товары;

Страница Специальные предложения - на ней отображаются товары, которые администратор перенес, присвоив им статус спец. предложения, которые можно отсортировать, по номеру, для порядкового отображения на главной странице или же удалить ненужное предложение.

Страница полученных заказов - содержит записи в таблице, о данных введенных покупателем во время оформления заказа и позволяет администратору удалить выбранный заказ кликом на соответствующую кнопку.

Страница настроек делится на:

Страница общих настроек - позволяет администратору редактировать информацию о названии магазина, urlмагазина, контактный email адрес магазина, еmail, на который будут отправляться уведомления о заказах, а также информацию о валюте действующей в интернет магазине - обозначению (например $), и код валюты (например USD).

Страница изменения оформления - позволяет администратору редактировать настройки каталога - максимальное количество товаров на странице, максимальное количество столбцов при показе товара, цвета использующиеся при оформлении таблиц.

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

Страница изменения информации - позволяет администратору редактировать информацию о магазине (любую информацию для пользователей магазина) и информацию о доставке и оплате.

Рисунок 3.10 - Карта сайта

3.6 Примеры пользовательского интерфейса

Рисунок 3.11 - Главная страница пользователя

Рисунок 3.12 - Информация о товаре

Рисунок 3.13 - Корзина

Рисунок 3.14 - Форма заполнения информации о покупателе

Рисунок 3.15 - Добавление Категорий и товаров

Рисунок 3.16 - Полученные заказы

3.7 Механизм шаблонов

CMS разработана на основе шаблонной библиотеки Smarty.

Smarty - это мощный инструмент, который компилирует шаблоны в PHP скрипты и потом запускает эти самые скрипты, тем самым позволяя сделать дизайн интернет-магазина легко редактируемым и отделить его от PHP скриптов.

Дизайн настраивается в шаблонах, которые представляют собой HTML файлы, расположенные во вложенной папке templates. Содержимое файлов-шаблонов представляет собой HTML-код со вставками специальных тэгов Smarty, оформленных в фигурных скобках {} - это различные условия {if}, циклы{section} и т.п.

Основной шаблон пользовательской части index. tpl.html (этот шаблон определяет внешний вид магазина). Администратор может открыть этот файл в текстовом или HTML редакторе (например PHPExpertEditor) и внести необходимые изменения (возможно изменить цветовое оформление, логотипы и т.п. - любые элементы дизайна). Для этого администратор должен обладать базовыми навыками работы с HTML и/или опыт работы с HTML редактором.

3.8 Разработка модульной структуры приложения

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

Рисунок 3.17 - Модульная структура

Наиболее часто используемые файлы:

Connect. inc. php - объявление констант для настройки соединения с БД;

MySQL. php - включает функции для работы с БД;

General. inc. php - объявление основных констант;

Appearance. inc. php - объявление констант оформления;

Functions. php - содержит наиболее используемые функции;

Category_functions. php - содержит наиболее используемые функции древа категорий;

Checklogin. php - проверяет авторизацию;

Tables. inc. php - объявление констант таблиц БД.

3.8 Руководство пользователя

1. Введение

1.1 Наименование программы

CMS (система управления контентом) интернет маркета.

1.2 Краткая характеристика области применения

Приложение, предоставляющее инструменты для добавления, редактирования, удаления информации на сайте (далее по тексту приложение).

2 Основание для разработки

2.1 Основания для проведения разработки

Основание для разработки Системы - задание на бакалаврскую работу кафедры "Компьютерные системы и сети” Национального аэрокосмического университета им. Н.Е. Жуковского "ХАИ”.

2.2 Наименование и условное назначение

CMS (система управления контентом) интернет маркета.

3. Назначение разработки

3.1 Функциональное назначение

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

3.2 Эксплуатационное назначение

Эксплуатационным назначением приложения является разработка веб-магазинов на его основе.

4 Требования к системе

4.1 Требования к системе в целом

4.1.1 Требования к структуре и функционированию системы

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

4.1.2 Требования к численности и квалификации персонала

Установкой приложения должен заниматься минимум один человек справами администратора, который должен обладать знаниями MySQL и PHP. Управление приложением должно производиться минимум одним пользователем с правами администратора.

Клиентские пользователи должны обладать базовыми навыками работы с web-приложениями. Требования к их количеству не предъявляются.

4.1.3 Показатели назначения

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

4.1.4 Требования к эргономике и технической эстетике

Необходимо разработать удобный визуальный интерфейс пользователя для взаимодействия с приложением.

4.1.5 Требования к эксплуатации и техническому обслуживанию, ремонту и хранению компонентов приложения

Устойчивое функционирование приложения должно быть обеспечено выполнением Заказчиком совокупности организационно-технических мероприятий:

а) Организации бесперебойного питания технических средств;

б) использование лицензионного ПО;

в) своевременное обновление ПОс сайта производителя;

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

4.1.6 Требования к защите информации от несанкционированного доступа

Объектами защиты в приложении являются:

а) пароль администратора;

б) информация о товаре;

в) информация о заказчике товара.

Для организации защиты выбранных объектов необходимо предусмотреть:

1) предоставлять доступ в администраторскую часть только после ввода пароля;

2) обеспечение хранения конфиденциальной информации в зашифрованном виде;

3) обеспечить передачу информации по открытым каналам связи в зашифрованном виде;

4) при выполнении опасных операций с данными (удаление, модификация) запрашивать подтверждение пользователя.

4.1.7 Требования по защите информации при авариях, требования по защите влияния от внешних воздействий

Необходимо предусмотреть возможность резервирования информации во избежание её потери при авариях (катастрофы природного и техногенного характера).

4.1.8 Требования по стандартизации и унификации

Приложение должно соответствовать современным принципам/технологиям проектирования.

База данных должна обеспечивать целостность, безопасность, резервируемость и сохраняемость данных.

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

4.2 Требования к функциям (задачам), выполняемым приложением

Приложение должно обеспечивать выполнение следующих модулей:

1) Интерфейс пользователя;

1.1) Каталог (развернутый вид - в центре экрана, и краткая навигация, расположенная на сайд-баре);

1.2) Прайс-лист (краткое отображение всех товаров по категориям);

1.3) Меню оформления заказа;

1.4) Поиск товара;

1.5) Два меню отображения информации в шапке приложения (информация о магазине и доставке/ оплате товара)

2) Интерфейс администратора;

2.1) Модуль обеспечения авторизации (проверка логина и пароля);

2.2) Модуль для создания/ удаления/ редактирования каталогов (информации раздела, фото);

2.3) Модуль добавления/ редактирования/ удаления товара (информации о нем, фото,);

2.4) Модуль "Специального предложения" (товар который будет отображен на главной странице)

2.5) Модуль Обзора полученных заказов;

2.6) Модуль настройки интернет-магазина (общая, визуальная, доступа и информации о нем);

2.7) Модуль показа общей информация по магазину (количество продуктов и категорий, количество заказов и сумма продаж).

4.2.1 Для выполнения задачи 1.1) необходимо реализовать следующие функции:

а) функция каталога (наименование каталога/подкаталогов, отображение фото, информация о каталоге);

б) функция навигации по каталогу.

4.2.2 Для выполнения задачи 1.2) необходимо реализовать следующие функции:

а) функция прайс-листа (наименование каталога, наименование товара, цена).

4.2.3 Для выполнения задачи 1.3) необходимо реализовать следующие функции:

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

б) меню брифинга корзины (располагается на сайд-баре, позволяет видеть сколько товаров у вас сейчас в корзине и на какую сумму, также позволяет вернутся обратно в развернутую корзину, для дальнейшего оформления заказа);

в) Меню контактной информации для связи с клиентом (включает пункты оформления информации о клиенте, делятся на обязательные (Ф.И. О) и необязательные (адрес) пункты);

4.2.4 Для выполнения задачи 1.4) необходимо реализовать следующие функции:

а) функция поиска товара;

4.2.5 Для выполнения задачи 1.5) необходимо реализовать следующие функции:

а) Модуль перевода меню (русский и английский, по умолчанию - русский);

4.2.6 Для выполнения задачи 1.6) необходимо реализовать следующие функции:

а) Меню информации - "О Магазине” - На этой странице возможно разместить, например, информацию о магазине, компании, правила предоставления услуг, контакты.

б) Меню информации - "Доставка и оплата” - На этой странице возможно разместить информацию о порядке доставки и оплаты заказов в интернет-магазине.

4.2.7 Для выполнения задачи 2.1) необходимо реализовать следующие функции:

а) функция проверки пароля (форма ввода пароля, в случае неправильного ввода, выводит сообщение об ошибке).

4.2.8 Для выполнения задачи 2.2) необходимо реализовать следующие функции:

а) Функция "категории”, позволяет добавлять/редактировать/удалять каталоги; после нажатия кнопки "добавить”, открывается окно в котором необходимо заполнить информацию о каталоге и выбрать логотип.

4.2.9 Для выполнения задачи 2.3) необходимо реализовать следующие функции:

а) Функция "товары”, позволяет добавлять/редактировать/удалять товары; после нажатия кнопки "добавить”, открывается окно в котором необходимо заполнить информацию о товаре и загрузить 3 вида фото. В самом меню доступны функции изменения цены, доступности товара на складе и включения его в список продаж, также имеется кнопка, для переноса товара в специальные предложения.

4.2.10 Для выполнения задачи 2.4) необходимо реализовать следующие функции:

а) Функция "Специальные предложения" - включает в себя отображения товара, порядок отображения на главной странице и кнопку удалить и сохранить.

4.2.11 Для выполнения задачи 2.5) необходимо реализовать следующие функции:

а) Функция "Заказы” Включает в себя таблицу с заполненными данными клиентов, о купле того или иного товара, дате и времени заказа, возможность удалить заказ после его выполнения.

4.2.12 Для выполнения задачи 2.6) необходимо реализовать следующие функции:

а) Вкладка "общие" включает в себя: изменения названия сайта, url, контактный емейл магазина и емейл на который будут приходить уведомления о полученных заказах. Также включает в себя настройки валют: обозначение валюты (например $), и код валюты (например USD).

б) Функция "оформление” позволяет задать количество товаров на странице, количество столбцов при показе товаров, цвета используемые в таблице, включить корзину, показывать популярные товары в пустых категориях.

в) Функция "доступ к администрированию" - позволяет изменить данные для входа в администраторскую часть (логин и пароль)

г) Функция "дополнительная информация” - позволяет редактировать информацию о магазине, доставке и плате, которая потом будет отображена в соответствующих пунктах меню на главной странице.

4.2.13 Для выполнения задачи 2.7) необходимо реализовать следующие функции:

а) Функция выводит информацию о магазине (количество товаров, каталогов, продаж) в верхнем-правом углу, а также непосредственно после входа в режим администрирования.

4.3 Требования к видам обеспечения

1) Программное:

ПО, необходимое для установки приложения:

а) Windows Server или Linux

б) Apache web-server

в) MySQLServer

г) PHP как модуль web-сервера версии 4.3.0 и выше

д) PHP редактор

е) интернет браузер поддерживающий протокол http.

2) Аппаратное:

а) минимальный необходимый процессор - 133 МГц;

б) ОЗУ - 128мб;

в) доступное дисковое пространство - не менее 300 Мб;

г) графический адаптер, для вывода изображения на экран.

3) Организационно-методическое:

Физический доступ к серверам на которых установлено приложение, должен быть ограничен.

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

5 Порядок контроля и приемки системы

Порядок выполнения и приемки этапов разработки приложения должен соответствовать требованиям ГОСТ 21.101-97.

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

Техническая документация при поставке должна соответствовать ЕСПД и ГОСТ 2.114-95.

Настоящее ТЗ может уточнятся и дополнятся по согласию сторон.

6 Требованию к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

1) Запуск web-сервера Apache;

2) Создание учетной записи администратора;

3) Установка приложения

7. Требования к документированию

4. Технологическая часть

4.1 Современные методы и средства тестирования web-приложений

Тестирование программного обеспечения - процесс исследования, испытания программного продукта, имеющий две различные цели:

· продемонстрировать разработчикам и заказчикам, что программа соответствует требованиям;

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

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

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

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

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

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

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

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

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

Качество программного обеспечения можно определить как совокупную характеристику исследуемого ПО с учётом следующих составляющих:

· надёжность

· сопровождаемость,

· практичность,

· эффективность,

· мобильность,

· функциональность.

Состав и содержание документации, сопутствующей процессу тестирования, определяется стандартом IEEE 829-1998.

Тестирования программного обеспечения

Существует несколько признаков, по которым принято производить классификацию видов тестирования. Обычно выделяют следующие:

По объекту тестирования

· Функциональное тестирование

· Тестирование производительности

· Нагрузочное тестирование

· Стресс-тестирование

· Тестирование стабильности

· Конфигурационное тестирование

· Юзабилити-тестирование

· Тестирование интерфейса пользователя

· Тестирование безопасности

· Тестирование локализации

· Тестирование совместимости

По знанию системы

· Тестирование чёрного ящика

· Тестирование белого ящика

· Тестирование серого ящика

По степени автоматизации

· Ручное тестирование

· Автоматизированное тестирование

· Полуавтоматизированное тестирование

По степени изолированности компонентов

· Модульное тестирование

· Интеграционное тестирование

· Системное тестирование

По времени проведения тестирования

· Альфа-тестирование

· Дымовое тестирование (англ. smoketesting)

· Тестирование новой функции (newfeaturetesting)

· Подтверждающее тестирование

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

· Приёмочное тестирование

· Бета-тестирование

По признаку позитивности сценариев

· Позитивное тестирование

· Негативное тестирование

По степени подготовленности к тестированию

· Тестирование по документации (формальное тестирование)

· Интуитивное тестирование (англ. adhoctesting)

4.1.1 Существующие подходы к тестированию Web-приложений

Большинство из существующих подходов к тестированию Web-приложений являются тестированием по принципу "черного ящика" (4.1.2). Все, чем обладает тестировщик - это само приложение, с которым можно взаимодействовать, например, через Web-браузер, и список требований, которым приложение должно удовлетворять. Тестирование заключается в переходе по различным ссылкам внутри приложения и анализе получаемых страниц. Существуют инструменты для автоматизации этих процессов, однако ведущая роль в разработке тестов все-таки отводится человеку.

Существует много решений, позволяющих записывать сценарии поведения пользователя (т.е. цепочку ссылок, по которым осуществлялся переход) - IBM RationalRobot, HP WinRunner, Empirix e-TEST и другие. Записанный единожды сценарий может далее воспроизводиться автоматически. Однако создание сценариев - трудоемкое занятие, причем отдельной задачей является анализ требований к приложению с целью определить, какие именно сценарии должны быть созданы для обеспечения хорошего качества тестирования. Некоторые инструменты (например, компонент PureAgent в системе PureTest) позволяют создавать сценарии на основе действий реальных пользователей, работающих с приложением. Однако и при таком подходе при достаточно большом количестве пользователей встает вопрос о выборе из множества возможных сценариев относительно небольшого набора, который, тем не менее, обеспечит хорошее качество тестирования.

Существуют инструменты, позволяющие автоматически генерировать ссылки для обращения к приложению по протоколу HTTP, получать соответствующие страницы и производить их анализ. Однако при генерации ссылок также обычно применяется подход "черного ящика" - исходный код приложений не анализируется, а ссылки, которые необходимо генерировать, должен описать тестировщик с использованием специфических для каждого инструмента средств. Например, eValid позволяет перебирать значения параметров для скриптов, которые будут подставляться в создаваемые ссылки, но список параметров с возможными значениями для каждого скрипта должен составлять тестировщик. При достаточно большом количестве скриптов и параметров создание такого списка потребует много времени; кроме того, список должен постоянно поддерживаться в актуальном состоянии - тестировщик должен следить за изменением состава скриптов и их параметров. Инструмент Puffin позволяет генерировать для параметров произвольные значения, однако такой подход во многих случаях сильно снижает качество тестирования по сравнению с ручным заданием значений. В случае Puffin, опять же, список имен параметров должен составлять и поддерживать тестировщик. Кроме того, существующие инструменты не предоставляют удобных средств для перебора различных комбинаций параметров, а во многих случаях интерес представляет именно перебор комбинаций, поскольку разные сочетания параметров могут задействовать различные части приложения.

Многие инструменты анализируют получаемые в процессе тестирования страницы, извлекая из них ссылки на другие части приложения и имитируя переход по ним (опять же, с дальнейшим анализом получаемых страниц; например, для таких целей предназначен компонент 'WebCrawler', входящий в PureTest). Таким образом, осуществляется переход по всем ссылкам, которые могут быть достигнуты, начиная с определенной страницы. Поскольку все части приложения, как правило, взаимосвязаны, то в идеале, начав с некоторой стартовой страницы и посетив все достижимые из нее ссылки, можно протестировать всю функциональность приложения, доступную пользователю. Однако число ссылок может быть чрезвычайно велико, и лавинообразно расти с увеличением числа посещенных страниц. К сожалению, современные средства перехода по ссылкам достаточно примитивны и просто осуществляют переходы по всем встреченным ссылкам (ввиду чего они часто используются при нагрузочном тестировании). Настройка либо доработка инструментов для более "интеллектуального" выбора ссылок, по которым надо осуществлять переходы, требует тщательного анализа самого приложения.

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

Кроме того, во многих случаях стоит цель тестирования не только части приложения, занимающейся формированием страниц HTML, но всего программного комплекса, неотъемлемой частью которого является постоянно изменяющаяся база данных. Сравнение страниц целиком в таких случаях не оправдано. Например, в случае приложения, формирующего страницу с ежечасно обновляемыми новостями, документы, выдаваемые по одному и тому же запросу в различные моменты времени, с большой вероятностью будут отличаться. Можно поддерживать еще и заранее заданный набор данных, на котором проводится тестирование, однако это не избавляет от проблем в случае изменения структуры или оформления страниц.

В качестве альтернативы предлагаются менее строгие проверки; так, уже упоминавшийся eValid позволяет производить более 20 сравнений, среди которых можно отметить следующие:

· 'URL' - проверка ссылки, на которой оказался пользователь после совершения определенных действий, записанных в сценарии;

· 'Title' - проверка названия страницы;

· 'Elements' - проверка числа элементов в DOM-модели страницы;

· 'ByteSize' - проверка размера страницы;

· 'LastModifiedDate' - проверка даты последнего изменения страницы;

· 'Checksum' - проверка контрольной суммы для текста страницы;

· 'Text' - проверка выделенных участков текста страницы;

· 'ScreenRectangle' - сравнение изображения определенного участка страницы с тем, что наблюдал тестировщик во время записи сценария.

Остальные проверки являются вариациями проверки части страницы как изображения либо являются комбинациями указанных проверок.

Можно отметить, что несмотря на достаточно большое количество доступных проверок, ни одна из них не пригодна в случае, когда изменяется содержательная часть страницы - часть проверок (такие, как 'Title' и 'URL') могут вообще не зависеть от этой составляющей документа, а другие ('ByteSize', 'Checksum', 'ScreenRectangle') с большой вероятностью сообщат об ошибке (т.е. об отличии полученного на новых данных результата от эталонного), но такие сообщения скорее всего не будут свидетельствовать о реальном нарушении функциональности приложения.

Существуют и более сложные подходы к разработке тестов для Web-приложений, позволяющие абстрагироваться от различных аспектов, связанных непосредственно с языком разметки HTML, и генерировать тесты на основе формальной модели данных, передаваемых приложению - см., например, [10]. Однако такие подходы трудоемки и требуют достаточно высокой квалификации тестировщиков.

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

Уровни тестирования. Модульное тестирование - тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция. Часто модульное тестирование осуществляетсяразработчиками программного обеспечения.

· Интеграционное тестирование - тестируются интерфейсы между компонентами, подсистемами или системами. При наличии резерва времени на данной стадии тестирование ведётся итерационно, с постепенным подключением последующих подсистем.

· Системное тестирование - тестируется интегрированная система на её соответствие требованиям.

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

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

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

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

В зависимости от доступа разработчика тестов к исходному коду тестируемой программы различают "тестирование (по стратегии) белого ящика" и "тестирование (по стратегии) чёрного ящика".

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

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

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

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

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

4.2 Тестирование функциональности

Для проверки корректного выполнения программой функций, заложенных в техническом задании, были составлены тестовые наборы, показанные в таблицах 4.1, 4.2, 4.3, 4.4.

Таблица 4.1 - Тестовые наборы для проверки функциональности авторизации

№ Теста	Действие	Ожидаемый результат	Отметка о выполнении
1	Ввод логина и пароля Login: admin Password: admin (ввод корректной информации)	Авторизация и вход на страницу администратора	проверено
2	Ввод логина и пароля Login: anonim Password: admin (ввод некорректной информации - неверный логин)	Сообщение о неправильно введенном логине или пароле	проверено
3	Ввод логина и пароля Login: admin Password: password (ввод некорректной информации - неверный пароль)	Сообщение о неправильно введенном логине или пароле	проверено

Таблица 4.2 - Тестовые наборы для проверки администрирования каталога и товаров

№ Теста	Действие	Ожидаемый результат	Отметка о выполнении
1	Выбор "Категории и товары"	Вывод меню редактирования каталога и товаров	проверено
2	Выбор "Добавить" категорию	Вывод формы для заполнения данных для новой категории	проверено
3	Заполнить форму и выбрать "Сохранить"	Создание новой категории	проверено
№ Теста	Действие	Ожидаемый результат	Отметка о выполнении
4	Выбор "Edit"	Вывод формы для редактирования данных о категории	проверено
5	Выбор "добавить" товар	Вывод формы для заполнения данных для нового товара	проверено
6	Заполнить форму и выбрать "Сохранить"	Добавление нового товара в выбранной категории	проверено
7	Выбор "кнопки - для удаления товара"	Удаление выбранного товара	проверено
8	Выбор названия товара	Вывод формы для редактирования данных	проверено
9	Выбор "кнопки - специальные предложения"	Перенос товара в меню "специальные предложения"	проверено

Таблица 4.3 - Тестовые наборы для проверки функциональностипоиска

№ Теста	Действие	Ожидаемый результат	Отметка о выполнении
1	Поиск товара по фразе, например: AMD	Вывод товара, в названии или описании которого упоминается данная фраза.	проверено
2	Поиск товара по фразе, заведомо несуществующей	Вывод сообщения о том, что ничего не найдено	проверено

Таблица 4.4 - Тестовые наборы для проверки функциональности закупки

№ Теста	Действие	Ожидаемый результат	Отметка о выполнении
1	Выбор категории: например AMD	Вывод товаров в данной категории и описание категории	проверено
2	Выбор товара: например процессор Athlon II	Вывод информации о товаре	проверено
3	Нажатие на кнопку "в корзину”	Вывод корзины	проверено
4	Установка количества товаров равным 20, и нажать кнопку обновить	Сумма заказа умножится на 20	проверено
5	Установка количества товаров равны мили меньше 0, и нажать кнопку обновить	Корзина очистится	проверено
6	Подтверждение заказа	Вывод формы для заполнения контактной информации	проверено
7	Ввод информации во все поля которые обязательные для заполнения	Добавление данных о заказе и покупателе в Базу Данных	проверено
8	Заполнение не всех обязательных полей	Вывод сообщения о незаполненных полях	проверено

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

5. Экономическое обоснование проекта

5.1 Маркетинговые исследования предприятия

Интернет-торговля - занятие очень выгодное. По крайней мере, должно быть таким в теории. Владельцу интернет-магазина не надо тратить деньги на аренду торговых площадей, закупку торгового оборудования, найм армии продавцов и консультантов. Вся информация представлена на сайте - и сам покупатель ходит среди "виртуальных полок" и выбирает, что ему нужно. Прибавьте к этому огромную потенциальную аудиторию рунета - десятки миллионов человек из России и стран СНГ. Вряд ли хоть один реальный магазин способен похвастаться столь большим числом потенциальных покупателей.

На практике придется побороться, чтобы клиенты выбрали именно наш магазин, а не торговую площадку конкурента. Сегодня Интернет-торговля стала обыденным явлением. Сотни магазинов предлагают тысячи товаров. Купить в интернете можно практически все, за исключением, наверно, путевки в космос. И конкуренция между магазинами - огромная. В борьбе за покупателя приходится обращать внимание на все - вплоть до мелочей.

Успех современного Интернет-магазина, обеспечивается результативным решением двух основных задач. Первая - привлечь на сайт магазина достаточное количество потенциальных покупателей. Вторая - перевести как можно больше посетителей из категории "потенциальных покупателей" в категорию реальных клиентов. Статистическое соотношение "посетители/покупатели" называется "уровнем конверсии", и чем выше этот показатель, тем (при прочих равных условиях) успешнее Интернет-магазине. В данной статье мы осветим некоторые базовые факторы организации Интернет-торговли, которые повышают уровень конверсии и без которых представить успешный магазин крайне сложно.

К числу внутренних факторов успеха интернет-магазина относятся прежде всего Сервис, Ассортимент и Цены. О приоритетности этих факторов можно долго спорить. С экономической точки зрения, для людей с невысокими доходами (к числу которых относятся многие россияне) определяющим фактором будут цены. Но давайте посмотрим на портрет рунетчика - в большинстве своем это офисные работники, руководители предприятий, специалисты, небедные студенты и учащиеся. Люди более-менее обеспеченные. И поэтому для них важнее Сервис и Ассортимент. И за это они готовы переплачивать. Например, Ozon.ru - один из крупнейших интернет-магазиноврунета. Но многие товары в нем дороже, чем в других магазинах, например, в Bolero.ru. Тем не менее, продуманная ценовая политика - одна из составляющих успеха, пусть и занимающая третье место после Сервиса и Ассортимента.

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

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

5.2 Расходы по созданию и размещению магазина в сети интернет

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

Таблица 5.2.1 - Расчет электроэнергии для девятичасового рабочего дня.

Наименование	кол-во	кВт/час	кВт в сутки (примерно)	кВт в месяц
Компьютер	1	0,17	1,53	45,9
Освещение	3	0,36	9,72	291,6
Сплит	1	0,7	6,3	189
ИТОГО:		1,23		526,5

Для предприятий 1 кВт / ч= 0,24

В месяц 0.24*526,5= 126,36 гривен.

В сети интернет магазин планируется разместить на ресурсах провайдера города Луганска НПЦ "Микроэлектроника", что обеспечит удобное обслуживание и рекламную ссылку на магазин с главной страницы сайта провайдера http://lugansck.ua/

Заработная плата программисту составляет 1600 гривен.

Таблица 5.2.2 - Расчет ежемесячных затрат на содержание интернет - магазина.

Наименование	Сумма, грн.
Зарплата программиста	1600
Зарплата курьера	605
Электроэнергия	126,36
Хостинг	75
Интернет	100
Прочие расходы	200
Итого:	2706,36

R_Пост = 2706,36 - постоянные ежемесячные расходы.

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

Годовая сумма амортизационных отчислений рассчитывается по формуле:

,

где

Ф - первоначальная стоимость основных фондов по видам, грн.;

N_A - норма амортизации по видам основных фондов, в %.

Годовую сумму амортизационных отчислений отразим в таблице 4.2.3

Таблица 5.2.3 - Расчет годовой суммы амортизационных отчислений.

Элементы основных фондов.	Кол-во	Стоимость, грн.	Сумма грн.	Норма амортиза-ции, %	Амортизацион-ные отчисления, грн.
Компьютер	1	3500	3500	20%	700
Сплит система	1	3200	3200	20%	640
Помещение	13,6м2	400	5440	3%	163,2
ИТОГО:	1503,2

Таким образом, годовая сумма амортизационных отчислений составляет 1503,2 гривны.

Исходя из того, что трудоёмкость создания информационной системы составляет 10 дней, рассчитываем амортизацию оборудования за этот период по формуле:

,

Рассчитаем сумму амортизационных отчислений для перечисленной группы оборудования с учетом числа календарных дней на разработку программного обеспечения (интернет - магазина) по формуле:

А = =41,2 грн.

Заработная плата программиста составляет 1600 грн. Соответственно, затраты на заработную плату включаемые в себестоимость программы с учетом работы над программой в течение 12 дней составят:

,

где ЗП_пр - заработная плата в месяц программиста, грн.;

Т_факт - число календарных дней на разработку интернет - магазина;

Д - число дней в периоде (месяц).

ЗП_пр = = 727,3 грн.

Таблица 5.2.4 - Расчет ежемесячных материальных затрат.

Наименование	Сумма, грн/мес.
Электроэнергия	126,36
Хостинг	75
Интернет	100
Прочие расходы	200
Итого:	501,36

З_м= 501,36 гривен в месяц

Следовательно, затраты на период разработки программного продукта рассчитаем по формуле:

З_пр= ,

где З_м - ежемесячные затраты, грн.;

Т_факт - число календарных дней на разработку интернет - магазина;

Д - число дней в периоде (месяц).

Зпр = 50136*10/22=227

Рассчитаем себестоимость программного продукта по формуле:

С_ст - себестоимость разработки программы

С_ст = З_пр + ЗП_пр + А

С_ст = 227,9+727,3+41,2 = 996,4 гривен.

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

С_ст ? 1000 гривен.

Исходя из нормального уровня рентабельности 20% мы можем определить цену разработанной нами программы:

,

где С_ст - себестоимость разработки программы;

R - планируемый уровень рентабельности.

Ц=1000+100*20/100=1200

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

5.3 Выводы

В результате расчета затраты на создание данного программного продукта составили 2703 грн. и 2706,36 - постоянные ежемесячные расходы.

Для снижения затрат, можно предложить следующие решения. Как видно, три четверти расходов представляют из себя затраты на оплату труда программиста. Снизить эти затраты, можно путем повышения эффективности труда программиста за счет использования более современных ЭВМ для работы, повышения удобства рабочего места и прочих факторов. Также при более бережном и аккуратном отношении к компьютерной технике возможно снизить затраты на ремонт, а так же уменьшить привлечение дополнительного персонала на обслуживание компьютеров.

6. Охрана труда и безопасность в черезвычайных ситуациях

В Украине главным нормативно-законодательным документом, определяющим требования безопасности и санитарно-гигиенические требования к организации рабочих мест операторов ЭВМ и работников, выполняющих обслуживание и ремонт ЭВМ, являются "Правила охраны труда во время эксплуатации ЭВМ”, утверждённые приказом Держнаглядохоронпраці от 10 февраля 1999 г №21 и зарегистрированные в Министерстве юстиции Украины 17 июня 1999 г под №382/3675. Этот документ устанавливает основные правила охраны труда и содержит ссылки другие нормативные документы.

6.1 Метеорологические условия при работе

Согласно ГОСТ 12.1.005-88 оптимальные параметры микроклимата для выполнения работы должны находиться в пределах, указанных в таблице 4.1.

Категорию работы учитываем по физической нагрузке. Работу сотрудников отдела отнесём к категории Iб (напряжённая работа).

Таблица 6.1 - Оптимальные нормы температуры, относительной влажности и подвижности воздуха