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

[iFomin]

Каждый, кто хоть раз сталкивался с задачами автоматизации тестирования, неизбежно встречал и сопутствующие проблемы. Чем больше опыта и выше профессионализм – тем сложнее проблемы.
За 4 года работы в отрасли докладчику довелось повидать немало самых разных трудностей – от тривиальных технических, решаемых парой строчек кода, до глобальных, требующих существенных изменений в масштабах всего отдела разработки. Тем не менее, ни одной проблемы не осталось нерешенной, и ни одного заказчика автоматизации не осталось недовольным.
Хотите узнать, как? Приходите на семинар. Услышите как о конкретных примерах решения проблем, так и рассуждения о методиках, которые позволяют их избежать. Жаждeте поделиться своим опытом? Возможность представится. Есть проблемы с автоматизацией? Приносите их с собой и выкладывайте на «стол». Обсудим, и обязательно решим.
Доступна Презентация
Доступна Аудио запись

На самом деле, обсуждений было чуть меньше, чем могло бы, может, продолжим здесь?

[OVA]

Ну давай про автоматизацию exploratory тестов, чо

[iFomin]

Ок, вбрасываю:

0) Почему бы эксплоратори тесты не заменить на бета-тесты среди кучки лояльных пользователей?

1) Автоматически собираем полную статистику действий пользователей
2) Переводим в более высокоуровневый формат (чтобы отвязаться от конкретных элементов интерфейса)
3) На новой версии запускаем некоторую выборку из собранных логов действий пользователей
4) Если интерфейс изменился (незначительно) - правим драйвер выполнения теста для измененных элементов. Пункт 2 в этом случае должен помочь поддерживать совместимость со старыми логами.
5) Вместо реальных пользователей логи можно собирать с кого-нибудь другого. Например, с ручных тестировщиков в прошлой итерации.

[OVA]

Ненене. Я про всякие oracle based тесты и прочее. Как у Робинсона про тестирование карт и подсказок поиска.

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

[iFomin]

Ненене. Я про всякие oracle based тесты и прочее. Как у Робинсона про тестирование карт и подсказок поиска.

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

Про Робинсона и Harthy я ничего не знаю, простите, мне очень стыдно.

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

Мы сами верстку автоматически не тестировали (не настолько критично, т.к. кривая верстка напрямую не влияет на бизнес), но я бы делал так:
1) Большая кнопка "страница у меня кривовата", которая показывается тестерам и пилотной группе пользователей, т.е. бета-тестерам
2) При нажатии на нее по возможности сохраняем все данные, которые можем (страница, на которой пользователь, скомпилированный код страницы, состояние текущей сессии, скриншот и т.д.) и куда-нибудь шлем, чтобы можно было легко воспроизвести проблему.
3) Если проблему распознали - пробуем написать чекпоинт, который эту проблему может отловить.
4) Прогоняем этот чекпоинт на том множестве страниц, на котором можем.
5) Исправляем проблему
6) Включаем чекпоинт в регрессию

Как-то так.

[OVA]

Html5 тоже решаемо для кроулеров.
Ну и обычный кроулер делает не базовое тестирование верстки (даже не по чеклисту, кроулеры нынче умные и некоторые даже JS пускать могут по поводу и без), а тупое сравнение DOM (до и после), а это совсем не торт.

Про робинсона и Harthy вот например:
http://www.harryrobi...mation-CAST.pdf
http://blog.betterso...ttachment_id=24

UPD: А вообще оба предложения от вас в этом топике пока сводятся к записи за бета-тестерами. Меня это несколько настораживает.

[iFomin]

Спасибо, ссылки классные, почитал.

Робинсон навеял пару идей, хоть и довольно тривиальных:
1) Для каждого ребра графа состояний выделять альтернативные методы перехода, и во всех автоматизированных сценариях использовать случайно один из этих методов (мы обычно используем более длинный и медленный, если быстрый не сработал/сломался, либо выбираем один из них в зависимости от контекста запуска)
2) В (каждой) вершине графа состояний выделить набор действий, который не меняет это состояние (либо меняет, а потом приводит обратно в то же самое). Затем во все уже написанные сценарии внедрить вызовы таких наборов действий (которые, в общем случае, тоже являются графами состояний: рекурсия). Получается этакий управляемый monkey-testing.

А вообще оба предложения от вас в этом топике пока сводятся к записи за бета-тестерами. Меня это несколько настораживает.

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

[LeshaL]

UPD: А вообще оба предложения от вас в этом топике пока сводятся к записи за бета-тестерами. Меня это несколько настораживает.

Если я правилно понял то, о чем говорит Илья, то речь идет больше о телеметрии (термин из формулы-1), т.е. когда работающая программа сама про себя собирает статистику и может делиться ею с создателем (с маленькой буквы :). Буквально сегодня меня IntelliJ IDEA спросила не хочу ли я им помочь сделать мир лучше, отправляя статистику использования функций программы и информацию о сбоях. Ну я не против того, чтобы мир стал лучше.

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

