Тестирование треугольника тест кейсы

Какое-то время назад мы опубликовали тренажер, имитирующий одну из стандартных задач на собеседовании тестировщика: тестирование утилиты, которая выводит данные о треугольниках. Мы решили дать коллегам возможность потренироваться — и не прогадали. Посещаемость сайта в определенные моменты доходила до 400 rps, а всего нашим тренажером воспользовалось больше 7000 уникальных пользователей.

Если Вам не удалось самостоятельно найти все баги, не стоит расстраиваться. У нас есть небольшой, но очень детальный курс по основам тестирования. Подробнее можно узнать по ссылке.

А теперь, как и обещали, выкладываем ответы к этой задаче. Внимание, дальше будут спойлеры. Если вы хотели пройти этот тренажер самостоятельно, пока что дальше лучше не читать.

В тренажере было два типа задач: проверить 12 тест-кейсов из тех, что мы задумали, и найти 4 спрятанных бага.

Как это обычно и бывает, багов оказалось больше, и многие их нашли и прислали репорты. Спасибо вам! Но обо всем по порядку.

Кейсов у нас было задумано 12.

1
Первое, что стоит сделать, увидев любую форму, попробовать просто по ней жмакнуть (засабмитить). Что ожидаем увидеть? Если кнопка сабмита не деактивирована (как в нашем случае), то самое ожидаемое поведение — форма выведет ошибки, сообщая, что не все обязательные поля для ввода были заполнены. Один кейс найден.

2
Второй кейс чем-то похож на предыдущий. Только в этом случае мы не заполняем одно поле (А или B). А остальные заполняем. Почему нельзя оставить пустым только поле C? Расскажем чуть ниже 🙂

3-7
Далее у нас идут позитивные кейсы. Вспоминаем уроки по геометрии, сколько существует треугольников? Нам удалось выделить пять видов: прямоугольный (3, 4, 5), тупоугольный (2, 3, 4), остроугольный (66, 67, 68), равнобедренный (3, 3, 5) и равносторонний (6, 6, 6). Все их можно перебрать, добавив себе пять очков к кейсам.

8
Снова возвращаемся к урокам геометрии. А какого треугольника быть не может? Верно, такого, у которого сумма двух маленьких сторон короче большой стороны (2, 3, 10). Все потому, что стороны в таком случае просто не смогут соединиться. Итак, еще один кейс: «не выполнились условия треугольника».

9
Очередной кейс, попробовать ввести в форму что-то, что никак не может являться сторонами треугольника. Например, буквы q, w, e. Итак, новые кейс найден: это не треугольник.

10
Далее начинается специфика тестирования в целом, и тестирование веб-приложения в частности. Тут, для начала, мы проверяем слишком большое число. Большим числом называем такое, которое больше максимального значения INT. Например, число 4294967295.

11
Два оставшихся кейса посвящены тестированию безопасности. Первый кейс, это проверка на SQL-инъекцию. На самом деле, конечно, писать настоящую инъекцию не надо, главное вообще подумать в эту сторону. Это уже будет означать, что о таком типе уязвимости вы помните. В нашем случае достаточно было ввести в поле такие ключевые слова, как select, or или where.

12
И последний кейс: XSS-уязвимость. О том, что это, можно почитать в нашей группе. Для того, чтобы кейс засчитался, необходимо было ввести тег для JS-кода. Т.е.

Видео:Тестирование треугольникаСкачать

Часть 2: Тестирование простого приложения (Тестирование ПО)

Видео:Примеры тест-кейсовСкачать

Записная книжка рассеянного [в пространстве и времени] программиста

Видео:Тест-кейсы в тестировании / Урок 16 / Тестировщик с нуляСкачать

Часть 2: Тестирование простого приложения (Тестирование ПО)

Видео:Интенсив по тестированию / Тема 5. Тест кейсыСкачать

Оглавление

Видео:Тестировщик с нуля / Урок 8. Тестовая документация. Чек-лист и тест-кейс в тестировании. ПримерыСкачать

Первое приложение

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

Напишем, функцию, которая принимает на вход три стороны треугольника, которые заданы целыми числами и возвращает тип треугольника. Сохраним написанный код в файле triangle.php.

Функция достаточно тривиальна, поэтому мы не будем останавливаться на ее реализации. Нас будет интересовать, как найти в ней ошибки.

Для начала потребуется реализовать механизм, который позволит вводить данные с консоли и получать результат. Сохраним следующий код в файле main.php. Чуть позже вы поймете, почему мы используем разные файлы для самой функции и для кода, который обрабатывает пользовательский ввод.

Код также достаточно тривиален. Теперь мы можем запустить полученное приложение (да, это именно приложение — последовательность инструкций, определяющих процедуру решения конкретной задачи компьютером).

