Правила по кратким тестам

Статья
11/05/2008

Обновлен: Ноябрь 2007

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

Примечание.
Термин "краткое тестирование" еще иногда называют "дымовым тестом" из области электронного оборудования. История возникновения данного термина такова: после изменений или ремонта определенного электронного устройства данное устройство просто включали. Если при включении из устройства не шел дым, тест считался пройденным.

Термин "краткое тестирование" еще иногда называют "дымовым тестом" из области электронного оборудования. История возникновения данного термина такова: после изменений или ремонта определенного электронного устройства данное устройство просто включали. Если при включении из устройства не шел дым, тест считался пройденным.

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

Работа с разработчиками

Поскольку краткое тестирование посвящено измененному коду, следует поработать с разработчиком, написавшим код. Нужно выяснить следующее:

Что изменилось в коде. Для этого также нужно знать, какая использовалась технология, разработчик сможет это объяснить.
Как изменение повлияет на функциональность.
Как изменение повлияет на независимость различных компонентов.

Проверьте код перед кратким тестированием

Перед кратким тестированием проверьте изменения в коде. Анализ кода — наиболее эффективный метод проверки качества кода и обнаружения дефектов. Краткие тесты обеспечивают выявление важнейших и самых слабых мест, указанных при анализе кода и анализе рисков, поскольку при сбое в этих областях продолжение тестирования невозможно.

Установите закрытые двоичные файлы на чистом отладочном построении

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

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

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

Создавайте ежедневные построения

При ежедневных построения разработчики работают в тестом сотрудничестве и обмениваются информацией. В случае задержек итераций новых построений возможно нарушение синхронизации сложных продуктов со множеством зависимостей. При ежедневных построениях и тестировании состояния измененных и новых файлов обеспечивается высокое качество.

Дополнительные сведения о регулярном создании построений см. в разделе Выполнение построений в Team Foundation Build. Дополнительные сведения о проверке построений продукта см. в разделе Практическое руководство. Настройка и запуск тестов проверки построения.

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

Создание высококачественных ежедневных построений должно быть важнейшей задачей для группы разработчиков. Если построение является неисправным из-за того, что при возврате кода не было проведено тестирование состояния, потребуйте от разработчика и тестера прекратить работу во всех прочих направлениях, пока данная проблема не будет устранена. Наказание за неисправность построения не должно быть чрезмерно строгим, однако оно должно подчеркивать важность создания высококачественных ежедневных командных построений.

Не следует выполнять слишком сложные тесты. Задача тестирования состояния вовсе не заключается в том, чтобы убедиться в отсутствии ошибок на 100%. Для этого бы потребовалось слишком много времени. Тесты состояния подразумевают проверку только на самом общем уровне. Нужно убедиться, что изменения в файле не приводят к нарушению работы всего построения и не взвывают серьезных ошибок функциональности.

Нагрузочное тестирование и веб-тестирование

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