Обоснование выбора инструментальных средств создания ПП. Технология разработки сайта для индивидуального предпринимателя туристического агентства "Планета-тур". Перечень характеристик входных и выходных данных. Сценарий пользовательского интерфейса.
На настоящее время Internet развивается довольно стремительно и поэтому сейчас невозможно ни одну уважающую себя организацию, фирму или какое-либо предприятие представить без своего Web-сайта, на котором можно разместить любую информацию о предприятии, сотрудниках, и т.д. Данная технология гиперсвязи страниц позволяет пользователю быстро осуществлять перемещение внутри страницы, или же с одной страницы на другую, в поисках необходимой для него информации.В современных условиях уже довольно сложно представить себе развитие общества без использования такого блага цивилизации, как Интернет. Под информационной функцией понимается, что сайт будет основываться на предоставление, какой-либо информации пользователям, относящейся к тематике сайта.Под удаленным приложением понимается, что сайт будет основываться на предоставление функций пользователям, чтобы упростить выполнение каких-либо действий. Недостатки: - На сайте присутствует минимальное количество функций, т.е. сайт практически не упрощает деятельность оператора, а так же не упрощает действий пользователей, например в заказе путевки. На сайте представлена в основном лишь информация, о туристическом агентстве и путевках какие оно предоставляет, что касается функциональности сайта, то здесь имеется лишь функция связи пользователя с оператором. Недостатки: - Минимальное количество функций, т.е. сайт не упрощает деятельность как - оператора, так и пользователя. Он будет представлять собой сайт, с помощью, которого предприниматель мог бы заявить о своей деятельности, сообщить информацию об основных странах в которые предоставляются путевки , об услугах, которые он предоставляет, о контактах для связи с агентством и формах заказа услуги.Работа руководителя данного агентства заключается в принятие и оформление заявок от клиентов на предоставление туристической путевки, а также предоставление информации об имеющихся туристических путевках. В офис агентства приходят клиенты, где им помогают подобрать и оформить путевку, затем руководитель агентства связывается с агентством, предоставляющим путевку и заключают договор. Сайт позволит упростить деятельность агентства «Планета-тур», в плане принятия заявок от клиентов на предоставление путевки и подбора путевки для клиента. Так же сайт позволит предоставлять информацию о имеющихся путевках, контактные данные для связи с агентством и информацию о деятельности агентства. Так в зависимости от выбранного раздела в модуле меню, в блок контента загружается соответствующий выбранному разделу модуль.Все виды тестирования программного обеспечения, в зависимости от преследуемых целей, можно условно разделить на следующие группы: - Функциональные Функциональные виды тестирования - это тестирования программного продукта в целях проверки реализуемости функциональных требований, то есть его способности в определенных условиях решать задачи, нужные пользователям. Тестирование в перспективе «требования» использует спецификацию функциональных требований к системе как основу для дизайна тестовых случаев (Test Cases). В этом случае необходимо сделать список того, что будет тестироваться, а что нет, приоритезировать требования на основе рисков (если это не сделано в документе с требованиями), а на основе этого приоритезировать тестовые сценарии (test cases). Тестирование в перспективе «бизнес-процессы» использует знание этих самых бизнес-процессов, которые описывают сценарии ежедневного использования системы.Нефункциональное тестирование описывает тесты, необходимые для определения характеристик программного обеспечения, которые могут быть измерены различными величинами. В целом, это тестирование того, "Как" система работает. Задачей тестирования производительности является определение масштабируемости приложения под нагрузкой, при этом происходит: измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций определение количества пользователей, одновременно работающих с приложением определение границ приемлемой производительности при увеличении нагрузки (при увеличении интенсивности выполнения этих операций) исследование производительности на высоких, предельных, стрессовых нагрузках. Задачей объемного тестирования является получение оценки производительности при увеличении объемов данных в базе данных приложения, при этом происходит: измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций может производиться определение количества пользователей, одновременно работающих с приложением. Тестирование удобства пользования дает оценку уровня удобства использования приложения по следующим пунктам: производительность, эффективность (efficiency) - сколько времени и шагов понадобится пользователю для завершения основных задач приложения, например, размещение новости, регистрации, покупка и т.д.В процессе разработки программного продукта была определена постановка задачи. При ее исследовании были определены входные и выходные данные и их форматы,
Вывод
Примеров уязвимостей и атак существует огромное количество. Даже проведя полный цикл тестирования безопасности, нельзя быть на 100% уверенным, что система по-настоящему обезопашена. Но можно быть уверенным в том, что процент несанкционированный проникновений, краж информации, потерь данных будет на несколько порядков ниже, чем у тех кто не проводил тестирования безопасности.
3). Тестирование взаимодействия (Interoperability Testing)
С развитием сетевых технологий и интернета взаимодействие разных систем, сервисов и приложений друг с другом приобрело значительную актуальность, так как любые связанные с этим проблемы могут привести к падению авторитета компании, что как следствие повлечет за собой финансовые потери. Поэтому к тестированию взаимодействия стоит подходить со всей серьезностью.
Тестирование взаимодействия (Interoperability Testing) - это функциональное тестирование, проверяющее способность приложения взаимодействовать с одним и более компонентами или системами и включающее в себя тестирование совместимости (compatibility testing) и интеграционное тестирование (integration testing).
Программное обеспечение с хорошими характеристиками взаимодействия может быть легко интегрировано с другими системами, не требуя каких-либо серьезных модификаций. В этом случае, количество изменений и время, требуемое на их выполнение, могут быть использованы для измерения возможности взаимодействия.
2. Нефункциональные виды тестирования
Нефункциональное тестирование описывает тесты, необходимые для определения характеристик программного обеспечения, которые могут быть измерены различными величинами. В целом, это тестирование того, "Как" система работает. Далее перечислены основные виды нефункциональных тестов: 1). Все виды тестирования производительности: Тестирование производительности (Performance testing)
Задачей тестирования производительности является определение масштабируемости приложения под нагрузкой, при этом происходит: измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций определение количества пользователей, одновременно работающих с приложением определение границ приемлемой производительности при увеличении нагрузки (при увеличении интенсивности выполнения этих операций) исследование производительности на высоких, предельных, стрессовых нагрузках.
Стрессовое тестирование (Stress Testing)
Стрессовое тестирование позволяет проверить насколько приложение и система в целом работоспособны в условиях стресса и также оценить способность системы к регенерации, т.е. к возвращению к нормальному состоянию после прекращения воздействия стресса. Стрессом в данном контексте может быть повышение интенсивности выполнения операций до очень высоких значений или аварийное изменение конфигурации сервера. Также одной из задач при стрессовом тестировании может быть оценка деградации производительности, таким образом цели стрессового тестирования могут пересекаться с целями тестирования производительности.
Объемное тестирование (Volume Testing)
Задачей объемного тестирования является получение оценки производительности при увеличении объемов данных в базе данных приложения, при этом происходит: измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций может производиться определение количества пользователей, одновременно работающих с приложением.
Тестирование стабильности или надежности (Stability / Reliability Testing)
Задачей тестирования стабильности (надежности) является проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки. Времена выполнения операций могут играть в данном виде тестирования второстепенную роль. При этом на первое место выходит отсутствие утечек памяти, перезапусков серверов под нагрузкой и другие аспекты влияющие именно на стабильность работы.
Иногда мы сталкиваемся с непонятными, нелогичными приложениями, многие функции и способы использования которых часто не очевидны. После такой работы редко возникает желание использовать приложение снова, и мы ищем более удобные аналоги. Для того чтобы приложение было популярным, ему мало быть функциональным - оно должно быть еще и удобным. Если задуматься, интуитивно понятные приложения экономят нервы пользователям и затраты работодателя на обучение. А значит они более конкурентоспособные! Поэтому тестирование удобства использования, о котором пойдет речь далее является неотъемлемой частью тестирования любых массовых продуктов.
Тестирование удобства пользования - это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. [ISO 9126]
Тестирование удобства пользования дает оценку уровня удобства использования приложения по следующим пунктам: производительность, эффективность (efficiency) - сколько времени и шагов понадобится пользователю для завершения основных задач приложения, например, размещение новости, регистрации, покупка и т.д. (меньше - лучше) правильность (accuracy) - сколько ошибок сделал пользователь во время работы с приложением?(меньше - лучше) активизация в памяти (recall) - как много пользователь помнит о работе приложения после приостановки работы с ним на длительный период времени? (повторное выполнение операций после перерыва должно проходить быстрее чем у нового пользователя) эмоциональная реакция (emotional response) - как пользователь себя чувствует после завершения задачи - растерян, испытал стресс? Порекомендует ли пользователь систему своим друзьям? (положительная реакция - лучше)
Уровни проведения
Проверка удобства использования может проводиться как по отношению к готовому продукту, посредством тестирования черного ящика (black box testing), так и к интерфейсам приложения (API), используемым при разработке - тестирование белого ящика (white box testing). В этом случае проверяется удобство использования внутренних объектов, классов, методов и переменных, а также рассматривается удобство изменения, расширения системы и интеграции ее с другими модулями или системами. Использование удобных интерфейсов (API) может улучшить качество, увеличить скорость написания и поддержки разрабатываемого кода, и как следствие улучшить качество продукта в целом.
Отсюда становится очевидно, что тестирование удобства пользования может производиться на разных уровнях разработки программного обеспечения: модульном, интеграционном, системном и приемочном. При этом оно целиком и полностью будет зависит от того, кто будет использовать приложение на выделенном конкретном уровне - разработчик, бизнес пользователь системы и т.д.
Советы по улучшению удобства пользования
Для дизайна удобных приложений полезно следовать принципам «пока-йока» или failsafe. У нас это более известно как «защита от дурака». Простой пример, если поле требует цифровое значение, логично ограничить пользователю диапазон ввода только цифрами - будет меньше случайных ошибок.
Для повышения юзабилити существующих приложений можно использовать цикл Демминга Plan-Do-Check-Act, собирая отзывы о работе и дизайне приложения у существующих пользователей, и, в соответствии с их замечаниями, планируя и проводя улучшения.
Тестирование удобства пользования не имеет ничего общего с тестированием функциональности пользовательского интерфейса, оно лишь проводится на пользовательском интерфейсе равно как и на многих других возможных компонентах продукта. При этом тип тестирования и тесткейсы будут совсем другие, так как речь может идти об удобстве использования не визуальных компонентов (если таковые имеются) или процессе администрирования, например, распределенного клиент-серверного продукта и т.д.
2. Тестирование удобства пользования можно провести без участия эксперта
Не всегда человек не разбирающийся в предметной области способен провести его самостоятельно. Представьте, что тестировщику нужно протестировать удобство пользования стратегического бомбардировщика. Ему придется проверить основные функции: удобство ведения боя, навигации, пилотирования, обслуживания, наземной транспортировки и т.д. Очевидно, что без привлечения эксперта это будет весьма проблематично, и можно даже сказать, что невозможно.
3). Тестирование на отказ и восстановление (Failover and Recovery Testing)
Тестирование на отказ и восстановление (Failover and Recovery Testing) проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети). Целью данного вида тестирования является проверка систем восстановления (или дублирующих основной функционал систем), которые, в случае возникновения сбоев, обеспечат сохранность и целостность данных тестируемого продукта.
Тестирование на отказ и восстановление очень важно для систем, работающих по принципу “24x7”. Если Вы создаете продукт, который будет работать, например в интернете, то без проведения данного вида тестирования Вам просто не обойтись. Т.к. каждая минута простоя или потеря данных в случае отказа оборудования, может стоить вам денег, потери клиентов и репутации на рынке.
Методика подобного тестирования заключается в симулировании различных условий сбоя и последующем изучении и оценке реакции защитных систем. В процессе подобных проверок выясняется, была ли достигнута требуемая степень восстановления системы после возникновения сбоя.
Для наглядности рассмотрим некоторые варианты подобного тестирования и общие методы их проведения. Объектом тестирования в большинстве случаев являются весьма вероятные эксплуатационные проблемы, такие как: - Отказ электричества на компьютере-сервере
- Отказ электричества на компьютере-клиенте
- Незавершенные циклы обработки данных (прерывание работы фильтров данных, прерывание синхронизации).
- Объявление или внесение в массивы данных невозможных или ошибочных элементов.
- Отказ носителей данных.
Данные ситуации могут быть воспроизведены, как только достигнута некоторая точка в разработке, когда все системы восстановления или дублирования готовы выполнять свои функции. Технически реализовать тесты можно следующими путями: - Симулировать внезапный отказ электричества на компьютере (обесточить компьютер).
- Симулировать потерю связи с сетью (выключить сетевой кабель, обесточить сетевое устройство)
- Симулировать ситуацию наличия в системе неверных данных (специальный тестовый набор или база данных).
При достижении соответствующих условий сбоя и по результатам работы систем восстановления, можно оценить продукт с точки зрения тестирования на отказ. Во всех вышеперечисленных случаях, по завершении процедур восстановления, должно быть достигнуто определенное требуемое состояние данных продукта: - Потеря или порча данных в допустимых пределах.
- Отчет или система отчетов с указанием процессов или транзакций, которые не были
- завершены в результате сбоя.
Стоит заметить, что тестирование на отказ и восстановление - это весьма продукт специфичное тестирование. Разработка тестовых сценариев должна производиться с учетом всех особенностей тестируемой системы. Принимая во внимание довольно жесткие методы воздействия, стоит также оценить целесообразность проведения данного вида тестирования для конкретного программного продукта.
Конфигурационное тестирование (Configuration Testing) - специальный вид тестирования, направленный на проверку работы программного обеспечения при различных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров и т.д.)
В зависимости от типа проекта конфигурационное тестирование может иметь разные цели: - Проект по профилированию работы системы
Цель тестирования: определить оптимальную конфигурацию оборудования, обеспечивающую требуемые характеристики производительности и времени реакции тестируемой системы.
- Проект по миграции системы с одной платформы на другую
Цель Тестирования: Проверить объект тестирования на совместимость с объявленным в спецификации оборудованием, операционными системами и программными продуктами третьих фирм.
Уровни проведения тестирования
Для клиент-серверных приложений конфигурационное тестирование можно условно разделить на два уровня (для некоторых типов приложений может быть актуален только один): 1. Серверный
2. Клиентский
На первом (серверном) уровне, тестируется взаимодействие выпускаемого программного обеспечения с окружением, в которое оно будет установлено: 1. Аппаратные средства (тип и количество процессоров, объем памяти, характеристики сети /сетевых адаптеров и т.д.)
2. Программные средства (ОС, драйвера и библиотеки, стороннее ПО, влияющее на работу приложения и т.д.)
Основной упор здесь делается на тестирование с целью определения оптимальной конфигурации оборудования, удовлетворяющего требуемым характеристикам качества (эффективность, портативность, удобство сопровождения, надежность).
На следующем (клиентском) уровне, программное обеспечение тестируется с позиции его конечного пользователя и конфигурации его рабочей станции. На этом этапе будут протестированы следующие характеристики: удобство использования, функциональность. Для этого необходимо будет провести ряд тестов с различными конфигурациями рабочих станций: 1. Тип, версия и битность операционной системы (подобный вид тестирования называется кросс-платформенное тестирование)
2. Тип и версия Web барузера, в случае если тестируется Web приложение (подобный вид тестирования называется кросс-браузерное тестирование)
3. Тип и модель видео адаптера (при тестировании игр это очень важно)
4. Работа приложения при различных разрешениях экрана
5. Версии драйверов, библиотек и т.д. (для JAVA приложений версия JAVA машины очень важна, тоже можно сказать и для .NET приложений касательно версии .NET библиотеки)и т.д.
Порядок проведения тестирования
Перед началом проведения конфигурационного тестирования рекомендуется: - создавать матрицу покрытия (матрица покрытия - это таблица, в которую заносят все возможные конфигурации), - проводить приоритезацию конфигураций (на практике, скорее всего, все желаемые конфигурации проверить не получится), - шаг за шагом, в соответствии с расставленными приоритетами, проверяют каждую конфигурацию.
Уже на начальном этапе становится очевидно, что чем больше требований к работе приложения при различных конфигурациях рабочих станций, тем больше тестов нам необходимо будет провести. В связи с этим, рекомендуем, по возможности, автоматизировать этот процесс, так как именно при конфигурационном тестировании автоматизация реально помогает сэкономить время и ресурсы. Конечно же автоматизированное тестирование не является панацеей, но в данном случае оно окажется очень эффективным помощником.
3. Связанные с изменениями виды тестирования
После проведения необходимых изменений, таких как исправление бага/дефекта, программное обеспечение должно быть пере тестировано для подтверждения того факта, что проблема была действительно решена. Ниже перечислены виды тестирования, которые необходимо проводить после установки программного обеспечения, для подтверждения работоспособности приложения или правильности осуществленного исправления дефекта: 1). Дымовое тестирование или Smoke Testing
Применяется для поверхностной проверки всех модулей приложения на предмет работоспособности и наличия быстро находимых критических и блокирующих дефектов. Подвидом дымового тестирования являются Build Verification Testing или Acceptance Testing, выполняемые на функциональном уровне командой тестирования, по результатам которого делается вывод о том, принимается или нет установленная версия программного обеспечения в тестирование, эксплуатацию или на поставку заказчику.
Для облегчения работы, экономии времени и людских ресурсов рекомендуется внедрить автоматизацию тестовых сценариев для дымового тестирования.
2). Регрессионное тестирование или 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
Осуществляемое действие Ожидаемый результат Фактический результат
Щелчок по гиперссылке «Главная страница» Открытие главной страницы Открытие главной страницы
Щелчок по гиперссылке «О нас» Открытие страницы о деятельности турагентства Открытие страницы о деятельности турагентства
Щелчок по гиперссылке «Туры по Европе» Открытие страницы с подбором туров по Европе Открытие страницы с подбором туров по Европе
Щелчок по гиперссылке «Горящие туры» Открытие страницы со списком горящих туров Открытие страницы со списком горящих туров
Щелчок по гиперссылке «Заказать тур» Открытие страницы с формой заказа тура Открытие страницы с формой заказа тура
Щелчок по гиперссылке «Рассчитать» Открытие страницы с онлайн калькулятором для подсчета стоимости тура Открытие страницы с онлайн калькулятором для подсчета стоимости тура
Щелчок по гиперссылке «Карта» Открытие страницы с мировой картой от Google Открытие страницы с мировой картой от Google
Щелчок по гиперссылке «О странах» Открытие страницы со списком основных стран, в которые предоставляются путевки Открытие страницы со списком основных стран, в которые предоставляются путевки
Щелчок по гиперссылке «Галерея» Открытие страницы с альбомами основных стран, в которые предоставляются путевки Открытие страницы с альбомами основных стран, в которые предоставляются путевки
Щелчок по гиперссылке «Контакты» Открытие страницы с контактами для связи с турагентством Открытие страницы с контактами для связи с турагентством
При проведении тестирования была проверена работа всех ссылок, размещенных на сайте. Все переходы осуществляются корректно в соответствии с междустраничными связями. Ссылки, которые имеют не существующий адрес, отсутствуют.
Второй этап тестирования заключался в тестах на удобство пользования - эти тесты помогают выявить трудности, возникающие у пользователя при работе с программой, а также определить причины этих затруднений.
Для тестирования был выбран тест для пользователя сайта - данный метод заключается в наблюдении за пользователем в то время, когда он решает поставленную перед ним задачу. Было дано задание найти все туристические путевки в страну Финляндию с продолжительностью 6 дней. В ходе тестирования было выявлено, что программный продукт является удобным для пользователя, так как позволяет беспрепятственно переходить с одной страницы на другую без возвращения на предыдущие страницы и находить необходимую информацию. У пользователя не возникло вопросов при выполнении поставленной перед ним задачи.
Третий этап тестирования заключается в сборке пакета при тестировании.
В ходе тестирования было выявлено, что программный продукт является удобным для пользователя, так как позволяет беспрепятственно переходить с одной страницы на другую без возвращения на предыдущие страницы. Сборка сайта при тестировании осуществлялась пошаговым методом сверху - вниз. Такой метод сборки предполагает последовательное подключение к набору уже оттестированных страниц очередной страницы. Сборка в процессе тестирования осуществлялась в последовательности: 1). спроектированы ссылки на главной странице и проведено тестирование переходов на разделы сайта по ссылкам;
2). спроектированы и разработаны все оставшиеся страницы;
3). спроектированы и разработаны связи между страницами (переход по гиперссылкам), а также проведено их тестирование.
3). Спроектирована форма заказа и проведено тестирование отправки заказа на электронную почту.
4). Проведено тестирование модулей на сайте, в частности их работоспособность, в процессе тестирования неполадки не обнаружены.
В ходе сборки пакета на каждом этапе проводилось тщательное тестирование страниц. В результате пошаговой сборки сайта ошибки между модулями обнаруживались и устранялись на ранних стадиях проектирования и кодирования сайта. Тестирование сайта в целом после завершения сборки показало, что сайт можно считать работоспособным и готовым к применению.
Инструкции по использованию программного продукта
Сайт функционирует в двух режимах доступа: для посетителей и для администратора.
Инструкция использования сайта для посетителей: При заходе на сайт, пользователю открывается главная страница, на котором имеется блок «меню навигации» в котором несколько разделов: - О нас
- Туры по Европе
- Горящие туры
- Заказать тур
- Рассчитать
- Карта
- Галерея
- Контакты
- О странах
Пользователь может переходить по этим разделам, щелкнув правой клавишей мыши по гиперссылке.
Описание работы с каждым разделом: 1. О нас
Щелкнув по гиперссылке «О нас» вы попадаете на информационную страницу, на которой вы можете ознакомиться с деятельности туристического агентства.
2. Туры по Европе
Щелкнув по гиперссылке «Туры по Европе» вы попадаете на страницу с html формой, в которой имеется возможность выбора, критериев по которым будет происходить поиск тура. Выбрав нужные вам критерия поиска тура, вы должны нажать курсором на кнопку «Найти», после чего произойдет обновление содержимого страницы и вы увидите туры по заданными вами критериями
3. Горящие туры
Щелкнув по гиперссылке «Горящие туры» вы попадаете на страницу со списком всех имеющихся горящих туров, чтобы просмотреть подробную информацию, о горящем туре, вам необходимо щелкнуть по гиперссылке, того или иного горящего тура, затем обновится содержимое страницы и будет выведена подробная информация о горящем туре.
4. Заказать тур
Щелкнув по гиперссылке «Заказать тур» вы попадаете на страницу с html формой, с помощью которой вы можете подать заявку на заказ тура. Для заказа вам необходимо ввести с клавиатуры данные в форму: имя, email, номер телефона, сообщение о заказе тура. После ввода всех данных вы должны, нажать курсором по кнопочке «Отправить сообщение», после чего вам на экран выведется сообщение об успешности отправки сообщения, а если данные были введены не верно, вы можете очистить поля, нажав курсором по кнопочке «Очистить».
5. Рассчитать
Щелкнув по гиперссылке «Рассчитать» вы попадаете на страницу с онлайн калькулятором, с помощью него вы сможете рассчитать стоимость той или иной путевки, не прибегая к стандартному калькулятору в операционной системе.
6. Карта
Щелкнув по гиперссылке «Карта» вы попадаете на страницу с мировой картой google, с помощью нее вы можете просмотреть место положение той или иной страны. Для перемещения по карте используйте кнопки слева в верхнем углу.
7. О странах
Щелкнув по гиперссылке «О странах» вы попадаете на страницу со списком основных стран, в которые предоставляются путевки, чтобы просмотреть информацию по стране, вы должны щелкнуть по гиперссылке страны и перейти на новую страницу для просмотра информации по стране.
8. Галерея
Щелкнув по гиперссылке «Галерея» вы попадаете на страницу с альбомами стран, чтобы просмотреть альбом какой-либо из представленных стран, щелкните мышью по альбому с названием той страны, которая вас интересует.
9. Контакты
Щелкнув по гиперссылке «Контакты» вы попадаете на страницу с контактами для связи с туристическим агентством.
Инструкция использования сайта для администратора: В приложение к курсовому проекту будет, прилагаться электронная книга «руководство Joomla» , в которой вы можете найти все интересующую информацию по использования панели администратора.
Вы можете ЗАГРУЗИТЬ и ПОВЫСИТЬ уникальность своей работы
