лекции, страница 25

Ошибки в реализации могут привести нев начало этого перехода, в другое место. Однако, мы уже знаем, что последовательностьdt(si–1’, si), будучи применена в состоянии si–1, во-первых, проверит, что это действительнотакое состояние с помощью d, а во-вторых, приведет после этого в si уже провереннымспособом. Поэтому, попав в некоторое состояние s, для еще не проверенного перехода si –a->s’ выполним t(s, si–1) d t(si–1’, si) a d.Получаемая таким образом последовательность обеспечит проверку всех переходов.Построим такой тест для нашего примера спецификации.a/xa/xb/x0a/x1b/xb/y1b/yb/ya/ya/x0b/y2a/y2Имеем d = ab, s0’ = s2, s1’ = s0, s2’ = s1.

Если мы будем обходить состояния в порядке s0-s2s1, то переводящие последовательности пусты. Поэтому первый этап дает abababab, и в егоконце мы оказываемся в состоянии s2.Далее будем проверять переходы в следующем порядке: 1-a->1, 2-a->2, 0-a->0, 1-b->0, 0b->2, 2-b->1. В этом случае промежуточные переводящие последовательности пусты, заисключением двух последних случаев, поэтому на втором этапе получаем такую входнуюпоследовательность: abaab.abaab.abaab.abbab.babbab.babbab.Итоговый тест:abababab.abaab.abaab.abaab.abbab.babbab.babbab/xyyyxxxy.yyxxx.xyyyy.xxxxy.yyxxy.yxxyyy.xxyyxx.Результат, возвращаемый ошибочной реализацией: xxxxxxxx…, после этого тестированиеможно не продолжать.В этом примере многие ошибки могут быть найдены уже на первом этапе, поскольку вполученную на нем последовательность входят все переходы.

Однако, если бы вспецификации имелись переходы по другим символам, отличным от a и b, ошибки в нихобнаруживались бы только на втором этапе.Использование других автоматных моделейДругие автоматные модели — системы размеченных переходов, расширенные иливзаимодействующие автоматы — при их использовании для тестирования чаще всегоприводятся к конечным автоматам.После этого становится можно использовать большое количество методов тестирования,разработанных для конечных автоматов.Литература[1] M.

Broy, B. Jonsson, J.-P. Katoen, M. Leucker, A. Pretschner (eds.). Model Based Testing ofReactive Systems. LNCS 3472, Springer, 2005.[2] В. Б. Кудрявцев, С. В. Алешин, А. С. Подколзин. Введение в теорию автоматов.М.: Наука, 1985.[3] М. П. Василевский. О распознавании неисправностей автоматов. Кибернетика, 9(4):93108, 1973.[4] T. S. Chow. Testing Software Design Modeled by Finite-State Machines. IEEE Transactions onSoftware Engineering, 4(3):178-187, 1978.Тестирование на основе моделейВ. В.

КуляминЛекция 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.