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

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

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

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

Покрытие тестовой модели

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

Качество сценариев

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

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

Возможные уровни описания тест-кейсов:

На 4-м уровне согласование с заказчиком может быть заменено на согласование .

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

• Тест-кейсы необходимо писать по требованиям

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

• Используйте детальные предусловия

Как сэкономить время на выполнении тест-кейсов?

Установите правила форматирования для всех тест-кейсов. Так тест-кейс будет удобен для понимания и чтения для любого участника проекта. Например, на проекте можно ввести следующие правила:

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

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

Если написание тест-кейсов занимает продолжительное время, то может возникнуть ситуация, когда специалист перестает видеть свои ошибки. Для этого необходим взгляд со стороны – здесь поможет проведение кроссс-ревью . Этот этап рекомендуется проводить в тех случаях, когда разработка тестовой модели растянута в сроках и длительна по времени. Например, когда разработка тестовых сценариев занимает более 1 месяца.

Процесс контроля качества сценариев можно вести с помощью Test Model Control – специально заготовленного шаблона.

Актуализация тестовой модели

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

Для актуализации можно вести «Матрицу требований» (Requirement Traceability Matrix): после каждого изменения в определенном требовании из тест-трекинговой системы делается выборка всех связанных с этим требованием тестовых сценариев, и проводится их обновление.

Средства управления тестовой моделью:

• TestRail
• TestLink
• Jira+Zephyr
• Microsoft Test Manager (MTM)
• Excel

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

Д. Гантер, С. Барнет, Л. Гантер.
Интеграция Windows NT и Unix

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

Что и зачем тестируется

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

Итак, какие факторы учитываются в таких случаях, что является объектом исследований и какого рода испытания наиболее популярны?

Критерии тестирования обычно таковы:

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

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

Равна ли сотня кроликов одному тигру?

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

Типичный пример — сравнение старших моделей систем на процессорах Intel с младшими в линии RISC-платформ. Да, действительно, в заданном ценовом диапазоне машины с Intel-архитектурой сопоставимы или, в некоторых случаях, даже превосходят RISC-системы. Однако то, что является потолком для одних платформ, — лишь начальный уровень для других и т. д.

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

Одним словом — переосмысливайте результаты тестов в соответствии со своими нуждами.

Специфика тестирования серверов

Если компьютер не включается — он неисправен.
Если не выключается — он сервер.
Народная примета

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

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

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

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

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

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

Для начала немного теории. Гленфорд Майерс в своей работе "Надежность программного обеспечения" приводит несколько "аксиом тестирования". Попробуем, следуя им, рассмотреть, что и как надо тестировать.

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

Невозможно тестировать свою собственную программу

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

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

С таким явлением автор столкнулся, пытаясь настроить Netscape Enterprise Web Server под Solaris (SPARC). Производительность сервера по http-протоколу удалось поднять почти в 6 (!) раз (по данным тестирования с MS InetLoad), однако на комплексном тесте увеличение оказалось трехкратным, в то время как быстродействие POP3-сервера возросло вдвое, News-сервера — осталось неизменным, а SMTP показал в два раза худшие результаты, чем до внесения изменений.

Кроме того, производители, зная характеристики того или иного тестового набора, могут оптимизировать параметры системы именно под него. Пример тому — Web-страничка Netscape, где приведены рекомендации, как настроить Netscape Enterprise Server для проведения тестирования с помощью SPECweb96 .

Тестирование проводится для обнаружения ошибок

В случае серверов и серверного программного обеспечения это значит, что устройство следует заставить работать в максимально неблагоприятном режиме — провести тест на "живучесть". Этого можно достичь проведением тестирования сервера в следующей рабочей конфигурации:

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

Здесь уместны два примечания:

1. Модель поведения пользователя.

По отношению к пользователям администратор должен быть пессимистом. Соответственно должно строиться и тестирование "на выживание".

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

2. Сервис перестал справляться с обработкой запросов: возможные варианты.

По степени серьезности такие отказы можно разделить на 4 группы:

