WikiDer > Разработка через приемочные испытания - Википедия

Acceptance test–driven development - Wikipedia
Разработка программного обеспечения
Активность ядер
Парадигмы и модели
Методологии и рамки
Вспомогательные дисциплины
Практики
Инструменты
Стандарты и свод знаний
Глоссарии
Контуры

Разработка через приемочные испытания (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]

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

Указанное состояние системы

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

Произошло действие или событие

Тогда (проверка)

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

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

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

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

Полный тест

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

Данный:

Книга, которая не была проверена
Книги
ЗаголовокПроверено
Великая книгаНет
Пользователь, который зарегистрирован в системе
Пользователи
ИмяСэм

Когда:

Пользователь проверяет книгу
Действие кассы
ПользовательСэмПроверяетВеликая книга

Потом:

Книга отмечена как оформленная
Книги
ЗаголовокПровереноПользователь
Великая книгадаСэм

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

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

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

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

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

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

Сценарий:Убедитесь, что бизнес-правило оформления заказа применяется

Данный:

Книга, которая была проверена
Книги
ЗаголовокПровереноПользователь
Великая книгадаСэм
Еще одна замечательная книгаНет
Пользователи
Имя
Сэм

Когда:

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

Потом:

Возникает ошибка
Произошла ошибка
Описание
Нарушение правил кассы

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

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

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

Рекомендации

  1. ^ а б c d е Пью, Кен (2011). Lean-Agile Acceptance Test-Driven Development: лучшее программное обеспечение за счет совместной работы. Эддисон-Уэсли. ISBN 978-0321714084.
  2. ^ Аджич, Гойко. (2009) Устранение разрыва в коммуникации: спецификация на примере и адаптивное приемочное тестирование, Neuri Limited,
  3. ^ Аджич, Гойко (2011). Уточнение на примере: как успешные команды создают правильное программное обеспечение. Мэннинг. ISBN 978-0-321-27865-4.
  4. ^ Челимский, Дэвид, Дэйв Астелс, Зак Деннис, Аслак Хеллесой, Брайан Хелмкамп и Дэн Норт. Книга RSpec: Разработка на основе поведения с помощью RSpec, Cucumber и друзей. Прагматическая книжная полка.
  5. ^ «Пример дизайна». Получено 2013-04-15.
  6. ^ «Разработка на основе сюжета» (PDF). Получено 2013-04-15.
  7. ^ Бек, Кент. Разработка через тестирование: на примере. Эддисон-Уэсли Профессионал, 2002.
  8. ^ Мельник, Григорий и Франк Маурер. Мельник, Григорий; Маурер, Франк (2007). «Множественные точки зрения на разработку, управляемую приемочными испытаниями исполняемых файлов». Гибкие процессы в разработке программного обеспечения и экстремальном программировании. Конспект лекций по информатике. 4536. С. 245–249. Дои:10.1007/978-3-540-73101-6_46. ISBN 978-3-540-73100-9.
  9. ^ Коскела, Лассе. (2007) Тестирование: TDD и Acceptance TDD для разработчиков Java. Публикации Мэннинга
  10. ^ Эванс, Эрик. (2003) Доменно-ориентированный дизайн: преодоление сложности в самой основе программного обеспечения. Эддисон-Уэсли Профессионал.
  11. ^ Вайнберг, Джеральд; Гаузе, Дональд (1989). Изучение требований: качество перед дизайном. Дорсет-Хаус. ISBN 0-932633-13-7.
  12. ^ Мартин, Роберт К. и Григорий Мельник.«Тесты и требования, требования и тесты: лента Мёбиуса» (PDF). Получено 2013-04-15.
  13. ^ [Test-driven_development]
  14. ^ Месарош, Жерар и Дженис Астон. (2006) «Добавление юзабилити-тестирования к гибкому проекту». Agile конференция
  15. ^ «Объяснение исследовательского тестирования» (PDF).
  16. ^ Месарош, Жерар. (2007) Тестовые шаблоны xUnit: рефакторинг тестового кода. Эддисон-Уэсли.

внешняя ссылка