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

ЛИЧНЫЙ КАБИНЕТ 

 

Здравствуйте гость!

 

Логин:

Пароль:

 

Запомнить

 

 

Забыли пароль? Регистрация

Повышение уникальности

Предлагаем нашим посетителям воспользоваться бесплатным программным обеспечением «StudentHelp», которое позволит вам всего за несколько минут, выполнить повышение уникальности любого файла в формате MS Word. После такого повышения уникальности, ваша работа легко пройдете проверку в системах антиплагиат вуз, antiplagiat.ru, etxt.ru или advego.ru. Программа «StudentHelp» работает по уникальной технологии и при повышении уникальности не вставляет в текст скрытых символов, и даже если препод скопирует текст в блокнот – не увидит ни каких отличий от текста в Word файле.

Работа № 97383


Наименование:


Диплом Методологии тестирования на примере тестирования сайтов

Информация:

Тип работы: Диплом. Добавлен: 30.5.2016. Сдан: 2013. Страниц: 64. Уникальность по antiplagiat.ru: < 30%

Описание (план):


Содержание
1 ТЕОРЕТИЧЕСКАЯ ЧАСТЬ 5
1.1 Техническое задание на разработку программного продукта 6
1.2 Организация ввода - вывода и пользовательского интерфейса 36
1.1.1 Входные данные 36
1.1.2 Выходные данные 36
1.1.3 Интерфейс пользователя 36
1.3 Структурная схема программы 37
2 ПРАКТИЧЕСКАЯ ЧАСТЬ 38
2.1 Выбор и обоснование языка программирования 39
2.2 Выбор стиля, методов и средств программирования 39
2.3 Описание программы 40
2.3.1 Общие сведения 40
2.3.2 Функциональное назначение программы 40
2.3.3 Описание логической структуры 40
2.3.4 Используемые технические средства 40
2.3.5 Вызов и загрузка 41
2.3.6 Входные данные 41
2.3.7 Выходные данные 41
2.4 Тестирование программы 42
Список литературы 43

ВВЕДЕНИЕ

Тема дипломной работы «Методологии тестирования на примере тестирования сайтов» является актуальной, так как в настоящее время вопросу тестирования программного обеспечения (ПО) уделяется все больше внимания, как со стороны производителей ПО, так и со стороны научной общественности.
Потребность в решении задач тестирования ПО возникает при создании практически каждого программного продукта. При этом подходы к их решению могут существенно отличаться в зависимости от характеристик ПО, подлежащего тестированию.
В области тестирования ПО ведутся активные исследования, а значит решаемые задачи по этой тематике актуальны.
Настоящая работа посвящена рассмотрению наиболее важных, по мнению автора, задач тестирования ПО, а также перспективных направлений их решения.
Предложенная классификация задач позволит проследить связи между зависимыми задачами с целью оптимизации процесса тестирования, а также поможет при выборе инструментов и подходов к их решению.
Тестирование программного обеспечения - это отдельная дисциплина, требующая специальных навыков.
Основная цель тестировщика - изучить оптимальные подходы к задачам тестирования и, в конечном счете, наладить рабочий процесс тестирования для будущих проектов.
Чем сложнее сайт, тем в более серьезном тестировании он нуждается. Многие разработчики и заказчики упускают этап тестирования сайта, в результате это может привести к серьёзным финансовым потерям, дополнительным трудозатратам и недовольству пользователей. По утверждениям ведущих специалистов одно только usability-тестирование сайта и следование рекомендациям по его улучшению может повысить экономические показатели на 135% и выше!
1. 1 ТЕОРЕТИЧЕСКАЯ ЧАСТЬ
Выполнили: _____________ Е.С.Смирнова.
Руководитель: _____________ Н.Ю. Хренова.
«__»_______2013

