2010-03-09 3 views
0

Когда программное обеспечение разработано, проводятся различные типы тестирования - блок, интеграция, функциональность, руководство. В моем текущем проекте (winforms с sql-сервером), который имеет устаревший код (без тестов), у нас есть много ошибок. Мы пытаемся удалить их с помощью комбинации ручных + тестов (в основном интеграции)Как справиться с такими сценариями?

Но все же некоторые ошибки могут исчезнуть.

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

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

Мысли?

ответ

1

«Должен ли у нас сценарий, запущенный в базе данных, который ищет сценарии, такие как описано?»

Вы имеете в виду «поместить скрипт в базу данных, чтобы исправить проблему», затем no.

NO. Никогда. Ни при каких условиях. Работа над ошибкой, добавив особую специальную логику, действительно очень плохая идея.

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

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

    a. Если вам повезет, вы исправили ошибку, с которой она должна работать, и она будет излишней. Что теперь? Какую копию удалить?

    b. В противном случае это будет противоречить другому коду. Что теперь? Какой правильный?

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

Если вы имеете в виду «написать сценарий в базе данных для тестирования приложения», то да. Для этого нужны сценарии модульного тестирования. Используй их.

Гораздо лучше создавать модульные тесты, чем создавать скрипты, которые вы помещаете в базу данных. Единичные тесты - лучший подход.

+0

«положить скрипт в базу данных, чтобы помочь найти и отладить проблему» - да, это то, что я имел в виду. Но опять-таки такой скрипт должен быть ошибкой (нужно тестирование!) –

+0

@junky_user: Нет, это не требует ошибок. Вы используете его на день, чтобы найти и исправить ошибки, а затем удалить его. –

0

У вас должен быть автоматический набор тестов. В этом тестовом наборе будут реализованы все сценарии, требуемые спецификацией. Поскольку не удается дождаться шести месяцев, чтобы проверить, что работает дисконтирование, фактическая реализация заменяется на реализацию mock (пример представлен в java, но те же принципы применяются и на других языках), что, например, «имитирует», что прошло 6 месяцев , Можно использовать утверждения для автоматизации тестов.

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

 Смежные вопросы

  • Нет связанных вопросов^_^