Откроем терминал, перейдем в каталог, с проектом и выполним следующую команду (для того, чтобы все сработало у вас должен быть установлен интерпретатор php в системе).

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

И вот что мы можем увидеть на экране.

Поэкспериментируйте немного с программой вводя разные наборы чисел.

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

Итак. Ниже приведен набор тестовых сценариев, которые должны быть написаны для нашей функции.

1. тест для проверки действительно неравностороннего треугольника (наборы [1, 2, 3], [2, 5, 10] треугольниками не являются).
2. проверка на действительно равносторонний треугольник
3. проверка на равнобедренный треугольник (наборы вида [2, 2, 4] треугольником не являются)
4. как минимум три теста для проверки равнобедренного треугольника, которые представляют собой перестановки одного и того же набора чисел ([3, 3, 4], [3, 4, 3], [4, 3, 3])
5. тест на нулевую длину одной из сторон
6. тест на сторону, имеющую длину меньше нуля
7. проверка набора чисел, в котором сумма длин двух сторон равна третьей
8. тест перестановок для троек чисел из теста 7
9. проверка набора чисел, в котором сумма длин двух сторон меньше третьей ([12, 15, 30])
10. тест перестановок для троек чисел из теста 9
11. проверка на нулевую длину всех трех сторон
12. проверка на передачу нецелочисленных значений
13. проверка на передачу неполного набора значений
14. проверка не только входных данных, но и ожидаемого выходного значения в каждом из тестов 1-13

Если вы не смогли назвать все кейсы, то не пугайтесь. Среднее число тестов, которые называли в разное время опытные разработчики составило 7,8.

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

Это упражнение должно было продемонстрировать вам, что тестирование простых программ наподобие вышеприведенной является отнюдь не тривиальной задачей. А теперь попытайтесь представить себе, насколько трудоемким окажется тестирование, скажем, бухгалтерской программы крупного предприятия, компилятора или же системы управления воздушным движением, объем кода которых может достигать сотен тысяч строк. Еще большие трудности возникают с приложениями, которые написаны с использованием объектно-ориентированных языков (куда входит и php) и подходов. В частности, тесты для подобных приложений должны выявлять ошибки с созданием экземпляров объектов и взаимодействия между ними.

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

Видео:Как писать Тест кейс. На примере проверки поля пароль в форме регистрации.Скачать

Тестируем

Конечно же самым простым решением будет просто закодировать все тестовые случаи для нашего проекта и написать нечто вроде следующего кода (файл triangle_test_simple.php).

И такое часто практикуется. Особенно в среде разработчиков на CC++. На каждый логически связанный набор тестовых случаев создается свой файл. Который содержит множество функций обрабатывающих по одному сценарию каждая.

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

Один из вариантов создания инструмента для работы с подобными тестами вы можете увидеть в файле triangle_test.php. Запустите его и увидите на экране подробный лог тестирования проекта.

Видео:Тест-дизайн в тестировании ПО. Задача "Треугольник" (Илья Комендантов)Скачать

Литература

Видео:Что такое тест-кейсы и как их писать: правила и примерыСкачать

Исходные тексты программ

Видео:Чек-листы и тест-кейсыСкачать

Оглавление

RSS feed This page was generated by GitHub Pages.

Видео:HFLabs Education Day. Тест-дизайн на примере треугольникаСкачать

Правильно пишем тест-кейсы. Памятка начинающему специалисту по тестированию

Когда смотришь на специалистов по тестированию, которые пишут тест-кейсы, то понимаешь, что многие из них даже не имеют представления как это правильно делается. Я не буду приводить множество примеров, которые показывают вопиющие ошибки, а постараюсь озвучить основные принципы того, как надо писать тест-кейсы.

Для начинающих поясним, что такое тест-кейс озвучив определение из глоссария терминов ISTQB:

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

Определение тест-кейса языком обывателя:

Тест-кейс — это чёткое описание действий, которые необходимо выполнить, для того чтобы проверить работу программы (поля для ввода, кнопки и т.д.). Данное описание содержит: действия, которые надо выполнить до начала проверки — предусловия; действия, которые надо выполнить для проверки — шаги; описание того, что должно произойти, после выполнения действий для проверки — ожидаемый результат.

Надеюсь, теперь многим стало понятно, что такое тест-кейс. Теперь перейдём к правилам написания тест-кейсов, которые вырабатывались не один год и показывают свою эффективность до сих пор.

Обязательные атрибуты для заполнения

