Сообщений в теме: 30

[Jackie]

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

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

Green, очень интересная мысль.
У меня возник вопрос: Не приведет ли это к излишней сложности тест-кейсов и скриптов? А любое усложнение - это временные задержки...

Спасибо.

[Jackie]

Вы на практике это используете? То есть, Ваш заказчик, вместо того, что бы решать свои ежедневные задачи, тестирует Ваш продукт?

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

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

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

[Kaluga]

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

Ну... Заказчик может идти навстречу Вам, проводя бета-тестирование, может - нет...
А вообще, это уже ОФФтопик.

[Kaluga]

А в случае изменения продукта вы так же будете помимо исправления основных тестов, исправлять еще и экзешник. Иными словами, дублировать свою работу?

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

Воля Ваша, нравится - используйте.

А я Вас, кстати, и не убеждаю использовать.

[Jackie]

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

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

А я Вас, кстати, и не убеждаю использовать.

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

[Kaluga]

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

Вы я так понимаю противник автоматизации вообще? Зачем писать тесты, когда можно и ручками? И без всяких там заморочей...
По существу. Это может облегчить, к примеру, передачу тестов от группы автотестирования группе "простого" тестирования.
Есть еще случаи, в которых применение оправданно. Но каждый надо рассматривать.

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

Ну что же Вы сами-то не представились?

Решил перефразировать. "много воды утекло", "периодически пытаются"... как Вы это связываете со мной? Мало ли кто там и что пытается? Вы их и спросите что там и как. Причем здесь я-то? Если Вы скажете, что экзешник при мне не работал и еще и аргументируете, то будет о чем говорить.
Можете здесь (это будет ОФФтопик), можете личкой

Сообщение отредактировал Kaluga: 14 февраля 2006 - 16:22

[Green]

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

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

Green, очень интересная мысль.
У меня возник вопрос: Не приведет ли это к излишней сложности тест-кейсов и скриптов? А любое усложнение - это временные задержки...

Спасибо.

А кому сейчас легко?


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

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

На мой взгляд такой подход (который, кстати, называется Data Driven Testing) оправдан только в случае масштабной автоматизации долго живущего приложения. В этом случае выгода может быть получена при последующей эксплуатации тестового фреймворка. Создав его один раз, можно наращивать объем тестов всего лишь добавляя новые условия в управляющую таблицу.
Мечта!

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

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

[Jackie]

Вы я так понимаю противник автоматизации вообще? Зачем писать тесты, когда можно и ручками?

Помилуйте, какой же тестер не любит быстрой... автоматизации?
Другое дело, что я не сторонник огульной автоматизации всего и вся.
Я стараюсь не забывать о главной задаче тестирования - о повышении качества продукта. И любое нововведение я рассматриваю именно с этой точки зрения: Будет ли оно способствовать повышению качества продукта? Ускорит ли оно тестирование?

[Jackie]

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

[Kaluga]

И любое нововведение я рассматриваю именно с этой точки зрения:  Будет ли оно способствовать повышению качества продукта? Ускорит ли оно тестирование?

Такими вопросами все задаются. И каждый находит ответ исходя из своего личного опыта. Общего решения нет, мне кажется.
ПыСы Я, кстати, не сторонник 100 процентной автоматизации.

[Guriy]

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

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

Green, очень интересная мысль.
У меня возник вопрос: Не приведет ли это к излишней сложности тест-кейсов и скриптов? А любое усложнение - это временные задержки...

Спасибо.

Если не заставлять скрипты разбираться в бизнес логике думаю не приведет.

Есть типичный список проверок где набор тестовых данных зависит от типа контрола, - например проверка валидаторов.
Почему бы проверку всех 29 февраля 2001 года не отдать скрипту?