Мы интегрируем процесс тестирования в наш процесс SCRUM. Моя новая роль - писать приемочные тесты наших веб-приложений, чтобы потом их автоматизировать. Я много читал о том, как должны быть написаны тестовые случаи, но ни один из них не дал мне практических советов по написанию тестовых случаев для сложных веб-приложений, и вместо этого они бросили противоречивые принципы, которые я с трудом применил:
Контрольные примеры должны быть короткими: возьмите пример CMS. Короткие тестовые примеры просты в обслуживании и позволяют идентифицировать входы и выходы. Но что, если я хочу протестировать длинный ряд операций (например, добавление документа, отправка уведомления другому пользователю, другой пользователь отвечает, документ меняет состояние, пользователь получает уведомление). Мне кажется, что контрольные примеры должны представлять собой полные сценарии. Но я вижу, как это приведет к появлению явно сложных тестовых документов.
Тесты должны идентифицировать входы и выходы: Что делать, если у меня есть длинная форма со многими взаимодействующими полями, с различным поведением. Я пишу один тест для всего или один для каждого?
Контрольные примеры должны быть независимыми: но как я могу применить это, если проверка операции загрузки требует, чтобы операция подключения была успешной? И как это относится к написанию тестовых случаев? Должен ли я написать тест для каждой операции, но каждый тест объявляет свои зависимости, или мне переписать весь сценарий для каждого теста?
Контрольные примеры должны быть слегка документированы: эти принципы специфичны для Agile проектов. Итак, есть ли у вас какие-либо советы о том, как реализовать этот принцип?
Несмотря на то, что я думал, что написание приемочных тестовых заданий будет простым, я был поражен каждым своим решением (к сведению: я разработчик, а не профессиональный тестировщик). Итак, мой главный вопрос: какие шаги или советы у вас есть для того, чтобы написать поддерживаемые приемочные тесты для сложных приложений. Спасибо.
Изменить : чтобы уточнить мой вопрос: я знаю, что приемочные испытания должны начинаться с требования и рассматривать все приложение как черный ящик. Мой вопрос касается практических шагов по написанию документа тестирования, идентификации тестовых случаев, работе с зависимостями между тестами ... для сложных веб-приложений
Конфликтующая информация может быть разочаровывающей, и ее сложно обобщить и применить к вашей конкретной ситуации. Ergo, возможно, вам придется делать то, что лучше всего работает в вашем контексте.
Я не большой поклонник длинных тестовых документов и довольно эффективно использовал визуальные эффекты для нескольких небольших проектов. Попробуй это? Как блок-схема (или любая другая диаграмма UML, такая как диаграмма состояний и т. Д.) Вместо использования только текста? Укажите входные, выходные данные, условия, циклы, дорожки, состояния, взаимодействия с другими компонентами и т. Д., А затем укажите, являются ли они успешными, неудачными, перенесенными, другими (?) На основе ваших критериев.
Вначале может быть немного работы, но это может помочь сохранить вас в здравом уме в долгосрочной перспективе. Какой бы метод вы ни выбрали, чем больше вы будете с ним работать, тем лучше вы его получите.
HTH, и удачи!
KM
источник
Я думаю, что вы уже добились некоторых хороших критериев. Второе замечание - это хороший способ определить области для ваших тестов, и я предлагаю также тестирование на наличие ошибок и исправлений (я рекомендую, чтобы каждое исправление ошибки сопровождалось хотя бы одним новым модульным тестом). Сейчас это может показаться ошеломляющим, но просто погрузитесь, и после получения небольшого опыта, становится легче понять, что делает для хороших тестов.
источник