Входные данные

Выходные данные

Информация о деятельности агентства в форме текстового файла

HTML страница “О нас”

Информация о контактах для связи с агентством в форме текстового файла

HTML страница “Контакты”

Информация о горящих турах в форме текстового файла

HTML страница “Горящие туры”

Информация об основных странах, в которые предоставляются путевки

HTML страница “О странах”

Фотографии основных стран, в которые предоставляются путевки

HTML страница “Галерея”

Логотип агентства

Отображение логотипа на страницах сайта

Текстовая информация с сайта #"600695.files/image002.gif">

Рис. 2 - Панель администратора CMS Joomla

CMS WordPress

WordPress является бесплатно и свободно распространяемой CMS. Большинство расширений ориентированы на сайты типов блога.

Достоинства:

-     Бесплатное распространение по лицензии CNU

-        Имеется удобная панель администрирования. ( Рис.4)

-        Большое разнообразие различных дополнений, модулей и плагинов.

Недостатки:

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

-        Еще одним важным недостатком данной CMS является ее уязвимость. Практика показывает, что в числе наиболее часто встречающихся интернет-проектов, которые подвергаются «взлому», блоги занимают далеко не последнее место. Поэтому если web-мастер дорожит своим проектом, управляемым при помощи

Рис. 3 - Панель администратора CMS WordPress

DataLife Engine

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

Достоинства:

-     Удобный вывод любой информации - статей, новостей, видео, аудио.

-        Имеется удобная панель администрирования. ( Рис.5)

-        Периодическое обновление версий CMS.

-        Огромное количество расширений.

-        Постоянная техническая поддержка.

Недостатки:

-     CMS является платной.

Рис.4 - Панель администратора CMS DLE

Подведем итог по рассмотренным системам управления контентом:

Эти системы обладают хорошими функциональным качествами, проработанным интерфейсом, т.е. удобность использования и оформление. CMS DLE ничем не уступает в функциональных качествах из представленных CMS, но за DLE надо заплатить за полнофункциональную версию системы, а для создания нашего программного продукта, это не подходит. CMS WordPress - эта система имеет не малый функционал, но она не подходит для создания на ней сайтов разнородной тематики, эта CMS более подходит для создания на ней блогов, размещения на ней какой-либо информации и Wordpress больше однопользовательская CMS, чем многопользовательская. Из сравнительного анализа было выявлено, что CMS Joomla более подходит для создания на ней сайта, т.к. она распространяется бесплатно и подходит для создания полнофункциональных сайтов различной тематики.

Языки программирования:

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

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

- Язык SQL используется для создания различных запросов к базе данных, под управлением СУБД MySQL.

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

Текстовые редакторы:++

Текстовый редактор, предназначенный для программистов и всех тех, кого не устраивает скромная функциональность входящего в состав Windows Блокнота. С помощью, которого можно с легкостью изменить файлы скриптов или веб страницы. В программе присутствует функция подсветки текста и возможность сворачивания блоков, согласно синтаксису языка программирования большого количества языков (C, C++, Java, XML, HTML, PHP, Java Script, ASCII, VB/VBS, SQL, CSS, Pascal, Perl, Python, Lua, TCL, Assembler).Плюс ко всему редактор распространяется бесплатно.

Microsoft Office Word

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

1.8 Перечень эксплуатационных качеств программного продукта

Сайт должен будет обладать следующими эксплуатационными качествами:

) Надежность:

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

Должно быть разграничение прав доступа;

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

Сайт должен корректно работать при большом количестве пользователей;

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

) Функциональность:

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

Должны быть средства для сжатия размера базы данных;

Все функции сайта должны корректно выполняться и не приводить к нарушению работоспособности всего сайта;

) Понятность интерфейса:

Все используемые элементы интерфейса должны быть выполнены согласно эргономическим требованиям;

Используемые пиктограммы должны быть схожи с пиктограммами ОС Windows;

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

) Удобность навигации:

Пользователю должно быть интуитивно понятно, в какой раздел ведет ссылка или объект;

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

Навигационное меню должно располагаться слева;

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

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

) Дизайн:

Дизайн сайта должен быть выполнен исходя из тематики сайта;

Цветовая гамма сайта должна радовать, вызывать приятные ассоциации у пользователей, а не отталкивать или вызывать у них дискомфорт. Чересчур яркие цвета могут отвлекать пользователей от содержимого;

Должны быть использованы блики, тени, отражения, градиенты;

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

