Примечание: чтобы использовать это руководство, вам понадобятся навыки, приобретенные после прочтения Как создать API с помощью Python и Django, а также код, над которым мы работали тогда. Мы продолжим работу с тем же API для приложения со списком дел, и будем использовать вот эту версию на GitHub.
Прошлым летом я работал над веб-приложением на Django со своими друзьями. Как-то раз я создал одну функцию и отправил своему другу на тестирование. Он ответил, что не смог ее протестировать, поскольку я случайно сломал функцию входа в систему. Однако это был не единственный случай, что-то подобное происходило каждую неделю. Основная проблема заключалась в том, что мы не использовали полноценное автоматизированное тестирование в нашем рабочем процессе.
Что такое автоматизированное тестирование?
Тестирование кода — одна из важнейших частей разработки. Тестирование может быть разным: можно протестировать приложение, всего лишь взглянув на веб-страницу, поиграв в видеоигру или проанализировав логи. Все зависит от типа вашего проекта.
Тестовая документация (тест план, тестовая стратегия, чек-листы, тест-кейсы) #18
Ручное тестирование отнимает много времени и допускает возможность ошибок, поэтому профессиональные разработчики стараются уделять больше внимания автоматизированному тестированию. В этой статье мы рассмотрим общий вид автоматизированного тестирования, модульные тесты, а также поговорим о том, как автоматизированное тестирование может помочь нам в процессе разработки. Мы начнем с написания тестов для моделей и представлений (views) существующего API, затем, добавив новую функцию, попрактикуемся в разработке через тестирование.
Автоматизированное тестирование экономит время и делает программное обеспечение качественней. Поначалу ручное тестирование кажется быстрым: нужно просто запустить код и посмотреть, работает ли он. Однако со временем, чем больше и больше функций вы добавляете в свое приложение, тем больше времени начинает отнимать такой тип тестирования.
К тому же вы можете просто забыть протестировать определенные вещи. Правильно реализованное автоматизированное тестирование охватывает все, работает всегда и занимает считанные секунды. Оно также делает код проще для понимания, что позволяет одновременно нескольким командам работать над кодом, не беспокоясь о том, что они могут сломать чью-то функцию.
Модульный тест по отдельности проверяет функциональность компонентов. Это тестирование самого низкого уровня, оно проверяет, что каждый компонент программы правильно работает в одиночку (интеграционные и системные тесты проверяют все компоненты вместе, а также их взаимодействия, но эта тема выходит за рамки данного руководства). При объектно-ориентированном подходе, например, вам пришлось бы писать модульные тесты для каждого объекта, а также для отдельных методов, в зависимости от их сложности. В Django мы используем модульное тестирование для каждой модели и представления.
Как в Django работает модульное тестирование?
Для работы с этим руководством, клонируйте вот этот проект из GitHub. Чтобы создать проект, выполните действия из первых трех параграфов в Как создать API с помощью Python и Django.
Тестовая документация | Документация IT-проекта
Когда вы используете python manage.py startapp appname для создания приложения на Django, один из создаваемых Django файлов папке appname имеет имя tests.py . Этот файл существует для размещения модульных тестов для моделей и других компонентов внутри приложения. По умолчанию этот файл содержит одну строчку кода: from django.test import TestCase . Test case содержит несколько связанных тестов для одного и того же фрагмента кода. TestCase — это объект Django, который мы будем наследовать для создания собственных модульных тестов. У класса есть два метода: setUp(self) и tearDown(self) , которые запускаются до и после отдельных тестовых функций для того, чтобы предоставить и очистить тестовую базу данных. Эта база независима от той базы данных, к которой вы получаете доступ с помощью python manage.py runserver . Чтобы взглянуть на код, откройте tests.py в папке todo нашего проекта.
Здесь мы тестируем функцию входа в систему. Поскольку мы используем встроенные в Django методы, все должно работать нормально, если в базе данных нет никаких проблем. Нам нужны только простые тесты: аутентифицируйтесь, если предоставлены верные данные, и не делайте этого, если нет. Благодаря этому примеру мы можем увидеть кое-что еще в модульном тестировании в Django.
Прежде всего, все тестовые методы в тестовом случае должны начинаться с test_ , чтобы быть выполненными при запуске тестовой команды python manage.py test . Остальные методы в тестовом случае нужно воспринимать как вспомогательные функции. Также необходимо знать, что все тестовые методы должны принимать self в качестве аргумента, где self является ссылкой на объект TestCase . Класс TestCase , который мы наследуем для создания нашего класса, содержит методы утверждений для проверки логических значений. Вызов self.assertSomething() проходит, если переданные в качестве аргументов значения соответствуют утверждению, в противном случае этого не происходит. Тестовый метод проходит, только если каждое утверждение в методе проходит.
Теперь давайте протестируем нашу модель: объект Task , определенный в models.py . Для тестового случая мы создаем пользователя и задачу (обратите внимание, что из-за того, что пользователь и задача связаны отношениями внешнего ключа, удаление пользователя в tearDown() приведет к удалению задачи). Здесь мы можем увидеть, что любой тестовый метод может иметь несколько утверждений и проходит только в том случае, если все они выполняются успешно. Когда мы обновляем задачу, мы можем записывать данные в базу вне функции setUp. В остальном, этот тест похож на тест функции входа. Большинство тестовых случаев для моделей представляют собой создание, чтение, модифицирование и удаление объектов в базе данных, хотя модели с методами и интереснее тестировать.
Тестировать представления несколько сложнее, чем модели. Однако поскольку мы пишем API, в отличие от веб-приложения, здесь можно не волноваться по поводу тестирования фронтенда. Большую часть ручных тестов посредством Postman можно заменить на тесты представлений. self.client — HTTP-клиент тестовой библиотеки Django.
Мы используем его для создания post-запроса к «/signin/» с учетными данными пользователя. Мы тестируем то же, что и раньше: верные учетные данные, неправильное имя пользователя и неправильный пароль. Это очень полезно, так как мы видим, что если тесты модели не выявляют ошибок, а тесты представлений выявляют — проблема не в модели, что в свою очередь позволяет тратить меньше времени на устранение багов. Мы делаем примерно то же самое для представлений, связанных с задачами.
Этот случай тестирует конечную точку «/all/». На самом деле у этого теста больше методов, но фрагмент выше показывает только новое. Чтобы клиент мог действовать как вошедший в систему пользователь, в setUp мы используем self.client.login() . Затем мы создаем задачи и сравниваем их с ожидаемым отформатированным выводом. Этот пример хорошо иллюстрирует преимущества методов setUp() и tearDown() , так как задачи из одного теста не переносятся в другие. Опять же, этот тест изолирует компонент представления, поскольку базовая модель тестируется отдельно.
Когда разберетесь с тестовым кодом, запустите python manage.py test , чтобы выполнить все тесты. Давайте взглянем на результат:
Creating test database for alias ‘default’. System check identified no issues (0 silenced). . FF. ====================================================================== FAIL: test_due_future (todo.tests.DueTodayTest) ———————————————————————- Traceback (most recent call last): File «/Users/Philip/Code/WFH/mkdev_blog/djangotesting/taskmanager/todo/tests.py», line 155, in test_due_future self.assertFalse(self.task.due_today()) AssertionError: True is not false ====================================================================== FAIL: test_due_past (todo.tests.DueTodayTest) ———————————————————————- Traceback (most recent call last): File «/Users/Philip/Code/WFH/mkdev_blog/djangotesting/taskmanager/todo/tests.py», line 161, in test_due_past self.assertFalse(self.task.due_today()) AssertionError: True is not false ———————————————————————- Ran 15 tests in 2.232s FAILED (failures=2) Destroying test database for alias ‘default’.
Все тесты, не выявившие ошибок, помечаются . , а тесты, показавшие ошибки — F . Такие тесты также показывают, почему именно утверждения не прошли.
Мы еще не говорили с вами о тех тестах, которые выявили ошибки, но мы исправимся чуть ниже. Вы могли заметить, что код теста очень подробен. Конечно же, мы протестировали лишь небольшую часть нашего функционала, но, несмотря на это, уже получили столько же строк кода, сколько и в файле представления. Этого и следовало ожидать.
Если вы хотите, чтобы ваши тесты были точными, вы не можете проводить их слишком часто. При изменениях в коде некоторые тесты перестанут работать. Таким образом, вы сможете понять, какие ошибки и в каких тестах нужно будет устранить. Так что будьте готовы к тому, что код тестов будет все расти и расти, а в среднестатистическом приложении будет столько же строк тестового кода, сколько и у кода самого приложения.
Что такое разработка через тестирование?
Давайте на секундочку вернемся к рассказу из начала статьи. Наша команда неделя за неделей сражалась с багами и в результате написала модульные тесты для всей базы данных. Мы покрыли тестами абсолютно все, каждая строчка кода проверялась по меньшей мере одним тестом. Мы поработали так пару недель, пока не решили существенно изменить структуру нашей базы данных.
Вместо того чтобы переписывать тесты, мы стали отбрасывать неработающие и буквально через несколько дней у нас стали снова вылезать случайные поломки. Разработка через тестирование помогла бы это предотвратить.
Чтобы тесты оставались актуальными, их нужно обновлять по мере обновления кода. Некоторые разработчики пользуются разработкой на основе тестов, чтобы всегда быть готовыми к любым изменениям в коде. Первое, что вы делаете при разработке функции — определяете что, собственно, эта функция будет делать.
Разработка через тестирование формализует этот процесс, поскольку при таком подходе вы, прежде всего, прописываете тесты для этой самой функциональности. Основная идея заключается в том, что вы пишите один или несколько тестов, которые определяют функцию, переписываете код до тех пор, пока тесты не выявят ошибок, а затем снова пишите еще больше тестов. Вернемся к тестам, выявившим ошибки. Нам нужно написать метод due_today() в модели Task . Согласно тесту, этот метод должен возвращать True , если задача должна быть выполнена сегодня и False , если нет. Скопируйте код ниже для замены существующего метода due_today() в модели Task , а затем запустите тесты снова. python def due_today(self): return self.due == date.today()
Тест не показывает ошибок, что значит, что наша функция работает и можно продолжать. Подобный подход к разработке требует больших физических и умственных усилий поначалу для определения поведения кода, но в результате значительно упрощает сам процесс разработки.
Чтобы протестировать разобрались ли вы, попробуйте написать тесты для остальных представлений или используйте тесты для задания новых функций, а затем напишите эти функции. Одним из простых вариантов будет поле с логическим значением completed в модели task , которому может быть присвоено значение True как только задача будет выполнена.
Это позволит нам не удалять выполненные задачи, а оставить их. Затем, подумайте о том, чтобы добавить тесты в ваши личные проекты. Да, вас может напугать перспектива покрытия тестами огромного проекта, который ранее не тестировался. Вместо того, чтобы пытаться протестировать все и сразу, попробуйте добавить тесты в маленькие фрагменты проекта или новые функции непосредственно во время разработки до полного покрытия.
Материалы для ознакомления:
- Официальное руководство Django, часть 5
- Обзор документации Django по тестированию
- Раздел по тестированию для продвинутых пользователей. Включает в себя покрытие тестами
- Документация Django по тестированию кода Django
Источник: mkdev.me
Как писать тестовые примеры (с примерами)
Тестирование является важной частью обеспечения производительности и функциональности программного обеспечения. И тестовые случаи, и сценарии помогают программистам устранять проблемы и улучшать программные проекты. Понимание того, как их писать, может помочь вам продвинуть ваше программное обеспечение на следующие этапы процесса разработки.
В этой статье мы объясним, что такое тестовые случаи, покажем, чем они отличаются от тестовых сценариев, и на примерах объясним, как писать тестовые случаи.
Что такое тестовый пример?
Тестовый пример — это серия действий по кодированию, которые программисты выполняют для проверки различных функций программного обеспечения. Тестовые сценарии содержат шаги анализа, условия поведения и результаты действий. Эти случаи также включают в себя любые переменные или условия, такие как пароли и электронные адреса. Тестировщики используют как программу, так и переменные для сравнения похожих результатов. Используя несколько тестовых примеров, инженер может определить, правильно ли функционирует программа.
Тестовый пример содержит как то, что программист хочет проверить, так и то, как он будет это проверять. В нем подробно описано, какая информация необходима команде разработчиков для проведения теста, а также критерии оценки после проведения теста. Например, простая веб-форма может попросить пользователя ввести текст, возвращая ошибку, если поле сообщения пустое. В этом примере данные, необходимые команде разработчиков, — это текст в поле сообщения, а критерий оценки — пустой ли текст.
Как предприятия используют тестовые случаи
Программисты, сотрудники службы контроля качества и кадровые агенты используют тестовые примеры для проверки ведомственных программ в компании. Сотрудники могут использовать тестовые примеры, чтобы убедиться, что базы данных и программное обеспечение интранета функциональны и оптимизированы для использования в компании. В небольших компаниях, работающих за комиссионные, команда может проводить ручное тестирование программного обеспечения на соответствие всем функциональным требованиям.
Тестовый сценарий vs. тестовый пример
Сценарий тестирования — это документация нескольких тестовых случаев для проверки продукта. Тестовые сценарии обычно описывают, что пользователь пытается сделать с помощью программного обеспечения и какие предыдущие требования привели его к этому выбору. Например, тестовый сценарий может гласить, пользователь может войти на веб-страницу после нажатия на кнопку входа , в то время как в тестовом примере говорится, что поле пароля содержит текст. Тестовые сценарии помогают проверить функциональность программы с точки зрения пользователя, а тестовые случаи помогают проверить код как изнутри, так и снаружи.
В отличие от тестовых примеров, сценарии представляют собой отдельные рабочие экземпляры программы. Другими словами, сценарий тестирования для одной веб-страницы при одном наборе обстоятельств не требует нескольких тестов. В отличие от сценариев, тестовые примеры проверяют программу несколько раз, используя многочисленные обстоятельства и изменяя данные, чтобы смоделировать различные диапазоны функциональности программы.
Как писать тестовые примеры с примерами
Если вы хотите создать тестовые случаи для своего программного обеспечения, рассмотрите некоторые из следующих шагов и примеров:
1. Создание описания тестового случая
Описание тестового случая включает в себя то, что программа делает в ответ на определенные условия. Например, описание тестового случая для страницы входа в систему может быть следующим, Проверка полей, когда пользователь нажимает кнопку входа в систему. Описания кейсов только обеспечивают контекст для сотрудников во время тестовых сценариев и не имеют ценности для кода или исполняемых данных. Пример тестового сценария приведен ниже:
| Кейс 1 | Проверьте поля, когда пользователь нажимает кнопку входа в систему. |
2. Добавьте необходимые тестовые данные
Для того чтобы проверить программу, начните с добавления тестовых данных в кейс. Тестовые данные могут включать такую информацию, как электронная почта, пароли и имена пользователей. Для нескольких тестовых примеров идентификация данных может стать самым длительным этапом процесса проверки. Идентификационные данные могут помочь понять, что программа документирует как проход или провал. Ниже приведен пример тестового случая после определения данных:
3. Активируйте этапы тестирования
Чтобы выполнить тест, активируйте действия сценария с помощью вашего программного обеспечения для тестирования. Поскольку тестовые примеры обычно проверяют несколько наборов данных и обстоятельств для каждого теста, подумайте о том, чтобы подготовить всю информацию заранее, чтобы сэкономить время. После того как инженер по тестированию задокументирует все необходимые данные, сотрудники, не являющиеся программистами, могут запустить тестовый пример, независимо от их опыта кодирования. Шаги могут помочь заинтересованным сторонам и другим сотрудникам понять тестовый пример в процессе его создания. Ниже приведен пример тестового примера:
4. Проверьте и задокументируйте результаты
После тестирования проверьте и задокументируйте различные результаты, чтобы оценить поведение программы. Создание раздела результатов для каждого теста поможет проследить, как фактические результаты сравниваются с оптимальными. Добавление дополнительного раздела PassFail в таблицу тестовых примеров может помочь заинтересованным сторонам, клиентам и другим программистам быстро понять результаты. Пример тестового случая приведен ниже:
5. Добавьте предварительные и последующие условия
После проверки базовой версии теста подумайте о добавлении необходимых предварительных или последующих условий. Условия могут включать определенный браузер, интернет-расширение, проверку капчи или блокировщика рекламы. Полная таблица тестовых случаев после выполнения нескольких тестов с условиями может выглядеть примерно так, как показано ниже:
Советы по написанию тестовых примеров
Если вы пишете тестовые примеры для своего программного обеспечения, учтите некоторые из следующих советов:
Используйте простой язык тестов
При создании тестового случая использование простого языка может помочь другим потенциальным пользователям эффективно проверить программу. Сотрудники вне отдела программирования или заинтересованные стороны могут захотеть проверить или проанализировать аспекты программы. Использование действенных фраз, таких как вводить данные, нажмите на или перейти к может помочь сотрудникам других отделов выполнить вашу программу. Если необходимо, предоставьте пошаговые инструкции по выполнению теста, чтобы помочь людям, не являющимся сотрудниками отдела программирования, выполнить тест точно.
Тестируйте программирование для целей конечного пользователя
Целью многих программных проектов является выполнение функций для конечного пользователя. Конечными пользователями могут быть клиенты, компании или сотрудники. При тестировании вашей программы постарайтесь создать дополнительные удобства для конечных пользователей, такие как командные подсказки или дополнительные инструкции. Простота эксплуатации может помочь повысить удовлетворенность клиента вашим продуктом.
Повторяйте тесты нечасто
Поскольку тестирование требует ввода данных, старайтесь выполнять каждый сценарий тестирования только один раз. Однократное тестирование может помочь сэкономить время в процессе проверки и направить усилия на улучшение или добавление функций. Если вы хотите одновременно тестировать различные функции, по возможности добавьте их в качестве условий. После разработки всех тестов просмотрите их, чтобы убедиться в отсутствии дублирования и в том, что каждый тест проверяет что-то уникальное.
Обзор спецификаций
Тестирование — это этап обеспечения качества между вашей программой и заказчиком. Рассмотрите возможность пересмотра спецификаций на этапе тестирования, чтобы убедиться, что вы добавили все необходимые условия. Тщательно тестируйте все аспекты программы, чтобы убедиться, что ваша программа соответствует ожиданиям клиента.
Рассмотрите возможность внешнего тестирования
После этапа первоначального тестирования рассмотрите возможность проведения этапа внешней проверки, прежде чем передавать продукт клиенту. Отделы вне вашей команды или даже компании могут помочь проверить вашу работу путем независимого тестирования вашего программного обеспечения. Внешнее тестирование может помочь проверить программирование после серьезной модификации и помочь в исправлении регрессии.
Создайте идентификационные номера тестовых случаев
Хотя названия и описания сценариев могут помочь идентифицировать тестовые случаи, рассмотрите возможность использования идентификационных номеров по всему проекту. Идентификационные номера могут помочь найти и изучить определенные тестовые случаи при использовании точной документации. Рассмотрите возможность использования последовательной системы идентификации результатов, чтобы заинтересованные лица или клиенты могли быстро найти аспекты вашего этапа тестирования во время обсуждения.
Используйте методы тестирования
Различные методы тестирования помогут вам сэкономить время в процессе проверки. Некоторые из этих методов включают:
- Анализ граничных значений: Эта техника позволяет проверить границы для различных диапазонов значений. Например, вы можете определить, что определенное поле всегда будет содержать число, вместо того, чтобы тестировать поле для каждого вида ввода.
- Эквивалентное разделение: Техника разбиения по эквивалентности делит поля на части, которые тестируют одинаковые типы значений. Например, разделив поля на две группы, вы можете использовать один тест для каждого поля, использующего числовые значения, и другой тест для каждого поля, использующего буквенные значения.
- Переход состояния: Методы перехода в состояние помогают разработчикам тестировать программное обеспечение, которое переводит поля из одного состояния (например, числового) в другое (например, буквенное). Эта техника может помочь выполнить одну проверку для сценариев с несколькими изменениями вместо того, чтобы организовывать несколько тестов для каждого изменения.
- Угадывание ошибок: Угадывание ошибок — это метод прогнозирования, который помогает сэкономить время во время тестирования. Это позволяет разработчикам предположить, что одна ошибка может привести к аналогичным другим.
Автоматизируйте тестовые случаи
Автоматизация процесса создания тестовых примеров происходит, когда разработчик использует программу, которая запускает тестовые примеры, избавляя пользователей от необходимости проводить тесты вручную. Преимущества автоматизации тестовых случаев заключаются в том, что для тестирования приложения может потребоваться мало людей, и это может дать более быстрые результаты. Однако автоматизация процесса создания тестовых примеров также сложна и может потребовать времени на разработку и внедрение. Для проектов с большим количеством требований к тестированию, бизнесу часто выгодно изучить автоматизацию, чтобы понять, сэкономит ли она время или деньги.
Ключевые слова:
- indeed.com
Источник: hr-portal.ru
Что такое тестовый сценарий?
Быстрое определение: последовательность шагов пользователя в приложении. Всякий вариант действий (возможность), который может быть протестирован, называется тестовым сценарием. Другие названия (менее распространенные, но тоже релевантные) — сценарий тестирования, тестовая возможность, тестовое условие.
Создавая тестовый сценарий, QA-инженер как бы «ставит себя на место пользователя»; в сценарии он описывает ситуации, возникающие в приложении.
Тестовый сценарий обычно представляет собой список тест-кейсов сквозного функционального тестирования приложения. Фактически это классификация проверяемых требований высокого уровня, которые разбиваются на категории по функциональности и строятся на юз-кейсах (что является хорошей практикой).
В одном сценарии может быть много тест-кейсов, поэтому тестировщик должен перед сдачей тестового сценария проверить все тест-кейсы по отдельности. Также в процессе лучше советоваться с пользователями, стейкхолдерами и разумеется разработчиками.
Итак, тестовые сценарии — это высокоуровневые документы, описывающие реалистичные варианты действий пользователя в приложении. Сценарии могут быть как позитивными, так и негативными.
Как писать тестовый сценарий
- Ознакомиться с требованиями в проекте, то есть со документами (спецификациями) системных требований (System Requirement Specifications, SRS), бизнес-требований (BRS), и функциональных требований (FRS). Изучить юз-кейсы приложения, мануалы и другие дополнительные материалы.
- По каждому требованию уточнить технические аспекты.
- Понять основные варианты взаимодействия пользователя с приложением.
- Определить возможные сценарии некорректного использования (и в частности злонамеренного)
- После ознакомления с требованиями подготовить список тест-кейсов проверки каждой функции приложения
- После определения базовых тестовых сценариев подготовить матрицу трассировки требований, где будут сопоставлены требования с тестовыми сценариями.
- Сценарии подаются на согласование руководителю проекта / тест-менеджеру / лиду и стейкхолдерам.
Несколько советов
- Иметь под рукой список часто используемых функций и модулей
- В сценариях проверять модули по одному, поддерживая порядок и не забывая о второстепенных модулях
- Сценарии лучше делать «на уровне модуля»
- Стараться не удалять готовые сценарии, чтобы потом не писать с нуля
- Писать сценарии простым понятным языком (а ещё лучше Simple English)
- Лаконичность — каждый сценарий лучше уложить в одну-две строчки (не абзацев)
Почему нужен тестовый сценарий
- Качественные тестовые сценарии дают полное тестовое покрытие
- Сквозная проверка функциональности функций и всего приложения
- Проверка важных транзакций/взаимодействий
- Проверка приложения на всех уровнях всеми привлеченными сторонами
Когда тестовый сценарий не нужен
- В Agile-методологиях типа Scrum тестовые сценарии могут редко применяться
- Когда приложение нестабильное; чрезвычайно сложное; или не хватает времени
- Когда сценарии будут в чем-то мешать, например, регрессионному тестированию
Характеристики хорошего сценария
- В идеале, это «указания тестировщикам, что сделать, одной строчкой»
- Упрощает и ускоряет тестирование, устраняет «дублирование действий»
- Создается в результате обдумывания шагов тестирования, их обсуждения, и затем записывается
- Это серия четких последовательных действий/процедур
- Если не хватает времени на написание многих тест-кейсов, команда выбирает вариант «один большой тестовый сценарий»
- Хороший тестовый сценарий легко модифицировать
Примеры
Для простоты иллюстрации — приложение Gmail, создание последовательности действий для самых используемых модулей: Входа (Inbox), Создания письма (Compose), и Входящих (Inbox)
Compose-модуль
- Введение корректных имени/пароля, далее проверка отображения главной страницы
- Некорректные имя/пароль, проверка отображения главной страницы
- Проверка сообщения об ошибке после введения пустого имени/пароля
- Проверка сброса полей после ввода валидного имени и последующего нажатия кнопки Отмены
- Проверка блокировки аккаунта (или предупреждения на резервную почту) после ввода трех некорректных значений подряд
- Проверка отображения полного имени пользователя на главной странице после ввода валидного имени
Login-модуль
- Проверка возможности доступа к полям To, Cc, Bcc для всех пользователей
- Проверка создания письма, отправки, и получения подтверждения
- Создание, отправка и сохранение в Отправленных
- Проверка обработки невалидных email-адресов
- Проверка автоматического сохранения в Черновиках после создания письма и отмены отправки
- Проверка ручного сохранения Черновика и подтверждения
Inbox-модуль
- Все полученные письма отображены, и выделены жирным шрифтом как непрочитанные
- Правильное отображение ID письма отправителя (Sender ID) последних писем
- Выбор (Select) письма > Ответ (Reply) > Пересылка (Forward); проверка его сохранения в Отправленных и наличия во Входящих у получателя
- Проверка получения и загрузки прикрепленных документов
- Проверка приклеплений на вирусы
- Выбор письма > Ответ > Пересылка > Сохранение как Черновика > Проверка его наличия в Черновиках
- Проверка, что все прочитанные входящие письма не выделены как непрочитанные
- Все Сс-получатели видимы всем пользователям
- Все Bcc-получатели скрыты
- Выбор письма > Удаление > проверка наличия в Корзине
Чем отличается сценарий тестирования и тест-кейс
| Четко прописанные этапы тестирования приложения/сайта | Документация высокого уровня, описывающая end-to-end-функциональность, которая будет протестирована |
| Сосредоточен на том, «что тестировать» и «как тестировать» | «Что тестировать» |
| Прописанные этапы, условия начала, ожидаемые результаты; нет неопределенности | Может быть некоторая неопределенность в сценарии из-за его краткости и ориентированности на человека |
| Тест-кейсы могут иметь источником тестовые сценарии; один сценарий может «порождать» множество тест-кейсов | Основывается на use-кейсах |
| Полезен при тщательном тестировании приложения/сайта | Полезен для быстрого тестирования E2E-функциональности приложения/сайта |
| Требуется довольно много времени и усилий на создание и выполнение | Сравнительно мало усилий на создание и выполнение |
Отличие тест-кейса от тестового сценария
FAQ
Что входит в тестовый сценарий?
Компоненты сценария: начальные условия, входные данные, пользовательские ожидаемые действия, и результаты которые должны быть. Сценарии группируются по use-кейсам, на основе которых созданы.
Может ли быть создан автоматически?
Да, может быть или полностью ручным и рассчитанным на выполнение тестировщиком-мануальщиком; или созданным инструментом автоматизации, полностью или частично.
В чем разница между тестовым сценарием, тест кейсом, тест-сьютом?
Тестовый сценарий — последовательность тестовых действий, которая может делиться на отдельные тест-кейсы.
Тест-сьют (тестовый набор) — совокупность тест-кейсов, сгруппированных по какому-то признаку (обычно функциональности).
Кто пишет сценарии тестирования?
Кроме тестировщиков, сценарии тестирования могут писать бизнес-аналитики.
Какие бывают сценарии тестирования?
Самых разных видов, как функционального, так и нефункционального — сценарии приемочного, нагрузочного, дымового, и т.п.
Зачем вообще нужны эти сценарии? Не проще все автоматизировать на 100%?
Это удобнее и human-friendly.
Чем отличается тестовый сценарий от чек-листа?
В чек-листе описывается список вещей, которые будут протестированы; в сценарии — этапы (шаги) и действия.
Что такое негативный тестовый сценарий?
Сценарий с негативными ситуациями/сбоями/отклонениями от так называемого «happy path», то есть беспроблемного использования, и происходит нечто непредусмотренное/ошибочное, когда система не выдает положенный результат.
Источник: testengineer.ru