вторник, 14 декабря 2010 г.

Странный баг в VirtualBox и способ его решения

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


Runtime error opening 'D:\Users\will\.VirtualBox\Machines\XP1\XP1.xml' for reading: -102 (File not found.).
D:\tinderbox\win-3.2\src\VBox\Main\MachineImpl.cpp[679] (Machine::registeredInit).
Код ошибки:
E_FAIL (0x80004005)
Компонент:
VirtualBox
Интерфейс:
IVirtualBox {3f36e024-7fed-4f20-a02c-9158a82b44e6}


Если кто столкнется с подобным, не торопитесь удалять и пересоздавать виртуальную машину. Чтобы решить проблему надо перейти в директорию с настройками проблемной виртуалки. Там будет два файла: <имя машины>.xml-prev и <имя машины>.xml-tmp. То есть при сохранении состояния машины и завершении работы почему-то не был создан файл <имя машины>.xml и именно из-за его остутствия и возникала указанная выше проблема.
В общем, берем и переименовываем -prev Или -tmp в .xml и пользуемся созданной ранее машиной.

upd 07/04/2013:

Вот такое сообщение  об ошибке говорит о том, что скорее всего не найден файл ,
эмулирующий диск для виртуалки (например, vdi-файл)

Не удалось открыть сессию для виртуальной машины
No error info
Код ошибки: 
E_FAIL (0x80004005)
Компонент: 
ProgressProxy
Интерфейс: 
IProgress {c20238e4-3221-4d3f-8891-81ce92d9f913}

пятница, 10 декабря 2010 г.

Башорг о тестировании

Сегодня попалась забавная байка, которая должна понравиться любому тестировщику :)

Суровые российские монтажники: получили задание от начальника установить лампу освещения на входе в здание с автоматом выключения. Есть такие, вырубающие ток в светлое время суток. Собрали, подключили, а так как на дворе светлый день, то проверка прошла на ура. Закрыли датчик шапкой - темно. Лампа включается. Сняли шапку с датчика - светло. Лампа выключается. И с чувством выполненного долга ушли домой. Самый цирк начался поздно вечером, потому что датчик монтажники закрепили прямо над лампой. Всю ночь у дежурного была дискотека: стемнело - датчик лампу зажег, лампа зажглась и стало светло, а стало светло - датчик лампу гасит, ой опять темно - датчик лампу зажигает .... и так от заката до рассвета.

:D

среда, 8 декабря 2010 г.

Selenium RC + Firefox + crond

Некоторое время назад потребовалось обеспечить бесперебойность работы selenium rc на одном из linux-серверов с установленной X-window.
До этого RC вручную запускался вручную либо непосредственно на сервере (DISPLAY :0) либо вручную же через vnc. После перезагрузки сервера или из-за пока неустановленных редких сбоев в самом RC процесс автоматического тестирования нарушался. Для решения проблемы было решено добавить запуск Selenium RC в cron.
В crontab была добавлена соответствующая строчка, запускающая RC-сервер. В этот момент не было учтено , что firefox оконное приложение и требует возможности работать на конкретном дисплее =) Соответственно по крону RC-сервер стартовать не мог. Вернее сам-то сервер стартовал, но запустить X-овое приложение (firefox) без дисплея уже не мог.
Возник вопрос о том, о каком вообще дисплее может идти речь, если приложение запускается в ситуации отсутствия каких-либо X-сессий? На некоторое (короткое) время возможность запуска X-программ из под cron была поставлена под сомнение, но довольно быстро было найдено решение.
В описанной ситуации можно использовать утилиту Xvfb, которая позволяет совершать графические операции в памяти и запускать "иксовые" приложения на виртуальных дисплеях.
Ниже привожу последовательность команд, решившая мою проблему:

Xvfb :1
export DISPLAY=:1
java -jar selenium-server.jar

Таким образом, если SeleniumRC будет запущен из-под cron описанным образом , то запускаемый им firefox будет запускаться на дисплее :1 и послушно выполнять все команды автотеста, с которого при желании можно даже снять скриншоты)

Надеюсь, данная информация кому-нибудь поможет и сэкономит время.

вторник, 7 декабря 2010 г.

Тестирование требований