индивидуальный предприниматель туристический сайт

2. ОСНОВНЫЕ ПРОЕКТНЫЕ РЕШЕНИЯ

2.1 Исследование предметной области

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

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

2.2 Функциональная схема программного продукта

На (рис. 5) представлена функциональная схема сайта

Рис. 5 Функциональная схема

2.3 Модульная структура программного продукта

На (рис.6) представлена модульная структура сайта

Рис.6 Модульная структура

2.4 Структурная схема

Сайт состоит из двух частей: панели администрирования и собственно сам сайт. Обе части построены по принципу блочной верстки, в блоки которых загружаются соответствующие модули. На (рис. 7) представлена блочная структура страниц сайта. Это значит, что страницы сайта состоят из отдельных модулей, которые загружаются в блоки. Все модули вместе представляют страницу сайта. Так в зависимости от выбранного раздела в модуле меню, в блок контента загружается соответствующий выбранному разделу модуль. Аналогичным образом работает и панель администрирования (рис. 8).

2.5 Сценарий пользовательского интерфейса

Исходя из структурной схемы (раздел 2.4), сайт разделен на блоки, в которые загружаются соответствующие модули. Среди всех блоков, есть такие, в которые загружается всегда один и тот же модуль, такие блоки называются статическими. К статическим блокам на сайте туристического агентства можно отнести меню горизонтальной навигации.(рис. 9)

Меню горизонтальной навигации.

Рис.9 Сценарий пользовательского интерфейса

2.6 Описание интерфейса программного продукта

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

На главной странице отображаются следующие модули:

-  Слайдшоу модуль

-              Модуль «Меню навигации»

-  Модуль «Навигация»

-              Модуль «Социальные сети»

-              Модуль «Курсы валют»

-              Модуль «Календарь»

-              Модуль «Счетчики»

-              Модуль «Контент»

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

Следующие модули содержат статическую текстовую информацию, так как все они имеют схожий интерфейс, представлен вид одного из модулей:

- Горящие туры

- О странах

Контакты

Следующие модули отображают формы HTML. Ниже приведен вид модулей:

- модуль «Формы подбора тура по критериям»

- модуль «Заказ тура»

- модуль «Рассчета стоимости тура»

И модули отображающие графическую информацию. Ниже приведен вид модулей:

модуль «Мировая карта»

- модуль «Галерея»

Администратор имеет доступ к панели администрирования

В панели администрирования можно сделать следующее:

-        Инициализация панели администратора

-        Добавление и редактирование текстовой информации на сайте

-        Добавление и редактирование пункта меню на сайте

-        Добавление и редактирование фотографий на сайте

3. РЕЗУЛЬТАТЫ ТЕСТИРОВАНИЯ

3.1 Виды тестирования

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

-     Функциональные

-        Нефункциональные

-        Связанные с изменениями

1. Функциональные виды тестирования

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

). Функциональное тестирование (Functional testing)

Тестирование функциональности может, проводится в двух аспектах:

-   требования

-        бизнес-процессы

Тестирование в перспективе «требования» использует спецификацию функциональных требований к системе как основу для дизайна тестовых случаев (Test Cases). В этом случае необходимо сделать список того, что будет тестироваться, а что нет, приоритезировать требования на основе рисков (если это не сделано в документе с требованиями), а на основе этого приоритезировать тестовые сценарии (test cases). Это позволит сфокусироваться и не упустить при тестировании наиболее важный функционал. Тестирование в перспективе «бизнес-процессы» использует знание этих самых бизнес-процессов, которые описывают сценарии ежедневного использования системы. В этой перспективе тестовые сценарии (test scripts), как правило, основываются на случаях использования системы (use cases). Преимущества функционального тестирования:

-     имитирует фактическое использование системы;

Недостатки функционального тестирования:

-     возможность упущения логических ошибок в программном обеспечении;

-        вероятность избыточного тестирования.

2). Тестирование безопасности (Security and Access Control Testing)

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

Принципы безопасности программного обеспечения.

Общая стратегия безопасности основывается на трех основных принципах:

- конфиденциальность

-        целостность

-        доступность

Конфиденциальность

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

Целостность

Существует два основных критерия при определении понятия целостности:

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

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

Доступность

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

Виды уязвимостей

В настоящее время наиболее распространенными видами уязвимости в безопасности программного обеспечения являются:(Cross-Site Scripting) - это вид уязвимости программного обеспечения (Web приложений), при которой, на генерированной сервером странице, выполняются вредоносные скрипты, с целью атаки клиента.

