Разработка на основе приемочных испытаний

Разработка на основе приемочных испытаний ( ATDD ) — это методология разработки , основанная на общении между бизнес-клиентами, разработчиками и тестировщиками. ^[1] ATDD охватывает многие из тех же практик, что и спецификация на примере (SBE), ^[2]^[3] разработка на основе поведения (BDD), ^[4] разработка на основе примеров (EDD) ^[5] и разработка на основе поддержки, также называемая разработкой на основе тестовых историй (SDD). ^[6] Все эти процессы помогают разработчикам и тестировщикам понять потребности заказчика до внедрения и позволяют заказчикам общаться на их родном языке.

ATDD тесно связан с разработкой через тестирование (TDD). ^[7] Он отличается акцентом на сотрудничестве разработчика-тестировщика-бизнес-клиента. ATDD охватывает приемочное тестирование , но подчеркивает написание приемочных тестов до того, как разработчики начнут кодировать.

Обзор

Приемочные тесты проводятся с точки зрения пользователя – внешнего вида системы. ^[1] Они проверяют внешне видимые эффекты, такие как указание правильного вывода системы при определенном вводе. Приемочные тесты могут проверять, как изменяется состояние чего-либо, например, заказ, который переходит из состояния «оплачен» в состояние «отправлен». Они также могут проверять взаимодействие с интерфейсами других систем, таких как общие базы данных или веб-сервисы. В целом они не зависят от реализации, хотя их автоматизация может быть иной. ^[8]^[9]

Создание

Приемочные тесты создаются, когда требования анализируются и до кодирования. ^[1] Они могут быть разработаны совместно запрашивающим требования (владельцем продукта, бизнес-аналитиком, представителем заказчика и т. д.), разработчиком и тестировщиком. Разработчики реализуют систему с помощью приемочных тестов. Неудачные тесты обеспечивают быструю обратную связь о том, что требования не выполняются. Тесты указываются в терминах бизнес-домена. Затем термины формируют универсальный язык, который используется клиентами, разработчиками и тестировщиками. ^[10] Тесты и требования взаимосвязаны. ^[11] Требование, для которого отсутствует тест, может быть реализовано неправильно. Тест, который не ссылается на требование, является ненужным тестом. Приемочный тест, разработанный после начала реализации, представляет собой новое требование. ^[12]

Стратегия тестирования

Приемочные тесты являются частью общей стратегии тестирования. Это клиентские тесты, которые демонстрируют бизнес-намерение системы. Компонентные тесты — это технические приемочные тесты, разработанные архитектором, которые определяют поведение больших модулей. Модульные тесты создаются разработчиком для управления простым в обслуживании кодом. ^[13] Они часто выводятся из приемочных тестов и модульных тестов. Кросс-функциональное тестирование включает в себя тестирование удобства использования, ^[14] исследовательское тестирование, ^[15] и тестирование свойств (масштабирование и безопасность). ^[16]

Критерии приемки и испытания

Критерии приемки — это описание того, что будет проверяться тестом. Если задано требование, например «Как пользователь, я хочу взять книгу из библиотеки», критерием приемки может быть «проверить, что книга отмечена как взятая». Тест приемки для этого требования дает детали, чтобы тест можно было запускать с тем же эффектом каждый раз.

Формат теста

Приемочные испытания обычно проходят в следующем формате: ^[1]

Дано (настройка)

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

Когда (триггер)

Действие или событие происходит

Затем (проверка)

Состояние системы изменилось или был произведен вывод

Кроме того, можно добавлять утверждения, начинающиеся с AND, в любой из разделов ниже (Дано, Когда, Тогда).

Для примера требования шаги могут быть перечислены следующим образом:

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

Полный тест

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

Данный:

Книга, которая не была проверена

Книги
Заголовок	Проверено
Отличная книга.	Нет

Пользователь, зарегистрированный в системе

Пользователи
Имя	Сэм

Когда:

Пользователь берет книгу

Действие оформления заказа
Пользователь	Сэм	Проверки	Отличная книга.

Затем:

Книга отмечена как выданная

Книги
Заголовок	Проверено	Пользователь
Отличная книга.	Да	Сэм

Тестовый экзамен

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

А что, если книга уже взята напрокат?
А что, если книги не существует?
Что делать, если пользователь не зарегистрирован в системе?
Есть ли дата, когда книгу необходимо сдать?
Сколько книг может взять напрокат пользователь?

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

Еще один тестовый пример

Предположим, что бизнес-клиент хотел бизнес-правила, что пользователь мог бы брать только одну книгу за раз. Следующий тест продемонстрирует это:

Сценарий: Проверьте, что правило кассового обслуживания применяется

Данный:

Книга, которая была проверена

Книги
Заголовок	Проверено	Пользователь
Отличная книга.	Да	Сэм
Еще одна замечательная книга	Нет

Пользователи
Имя
Сэм

Когда:

Пользователь проверяет другую книгу

Действие оформления заказа
Пользователь	Сэм	Проверки	Еще одна замечательная книга

Затем:

Возникает ошибка

Произошла ошибка
Описание
Нарушение правил кассового обслуживания

Приемочные испытания проекта