1.1 Техническое задание на разработку программного продукта
Основная цель тестирования - это обнаружение ошибок в ПО до того, как их найдут пользователи. Есть две концепции, о которых необходимо знать.
1. Проверка ПО на 100%.
2. Нахождение максимального количества багов.
По первой концепции можно сказать одно - 100% проверка ПО невозможна. Полное и абсолютное тестирование выглядит скорее мечтой, чем реальностью. Вот простой пример: еще в 1979 г. Майерс (Myers) описал некоторый простой алго­ритм. В нем был всего один цикл и несколько операторов услов­ного перехода. В большинстве языков программирования для кодирования такого алгоритма потребуется не более 20 строк кода. Но такая программа имеет более 100 триллионов путей выполне­ния! Самому быстрому тестировщику для полного тестирования потребовался бы как минимум миллион лет.
Таким образом, целью тестирования является не тотальное обнаружение всех ошибок (это принципиально невозможно), а выявление наибольшего количества наиболее критичных ошибок (вторая концепция).
Основными критериями завершенности тестирования яв­ляется отсутствие критичных ошибок, каждая из которых может сделать абсолютно невозможной реализацию декларированной в системе прикладной функциональности (решение принимается по результатам функционального тестирования). Кроме того, при принятии решения учитывается общее количество зарегистриро­ванных, но неисправленных ошибок. Компания-разработчик обычно заранее выбирает по каждому программному продукту общее количество ошибок (лимит), с которым уже нельзя выпус­кать программный продукт.
Тестирование (testing) - это проверка соответствия между реальным поведением программы и ее ожидаемым поведением на ограниченном наборе тестов, выбранном определенным образом.
Можно дать и другое определение тестирования, но смысл не изменится.
Тестирование (testing) - это проверка соответствия программы требованиям, осуществляемая путем наблюдения за ее работой в специальных, искусственно созданных ситуациях, выбранных определенным образом.
Баг(bug) - это отклонение фактического результата (actual result) от ожидаемого результата (expected result).
Ожидаемый результат (expected result) - результат, который мы ожидаем.
Фактический результат (actual result)- результат, который мы получили по факту.
Спецификация (spec) - это детальное описание того, как должно работать ПО. В большинстве случаев баг - это отклонение от спецификации.
Тестирование программного обеспечения выполняет две базовых функции: верификацию и аттестацию. В функции верификации и аттестации (verificationand validation, V&V) определяются следующим образом:
а) Верификация (verification) обеспечивает соответствие результатов конкретной фазы процесса разработки требованиям данной и предшествующей стадий
б) Аттестация (validation) есть гарантия того, что программный продукт удовлетворяет системным требованиям.
Тестовый случай (Test Case) - это совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Тестовое покрытие (Test Coverage) - это набор тестов для проверки тестируемой функции. Расчет тестового покрытия проводится по формуле: отношение кол-ва строк кода, покрытых тестами, к общему кол-ву строк кода тестируемой функции, умноженное на 100%.
Front end (читается как "фронт-энд") - это непосредственный интерфейс пользователя, т.е. текст, картинки, кнопки, линки и прочие вещи, которые пользователь видите окне Web-браузера или E-Mail клиента.
Back end (читается как "бэк-энд") - это ПО и данные, находящиеся за фасадом фронт-энда: HTML-код Web-страницы, Web-сервер, код приложения, база данных и т.д.
Покрытие исполнения тестов - это всегда величина конкретная, и выражается она процентным отношением исполненных тестов к общему количеству тестов.
Немедленная польза от классификации в отношении видов тестирования заключается в том, что упорядоченная и обобщенная информация легче воспринимается. Для начала мы перечислим все виды классификаций, а потом поясним.
1) По знанию внутренностей системы:
a. черный ящик (black box testing)
b. серый ящик (grey box testing)
c. белый ящик (white box testing)
2) По объекту тестирования:
a. функциональное тестирование (functional testing)
b. тестирование интерфейса пользователя (UI testing)
c. тестирование локализации (localization testing)
d. тестирование производительности (performance testing)
e. тестирование безопасности (security testing)
f. тестирование опыта пользователей (usability testing)
g. Конфигурационное тестирование (configuration testing)
3) По субъекту тестирования:
a. альфа-тестировщик (alpha-tester)
b. бета-тестировщик (beta-tester)
4) По времени проведения тестирования:
a. альфа-тестирование (alpha-testing)
b. бета-тестирование (beta-testing)
5) По критерию "позитивности" сценариев:
a. позитивное тестирование (positive testing)
b. негативное тестирование (negative testing)
6) По степени изолированности тестируемых компонентов:
a. компонентное тестирование (component testing)
b. интеграционное тестирование (integration testing)
c. системное тестирование (system testing)
d. приемочное тестирование (acceptance testing)
7) По степени автоматизации тестирования:
a. ручное тестирование (manual testing)
b. автоматизированное тестирование (automated testing)
c. смешанное/полуавтоматическое тестирование (semiautomated testing)
8) По степени подготовки к тестированию:
a. тестирование по документации (formal/documented testing)
b. эд хок-тестирование (ad hoc testing)
Теперь подробно разберем каждую из классификаций.
1) По знанию внутренней системы
Черный ящик (black box) - это не что иное, как тестируемые части бэк-энда составляющие невидимый пользователю виртуальный мост, который соединяет:
· Фактический ввод
· Фактический вывод
Признаки подхода "Черный ящик":
1. Тестировщик не знает, как устроен виртуальный мост.
Черный ящик тестировщику, знающему лишь то, для чего был написан код (т.е. функциональности), а не как он был написан, легче смотреть на тестирование с точки зрения пользователя, но с другой стороны такое тестирование ведется в слепую, так как ни одна из частей виртуального моста неизвестна.
2. Идеи для тестирования идут от предполагаемых образцов (паттернов) поведения пользователей. Поэтому подход "Черный ящик" также называют поведенческим.
Предполагаемые паттерны поведения пользователей - это те сценарии и данные, которые, как мы ожидаем, будут реализовываться и вводиться пользователем.
Основные источники предполагаемых паттернов поведения пользователей могут быть:
· напрямую взяты из спецификации
· найдены путем эксплоринга
· получены путем применения методики черноящичного тестирования
· программистом или продюсером
При подходе "Черный ящик" тестировщик не основывает идеи для тестирования на знании об устройстве и логике тестируемой части бэк-энда.
Белый ящик (white box) - также известен под именами Стеклянный ящик (glass/ clear box), Открытый ящик (open box).
В отличие от "Черного ящика" при подходе "Белый ящик" тестировщик основывает идеи для тестирования на знании об устройстве и логике тестируемой части бэк-энда.
Таким образом, при белоящичном тестировании сценарии создаются с мыслью о том, чтобы протестировать определенную часть бэк-энда, а не определенный паттерн поведения пользователя.
Покрытие возможных сценариев - это одна из частей важнейшей концепции, называемой тестировочное покрытие, которое состоит из двух вещей:
· покрытие возможных сценариев
· покрытие исполнения тестов
Симбиоз использования подходов "Черный ящик" и "Белый ящик" увеличивает покрытие возможных сценариев
· количественно, потому что появляется большее количество тестов
· качественно, так как ПО тестируется принципиально разными подходами
В реальной жизни белоящичное тестирование проводится самим программистом или коллегами-программистами с квалификацией того же уровня. Юнит-тест относится к методу "Белый ящик".
Серый ящик(grey box) - Этот подход, сочетающий элементы двух предыдущих подходов, это:
· с одной стороны, тестирование, ориентированное на пользователя, а значит, мы используем паттерны поведения пользователя.
· с другой стороны, информированное тестирование, т.е. мы знаем, как устроена хотя бы часть тестируемого бэк-энда, и активно используем это знание.
На практике именно этот подход используется чаще всего, так как использование какого-то одного из подходов не даст полного результата.
2) По объекту тестирования
Функциональное тестирование рассматривает заранее указанное поведение и основывается на анализе спецификаций функциональности компонента или системы в целом.
Функциональные тесты основываются на функциях, выполняемых системой, и могут проводиться на всех уровнях тестирования (компонентном, интеграционном, системном, приемочном). Как правило, эти функции описываются в требованиях, функциональных спецификациях или в виде случаев использования системы.
Тестирование функциональности может проводиться в двух аспектах:
· требования
· бизнес-процессы
Тестирование в перспективе «требования» использует спецификацию функциональных требований к системе как основу для дизайна тест-кейсов. В этом случае необходимо сделать список того, что будет тестироваться, а что нет, приоритезировать требования на основе рисков (если это не сделано в документе с требованиями), а на основе этого приоритезировать тестовые сценарии (test cases). Это позволит сфокусироваться и не упустить при тестировании наиболее важный функционал.
Тестирование в перспективе «бизнес-процессы» использует знание этих самых бизнес-процессов, которые описывают сценарии ежедневного использования системы. В этой перспективе тестовые сценарии (test scripts), как правило, основываются на случаях использования системы (use cases).
Преимущества функционального тестирования:
· имитирует фактическое использование системы;
Недостатки функционального тестирования:
· возможность упущения логических ошибок в программном обеспечении;
· вероятность избыточного тестирования.
Достаточно распространенной является автоматизация функционального тестирования.
Тестирование интерфейса пользователя(UI testing) - это тестирование, при котором проверяются элементы интерфейса пользователя.
Важно понимать разницу между
· тестированием интерфейса пользователя и
· тестированием с помощью интерфейса пользователя.
Тестирование локализации - это процесс тестирования локализованной версии программного продукта. Проверка правильности перевода элементов интерфейса пользователя, проверка правильности перевода системных сообщений и ошибок, проверка перевода раздела "Помощь"/"Справка" и сопроводительной документации.
С помощью тестирования локализации проверяются перевод, адаптация элементов интерфейса, вспомогательные файлы, правильное обоснование и адаптация элементов интерфейса, а также правила написания текста.
Цель теста локализации - убедиться, что приложение поддерживает многоязыковый интерфейс и функции. А также проблемы связанные с локализацией (перевод на другой язык, формат дат и чисел, почтовые адреса, порядок имени и фамилии, валюты и т.д.). Орфография и грамматика обычно не тестируются. Локализация программного обеспечения - процесс адаптации к культурным особенностям той или иной страны: перевод документации, элементов пользовательского интерфейса, вспомогательных материалов с одного языка на другой.
Процесс локализации тестирования может включать в себя:
• Определение и изучение списка поддерживаемых языков
• Проверка правильности перевода согласно тематике данного сайта или программы
• Проверка правильности перевода элементов интерфейса пользователя
• Проверка правильности перевода системных сообщений и ошибок
• Проверка перевода раздела «Помощь» и сопроводительной документации
Тестирование производительности (performance testing) - это автоматизированное тестирование, имитирующее работу определенного количества бизнес пользователей на каком либо общем (разделяемом ими) ресурсе.
Оно в свою очередь делится:
· Нагрузочное тестирование (load testing)
· Стресс-тестирование (stress testing)
· тестирование стабильности (stability testing)
Нагрузочное тестирование (load testing)
Нагрузочное тестирование - эмуляция одновременной работы сотен и тысяч пользователей для анализа работы системы под нагрузкой.
Стрессовое тестирование (Stress Testing)
Стрессовое тестирование позволяет проверить насколько приложение и система в целом работоспособны в условиях стресса и также оценить способность системы к регенерации, т.е. к возвращению к нормальному состоянию после прекращения воздействия стресса. Стрессом в данном контексте может быть повышение интенсивности выполнения операций до очень высоких значений или аварийное изменение конфигурации сервера. Также одной из задач при стрессовом тестировании может быть оценка деградации производительности, таким образом цели стрессового тестирования могут пересекаться с целями тестирования производительности.
Тестирование стабильности или надежности (stability testing)
Задачей тестирования стабильности (надежности) является проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки. Времена выполнения операций могут играть в данном виде тестирования второстепенную роль. При этом на первое место выходит отсутствие утечек памяти, перезапусков серверов под нагрузкой и другие аспекты влияющие именно на стабильность работы.
Тестирование безопасности (security testing) - это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным.
Общая стратегия безопасности основывается на трех основных принципах:
· конфиденциальность
· целостность
· доступность
Конфиденциальность - это сокрытие определенных ресурсов или информации. Под конфиденциальностью можно понимать ограничение доступа к ресурсу некоторой категории пользователей, или другими словами, при каких условиях пользователь авторизован получить ........



Перейти к полному тексту работы


Скачать работу с онлайн повышением уникальности до 90% по antiplagiat.ru, etxt.ru или advego.ru


Смотреть похожие работы

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