| Разработка программного обеспечения |
|---|
Разработка через приемочное тестирование ( 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 . Пример теста: «Когда новая библиотечная система находится в производстве, пользователи смогут регистрировать книги в три раза быстрее, чем сегодня».
См. Также [ править ]
- Concordion
- FitNesse
- Робот Фреймворк
- Датчик (программное обеспечение)
- Огурец (программное обеспечение)
Ссылки [ править ]
- ^ а б в г д Пью, Кен (2011). Lean-Agile Acceptance Test-Driven Development: лучшее программное обеспечение благодаря совместной работе . Эддисон-Уэсли. ISBN 978-0321714084.
- ^ Аджич, Гойко. (2009) Устранение разрыва в общении: спецификация на примере и адаптивное приемочное тестирование , Neuri Limited,
- ^ Adzic, Гойко (2011). Уточнение на примере: как успешные команды создают правильное программное обеспечение . Укомплектование персоналом. ISBN 978-0-321-27865-4.
- ^ Chelimsky, Дэвид, Дэйв Astels, Зак Деннис, Aslak Hellesøy, Брайан Helmkamp и Dan North. Книга RSpec: Разработка на основе поведения с помощью RSpec, Cucumber и друзей. Прагматическая книжная полка.
- ^ «Пример управляемой конструкции» . Проверено 15 апреля 2013 .
- ^ «История разработки, основанной на тестировании» (PDF) . Проверено 15 апреля 2013 .
- ^ Бек, Кент. Разработка через тестирование: на примере. Эддисон-Уэсли Профессионал, 2002.
- ↑ Мельник, Григорий и Франк Маурер. Мельник, Григорий; Маурер, Франк (2007). «Множественные точки зрения на разработку, управляемую приемочными испытаниями исполняемых файлов». Гибкие процессы в программной инженерии и экстремальном программировании . Конспект лекций по информатике. 4536 . С. 245–249. DOI : 10.1007 / 978-3-540-73101-6_46 . ISBN 978-3-540-73100-9.
- ^ Коскела, Лассе. (2007) Тестирование: TDD и Acceptance TDD для разработчиков Java. Публикации Мэннинга
- ^ Эванс, Эрик. (2003) Доменно-ориентированный дизайн: преодоление сложности в самой основе программного обеспечения . Эддисон-Уэсли Профессионал.
- ^ Вайнберг, Джеральд ; Гаузе, Дональд (1989). Изучение требований: качество перед дизайном . Дорсет-Хаус. ISBN 0-932633-13-7.
- ^ Мартин, Роберт С. и Григорий Мельник. «Тесты и требования, требования и тесты: лента Мёбиуса» (PDF) . Проверено 15 апреля 2013 .
- ^ [Test-driven_development]
- ^ Месарос, Джерард и Дженис Астон. (2006) «Добавление юзабилити-тестирования к гибкому проекту». Гибкая конференция
- ^ «Объяснение исследовательского тестирования» (PDF) .
- ^ . MÉSZÁROS, Gerard (2007) XUnit Test Patterns: Рефакторинг Код проверки . Эддисон-Уэсли.
Внешние ссылки [ править ]
- Пример фреймворков автоматизации