Перечитываю старую добрую кингу Альфреда Дастина (Elfreide Dusting) "Автоматизированное тестирование программного обеспечения" (Automated Software Testing). Читал ее когда-то очень давно, не имея реального шанса проверить на практике советы и предположения, которые делает автор в своей книге. Сейчас, став чуть более опытным, многое из прочитанного становится более понятным, подтверждающим полученный опыт и "набитые шишки". Особенно понравилась следуюшая мысль (которая для кого-то может показаться банальной):
Программа, в основе которой лежат неточные требования, не будет удовлетворять заказчика или конечного пользователя независимо от качества описания архитектуры или программного кода, составляющего модули приложения (выделил жирным , по-моему , главную фразу предложения:)
Тысячу раз СОГЛАСЕН - так оно зачастую и происходит...
В качестве мер по предотвращению дефектов и проблем с конечным пользователем автор предлагает привлекать тестировщиков (высокой квалификации) с самых ранних стадий разработки ПО. В частности, со стадии составления спецификаций требований. Это мне также кажется верной стратегией, но ее соблюдение требует дополнительных трудозатрат со стороны тестирования. Кроме того, есть и психологический момент - не все разработчики, сисарки, менеджеры видят в тестировщиках людей, способных влиять на архитектурные решения до начала кодирования.
Интересно было бы узнать, насколько распространена практика привлечения сотрудников группы(сектора,отдела) тестирования к фазе составления требований к программному продукту и , соответственно, насколько она эффективна?
Если у кого есть желание поделиться своим опытом и мнением на этот счет, то буду признателен за соответствующие комментарии.

пятница, 26 ноября 2010 г.

Ротация

"На фронте я любил наблюдательного человека посылать. Старый ему видимую обстановку докладывал, а новый свежим взглядом проверял. И представляете, очень удачно это порой получалось. У старого наблюдателя от целого дня напряженного высматривания глаз, что называется, замылился. Он чего и не было замечал, а то что вновь появлялось не видел…». Володя Шарапов :)

Добрый день, коллеги.
Несколько слов о ротации тестировщиков...
При тестировании сложной программной системы , состоящей из множества подсистем , модулей, обеспечивающих функционирование различных бизнес-процессов , команда тестировщиков неизбежно делится на людей, специализирующихся на конкретных частях тестируемой системы. То есть со временем тестировщик начинает узнавать систему все лучше и лучше, но в какой-то отдельной ее части он разбирается лучше других.
Все новые доработки этой наиболее близкой и понятной ему части распределяются на него, он быстрее всех и качественнее всех диагностирует проблемы в этой подсистеме. В общем, его руководителю проще и дешевле дать эту подсистему на откуп. И так для каждой части сложного программного комплекса. В такой ситуации работы по тестированию проходят с максимальной скоростью. Люди досконально знают тестируемые ими части системы и не тратят время на лишние выяснения и ознакомления.
Все хорошо до тех пор, пока у человека не начинается "замыливаться взгляд". Он продолжает быстро справляться с задачами , связанными с его областью, но его тестирование становится все менее въедливым и растет риск пропуска (или намеренного игнорирования) сначала некритичных ошибок , а затем и серьезных проблем. Это ненадуманная проблема - с ней приходилось сталкиваться в реальной практике.
Способ решения довольно прост и напрашивается сам собой. Производить ротацию тестировщиков по подсистемам, время от времени давая им длительное время поработать с поначалу плохо знакомой им частью программного комплекса. При систематическом применении такого подхода средний уровень "знания" тестировщиками программного продукта повышается, люди по-прежнему ценны для компании , но в то же время взаимозаменяемы, им интереснее трудиться и еще много плюсов побольше и поменьше, самый главный из которых состоит в том, что как правило сразу после ротации в каждой подсистеме "новичками" обнаруживаются ошибки казалось бы там, где уже все "вылизано"...
Отмечу, что подобный процесс должен сопровождаться качественным документированием методик тестирования, особенностей реализации и функционирования тестируемых подсистем, для того, чтобы снизить временные затраты на ознакомление.

Так что товарищ Шарапов все сказал правильно =)

вторник, 16 ноября 2010 г.

Первый опыт непрерывной интеграции

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

Для сборки проекта используется кроссплатформенная система сборки CMake (взамен устаревших и более сложных в использовании Autotools), а также две другие утилиты из CMake-семейства: CTest и CDash.
CTest используется для прогона модульных и комплексных автотестов.
CDash для обработки, хранения и отображения результатов автоматических сборок (результатов работы CTest-а).

Для проведения автосборок и сеансов автоматического тестирования выделен отдельный сервер.
cron-настроен на проведение автоматических ночных сборок.
Результаты каждого ночного сеанса тестирования автоматически экспортируются в CDash(в xml-формате) для обработки , архивирования и возможности отображения и анализа в любой момент времени.
Так "система" работает сейчас. Но, как говорится, всегда есть к чему стремиться. Проведение ночных сборок хоть и повышает скорость реакции на "поломки" в коде, но иногда и такая скорость недостаточна.
Сейчас есть желание и потребность прогона сборки после каждого коммита в репозиторий. Проблема в том, что коммиты могут быть многочисленны в течение одного дня и прогонять весь набор тестов (модульных и комплексных) после каждого изменения может стать трудновыполнимой задачей. В связи с этим вижу 2 варианта решения проблемы:

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

