И почему я делаю это вместо этого.
Опираясь на свой опыт проведения тестов и создания тестовых спецификаций, хочу сказать вам, что я не хочу, чтобы вы писали такую тестовую спецификацию.
1. Я не знаю, как действовать.
Это дело написано только для людей, которые знают характеристики системы (таких как я), и подробные методы работы не написаны. Вы не всегда делаете тестовые спецификации, поэтому вам следует писать тестовые примеры, которые могут быть выполнены людьми, не понимающими системных спецификаций.
Если вы напишете это внимательно, это будет хлопотно, но в конце концов, есть большая вероятность, что вы получите запросы о том, как выполнить этот метод работы. Я думаю, что это приведет к трудностям в объяснении.
Замечание: пишите внимательно, представляя, что даже новый выпускник, только что присоединившийся к компании, может понять
2. Неоднозначные ожидания
Например, есть случай, когда суждение размыто в зависимости от человека, например, «что правильно». Если оценка варьируется в зависимости от человека, есть вероятность, что тест продолжится с правильным ожидаемым значением, даже если есть проблема. В этом случае обнаружение дефектов, которые могли быть обнаружены во время тестирования, может быть задержано, что приведет к значительным дефектам.
Замечание: избегайте абстрактных выражений и описывайте конкретные ожидаемые значения.
3. Выполнение одной и той же операции снова и снова
Бывают случаи, когда тесты пишутся отдельно, хотя их можно тестировать вместе в одном потоке, и во многих случаях создаются ненужные данные.
Учитывая эффективность, я хочу проверять вещи, которые могут быть подтверждены одновременно в серии потоков. Было бы неплохо подумать не только о создании тестовых спецификаций, но и написать, думая о реализации тестов, которая будет более поздним процессом.
Если тест занимает много времени, я думаю, что это тоже самое, но я устаю и не могу сосредоточиться. Поскольку тестирование является необходимым процессом, связанным с вопросами качества, для проверки на наличие дефектов…