XSRF / CSRF (Request Forgery) - это вид уязвимости, позволяющий использовать недостатки HTTP протокола, при этом злоумышленники работают по следующей схеме: ссылка на вредоносный сайт установливается на странице, пользующейся доверием у пользователя, при переходе по вредоносной ссылке выполняется скрипт, сохраняющий личные данные пользователя (пароли, платежные данные и т.д.), либо отправляющий СПАМ сообщения от лица пользователя, либо изменяет доступ к учетной записи пользователя, для получения полного контроля над ней.injections (SQL, PHP, ASP и т.д.) - это вид уязвимости, при котором становится возможно осуществить запуск исполняемого кода с целью получения доступа к системным ресурсам, несанкционированного доступа к данным либо выведения системы из строя.Side Includes (SSI) Injection - это вид уязвимости, использующий вставку серверных команд в HTML код или запуск их напрямую с сервера.Bypass - это вид уязвимости, при котором возможно получитнесанкционированный доступ к учетной записи или документам другого пользователя

Вывод

Примеров уязвимостей и атак существует огромное количество. Даже проведя полный цикл тестирования безопасности, нельзя быть на 100% уверенным, что система по-настоящему обезопашена. Но можно быть уверенным в том, что процент несанкционированный проникновений, краж информации, потерь данных будет на несколько порядков ниже, чем у тех кто не проводил тестирования безопасности.

). Тестирование взаимодействия (Interoperability Testing)

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

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

. Нефункциональные виды тестирования

Нефункциональное тестирование описывает тесты, необходимые для определения характеристик программного обеспечения, которые могут быть измерены различными величинами. В целом, это тестирование того, "Как" система работает. Далее перечислены основные виды нефункциональных тестов:

). Все виды тестирования производительности:

Тестирование производительности (Performance testing)

Задачей тестирования производительности является определение масштабируемости приложения под нагрузкой, при этом происходит:

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

Стрессовое тестирование (Stress Testing)

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

Объемное тестирование (Volume Testing)

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

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

Тестирование стабильности или надежности (Stability / Reliability Testing)

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

). Тестирование удобства пользования (Usability Testing)

Иногда мы сталкиваемся с непонятными, нелогичными приложениями, многие функции и способы использования которых часто не очевидны. После такой работы редко возникает желание использовать приложение снова, и мы ищем более удобные аналоги. Для того чтобы приложение было популярным, ему мало быть функциональным - оно должно быть еще и удобным. Если задуматься, интуитивно понятные приложения экономят нервы пользователям и затраты работодателя на обучение. А значит они более конкурентоспособные! Поэтому тестирование удобства использования, о котором пойдет речь далее является неотъемлемой частью тестирования любых массовых продуктов.

Тестирование удобства пользования - это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. [ISO 9126]

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

эмоциональная реакция (emotional response) - как пользователь себя чувствует после завершения задачи - растерян, испытал стресс? Порекомендует ли пользователь систему своим друзьям? (положительная реакция - лучше)

Уровни проведения

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

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

Советы по улучшению удобства пользования

Для дизайна удобных приложений полезно следовать принципам «пока-йока» или fail-safe. У нас это более известно как «защита от дурака». Простой пример, если поле требует цифровое значение, логично ограничить пользователю диапазон ввода только цифрами - будет меньше случайных ошибок.

Для повышения юзабилити существующих приложений можно использовать цикл Демминга Plan-Do-Check-Act, собирая отзывы о работе и дизайне приложения у существующих пользователей, и, в соответствии с их замечаниями, планируя и проводя улучшения.

Заблуждения о тестировании удобства пользования

. Тестирование пользовательского интерфейса = Тестирование удобства пользования

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

. Тестирование удобства пользования можно провести без участия эксперта

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

). Тестирование на отказ и восстановление (Failover and Recovery Testing)

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

Тестирование на отказ и восстановление очень важно для систем, работающих по принципу “24x7”. Если Вы создаете продукт, который будет работать, например в интернете, то без проведения данного вида тестирования Вам просто не обойтись. Т.к. каждая минута простоя или потеря данных в случае отказа оборудования, может стоить вам денег, потери клиентов и репутации на рынке.

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

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

-        Отказ электричества на компьютере-сервере

-              Отказ электричества на компьютере-клиенте

