Lecture08 (Лекции в ПДФ)

Тестирование на основе моделейВ. В. КуляминЛекция 8. Основы технологии разработки тестов UniTESKРазработка тестов и тестирование на основе моделей предполагают, что используемыемодели формулируются явно. Одной из технологий такого типа является разработанная вИнституте системного программирования РАН в 1995-2002 технология UniTESK.Назначение технологии UniTESK — разработка и развитие наборов тестов для сложныхразвивающихся систем.

Сложность системы означает достаточно большое количествофункций, сложный интерфейс (от нескольких десятков операций), достаточно большойразмер кода (от 5·104 строк). Развитие системы предполагает, что время от временипоявляются ее новые версии, и что набор тестов придется поддерживать в рабочемсостоянии и пополнять тестами новых функций в течение значительного периода времени(начиная от 2-х лет, для более чем 2-х версий).

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

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

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

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

Большинство таких языковявляются расширениями языков программирования, построенными по общимправилам.• Инструменты, автоматизирующие работу с моделями на определенных языках ипостроение тестов из них.Далее дается описание метода разработки тестов. Оно сопровождается примерамипостроения моделей и тестов на их основе, в основном на расширении языка Java.МетодИспользуемый метод построения тестов включает в себя следующие виды деятельности.1. Определение целей и рамок проекта.2. Определение и анализ требований к тестируемой системе.3.

Определение и анализ требований к полноте тестирования.4. Разработка и выполнение тестов.5. Анализ результатов тестирования.Эти виды деятельности обычно выполняются примерно в той последовательности, вкоторой перечислены выше. Однако при необходимости используется итеративнаяразработка — т.е. возможны (неоднократные) возвращения от следующих видовдеятельности к предыдущим для выполнения каких-то доработок или изменений. Крометого, после проведения декомпозиции системы на отдельные компоненты в рамках первойили второй деятельности, дальнейшая разработка тестов для каждого компонента можетидти независимо от остальных, поэтому разные действия для различных компонентов частовыполняются одновременно и параллельно.Далее каждый из видов деятельности рассматривается более подробно.Определение целей и рамок проектаВ ходе выполнения этого вида деятельности принимаются основные стратегическиерешения, касающиеся проекта.

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

Определение задач и рамок тестируемой системы.В рамках этой задачи нужно определить, что представляет собой тестируемаясистема (system under test, SUT), для чего она предназначена — какие основныезадачи решает. Также важно, из каких частей она состоит — что входит, а что невходит в нее, какие именно части нужно тестировать, можно ли их отделить отдругих частей/других систем при проведении тестирования, и как.2. Определение набора проверяемых функций и свойств.Нужно выяснить, полный список функций (функция, feature — это некотораяуслуга, предоставляемая системой), которые необходимо протестировать, а такжесписок других свойств, которые необходимо проверять.

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

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

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