какие вы знаете методы генерирования тестов
Комбинаторное тестирование: генерация тестовых данных и не только
Хотя популярность buzzword «pairwise» уже не та, на собеседованиях до сих пор задают вопрос о том, что представляет собой эта техника тест-дизайна. Однако, далеко не все тестировщики (как те, кто приходят на собеседование, так и те, кто его проводят) могут четко сформулировать ответ на вопрос, зачем нужны комбинаторные техники в общем и pairwise в частности (подавляющее большинство ошибок, все же, находятся на атомарных значениях параметров и не зависят от других). Простой ответ на этот вопрос, на мой взгляд — для нахождения багов, возникающих вследствие явных и неявных зависимостей между параметрами. Для простых случаев техника вряд ли принесет серьезную пользу, поскольку их можно проверить вручную, а для большого числа параметров и сложных зависимостей между ними количество тестов, скорее всего, будет слишком велико для ручного тестирования. Потому основное применение комбинаторных техник (и соответственно, инструментов, осуществляющих генерацию комбинаций параметров) — автоматизированное составление наборов тестовых данных по определенным законам.
Большинство инструментов для генерации комбинаторных тестов умеют выдавать результат в виде файла с данными, который может быть передан на вход соответствующим автотестам. Такой пример (используется инструмент PICT) и будет рассмотрен ниже.
Пример 1. Серия и номер паспорта
Аналогично можно составить негативные тесты (PICT позволяет пометить их специальным символом “
“).
Модель 2
Часть результатов моделирования
Из этих файлов потом можно будет читать построчно (разделитель — знак табуляции) и заполнять поля в приложении.
Пример 2. Увеличение тестового покрытия с помощью дополнительного параметра
Иногда баги, связанные с валидациями, зависят от того, каким образом пользователь вводит невалидные данные: с клавиатуры (физической или экранной), с помощью контекстного меню копирования-вставки, горячих клавиш, перетаскивания выделенного текста. Например, часто перетаскивание текста не обрабатывается клиентской валидацией, если таким образом вводятся некорректные данные. Способ ввода можно ввести в модель в качестве дополнительного параметра и учесть его при составлении автотестов.
Модель 3
Часть результатов моделирования
Пример 3. Тесты для систем принятия решений, валидация требований
Для систем принятия решений иногда составляются исчерпывающие тестовые наборы, которые потом можно использовать не только для тестирования, но и для валидации требований. Применяя последовательно правила системы к каждому тесту, можно посмотреть, не получаются ли противоречивые результаты.
Валидация требований — очень немаловажная часть тестирования в данном случае, поскольку можно обнаружить скрытые противоречия. Инструмент генерации комбинаторных тестов позволит не только составить тесты, но и задать условия, накладываемые на входные данные. Если эти условия делают какие-то из возможных данных недостижимыми, инструмент укажет на это, что может послужить сигналом тщательной проверки требований на непротиворечивость.
Модель 4
Реакция инструмента на противоречивые требования
В данной модели есть противоречивые требования, которые отсекают значение WORK: >=11, и оно не появляется ни в одном из тестов. К сожалению, инструмент не дает ответа на вопрос, какие именно условия вызывают противоречие, только показывает, какое значение исключено из тестов. Однако, этой информации может быть достаточно, чтобы выделить из всего массива ограничений те, что влияют на этот параметр, и проанализировать их на предмет противоречивости.
Исчерпывающий набор тестов в дальнейшем может быть использован для техники тест-дизайна «причина-следствие».
Пример 4. Формирование параметров окружений для конфигурационного тестирования
Инструменты для комбинаторного тестирования позволяют также составлять список возможных конфигураций, который потом можно отсортировать по популярности использования, вычеркнуть неподходящие и т.д. Если не обязательно проводить все тесты для каждой из конфигураций, можно поделить их равномерно между выбранными окружениями, добавив окружение в качестве еще одного параметра для генерации тестовых данных (так, как это делалось в примере со способом ввода данных).
Модель 5
Результаты моделирования
Автоматическая генерация тестовых скриптов с помощью нейронных сетей
В последние годы использование технологий Deep Learning позволило достичь значительного прогресса в таких областях, как распознавание образов, автоматический перевод и др. Этот успех, а также разработки в области беспилотных автомобилей и достижения компьютера в игре GO, позволили фантазировать о том, что Искусственный Интеллект скоро будет делать ту работу, которую сейчас выполняют люди, и будет претендовать на их рабочие места.
Повсеместная замена людей на роботов — процесс увлекательный, но не быстрый. Однако уже сейчас можно использовать возросшие вычислительные мощности компьютеров для того, чтобы облегчить решение задач, с которыми люди сталкиваются каждый день. Например, процесс написания программ. Использование систем, которые облегчают процесс программирования, не является чем-то исключительным, любая среда разработки предоставляет множество таких инструментов.
В этой статье представленна технология, помогающая программисту написать тест на основе модуля на языке Java. Технология позволяет значительно сэкономить время по сравнению с написанием теста вручную.
Тесты
В процессе создания программного модуля мы всегда хотим быть уверены, что запрограммированный функционал соответствует нашим требованиям. Для того чтобы знать, что реальное поведение созданной нами программы соответствует ожидаемому результату, используются тесты.
Необходимость, все плюсы и минусы написания тестов перечислены здесь. Однако несомненно то, что написание тестов требует значительного времени (исследования показывают, что разработчики тратят до 30% времени на создание тестов). Кроме того, эта деятельность не развивает функциональность основного программного модуля, поэтому логично, что многие команды стараются избежать написания тестов. С другой стороны, поддержка старого функционала и программирование нового сильно осложняются без использования тестов.
В данной статье мы обсуждаем технологию автоматической генерации тестов. При синтезе тестов мы будем использовать Gherkin-нотацию.
Пример теста на русском языке с использованием Gherkin:
BDD, TDD
Техники TDD и BDD подразумевают, что тест пишется до начала разработки самого тестируемого модуля (https://ru.wikipedia.org/wiki/Разработка_через_тестирование),
Не обсуждая плюсы и минусы подхода TDD и BDD, нужно сказать, что в жизни очень часто встречаются ситуации (а, возможно, таких случаев большинство), когда тесты пишутся после готовности модуля, или тесты не пишутся вовсе. Это приводит к тому, что код становится нечитаемым и сложно поддерживаемым, приводя, в частности, к феномену legacy code.
Таким образом, мы предлагаем возможность синтезировать тест и описание кода в формате BDD на основе готового кода — в том случае, если тестов вообще не было или тесты собирались писать после создания программного модуля.
Синтез
Процесс создания тестов начинается с анализа готового программного модуля. В данный момент мы работаем с классами, написанными на Java. Общая схема работы такая — вначале мы собираем логи и информацию о выполнении программного модуля, затем на основе этих логов обучаем нейронную сеть, далее используем нейронную сеть для генерации готовых тестовых скриптов.
Сбор логов
Допустим, у нас есть модуль, обслуживающий клиентский банковский счет.
Мы собираем логи на каждом шаге программы, начиная с информации об input и output, и заканчивая изменениями переменных
Сам сбор происходит следующим образом:
Мы берем инпуты — это могут быть данные из access логов, или варианты, предоставленные программистом, или автоматически сформированные данные с помощью различных генетических или рандомных механизмов (Evosuite, Randoop).
В особых случаях мы можем оставить модуль сбора логов в продакшене, но в общем случае это не рекомендуется.
Обучение нейросети
Обучение нейронной сети происходит в парадигме Neural Programmer-Interpreters.
NPI работает так: на основе входных данных (на картинке, “previous NPI state”, “environment observation”, “input program”) предсказывает команда (“output program”).
Умея распознавать environment для предскзывания простых программ (операции сложения, ссотировки), программа может предсказывать Gherkin нотацию для этих данных. Качество использования NPI зависит как от возможности обрабатывать определенные входные данные, так и от развития архитектуры нейросети.
Таким образом, обученная нейросеть решает традиционную для программного синтеза задачу — как найти правильную программу (Gherkin нотацию, тест-кейс) для текущих входных данных (env1’).
Генерация скриптов.
На основе обученной нейросети генерируются тест-кейсы. В самом простом случае — списки данных, которые прошли валидно, и списки данных, которые валидацию не прошли.
Готовые скрипты можно редактировать с учетом финальных требований. Тесты Gherkin написаны на “естественном языке”, что подразумевает возможность прочтения и редактирования этих тестов всей командой, как теми, кто писал код, так и теми, кто не имел отношения к разработке модуля.
При каждом выполнении тесты будут проверять те условия, которые в них закодированы. В том случае, если функционал тестируемого программного модуля изменился, нейронную сеть можно обучить повторно для генерации новых тестов.
Выполнение тестов на языка Gherkin производится на тестовом фреймворке Cucumber.
Фреймворк поддерживает автоматическое выполнение скриптов при сборке с помощью Maven.
Также Cucumber интегрируется с другими инструментами continuous integration, такими как Jenkins и прочее.
Генерация тестовых скриптов, ограничения
У автоматического генератора есть сразу несколько ограничений. Все они обусловлены тем, что программа не «учится» программировать или «понимать» алгоритмы. Цель программы — уметь сопоставлять понятные ей виды входных данных с выходными данными, и подбирать лейблы, что является простым случаем conditional program generation:
Простые кейсы
Не обладая интуицией или глубоким пониманием логики работы программы, система может выявлять только простые случаи сбоев программы (например, параметры которые приводят к сообщениях об ошибках), в то же время остаются кейсы, которые могут быть выявлены только программистом.
Ограниченный набор логируемых параметров
Легко логировать и анализировать нейросетью примитивные типы (строчки, цифры), сложнее логировать и анализировать объекты.
Выявление простых взаимосвязей
Соответственно, легко выявлять простые взаимосвязи в простых данных. Все вышеперечисленное подразумевает, что, на данный момент, валидация и доработка автоматических тестов происходит вручную.
Перспективы
Главное направление развития системы — увеличение количества и сложности распознаваемых паттернов.
Текст книги “tестирование dot com”
Автор книги: Роман Савин
Жанры:
Интернет
Прочая компьютерная литература
Текущая страница: 10 (всего у книги 17 страниц)
в. Программы для тестирования скорости и надежности
О таком ПО мы уже говорили. И так как stress/load/performance
testing – это песня не нашего черно-сероящичного репертуара,
петь, т.е. говорить, о них больше не будем.
г. Прочие программы
Это, например, “Проверяльщики линков” (link checkers).
Классификация видов тестирования
Здесь ручной подход сочетается с автоматизированным. Напри-
мер, с помощью тула я создаю новый эккаунт и потом вручную
генерирую транзакцию покупки.
8. По степени подготовки к тестированию
• тестирование по тест-кейсам (documented testing);
• интуитивное тестирование (ad hoc testing).
Здесь все просто. Есть тестирование по тест-кейсам, а есть тести-
рование ad hoc (лат. – для этой цели, читается как «эд-хок»), т.е.
мы просто интуитивно роемся в ПО, пытаясь найти баги. Интуи-
тивное тестирование, как правило, применятся:
• тестировщиком в качестве теста приемки и/или теста сдачи
(если тест-кейсы для них не формализованы в документации);
• тестировщиком в качестве успокаивающего для сердца в
довесок к документированным тестированию новых функ-
циональностей и регрессивному тестированию;
• тестировщиком, который только что пришел в компанию,
где код уже написан и нужно срочно все протестировать;
• когда бухгалтерия и менеджмент протягивают тестиров-
щикам руку помощи перед релизом;
• в других случаях, когда нет тест-кейсов.
Нужно отметить, что эд хок-тестирование часто дает поразитель-
ные результаты: бывает, исполняешь только что пришедшие в
голову сценарии, которые и не снились при подготовке к тестиро-
ванию, и находишь дородные, розовощекие и ухмыляющиеся баги.
Краткое подведение итогов
1. Мы классифицировали основные виды тестирования в интернет-
2. Мы узнали о трех основных подходах к тестированию: “Черный
ящик”, “Белый ящик” и “Серый ящик”. Водораздел между ними
лежит в плоскостях степени знания о внутренностях системы и
ориентированности на надежды и чаяния конечного пользователя.
3. Мы узнали, что паттерн поведения пользователя составляют
сценарии и данные для них (хотя мы стали все это вместе на-
Тестирование Дот Ком. Часть 2
4. Мы узнали об основных источниках знания о потенциальных
паттернах поведения пользователей.
5. Мы узнали концепцию тестировочного покрытия.
6. Мы узнали, что количественное и качественное тестирование
обеспечивается путем слияния в оргазме черноящичных и бело-
ящичных методик тестирования.
7. Мы узнали, что мало быть хорошим человеком. Надо еще по-
нимать, какой ожидаемый вывод является тем самым ожидае-
мым результатом, который приведет нас к реальному тести-
8. Мы поняли разницу между тестированием интерфейса поль-
зователя и тестированием с помощью интерфейса пользо-
9. Мы удивились, узнав, что код, прекрасно работающий функ-
ционально, может привести к сбою в работе веб-сайта (про-
10. Мы прочувствовали, что несовместимость – это проблема не
только человеческих отношений, но и отношений нашего сайта с
“железом” и ПО пользователя.
11. Мы запомнили, что, как правило, позитивные тесты исполняются
12. Мы прошли шаг за шагом от компонентного до системного тес-
13. Мы разобрались в видах автоматизации.
14. Мы отметили, что интуитивное (эд хок) тестирование иногда
приносит превосходные результаты.
Задание для самопроверки
Приведите, пожалуйста, классификацию видов тестирования с оп-
ределением каждого из них.
ПОДГОТОВКА К ТЕСТИРОВАНИЮ
И ПРАКТИЧЕСКАЯ МЕТОДОЛОГИЯ
ЖИЗНЬ ЗАМЕЧАТЕЛЬНЫХ БАГОВ
СТАДИЯ 1: ТЕСТИРОВАНИЕ НОВЫХ ФИЧА
(New Feature Testing)
СТАДИЯ 2: РЕГРЕССИВНОЕ ТЕСТИРОВАНИЕ
ПОДГОТОВКА К ТЕСТИРОВАНИЮ
НИГИЛИСТИЧЕСКИЙ НАСТРОЙ И
• МЕНТАЛЬНЫЙ НАСТРОЙ ТЕСТИРОВЩИКА
• МЕТОДЫ ГЕНЕРИРОВАНИЯ ТЕСТОВ
• МЕТОДЫ ОТБОРА ТЕСТОВ
П одготовка к тестированию с точки зрения тестировщика
1. Написание новых тест-кейсов и/или
2. Изменение существующих тест-кейсов и/или
3. Удаление существующих тест-кейсов.
Иногда требуется создание/модификация тест-тулов, но об этом
мы здесь говорить не будем, так как фактически тест-тулы – это
чистой воды программирование, облегчающее исполнение тест-кейсов.
Кстати, дни начала и завершения ПОДГОТОВКИ к тестированию указаны в
расписании тестирования (test schedule), которое является публичной (в
пределах компании) информацией. Таким образом, тестиров-щик может
рассчитывать свои силы, т.е. уходить с работы в 4 дня или 4 утра в
зависимости от достигнутого им прогресса.
Многие вещи, о которых мы будем говорить, могут показаться теоретиче-
ски простыми, но пусть эта псевдопростота не вводит вас в заблуждение.
Приведем аналогию с шахматами. Взрослому человеку нужно 5 минут, чтобы
запомнить правила (как ходят/бьют пешки и фигуры, правила рокировки и
пр.), а для того чтобы стать мастером игры, нужны сотни сыгранных партий.
То же самое и с методами тестирования: понять базовые элементы и
концепции особого труда не составит. Для того же, чтобы стать эффек-
тивным профессионалом, понадобятся месяцы и годы практического
применения этих элементов и концепций на реальном ПО.
Тестирование Дот Ком. Часть 3
Для тестировщика подготовка к тестированию – это наибо-
лее сложный, творческий и интересный процесс.
Венцом этого процесса являются тест-кейсы, которые после их
исполнения на стадии “Исполнение тестирования” смогли бы
превентировать встречу пользователей и багов.
Мы – ловцы. И тест-кейсы – это сеть, которую мы
• плетем (подготовка к тестированию) и
• используем (исполнение тестирования).
Как мы помним, тест-кейс содержательно состоит по крайней мере
из ожидаемого результата, но, как правило, это комбинация:
И те, и другие, и третьи можно почерпнуть из множества источ-
• других кладезей информации.
Вопрос: что отличает тестировщиков от других участников про-
цесса разработки ПО, которые тоже могут придумать тест-кейсы,
основываясь на спеках, опыте, эксплоринге и т.д.? Ответ:
отличают нас две профессиональные вещи:
• инструментарий, т.е. прикладные знания.
Сначала о ментальном настрое замолвим мы слово.
Ментальный настрой тестировщика
Помните наблюдение, что, попадая в лес,
• плотник видит доски,
• художник – пейзажи, а
• биолог – материал для диссертации?
Нигилистический настрой и практическая методология
• для пользователя код – это инструмент для выполнения
каких-либо неотложных задач (например, покупки устрой-
ства для подзаводки автоматических часов);
• для продюсера – реализация гениальных идей менедж-
мента, увековеченных в спеке;
• для программиста – кусок хлеба с черной икрой;
• для тестировщика код – это убежище багов.
Постулат «Software has bugs» («ПО содержит баги») – это не
выдумка лицемеров и лжесвидетелей, а вселенский закон, кор-
мящий тестировщиков, а следовательно, и их жен, детей, говоря-
щих попугаев и лысых кошек. Не будем же лишать наших домо-
чадцев лакомого куска и раскроем свое сердце истинной сути ве-
щей, заключающейся в том, что ПО своей природе – это баго-
содержащее и неблагонадежное существо.
код – это убежище багов.
Итак, навесив ярлыки, идем дальше.
Как известно, ищущий да обрящет (из этого не следует, что не
ищущий не сможет обрести. Однако логичнее предположить, что
именно тот, кто ищет, найдет больше. По крайней мере, как
Тестирование – это ПОИСК багов.
«ПОИСК» – это ключевое слово, точно раскрывающее смысл
нашей профессии, которая принципиально требует от нас, как и
от сыщиков, и прикладных знаний, и интуиции, и ментальных
Концепция «поиска багов» как пути, по которому идет тестировщик для
превентирования свидания пользователя и багов, начисто отметает
идею о том, что тестировщик, подобно ОТК (отдел технического кон-
троля в СССР), сертифицирует продукт на качество и ставит штамп
«Проверено, багов нет». Ничего мы не сертифицируем, да и штампов
у нас нет, кроме тех самых. в паспорте.
Еще раз: основа работы тестировщика – это поиск багов.
Тестировщик не занимается поиском доказательств того, что ПО
Тестирование Дот Ком. Часть 3
Мы должны настроить себя на поиск багов в коде, который
является убежищем этих самых багов. Nice and simple.
Основой такого настроя – ментального настроя тестировщи-
ка – является деструктивное мышление, полное подозритель-
ности, недоверия и априорного отрицания даже потенциаль-
ного наличия добродетелей – все в отношении ПО. Мы долж-
ны твердо верить в то, что «был бы код, а баги найдутся».
Пытливый ум внимательного слушателя сразу же сгенерирует
вопрос, на который я тут же отвечу.
Вопрос: «О каком деструктивном мышлении мы можем гово-
рить, если у нас есть такое понятие, как “позитивное тестирова-
ние”, и позитивные тест-кейсы настолько важны, что мы испол-
няем их в первую очередь?»
Ответ: “Позитивное тестирование и принцип первичного испол-
нения позитивных тест-кейсов – это технический аспект. Де-
структивность в мышлении – это аспект ментальный. Даже если
мы создаем тест-кейс с позитивным сценарием, мы должны ис-
кать способ, чтобы обнаружить баги”.
Дорогие друзья! Взращивайте и лелейте в себе неисправимый пес-
симизм в отношении идеи о коде, свободном от багов.
Смотрите на код как на виртуальную вещь, которая в процессе
тестирования послужит еще одним доказательством постулата о
несовершенстве мира. Если вы настроите себя на деструктив-
ное мышление в отношении кода, то ваша интуиция вклю-
чится на всю катушку и прекрасные идеи для тест-кейсов
будут стаями роиться в ваших головах, как только вы прочи-
Парочка сладких десертов
– Скажите, а исполнится ли загаданное желание, если я загадаю его,
сидя между двумя программистами?
– Конечно, исполнится, но. будет глючить!
Хирург, инженер и программист сидят в баре и обсуждают, чья про-
фессия является древнейшей:
Хирург: Моя профессия является древнейшей, потому что Богу нужны
были знания по хирургии, чтобы извлечь из Адама ребро.
Инженер: Но еще до этого был хаос, и, чтобы сделать мир из хаоса,
Богу нужны были инженерные знания.
Программист: Ха! Кто же, как вы думаете, создал весь этот хаос?
Нигилистический настрой и практическая методология
Теперь, настроенные и решительные, переходим к профессио-
нальным прикладным знаниям, а именно к методологии соз-
дания тест-кейсов (testcase design methodology) (далее – мето-
В одной из прошлых бесед мы говорили
о первой части методологии – формальной стороне построе-
Сегодня же речь пойдет
о второй ее части – содержательной стороне тест-кейса.
Искусство создания содержательной части тест-кейсов заключа-
ется в нахождении тех “золотых”
которые при исполнении тестирования помогли бы обнару-
жить больные, багосодержащие места тестируемого ПО.
Какие два этапа составляют процесс, называемый “выбор”?
1. Сначала нам нужно увидеть, что имеется в наличии.
2. Затем, используя некий критерий (-ии), мы выбираем или
Например, выбирая щенка,
1) мы должны увидеть одного или больше щенков (что имеется в на-
2) посмотреть, как весело он (они) бегает, как блестят его глазенки
и пр. И посмотрев, решить – брать или не брать.
Подход к выбору сценариев концептуально схож:
1. Что имеется в наличии, мы видим после использования
методов генерирования тестов (methods of test generation);
2. Орудиями отбора являются методы отбора тестов (test se-
Методы генерирования тестов:
1. Черновик-чистовик (dirty list-white list);
2. Матричная раскладка (matrices);
3. Блок-схемы (flowchart).
Тестирование Дот Ком. Часть 3
Методы отбора тестов:
1. Оценка риска (risk estimate);
2. Эквивалентные классы (equivalent classes);
3. Пограничные значения (boundary values).
Методы генерирования тестов
1. Черновик-чистовик (dirty list-white list).
2. Матричная раскладка (matrices).
3. Блок-схемы (flowchart).
Это самый простой и практичный метод. Суть проста. Два этапа:
а. Черновик (dirty list)
В процессе (и/или после) прочтения спека, эксплоринга ПО и/или
получения информации о ПО другим способом, не анализируя и
отдавшись вдохновению и фантазии, мы просто набрасываем на
лист бумаги (или в файл Ворда), являющийся черновиком (dirty
list), ВСЕ идеи, связанные с тестированием, которые только могут
прийти в голову, – идеи в самом широком смысле этого слова,
включая идеи для тест-кейсов, сценарии, отдельные элементы
сценариев (шаги и/или данные), ожидаемые результаты, вопросы
для выяснения у продюсера и пр.
Еще раз: ВСЕ идеи – даже самые на первый взгляд далекие от
здравого смысла. Локальный мозговой штурм.
б. Чистовик (white list)
Затем мы начинаем анализировать написанное (и, если нужно,
получать ответы на вопросы) и переносим на чистовик вещи,
имеющие право на жизнь. Право на жизнь определяется на осно-
вании информации из спека, общения, интуиции, критериев от-
бора тестов, разговора с программистом и пр. При переносе на
чистовик мы также уточняем наши идеи и группируем их (на-
пример, по позитивности и негативности; по функциональным
направлениям и т.п.). Таким образом, как правило, первый чисто-
вик превращается во второй черновик, и мы берем следующий
лист бумаги и, надеясь, что он будет чистовиком, начинаем пере-
Нигилистический настрой и практическая методология
носить на него наши идеи и т.д. В итоге в один из светлых май-
ских дней мы все-таки получаем чистовик. На основании мате-
риала из чистовика мы пишем тест-кейсы.
Сейчас рекомендую вам немедленно взять ручку, лист бумаги и
потратить 15 минут на генерацию черновика по тестированию
автомата для продажи банок с колой (любимый тест рекрутеров
из “Майкрософта”). Начинаем:
• Проверить, что покупателю выдается именно та банка, ко-
• А что, если покупатель нажмет на кнопку два раза?
• А что, если покупатель попробует наклонить аппарат, что-
бы банки посыпались как из рога изобилия?
• Проверить, что правильно выдается сдача.
• Какая реакция на монетку иностранного государства?
После того как черновик готов, потратьте 15 минут на составле-
ние чистовика и затем 30 минут на составление тест-кейсов по
• сценарий (шаги и данные) и
Ручаюсь, что этот час окупится сторицей, чем бы вы ни занима-
лись в жизни, и вы ни разу не пожалеете, что потратили 60 минут
времени на подобный тренинг.
2. МАТРИЧНАЯ РАСКЛАДКА
Давайте без прелюдий и патетики перейдем к примеру.
Украдем макет первой страницы регистрации из цикла разра-
Сделаем матричную раскладку.
Тестирование Дот Ком. Часть 3
Этап 1. Набросок элементов (табл. 1)
Таким образом, у нас получилось 3 подгруппы:
2. “Индекс действующий?” (существует ли адрес с таким ин-
дексом в Российской Федерации?)
3. “Значения индекса”.
Каждый из элементов имеет свой уникальный ID, например, эле-
мент, когда пользователь вводит в поле индекса 6 цифр, мы обозна-
чили как Индекс_эл_005 (элемент номер 005 страницы с индексом).
Буквенная часть ID (Индекс_эл) – это вещь произвольная. Про-
сто мне кажется, что для разбираемого примера это название
интуитивно и логично.
Прошу заметить, что мы набросали элементы как позитивных,
так и негативных сценариев.
Нигилистический настрой и практическая методология
Этап 2. Комбинация элементов (табл. 2)
Теперь мы начинаем комбинировать элементы между собой.
индекс действителен, 6 цифр действую-
щего российского индекса: 119602
индекс недействителен, 6 цифр: 000000
индекс недействителен, 5 цифр: 11960
индекс недействителен, 7 цифр: 1196021
индекс недействителен, буквы: 1196о2
(буква “о” вместо нуля)
индекс недействителен, специальные
(символ “(” вместо девятки)
индекс недействителен, пробел
между цифрами: 1196 02
Как видно, мы скомбинировали элементы табл. 1 в сценарии.
У каждого из сценариев есть свой уникальный ID, например сце-
нарий, когда в поле индекса не вводится никакого значения, про-
ходит под штампом Индекс_ком_008 (комбинация номер 008 стра-
Кстати, обратите внимание:
• в данном конкретном примере мы играем с частью сценария под
названием «данные»(варианты индекса),
• сначала расписываем позитивные, а затем негативные сценарии,
• сценарий Индекском 008 не был комбинацией элементов табл. 1,
а напрямую следовал из элемента Индекс_эл 002.
Тестирование Дот Ком. Часть 3
Вопрос: зачем мы присваивали уникальный ID каждому из эле-
ментов в табл. 1, если мы их не используем? Ответ: иногда в
табл. 2 вписывается не содержание элементов (как мы это
сделали), a ID. Кроме того, если у элемента есть ID, то это просто
• при обсуждении, когда у вас и вашего коллеги есть по экземпляру
• когда я рассказываю вам о матричном методе.
Итак, у нас есть 8 сценариев для страницы, когда пользователь
должен ввести некое значение (либо пустое место) для индекса
места жительства. Мы можем сразу же, используя эти сценарии,
написать тест-кейсы. Ожидаемым результатом для всех, кроме
Индекс_ком_001, будет перезагрузка страницы с индексом с со-
общением об ошибке:
«Введите действительный российский индекс». При этом текст
“Индекс места жительства*” будет красного цвета.
Для ИндекскомОО 1 ожидаемым результатом будет следующая
Теперь вспомним об этапах покупки книг:
а. Регистрация (если нет счета пользователя).
б. Заполнение книгами виртуальной корзины.
в. Редактирование корзины: какие-то книги может убрать,
каких-то купить больше, чем одну.
Нигилистический настрой и практическая методология
г. Указание деталей доставки.
Так вот мы придумали сценарии только для первой части нашей
версии регистрации (вторая часть – это страница с именем, фа-
милией, е-мейлом, паролем и подтверждением пароля). У второй
части тоже будут свои табл. 1 и табл. 2.
Более того, у каждого из остальных этапов тоже могут быть
свои одна или более связок табл. 1 – табл. 2.
Черноящичное тестирование веб-проекта – это манипуляции
с одной или больше веб-страниц, зависимых друг от друга,
определенная комбинация которых ведет нас к определенному
Таким образом, иногда появляется потребность
• в табл. 3, когда сценарии из табл. 2 становятся элементами
более сложных сценариев,
• в табл. 4, когда сценарии из табл. 3 становятся элементами
еще более сложных сценариев,
иногда в табл. 1 мы сразу отражаем возможные значения для несколь-
ких связанных между собой веб-страниц.
Я знаю, что матричный метод в начале работы по нему кажется
сложным и запутанным. Единственный способ освоить его – это
использовать на практике, что мы с вами сейчас и сделаем.
Однажды в классе по “юниксу” на занятии по теме “Регулярные
выражения” (наука поиска паттернов в тексте) один товарищ
удивительно метко выразил физическое состояние всех студен-
тов: “Это как операция на головном мозге”. Я не удивлюсь, если
в начале использования матричного метода у вас будет схожее
Итак, предлагаю вам сейчас самостоятельно создать табл. 1 и
табл. 2 для второй части регистрации. Также прошу вас написать
тест-кейсы по полной форме на каждый из сценариев первой и
второй частей регистрации.
Тестирование Дот Ком. Часть 3
Одна из прелестей матричного подхода заключается в наглядно-
сти – мы видим перед собой таблицу со структурированными
вариантами сценариев, и нам удобно комбинировать их в более
сложные сценарии или непосредственно переносить их в тест-
Кстати, во многих случаях нет смысла идти дальше табл. 1, например
когда сценарии для тест-кейсов непосредственно вытекают из эле-
ментов табл. 1 или когда сценарии для тест-кейсов можно просто до-
мыслить, скомбинировав в уме элементы табл. 1.
В беседе о продюсерах и вещах, которые им нужно улучшить в
своей работе, мы уже говорили о блок-схемах. Блок-схема – это
графическая презентация некого процесса.
Блок-схемы допускают разные уровни абстракции, например
процесс регистрации можно представить и в таком виде:
Эта блок-схема и ее сестра из беседы о цикле разработки ПО
• похожи тем, что демонстрируют нам логику работы реги-
• различаются тем, что имеют различную детализацию этой
Нигилистический настрой и практическая методология
В своей работе тестировщики используют ту степень детали-
зации, которая нужна для конкретной ситуации: если мы тес-
тируем саму регистрацию, то нам необходима большая степень
детализации (процесса регистрации) по сравнению с ситуацией,
когда нам нужно увидеть место регистрации как часть процесса
Идея о разных степенях абстрагированности раскладки в зави-
симости от того, ЧТО и КАК мы тестируем, напрямую отно-
сится и к черновику-чистовику, и к матричному методу.
Вот элементарные, непробиваемые и вечные формы (блоки) для
составления блок-схем, которых вам будет достаточно в боль-
Точка начала/конца блок-схемы может
содержать название этой точки (например,
название веб-страницы) или просто и со
вкусом величаться “Начало”/”Конец”.
Это любой этап процесса, кроме этапов
начало/конец, решение или перенос.
Решение – некая точка, после которой
возможны, как правило, два варианта раз-
Перенос ставится в том случае, если данное
ответвление процесса представлено (будет
представлено) другой блок-схемой.
Вот несколько рекомендаций по составлению блок-схем.
1. Перед составлением блок-схемы назовите основной про-
цесс, описываемый ею, например «Процесс регистрации».
2. Сначала набросайте путь основного течения процесса, на-
пример, в случае с регистрацией это три блока, показанные
на последней блок-схеме (страница 1, страница 2 и под-
3. Называйте каждый блок кратко и информативно.
4. Приводите ссылки на полезную информацию, например,
см. Спек #9017 – это ссылка на соответствующий спек.
Тестирование Дот Ком. Часть 3
5. Для наглядности презентации старайтесь скомпоновать
блок-схему таким образом, чтобы процесс шел сверху вниз
6. Для превентирования ошибки в толковании избегайте пе-
7. Протестируйте (проверьте) законченную блок-схему на пред-
мет соответствия спеку или другому источнику.
Для тренировки нарисуйте блок-схему следующей ситуации.
Идея: вскипятить чайник.
Вот вам в помощь блоки решений, которые предстоит разложить
1. Вода в чайнике есть/нет.
2. Плита включена да/нет.
3. Чайник кипит да/нет.
Для совершенствования в составлении блок-схем очень рекомен-
дую найти ресурсы в Интернете или купить книгу.
Блок-схемы – это визуальные источники идей для тестиро-
как и в случае со всеми методами генерации тестов, процесс
создания блок-схем вызывает рождение множества превосход-
ных идей для тестирования, открывает тестировщику новые
грани ПО и вызывает ряд вопросов, которые не возникли бы
при простом прочтении спека.
теория (простое прочтение спека перед его утверждением) и
практика (работа со спеком при создании тест-кейсов) – это две
На «практике», если спек более или менее сложный, неизбежно воз-
никнет необходимость в уточнениях.
Нигилистический настрой и практическая методология
Знайте, что отвечать на вопросы по спеку – это святая обязан-
Вы имеете право, нет, ОБЯЗАНЫ задать ему ВСЕ вопросы по спеку, ко-
торые у вас возникнут, ибо шкуру будут спускать с вас, а нес него, если
вы из-за неотвеченных вопросов пропустите баги.
Кстати, обязательно сохраняйте всю переписку в отдельном фолдере
(папке) е-мейл клиента (дайте фолдеру наименование (Ю) спека):
вдруг продюсер дал вам уточнение, оно было неверным, вы написали
тест-кейс с ошибкой/не написали тест-кейс вовсе и пропустили серь-
Нет е-мейла – нет доказательств, есть е-мейл – есть доказательства.
Если уточнение по спеку было сделано устно, пошлите е-мейл продю-
серу, где опишите то, как вы поняли уточнение, и спросите “Я правиль-
Если продюсер не отвечает, пошлите ему тот же е-мейл из фолдера е-
мейл клиента «Отправленная почта», чтобы он видел, что уже один
раз проигнорировал ваш запрос.
Если ответа снова нет и продюсер не болен, не уехал на ПМЖ в Австра-
лию, а даже очень здоров, строит дачку в Малаховке, и вы видите его в
столовой каждый день, то просто перешлите последний из е-мейлов
продюсера своему менеджеру и сообщите ему, что не можете рабо-
Менеджер не будет сам говорить с ним, а переправит ваш е-мейл ме-
неджеру продюсеров, чтобы тот спросил у продюсера: “В чем, собст-
венно, дело?” Даю гарантию, через час продюсер сам прилетит к вам,
как ни в чем не бывало хлопнет по плечу, как лучшего друга, и проведет
с вами столько времени, сколько нужно, травя байки и находя удачные
аналогии для того, чтобы вы лучше поняли материал. “Бизнес есть
бизнес”, вы ищете баги и, чтобы быть эффективным, должны по-
лучить всю информацию по спеку.
Теперь суперважная вещь в отношении методов генерирования и
Превосходные результаты дает комбинирование методов.
Например, можно набросать черновик и в качестве чистовика создать
табл. 1, сгруппировав в ней идеи из черновика.
С другой стороны, имея табл. 1, табл. 2 и т.д., можно использовать метод
черновик-чистовик, чтобы выделить сценарии из элементов табл. 1,
С третьей стороны, можно создать блок-схему, чтобы нагляднее ви-
деть процессы, описанные в таблицах, и найти новые интересные
В общем бесчисленное множество комбинаций и огромное поле для
творчества! Как мы уже говорили, в тестировании НЕТ ДОГМ
Тестирование Дот Ком. Часть 3
и даже сами основы отрасли знания “Тестирование” постоянно
находятся под обстрелом, так что дерзайте и находите именно те
приемы и методы, которые будут работать для вас в тех ситуа-
циях, в которых вы будете работать.
Методы отбора тестов
1. Оценка риска (risk estimate).
2. Эквивалентные классы (equivalent classes).
3. Пограничные значения (boundary values).
Общая вещь: методы отбора тестов применяются во время
или после генерирования тестов.
1. ОЦЕНКА РИСКА (risk estimate)
Представьте, что вы только что прикупили отель где-нибудь в
горах Сьерра-Невада в Северной Калифорнии. У вас нет опыта
работы менеджером отеля, но вы чувствуете себя абсолютно уве-
ренным в своей новой роли, так как у вас есть высшее образова-
ние в области физики твердого тела и такую фигню, как управле-
ние отелем, вы, конечно, осилите на раз.
К вашему отелю ведут три дороги:
• первая соединяет отель и ответвление скоростной магист-
• вторая соединяет отель и дорогу, ведущую к горнолыж-
• третья соединяет отель и небольшую проселочную дорогу.
по которой ездят в основном местные жители.
Все три дороги имеют одинаковую протяженность.
10 человек уже приехали и 30 человек должны приехать сегодня.
Всю ночь шел снег, и все три дороги замело так, что ни один
джип не проедет ни по одной из них.
У вас есть только одна снегоуборочная машина, и на уборку лю-
бой из дорог уйдет полдня. Так что нужно выбирать, с какой из
Можно подойти к решению этой задачи чисто субъективно.
Нигилистический настрой и практическая методология
Абсолютно очевидно, что по дороге номер 3 могут приехать
только ваши местные кореша
• для игры в покер (но сегодня не день покера – пятница)
• на барбекю (но сегодня не суббота).
Значит, дорога 3 остается в снегу.
Абсолютно очевидно, что дорога номер 2 также не является
приоритетной в расчистке, так как абсолютно очевидно, что 10
Таким образом, наш план:
• посадить отельского “жнеца, швеца и на дуде игреца” за
руль снегоуборочной машины расчищать роад намбер уан:
дорогу к скоростной магистрали;
• вывесить в лобби отеля большой плакат “Дорог на гор за-
крыт. Не ходи, а то хана” для уже вселившихся;
• накормить уже вселившихся бесплатным завтраком (в каче-
Запомним, с какой уверенностью мы говорили себе: “Абсолютно
Давайте перед тем как реализовывать наш гениальный план, ос-
нованный на очевидных вещах, остановимся на минутку у стойки
регистрации и поговорим с менеджером отеля, который прорабо-
Первый вариант разговора
Вопрос: «Что делать, Джеймс?»
Ответ: “Босс, все очень просто. Все, кто уже вселился в отель,
приехали играть в снежки, кататься на беговых лыжах или просто
дышать свежим воздухом. Я это знаю потому, что переговорил с
каждым из них и знаю большинство из них, так как они приезжают
каждый год. Поэтому нет никакого смысла в расчистке дороги
номер 2, все остаются в отеле или развлекаются в его окрестностях.
Я также знаю, что 16 человек из 30 – это компания, которая вы-
едет к нам рано утром из Рино (я вчера говорил по телефону с
одним из них) по этой дороге (показывает на карте), которая пе-
ресекается с дорогой номер 3. Соответственно они прибудут к
нам по дороге номер 3.
Тестирование Дот Ком. Часть 3
Далее, посмотрите на монитор. Где живут 12 из 14 оставшихся
клиентов? Они все живут в Сан-Франциско и окрестностях.
Только что передали по радио, что на единственной скоростной