Курсовая работа
Автоматизация
тестирования программных систем средствами Java
технологий
Содержание
Введение
. История развития и виды тестирования программного обеспечения
.1 История развития тестирования программного обеспечения
.2 Виды тестирования
.2.1 Инсталляционное тестирование (installation testing)
.2.2 Регрессионное тестирование (regression testing)
.2.3 Тестирование новой функциональности (new feature testing)
.2.4 Конфигурационное тестирование (configuration testing)
.2.5 Тестирование совместимости (compatibility testing)
.2.6 Тестирование удобства эксплуатации (usability testing)
.2.7 Интеграционное тестирование (integration testing)
.2.8 Тестирование безопасности (security testing)
.2.9 Тестирование интернационализации (internationalisation testing)
.2.10 Локализационное тестирование (localisation testing)
.2.11 Тестирование прототипа (prototype testing)
.2.12 Тестирование производительности (performance testing), Нагрузочное тестирование (load testing), Стрессовое тестирование (stress testing)
.2.13 Модульное (компонентное) тестирование (Unit testing)
. JUnit (Модульное тестирование)
.1 Описание
.2 Аннотация @Test
.3 Наиболее часто используемые методы
.4 Фикстуры
.5 Тестирование исключительных ситуаций
.6 Ограничение по времени
.7 Игнорирование тестов
. Примеры
Заключение
Список использованных источников
Введение
В настоящее время необходимость систематизированного тестирования в промышленной разработке программного обеспечения (ПО) общепризнанна и неоспорима. Тестирование является составляющей частью процесса отладки ПО, после выявления ошибок дефекты в программном коде должны быть устранены разработчиками. От тестовой части требуется во-первых, выявлять значительное количество дефектов программы, на как можно более ранних стадиях, во-вторых, фаза внедрения программного продукта на каждой итерации требует от тестовой подсистемы выявить такое количество ошибок, чтобы продукт мог поступить к конечному пользователю. Все это все более и более повышает требования к качеству тестов.
Традиционные методы разработки тестов вручную уже не могут обеспечить качественное тестирование современных программных систем. Появляется все большее число методик автоматизации и инструментальных средств, направленных на повышение качества и сокращение затрат ресурсов на тестирование ПО. Недостаточно хорошо проведенное тестирование может нанести серьезный урон проекту в целом. Устранение ошибки на стадии сопровождения готового ПО обходится в среднем в 200 раз дороже, чем на стадии определения требований, а в результате позднего выявления ошибок общий бюджет проекта возрастает на 30-40%.
На данный момент существует довольно много видов тестирования. Основные из них будут рассмотрены в данной работе.
Объект исследования. Объектом исследования является модульное (Unit) тестирование на языке программирования Java с использованием библиотеки JUnit.
Целью настоящей работы является сокращение трудоемкости модульного тестирования разрабатываемого приложения.
Задачей работы является описание создания тестовых классов на языке программирования Java.
программного обеспечения трудоемкость модульный
1. История развития и виды тестирования программного обеспечения
.1 История развития
тестирования программного обеспечения
Первые программные системы разрабатывались в рамках программ научных исследований или программ для нужд министерств обороны. Тестирование таких продуктов проводилось строго формализовано с записью всех тестовых процедур, тестовых данных, полученных результатов. Тестирование выделялось в отдельный процесс, который начинался после завершения кодирования, но при этом, как правило, выполнялось тем же персоналом.
В 1960-х много внимания уделялось «исчерпывающему» тестированию, которое должно проводиться с использованием всех путей в коде или всех возможных входных данных. Было отмечено, что в этих условиях полное тестирование ПО невозможно, потому что, во-первых, количество возможных входных данных очень велико, во-вторых, существует множество путей, в-третьих, сложно найти проблемы в архитектуре и спецификациях. По этим причинам «исчерпывающее» тестирование было отклонено и признано теоретически невозможным.
В начале 1970-х тестирование ПО обозначалось как «процесс, направленный на демонстрацию корректности продукта» или как «деятельность по подтверждению правильности работы ПО». В зарождавшейся программной инженерии верификация ПО значилась как «доказательство правильности». Хотя концепция была теоретически перспективной, на практике она требовала много времени и была недостаточно всеобъемлющей. Было решено, что доказательство правильности - неэффективный метод тестирования ПО. Однако, в некоторых случаях демонстрация правильной работы используется и в наши дни, например, приемо-сдаточные испытания. Во второй половине 1970-х тестирование представлялось как выполнение программы с намерением найти ошибки, а не доказать, что она работает. Успешный тест - это тест, который обнаруживает ранее неизвестные проблемы. Данный подход прямо противоположен предыдущему. Указанные два определения представляют собой «парадокс тестирования», в основе которого лежат два противоположных утверждения: с одной стороны, тестирование позволяет убедиться, что продукт работает хорошо, а с другой - выявляет ошибки в ПО, показывая, что продукт не работает. Вторая цель тестирования является более продуктивной с точки зрения улучшения качества, так как не позволяет игнорировать недостатки ПО.
В 1980-х тестирование расширилось таким понятием, как предупреждение дефектов. Проектирование тестов - наиболее эффективный из известных методов предупреждения ошибок. В это же время стали высказываться мысли, что необходима методология тестирования, в частности, что тестирование должно включать проверки на всем протяжении цикла разработки, и это должен быть управляемый процесс. В ходе тестирования надо проверить не только собранную программу, но и требования, код, архитектуру, сами тесты. «Традиционное» тестирование, существовавшее до начала 1980-х, относилось только к скомпилированной, готовой системе (сейчас это обычно называется системное тестирование), но в дальнейшем тестировщики стали вовлекаться во все аспекты жизненного цикла разработки. Это позволяло раньше находить проблемы в требованиях и архитектуре и тем самым сокращать сроки и бюджет разработки. В середине 1980-х появились первые инструменты для автоматизированного тестирования. Предполагалось, что компьютер сможет выполнить больше тестов, чем человек, и сделает это более надежно. Поначалу эти инструменты были крайне простыми и не имели возможности написания сценариев на скриптовых языках.
В начале 1990-х в понятие «тестирование» стали включать планирование, проектирование, создание, поддержку и выполнение тестов и тестовых окружений, и это означало переход от тестирования к обеспечению качества, охватывающего весь цикл разработки ПО. В это время начинают появляться различные программные инструменты для поддержки процесса тестирования: более продвинутые среды для автоматизации с возможностью создания скриптов и генерации отчетов, системы управления тестами, ПО для проведения нагрузочного тестирования. В середине 1990-х с развитием интернета и разработкой большого количества веб-приложений особую популярность стало получать «гибкое тестирование» (по аналогии с гибкими методологиями программирования).
В 2000-х появилось еще более широкое определение тестирования, когда в него было добавлено понятие «оптимизация бизнес-технологий» (en:business technology optimization, BTO). BTO направляет развитие информационных технологий в соответствии с целями бизнеса. Основной подход заключается в оценке и максимизации значимости всех этапов жизненного цикла разработки ПО для достижения необходимого уровня качества, производительности, доступности.
.2 Виды тестирования
.2.1 Инсталляционное тестирование (installation testing)
В процессе инсталляционного тестирования проверяется корректность установки и удаления программного продукта в среде, максимально приближенной к эксплутационной. Об этом аспекте корректной работы программного обеспечения очень часто просто забывают (и напрасно). Правильно выполненная установка программы - необходимое условие её корректной дальнейшей работы. Проверка правильности установки должна быть обязательным элементом проекта по тестированию любого продукта. Если программу невозможно корректно установить, и при этом что-то не будет работать или будет работать неправильно, работа по тестированию самого программного тестирования бессмысленна. Почему? Потому что заказчику не нужен продукт, который даже невозможно установить. Если пользователь уже на этапе установки сталкивается с проблемами в разработанном программном продукте, что он подумает о самом программном продукте? Будет ли он связываться с такой фирмой-разработчиком?
.2.2 Регрессионное тестирование (regression testing)
Повторное выполнение тестов для
проверки того, что изменения, внесённые в программу в результате разработки
новой или изменения существующей функциональности, устранения ошибок, не
повлияли на функциональность, которая не изменялась (т.е. текущая версия ведёт
себя идентично предыдущей, за исключением измененных областей).
1.2.3 Тестирование новой функциональности (new feature testing)
В данном виде тестирования
акцент делается на тестировании новой функциональности, появившейся в
конкретном выпуске (build) программного продукта.
1.2.4 Конфигурационное тестирование (configuration testing)
С помощью конфигурационных
тестов проверяется совместимость продукта с различным программным (software) и
аппаратным (hardware) обеспечением. Как правило, программный продукт делается с
тем расчётом, чтобы он сразу работал в максимально разнообразной внешней среде.
Если же речь идёт о «коробочном продукте», то фактор совместимости приобретает
ещё более важное значение. Для того, чтобы выяснить реакцию продукта на
окружение и соседство с другим программным обеспечением, и проводят данные тесты.
1.2.5 Тестирование совместимости (compatibility testing)
Тестирование совместимости
помогает убедиться в функциональных возможностях и надёжности работы продукта в
поддерживаемых браузерах (если речь идет о Web-приложениях) и операционных
системах. Также может проверяться работоспособность продукта при использовании
различных аппаратных платформ.
1.2.6 Тестирование удобства эксплуатации (usability testing)
Тестирование интерфейса человек/машина производится в отношении таких моментов как внешний вид пользовательского интерфейса, удобство навигации (преимущественно для Web-сайтов). Практичность и удобство использования - очень важные характеристики программного продукта. Например, программа может вполне соответствовать всем предъявляемым к ней требованиям с точки зрения функциональности. Но функции реализованы неудобно: некоторые шаги приходится повторять много раз, тогда как по логике достаточно выполнить однажды; расположение элементов интерфейса нелогично, программа быстро вызывает утомление и т.д. Для выявления такого рода недочётов и применяют тесты на удобство использования. Часто эта группа тестов относится к категории некритичных, но когда речь идёт, например, о рыночном готовом продукте, пренебрегать удобством эксплуатации весьма опасно.
.2.7 Интеграционное тестирование (integration testing)
Такой вид тестирования может
представлять два направления деятельности: 1. Проверку того, как
отдельные модули приложения взаимодействуют между собой. 2. Проверку
того, как приложение взаимодействует с каким-то внешним приложением или
компонентом системы.
1.2.8 Тестирование безопасности (security testing)
Тестирование безопасности представляет собой ряд работ: от разработки политики безопасности до тестирования безопасности на уровне приложения, операционной системы и сетевой безопасности. Тестирование безопасности может иметь различную степень покрытия:
первичное тестирование безопасности;
полное тестирование приложения;
полное тестирование приложения и сервера.
Для тестирования безопасности на начальном уровне применяются специальные утилиты, способные проверить приложение или систему на наличие элементарных уязвимостей (список которых, однако, может включать тысячи и десятки тысяч пунктов).
На более глубоком уровне тестированием безопасности занимаются эксперты, т.к. данный вид тестирования требует глубочайших знаний особенностей технологий, с использованием которых разработано приложение.
.2.9 Тестирование интернационализации (internationalisation testing)
1.2.10 Локализационное тестирование (localisation testing)
Проверяет, насколько корректно продукт адаптирован к работе на том или ином языке: всё ли переведено и переведено правильно, не нарушилась ли логика построения интерфейса и обработки данных и т.д. Для локализационного тестирования рекомендуется обязательно приглашать в команду носителя того языка, перевод на который тестируется. В противном случае мы рискуем увидеть нечто подобное:
Пункт меню: «Сделать под себя» («Customise»)
Огромная красная кнопка «ВСЁ!» («Finish»)
Пункт меню «Ясные печенья» («Clear cookies»)
.2.11 Тестирование прототипа (prototype testing)
Это метод выявления структурных, логических ошибок и ошибок проектирования на ранней стадии развития продукта до начала фактической разработки. Основная цель тестирования прототипа - выявить потенциальные проблемы в приложении, проверить, насколько приложение соответствует потребностям и ожиданиям пользователя и обнаружить расхождения с требованиями к графическому интерфейсу пользователя.
Тестирование прототипа охватывает следующие аспекты:
Структура приложения;
Формы;
Прототип бизнес-логики;
Логические связи между модулями;
Навигация;
Графический интерфейс пользователя.
Под тестированием прототипа
также может пониматься исследование готового (старого или аналогичного)
продукта, новую (или альтернативную) версию которого планируется разработать.
Такое тестирование позволяет быстро сформировать перечень основных требований к
продукту.
1.2.12 Тестирование производительности (performance testing), Нагрузочное тестирование (load testing), Стрессовое тестирование (stress testing)
Эти три вида тестирования тесно связаны между собой и перетекают в некоторых случаях друг в друга. Тестирование производительности проверяет способность программы выполнять заданное количество операций в заданный промежуток времени. Нагрузочное тестирование проверяет способность приложения работать при запланированной нагрузке. Стрессовое тестирование проверяет поведение приложения в условиях, выходящих за рамки оговоренных для эксплуатации приложения.
.2.13 Модульное (компонентное) тестирование (Unit testing)
С термином Unit testing связана некоторая путаница. Во-первых, на русский его переводят и как «модульное тестирование», и как «компонентное тестирование». Во-вторых, под этим термином кроется два достаточно различных вида деятельности:
1. Если мы говорим и «компонентном тестировании» (здесь уместнее этот перевод) в общем смысле (в контексте «тестирования вообще»), мы имеем в виду тестирование отдельных частей приложения. Причём эти части могут быть достаточно крупными.
2. Если мы говорим о «модульном тестировании» (здесь уже лучше использовать такой перевод) в контексте автоматизации тестирования, мы имеем в виду тестирование отдельных участков кода, классов, методов.
Как и любая технология
тестирования, модульное тестирование не позволяет отловить все ошибки
программы. В самом деле, это следует из практической невозможности трассировки
всех возможных путей выполнения программы, за исключением простейших случаев.
Кроме того, происходит тестирование каждого из модулей по отдельности. Это
означает, что ошибки интеграции, системного уровня, функций, исполняемых в
нескольких модулях, не будут определены. Таким образом, модульное тестирование
более эффективно при использовании в сочетании с другими методиками
тестирования.