• снижение производительности — сервис не успевает провести обработку, но отвечает корректно (возвращает соответствующий код ошибки — "Too many connections" и т. п.);
• аварийное завершение работы сервиса, не влекущее за собой негативных последствий для системы: соответствующая программа завершила работу, выгружена из памяти, системные ресурсы освобождены;
• аварийное завершение работы сервиса, отрицательно влияющее на производительность системы. Программа либо "висит" в списке процессов, не высвобождая ресурсы, либо в процессе завершения захватывает дополнительные ресурсы;
• крах системы — в лучшем случае с последующей перезагрузкой, в худшем — с зависанием.

Готовьте тесты как для правильных, так и для неправильных входных данных

Эта аксиома детализирует предыдущую с точки зрения входных информационных потоков.

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

Совет, взятый из той же книги Г. Майерса: "старайтесь, чтобы система не рассердила пользователя, ибо это может привести к некоторым неожиданным ситуациям на входе — правило # 5 минимизации ошибок пользователя в диалоговых системах. Быть пессимистом — не значит быть мизантропом!".

А как насчет news-сервера — установлен ли там максимальный размер статьи?

Может ли кто-то, вознамерившись загрузить половину вашего FTP-сайта, открыть три десятка параллельных ftp-сессий, и если да, то как это повлияет на ваш канал и работу других желающих посетить FTP?

В качестве примера, подтверждающего корректность такого подхода, можно упомянуть инцидент с ракетным крейсером Yorktown, где ошибка ввода оператора повлекла за собой отказ системы управления двигателями . Или еще один, приведенный самим Майерсом: "Операторы Нью-Йоркской системы диспетчеризации полицейских машин SPRINT в свободное время развлекались тем, что пытались вывести ее из строя, вводя заведомо неправильные сообщения". Это происходило в начале 70-х. Может, с тех пор нравы и смягчились, но это маловероятно.

Избегайте невоспроизводимых тестов

В случае тестирования серверов и серверного ПО эта аксиома особенно актуальна. Во-первых, для их тестирования необходимо наличие аппаратно разделенных генераторов нагрузки (Client-Side Load Generators, CSLG) — обычно это группы рабочих станций, выполняющих клиентскую часть теста и обеспечивающих поток запросов на сервер. Во-вторых, на результаты может повлиять состояние сети, соединяющей сервер и CSLG. Кроме того, во многих случаях производительность зависит от предыстории обращений к серверу. Большинство серверных приложений использует кэширование. Скорость обращения к кэш-памяти значительно выше скорости обращения к дисковой подсистеме. Кэш приложения может наполняться вследствие предварительных или отладочных прогонов тест-программ — и соответственно могут меняться результаты. Более того, при комплексном тестировании возможно перекрестное влияние приложений — так, количество обработанных за единицу времени сложных запросов к POP3- или IMAP-серверам зависит от размера почтового спула, который может быть увеличен предыдущим проведением SMTP-теста. И наконец, на производительность влияют настройки операционной системы.

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

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

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

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

Почему тестирование необходимо?