Реагирование на появление изменений в репозитории - не проблема. Можно использовать готовые и навороченные решения, либо обойтись собственными скриптами.

В общем, в ближайшее время задуманное будет реализовано.

Комментарии, вопросы, отзывы - милости прошу )

суббота, 13 ноября 2010 г.

Установка TestLink

Коллеги, отвечающие на мой предыдущий пост, помимо разных OpenSource TSS систем упомянули TestLink. Краем глаза мне удалось почитать документацию о нескольких из них, где-то даже попользоваться "демками".. В итоге из всего просмотренного решил более детально остановиться на TestLink. У этого проекта есть демо-версия, но она слишком медленно работает, заполнена кучей демо-данных со всех уголков мира ) и не дает реального представления о том, как система устроена изнутри. В общем, решил поставить и посмотреть. Забегая вперед, скажу , что процесс установки предельно прост и для многих его описание может показаться излишним, но , быть может, кому-то окажется полезным. Поэтому, опишу процесс инсталляции TestLink 1.9 на одном из имеющихся в моем распоряжении хостов:

OS: Debian Lenny9
web server: apache 2.0
php: 5.2.6 (требуется любая версия >= 5.2.0 )
mysql: Ver 14.12 Distrib 5.0.51a, for debian-linux-gnu (i486) using readline 5.2

1. Получение дистрибутива
Скачиваем дистрибутив с офсайта: прямая ссылка на архив
2. Виртуальный хост
  • создаем директорию для виртуального хоста. В моем случае:
    sudo -s
    mkdir /var/www/vhosts/testlink

  • распаковываем содержимое скачанного архива в созданную директорию
  • производим настройку виртуального хоста

    ...
    ServerName testlink:80
    DocumentRoot /var/www/vhosts/testlink
    CustomLog /var/www/vhosts/testlink/logs/access_log combined
    ErrorLog /var/www/vhosts/testlink/logs/error_log

    DirectoryIndex index.html index.phtml index.php
    &ltifmodule mod_php4.c&gt
    php_admin_flag engine on
    php_admin_flag safe_mode on
    &lt/ifmodule&gt
    &ltifmodule mod_php5.c&gt
    php_admin_flag engine on
    php_admin_flag safe_mode on
    &lt/ifmodule&gt
    AllowOverride All
    Options +Indexes FollowSymLinks +ExecCGI
    &lt/directory&gt
    &ltlocation ^/ &gt
    SetHandler mod_php5
    order allow,deny
    allow from all
    &lt/location&gt
    ...

    В моем случае конфиги виртуальных хостов располагаются в отдельных файлах и включаются в главный файл настроек апача.
  • перезапускаем апач чтобы новые настройки вступили в силу

    apache2ctl graceful



3. настраиваем /etc/hosts (для *nix машин) или %windows%\system32\drivers\etc\hosts (для виндовых машин) на клиентской машине для возможности указания teslink в url:
для этого достаточно в указанном файле достаточно прописать

testlink


4. тест url
проверяем доступность инсталляции testlink:
http://testlink/index.php

Должны увидеть форму инсталляции:



Переходим по ссылке New Installation и принимаем лицензионное соглашение.
TestLink распространяется под Gnu GPL. Так что используем на здоровье )

5. Проверка системных требований
После принятия соглашения открывается форма проверки сервера на соответствие требованиям TestLink
Если то или иное требование выполняется, то соответствующий пункт помечается зеленым цветом и магическим словом ОК. В противном случае, видим оранжевые сообщения о том, чего у нас нет и чем это чревато.
Двигаемся по порядку:

Системные требования:
Server Operating System (no constrains) Linux
PHP version OK ( 5.2.0 [minimum version] <= 5.2.6-1+lenny9 [your version] ) Здесь у меня все ок. Web and PHP configuration

Maximum Session Idle Time before Timeout 24 minutes and 0 seconds - (Short. Consider to extend.) - инсталлятор рекомендует мне увеличить пераметр Max Session Idle Timeout - пока не понятно для чего, потому пропускаем мимо ушей и смотрим дальше

Checking max. execution time (Parameter max_execution_time) 30 seconds - We suggest 120 seconds in order to manage hundred of test cases (edit php.ini) - эта рекомендация понятна, но пока некритична (нам еще далеко до "сотен" тест-кейсов ) - решаем проблемы по мере постуления и двигаемся дальше

