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

[Kaluga]

Гы...
Это перл! Друзья, вы только вдумайтесь!

На мне висело (в смысле автоматизации) около 30 крупномасштабных проектов. За год их тестирование было автоматизировано было от 2 до 40% (только для батчевых продуктов, запускающихся из коммандной строки).

Майк, вы работает в МайкроСофт? ;)
И еще где-нить в IBM подрабатываете?..
Мне кажется на территории экс СССР всего-то 30 крупных проектов не набрать... :D

[Mike]

Сомневаюсь, что в Майкрософте один тестер работает с 30 проектами <_< . А вот в том месте где я работал это было так, Вы уж извините :) .

[Kaluga]

...что-то я не увидел там крупных проектов... :D

[Mike]

Kaluga! Не надо придираться к словам. Я вовсе не собирался "гнуть пальцы" (но прийдётся :D ). Да, эти "крупные проекты" - не более чем отдельные коробочные продукты фирмы, занимающей 2-е место на рынке ПО для аналитической химии, чьим софтом пользуется более половины крупных фармацевтических и химических компаний (таких как Pfiser, Glaxo-Welcome, BASF, 3M, Johnson&Johnson и др.) и несколько десятков университетов. Не более того. Это не операционная система Windows, и даже не WebSphere или DB2. :rolleyes: :) .

[Case]

Господа :)
Давайте ещё начнём размерами мобилок мерятся ? :)))
Ну что за ерунда в самом деле :)

Давайте я на эту тему вам расскажу один случай которому я был свидетелем.
Дело было в одной очень сильной конференции по базам данных. Очень професиональная подобралась аудитория - получал очень грамотные ответы и рекомендации. (занимался админитрированием серверов БД в то время).
Пришёл в конференцию как то молодой человек стал гнуть пальцы на предмет размера его БД.
"ну короче, у меня база за 150 мегов. хранимок одних штук 40 и так далее..."
Оговорюсь, для ясности, что работал в то время с базой чуть более гигабайта, хранимок чуть более 150 и считал себя в конференции новичком - ну уж очень серьёзные там дяденьки собрались.
Молодому чеовеку мягко дали понять что тут собрались люди, которые работают с гораздо более серьёзными обьемами и проблемами и при этом никто не кичится размерами своих пузиков.
Забавно было читать один из комментариев завсегдатаев эхи, уже опосля инцидента:
"пришёл паренёк к дядькам экскаваторщикам и давай кичиться размерам своего савочка" :)
С тех пор и стали звать господ завсегдатаев не иначе как экскаваторщиками - очень уважительно так.

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

[solo]

так что ребята, только я да Mike, хоть чего-то добились?
неужели больше никто не пробовал?

А по поводу процентов...
Фактически автоматизировать приложение которое прошло свою
активную фазу(1-2 change requуst-а), можно и нужно автоматизировать
как можно больше.
Надеюсь что к январю смогу похвастаться:)

[Case]

Нет не только вы. Я просто очень затрудняюсь с процентами, так как система постоянно наращивает функционал паралельно с грандиозными переделками архитектуры и я не могу точно сказать какое количество от всех выполняемых тестов мы автоматизировали.
Мы пошли по принципу "автоматизация для тестировщиков, а не тестировщики для автоматизации", то есть разрабатываем в первую очередь те скрипты, которые отнимают много времени на рутину (заполнение многостраничных форм однотипной информацией). То есть при выполнении ручного тестирования мы время от времени используем записанные и отредактированные скрипты, которые просто заменяют наши действия. Выигрыш по времени на проход одного чек листа получается примерно процентов 70%.
Автоматизирована большая часть тестов, которые требуют затрат времени на ввод информации, анализ, что система выдаёт на выходе - то есть анализ отработки логики проводим в ручную.

[allex]

Мне кажется, что вопрос поставлен настолько широко, что не имеет особой ценности :) Уточните, пожалуйста, о чём идёт речь: хочется добиться максимального покрытия с помощью автоматически генерируемых тестов? На основе чего генерируются тесты? Интерфейсы, исходный код, формальная спецификация, другая информация о программе? Мне кажется, что для разных классов программ результаты будут сильно разные.
К примеру, в одном из наших первых проектов тестировалась большая библиотека функций, имеющих параметры простых (скажем, целочисленных) типов. Был написан инструмент, который на основе формальных имплицитных спецификаций этих функций позволял добиться очень хорошего покрытия спецификаций или кода. 80% - достаточно типично. А то и все 100.
Более свежий пример - подсистемы компиляторов.
На основе BNF грамматики языка можно сгенерировать тесты, покрывающие 80% кода парсера. Есть у нас такой инструмент собственного изготовления. Некторое количество ошибок вылавливает, несмотря на то, что парсер - очень простая штука.
Занимались разработкой тестов для оптимизаторов. На основе неформального описания оптимизатора строили модель, по которой генерировались тесты. На gcc проверяли - 60% - типичное покрытие кода. Если немного поковыряться в исходниках компилятора и понять, чем его оптимизатор отличается от общего описания - можно ещё процентов на 10-20 поднять.
Но это не то, что вы называете автотестами, я думаю? :) Поскольку работу довольно большую приходится проделывать.

[Green]

Разрешите вставить свои две копейки... :rolleyes:

Термин Smoke test пошел со времен производства первых электронных устройств. Тест, который они проходили и проходят сейчас в первую очередь, это тест на дым. Включаем аппарат в розетку, если дыма нет, значит можно проверять дальше. От сюда и повелось...

[Green]

Что же касается процентного соотношения автоматизации тест кейсов, то вопрос действительно поставлен не корректно.

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

Проект заключался в написании переводчика со старого стандарта на новый и обратно (GUI отсутствовал как класс :rolleyes: ). Запросы поступали и уходили в виде xml файлов. Правила перевода (в виде XPaths) были описаны в Excel файле и утверждены заказчиком. Общее число правил было где-то пару десятков тысяч (уже точно не помню). Требование заказчика - проверка каждого правила.

Автоматизация просто просилась в проект... Написал целую библиотеку скриптов на JScript. Проект прошел успешно. Библиотекой пользуюсь до сих пор. B)