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