Материал: ВВПИ. Лекции

Наконец, кроме ограничения количества тестов их отбора важным является их прогон на некоторых (не на всех возможных!) входных данных. Часто здесь применяют принцип факторизации – множество всех возможных входных значений разбивают на значимые с точки зрения тестирования классы и «прогоняют» тесты не на всех возможных входных значениях, а берут по одному набору значений из каждого класса. Например, тестируют некоторую функцию системы на ее граничные значения – очень большие значения параметров, очень маленькие и пр. Часто факторизацию удобно делать, исходя из требований к данной функции, также бывает полезно посмотреть на ее реализацию и «пройтись» тестами по разным ее логическим веткам (порождаемым, например, условными операторами).

Виды тестирования. Не претендуя на полноту, выделим следующие виды тестирования.

•Модульное тестирование - тестируется отдельный модуль, в отрыве от остальной системы. Самый распространенный случай применения – тестирования модуля самим разработчиком, проверка того, что отдельные модули, классы, методы делают действительно то, что от них ожидается. Различные среды разработки широко поддерживают средства модульного тестирования – например, популярная свободно распространяемая библиотека для Visual Studio NUnit, JUnit для Java и т.д. Созданные разработчиком модульные тесты часто включаются в пакет регрессионных тестов и таким образом, могут запускаться многократно.

•Интеграционное тестирование – две и более компонент тестируются на совместимость. Это очень важный вид тестирования, поскольку разные компоненты могут создаваться разными людьми, в разное время, на разных технологиях. Этот вид тестирования, безусловно, должен применяться самим программистами, чтобы, как минимум, удостовериться, что все живет вместе в первом приближении. Далее тонкости интеграции могут исследовать тестеровщики. Необходимо отметить, что такого рода ошибки – «ошибки на стыках» - непросто обнаруживать и устранять. Во время разработки все компоненты все вместе не готовы, интеграция откладывается, а в конце обнаруживаются трудные ошибки (в том смысле, что их устранение требует существенной работы). Здесь выходом является ранняя интеграция системы и в дальнейшем использование практики постоянной интеграции.

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

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

•Нагрузочное тестирование – тестирование системы на корректную работу

сбольшими объемами данных. Например, проверка баз данных на корректную обработку большого (предельного) объема записей, исследование поведение серверного ПО при большом количестве

46

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

•Стрессовое тестирование – тестирование системы на устойчивость к непредвиденным ситуациям. Этот вид тестирования нужен далеко не для каждой системы, так как подразумевает высокую планку качества.

•Приемочное тестирование – тестирование, выполняемое при приемке системы заказчиков. Более того, различные стандарты часто включают в себя наборы приемочных тестов. Например, существует большой пакет тестов, поддерживаемых компанией Sun Microsystems, которые обязательны для прогона для всех новых реализаций Java-машины. Считается, что только после того, как все эти тесты успешно проходят, новая реализация вправе называться Java.

Работа с ошибками

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

средства контроля ошибок (bug tracking systems).

Менеджеры

Рис. 6.2.

Как правило, описание ошибки в системе контроля ошибок имеет следующие основные атрибуты:

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

ответственного за ее исправление – разработчика, которому ошибка отправляется на исправление;

состояние, например, ошибка найдена, ошибка исправлена, ошибка закрыта, ошибка вновь проявилась и т.д.

47

Этот список существенно дополняется в различных программных средствах контроля ошибок, но это основные атрибуты.

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

базу данных для хранения ошибок;

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

сетевой доступ, так как проекты все чаще оказываются распределенными;

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

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

Литература

1.Кулямин В.В. Технология программирования. Компонентный подход. М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2007. 463 с.

2.I.Sommerville Software Engineering. 6th edition. Addison-Wesley, 2001. 693 p. /

Русский перевод: И.Соммервилл. Инженерия программного обеспечения. Издательский дом “Вильямс”, 2002. 623 c.

48

Лекция 8. Диаграммные техники в работе со знаниями

Метод случаи использования

Описание примера. В качестве примера рассмотрим «Телефонную службу приема заявок». Заказчиком данной системы является компания, владеющая сетью продуктовых магазинов. Эта компания, кроме обычной розничной торговли и оптовых поставок продуктов отдельным столовым и ресторанам, хочет предоставлять еще и сервис по обслуживанию клиентов по телефонным заявкам. Клиент регистрируется в компании, а потом по телефону, в удобное для себя время, делает заказ товаров, которые к нему привозят домой, и он расплачивается. Для этого компания хочет организовать у себя локальный телефонный центр, состоящий из офисной многоканальной АТС, штата операторов и соответствующего программного обеспечения. При этом в компании уже есть информационная система по обработке заявок от постоянных мелкооптовых клиентов, и заказываемая система должна быть с ней проинтегрирована.

Работа с требованиями. Случаи или варианты использования (use cases) были предложены в конце 90-х годов Айвером Якобсоном, одним из главных авторов языка UML, как диаграммный подход для извлечения и первичной формализации требований к системам. Выше уже говорилось о сложности по формированию единой и связной картины требований к ПО. Необходимо извлечь требования из всех возможных источников, формализовать в некотором виде и обсудить. Этот процесс – извлечение, формализация, обсуждение – итеративен, то есть все делается не за один присест. Более того, сам способ формализации должен быть удобен для обсуждения, и в первую очередь, с потенциальными пользователями системы, которые могут быть совершенно не IT не компетентны. Их комментарии, одобрения и несогласия часто являются основой итеративного извлечения требований к системе. Кроме того, этот способ работы с информацией должен вести к созданию моделей, удобных в дальнейшей реализации системы. Другими словами, ясно формулировать исходные задачи для разработки. То есть способ формализации должен быть прост, понятен и обладать достаточной строгостью. Этим требованиям удовлетворяют диаграммы случаев использования, являющиеся на сегодняшний день составной частью стандарта UML.

Пример диаграммы случаев использования представлен на рис. 7.1.

49