• Номер тест-кейса — уникальный идентификатор тест-кейса (такие системы как TestRail, TestLink и подобные автоматически присваивают тест-кейсам уникальные номера). Если у вас тысячи тест-кейсов, то при общении с коллегами, вам будет удобнее сообщить номер тест-кейса ссылаясь на него, а не пытаться словами рассказать, где и как найти определённый тест-кейс.
• Заголовок — краткое, понятное и ёмкое описание сути проверки.
• Предусловия — описание действий, которые необходимо предварительно выполнить или учесть, и которые не имеют прямого отношения к проверке.
• Шаги проверки — описание последовательности действий, которые необходимо выполнить для проверки.
• Ожидаемый результат — проверка, которая устанавливает, что мы ожидаем получить, после выполнения определённых действий в соответствующем шаге.

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

Правила написания тест-кейсов

1. Заголовок:
   • должен быть чётким, кратким, понятным и однозначно характеризующим суть тест-кейса;
   • не может содержать выполняемые шаги и ожидаемый результат.
2. Предусловие:
   • может содержать полную информацию о состоянии системы или объекта, необходимом для начала выполнения шагов тест-кейса;
   • может содержать ссылки на информационные источники, которые необходимо изучить перед прохождением тест-кейса (инструкции, описание систем…);
   • не может содержать ссылки на тестируемый ресурс, если у информационной системы более одной среды (прод, тест, препрод…), данная информация должна быть вынесена в инструкцию, и ссылка приложена в предусловии;
   • не может содержать данные для авторизации, данная информация должна быть вынесена в инструкцию, и ссылка приложена в предусловии;
   • не может содержать выполняемые шаги и ожидаемый результат, если нам нужно, чтобы до выполнения шагов проверки у нас была открыта главная страница, то мы в предусловии указываем «открыта главная страница сайта»;
   • не может содержать ожидаемый результат.
3. Шаги проверки:
   • должны быть чёткими, понятными и последовательными;
   • следует избегать излишней детализации шагов. Правильно: «ввести в поле число 12».
     Неправильно: «нажать на клавиатуре на цифру ‘1’, следующим шагом нажать на клавиатуре на цифру ‘2’»;
   • должны использоваться безличные глаголы.
     Правильно: нажать, ввести, перейти.
     Неправильно: нажмите, введите, идите;
   • не должно быть комментариев и пояснений, если есть необходимость привести мини-инструкцию, то оформляем инструкции в базе-знаний и в предусловии ссылаемся на неё;
   • не должно быть жёстко прописанных статических данных (логины, пароли, имена файлов) и примеров, для исключения эффекта пестицида.
4. Ожидаемый результат:
   • должен быть у каждого шага проверки;
   • должно быть кратко и понятно описано состояние системы или объекта, наступающее после выполнения соответствующего шага;
   • не должно быть избыточного описания.
5. Общие требования к тест-кейсам:
   • язык описания тест-кейсов должен быть понятен широкому кругу пользователей, а не узкой группе лиц;
   • тест-кейс должен быть максимально независим от других тест-кейсов и не ссылаться на другие тест-кейсы (лучшая практика, когда зависимостей нет вообще);
   • тест-кейсы группируются в функциональные блоки по их назначению;
   • в тест-кейсах проверяющих работу функционала скриншотов быть не должно, иначе вы будете посвящать сотни часов на изменение всех скриншотов в тысячах тест-кейсах при изменении интерфейса тестируемой программы. Скриншоты могут быть добавлены только в тест-кейсы проверяющие отображение страниц и форм.

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

Примеры

Для наглядности приведу пару примеров. Рассмотрим на примере сайта, на котором вы сейчас находитесь.

Тест-кейс №1. Корректный

Тест-кейс №2. Некорректный

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

Во второй части видео (с 8-й минуты) разбираю на примерах создание тест-кейсов:

Главное в нашем деле практика. Практикуйтесь в написании тест-кейсов.

Если вы будете вести тест-кейсы в таблице (к примеру в Excel), то можете скачать шаблон тест-кейсов. В файле две вкладки. На одной шаблон единичного тест-кейса, а на второй пример порядка размещения группы тест-кейсов.

📺 Видео

Идеальный Баг Репорт в Jira, Тест Кейс в TestRail. Тест Документация. Курс Тестирование ПО Занятие 9Скачать

Тестовое задание на собеседовании тестировщикаСкачать

Урок 42 / QA с Нуля / Пишем тест-кейсСкачать

Как применять техники тестирования, полученные на курсе? (часть 3 - Тест-кейсы)Скачать

Курсы тестировщиков онлайн. Урок 29. Как писать тест кейсы с НУЛЯ. Пример тест кейсаСкачать

Тест-кейсы: полная лекция из ШНАТСкачать

Тест документация, тест планы, тест кейсы by Mikhail PortnovСкачать

Интенсив по тестированию / Тема 6.2. TestRail. Создание тест кейсовСкачать

Как тестировать ИГРЫ? Как писать ТЕСТ КЕЙСЫ? Работаем с TestCaseLabСкачать