Стратегии для тестирования против живой системы - PullRequest
2 голосов
/ 02 декабря 2009

Позвольте мне описать сценарий:

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

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

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

Итак, мой вопрос:

Как вы проводите какое-либо тестирование (ручное или автоматическое) нашего приложения VB.NET на этих действующих системах?

Ваши предложения будут оценены.

Ответы [ 2 ]

2 голосов
/ 02 декабря 2009

Давайте начнем с того, что поставим под сомнение ваше предположение «Невозможно имитировать логику ни в одной из этих систем».

Конечно, вы можете имитировать поведение, если используете правильные инструменты. Ваша система взаимодействует с базой данных посредством объекта базы данных; Ваша система должна взаимодействовать с веб-службой через объект веб-службы. Любой из этих объектов или оба из них могут быть смоделированы посредством использования соответствующей среды для имитации. Для любого вызова модульного теста для объекта базы данных вы создаете макет для этого объекта, устанавливаете его ожидания и результат для вызова, а затем передаете макет своему тестируемому коду (CUT) вместо «реального» объекта базы данных. Ваш код вызывает макет, который затем сравнивает свои аргументы с заранее установленными ожиданиями и возвращает ожидаемый результат (вместо фактического взаимодействия с базой данных). Ваш код затем воздействует на результат. Если аргументы метода не соответствуют ожиданиям, фиктивный объект выдаст исключение.

Вы можете прочитать статьи о фиктивных объектах и ​​модульном тестировании для .Net здесь:

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

Возможно, вы захотите поговорить с вашим поставщиком веб-услуг - каждый сторонний веб-сервис, с которым я когда-либо взаимодействовал, кроме простых запросов, имел тестовый режим (вы используете тестовые учетные данные и тестовый сервер вместо действующего сервера) , Любые транзакции на тестовом сервере очищаются в конце дня. Если они не предлагают тестовую услугу И , то их услуга включает в себя не только простые запросы, тогда я настоятельно рекомендую найти другого поставщика услуг.

Существует еще одна стратегия, которую вы можете использовать для работы с базой данных при определенных обстоятельствах: использовать транзакции. Когда вы открываете соединение с базой данных во время модульного теста, открывайте транзакцию. В конце каждого юнит-теста откатывайте транзакцию. Это простая идея, но дьявол кроется в деталях, и будет хаос, если вы облажаетесь и случайно совершаете транзакцию. Я не рекомендую, но я работал в течение 2 лет над одним проектом.

0 голосов
/ 02 декабря 2009

Похоже, вы создаете бизнес-приложение: программное обеспечение, которое будет использоваться в одном месте одной компанией. В этом сценарии тестирование не так уж важно. Лучшие тестировщики обнаруживают около 20% проблем в вашем коде, поэтому независимо от того, тестируете вы или нет, вы все равно должны быть готовы к решению проблем в работе.

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

  1. Создание действительно хорошей регистрации. До половины кода может иметь дело с обработкой исключений и ведением журнала. Если можете, войдите в базу данных.
  2. Создание много-много проверок согласованности. Чем больше предположений вы проверите, тем лучше. Когда вы выполняете операцию записи (например, размещаете заказ веб-службы), удваивайте количество чеков. Если проверка не удалась, полностью остановите приложение. Не хромайте: остановитесь и проанализируйте, что пошло не так.
  3. Разрабатывайте приложение по одной части за раз. Протестируйте каждую часть в тесном сотрудничестве с конечными пользователями. Сначала протестируйте несколько элементов вручную; затем 10; затем 100; и если вы и конечные пользователи счастливы, включите его.

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...