softwaretesting102 МаратАхин 2011kspt.icc.spbstu.ru/.../software-testing-102v2.pdf ·...

Основы тестирования программного обеспеченияSoftware Testing 102

Марат Ахин

Санкт-Петербургский государственный политехнический университет

2011

Марат Ахин (СПбГПУ) Введение 2011 1 / 146

Прелюдия

Содержание

1 ПрелюдияSoftware Testing 102Что такое тестирование?

2 Общая модель тестирования

3 Уровни тестирования ПО

4 Homework

5 Тестирование белого ящика

6 Design for testability

7 Homework

8 Интеграция тестирования в процесс разработки ПО

9 Будущее тестирования


Прелюдия

Методы обеспечения качества ПО


Прелюдия Software Testing 102

Software Testing 102

Основы тестирования программного обеспеченияТо, что Вы точно должны знать, если хотите стать хорошимспециалистом по тестированию ПОА если я хочу быть разработчиком?

Знание основ тестирования ПО разработчику никогда не помешает


Прелюдия Software Testing 102

Почему разработчик должен уметь тестировать ПО?

Потому что так сказал преподаватель!

Потому что тестирование является основой практически любойметодологии проектирования и разработки ПО, которыеиспользуются в настоящее время


Прелюдия Что такое тестирование?

Что за вопрос лежит в основе тестирования?

Работает ли это ПО правильно?НЕТ, тестирование никогда не может дать Вам ответа на этотвопрос

Работает ли это ПО неправильно?

ДА, тестирование может (и должно) ответить на этот вопрос

Тестирование = Разрушение



Что такое тестирование?

Лучший друг верификации и валидации ПОВ чем разница?

Верификация – «мы сделали это правильно»Валидация – «мы сделали то, что надо»



Можем ли мы что-то гарантировать при тестировании?

Данное ПО никогда не упадет по NPEПотоки никогда не заблокируютсяВычисления всегда выполняются корректноВременные характеристики всегда выдерживаются

Мы можем дать такие гарантии лишь в самых тривиальных случаях,когда обычно все ясно и без тестирования

Почему это так – мы рассмотрим в следующих лекциях



Почему тестировать сложно?

Brian Kernighan«Debugging is twice as hard as writing the code in the first place.Therefore, if you write the code as cleverly as possible, you are, bydefinition, not smart enough to debug it.»

Massimo Arnoldi (feat. Kent Beck)

«Unfortunately at least for me (and not only) testing goes against humannature. If you realize the pig in you, you will see that you program withouttests.»

Чтобы сделать тестирование более приятным процессом, необходимопонять его характерные особенности и свойства


Общая модель тестирования


1 Прелюдия

2 Общая модель тестированияТестирование ПО с точки зрения дилетантаМодель программной ошибкиМодель тестирования ПО


4 Homework



7 Homework




Общая модель тестирования Тестирование ПО с точки зрения дилетанта

Тестирование ПО с точки зрения дилетанта

Запустили приложениеПроверили результаты выполнения на предмет наличия в нихошибок

aka «багов»aka «сбоев»aka «дефектов»aka «неудач»

Сперва надо разобраться, а что же такое «программная ошибка»?


Общая модель тестирования Модель программной ошибки

Модель программной ошибки

FAILURE

FAULT

ERROR

Неудача – наблюдаемое снаружинекорректное поведение программыСбой – некорректное состояниепрограммы из-за ошибкиОшибка – ошибка в самойпрограмме, внесенная на этаперазработки

Рассмотрим данную модель на примере




Найдите ошибку в следующей программе на Java

1 int sumCollection(final Collection <Integer > c) {2 int sum = 0;3 for (int i : c) {4 sum += i;5 }6 return sum;7 }

Возможное переполнение в строке 4




c = {}

Что будет?


Нет ни сбоя, ни неудачи – программа работает корректно




c = {1, 2, 3, 5}

Что будет?


Нет ни сбоя, ни неудачи – программа работает корректно




c = {1, 2, 3, 5, +MAX_INT, -MAX_INT}

Что будет?


Сбой есть – программа проходит через некорректное состояниеНо неудачи нет – результат работы программы корректен




c = {1, 2, 3, 5, +MAX_INT}

Что будет?


Сбой есть – программа проходит через некорректное состояниеНеудача тоже есть – результат работы программы неправильный


Общая модель тестирования Модель тестирования ПО

Модель тестирования ПО

Эталонная модель может бытьпредставлена множеством различныхспособов

неформальное представление того,«как ПО должно работать»формальная техническаяспецификациянабор тестовых примеровкорректные результаты работыпрограммыдругая (априори корректная)реализация той же исходнойспецификации



Свойства теста

Для того, чтобы найти ошибку, тест должен обеспечивать выполнениеопределенных свойств

Каких?Reachibility – тест должен выполнить место в исходном коде, гдеприсутствует программная ошибкаCorruption – при выполнении ошибки состояние программыдолжно испортиться с появлением сбояPropagation – сбой должен распространиться дальше и вызватьнеудачу в работе программы

Обеспечение этих свойств – одна из самых сложных проблемтестирования ПО



Свойства теста