В этом разделе мы рассмотрим самые базовые понятия и принципы, которые используются в процессе тестирования. Мы узнаем, что же, собственно, собой представляет тестирование, зачем оно нужно и кто им занимается. Рассмотрим цели, принципы и основные этапы тестирования. Почувствуем, каким должен быть психологический настрой настоящего тестировщика и развенчаем напоследок несколько мифов о тестировании. Уверены, Вам будет интересно.
Начнем с того, что же такое «тестирование». Для начала, давайте абстрагируемся от сухих академических определений и посмотрим на это понятие с точки зрения повседневного использования.
Когда мы что-то тестируем, то задаем себе простой вопрос: «работает ли это так, как мы ожидаем?» или, другими словами: соответствует ли реальное поведение объекта тестирования нашим ожиданиям? Если ответ положительный – замечательно, если нет, – мы обмануты в своих ожиданиях, а значит что-то нужно исправлять.
Тестирование необходимо потому, что все мы совершаем ошибки. Некоторые из них могут быть незначительными, в то время как другие – иметь самые разрушительные последствия. Все, что производится человеком, может содержать ошибки (так уж мы, люди, устроены). Именно поэтому любой продукт нуждается в проверке – тестировании, прежде чем его можно будет эффективно и безопасно использовать.
То же самое справедливо и для программного обеспечения (англ. Software).
Программное обеспечение (Software) – компьютерные программы, функции, а также сопровождающая их документация и данные, имеющие отношение к эксплуатации компьютерной системы.
Компьютерные технологии все глубже проникают в нашу повседневную жизнь. Программное обеспечение управляет работой множества окружающих нас вещей – от мобильных телефонов и компьютеров до стиральных машин и кредитных карт. В любом случае, все мы сталкивались с теми или иными ошибками в программах: текстовый редактор, намертво зависший при работе над дипломным проектом, банкомат, «съевший» карточку или просто сайт, который никак не загрузится – все это отнюдь не облегчает нам жизнь.
Однако не все ошибки одинаково опасны – для разных программных систем уровни риска могут отличаться.
Риск (risk):
– фактор, который может привести к негативным последствиям в будущем; как правило, выражается через вероятность наступления таких последствий и их влияние на систему.
– то, что еще не произошло, и может вообще не произойти; потенциальная проблема.
Кроме того, уровень риска будет зависеть от вероятности наступления негативных последствий.
К примеру, одна и та же незначительная ошибка, скажем опечатка, может иметь совершенно разные уровни риска для разных программ:
– опечатка в описании интересов на персональной страничке в социальной сети вряд ли будет иметь существенные последствия, разве что вызовет улыбку у Ваших друзей;
– такая же простая опечатка, допущенная в описании деятельности крупной компании, размещенном на ее сайте, уже опасна, так как косвенно свидетельствует о непрофессионализме ее сотрудников;
– опечатка в коде программы, которая подсчитывает уровни облучения при работе рентгеновского аппарата (например, 100 вместо 10) может иметь самые печальные последствия – вред, нанесенный здоровью и безопасности людей, выльется в потерю доверия к компании и судебные иски со многими нулями.

Аннотация: Основные понятия тестирования. Фазы и этапы тестирования. Типы тестов. Разработка, управляемая тестами (Test Driven Development)

Введение

Тестирование является одним из наиболее устоявшихся способов обеспечения качества разработки программного обеспечения.

С технической точки зрения тестирование заключается в выполнении приложения на некотором множестве исходных данных и сверке получаемых результатов с заранее известными (эталонными) с целью установить соответствие различных свойств и характеристик приложения заказанным свойствам. Как одна из основных фаз процесса разработки программного продукта ( Дизайн приложения - Разработка кода - Тестирование), тестирование характеризуется достаточно большим вкладом в суммарную трудоемкость разработки продукта. Широко известна оценка распределения трудоемкости между фазами создания программного продукта: 40%-20%-40%.

С точки зрения математики тестирование можно рассматривать как интерпретацию некоторой формулы и проверки ее истинности на некоторых множествах. Действительно, программу можно представить в виде формулы f = f1* f2* f3*... * fn , где f1 , f 2 , ... fn - операторы языка программирования, а их суперпозиция - программа .

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

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

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

Динамическое тестирование (собственно тестирование) осуществляет выявление ошибок только на выполняющейся программе с помощью специальных инструментов автоматизации тестирования - Testbed или Testbench.

Основы тестирования

Классы критериев тестирования

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

• Условие критерия тестирования команд (критерий С0) - набор тестов в совокупности должен обеспечить прохождение каждой команды не менее одного раза.
• Условие критерия тестирования ветвей (критерий С1) - набор тестов в совокупности должен обеспечить прохождение каждой ветви не менее одного раза.
• Условие критерия тестирования путей (критерий С2) - набор тестов в совокупности должен обеспечить прохождение каждого пути не менее 1 раз.

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

Выделяют следующие частные виды функциональных критериев :

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

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

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