Checking maximal allowed memory (Parameter memory_limit) OK (128 MegaBytes)
Checking if Register Globals is disabled OK
Checking MySQL Database OK
Checking Postgres Database Failed! Postgres Database cannot be used. - на моем сервере не установлен Postgres. Пока пропускаю этот ворнинг, надеясь, что MySql для корректной работы будет достаточно.

Checking GD Graphic library Failed! GD Graphic library not enabled.
Graph rendering requires it. This feature will be disabled. It's recommended to install it..

- вот тут уже надо вмешаться. Не установлена графическая либа для php. Подозреваю, что не смогу смотреть всякие там графики и отчетики. Хочу, чтобы было все красиво, потому ставим либу:

sudo aptitude install php5-gd

далее добавляем строку extenstion=gd.so в php.ini и перезапускаем Apache.
В результате должны увидеть:

Checking GD Graphic library OK

Checking LDAP library Failed! LDAP library not enabled. LDAP authentication cannot be used. (default internal authentication will works). - С этим предупредением поступаем как с предыдущим - ставим нужную библиотеку (для возможности ldap-аутентификации в будущем):


sudo aptitude install php5-gd


далее добавляем строку extenstion=ldap.so в php.ini и перезапускаем Apache.
В результате должны увидеть:
Checking LDAP library OK

Checking JSON library OK - тут изначально у меня все ок. Если , у кого соответствующая библиотека не установлена, то вы знаете теперь как поступить )

Read/write permissions

Checking if /var/www/vhosts/testlink/gui/templates_c directory exists OK
Checking if /var/www/vhosts/testlink/gui/templates_c directory is writable OK
Checking if /var/www/vhosts/testlink/logs directory exists OK
Checking if /var/www/vhosts/testlink/logs directory is writable OK
Checking if /var/www/vhosts/testlink/upload_area directory exists OK
Checking if /var/www/vhosts/testlink/upload_area directory is writable OK

В общем цель данной страницы визарда установщика: увидеть сообщение "Your system is prepared for TestLink configuration (no fatal problem found)." и нажать Continue. Что и делаем! (Если у кого возникли фатальные проблемы, пишите о них в комментариях, а также о том , как вы их обошли - буду признателен )
Двигаемся дальше...

6. Definition of DB access
О назначении этого шага нетрудно догадаться по его названию - на следующей странице визарда мы должны:

  • Выбрать тип бд - мой выбор "MySQL (5.0 and later)"

  • адрес сервера, где находится наша СУБД - я выбрал localhost (пока все на одном сервере)

  • Указать имя схемы бд (соответствующую схему надо будет создать) - оставляем "testlink"

  • Опционально указать префикс таблиц: оставляем незаполненным

  • В полях "Database admin login" и "Database admin password" указываем логин и пароль админа СУБД для того, чтобы инсталлятор смог автоматически создать нужную схему и все нужные объекты в ней

  • В полях "TestLink DB login" и "TestLink DB password" указываем логин и пароль пользователя схемы из-под которого будет вестись вся внутренняя работа с БД (полет фантазии в выборе логина и пароля =)


Далее убеждаемся что демон (служба) mysql запущена и жмем батон "Process TestLink Setup!"

После этого инсталлятор:
  • создает файл config_db.inc.php в DocumentRoot-дериктории сайта , поэтому убедитесь, что у пользователя, из-под которого у вас запущен apache есть w-права на соответствующую директорию

  • Удаляет все , что есть в бд testlink (внимание! на случай, если вы используете уже существующую бд)

  • Создает все нужные таблицы в бд заново



Видим два предупреждения, касающихся настройки почтовых уведомлений.
Пока пропускаем это.
Переходим по ссылке "Please Click Me" и радуемся тому, что все благополучно установилось.
Логинимся под учеткой admin/admin и приступаем к созданию первого проекта по тестированию.

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

Всем удачи.

среда, 3 ноября 2010 г.

Оптимизация повторного использования тестов

Добрый день!