-              Незавершенные циклы обработки данных (прерывание работы фильтров данных, прерывание синхронизации).

-              Объявление или внесение в массивы данных невозможных или ошибочных элементов.

-              Отказ носителей данных.

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

-     Симулировать внезапный отказ электричества на компьютере (обесточить компьютер).

-              Симулировать потерю связи с сетью (выключить сетевой кабель, обесточить сетевое устройство)

-              Симулировать отказ носителей (обесточить внешний носитель данных)

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

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

-        Потеря или порча данных в допустимых пределах.

-              Отчет или система отчетов с указанием процессов или транзакций, которые не были

-              завершены в результате сбоя.

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

). Конфигурационное тестирование (Configuration Testing)

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

В зависимости от типа проекта конфигурационное тестирование может иметь разные цели:

-        Проект по профилированию работы системы

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

-        Проект по миграции системы с одной платформы на другую

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

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

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

1.   Серверный

2.      Клиентский

На первом (серверном) уровне, тестируется взаимодействие выпускаемого программного обеспечения с окружением, в которое оно будет установлено:

1.   Аппаратные средства (тип и количество процессоров, объем памяти, характеристики сети /сетевых адаптеров и т.д.)

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

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

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

1.   Тип, версия и битность операционной системы (подобный вид тестирования называется кросс-платформенное тестирование)

2.      Тип и версия Web барузера, в случае если тестируется Web приложение (подобный вид тестирования называется кросс-браузерное тестирование)

.        Тип и модель видео адаптера (при тестировании игр это очень важно)

.        Работа приложения при различных разрешениях экрана

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

Перед началом проведения конфигурационного тестирования рекомендуется:

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

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

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

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

. Связанные с изменениями виды тестирования

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

). Дымовое тестирование или Smoke Testing

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

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

). Регрессионное тестирование или Regression Testing

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

Регрессионными могут быть как функциональные, так и нефункциональные тесты.

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

Сам по себе термин "Регрессионное тестирование", в зависимости от контекста использования может иметь разный смысл. Сэм Канер, к примеру, описал 3 основных типа регрессионного тестирования:

-     Регрессия багов (Bug regression) - попытка доказать, что исправленная ошибка на самом деле не исправлена

-              Регрессия старых багов (Old bugs regression) - попытка доказать, что недавнее изменение кода или данных сломало исправление старых ошибок, т.е. старые баги стали снова воспроизводиться.

-              Регрессия побочного эффекта (Side effect regression) - попытка доказать, что недавнее изменение кода или данных сломало другие части разрабатываемого приложения

Тестирование сборки или Build Verification Test

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

Санитарное тестирование или проверка согласованности/исправности или Sanity Testing

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

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

3.2 Методы тестирования

Существует несколько методов тестирования:

Метод «белого ящика»

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

Метод «черного ящика»

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

Метод «серого ящика»

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

Тестирование нефункциональных параметров программы

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

Это тестирование:

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

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

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

3.3 Набор тестовых данных с результатами тестирования данного ПП

Первый этап тестирования сайта был произведен с помощью методики «Черного ящика», о принципе которой было описано выше. Роль тестирования состоит в том, чтобы определить местонахождение немногочисленных ошибок, оставшихся в хорошо спроектированной программе.

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

Таблица 2 Классы эквивалентности

Таблица 3

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

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

Для тестирования был выбран тест для пользователя сайта - данный метод заключается в наблюдении за пользователем в то время, когда он решает поставленную перед ним задачу. Было дано задание найти все туристические путевки в страну Финляндию с продолжительностью 6 дней. В ходе тестирования было выявлено, что программный продукт является удобным для пользователя, так как позволяет беспрепятственно переходить с одной страницы на другую без возвращения на предыдущие страницы и находить необходимую информацию. У пользователя не возникло вопросов при выполнении поставленной перед ним задачи.

Третий этап тестирования заключается в сборке пакета при тестировании.

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

1). спроектированы ссылки на главной странице и проведено тестирование переходов на разделы сайта по ссылкам;

). спроектированы и разработаны все оставшиеся страницы;

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

). Спроектирована форма заказа и проведено тестирование отправки заказа на электронную почту.

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

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

Инструкции по использованию программного продукта

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

Инструкция использования сайта для посетителей:

При заходе на сайт, пользователю открывается главная страница, на котором имеется блок «меню навигации» в котором несколько разделов:

-              О нас

-        Туры по Европе

-        Горящие туры

