Какие тестовые сценарии необходимы и достаточны для исчерпывающего «черного ящика» тестирования модели повторяющихся встреч?

Question

У меня есть модель django для встречи в календаре, для которой я пытаюсь написать очень полный тестовый драйвер. Повторяющаяся встреча происходит в определенный момент времени и может продолжаться бесконечно или повторяться фиксированное количество раз. Встреча отражает функциональность, доступную для встречи в Календаре Google (может повторяться ежемесячно / ежегодно / еженедельно, каждые две недели, каждые 3 года).

Я пытаюсь придумать модульное тестирование, которое исчерпывающе проверит основы этой реализации. Я ищу крайние случаи, которые определят самые основные тесты.

У меня есть много основных, но я ищу предложения, чтобы помочь определить наиболее важные случаи: 1) Создать одну встречу 2) Создать встречу, которая повторяется еженедельно 3) ... повторяется ежемесячно 4) повторяется каждые 2 недели 5) повторяется каждые 2 месяца 6) повторяется ежегодно

Answer 1

Тест с последними днями месяцев, високосными годами и сумасшествием, если в году будет дополнительная секунда (этот удар попал в водителя в плеере zune).

Проверьте, хорошо ли работает при пересечении лет.

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

Answer 2

Не забудьте проверить годовую повторяемость за 29 февраля в високосный год;)

Answer 3

Прежде чем вы начнете дорабатывать сценарии, вам действительно нужно составить план тестирования, основанный на вашем понимании требований.

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

В идеале, создайте модель приложения и начните с этого.

Придумайте анализ рисков того, что вы планируете делать. Затем запланируйте функциональное тестирование, проверку безопасности, локализацию и т. Д.

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

Получите от бизнеса информацию (если возможно, подпишите) о вашем анализе риска и о том, как вы собираетесь его использовать.

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

При этом я согласен с тем, что вышеупомянутые сценарии проверены и верны. Хорошие идеи. Также добавьте тестирование на летнее время. Используйте разные почтовые клиенты. Попробуйте опубликовать дату занятости / занятости. Попросите разработчиков объяснить, как они публикуют эту информацию. Это через веб-сервис? Они ожидают, что только пользователи Exchange будут использовать это? Кто-нибудь в разных странах, где даты форматируются по-разному? Затем вы можете найти слабые места и найти больше ошибок.

Счастливого тестирования.