Метод мутационного тестирования состоит в том, что в разрабатываемую программу P вносят мутации (мелкие ошибки), т.е. искусственно создают программы- мутанты P1, P2... . Затем программа P и ее мутанты тестируются на одном и том же наборе тестов (X, Y).

Если на наборе (X, Y) подтверждается правильность программы P и, кроме того, выявляются все внесенные в программы- мутанты ошибки, то набор тестов (X, Y) соответствует мутационному критерию, а тестируемая программа объявляется правильной. Если некоторые мутанты не выявили всех мутаций, то надо расширять набор тестов (X, Y) и продолжать тестирование.

Фазы тестирования

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

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

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

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

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

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

Этапы тестирования

Каждая фаза тестирования включает в себя следующие этапы:

1. Определение целей (требований к тестированию), включающее следующую конкретизацию: какие части системы будут тестироваться, какие аспекты их работы будут выбраны для проверки, каково желаемое качество и т. п.
2. Планирование : создание графика (расписания) разработки тестов для каждой тестируемой подсистемы; оценка необходимых человеческих, программных и аппаратных ресурсов; разработка расписания тестовых циклов . Важно отметить, что расписание тестирования обязательно должно быть согласовано с расписанием разработки создаваемой системы.
3. Разработка тестов (тестового кода для тестируемой системы).
4. Выполнение тестов : реализация тестовых циклов .
5. Анализ результатов .

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

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

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

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

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

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

Типы тестов

В тестовом плане определяются и документируются различные типы тестов .

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

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

Типы тестирования по способу выбора входных значений:

1. Функциональное тестирование, при котором проверяется:
   • покрытие функциональных требований;
   • покрытие сценариев использования.
2. Стрессовое тестирование, при котором проверяются экстремальные режимы использования продукта.
3. Тестирование граничных значений.
4. Тестирование производительности.
5. Тестирование на соответствие стандартам.
6. Тестирование совместимости с другими программно-аппаратными комплексами.
7. Тестирование работы с окружением.
8. Тестирование работы на конкретной платформе.

Test Driven Development

Рассмотрим подход к тестированию, несколько отличающийся от приведенного выше. Разработка через тестирование ( Test Driven Development - TDD) - процесс разработки программного обеспечения, который предусматривает написание и автоматизацию модульных тестов еще до момента написания соответствующих классов или модулей. Это гарантирует, что все обязанности любого элемента программного обеспечения определяются еще до того, как они будут закодированы.

TDD задает следующий порядок этапов программирования:

• Красный - напишите небольшой тест, который не работает, а возможно, даже не компилируется.
• Зеленый - заставьте тест работать как можно быстрее, при этом не думайте о правильности дизайна и чистоте кода. Напишите ровно столько кода, чтобы тест сработал.
• Рефакторинг - удалите из написанного вами кода любое дублирование.
• Освоив TDD, разработчики обнаруживают, что они пишут значительно больше тестов, чем раньше, и двигаются вперед маленькими шагами, которые раньше могли показаться бессмысленными.

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

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

Итоги

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

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

Кроме того, продолжаются исследования в области тестов, ориентированных на конкретную модель разработки (водопадную, спиральную) или на конкретную парадигму программирования. Например, для тестирования компонентно-ориентированных систем предлагается тестирование при помощи агентов. Для тестирования активных Java-апплетов предлагают использовать нейросети. Для тестирования агентов, существующих в web (роботы, пауки), предлагают использовать системы, основанные на знаниях.

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

План курса:

Аудит - Что проверяли

Тестовая модель

Покрытие проверками

Equivalence Partitioning

1) Разбить на классы входные параметры

2) 1 класс == 1 проверка

2) 1 класс == 1 проверка

3) Негативная проверка только для 1го класса в кейсе

4) Пересмотреть позитивные проверки

5) Итого

Еще классы …

~30% позитивных кейсов

Boundary values

Задача: Создать тест-кейсы для Evacuation Plan

Задача: Создать тест-кейсы для Evacuation Plan

Pairwise Testing

Задача

Идеи

105*16*2*4*5*2 = 134 400