-        Заказать тур

-        Рассчитать

-        Карта

-        Галерея

-        Контакты

-        О странах

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

Описание работы с каждым разделом:

. О нас

Щелкнув по гиперссылке «О нас» вы попадаете на информационную страницу, на которой вы можете ознакомиться с деятельности туристического агентства.

2. Туры по Европе

Щелкнув по гиперссылке «Туры по Европе» вы попадаете на страницу с html формой, в которой имеется возможность выбора, критериев по которым будет происходить поиск тура. Выбрав нужные вам критерия поиска тура, вы должны нажать курсором на кнопку «Найти», после чего произойдет обновление содержимого страницы и вы увидите туры по заданными вами критериями

3.   Горящие туры

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

.     Заказать тур

Щелкнув по гиперссылке «Заказать тур» вы попадаете на страницу с html формой, с помощью которой вы можете подать заявку на заказ тура. Для заказа вам необходимо ввести с клавиатуры данные в форму: имя, email, номер телефона, сообщение о заказе тура. После ввода всех данных вы должны, нажать курсором по кнопочке «Отправить сообщение», после чего вам на экран выведется сообщение об успешности отправки сообщения, а если данные были введены не верно, вы можете очистить поля, нажав курсором по кнопочке «Очистить».

.     Рассчитать

Щелкнув по гиперссылке «Рассчитать» вы попадаете на страницу с онлайн калькулятором, с помощью него вы сможете рассчитать стоимость той или иной путевки, не прибегая к стандартному калькулятору в операционной системе.

.     Карта

Щелкнув по гиперссылке «Карта» вы попадаете на страницу с мировой картой google, с помощью нее вы можете просмотреть место положение той или иной страны. Для перемещения по карте используйте кнопки слева в верхнем углу.

.     О странах

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

.     Галерея

Щелкнув по гиперссылке «Галерея» вы попадаете на страницу с альбомами стран, чтобы просмотреть альбом какой-либо из представленных стран, щелкните мышью по альбому с названием той страны, которая вас интересует.

.     Контакты

Щелкнув по гиперссылке «Контакты» вы попадаете на страницу с контактами для связи с туристическим агентством.

Инструкция использования сайта для администратора:

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

ЗАКЛЮЧЕНИЕ

В процессе разработки программного продукта была определена постановка задачи. При ее исследовании были определены входные и выходные данные и их форматы, определены функции создаваемого программного продукта, определены технические и программные требования, выявлены типы предполагаемых пользователей, изучены различные приложения для разработки web-сайтов и выбрано наиболее целесообразные по ряду критериев приложения: система управления контентом Joomla и текстовые редакторы: Notepad ++ и Microsoft Office Word. Постановка задачи и интерфейс сайта основывается на требованиях заказчика.

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

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

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

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

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

1.     Рудаков А.В. Технология разработки программных продуктов: Учеб. Пособие для студ. сред. проф. Образования. - М.: Издательский центр «Академия», 2005. - 208 с.

2.      PHP/MySQL для начинающих. Автор: Харрис Э. Издательство: Кудиц-образ 2005 г.

3.     Панфилов И.В., Самоучитель. Создание Web-сайтов, Издательство: Триумф,2008

.       ГОСТ Р 6.30-2003 УНИФИЦИРОВАННЫЕ СИСТЕМЫ ДОКУМЕНТАЦИИ "УНИФИЦИРОВАННАЯ СИСТЕМА ОРГАНИЗАЦИОННО-РАСПОРЯДИТЕЛЬНОЙ ДОКУМЕНТАЦИИ. ТРЕБОВАНИЯ К ОФОРМЛЕНИЮ ДОКУМЕНТОВ" от 1 июля 2003 г.

5.      ГОСТ 19.106-78. ЕСПД. Общие требования к программным документам, выполненным печатным способом.

6.         Молли Е., Языки HTML и CSS для создания Web-сайтов Издательство: Триумф, 2007.

.        Бенкен Е.С. PHP, MySQL, XML: программирование для Интернета. - СПб: БХВ- Петербург, 2007. - 336 с.: ил.

.        Курс лекций по предмету «Технология разработки программных продуктов»

© 2003 - 2022 «Библиофонд»

Обратная связь

Пользовательское соглашение

Политика конфиденциальности

Полная версия

Помощь по учебным работам

Консультация по курсовой работе

Консультация по дипломной работе ВКР

Консультация по реферату

Консультация по отчетам о практике