Написание приемочных тестов

Мы интегрируем процесс тестирования в наш процесс SCRUM. Моя новая роль - писать приемочные тесты наших веб-приложений, чтобы потом их автоматизировать. Я много читал о том, как должны быть написаны тестовые случаи, но ни один из них не дал мне практических советов по написанию тестовых случаев для сложных веб-приложений, и вместо этого они бросили противоречивые принципы, которые я с трудом применил:

• Контрольные примеры должны быть короткими: возьмите пример CMS. Короткие тестовые примеры просты в обслуживании и позволяют идентифицировать входы и выходы. Но что, если я хочу протестировать длинный ряд операций (например, добавление документа, отправка уведомления другому пользователю, другой пользователь отвечает, документ меняет состояние, пользователь получает уведомление). Мне кажется, что контрольные примеры должны представлять собой полные сценарии. Но я вижу, как это приведет к появлению явно сложных тестовых документов.

• Тесты должны идентифицировать входы и выходы: Что делать, если у меня есть длинная форма со многими взаимодействующими полями, с различным поведением. Я пишу один тест для всего или один для каждого?

• Контрольные примеры должны быть независимыми: но как я могу применить это, если проверка операции загрузки требует, чтобы операция подключения была успешной? И как это относится к написанию тестовых случаев? Должен ли я написать тест для каждой операции, но каждый тест объявляет свои зависимости, или мне переписать весь сценарий для каждого теста?

• Контрольные примеры должны быть слегка документированы: эти принципы специфичны для Agile проектов. Итак, есть ли у вас какие-либо советы о том, как реализовать этот принцип?

Несмотря на то, что я думал, что написание приемочных тестовых заданий будет простым, я был поражен каждым своим решением (к сведению: я разработчик, а не профессиональный тестировщик). Итак, мой главный вопрос: какие шаги или советы у вас есть для того, чтобы написать поддерживаемые приемочные тесты для сложных приложений. Спасибо.

Изменить : чтобы уточнить мой вопрос: я знаю, что приемочные испытания должны начинаться с требования и рассматривать все приложение как черный ящик. Мой вопрос касается практических шагов по написанию документа тестирования, идентификации тестовых случаев, работе с зависимостями между тестами ... для сложных веб-приложений

В моих приемочных комплектах я держался подальше от использования специфичных для технологии элементов управления, т. Е. Для веб-приложений не используйте css, не используйте html-элементы, если вам нужно заполнить форму, выполните действия, описанные в шагах по настройке SUT, а не фактические приемочные тесты

Я использую огурец для моего принятия и имею следующее

Given A xxx 
And I am on the xxx page
And a clear email queue
And I should see "Total Payable xxxx"
And I supply my credit card details
When I the payment has been processed
Then my purchase should be complete
And I should receive an email
When I open the email with subject "xxx"
Then I should see the email delivered from "xx"
And there should be an attachment of type "application/pdf"
And attachment 1 should be named "xxxx"
And I should be on the xxx page
And I should see my receipt

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

этот тест находится в конце покупки, которая идет

Создать -> Подтвердить -> Оплата -> Распечатать квитанцию

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

Сначала вам нужно определить приемочное тестирование .

То, что вы описываете, это интеграция или тестирование системы .

Поэтому, хотя я не на 100% согласен с определениями в википедии, они все еще в значительной степени актуальны.

По сути, цель приемочного тестирования заключается в проверке того, что «бизнес-процессы», в которых используется созданная вами часть программного обеспечения, действительно работают так, как задумано, и соответствуют цели - с данными из реальной жизни. Таким образом, вы не создаете тестовые наборы, как юнит-тесты или все остальное. Он не должен быть разработан таким же образом.

Вопрос, который нужно задать: «Как используется система?». Итак, давайте проверим это так, как это предполагается использовать. Конечно, теперь вы снова надеваете инженерную шляпу и неукоснительно выполняете бизнес-требования, чтобы получить тестовые примеры. Это предполагает, что у вас есть хорошо написанные бизнес-требования.

Если вы этого не сделаете, еще не слишком поздно, вы должны сесть на встречу с пользователем (-ями) или их представителями (а также с бизнес-аналитиком и специалистом по техническому проектированию) и записать, что они ожидают от программного обеспечения в деловых условиях ( с очевидным предостережением, что это слишком мало, слишком поздно, но лучше начинать поздно, чем никогда - и, конечно, не вводить новые функции). Это то, что ваши тесты будут.

Другой способ сделать это (опять же, если у вас есть такой документ) - это просмотреть руководство пользователя. Хотя это один шаг, исключенный из реальных бизнес-требований, поэтому его следует использовать только в том случае, если ничего не помогает.

Когда вы идете покупать автомобиль, вы обычно не заходите слишком глубоко под капот (если вы не являетесь автомехаником). Вы просто садитесь за руль и проверяете удобство, удобство использования, внешний вид, звуки ... то есть общие вещи. Как правило, вы верите, что если автомобиль должен быть в ваших руках в первую очередь (по крайней мере, для нового автомобиля), он в целом безопасен и хорошо сложен (есть гарантия, вы выполнили домашнюю работу и посмотрели технические характеристики). ...). Итак, теперь вы проверяете, будет ли это автомобиль, которым вы хотите управлять в течение следующих нескольких лет.

То же самое с программным обеспечением.

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

Я не большой поклонник длинных тестовых документов и довольно эффективно использовал визуальные эффекты для нескольких небольших проектов. Попробуй это? Как блок-схема (или любая другая диаграмма UML, такая как диаграмма состояний и т. Д.) Вместо использования только текста? Укажите входные, выходные данные, условия, циклы, дорожки, состояния, взаимодействия с другими компонентами и т. Д., А затем укажите, являются ли они успешными, неудачными, перенесенными, другими (?) На основе ваших критериев.

Вначале может быть немного работы, но это может помочь сохранить вас в здравом уме в долгосрочной перспективе. Какой бы метод вы ни выбрали, чем больше вы будете с ним работать, тем лучше вы его получите.

HTH, и удачи!

KM

Я думаю, что вы уже добились некоторых хороших критериев. Второе замечание - это хороший способ определить области для ваших тестов, и я предлагаю также тестирование на наличие ошибок и исправлений (я рекомендую, чтобы каждое исправление ошибки сопровождалось хотя бы одним новым модульным тестом). Сейчас это может показаться ошеломляющим, но просто погрузитесь, и после получения небольшого опыта, становится легче понять, что делает для хороших тестов.