Разработка через приемочное тестирование
| Часть серии о |
| Разработка программного обеспечения |
|---|
Разработка через приемочное тестирование ( 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, в любой из разделов ниже («Дано», «Когда», «Тогда»).
Для примера требования шаги могут быть перечислены как:
Given Book that has not been checked out
And User who is registered on the system
When User checks out a book
Then Book is marked as checked out
Полный тест
[ редактировать ]Предыдущие шаги не включают в себя какие-либо конкретные примеры данных, поэтому они добавляются для завершения теста:
Данный:
- Книга, которую не выписали
| Книги | |
|---|---|
| Заголовок | Выписано |
| Отличная книга | Нет |
- Пользователь, зарегистрированный в системе
| Пользователи | |
|---|---|
| Имя | Один |
Когда:
- Пользователь проверяет книгу
| Действие оформления заказа | |||
|---|---|---|---|
| Пользователь | Один | Выезд | Отличная книга |
Затем:
- Книга помечена как извлеченная
| Книги | ||
|---|---|---|
| Заголовок | Выписано | Пользователь |
| Отличная книга | Да | Один |
Тестовый экзамен
[ редактировать ]Изучение теста с конкретными данными обычно приводит к множеству вопросов. Для примера это могут быть:
- Что делать, если книга уже извлечена?
- Что делать, если книги не существует?
- Что делать, если пользователь не зарегистрирован в системе?
- Есть ли дата, когда книгу нужно будет сдать?
- Сколько книг может получить пользователь?
Эти вопросы помогают выявить недостающие или неоднозначные требования. К ожидаемому результату можно добавить дополнительные сведения, такие как срок выполнения. Другие приемочные тесты могут проверить, что такие условия, как попытка извлечь книгу, которая уже извлечена, приводят к ожидаемой ошибке.
Еще один тестовый пример
[ редактировать ]Предположим, что бизнес-клиент хочет ввести бизнес-правило, согласно которому пользователь может брать только одну книгу за раз. Следующий тест покажет, что:
Сценарий: Проверьте, соблюдается ли бизнес-правило оформления заказа
Данный:
- Книга, которая была извлечена
| Книги | ||
|---|---|---|
| Заголовок | Выписано | Пользователь |
| Отличная книга | Да | Один |
| Еще одна отличная книга | Нет |
| Пользователи |
|---|
| Имя |
| Один |
Когда:
- Пользователь проверяет другую книгу
| Действие оформления заказа | |||
|---|---|---|---|
| Пользователь | Один | Выезд | Еще одна отличная книга |
Затем:
- Возникла ошибка
| Произошла ошибка |
|---|
| Описание |
| Нарушение бизнес-правила кассы |
Приемочные испытания проекта
[ редактировать ]Помимо приемочных испытаний требований, приемочные испытания можно использовать для проекта в целом. [1] Например, если бы это требование было частью проекта по проверке книг в библиотеке, приемочные испытания могли бы проводиться для всего проекта. Их часто называют целями SMART . Пример теста: «Когда новая библиотечная система будет запущена в эксплуатацию, пользователи смогут загружать и выдавать книги в три раза быстрее, чем сегодня».
См. также
[ редактировать ]- Конкордеон
- Фитнессе
- Робот Фреймворк
- Датчик (программное обеспечение)
- Огурец (программное обеспечение)
Ссылки
[ редактировать ]- ^ Jump up to: а б с д и Пью, Кен (2011). Lean-Agile-разработка на основе приемочного тестирования: лучшее программное обеспечение благодаря сотрудничеству . Аддисон-Уэсли. ISBN 978-0321714084 .
- ^ Аджич, Гойко. (2009) Преодоление разрыва в общении: спецификация на примере и гибкое приемочное тестирование , Neuri Limited,
- ^ Аджич, Гойко (2011). Спецификация на примере: как успешные команды создают правильное программное обеспечение . Мэннинг. ISBN 978-0-321-27865-4 .
- ^ Челимский, Дэвид, Дэйв Астелс, Зак Деннис, Аслак Хеллесой, Брайан Хелмкамп и Дэн Норт. Книга RSpec: Разработка, основанная на поведении, с RSpec, Cucumber и друзьями. Прагматичная книжная полка.
- ^ «Примерный дизайн» . Проверено 15 апреля 2013 г.
- ^ «История разработки через тестирование» (PDF) . Проверено 15 апреля 2013 г.
- ^ Бек, Кент. Разработка через тестирование: на примере. Аддисон-Уэсли Профессионал, 2002.
- ^ Мельник, Григори и Франк Маурер. Мельник, Григорий; Маурер, Франк (2007). «Множественные перспективы разработки, основанной на приемочном тестировании исполняемых файлов». Гибкие процессы в программной инженерии и экстремальном программировании . Конспекты лекций по информатике. Том. 4536. стр. 245–249. дои : 10.1007/978-3-540-73101-6_46 . ISBN 978-3-540-73100-9 .
- ^ Коскела, Лассе. (2007) Test Driven: TDD и Acceptance TDD для разработчиков Java. Публикации Мэннинга
- ^ Эванс, Эрик. (2003) Доменно-ориентированный дизайн: решение проблем в сердце программного обеспечения . Аддисон-Уэсли Профессионал.
- ^ Вайнберг, Джеральд ; Гаус, Дональд (1989). Изучение требований: качество прежде проектирования . Дорсет Хаус. ISBN 0-932633-13-7 .
- ^ Мартин, Роберт С. и Григорий Мельник. «Тесты и требования, Требования и тесты: Лента Мёбиуса» (PDF) . Проверено 15 апреля 2013 г.
- ^ [Разработка через тестирование]
- ^ Месарос, Джерард и Дженис Астон. (2006) «Добавление юзабилити-тестирования в гибкий проект». Гибкая конференция
- ^ «Описание исследовательского тестирования» (PDF) .
- ^ Месарос, Джерард. (2007) Тестовые шаблоны xUnit: рефакторинг тестового кода . Аддисон-Уэсли.