О том, как обеспечить выполнение этих свойств, мы поговорим наследующей лекции

А сейчас...Как именно мы можем наблюдать за ошибками в работе программы?

Можно выделить три основных уровня, на которых мы можемпроверять корректность работы программы


Уровни тестирования ПО


1 Прелюдия


3 Уровни тестирования ПОМодульное тестированиеТестирование черного ящикаТестирование белого ящикаИнтеграционное и системное тестирование

4 Homework



7 Homework




Уровни тестирования ПО Модульное тестирование

Модульное тестирование

Модульное тестирование – проверка корректности работыотдельных модулей программыМодуль – это

Набор входовНекий «ящик», выполняющий какие-либо преобразованияНабор выходов

Вопрос – что мы вообще можем сделать с модулем?




Мы можемПодать модулю на вход какие-либо данныеСчитать с выходов результаты его работы

К сожалению, это ВСЕ, что мы можем сделать с модулем

Как можно тестировать ПО в таких ужасных условиях?




Решение «в лоб»Протестировать модуль на всех возможных комбинациях входов

Чтобы протестировать функцию, которая перемножает два32-разрядных числа, необходимо перебрать 264 вариантов.Если на проверку каждого варианта тратить по 1 наносекунде,нам понадобится всего лишь 584 года

Необходимо как-то уменьшить число перебираемых вариантов




Все зависит от того, знаем ли мы что-нибудь о том самом«ящике»

Тестирование черного ящика – известна только внешняяспецификация модуляТестирование белого ящика – известно полное внутреннееустройство модуляТестирование серого ящика – известны некоторые деталиустройства модуля


Уровни тестирования ПО Тестирование черного ящика

Тестирование черного ящика

Мы ничего не знаем об устройстве модуляМы знаем только то, как он должен себя вести с точки зрениясобственного окружения

Разбиение на классы эквивалентностиИдея заключается в том, чтобы разбить пространство входныхсостояний программы на небольшое число классовэквивалентности таким образом, чтобы все элементы одногокласса эквивалентности обрабатывались модулем одинаково сточки зрения спецификацииВ случае, если при написании модуля спецификация былаполностью учтена, тестирование всех классов эквивалентностиозначает полное тестирование данного модуля




Пример

Вход – пара чисел (x , y)Выход – строка, характеризующая отношение между x и y

x < yx > yx = yERROR (если на вход модуля был подан объект, не являющийсяпарой чисел)

В данном случае все просто и понятно...




ПримерВход – три числа x , y и zВыход

x · y · z , если x – целое число, y > 0, z > 0x · y , если x – целое число, x < 42, y > z2

xz , если x представимо рациональной дробью по основанию 13,z < 42...

В этом случае все уже не столь очевидно...




Необходимо использовать какую-либо стратегию комбинированияортогональных друг другу классов эквивалентности

ПримерРасчет городского налога

Нерезиденты платят 1% от общего доходаРезиденты платят

1% от дохода, если он не превышает 300,000 в год5% от дохода, если он не превышает 600,000 в год15% от дохода, если он превышает 600,000 в год




Некоторые стратегии дают разную схему комбинирования классовэквивалентности для разных спецификаций, даже если эти

спецификации задают одинаковое поведение модуля


Если доход не превышает 300,000 в год, налог составляет 1%Если доход не превышает 600,000 в год

Для нерезидентов налог составляет 1% от общего доходаДля резидентов налог составляет 5% от общего дохода

Если доход превышает 600,000 в годДля нерезидентов налог составляет 1% от общего доходаДля резидентов налог составляет 15% от общего дохода



Причинно-следственный анализ

Анализ причинно-следственных связей

Систематический подход к перебору возможных причин (входов)и следствий (выходов) и отношений между нимиПод причиной может пониматься как конкретное значение входа,так и определенный класс эквивалентностиПод следствием обычно понимается конкретное значение выхода

Но иногда это может также быть какой-либо классэквивалентности




1: Определение причин и следствийСамый важный и самый сложный этап анализаКрайне важно выбрать правильный уровень абстракцииПричины не обязательно должны быть взаимоисключающими

2: Вывод логических отношений и ограниченийЗадаются при помощи логических операций И, ИЛИ, НЕОписывают возможные комбинации причин с учетоманализируемой предметной области и здравого смысла




3: Выбор подходящей стратегии выбора тестовС помощью стратегии задается то, какие комбинации причинбудут выбираться при проведении тестовВ зависимости от выбранной стратегии будут получаться те илииные показатели полноты и стоимости тестирования

4: Составить план тестированияТребует внимательного анализа причинно-следственныхзависимостей в соответствии со стратегией выбора тестовОбычно это крайне трудоемкий процесс

Что означает возможность ошибки при подготовке к тестированиюА это очень и очень плохо – поэтому желательно использоватьсредства автоматизации





Нерезиденты платят 1% от общего доходаРезиденты платят

1% от дохода, если он не превышает 300,000 в год5% от дохода, если он не превышает 600,000 в год15% от дохода, если он превышает 600,000 в год

Удобным способом представления причинно-следственных связейявляются булевы графы




Возможные стратегии выбора тестов

