Лекции. Тестирование ПО (all in one) (1186159), страница 17
Текст из файла (страница 17)
Поэтому в аналогичных ситуациях нужно использовать «длинные»дизъюнкты, которые эквивалентны просто всем комбинациям элементарных условий.Те же соображения помогают определить аналогичные метрики покрытия требований втех случаях, когда требования описываются на любом формализованном языке.В целом критерии покрытия на основе требований обладают важным преимуществом ужепотому, что они позволяют учитывать требования при оценке полноты тестирования, так чтонепроверенное требование автоматически означает не вполне полное тестирование. Однако,в отличие от структурных метрик, для организации измерения покрытия по требованиямнужны серьезные дополнительные усилия, например, указание у каждого теста, какиетребования он проверяет.
Кроме того, проверка некоторого требования в определеннойситуации еще не означает, что то же требование будет выполнено в другой, если в этихситуациях работают различные наборы компонентов и элементов кода тестируемой системы.Структурные критерии и критерии полноты на основе требований, также иногданазываемые функциональными, удачно дополняют друг друга — структурные позволяютотслеживать полноту тестов по отношению к коду, а функциональные — по отношению ктребованиям.
Если же в двух ситуациях задействуется один и тот же код и проверяются однии те же требования, достаточно трудно сделать так, чтобы в них система работала поразному, т.е. в одном случае правильно, а в другом ошибочно. Поэтому на практике дляоценки полноты тестирования хорошо использовать комбинацию из структурных ифункциональных критериев покрытия.Критерии полноты на основе предположений об ошибках.Поскольку общие предположения вида «если что-то выполняется или проверяется исодержит ошибку, то мы ее обнаружим» неверны, некоторые специалисты по тестированиюпредлагают использовать явное указание ошибок, на обнаружение которых нацелен набортестов, в качестве критерия его полноты.К сожалению, описать все возможные ошибки крайне тяжело, а если указать тольконекоторые, возникает законное подозрение, что эти-то ошибки тесты находят, а вот какие-тодругие — нет.
Если наша программа действительно застрахована от ошибок других типов,все в порядке, но в большинстве случаев это не так.Наиболее удобный на практике способ измерения полноты тестирования на основе явныхгипотез о возможных ошибках — это метод определения полноты тестов на основеобнаруженных мутантов.В рамках этого метода для языка программирования, на котором написана тестируемаяпрограмма, определяется достаточно полный набор операторов мутации.
Каждый такойоператор изменяет текст программ, например, удаляя определенную инструкцию, вставляяновую инструкцию, заменяя переменные в выражениях на другие переменные того же типаили на константные выражения того же типа, заменяя операторы арифметических действий+, –, *, / друг на друга, заменяя операторы логических операций друг на друга и пр. Важно,что после применения любого из операторов мутации синтаксически и семантическикорректная программа остается корректной.Программа, получаемая из тестируемой применением одного оператора мутации,называется мутантом.
При применении большего числа операторов получаются мутантывторого и более высоких порядков, но они обычно не используются, потому что ихколичество даже для небольшой программы очень велико.Те мутанты, которые эквивалентны по поведению исходной программе, т.е. ведут себяточно так же во всех ситуациях, выбрасывают из полученного множества мутантов. Послеэтого используется метрика полноты тестов, определяемая как доля обнаруживаемыхтестами мутантов среди оставшихся.На практике наборы мутантов обычно получаются достаточно большими, и приходитсязатрачивать значительные усилия, чтобы отсеять из них эквивалентные исходной программе,поскольку обнаружение эквивалентности нельзя автоматизировать полностью.
В результатеметрика полноты на основе доли обнаруженных мутантов достаточно сильна, но ееприменение очень трудоемко.Еще одним аргументом против использования мутантов служит то, что они помогаютобнаруживать только небольшие и случайные ошибки-опечатки. Серьезная ошибка впонимании требований чаще всего приводит не к изменению одного знака или пропускуодной инструкции, а к потере целой группы инструкций, которые должны были срабатыватьв определенных условиях, вместе с условиями их выполнения. Обнаружить такую ошибку спомощью мутаций очень нелегко.Критерии полноты на основе произвольных моделейРазличные другие модели поведения или устройства тестируемой системы, так же, как иописания требований к ней или графовые схемы передачи управления, могут служить дляопределения критериев покрытия.
Для этого достаточно, чтобы в модели были некоторыеэлементы, которые задействуются в различных ситуациях.Критерии полноты на базе моделей могут в ряде случаев уточнять и детализироватькритерии полноты, полученные непосредственно из требований. На практике вседополнительные модели обычно являются уточненными требованиями к тестируемойсистеме, поэтому у определенных с их помощью критериев те же достоинства и недостатки,которые выше были указаны для критериев, основанных на требованиях.Алгебраические моделиОдин из экзотических примеров такого рода — алгебраические описания программныхсистем.
Абстрактный тип данных, класс или компонент может быть описан алгебраическикак система с операциями, удовлетворяющими определенным соотношениям на ихрезультаты.Например, тип списка элементов типа T с операциями получения числа элементов,добавления элемента в заданное место списка, удаления элемента из заданного места иполучения элемента, находящегося в определенном месте, описывается так.[].size() = 0[X.size()] ≡ [X](i <= X.size()) => X.add(i, o).size() = X.size()+1(i < X.size()) => X.remove(i).size() = X.size()–1(i < X.size()) => [X.get(i)] ≡ [X](i, j <= X.size() & i < j) => [X.add(i, o1).add(j, o2)] ≡ [X.add(j–1, o2).add(i, o1)](i <= X.size()) => [X.add(i, o1).add(i, o2)] ≡ [X.add(i, o2).add(i+1, o1)](i <= X.size()) => [X.add(i, o).remove(i)] ≡ [X](i, j <= X.size() & i < j) => [X.add(i, o).remove(j)] ≡ [X.remove(j–1).add(i, o)](i, j <= X.size() & i > j) => [X.add(i, o).remove(j)] ≡ [X.remove(j).add(i, o)](i <= X.size()) => X.add(i, o).get(i) = o(i, j <= X.size() & i < j) => X.add(i, o).get(j) = X.get(j-1)(i, j <= X.size() & i > j) => X.add(i, o).get(j) = X.get(j)(i, j < X.size()-1 & i < j) => [X.remove(i).remove(j)] ≡ [X.remove(j+1).remove(i)](i, j < X.size() & i <= j) => X.remove(i).get(j) = X.get(j+1)(i, j < X.size() & i > j) => X.remove(i).get(j) = X.get(j)Терм в данной системе — любая конечная цепочка операций, примененная к [].
Вприведенных аксиомах X можно заменять на произвольный терм. Терм считаетсяправильным, если выполнено следующее.•Операция add(i, o) применяется в нем только к подтермам X, про которые можнодоказать, что i <= X.size().•Операции remove(i) и get(i) применяются в нем только к подтермам X, про которыеможно доказать, что i < X.size().В аксиомах [X] ≡ [Y] означает эквивалентность термов X и Y, так что в любомвысказывании X можно заменять на Y и обратно без изменений в истинности этоговысказывания.
Из этих аксиом можно доказать, что любой список, т.е. правильный терм,эквивалентен терму, получаемому конечной цепочкой операций add(), в которыхиспользуются значения первого параметра, на единицу меньшие номера вызова операции вцепочке, — это канонический вид списка. Длиной терма назовем количество операций,участвующих в нем.Тестами можно считать произвольные термы.Метрикой покрытия аксиом можно считать долю тех аксиом, которые используются приприведении заданного набора тестов к каноническому виду, среди всех выписанных аксиом.Метрикой покрытия термов длины <=k можно считать долю термов длины <=k,используемых в тестах или появляющихся в процессе их приведения к каноническому виду,среди всех термов длины <=k.К сожалению, для алгебраических моделей трудно обосновать выбор k такого, что стоитпытаться добиться полного покрытия всех термов длины <=k, но не стоит пытаться покрытьвсе термы длины <=(k+1).Автоматные моделиГораздо более широко используют описания поведения программных систем в видеконечныхавтоматовилиихрасширений—расширенных,бесконечных,взаимодействующих, иерархических автоматов, систем переходов и т.д.У всех видов автоматов имеются состояния и переходы.
Соответственно, для всех видовавтоматов можно определить следующие метрики покрытия.Метрика покрытия состояний — доля тех состояний, в которых система побывала вовремя тестирования, по отношению к количеству всех достижимых состояний.Метрика покрытия переходов — доля переходов, выполненных во время тестирования,по отношению к числу всех достижимых переходов.Метрика покрытия цепочек переходов длины k — доля выполненных при тестированиицепочек последовательных переходов дины k по отношению к общему количествудостижимых цепочек последовательных переходов длины k.Например, для конечного автомата, изображенного ниже, достаточно выполнить цепочкувходов abb, чтобы побывать во всех состояниях. Покрытие переходов при этом будет равнотолько 3/8 = 37.5%.a/y0b/xa/x1b/zb/ya/z23b/xa/yЧтобы покрыть все переходы, можно выполнить цепочку bbabbaaa. Покрытие парпоследовательных переходов при этом равно 7/16 = 43.75%.Покрытые пары последовательных переходов: 0-aa, 0-ab, 0-ba, 0-bb, 1-aa, 1-ab, 1-ba, 1-bb,2-aa, 2-ab, 2-ba, 2-bb, 3-aa, 3-ab, 3-ba, 3-bb.В описании расширенных автоматов участвуют предикаты-охранные условия переходов.Поэтому при определении метрик покрытия для расширенных автоматов можноиспользовать те же подходы, что и для определения метрик покрытия условий, ихкомбинаций и MC/DC.Литература[1][2][3][4][5]IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004.H.
Zhu, P. A. V. Hall, J. H. R. May. Software Unit Test Coverage and Adequacy. ACMComputing Surveys, 29(4):366-427, Dec. 1997.B. Beizer. Software Testing Techniques. International Thomson Press, 1990.S. Rapps, E. J. Weyuker. Selecting Software Test Data Using Data Flow Information. IEEETransactions on Software Engineering 11:367–375, 1985.P. G. Frankl, E. J. Weyuker. An Applicable Family of Data Flow Testing Criteria. IEEETransactions on Software Engineering 14:1483–1498, 1988.Тестирование на основе моделейВ. В. КуляминЛекция 4. Основные техники построения тестовВ этой лекции рассматриваются основные техники построения тестов и используемыедля этого модели.
Начнем с разных видов моделей.Виды моделей, используемых при построении тестовДля разработки тестов необходима информация о корректном поведении тестируемойсистемы и о разнообразии ситуаций, которые могут возникать при ее взаимодействии сдругими системами или людьми. Чаще всего при использовании моделей для построениятестов различные тестовые ситуации стараются выделить из структуры этих моделей.
Самиже модели описывают, прежде всего, поведение системы или требования к этому поведению.Все модели, используемые для описания поведения ПО делятся на два основных вида —исполнимые (или операционные) и логико-алгебраические.Исполнимые модели дают описание поведения системы в терминах ее действий,определяя как она работает: какие воздействия она получает извне, что делает в ответ, какиереакции выдает.
Такое описание либо можно непосредственно выполнить, либо для еговыполнения нужна некоторая виртуальная машина. Обычно из самого вида моделиустройство такой машины примерно понятно, хотя многие детали ее устройства могутоказаться нетривиальны. Типичный пример исполнимой модели — конечный автомат. Онработает очень просто — сначала находится в начальном состоянии, ему на вход подаетсяпоследовательность входных символов, он выдает в ответ последовательность выходныхсимволов той же длины и вместе с выдачей каждого символа изменяет свое состояние.Логико-алгебраические модели описывают поведение системы не в терминах еедействий, а в терминах свойств результатов ее работы. Они делают больший акцент на то,что она делает, а не как это происходит. Чаще всего они не могут быть выполненынепосредственно.Есть, однако, промежуточные разновидности моделей, которые хотя имеют логикоалгебраическую природу, но и достаточно легко исполнимы, или совмещают элементыобоих классов моделей.Исполнимые моделиПрактически все виды исполнимых моделей являются обобщенными и расширеннымиавтоматами разных типов.Конечные автоматы (Finite State Machines, FSM, Finite Automata).Конечный автомат — набор (S, s0, I, O, T), гдеS — конечное множество, элементы которого называются состояниями автомата;s0 — элемент S, называемый начальным состоянием;I — конечное множество, элементы которого называются входными символами, входамиили стимулами, само I называют входным алфавитом автомата;O — конечное множество, элементы которого называются выходными символами,выходами или реакциями, само O называют выходным алфавитом автомата;T ⊆ S×I×O×S — множество переходов автомата.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
