Эта страница была перенесена на altlinux.org. Текст на freesource.info заморожен.

Автоматическое тестирование программ

Сизиф должен стоять на рабочих машинах, иначе поиск багов и разработка прекратится.

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

%_datadir/rpm-autotest, в который будут класться сценарии для автоматического тестирования пакета.

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

по очереди вызываются все скрипты тестирования.

Продумать сценарий для запуска/завершения графических программ (или то же самое можно сделать с помощью ldd -r на бинарнике?)

Что именно проверять в сценарии

Функциональность программ в командной строке

inkscape, dia, convert (чтобы не повторять bug #6400, bug #2441 соответственно)

Обработку --help

Dmitry Levin:

Программа, корректно обрабатывающая --help, должна

выводить текст в stdout;
завершаться с кодом возврата 0.

При неправильном использовании параметров программа

1. Не должна показывать help.

2. Желательно выводить диагностику об ошибке.

3. Конечно, сообщение об ошибке должно быть отправлено в stderr.

4. Завершаться с кодом не 0

К сожалению, большинство программ нарушают как минимум одно из этих правил.

Способы тестирования

Автоматическое тестирование ПО

Автоматическое тестирование GUI:

см. пакет в Сизифе test-gui-dialog
или средство cxTest для тестирования программ WINE

Для библиотек – метод, поставленный на поток в перловых модулях – тесты, позволяющие убедиться, что функции ведут себя правильно.

Для командной строки – предполагается при сборке пакета выполнять некие проверки (например, вызов команды с различными ключами – всё собираюсь dia так тестировать.

Ссылки

http://www.software-testing.ru/lib/kurskih/testing-start.htm