1 Все возможные комбинации причин2 Все возможные эффекты при минимальном общем числе тестов3 Все возможные эффекты для всех возможных при этом

комбинаций причин4 Стратегия 3 с набором дополнительных правил

Для узлов типа И рассматриваем только такие комбинациипричин, в которых

либо все входы истиннылибо лишь один вход ложен

Для узлов типа ИЛИ рассматриваем только такие комбинациипричин, в которых

либо все входы ложнылибо лишь один вход истинен



Другие методы тестирования черного ящика

Анализ граничных значений

Exploratory testingМетод научного тыкаЧертовски эффективный в случае правильного его примененияНеобходимо выйти за рамки разумного и пытаться сломатьсистему настолько нестандартными способами, какие Вы толькоможете себе представить

Ad hoc testingСамый неформальный метод тестированияМетод научного тыка, возведенный в абсолютНет ни предварительного планирования, ни документированияпроцесса тестирования



Exploratory testing

Exploratory testing is simultaneous learning, test design, and test execution

Test designCareful observationCritical thinkingDiverse ideasRich resources



Exploratory testing

Input/Output attacksAttacks by input valueAttacks by input value combinationAttacks by input order

Data attacksAttacks by variable valueAttacks by data element sizeAttacks by data access

Computation attacksAttacks by operandAttacks by resultAttacks by feature interaction


Уровни тестирования ПО Тестирование белого ящика

Тестирование белого ящика

Будет рассмотрено на следующей лекции


Уровни тестирования ПО Интеграционное и системное тестирование

Интеграционное и системное тестирование

Тестирование корректности работы нескольких модулей вместе всоставе программной системы

Два основных подходаМоментальный

Тестирование взаимодействия начинается после написания всехотдельных модулейТакое тестирование также известно как тестирование методом«Большого Взрыва»

ИнкрементальныйТестирование взаимодействия выполняется постоянно, в процессеразработкиВопрос в том, о какой инкрементальности мы говорим



Интеграционное и системное тестирование



Нисходящее интеграционное тестирование

Тестирование начинается с верхних уровней системыОтсутствующие на данный момент модули заменяются«заглушками»По мере реализации новых модулей они подключаются к системевместо «заглушек»



Нисходящее интеграционное тестирование

ПреимуществаВозможность ранней проверки корректности высокоуровневогоповеденияМодули могут добавляться по одному, независимо друг от другаНе требуется разработка множества драйверовМожно разрабатывать систему как в глубину, так и в ширину

НедостаткиОтложенная проверка низкоуровневого поведенияТребуется разработка «заглушек»Крайне сложно корректно сформулировать требования ковходам/выходам частичной системы



Восходящее интеграционное тестирование

Тестирование начинается с нижних уровней системыОтсутствующие на данный момент модули заменяютсядрайверамиПри реализации всех модулей нижнего уровня драйвер можетбыть заменен на соответствующий модуль



Восходящее интеграционное тестирование

ПреимуществаВозможность ранней проверки корректности низкоуровневогоповеденияНе требуется написание заглушекПросто определить требования ко входам/выходам модулей

НедостаткиОтложенная проверка высокоуровневого поведенияТребуется разработка драйверовПри замене драйвера на модуль высокого уровня можетпроизойти «мини-Большой Взрыв»



Системное тестирование

Модульное тестирование «очень большого и сложного ящика»

Обычно системное тестирование выполняется с определеннойцелью

Тестирование производительностиСтресс тестированиеТестирование безопасностиТестирование совместимостиТестирование переносимостиТестирование восстанавливаемостиТестирование устанавливаемостиТестирование обслуживаемости...



Системное тестирование

Как проверить соответствие поведения системы неформальнымтребованиям?


Homework


1 Прелюдия



4 Homework



7 Homework




Homework

Homework

Написать краткое эссе на тему: какойметод системного тестированияявляется самым важным с точкизрения обеспечения качества ипочему?Оригинальность (в разумныхпределах) приветствуется


Homework

Полнота тестирования ПО: оценка и обеспечениеSoftware Testing 102

Марат Ахин


2011

Марат Ахин (СПбГПУ) D4T 2011 51 / 146

Homework

Quiz


Тестирование белого ящика


1 Прелюдия



4 Homework

5 Тестирование белого ящикаСвойства тестирования белого ящикаПокрытие потока управленияПокрытие потока данныхМутационное тестирование


7 Homework




Тестирование белого ящика Свойства тестирования белого ящика

В чем отличие от тестирования черного ящика?

В цвете??? Вообще-то – да!

Мы знаем то, как устроен тот «ящик», который мы тестируемМы можем использовать это знание для того, чтобыпроектировать тестыЭтот метод также известен как структурное тестирование

Это дополнительное знание – хорошо или плохо?



Свойства тестирования белого ящика

Дополнительная информация о тестируемом ПО не может бытьлишней

Благодаря ей мы можем проектировать более эффективные иточные тестыМы знаем устройство «ящика» – и знаем то, какие его частитребуют более тщательного тестирования, а какие можнопрактически не тестироватьЗа счет этого можно снизить стоимость проведения тестирования




