1.2. Техники тестирования. Модуль 1 Тема Техники тестирования
 Скачать 4.69 Mb.
|
Модуль 1Тема 1.2. Техники тестированияИз-за большого количества различных систем разного размера, назначения и конфигураций собрать набор тестов для каждой системы не используя специальных техник представляется невозможной задачей. В этом разделе мы рассмотрим самые популярные техники, позволяющие сократить набор тестов, при этом достигнув удовлетворительного уровня тестирования. Позитивное и негативное тестированиеПозитивное тестирование – это тестирование системы на соответствие ожидаемому штатному поведению. Иными словами, мы проверяем, что система ведёт себя именно так, как должна вести. К примерам таких тестов можно отнести математические правила вроде “любое число, умноженное на ноль, в результате даст ноль” или “минус на минус даст плюс”. С помощью негативного тестирования проверяют то, как система ведёт себя в нештатных ситуациях: ввод неверных данных, обработка исключительных ситуаций и т.д. Если вернуться к примерам выше, то тут мы должны протестировать такие функции, как деление на ноль или вычисление корня из негативного числа. При написании тестов обычно сначала покрывают систему позитивными, а только потом негативными тестами. Анализ классов эквивалентностиНет необходимости тестировать комбинации всех некорректных значений. Если код, отвечающий за обработку ошибок отлавливает одну, то он обычно отлавливает и все остальные. Однако, для нахождения большего количества ошибок нужно тестировать по меньшей мере несколько комбинаций входных данных. Вывод: мы не можем протестировать все комбинации всех данных, поэтому нам нужно выбрать что именно тестировать. Выбор может облегчить техника анализа классов эквивалентности. Класс эквивалентности – часть набора данных (обычно входных данных для модуля/программы), объединённых неким отношением эквивалентности. Допущение: все входные данные из класса вызовут одинаково успешное или неуспешное поведение системы. Тестируется одно входное значение для каждого класса. Подходит для покрытия входных данных, пространства требований и спецификаций, тестирования взаимодействий, функционального тестирования. Пример: предположим, у нас есть программа, которая по сторонам треугольника может определить прямоугольный он или нет. Исходя из предположения, что для проверки этого свойства ко всем комбинациям сторон применяется одна и та же теорема Пифагора, мы можем поделить все фигуры на три класса эквивалентности: Прямоугольные треугольники Все остальные треугольники Не треугольники (тут можно, конечно, в зависимости от того, что именно принимает программа, нафантазировать с десяток классов эквивалентности, но мы для наглядности ограничимся одним) После этого достаточно будет протестировать по одной фигуре из каждого класса, чтобы с какой-то уверенностью сказать, что программа работает как ожидается. Пример: возраст человека. При обработке возраста мы можем условно разделить все значения на следующие группы: Ребёнок. Возраст ≤ 12 Подросток. 13 ≤ Возраст ≤ 19 Взрослый. 20 ≤ Возраст ≤ 64 Пожилой. 65 ≤ Возраст Слабое и сильное тестирование классов эквивалентностиЕсли наборов входных данных несколько и они независимы, то встаёт вопрос, как тестировать классы эквивалентности. Существуют два метода: слабое и сильное тестирование классов эквивалентности, При слабом тестировании нам достаточно составить набор тестов так, чтобы каждый класс был протестирован по одному разу, а при сильном тестировании должны быть проверены все комбинации классов эквивалентности. Пример: предположим, существует программа, рассчитывающая налоговые льготы в зависимости от возраста и количества детей. Добавим к предыдущему примеру следующие группы для количества детей: Нет детей. Количество детей меньше 3 Количество детей от 3 до 5 Количество детей больше 5 Слабое тестирование
Сильное тестирование
Анализ граничных значенийЗамечено, что программисты часто допускают ошибки именно на границах классов. В примере с возрастом очень маловероятно, что система поведёт себя по-разному при обработке значений 75 и 85. Однако, ошибку могут вызвать значения 64, 65 и 66, так как именно эти значения стоят на границах соседних классов эквивалентности. При написании кода программист может запутаться и вместо строгого неравенства поставить нестрогое и наоборот. Если мы хотим покрыть эти случаи, нам потребуются дополнительные тесты. На рисунке ниже изображены все необходимые тесты для тестирования двух смежных классов и их граничных значений: За пределами первого класса На границе первого класса Внутри первого класса (теоретически, можно пропустить, но тогда если предыдущий тест не пройдёт, не будет ясна причина – виновата логика программы или ошибка на границе) За пределами второго класса На границе второго класса Внутри второго класса На границе второго класса За пределами второго класса (граница открытая)  Рисунок 1. Анализ двух классов эквивалентности Таблицы решенийИногда логика программы бывает довольно сложной и сразу непонятно сколько и каких тестов понадобится, чтобы покрыть всё пространство условий. В таком случае нам на помощь приходят таблицы решений – техника, позволяющая не только не пропустить условия, но ещё и сократить количество необходимых тестов, иногда значительно. Давайте сразу рассмотрим технику на примере банкомата со следующей логикой работы при запросе выдачи денег: Если на счету достаточно средств, сумма делится на 20 без остатка (банкомат выдаёт только купюры по 20 долларов США), количество бесплатных операций выдачи не превышено – выдать запрашиваемую сумму без комиссии Если количество бесплатных операций выдачи превышено, но не превышено общее количество разрешённых операций выдачи, выдать сумму и снять комиссию за обналичивание Если общее количество разрешённых операций выдачи превышает максимум, показать специальное сообщение об ошибке (“вы превысили максимальное количество операций выдачи”) и отменить транзакцию Если на счету недостаточно средств, показать сообщение об ошибке (“на вашем счёте недостаточно средств”) Если сумма не делится на 20 без остатка, показать сообщение об ошибке (“вы ввели неверную сумму”) Как протестировать такую логику, не забыв ничего и как составить набор тестов? В этом нам помогут следующие восемь шагов для построения таблицы решений Перечислите все возможные действия Перечислите все возможные входные данные для каждой переменной Посчитайте количество правил Заполните столбцы всеми возможными комбинациями данных Сопоставьте каждую комбинацию с классом эквивалентности Уменьшите количество комбинаций, находя общие действия Проверьте оставшиеся комбинации Разработайте тесты Давайте разберём их по порядку Перечислите все возможные действияВозможных действий здесь пять: выдать деньги, снять комиссию, показать сообщения трёх типов. Давайте запишем их в таблицу.
Перечислите все возможные входные данные для каждой переменнойФактически, у нас три переменных, от которых зависит результат: “достаточно средств”, “сумма делится на 20” и “количество снятий”. Первые две переменные принимают значения “Да” и “Нет”, а третья может принимать три значения. Давайте запишем их в отдельную таблицу.
Посчитайте количество правилЗдесь всё просто: нужно просто перемножить количества вариантов для всех переменных: 2 х 2 х 3 = 12 Заполните столбцы всеми возможными комбинациями данныхТеперь мы берём таблицу из предыдущего пункта, но вместо всех возможных входных данных в столбцы записываем их конкретные комбинации. Нетрудно догадаться, что таких столбцов будет 12 (для лучшей читаемости таблица разбита на две части).
Сопоставьте каждую комбинацию с классом эквивалентностиНа этом шаге нужно объединить две таблицы, подписав под предыдущей все возможные исходы. Что в нашем случае будет являться классом эквивалентности? Возможный исход.
На примере выше видно, что бывают такие комбинации входных условий, которые в теории должны привести ко множественному исходу (n3). Однако, понятно, что достаточность средств является превалирующим условием, поэтому можно убрать лишние отметки. Итоговая таблица будет выглядеть вот так:
Уменьшите количество комбинаций, находя общие действияВ первой части таблицы можно заметить, что результат зависит исключительно от первого параметра, поэтому нет смысла тестировать все шесть комбинаций и таблицу можно “схлопнуть”
Проверьте оставшиеся комбинацииТак же можно поступить и с наборами n7-n9. В результате получится следующая таблица:
Разработайте тестыНа основе полученных данных уже можно собрать набор тестов и тестировать логику банкомата. Попарное тестированиеPairwise testing (all-pairs analysis, попарное тестирование или попарный анализ, анализ всех пар комбинаций) - это современная и эффективная методика тестирования, основанная на том предположении, что большинство дефектов возникает при взаимодействии всего двух факторов, Тестовые наборы, генерируемые при использовании данной методики охватывают все уникальные пары комбинаций факторов, что считается достаточным для обнаружения большего числа дефектов. Давайте рассмотрим пример – представим форму, на которой есть: список – может принимать значение от 0 до 9 включительно поле ввода – может принимать целочисленные значения от 1 до 99 включительно чекбокс1 – принимает значения on / off чекбокс2 – принимает значения on / off Всего возможных комбинаций 10 * 99 * 2 * 2 = 3960. Довольно много, если тестировать все из них. Но в таком количестве комбинаций пары будут часто повторяться, поэтому мы можем сгенерировать куда более компактный набор. Шаг 1: необходимо определить какое количество входных параметров (переменных) у нас есть и какие значения может принимать каждый входной параметр  Шаг 2: если можно упростить значения переменных, то обязательно это делаем. Например, поле ввода может принимать значения от 1 до 99. Понимая бизнес-логику приложения мы можем разбить значения 1 до 99 на классы эквивалентности и использовать уже их как возможные значения для комбинирования. Либо можем использовать технику граничных значений. Для простоты уменьшим количество возможных значений до трёх - валидное целочисленное значение, невалидное целочисленное значение, символы. Следующим шагом уменьшим количество возможных значений для списка до двух: 0 и любое другое значение Шаг 3: теперь наши входные данные выглядят так  Поменяем порядок столбцов таблицы так, чтобы переменная с наибольшим количеством значений была первой, а с наименьшим количеством значений – последней  Шаг 4 Каждая строка таблицы будет представлять уникальный набор входных данных для теста. Смотрим сколько значений может принимать переменная второго столбца (список) – столько раз нужно вставить все значения первого столбца  Шаг 5 Заполняем второй столбец. Для каждой пары одинаковых значений первого столбца заполняем оба значения второго столбца  Шаг 6 Таким же образом заполняем третий столбец  На этом шаге видно, что у нас нет пар из значений второго и третьего столбцов “0 - off” и “other - on”. Поэтому в одном месте придётся просто поменять порядок значений. Это будет выглядеть следующим образом (обратите внимание на строки 4-5):  Шаг 7 Добавляем значения последней переменной.  Прелесть данного метода в том, что если мы захотим добавить ещё два чекбокса, то количество тестов увеличится не в четыре раза, как можно было бы подумать, а всего лишь на две строки.  Пример инструмента для генерации данных для попарного тестирования: https://pairwise.teremokgames.com/ Диаграммы состоянийПрименяются в следующих случаях: Тестировщик проверяет приложение на конечный набор входных значений. Тестировщик пытается проверить последовательность событий, которые происходят в тестируемом приложении Тестируемая система имеет зависимость от событий / значений в прошлом  То же самое, но в виде таблицы:  | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||