Лучший способ проверить приложение Delphi

У меня есть приложение Delphi, которое имеет много зависимостей, и было бы трудно рефакторировать его для использования DUnit (он огромен), поэтому я думал об использовании чего-то вроде TestComplete AutomatedQA для тестирования из интерфейсного пользовательского интерфейса.

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

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

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

  1. стоит ли?
  2. это был бы хороший способ проверить?
  3. результат теста должен в моей базе данных (Oracle), есть ли простой способ в testcomplete проверить эти значения (несколько полей в нескольких таблицах)?
  4. мне нужно настроить тестовая база данных чтобы выполнить все автоматическое тестирование, будет ли простой способ автоматизировать повторную настройку тестовой БД? Кроме Drop user cascade, создайте пользователя..., impdp.
  5. есть ли способ в testcomplete указать параметры командной строки для exe?
  6. есть ли у кого-нибудь подобный опыт.

7 ответов


Я в аналогичной ситуации. (Большое приложение с большим количеством зависимостей). Автоматизированного тестирования практически нет. Но есть большое желание исправить эту проблему. И именно поэтому мы будем решать некоторые проблемы с каждым новым выпуском.

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

то, что мы сделали:

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

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

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

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


Я бы предложил вам использовать как DUnit, так и что-то вроде TestComplete, поскольку каждый из них служит другой цели.

DUnit отлично подходит для модульного тестирования, но трудно использовать для общего тестирования приложений и тестирования пользовательского интерфейса.

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

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

с большим (существующим) приложением вы находитесь в сложной ситуации в отношении внедрения автоматизированного тестирования.

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


Я не могу ответить на все, так как я никогда не использовал testcomplete, но я могу ответить на некоторые из них.

1 - Да. Регрессионное тестирование того стоит. Вам как разработчику довольно неловко, когда клиент возвращается к вам, когда вы сломали что-то, что раньше работало. Всегда хорошая идея убедиться, что все, что раньше работало, все еще работает.

4-Oracle имеет что-то под названием флешбек, которая позволяет создать точку восстановления в базе данных. После вы сделали тестирование вы можете просто вернуться к этой точке восстановления. Вы можете написать сценарии, чтобы использовать его тоже,FLASHBACK DATABASE TO TIMESTAMP (FEB-12-2009, 00:00:00);, etc


мы рассматриваем использование VMWare для изоляции некоторых наших тестов.

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

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


  1. стоит ли?

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

  1. Это был бы хороший способ проверить?

Я бы сказал, что правильный набор тестов DUnit лучше первый шаг. Однако, если у вас большая кодовая база который не спроектирован для тестирования, настройка функциональных тестов-еще большая боль, чем настройка тестов GUI.

  1. результат теста в моей базе данных (Oracle), есть простой способ в testcomplete проверить эти значения (несколько полей в нескольких таблицах)?

TestComplete имеет интерфейс ADO и BDE. Или вы можете использовать интерфейс OLE в VBScript для доступа ко всему, что доступно.

  1. есть ли способ в testcomplete указать параметры командной строки для exe?

да.


одним из способов интродукции unittesting в (старом) приложении может быть " запуск базы данных "(например, функция" Flashback", описанная Ричом Адамсом). Программа som unittest использует DUnit для управления GUI. Se "тестирование GUI с DUnit" на http://delphixtreme.com/wordpress/?p=181

каждый раз, когда тест запускается путем восстановления в "Start database", потому что тогда можно использовать известный набор данных.


Мне нужно установить тестовую базу данных, чтобы сделать все автоматизированные тестирование, будет ли простой способ автоматизировать повторную настройку тестовой БД?

использовать транзакции: выполнить откат по завершении теста. Это должно вернуть все в исходное состояние.

рекомендуемое значение:

http://xunitpatterns.com/