В дополнение к приемочным испытаниям для требований приемочные испытания могут использоваться для всего проекта. ^[1] Например, если это требование было частью проекта по выдаче библиотечных книг, могут быть приемочные испытания для всего проекта. Их часто называют целями SMART . Пример теста: «Когда новая библиотечная система будет запущена в эксплуатацию, пользователи смогут выдавать и вносить книги в три раза быстрее, чем сегодня».

Смотрите также

Ссылки

^ abcde Pugh, Ken (2011). Lean-Agile Acceptance Test-Driven Development: Better Software Through Collaboration . Addison-Wesley. ISBN 978-0321714084.
^ Аджич, Гойко. (2009) Преодоление разрыва в коммуникации: спецификация на примере и гибкое приемочное тестирование , Neuri Limited,
^ Аджич, Гойко (2011). Спецификация на примере: как успешные команды поставляют правильное программное обеспечение . Мэннинг. ISBN 978-0-321-27865-4.
^ Челимски, Дэвид, Дэйв Астелс, Зак Деннис, Аслак Хеллесой, Брайан Хелмкамп и Дэн Норт. Книга RSpec: Разработка на основе поведения с RSpec, Cucumber и друзьями. Книжная полка Pragmatic.
^ "Пример управляемого дизайна" . Получено 2013-04-15 .
^ "Story Test-Driven Development" (PDF) . Получено 2013-04-15 .
^ Бек, Кент. Разработка через тестирование: на примере. Addison-Wesley Professional, 2002.
^ Мельник, Григорий и Франк Маурер. Мельник, Григорий; Маурер, Франк (2007). «Множественные перспективы разработки на основе приемочных тестов». Agile-процессы в программной инженерии и экстремальном программировании . Конспект лекций по информатике. Том 4536. С. 245–249. doi :10.1007/978-3-540-73101-6_46. ISBN 978-3-540-73100-9.
^ Коскела, Лассе. (2007) Тестирование через тестирование: TDD и принятие TDD для разработчиков Java. Manning Publications
^ Эванс, Эрик. (2003) Проектирование на основе предметной области: преодоление сложности в самом сердце программного обеспечения . Addison-Wesley Professional.
^ Вайнберг, Джеральд ; Гаузе, Дональд (1989). Изучение требований: качество прежде дизайна . Dorset House. ISBN 0-932633-13-7.
^ Мартин, Роберт С. и Григорий Мельник. «Тесты и требования, требования и тесты: лента Мёбиуса» (PDF) . Получено 15.04.2013 .
^ [Разработка через тестирование]
^ Месарош, Джерард и Дженис Астон. (2006) «Добавление тестирования удобства использования в Agile-проект». Agile Conference
^ «Объяснение исследовательского тестирования» (PDF) .
^ Месарош, Джерард. (2007) Шаблоны тестирования xUnit: рефакторинг тестового кода . Эддисон-Уэсли.

Внешние ссылки

Примеры фреймворков автоматизации

[Pugh11-1] Pugh, Ken (2011). Lean-Agile Acceptance Test-Driven Development: Better Software Through Collaboration . Addison-Wesley. ISBN 978-0321714084.

[2] Аджич, Гойко. (2009) Преодоление разрыва в коммуникации: спецификация на примере и гибкое приемочное тестирование , Neuri Limited,

[3] Аджич, Гойко (2011). Спецификация на примере: как успешные команды поставляют правильное программное обеспечение . Мэннинг. ISBN 978-0-321-27865-4.

[4] Челимски, Дэвид, Дэйв Астелс, Зак Деннис, Аслак Хеллесой, Брайан Хелмкамп и Дэн Норт. Книга RSpec: Разработка на основе поведения с RSpec, Cucumber и друзьями. Книжная полка Pragmatic.

[5] "Пример управляемого дизайна" . Получено 2013-04-15 .

[6] "Story Test-Driven Development" (PDF) . Получено 2013-04-15 .

[7] Бек, Кент. Разработка через тестирование: на примере. Addison-Wesley Professional, 2002.

[8] Мельник, Григорий и Франк Маурер. Мельник, Григорий; Маурер, Франк (2007). «Множественные перспективы разработки на основе приемочных тестов». Agile-процессы в программной инженерии и экстремальном программировании . Конспект лекций по информатике. Том 4536. С. 245–249. doi :10.1007/978-3-540-73101-6_46. ISBN 978-3-540-73100-9.

[9] Коскела, Лассе. (2007) Тестирование через тестирование: TDD и принятие TDD для разработчиков Java. Manning Publications

[10] Эванс, Эрик. (2003) Проектирование на основе предметной области: преодоление сложности в самом сердце программного обеспечения . Addison-Wesley Professional.

[11] Вайнберг, Джеральд ; Гаузе, Дональд (1989). Изучение требований: качество прежде дизайна . Dorset House. ISBN 0-932633-13-7.

[12] Мартин, Роберт С. и Григорий Мельник. «Тесты и требования, требования и тесты: лента Мёбиуса» (PDF) . Получено 15.04.2013 .

[13] [Разработка через тестирование]

[14] Месарош, Джерард и Дженис Астон. (2006) «Добавление тестирования удобства использования в Agile-проект». Agile Conference

[15] «Объяснение исследовательского тестирования» (PDF) .

[16] Месарош, Джерард. (2007) Шаблоны тестирования xUnit: рефакторинг тестового кода . Эддисон-Уэсли.