Определение тестирования и его сравнение с другими методами контроля качества ПО. Новый всплеск интереса к формальным методам произошел в первой половине 90-х. Его вызвали первые результаты, полученные при использовании формальных моделей и формальных спецификаций в тестировании. В данном виде тестирования широко применяются инструменты записи-воспроизведения (record/playback); из наиболее известных продуктов можно назвать Rational Robot (компания IBM/Rational), WinRunner (Mercury Interactive), QARun (Compuware). Наряду с этим существуют инструменты для текстовых терминальных интерфейсов, например, QAHiperstation компании Compuware.
Для проведения нагрузочного тестирования предлагается использовать метод виртуального пользователя. Виртуальный пользователь — это тоже модель. Поскольку тестирующий сервер обрабатывает множество запросов от потоков работающей системы, целесообразно снабдить данный сервер системой распределения (балансировки) нагрузки. E — множество исключительных ситуаций или событий (по аналогии с Obs от Microsoft Research).
Унифицированный Язык Моделирования (uml)
Итак, различные работы в процессе производства программ должны быть хорошо интегрированы с работами по тестированию. Соответственно, инструменты тестирования должны быть хорошо интегрированы со многими другими инструментами разработки. Следующий шаг сделала компания IBM, начав интеграцию возможностей инструментов от Rational в среду разработки программ Eclipse.
Альтернатива «большому скачку» — интеграционное тестирование, когда система строится поэтапно, группы модулей добавляются постепенно. Иногда тестировщикам могут быть навязаны формальные модели, используемые для определения и построения системы, чтобы они могли использовать их для определения целевых показателей покрытия. В других случаях у тестировщиков может быть мало документации для работы, и им приходится изобретать собственные модели. Выбор любой тестовой модели и целевого показателя покрытия является в некоторой степени произвольным и субъективным. Следовательно, неформальные тестовые модели и меры покрытия могут быть столь же полезны, как и устоявшиеся формальные модели.
Это означает, что необходимы автоматизированные средства тестирования сложных взаимодействующих систем, причем на основе новых методологий. Для этих инструментов характерны высокая гибкость, возможность подключения совершенно независимых модулей для реализации дополнительных функций и возможность использования в рамках более сложных тестовых систем. Одним из инструментов модульного тестирования, обладающих наиболее богатой функциональностью, является TestNG [20,21].
Такую реализацию можно использовать для непосредственного тестирования. В некоторых средах для моделирования, модели могут содержать достаточное количество информации для генерации исполняемых тестов. При записи скрипта можно делать остановки для того, чтобы указывать, какие ответы системы в конкретной ситуации надо рассматривать как правильные, какие вариации входных данных пользователя возможны и т.д. При наличии таких вариаций при очередном воспроизведении теста инструмент самостоятельно будет выбирать одну из определенных альтернатив.
Модель — некоторое отражение структуры и поведения системы. Модель может описываться в терминах состояния системы, входных воздействий на нее, конечных состояний, потоков данных и потоков управления, возвращаемых системой результатов и т.д. Для отражения разных аспектов системы применяются и различные наборы терминов. Формальная спецификация представляет собой законченное описание модели системы и требований к ее поведению в терминах того или иного формального метода. Для описания характеристик системы можно воспользоваться несколькими моделями в рамках нескольких формализмов. Обычно, чем более общей является нотация моделирования, тем больше трудностей возникает при автоматизации тестирования программы на основе модели/спецификации, описанной в этой нотации.
Распространение компонентных технологий породило термин «компонентное тестирование» как частный случай интеграционного тестирования. Покрытие, которого мы планируем достичь, является естественным следующим шагом после определения сферы покрытия. Если заинтересованные стороны не понимают ваших моделей, они не будут понимать ваше тестирование, доверять ему или инвестировать в него. Таким образом, любая модель, представляющая собой ориентированный граф, может быть обработана таким же образом. Но будьте осторожны, иногда модели допускают небезопасные упущения – возможно, модель чрезмерно упрощает ситуацию, – и нам нужно обратить на это внимание.
Если мы планируем пользовательский тест, мы, вероятно, примем поток бизнес-процессов в качестве нашей модели и шаблона для отслеживания путей реализации системных функций, которые важны для пользователя. Если мы тестируем интеграцию сервисных компонентов от имени технического архитектора, мы будем использовать архитектурную модель, схемы совместной работы, спецификации интерфейса и так далее в качестве основы нашего тестирования. Если мы тестируем функции, определенные пользователями, мы будем использовать пользовательские истории, которые были результатом более ранней совместной работы над требованиями. Тестовая модель может представлять собой контрольный список или набор критериев. Это также может быть диаграмма, полученная из проектного документа или анализа текста.
Тестирование на основе моделей – это новый подход к тестированию программного обеспечения. Это легкий формальный метод для В чем заключается тестирование модели проверки системы. Такое тестирование может применяться и для проверки “железа”, и для проверки программного обеспечения.
Для каждого действия (например, начала работы, ввода стихотворения, сохранения) может быть сгенерирован тестовый пример и проверен результат. Это один из способов продемонстрировать, как соотносятся процессы тестирования с основными процессами проектирования и разработки. В V-модели основные этапы ЖЦ ПО образуют левую сторону “V”, кодирование находится в самой нижней точке диаграммы, а тестирование образует ее правую сторону. Для простоты изложения, вид деятельности, подобный сопровождению, на диаграмме не показан.
Если у нас нет представления о покрытии, мы, возможно, не сможем ответить на такие вопросы, как “что было протестировано?”, “что не было протестировано?”, “мы уже закончили?”, “сколько тестов осталось?” Это особенно неудобно для менеджера тестирования. Мы могли бы легко определить область нашего тестирования, например, как ERP-системы. Тесты, полученные на основе неформальной модели, так же действительны, как и тесты, полученные на основе формальной модели, если они расширяют наши знания о поведении или возможностях нашей системы.
Технология продается «в коробочном варианте», но о той части, которая проводит тестирование распределенных систем, на официальном сайте не указано (не указана и поддержка языка С# — лишь C и Java). И не понятно, реализованы ли эти идеи на практике. Главным аспектом, тормозящим развитие технологии, является сложность описания модели при помощи пред- и постусловий, особенно когда продукт представляет собой реальную систему для автоматизации какого-то процесса без строгих требований к ней. Для работы с системой UniTesK нужно высшее математическое образование. В статье предлагается использовать подход к тестированию программ на основе построения моделей [2]. Это достаточно новый подход, при котором строится математическая модель всей системы, и по ней проводится тестирование.
Как Начать Использовать Тестовые Модели
Таким образом, для всех участников проекта будет понятно, на основании чего написан данный тест-кейс. В идеале наша тестовая модель должна объективно определять элементы покрытия. Когда мы запланировали или выполнили тесты, охватывающие элементы, определенные нашей моделью, мы можем количественно оценить достигнутый покрытие и, как долю всех элементов в модели, выразить этот покрытие в процентах. Покрытие — это термин, который мы используем для описания тщательности или полноты нашего тестирования в отношении нашей тестовой модели.
Например, в инструменте управления дефектами дефекты поднимаются со статусом “Новый” (New). Как только дефект исправляется разработчиками, он должен быть переведен в статус “Исправлен” (Fixed). Если дефект не исправлен, статус меняется на “Переоткрыт” (Re-open). Диаграммы состояний должны быть разработаны таким образом, чтобы они вызывали событие для каждого состояния. Приведенная выше модель объясняет упрощенный подход к написанию стихов в блокноте и возможные действия, связанные с каждым шагом.
Технически это возможно реализовать при помощи средств в современных языках программирования — Reflection и сериали-зации. Reflection позволяет в процессе работы программы получить доступ ко всем ее объектам, а сериализация — сохранить какой-то объект в памяти или на диске и потом восстановить его. W — флаг ошибки, или ошибочного состояния.
Действие — это надпись на дуге перехода между двумя состояниями. Научная группа Института системного программирования РАН RedVerst (Research and development in Verification, Specification, and Testing) разработала технологию промышленного тестирования UniTesK, основанную на формальных спецификациях. Технология объединяет средства для тестирования C/C++, Java и C# приложений, а также специальные средства для тестирования компиляторов.
Поэтому обсуждение инструментов предваряет изложение общих положений «правильного» тестирования. Тестирование — это процесс проверки соответствия продукта предъявляемым к нему требованиям. Поэтому в части общего описания тест-кейса (в тест-трекинговых системах обычно употребляется термин «Summary») необходимо ссылаться на конкретное требование в связке с фрагментами текста требований.
- Мы будем писать интеграционные тесты, но перед этим давайте создадим фабрику.
- Разработка тестов (Test design) — это процесс, посредством которого мы выбираем из множества доступных вариантов те тесты, которые, по нашему мнению, будут наиболее ценными для нас и наших заинтересованных сторон.
- В настоящее время нередки случаи, когда приложения состоят из компонентов, реализованных на различных языках программирования и работающих на разных платформах.
- UML включает в себя набор графических нотаций для создания визуальных моделей, которые могут описывать очень сложное поведение системы.
- Широко распространены инструменты тестирования приложений с графическим пользовательским интерфейсом.
- Инструменты, поддерживающие тестирование на основе моделей, должны работать с какими-то представлениями моделей поведения и моделей ситуаций.
Накопленные вероятности переходов можно сравнивать с вероятностями, описанными при создании модели системы. Кроме того, можно использовать скорректированные в результате выполнения системы вероятности переходов в качестве базовых для проведения офлайн-симуляции работы и статистического вероятностного моделирования. В предыдущих разделах было описано, как получить модель тестируемой системы. Полученную статическую модель с переходами будем считать ориентированным графом системы, где состояния соответствуют вершинам, а переходы — дугам. Поскольку разработчики пишут код в своих привычных средах разработки, целесообразно разработать модули поддержки описания модели системы для популярных сред программирования (add-in для MS Visual Studio, plugin для Eclipse). 1 Под состоянием в данном случае понимается набор значений выбранных переменных системы, которые имеют наибольшее значение для логики работы программы.
1) Пытаются применить для автоматизации обхода очень простого набора состояний, для которого не составляет сложности написать кейсы вручную. Модель помогает определить объем тестирования, а также объяснить его заинтересованным сторонам в терминах, которые они понимают, ценят и (надеюсь) одобряют. Модель может показать, что входит в сферу тестирования, но, что не менее важно, и то, что выходит за рамки.
(Заметим, что это разные модели; первые часто называют архитектурными, а вторые — функциональными или поведенческими.) Они зачастую составляются на основе документов или обсуждений в неформальном виде. Стандартизованная схема жизненного цикла с четкой регламентацией необходимых работ и с перечнем соответствующей документации легла в основу так называемой «водопадной» или каскадной модели. Водопадная модель подразумевает жесткое разбиение процесса разработки программного обеспечения на этапы, причем переход с одного этапа на другой осуществляется только после того, как будут полностью завершены работы на предыдущем этапе. Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой. Водопадная модель стала доминирующей в стандартах процессов разработки Министерства обороны США.