К сожалению, при тестировании ПО всегда есть один негативныйфактор – человек

Обычно при тестировании белого ящика тесты пишет самразработчик «ящика»При разработке он думал о вполне определенных входныхвоздействиях на модульСкорее всего, при тестировании он будет подавать такие жевходные воздействияВ то же время, ошибки появляются, когда в работе модулявозникают «неожиданности»




Как мы можем использовать знание о том, как устроен тестируемыймодуль?

Мы можем пытаться обеспечить определенный уровеньпокрытия исходного кода модуляВ зависимости от того, как именно мы хотим покрыть исходныйкод, мы будем получать те или иные методы тестирования белогоящика

Оценки покрытия также используются для оценки полнотытестирования ПО

Об этом мы поговорим чуть дальше



Виды тестового покрытия

Выделяют два основных вида покрытияПокрытие потока управленияПокрытие потока данных

Они работают с такими понятиями, как граф потокауправления (CFG) и граф потока данных (DFG)

Надеюсь, что все знают, что такое CFG и DFG?..


Тестирование белого ящика Покрытие потока управления

Покрытие потока управления

Как мы можем покрыть данныйCFG?

По узламПо дугамПо условиямПо путям...



Покрытие операторов программы

Каждый узел CFG был пройден впроцессе тестирования хотя бы один разСамый слабый способ оценки тестовогопокрытия

Сколько тестов требуется для того, чтобыобеспечить полное покрытие операторовпрограммы для следующего примера?



Покрытие ветвлений программы

Каждая ветка программы была пройденахотя бы один разНесколько более сильный способ оценкипокрытия

Сколько тестов требуется для того, чтобыобеспечить полное покрытие ветвленийпрограммы для следующего примера?




Как соотносятся между собой покрытияоператоров и ветвлений?

1 Никак2 Покрытие операторов включает покрытие

ветвлений3 Покрытие ветвлений включает покрытие

операторов




Никак

Почему покрытие ветвлений не включаетв себя покрытие операторов?

Потому что в программе можетприсутствовать «мертвый код»



Покрытие условий программы

Каждое ветвление может выполняться по различным причинамПри покрытии условий программы мы требуем, чтобы все условияпрограммы хотя бы один раз приняли значение «true» и «false»

1 if (p != q && (p == null || !p.equals(q))) {2 ...3 }

Как соотносятся между собой покрытия ветвлений и условий?



Покрытие ветвлений и условий программы

Комбинация соответствующих покрытийПолностью покрывает их

Можно ли предложить что-то более сильное?




Комбинационное покрытие условий программы

Полный перебор всех возможных комбинаций условий всехвозможных ветвлений

Сколько вариантов необходимо перебрать, чтобы получить полноекомбинационное покрытие для следующего примера?




Покрытие путей программы

Мы требуем, чтобы все возможные пути программы быливыполнены хотя бы один раз

Как данное покрытие соотносится с комбинационным покрытиемусловий?

Обычно считается самым сильным типом покрытия потокауправленияЕго можно было бы использовать, если бы не...

Циклы и рекурсия




450 возможных путей




Для борьбы с этим используют несколько подходов

Один из вариантовТребуем, чтобы тело цикла было выполнено

012kmaxmax + 1

Объясните, почему выбраны именно эти варианты


Тестирование белого ящика Покрытие потока данных

Покрытие потока данных

Что еще можно сделать?

Можно вспомнить о том, что программы работают не просто такОсновная цель работы любой программы – работа с данными

С этой точки зрения для тестирования представляет интересанализ таких путей выполнения программы, на которых активноработают с данными

Сперва вспомним несколько определений



Определения и использования переменных

Определение переменной (Def)

Оператор программы, в котором значение переменной v может бытьизменено

v = 42

f(&v, ...)

scanf(fmt, &v)

Использование переменной (Use)

Оператор программы, в котором значение переменной v влияет навыполнение программы тем или иным способом

q = v + 2

g(v, ...)

if (v != NULL) ...



Определения и использования переменных

Def-Use ChainПара (d , u) операторов программы, для которой выполняютсяследующие условия

d – определение переменной v

u – использование переменной v

между d и u существует хотя бы один путь, на которомпеременная v не переопределяется

Рассмотрим данные определения на примере



Пример




Какие варианты покрытий можно предложить с использованием этихпонятий?

Покрытие всех определенийДля каждой интересующей нас переменной v должна бытьпротестирована хотя бы одна Def-Use Chain от каждогоопределения v до хотя бы одного использования v



All-Def Coverage

Рассмотрим следующие тесты1 → 2 → 3 → 4 → 5 → 6




Покрытие всех использованийДля каждой интересующей нас переменной v должна бытьпротестирована хотя бы одна Def-Use Chain от каждогоопределения v до каждого использования v

Является ли All-Use более сильным критерием по сравнению с All-Def?



All-Use Coverage

Рассмотрим следующие тесты1 → 2 → 3 → 4 → 5 → 61 → 2 → 3 → 4 → 61 → 3 → 4 → 5 → 6




Покрытие всех Def-Use ChainДля каждой интересующей нас переменной v должны бытьпротестированы все возможные Def-Use Chain от каждогоопределения v до каждого использования v

