Как убедиться, что одна и та же ошибка не проникает в продукт во второй раз?

Question

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

Спасибо за ответы. Похоже, мой вопрос не был ясен. Я понимаю, что нам нужно написать отчет об ошибке, исправить ошибку и провести тестирование для проверки исправления. Однако на каком этапе тестирования должен проходить этот тест, чтобы в следующем выпуске версии мы обязательно повторили тест снова, чтобы убедиться, что ни одно из новых изменений не привело к повторному появлению ошибки. Должно ли оно пройти регрессионное тестирование или интеграционное тестирование для этого конкретного проекта, или мы должны просто протестировать все ошибки в системе отслеживания ошибок, начиная с версии 1.0?

Answer 1

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

---

Это должно быть регрессионное тестирование, и оно должно быть максимально автоматизировано.

Answer 2

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

Answer 3

Что вы имеете в виду, говоря "Ты защищен от регрессии, потому что этот тест внезапно провалится. "?

Смысл «модульных тестов» заключается в том, что они будут запускаться автоматически как часть цикла компиляции / проверки: вы будете запускать тесты после компиляции и перед проверкой кода. Если модульный тест не пройден, то вы знаете, что некоторый код, который вы только что написали , воссоздает старую ошибку.

редактировать:

Как ты можешь быть так уверен, что просто потому что ваши юнит-тесты прошли все Ваши ошибки были исправлены.

Как правило, если вы можете воспроизвести ошибку, вы можете выполнить тест для дублирования ее в коде. Наиболее важной частью является то, как только вы написали тест для проверки наличия ошибки, затем, если вы запустите тесты, и тест не пройден, вы снова введете ошибку. Одна большая книга на эту тему - «Эффективная работа с устаревшим кодом»

Разве нельзя для одной ошибки пройти несколько юнит-тестов.

Конечно, это может охватывать несколько тестов.

Давайте предположим, что ошибка "не могу сохранить файлы".

И давайте предположим, что есть несколько различных сценариев, которые могут вызвать это:

• недостаточно места на диске,

• файл, который вы пишете поверх открыт и заблокирован другим процессом,

• есть проблемы с разрешениями (например, вы не можете получить доступ к каталогу, или нет прав на запись),

• или во время сетевой ошибки Вы сохраняете файл.

В идеале, ваш тестовый комплект (набор тестов) должен иметь отдельный тест для каждого. Для некоторых тестов вам может понадобиться использовать вещи, которые называются «фиктивными объектами» (их также можно использовать, когда вы еще не написали код для компонента).

Answer 4

1. Получить отчет об ошибке
2. Напишите контрольный пример для воспроизведения отчета об ошибке
3. Исправлена ​​ошибка
4. Наслаждайтесь отсутствием необходимости исправлять эту ошибку снова

Answer 5

В зависимости от того, с какой точки зрения вы спрашиваете, вы можете атаковать проблему различными способами. С точки зрения разработчиков, может быть лучше, чтобы все ошибки, начиная с 1.0 (или ранее), были проверены с помощью надлежащего модульного теста, и позволяли ему работать даже с CI. Когда возникает много хлопот, попробуйте сгруппировать их, необходимые тесты, которые будут выполняться с каждой сборкой, некоторые раз в день, отдыхать раз в неделю (или что-то в этом роде).

С точки зрения QA / Testing это требует немного больше усилий.

1. Подготовить регрессионный костюм к применению. Основные бизнес-процессы / варианты использования, счастливые пути. Сделайте это своей базой. Набор тестов, которые не должны ни при каких обстоятельствах. Всегда запускайте его перед выпуском или когда вносятся большие изменения, когда вносится много изменений, когда модифицируются критические части. Приложите некоторые усилия для его автоматизации (и на этот раз я говорю не о модульных тестах, а о полных тестах приложений).
2. Чем создавать регрессионные тесты подходит для областей применения. Больше тестов, чем в предыдущем костюме, но каждый регрессионный костюм ориентирован на различные области применения. Когда вы изменяете одну часть приложения, запускайте регрессию для этой части. это может быть автоматизировано, но может быть трудно поддерживать тесты для областей, которые часто меняются.
3. Обучите свою команду qa просматривать репозиторий ошибок, когда они начинают работать над тестами с некоторыми требованиями / функциональностью. Им следует проверить наличие предыдущих ошибок, если они кажутся актуальными.

Имейте в виду, что вы должны быть осторожны с регрессионным тестированием, автоматизацией тестирования и желанием проверять все ошибки версии 1.0. Может быть, приложение изменилось так сильно, начиная с версии 1.0, что некоторые ошибки больше не актуальны? Это следует учитывать при построении регрессионных тестов на основе старых ошибок.

Answer 6

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

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

Answer 7

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

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