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

Question

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

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

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

Что мы сделали:

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

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

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

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

Answer 3

1. Стоит ли это?

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

2. Это будет хороший способ проверить?

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

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

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

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

Да.

Answer 4

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

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

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

Answer 5

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

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

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

Answer 6

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

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

Рекомендуемое чтение:

http://xunitpatterns.com/

Answer 7

Одним из способов введения юнит-тестирования в (старом) приложении может быть «Начать базу данных» (например, функция «Воспоминания», описанная Rich Adams) Программа som unittest использует DUnit для управления GUI. См. "Тестирование графического интерфейса с помощью DUnit" на http://delphixtreme.com/wordpress/?p=181

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