Какие средства кто использует для %subj%?

Здравствуйте, Димчанский, Вы писали:

Д>Какие средства кто использует для %subj%?
Кривые ручки

Здравствуйте, kolam, Вы писали:
K>Кривые ручки

Я пока тоже ими Но как-то малопродуктивно.

Здравствуйте, Димчанский, Вы писали:

Д>Какие средства кто использует для %subj%?

TestComplete. После работы с VisualTest'ом на TestComplete'е просто отдыхается, а не работается.

Здравствуйте, Димчанский, Вы писали:

Д>Здравствуйте, kolam, Вы писали:
K>>Кривые ручки

Д>Я пока тоже ими Но как-то малопродуктивно.

Даже интересно стало почему Что же нужно тестировать такое в интерфейсе, где руками малопродуктивно, но продуктивно средствами автоматизированного тестирования? (т.е. я конечно могу сказать когда это так, но Ваш ли это случай?)

Здравствуйте, alpes, Вы писали:

A>Даже интересно стало почему Что же нужно тестировать такое в интерфейсе, где руками малопродуктивно, но продуктивно средствами автоматизированного тестирования? (т.е. я конечно могу сказать когда это так, но Ваш ли это случай?)

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

Здравствуйте, Димчанский, Вы писали:

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

A>>Даже интересно стало почему Что же нужно тестировать такое в интерфейсе, где руками малопродуктивно, но продуктивно средствами автоматизированного тестирования? (т.е. я конечно могу сказать когда это так, но Ваш ли это случай?)

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


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

Здравствуйте, alpes, Вы писали:

A>Стало еще интереснее. Напишите, пожалуйста, потом сколько времени ушло на автоматизацию тестирования. Интересно было бы сравнить со временем, ушедшим бы на тыкание ручками.

Тут, как говорится, и к гадалке не нужно ходить. IMHO, если делать все тесты (в смысле скрипты писать), то времени уйдёт гораздо больше, чем проверить ручками. Но если писать тест своевременно, для каждого нового нововведения, то можно хоть как-то ограничить тыкание ручками. Поэтому я здесь не ставлю вопрос, для чего и когда надо применять тесты, я спрашиваю, что народ вообще использует из средств для тестирования.

Здравствуйте, kolam, Вы писали:

K>После *каждого* исправления конечно сложно... Но достаточно вести лог изменений (в любом случае полезная вещь, не только для тестирования), и незадолго до релиза или по завершеии работы над модулем, пройтись по списку и протестировать все (и сразу ).

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

Здравствуйте, Димчанский, Вы писали:

Д>Я вот думаю, что неплохо было бы постепенно писать хоть часть тестов, чтобы ночью гонять их.
Ну-у-у не знаю. А что GUI сотавляет значительную часть разрабатываемого продукта? Обычно регрессионные тесты покрывают функциональность ядра. И создаются они чтобы быть уверенным что все работает "не смотря на последние изменения".
Для UI создавать регрессионные тесты конечно можно, но при любом изменении "внешенго вида" необходимо тратить время на анализ логов тестирования и переделывать и тесты с учетом последних изменений.

Здравствуйте, Димчанский, Вы писали:

Д>Какие средства кто использует для %subj%?

squish

Здравствуйте, kolam, Вы писали:

K>Здравствуйте, Димчанский, Вы писали:

Д>>Я вот думаю, что неплохо было бы постепенно писать хоть часть тестов, чтобы ночью гонять их.
K>Ну-у-у не знаю. А что GUI сотавляет значительную часть разрабатываемого продукта? Обычно регрессионные тесты покрывают функциональность ядра. И создаются они чтобы быть уверенным что все работает "не смотря на последние изменения".
K>Для UI создавать регрессионные тесты конечно можно, но при любом изменении "внешенго вида" необходимо тратить время на анализ логов тестирования и переделывать и тесты с учетом последних изменений.

Брррр...
Что-то я вообще перестал понимать — а как тестировать функциональность без учета интерфейса? Особенно при тестировании "черного ящика"...

Здравствуйте, новичок_тестер, Вы писали:

_>Брррр...
_>Что-то я вообще перестал понимать — а как тестировать функциональность без учета интерфейса? Особенно при тестировании "черного ящика"...

[Приложение   ]
 ^
 |
[Фасад        ]
 ^
 |
[Движок тестов]
 ^
 |
[Тесты        ]

Итак, у нас есть тестируемое приложение. Есть надстройка над ним — Фасад (см. паттерн Facade) — предоставляющая доступ ко всей функциональности системы посредством набора высокоуровневых процедур. И есть непосредственно движок, который выполняет тесты написанные в высокуровныевых терминах фасада.
Точнее сказать, что тесты в данном случае написаны "на естемтвенном языке" тест кейсов и шагов воспроизведения из баг репорта. Это и есть "поведенческое тестирование" о котором так много гооврили большевики Такой подход позволяет очень быстро создавать новые тесты. Изменения в приложении требуют изменений только в фасаде.

Здравствуйте, kolam, Вы писали:

K>Итак, у нас есть тестируемое приложение. Есть надстройка над ним — Фасад (см. паттерн Facade) — предоставляющая доступ ко всей функциональности системы посредством набора высокоуровневых процедур. И есть непосредственно движок, который выполняет тесты написанные в высокуровныевых терминах фасада.
K>Точнее сказать, что тесты в данном случае написаны "на естемтвенном языке" тест кейсов и шагов воспроизведения из баг репорта. Это и есть "поведенческое тестирование" о котором так много гооврили большевики Такой подход позволяет очень быстро создавать новые тесты. Изменения в приложении требуют изменений только в фасаде.

Повторюсь — тестируется "черный ящик". Доступ к функциональности — только через интерфейс.
Как быть в этом случае?
И потом — программирование на Дельфи обычно не предполагает использование паттернов...

нт> Повторюсь — тестируется "черный ящик". Доступ к функциональности -
нт> только через интерфейс. Как быть в этом случае?
нт> И потом — программирование на Дельфи обычно не предполагает
нт> использование паттернов...

посмотри testComplete.
Там сделано несколько путей для тестирования.

С уважением
Кочмин Александр

Здравствуйте, новичок_тестер, Вы писали:

_>Повторюсь — тестируется "черный ящик". Доступ к функциональности — только через интерфейс. Как быть в этом случае?
Городить фасад над интерфесом средствами того же TestCompletee Open Application.

_>И потом — программирование на Дельфи обычно не предполагает использование паттернов...
Использование паттернов не зависит от среды и платформы разработки. Это универсальные логические конструкции, применяемые при проектировании системы.

Здравствуйте, kolam, Вы писали:

K>Здравствуйте, новичок_тестер, Вы писали:

_>>Повторюсь — тестируется "черный ящик". Доступ к функциональности — только через интерфейс. Как быть в этом случае?
K>Городить фасад над интерфесом средствами того же TestCompletee Open Application.

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

_>>И потом — программирование на Дельфи обычно не предполагает использование паттернов...
K>Использование паттернов не зависит от среды и платформы разработки. Это универсальные логические конструкции, применяемые при проектировании системы.

Здравствуйте, <Аноним>, Вы писали:

А>В этом случае мы возвращаемся к исходному, при изменении интерфейса приложения необходимо изменять тестовые скрипты.
В общем-то да. Хотя, поддержка TС Open Application может снизить объем изменений.