Как соотносится All-Def-Use-Chain с покрытием всех путей программы?



Пример


Тестирование белого ящика Мутационное тестирование

Что еще мы можем сделать с «белым ящиком»?

Зная внутреннее устройство модуля, мы можем измерить то,насколько полно мы его тестируемА также можем оптимизировать написание тестов, используяинформацию о тестовом покрытии

Может быть, кто-нибудь сможет предложить что-нибудь еще?




Мы всегда можем забраться внутрь модуля и что-нибудь тамизменить

Зачем?

Чтобы оценить полноту нашего тестирования – но в другойплоскости

Идеальный тест работает только на тестируемой программеПри любом изменений он перестает проходить

В этом заключается основная идея «мутационного тестирования»



Мутационное тестирование

Исходная программа подвергается мутации, в результатеполучается набор из N мутантовПосле этого имеющиеся тесты запускаются на этих мутантах

Если тест не проходит на мутанте, то говорят, что тест «убивает»этого мутанта

Доля «убитых» мутантов показывает, насколько полно данныйнабор тестов покрывает нашу программу

Недостатки?



Мутационное тестирование

Основная сложность заключается в том, что данный видтестирования практически невозможно выполнять вручную

Количество необходимых для оценки покрытия мутантовпропорционально объему анализируемого ПОПонятно, что даже для небольшой программной системыполучение достаточного числа мутантов вручную являетсяневозможным

Кроме того, сильно возрастают затраты на проведениетестирования

Вместо одного запуска каждого теста требуется выполнить Nзапусков


Design for testability


1 Прелюдия



4 Homework


6 Design for testabilityTest-Driven DevelopmentСпособы обеспечения управляемостиСпособы обеспечения наблюдаемостиТестирование некоторых классов приложений

7 Homework







Зачем?

Тест должен обеспечивать выполнение трех основных свойствReachibilityCorruptionPropagation



Как можно обеспечить выполнение этих свойств?

1 Можно надеяться на то, что данные свойства будут выполнятьсясами по себе

Как показывает многолетний опыт, если при разработке ПО недумают о RCP, то тестировать данное ПО будет очень сложноАдаптировать ПО для тестирования, если RCP нет, такжепрактически невозможно

2 Можно заранее обеспокоиться выполнением RCP

Design for Testability (D4T)

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


Design for testability Test-Driven Development

Как можно обеспечить выполнение этих свойств?

Способы D4T зависят от того, какое ПО мы разрабатываем

Test-Driven DevelopmentНаиболее известный способ обеспечения D4TЕдинственный способ, применимый практически к любому ПООсновной принцип – тесты разрабатываются перед исходнымкодом

Зачем?



Test-Driven Development

Чтобы обеспечить управляемость и наблюдаемость

Наблюдаемость обеспечивается за счет того, что каждый тестпроверяет какой-либо набор предположений о тестируемойпрограмме

Корректность этих предположений должна быть видна снаружипрограммыДля каждого теста проверяется как успешное, так и неудачноевыполнение теста

Управляемость обеспечивается за счет того, что тесты пишутсядля минимальных элементов функциональности

Никакой дополнительной функциональности, которая не покрытатестами, нетЛюбое возможное действие имеет соответствующий тест

Преимущества и недостатки?



Test-Driven Development

TDD стимулирует к написанию маленьких, локальных модулейОшибки обнаруживаются рано, что снижает стоимость ихисправленияРазработка идет от функциональности, что приводит к созданиюболее простых и понятных интерфейсов

Разработка тестов требует дополнительного времениПри исправлении ошибки, сделанной на ранних этапахразработки, требуется модифицировать или написать с нулябольшое число тестовЭффект «розовых очков»


Design for testability Способы обеспечения управляемости

Способы обеспечения управляемости

Мы можем практически полностью управлять тем кодом, чторазработан нами

Этим вопросом занимаются такие дисциплины как SoftwareArchitecture, Software Analysis & Design, etc.

Кроме этого, в ПО обычно есть значительная часть кода, скоторым мы ничего сделать не можем

сторонние библиотекисистемные библиотеки ОСlegacy-код

Как управлять ими?



Simulate & Stub

Никак

Критически важные сторонние компоненты необходимоэмулировать или заменять заглушками (Simulate & Stub → S&S)

Заглушки могут работать значительно быстрее, чем сторонний кодЗаглушки являются полностью управляемыми элементами

С их помощью можно имитировать редкие ошибки (например,сбои в аппаратуре)Заглушки могут «вносить в систему детерминизм» там, где его нет

S&S может обеспечить «обратную масштабируемость» (downwardsscalability)



Simulate & Stub

Пример S&S – mock-объекты

Заглушки в ООПМогут быть легко заменены (при правильном проектировании) нареальные объекты при развертывании приложенияЧасто работают на порядок быстрее реальных объектовСтимулируют разработку модульного, слабо связанного кода



Способы обеспечения управляемости

А все же – что мы можем сделать с нашим кодом?

Правило C2POFConsistent test run resultsConfiguration is not neededPartial testing is possibleOrder of tests is not importantFast run time