Илья, поправь, если я неправильно понял идею.

И вот, кстати, замечательный доклад на схожую тему от Романа Юферева:

[OVA]

Робинсон навеял пару идей, хоть и довольно тривиальных:

Робинсон вообще классный и у него есть чего еще на сайте пошарить. В принципе все что вы тут про графы написали у него там есть и даже больше :). И что самое примечательное, то большая часть "умных" тестов по моему личному опыту довольно простые и в техническом плане и идея сама (хотя идея очень часто не очевидна, тут ньюанс, да).

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

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

UPD: Заодно и Леше ответил)

[iFomin]

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

Формулы-1 я фанат не большой, но идея у меня была именно такая, да.

За ссылку спасибо, посмотрю!

[LeshaL]

...
а любой честный буржуй от таких предложений обычно начинает сильно параноить.

Не соглашусь. 10+ лет назад я начинал работать тестером в компании Тугезерсофт. Делали UML/CASE тул (кстати никто еще лучше так и не сделал). В программе был специальный механизм для отсылки фидбека, если выскочил java exception.
Присылали и много. Мой коллега даже написал автосабмитер таких багов, который конечно дупликаты умел находить. Фиксили их кстати тоже, а не забивали.
Причем иногда до интересного доходило, разработчик видя стэк-трейс мог рассказать как баг воспроизвести можно. А иногда никто не понимал почему программа вырабатывала исключение в месте, где его не ожидалось.

[OVA]

Не соглашусь. 10+ лет назад я начинал работать тестером в компании Тугезерсофт. Делали UML/CASE тул (кстати никто еще лучше так и не сделал). В программе был специальный механизм для отсылки фидбека, если выскочил java exception.
Присылали и много. Мой коллега даже написал автосабмитер таких багов, который конечно дупликаты умел находить. Фиксили их кстати тоже, а не забивали.
Причем иногда до интересного доходило, разработчик видя стэк-трейс мог рассказать как баг воспроизвести можно. А иногда никто не понимал почему программа вырабатывала исключение в месте, где его не ожидалось.

Ну это немного не то). Такое есть и в общем-то практически повсеместно. Сами похожее используем (даже какую-то логику накрутили чтобы оно автоматом сотни дубликатов не плодило в багтрекере). Но статистику толком так собрать не получится. И опять же:
1. Unhandled Exception'ы такие штуки не ловят. То есть если мы где-то что-то недозавернули, то мы об этом можем никогда и не узнать, а у пользователя случится ой и он будет ругаться в саппорт.
2. Мы так можем получить только баги которые явно приводят к ошибке. Косяки бизнес-логики когда приложение ошибок не выдает, но работает некорректно мы так отловить не сможем.
3. Мы себя ограничиваем сильно по компонентам программы. Для инстоллера придется писать свою, да и то врятли получится. Если компонент куча, то не всегда есть возможность собирать со всех информацию в кучу, а баг случается на взаимодействии часто.
4. Это все же не статистика. Это какая-то довольно странная выборка, хоть и в определенном смысле интересная.

[iFomin]

Ну это немного не то). Такое есть и в общем-то практически повсеместно. Сами похожее используем (даже какую-то логику накрутили чтобы оно автоматом сотни дубликатов не плодило в багтрекере). Но статистику толком так собрать не получится. И опять же:
1. Unhandled Exception'ы такие штуки не ловят. То есть если мы где-то что-то недозавернули, то мы об этом можем никогда и не узнать, а у пользователя случится ой и он будет ругаться в саппорт.
2. Мы так можем получить только баги которые явно приводят к ошибке. Косяки бизнес-логики когда приложение ошибок не выдает, но работает некорректно мы так отловить не сможем.
3. Мы себя ограничиваем сильно по компонентам программы. Для инстоллера придется писать свою, да и то врятли получится. Если компонент куча, то не всегда есть возможность собирать со всех информацию в кучу, а баг случается на взаимодействии часто.
4. Это все же не статистика. Это какая-то довольно странная выборка, хоть и в определенном смысле интересная.

У нас софт в большинстве внутренний, поэтому мне и кажется довольно естественной вещью собирать от пользователя все, что кажется необходимым. Понятно, что в аутсорсе это не сработает, но там и понятия качества довольно специфические. Если заказчик принял - дальше уже баги становятся его проблемами.
1. Это очень просто отслеживается статическим анализом. В идеале надо на Throwable всегда ставить стандартный обработчик.
2. Косяки бизнес-логики как раз очень хорошо ловятся статистикой, если есть достаточное количество пользователей. Причем метрики могут быть совсем тривиальными (например, количество денег, заработанных в день). Любой баг, который не приводит к снижению дохода, на самом деле фиксить не обязательно. Что бы там QA не говорил.
3. Если писать инстоллеры на стандартных компонентах, то это и не потребуется же. Там уже все протестировано сотни раз до нас. А те компоненты, которые пишем сами, надо сразу дизайнить для тестабилити, если качество действительно важно.
4. Это не статистика, да. Статистика гораздо интереснее.