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

[Kaluga]

Мне интересно, какого покрытия автотестами вам удалось добиться и какие это типы тестов?

[solo]

У нас автоматизированы так называемые "smoke" тест кейсы, это примерно 10% от спецификации по функциональному тестированию. А также load и stress тесты по некоторым проектам.
Мы, к сожалению, только начали, поэтому охват еще не сильно велик :(, но мы работаем над этим:)

[Kaluga]

А кто у вас смоук тесты гоняет - ваша группа или разработчики?

И как вы понимаете лоад и стресс тесты?

[Alpha]

ту solo
Не очень понятно что такое "smoke" тест кейсы

[Kaluga]

to Alpha
Smoke tests - тесты на то, что система хоть как-то работает, что самая-самая ключевая функциональность реализована.

[Case]

И как вы понимаете лоад и стресс тесты?

Мы вроде уже обговаривали эту тему :)

[Kaluga]

Ну...
Это же вы...
А я теперь хочу ее с соло обговорить... ;)

[solo]

Вопросов нет, давайте одговорим:)
Итак:
smoke test - набор тест коейсов охватывающий основную функциональность системы, обычно идет за тестом инсталяции. Он определяет будет ли сисетма тестироваться дальше. Т.е. если какой-либо тест кейс из этого набора не пройдет, то кволити менеджер имеет право зареджектить билд не приступая к другим тестам.
У нас их гоняют как девелоперы, чтобы убедится что ссистема работает, так и мы. Но все больше, к сожелению, проявляется тенденция типа, "ну тестеры же есть, они и проверят:)))".


load: предположим что к системе есть требование, что вроде отклика(записи, чтения, рефреш списков etc.) должно равняться определенному значению при нагрузке от 50 до 500 юзеров. Мы нагружаем систему 500-ми юзерами и проверяем как ведет себя система.

stress: проверка(определение) предельной нагрузки системы, в принципе это силльно похоже на benchmarking. Т.е. например логгинг нескольких тысяч юзеров одновременно, сохранение и т.д.

[solo]

немного перепутал, не "одговорим", а обговорим:)

кстати вообще тестирование организовано так:

- инсталяция
- smoke
- bug regression

- standard
- performance(load, stress)
- secutity
..

Первая часть практически выполняется всегда, вторая в зависимости от назначения билда, сроков и т.д.

Это конечно не идеал, но работает:)

[Олешка]

Делитесь, откуда термин "smoke"? Ссылочку в студию, пожалуйста.

[solo]

Откуда я точно взял это термин уже не помню, наверное вычетал где-то, а по этой ссылочке, например, такая http://www.faqs.org/qa/qa-477.html

[Kaluga]

Да это нормальный термин. У "буржуев" оч. часто встречается.
Возьмите, к примеру,
http://www.qaforums....t=008461#000000

[Олешка]

Ок, спасибо, заглянем к буржуям :)

[Case]

Господа адепты систем автоматизации!
Неужто за 10% никто в своих попытках не вышел?
Особенно интересует мнение товарищей, которые провели сертификацию систем качества, как у вас это получилось без должного уровня автоматизации?

[Mike]

[ Deleted ] - Сорри, форум тормозил, случайно запостил 2 раза... :unsure:

[Mike]

IMHO, за 10-20% и нет смысла выходить. За то уж эти 10-20% процентов должны соответствовать... Нельзя и противопоказано автоматизировать всё. Когда тестов становится много, очень быстро падают как качество анализа результата, так и качество обновления тестов. Мне кажется, что главный вопрос - что автоматизировать. На мне висело (в смысле автоматизации) около 30 крупномасштабных проектов. За год их тестирование было автоматизировано было от 2 до 40% (только для батчевых продуктов, запускающихся из коммандной строки). И по результатам могу сказать, что:
- смоук тесты проходили почти всегда, а когда нет, ручные тестеры обнаруживали баги быстрее. Зато переписывать их (тесты) приходилось довольно часто. Тут, впрочем, понятно - баги в смоуках обычно бывают при тестировании альфа-версии, когда автоматизация проблематична (хотя-бы потому, что ничего не работает :)).

Среди остальных багов, обнаруживаемых автоматическими тестами, по тестам баги распределялись следующим образом
60% - как-бы регрессионные тесты функционала , основанные, как правило, на циклах и больших наборах тестовых данных. Так как к интерфейсу старался не привязываться, переписывать их приходилось реже чем смоуки.
40% - интерфейсные тесты (была написана специальная утилита для захвата интерфейса (методом тыка - бегаем по всем менюшкам и открываем все окна (если элемент меню заканчивается на "...") и изучаем их) и последующего сравнения. Утилитка была хороша тем, что её практически никогда не приходилось переписывать при изменениях (за исключением злобного нарушения стандартов программерами).

В общем, по-моему, автоматизировать надо то, что автоматизируется легко и с удовольствием :) - а это, как правило - длинные рутинные тесты с большим количеством тестовых данных, которые ручным тестировщикам делать скучно и лень (поэтому неэффективно). Так в моей практике был пример теста, который в ручную выполнялся 12 дней(!), а в автоматизированном варианте - 3-4. Речь шла об импорте из ~200 форматов и последующем экспорте ещё в 5. Перебрать надо было всё. А открывались эти файлы минут по 10 (некоторые по 100-200Мb, а машинки у тестеров слабенькие). И кстати, за год тест отловил ~30 багов. Что очень неплохо (хотя в ручную, понятно, отловилось бы раза в 2 больше).

[Case]

Откуда цифры в 10-20% никак не пойму, тем более что вы указали очень серьёзное количество проектов. Как по мне то от специфики проекта зависит очень многое - если у меня консольный интерфейс (команд промтп навсегда) - это один бизнес.
Если сервер приложений, на котором крутится отлаженная логика и известны все вызовы и ожидаемые результаты - другой вариант.

[Mike]

Откуда цифры в 10-20% никак не пойму, тем более что вы указали очень серьёзное количество проектов. Как по мне то от специфики проекта зависит очень многое - если у меня консольный интерфейс (команд промтп навсегда) - это один бизнес.
Если сервер приложений, на котором крутится отлаженная логика и известны все вызовы и ожидаемые результаты - другой вариант.

Согласен. 10-20% я имел в виду для типичных GUI-приложений, для консольных приложений (особенно батчевых) - может быть сильно больше. Сервер приложений - вообще совершенно отдельная тема (тут, кстати, тулзы для функционального тестирования вообще могут не годиться). Что до количества проектов - ну, сколько было <_< . Понятно, 30 проектов на одного "автоматизатора" это перебор, но "перезагруженность автоматизатора" - ситуация совершенно обычная, поэтому (тем более) грамотный отбор тестов на автоматизацию становится решающим фактором, определяющим успех или неуспех автоматизации тестирования вообще.

[Case]

Про "перезагруженность автоматизатора", если можно чуть более подробно - не встречался с терминологией. Смысл понятен, не хочу допридумывать ерунды.

[Mike]

Сорри за дурацкую формулировку :unsure: . Я имел в виду, всего лишь, что 30 проектов на тестировщика, занимающегося автоматизации - перебор ;). А ситуация, когда всего один человек в отделе занимается автоматизацией тестирования, насколько я понимаю, типична.