Из оригинальной статьи на Wakaleo.com
Обычные отчеты о тестах, генерируемые такими инструментами, как JUnit или TestNG , естественно, фокусируются на том, какие тесты были выполнены, и прошли ли они или нет. Хотя это, безусловно, полезно с точки зрения тестирования, эти отчеты далеко не дают полной картины.
Инструменты отчетности BDD, такие как Cucumber и JBehave, делают еще один шаг вперед, представляя концепцию «ожидающих испытаний». Ожидающий тест — это тест, который был указан (например, в качестве критерия приемлемости для пользовательской истории), но еще не был реализован.
В BDD мы описываем ожидаемое поведение нашего приложения на конкретных примерах, которые в конечном итоге составляют основу «критериев приемлемости» для пользовательских историй, которые мы реализуем. Инструменты BDD, такие как Cucumber и JBehave, не только сообщают о результатах тестов: они также сообщают о пользовательских историях, которые эти тесты подтверждают.
Однако эта отчетность все еще ограничена для крупных проектов, где количество пользовательских историй может стать громоздким. Пользовательские истории не создаются изолированно: скорее, пользовательские истории помогают описывать функции , которые поддерживают возможности, которые необходимо реализовать для достижения бизнес-целей приложения. Поэтому имеет смысл иметь возможность сообщать о результатах тестирования не только на уровне истории пользователя, но и на более высоких уровнях, например, с точки зрения функций и возможностей. Это облегчает отчет не только о том, какие истории были реализованы, но также о том, какие функции и возможности еще предстоит сделать. Пример такого отчета показан на рисунке 1 (или см. Полный отчет здесь ).
Рисунок 1. Отчет об охвате тестированием, в котором перечислены как протестированные, так и непроверенные требования.
В гибких проектах обычно считается, что пользовательская история не завершена, пока не пройдут все ее автоматические приемочные тесты. Аналогично, функцию нельзя считать готовой к доставке, пока не будут определены и реализованы все критерии приемлемости для базовых пользовательских историй. Однако разумные команды избегают попыток заранее определить все критерии приемлемости, оставляя это до «последнего ответственного момента», часто незадолго до запланированного внедрения пользовательской истории. По этой причине отчеты, которые касаются прогресса и статуса проекта только с точки зрения результатов испытаний, отсутствуют на общей картине.
Чтобы получить более точное представление о том, какие функции были предоставлены, какие выполняются, и какую работу еще предстоит выполнить, мы должны думать не с точки зрения результатов испытаний, а с точки зрения требований, которые мы понимаем в настоящее время, соответствия в настоящее время осуществляются тесты на соответствие этим требованиям, но также указывается, какие требования в настоящее время не определены критерии приемлемости И когда графики и отчеты показывают, насколько достигнут прогресс, требования без критериев приемлемости также должны быть частью картины.
Отчетность BDD на уровне требований с Thucydides
Thucydides — это инструмент с открытым исходным кодом, который применяет некоторые из этих концепций на практике. Опираясь на инструменты BDD, такие как JBehave, или используя обычные тесты JUnit, Thucydides сообщает не только о том, как тесты проходили, но и вписывает их в более широкую картину, показывая, какие требования были протестированы и, что не менее важно, какие требования нет. Вы можете узнать больше о Фукидиде в этом руководстве или на сайте Фукидид .
В оставшейся части этой статьи мы увидим, как составлять отчеты о ваших требованиях и результатах тестирования с помощью Thucydides, используя очень простой подход на основе каталогов. Вы можете следовать этому примеру, клонируя проект Github по адресу https://github.com/thucydides-webtests/thucydides-simple-demo.
Простые требования в Thucydides — подход на основе каталогов
Thucydides может интегрироваться со многими различными системами управления требованиями, и легко написать свой собственный плагин для адаптации интеграции в соответствии с вашей конкретной средой. Например, популярным подходом является хранение требований в JIRA и использование Thucydides для считывания иерархии требований непосредственно с карт JIRA. Однако самый простой подход, который использует подход на основе каталогов, вероятно, самый простой в использовании, чтобы начать работу, и именно этот подход мы рассмотрим здесь.
Требования обычно могут быть организованы в иерархическую структуру. По умолчанию Thucydides использует трехуровневую иерархию требований. На верхнем уровне возможности представляют собой высокоуровневую емкость, которую приложение должно предоставить для достижения бизнес-целей приложения. На следующем уровне функции помогают реализовать эти возможности. Чтобы упростить реализацию, функцию можно разбить на пользовательские истории , каждая из которых, в свою очередь, может содержать ряд критериев приемлемости .
Рисунок 2. Тестовые каталоги JUnit отражают иерархию требований.
Конечно, вам не нужно использовать эту структуру, если она вам не подходит. Вы можете переопределить thucydides.capability.typesсистемное свойство, чтобы предоставить свою собственную иерархию. Например, если вы хотите иерархию с модулями, былин и функций, вы бы просто установить thucydides.capability.typesв «модуль, эпической, функция» .
Когда мы используем стандартную стратегию требований к каталогам в Thucydides, требования сохраняются в иерархической структуре каталогов, которая соответствует иерархии требований. На самом низком уровне пользовательская история представлена файлом JBehave * .story , историей easyb или тестом JUnit. Все остальные требования представлены в виде каталогов (пример такой структуры см. На рисунке 2).
В каждом каталоге требований вы можете при желании разместить файл narrative.txt , в котором содержится краткое изложение требований в произвольном тексте. Это будет отображаться в отчетах, а первая строка будет отображаться как заголовок требования. Типичный повествовательный текст иллюстрируется в следующем примере:
Learn the meaning of a word In order to learn the meaning of a word that I don't know As an online reader I want to be able to find out the meaning of the word
Если вы реализуете критерии приемки как тесты JUnit, просто поместите тесты JUnit в пакет, который соответствует требованию соответствия. Вам необходимо использовать thucydides.test.rootсистемное свойство, чтобы указать корневой пакет ваших требований. Для примера на рисунке 2 это значение должно быть установлено на nz.govt.nzqa.lssu.stories.
Рисунок 3: В narrative.txt появляется файл в отчетах для описания требований.
Если вы используете JBehave, просто поместите файлы * .story в src/test/resources/storiesкаталог, снова соблюдая структуру каталога, соответствующую вашей иерархии требований. В narrative.txt файлы также работать для требований JBehave.
Прогресс измеряется по общему количеству критериев прохождения, отказа или ожидания приемлемости либо для всего проекта (на верхнем уровне), либо в рамках конкретного требования по мере детализации иерархии требований. Для целей отчетности требованию без критериев приемлемости присваивается произвольное количество «мнимых» ожидающих критериев приемлемости. Thucydides считает, что вам нужно 4 теста на требование по умолчанию, но вы можете переопределить это значение, используя thucydides.estimated.tests.per.requirementсистемное свойство.
Рисунок 3: Для JBehave все идет не так src/test/resources/stories.
Вывод
BDD является отличным подходом для общения и отчетности перед заинтересованными сторонами. Однако для получения точных отчетов о приемочных испытаниях по реальным проектам вам необходимо выйти за рамки уровня истории и удовлетворить всю иерархию требований. В частности, вам нужно не только сообщать о выполненных тестах, но и разрешать тесты, которые еще не были написаны.
Thucydides реализует эти концепции на практике: используя простое соглашение на основе каталогов, вы можете легко интегрировать иерархию требований в свои приемочные тесты.