Все мы знаем , что повторно использовать тесты - хорошая практика, позволяющая экономить ресурсы. Для этого (в частности для этого) мы автоматизируем часть тестов, а остальное документируем и сохраняем для возможности ручной регрессионной проверки в будущем.
Есть идея в своей повседневной практике внедрить некую систему управления тестами, в которой тест - отдельно хранимая сущность, доступная для повторного использования в произвольном количестве тестовых сценариев. То есть, нужна возможность компоновать тестовые сценарии из уже заготовленных тестов , как из кирпичиков.
Сейчас в своей профессиональной деятельности использую *.odt и *.doc форматы для хранения тестовых сценариев. Зачастую сталкиваюсь с ситуацией, когда один и тот же тест приходится копировать в разные сценарии. А при необходимости актуализации теста (например, в связи с изменениями в тестируемой системе) приходится актуализировать целый ряд документов. Этот "мартышкин труд" уже порядком надоел. Тем более, на одной из конференций, посвященной QA , я познакомился с решением для поддержки тестирования из MS Team Foundation Server 2010 и был , признаться , печатлен той степенью автоматизации поддержки тестирования, которой удалось достичь разработчикам VS2010.
По ряду причин продукция Microsoft нам не подходит. В связи с этим нахожусь в поиске упрощенных openSource и , возможно, платных (неполных) аналогов TFS. Полнейшая автоматизация traceability требований, кода и тестов на данный момент не цель. Главное - возможность повторного использования описаний тестов ;)
Если кто-то сталкивался с похожими проблемами, буду признателен за совет, отзыв , мнение.

вторник, 22 июня 2010 г.

Слишком умная мозилла (к вопросу о кроссброузерности)

Основным броузером для отладки и тестирования веб-интерфейса нашего продукта является Firefox. Недавно опытным путем выяснилась одна его особенность: дописывать закрывающие '>' для html-тегов.

Выявили так: была сделана доработка, протестирована вручную под Firefox. Написан Seleinum-автотест , который был прогнан на IE - тест провалился.
Причина - не был закрыт один из тегов td из-за чего не отобразился на форме один из ключевых контролов.
Этот же тест затем провалился и на Opera.

Вопрос, на что лучше - этот "искусственный интеллект" Мозиллы, позволяющий все-таки работать с формой, имеющей мелкие недоработки, или более четкое соблюдение стандартов в IE и Opera ?

пятница, 4 июня 2010 г.

Кроссброузерность selenium-автотестов

С некоторых пор мы начали процесс автоматизации функционального тестирования нашего веб-интерфейса. Проводили разведку боем. Автоматизировали определенную часть функционала и временно приостановили работы по автоматизации, для того чтобы посмотреть как этот набор тестов поведет себя в реальной жизни. НАсколько будет устойчив к изменениям в интерфейсе, насколько продуктивен в диагностике проблем. В общем спустя времени , получив результат, поняли, что очень даже стоит продолжить начатое. Первоначально все тесты прогонялись под Firefox. Сейчас же решили включить аналогичные проверки на IE. Первый пробный запуск автотестов (без какой либо переделки и доводки) показал, что существенная часть тестов не прошла , причем большая часть - из-за особенностей IE (первый прогон был на v.6.0)... Радужное настроение немного померкло, перспектива затачивать скрипты отдельно под каждый броузер не слишком впечатляет) .. Ну что же, это небольшой вызов - будем разбираться, придумывать рецепты, которыми я обязательно поделюсь!

пятница, 23 апреля 2010 г.

Дни Качества в Майкрософт)

В конце марта месяца 2010 посетил конференцию MS QA Days в Москве в Крылатском. Не являясь активным пользователем технологий MS ни в быту ни в работе, тем не менее нашел 2 из 4х докладов несомненно полезными для себя: первый - "Стратегические соображения о тестировании и готовности программного обеспечения к эксплуатации” (Strategic thoughts on testing and software readiness)" (Григорий Мельник) и последний - "BDD или элегантные тесты на доменную модель" (Андрей Бибичев). Второй доклад был откровенно скучным и автор явно был не совсем к нему готов, что вызывало желание поскорее дотянуть до кофе-брейка , дабы не уснуть. Третий доклад был откровенной рекламой одного из продуктов MS представителем Quest Software - живенько, наглядненько, но "мне это не подходит" (с)

Программа и видео презентации можете найти на оф.сайте мероприятия...

http://msqadays.ru/program.shtml

пятница, 9 апреля 2010 г.

IE и cookie

В моей тестовой лабе имеется хост для тестирования веб-интерфейса,содержащий подчеркивания в имени... В код веб-интерфейса была добавлена поддержка куков.. проверяю... В мозилле все ок, в опере все ок, в хроме и сафари тоже все ок... Один IE 6,7,8 делает вид, что куков, которые ему отправляются просто нет.. ДЕлает вид, и молчит) Ковыряюсь в настройках безопасности, разрешаю ему все что можно разрешить броузеру.. Все равно, не работает....
В итоге, оказалось, что проблема в том, что в имени хоста были подчеркивания )... То есть, IE молча решил что раз имя хоста не соответствует стандартам, то с этим сайтом можно в принципе работать... но без кукисов)))
Уж не знаю, хвалить за такое молчаливое качество IE или ругать)