C2POF

Результаты тестов должны быть повторяемымиВ тесте не должно быть недетерминированного поведенияНеобходимо минимизировать зависимость теста от его окруженияS&S – но уже внутри нашего кода

Тесты не должны требовать дополнительной конфигурацииЭто касается как самих тестов, так и тестируемых модулейпрограммыИначе в каждом тесте требуется выполнять рутинную работу позаданию каких-либо параметровS&S – но уже внутри нашего кода

Тесты должны выполняться быстроКогда число тестов становится достаточно большим, Вы неможете тратить по 10 минут каждые полчаса на запуск тестовНо тесты необходимо запускать часто – чтобы находить ошибкикак можно раньшеS&S – но уже внутри нашего кода



C2POF

Тесты должны допускать возможность частичного запускаТо есть между тестами не должно быть никаких зависимостей повыполнениюВ противном случае возникают сложные, мало кому понятныеошибки при изменении отдельных тестов

Тесты должны допускать возможность запуска в любом порядкеТо есть между тестами не должно быть никаких зависимостей повыполнениюЕсли Вы не можете добиться этого – значит, Вы делаете что-то нетак

Какие из этих свойств важнее?Какие из этих свойств сложнее в обеспечении?


Design for testability Способы обеспечения наблюдаемости

Способы обеспечения наблюдаемости

Некоторые способы обеспечения наблюдаемости мы ужерассмотрели «между строк» ранее

Например, разработка на основе маленьких, локальных модулей

Что еще можно сделать?


Зачем?

Чтобы обеспечить выполнение свойства распространяемости сбояЭто, фактически, и означает обеспечение наблюдаемости




Выделяют три основных способа обеспечения наблюдаемостиИспользование assert’овПроверка состояния программы при выполненииЖурналирование

AssertionsКонтролируют некоторые факты о состоянии программы принеобходимостиПревращают некоторые сбои в неудачи

Причем по такой неудаче относительно просто понять причину еевозникновения

Могут использоваться как при тестировании, так и во времяреальной эксплуатации ПО




Invariant checkersПроверяют корректность состояния программы в какой-то точкевыполнения

Могут рассматриваться как более масштабные assert’ы

Корректность может выражаться как набор довольно сложныхинвариантовМогут обнаруживать хитрые «скрытые» сбоиКрайне ресурсоемки, поэтому используются только притестировании




LoggingСамый часто используемый способ обеспечения наблюдаемостиЗаписывают трассы выполнения программы вместе с еесостоянием в удобной для разработчика формеПредоставляют разработчику очень много информации

Это позволяет разобраться в причинах некорректной работыпрактически в любом случаеЭто может сделать работу с трассами практически невозможной


Design for testability Тестирование некоторых классов приложений

Тестирование некоторых классов приложений

Простота обеспечения управляемости и наблюдаемости зависитот того, какое ПО мы разрабатываемРассмотрим некоторые проблемы, которые возникают притестировании

объектно-ориентированных приложенийприложений с GUIВеб-приложений



Тестирование ОО-приложений

В чем основные отличия ОО-приложений?НаследованиеПолиморфизмИнкапсуляция

Как они влияют на управляемость и наблюдаемость?



Тестирование ОО-приложений

Наследование и полиморфизм усложняют обеспечениеуправляемости

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

Инкапсуляция усложняет наблюдаемостьСобственно, ее основная задача – это скрыть подробностиреализацииУ нас нет стандартных средств определения внутреннего состоянияобъектов



Тестирование приложений с GUI

В чем основные отличия приложений с GUI?В GUIОсновной недостаток GUI для тестирования – крайне большоевозможное число состоянийКроме того, GUI обычно очень контекстно-чувствительны

Как это влияет на управляемость и наблюдаемость?



Тестирование приложений с GUI

Управляемость GUI обычно крайне низкаЧасто с этим ничего невозможно сделатьВ некоторых случаях GUI имеет средства автоматизацииДля больших интерфейсов даже этого может быть мало

Наблюдаемость GUI обычно крайне низкаАнализировать визуальные ошибки автоматически очень сложноК сожалению, классические средства обеспечения наблюдаемостислабо подходят для работы с GUI



Тестирование Веб-приложений

В чем основные отличия Веб-приложений?Распределенная архитектураАктивная работа с базами данныхКрайне сложное взаимодействие с пользователем

Как они влияют на управляемость и наблюдаемость?



Тестирование Веб-приложений

Распределенная архитектура несколько помогает притестировании

ПО всегда можно «разрезать» по какой-либо плоскости ииспользовать S&SВзаимодействие по сети просто отслеживать и анализировать

БД усложняют обеспечение как управляемости, так инаблюдаемости

БД – это огромное хранимое состояние программы, котороевлияет на ее работуПонять, что и как хранится в БД, очень сложно


Homework


1 Прелюдия



4 Homework



7 Homework




Homework

Homework

Написать эссе объемом не менее 3000символов на одну из следующих тем

Какое из свойств C2POF важнее ипочему?Какое из свойств C2POF сложнее вобеспечении и почему?Какой из способов обеспеченияуправляемости лучше и почему?Какой из способов обеспечениянаблюдаемости лучше и почему?


