Python-сообщество

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

Зато, опять же - все делается автоматом. Т.е. перед уходом с работы запускают шарманку - а утром имеют результат. Конечно, сломанные тесты приходится запускать и отлаживать вручную - поэтому предпочтительней иметь юниттесты.

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

poltergeist, глянь еще на openqa.org
Может, какой из инструментов понравится. Я о selenium слышал неплохие отзывы.

+1 за selenium, у нас при предварительной оценке “что будем юзать”, были голоса за selenium. За twill сыграло больше, что у можно единообразно с юниттестами запускать, и сервер/процесс/прокси отдельный не надо (работает через wsgi intercept). Да, у нас js мало, поэтому twill подходит %) Хотя вот сейчас уже хочется и js тестировать :)

Отредактировано (Сен. 4, 2009 19:24:24)

j2a Есть ещё Windmill (http://www.getwindmill.com/), я им сейчас и пользуюсь. Тоже самое, что и селениум, только ближе к питону в общем (потому как на питоне написан) и к джанге конкретно (есть свой тест раннер, авто-загрузка фикстур, остальное можно самому дописать). Но виндмилл и селениум я и считаю не удобными, т.к. чтобы проверить какой-то нюанс в работе приложения, нужно порой делать длительный сетап. К тому же эти тесты на порядки медленнее юнит-тестов, которые проходят в рамках транзакций (setup/teardown происходит оч быстро) и даже без юзания HTTP (ты ведь заметил как в джанге 1.1 “летают” юниттесты:)?). Вот и набегает куча просиженного зря времени и нехотение этим всем заниматься. А js у нас бывает много:(

У нас кстати нет такого отдела QA, сами все виды тестов пишем, поэтому наверное я этим лично так и озадачен.

P.S. юмор: есть у нас в проекте одна страничка, на которой два выпадающих списка - страна где родился и национальность, каждый из которых по ~190 элементов. Попросили сделать тест, который перебирал бы все варианты сочетаний (т.к. на них завязана дальнейшая логика JS), хотя важными являются среди стран только три группы: UK, EU и non EU. Так вот наши работники сделали один тест (один файл) и размножили его скриптом, получилось 190**2 == 36100 тестов (файлов), которые они ещё собирались положить в SVN, хорошо что я вовремя из отпуска вернулся. Вот как так можно?

P.P.S. Windmill оказался очень даже портабельным, я делал специальную сборку для запуска тестов на голой машине без никаких признаков установленного питона на ней (Windows). Работает, причём не нужен никакой внешний сервер для запуска приложения, тестовый сервер автоматом поднимается на локалхосте:)

Отредактировано (Сен. 4, 2009 20:37:34)

Ага, про windmill слышал. Спасибо за наводку, гляну подробнее…

Как я писал - нужны все виды тестов. Модульные, регрессионные и функциональные.
Регрессионные у нас выглядят как пара десятков относительно простых и быстрых функциональных. По регламенту должны запускаться разработчиком перед коммитом. Они же вместе с юниттестами проходят в процессе автоматической ежедневной сборки для QA.

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

Кстати, наш отдел QA насчитывает 4 человека. Что очень немного для компании в сотню людей, половина из которых - программисты. Остальные - аналитики, админы базы данных, наших сервисов и просто админы, тех поддержка, секретари и мальчики из приемной на входе.
Из этих четверых один - начальник. Тестов практически не пишет, присутствует примерно на семи совещаниях за день и чутко держит руку на пульсе.
Еще один - типа программист. В его задачи входит поддержка автозапуска QA тестов и оптимизация времени их исполнения. С моей точки зрения - синекура. Я бы сделал всю его работу “в промежутках между основным занятием” - и часто таки делаю. Быть может, я чего-то недопонимаю и этот мужик вкалывает с утра до вечера не покладая рук - но мне это не видно.
Остаются двое постоянно пашущих QA тестеров - и они эти тесты пишут. Много. Постоянно. И часами сидят рядом с разработчиками - иногда неясно, тест не соответствует спецификации или код. Бывает и так, что тест правильно улавливает ожидания - но подразумеваемая функциональность будет реализована позже, в другой story.
Тестеры думают в терминах работающего приложения - и потому их тесты длинны, сложны и медленны. К счастью приходится иметь дело за раз с тремя-пятью, и это не напрягает. И помогает основное правило юниттестирования: нашел ошибку - зафиксируй ее в юниттесте.
Дополнительная наша сложность - создаваемый продукт является системой по торговле ценными бумагами, и бухгалтерия там жуткая. Сплошь одни циферки - и поди разберись, почему вышло три, а должно было быть 4.43. Мой мозг иногда закипает. Но есть выход - занятся серьезной архитектурной или оптимизациооной задачей - и там привычные программерские трудности :) А делать скушные вещи будет кто-то другой - проект большой, и архитектурных вызовов в нем хватает.

Это я веду к тому, что тестеров много не нужно - может быть хватит и одного толкового. Правда есть подводный камень - либо тестер должен быть с опытом, либо вы сами обязаны его научить.
Я имел неприятный опыт несколько лет назад: взятая на эту должность умная девушка ни разу нам, программистам, не помогла. Программировать умела, в предметной области разбиралась. А пользы - не было. Как я эту ситацию сейчас понимаю - был бы толк. Если б я обладал моими сегодняшними знаниями - сумел бы наладить работу. А тогда ожидал: прийдет тестер - и сразу появится у нас хороший и продуктивный отдел тестирования. При том что сам не понимал, что он должен из себя представлять - но прочитал о полезности и надеялся что “все будет хорошо”. Не получилось… Потерял веру в QA тестирование - и увидел хорошо работающий QA на моей последней работе.
И заново поверил - ибо помогает очень сильно.

P.S.
bialix, который Александр Бельченко, когда-то на третьем exception рассказывал, как устроена система тестирования bazaar. Я прослушал, все понял - но не воспринял до конца. А теперь - понимаю и не представляю даже, как жить без тестов.

Андрей Светлов
Не посоветуешь, какие бы исходники почитать на предмет качественно оформленного тестирования?

Вопрос по buildbot'у. Сегодня впервые столкнулся с автоматическим прогоном тестов.
Что не так: каждый раз получаю

Project matching query does not exist. failed test

LP fan
Зачем вы старую тему подняли?

Судя по всему у вас Django. Задайте вопрос в соответствующем разделе.

Александр Кошелев
Ну просто поиск по слову buildbot выдал только три результата. Один (этот) в форуме Web, и два других в форуме Флейм. Вот я и подумал не создавать новую тему. Вижу таки она меня настигла ))

Да, у меня Django (и мне всего 23 так что мне даже как-то не привычно когда мне пишут “Вы”)