Homework

Интеграция тестирования в жизненный циклразработки ПОSoftware Testing 102

Марат Ахин


2011

Марат Ахин (СПбГПУ) РТ 2011 112 / 146

Homework

Quiz


Интеграция тестирования в процесс разработки ПО


1 Прелюдия



4 Homework



7 Homework

8 Интеграция тестирования в процесс разработки ПОТестирование ПО в процессе разработкиРегрессионное тестированиеВыборочное регрессионное тестированиеУправление регрессионными тестамиРТ на практике



Интеграция тестирования в процесс разработки ПО Тестирование ПО в процессе разработки

Тестирование ПО в процессе разработки

Как ПО изменяется в процессе разработки?

Инкрементально, небольшими независимыми шагамиИзменение уже существующего кодаИсправление ошибокДобавление новой функциональностиАдаптация имеющихся компонентов к новым задачам

Любые (даже самые незначительные) изменения могут серьезноповлиять на качество ПО


Интеграция тестирования в процесс разработки ПО Тестирование ПО в процессе разработки

Тестирование ПО в процессе разработки

После любого изменения требуется проверить, что в программе непоявилось новых ошибокДля этого мы выполняем все имеющиеся тесты и проверяем, чтовсе они успешно завершаются

Основной вид тестирования в процессе разработки ПО – эторегрессионное тестирование


Интеграция тестирования в процесс разработки ПО Регрессионное тестирование

Регрессионное тестирование

Как выглядит одна итерация регрессионного тестирования?

1 Мы модифицируем программу P и получаем программу P′

2 Из всего множества тестов T мы выбираем набор тестов T′,

который необходимо выполнить на P′

3 Для новой функциональности мы разрабатываем новые тесты T′′

4 Полученный набор тестов T′+ T

′′запускается на P

′

5 Результаты выполнения анализируются с последующейвозможной модификацией как программы, так и набора тестов

Какие проблемы связаны с РТ?




Проблема №1

Как выбрать набор тестов T′после изменения в программе?

Консервативный подходВыбирать все имеющиеся тестыПолное регрессионное тестирование

Экономичный подходВыбирать все тесты, каким-либо образом связанные потребованиям/спецификации/интуиции с изменениями в коде«Выборочное» регрессионное тестирование




Каким свойствам должно удовлетворять выборочное регрессионноетестирование?

Полнота – способность выбирать те тесты, которые могутобнаружить ошибки, связанные с изменениями в кодеТочность – способность пропускать такие тесты, которые неизменяют своего поведения на модифицированной программеЭффективность – способность выполняться быстрее, чем полноерегрессионное тестированиеУниверсальность – применимость в большинстве практическихситуаций

«Качественно. Быстро. Дешево. Выберите любые два.»




Умный подходВыбирать тесты, которые «затрагивают» при выполненииизмененные части программыВыборочное регрессионное тестирование

Существует множество подходов к ВРТ на различных уровняхМодульное ВРТИнтеграционное ВРТСистемное ВРТ

Все подходы различаются по двум основным критериямСпособ идентификации измененных программных компонентовМетод получения информации о покрытии элементов программытестами


Интеграция тестирования в процесс разработки ПО Выборочное регрессионное тестирование

Модульное ВРТ

Подход МакКартиАнализ изменений на уровне целого модуляСвязь элементов программы с тестами задается вручнуюразработчиком





Поход Ротермела и ХарролдАнализ изменений на уровне узлов CFG программыСвязь элементов программы с тестами задается на уровне CFG наоснове динамической информации о выполнении каждого теста





Подход БаллаАнализ изменений на уровне узлов CFG программыСвязь элементов программы с тестами задается на уровне CFG наоснове динамической информации о выполнении каждого теста





Подход на основе ASTАнализ изменений на уровне вершин AST программыСвязь элементов программы с тестами задается на уровне AST наоснове динамической информации о выполнении каждого теста




Интеграционное ВРТ

Подход на основе концепции файерволаАнализ изменений на уровне целых модулейСвязь элементов программы с тестами не учитывается




Интеграционное ВРТ

Подход Ротермела-ХарролдАнализ изменений на уровне узлов межмодульного CFGСвязь элементов программы с тестами задается на уровне CFG наоснове динамической информации о выполнении каждого теста




Системное ВРТ

Какие варианты Вы можете предложить?

Вспомните, что системное тестирование – это модульное тестирование«очень большого и сложного ящика»

Какие варианты Вы можете предложить теперь?


Интеграция тестирования в процесс разработки ПО Управление регрессионными тестами

Управление регрессионными тестами

Проблема №2Как управлять набором регрессионных тестов?

Когда и как добавлять в набор новые тесты?Когда можно удалять старые тесты?



Добавление новых тестов

Когда надо добавлять новый регрессионный тест?

Когда в ПО появилась новая функциональностьКогда в ПО была исправлена ошибкаКогда мы хотим улучшить тестовое покрытие ПОКогда мы можем себе позволить добавить новыйнеповторяющийся тест



Добавление новых тестов

С течением времени число тестов увеличиваетсяЧем больше тестов, тем лучше тестовое покрытиеПроблемы начинаются, когда тестов становится слишком много

Что такое «слишком много»?



Удаление старых тестов

Когда можно удалять старый тест?

Никогда

Когда тест дублирует другие тестыКогда тест не улучшает тестовое покрытиеКогда тест ни разу не обнаружил ошибки за все времятестированияКогда тест обнаруживает такие же ошибки, как и другие тесты



Приоритизация регрессионных тестов

Проблема №3Как запускать регрессионные тесты?

Взяли имеющийся набор тестов и запустили их

Такой подход может не всегда нас устраиватьЧто мы можем изменить?




Мы можем изменить порядок, в котором мы запускаемрегрессионные тестыЗачем?

Чем раньше мы узнаем о том, что в ПО появилась регрессионнаяошибка, тем скорее мы сможем приступить к ее исправлениюЧасто причиной непрохождения различных (напрямую несвязанных друг с другом) тестов является одна и та же ошибка вПОИногда время на тестирование является ограниченным, инеобходимо найти наибольшее число ошибок с учетом всехограничений

Как мы можем приоритизировать регрессионные тесты?




При помощи интуицииПодход работает, если у Вас хорошая интуицияКроме интуиции можно использовать имеющийся опыт разработкиПО

На основе знаний о тестовом покрытии ПОСперва выполняются тесты, которые имеют наибольшее покрытиеПОСперва выполняются тесты, которые покрывают более важныекомпоненты ПО

На основе истории разработкиПриоритет отдается тестам, которые чаще других обнаруживалирегрессионные ошибкиПервыми выполняются тесты, проверяющие корректность работынаиболее «проблемных» компонентов ПО




Случайным образомПодход перекликается со случайным ВРТЕсли мы можем случайным образом поменять порядоквыполнения тестов, то почему бы это не сделать?

На основе характеристик тестовПервыми выполняются тесты с наименьшим временем выполненияПриоритет отдается тестам, которые наиболее активно работают сокружением программной системы



Анализ результатов регрессионного тестирования

Проблема №4Что делать с результатами регрессионного тестирования?

Если все тесты проходят – все хорошо

Если тест не проходит – то все зависит от того, по какой причинеон не проходит

Варианты?




В тестируемом модуле есть ошибкаОшибку необходимо локализовать и исправитьПосле исправления требуется выполнить повторное РТ

Входные тестовые данные больше не являются корректнымиНапример, была изменена спецификация модуляНеобходимо либо обновить тест, либо удалить его

Ожидаемые выходные данные изменилисьОпять же, была изменена спецификация модуляНеобходимо обновить тест




Часто довольно сложно понять, о какой именно ситуации идетречь в каждом конкретном случае

Особенно если мы тестируем модули со сложнойфункциональностьюВ этом нам нисколько не помогает проблема рассинхронизацииспецификации и тестов

Как обстоит дело с РТ/ВРТ на практике?


Интеграция тестирования в процесс разработки ПО РТ на практике

РТ на практике

РТ используется очень частоTDDAgile DevelopmentRUP

ВРТ практически не используется

Почему?




Крайняя сложность выбора регрессионных тестовОпасность пропустить регрессионную ошибку при использованиинебезопасного ВРТСтрах перед использованием «непонятной» технологииПростота экстенсивного пути решения проблем РТ

Отсутствие инструментальной поддержкиДо недавнего времени




Сложность получения динамической информации о покрытиитестами компонентов программы

Требуется выполнить инструментирование ПО дополнительнымитрассирующими вызовамиЖурналирование особого вида

Какие сложности могут при этом быть?


Будущее тестирования


1 Прелюдия



4 Homework



7 Homework


9 Будущее тестированияУровни тестированияОткрытые проблемы в тестировании ПО


Будущее тестирования Уровни тестирования

Уровни тестирования

Уровень 0Тестирование ничем не отличается от отладки

Уровень 1Цель тестирования – доказать корректность программы

Уровень 2Цель тестирования – доказать, что в программе есть ошибки

Уровень 3Цель тестирования – увеличить качество ПО


Будущее тестирования Уровни тестирования

Уровни тестирования

Уровень 4Тестирование – это одна из частей процесса разработки ПО

Подавляющее большинство компаний находятся на уровнях 0 и 1«Monkey testing»Цена/качество

Некоторые компании «доросли» до уровней 2 и 3Тестирование не является часть процесса разработкиВо главу угла ставится непосредственно разработка ПО


Будущее тестирования Открытые проблемы в тестировании ПО

Открытые проблемы в тестировании ПО

Как тестировать «сверх-высоконадежное» ПО?

Можно ли автоматизировать генерацию тестов?

Как перейти к активному использованию ВРТ?

Как оценивать полноту тестирования в промышленных проектах?

Как использовать результаты научных исследований на практике?


Будущее тестирования Открытые проблемы в тестировании ПО

Революция в тестировании

Тестирование должно стать неотъемлимой частью разработки ПО


softwaretesting102 МаратАхин 2011kspt.icc.spbstu.ru/.../software-testing-102v2.pdf ·...

Documents