Тестирование инсталляции — под инсталляционным тестированием (тестированием установки) подразумевают уровень корректности установки некоего программного продукта в искусственно созданной среде с целью выявления степени ее готовности к эксплуатации.

Тестирование инсталляции (установки) направленно на проверку успешной инсталляции и настройки, а также обновления или удаления программного обеспечения.

Данный вид тестирования используется для проверки установки приложений и программ, как десктопных, так и мобильных.

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

Рассмотрим проверки, которые необходимо проводить при проведении инсталляционного тестирования на примере:

В настоящий момент наиболее распространена установка ПО при помощи инсталляторов (специальных программ, которые сами по себе так же требуют надлежащего тестирования).

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

Особенности тестирование инсталляции (инсталляторов):

Инсталлятор — это «обычная» программа, основные функции которой — Установка (Инсталляция), Обновление и Удаление (Деинсталляция) программного обеспечения.

Являясь обычной программой, инсталлятор обладает рядом особенностей, среди которых стоит отметить следующие:

• Глубокое взаимодействие с операционной системой и зависимость от неё (файловая система, реестр, сервисы и библиотеки).
• Совместимость как родных, так и сторонних библиотек, компонентов или драйверов, с разными платформами.
• Удобство использования: интуитивно понятный интерфейс, навигация, сообщения и подсказки.
• Дизайн и стиль инсталляционного приложения.
• Совместимость пользовательских настроек и документов в разных версиях приложения.
• И многое другое.

Если эти особенности не зарядили Вас на серьезное отношение к тестированию инсталляционных программ, то вот небольшой список рисков, который покажет всю значимость корректной работы инсталляторов:

• риск потери пользовательских данных.
• риск вывода операционной системы из строя.
• риск неработоспособности приложения.
• риск некорректной работы приложения.

В тоже время, как и на любую программу, на инсталлятор накладываются некоторые функциональные требования. Объединив их со списком особенностей, мы получим более полную картину, показывающую объем предстоящих работ по тестированию. Далее, исходя из списка требований, Вам надо будет ответить на вопросы: «Что тестировать?», и только затем — «Как тестировать?».

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

Что тестировать в Инсталляционных программах?

Распишем подробнее, «Что?» необходимо проверить, для оценки правильности работы инсталлятора:

• Установка (Инсталляция).
• Корректность списка файлов в инсталляционном пакете:

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

отсутствие лишних файлов (проектные файлы, не включенные в инсталляционный пакет, не должны попасть на диск пользователя).

• Регистрация приложения в ОС.
• Регистрация расширений для работы с файлами:

для новых расширений.

для уже существующих расширений.

• Права доступа пользователя, который ставит приложение:

права на работу с системным реестром.

права на доступ к файлам и папкам, например %Windir%\system32.

• Корректность работы мастера установки (Installation Wizard).
• Инсталляция нескольких приложений за одни заход.
• Установка одного и того же приложения в разные рабочие директории одной рабочей станции.
• Обновление.
• Правильность списка файлов, а так же отсутствие лишних файлов:

проверка списка файлов при разных параметрах установки.

отсутствие лишних файлов.

• Обратная совместимость создаваемых данных:

сохранность и корректная работа созданных до обновления данных.

возможность корректной работы старых версий приложения с данными, созданными в новых версиях.

• Обновление при запущенном приложении.
• Прерывание обновления.
• Удаление (Деинсталляция).
• Корректное удаление приложения:

удаление из системного реестра установленных в процессе инсталляции библиотек и служебных записей.

удаление физических файлов приложения.

удаление/восстановление предыдущих файловых ассоциаций.

сохранность файлов созданных за время работы с приложением.

удаление при запущенном приложении.

удаление с ограниченным доступом к папке приложения.

удаление пользователем без соответствующих прав.

Как проводить тестирование инсталляции?

Получение списка файлов должно проводиться До, а проверка самих файлов — После установки.

Самое правильное — это попытаться получить список файлов от сборщика инсталляционного пакета. Фраза: «Возьмите и составьте список после установки ПО, там все верно» — это провокация и на нее лучше не поддаваться.

Если программа содержит файлы подписанные сертификатом, например от MS, то не исключено, что могут попадаться временные файлы, которые уже не нужны для работы приложения (*.tmp и т.д.). Обратите внимание, что один и тот же инсталляционный пакет может устанавливать под разные ОС разные наборы файлов. Поэтому тестировать надо делать под каждую ОС отдельно.

Практически для любой ОС важна регистрация рабочих библиотек и служебных записей. Например, в ОС Windows вам необходимо будет проверить системный реестр на предмет корректной записи новых данных и регистрации новых/нового приложения.

Если при открытии документа, на работу с которым рассчитана ваша программа, вы получите в результате диалог выбора программы для открытия файлов данного типа или же он будет открыт другим приложением, то налицо будет ошибка регистрации расширения в ОС.

По-хорошему инсталляционная программа должна при старте проверять учетную запись пользователя и сразу корректно сообщать о каких-либо проблемах с правами. Но не исключен вариант, что на какие-нибудь служебные папки будут установлены дополнительные ограничения. Можно попытаться самим смоделировать ситуации когда какая-нибудь из папок закрыта для записи, например «\Program Files«, «\Windows«, «%Windir%\system32«, а также проверить как будет себя вести приложение при невозможности записать какие-нибудь из файлов по нужному пути. Не исключен вариант, что без некоторых файлов работоспособность всего приложения не будет нарушена. В этом случае достаточно указать о проблеме с копированием файла(ов) в лог, и НЕ выводить сообщение об ошибке.

Необходимо провести полное Тестирование мастера установки (Installation Wizard) приложения.

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

Встречаются приложения, которые можно установить в разные рабочие директории одной и той же рабочей станции, и при этом они будут работать независимо друг от друга, не создавая никаких конфликтных ситуаций. Но это не всегда так. Могут возникать конфликты с доступам к общим ресурсам на диске, в памяти и/или в системе. Все это должно быть протестировано тщательнейшим образом.

Обновление

Проверка обратной совместимости включает следующие шаги:

• После установки обновления, все ранее созданные приложением объекты, такие как документы, формы, сохранения (если это игра) должны открываться и работать без ошибок. Такое поведение называется обратная совместимость (backward compatibility). Пользовательские настройки должны остаться прежними, конечно если обновления не затрагивали именно их изменение.
• Созданные в новой версии однотипные документы должны корректно открываться в старых версиях, конечно если целью обновления не стояло изменение формата и структуры файлов. Если же был внедрен новый формат, то в новой версии должна быть реализована возможность сохранения документа в старом формате.
• В случае, если обновляемое приложение запущено, пользователь должен получить предупреждение о том, что обновление невозможно, при работающем приложении.

Заметим, что процесс обновления может быть остановлен в любой момент, при этом исходное приложение должно остаться не изменённым и в рабочем состоянии. Допустим у вас установлено приложение версии 1, вы пытаетесь обновить его до версии 2, но в процессе установки передумали и прервали установку. В этом случае инсталлятор должен вернуть все уже сделанные изменения, почистить использованные для обновления временные файлы и завершить свою работу. При этом приложение версии 1 остается в рабочем состоянии.

Удаление (Деинсталляция)

Хорошей практикой считается удаление созданного в процессе инсталляции (регистрационные записи в системном реестре, библиотеки в системных каталогах %Windir%\system32, файлы и т.д.). Условно процесс тестирования деинсталляции можно разбить на несколько частей:

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

Стоит проверить поведение инсталлятора, если каталог программы закрыт для удаления по правам доступа. В данном случае процесс удаления не должен производиться, и пользователь должен получить соответствующее сообщение.

Тестирование мастера установки (Installation Wizard)

В большинстве случаев инсталлятор представляет собой приложение в виде мастера (Wizard), которое может обладать специфическими требованиями, рекомендации по тестированию которых рассмотрены ниже:

Умные люди писали: «Визарды — это зло». С этим можно соглашаться или нет, но тестировать их все равно приходится. Предлагается следующий план тестирования инсталляционного визарда:

• Определить все пути от начала до конца, и затем расставить приоритеты для каждого из них. Это поможет нам избежать излишних затрат и усилий при прохождении низкоприоритеных путей.
• Забудьте про GUI. Постарайтесь описать тест-кейcы без привязки к интерфейсным элементам. К примеру, GUI контролы checkbox/radiobutton или меню из двух пунктов это просто выбор между true и false, важно то, на что он влияет в конечном счете.
• Если по результатам прохождения визарда получается какой либо проперти файл (файл, описывающий свойства в виде списка: свойство=значение), который потом передается дальше в процедуру экспорта, в этом случае можно разделить проверки на два этапа — первый, создавать (генерировать) такие проперти файлы и проверять, что экспорт работает правильно. Второй — проверять, что через GUI получаются правильные проперти файлы.
• Не забудьте заняться таким рутинным видом тестирования визардов, как ходить туда-обратно по страницам:

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

• Убедитесь, что визард адекватно реагирует на неправильные ответы и не дает ходить дальше.
• Кнопка Cancel (Close) должна работать всегда и на всех страницах визарда.
• Создайте для каждого из возможных путей мастера установки шаблонный результат (в идеале, сделайте их несколько — для разных входных данных). Затем, по возможности, автоматизированно или вручную сравнивайте полученный результат с шаблонным.
• Выделите те опции, которые не влияют ни на какие другие, и на которые другие не оказывают влияния. Работу этих опций можно будет тестировать изолированно от других.

Кросс-платформенное тестирование инсталляторов

Отдельным пунктом хочется выделить кросс-платформенное тестирование инсталляторов, которое обязательно должно проводиться для всех трех функций — установка, обновление и удаление:

• Корректность работы инсталлятора с различными версиями ОС, Сервиспаков (ServicePack) и установленных обновлений.
• Проверка файлов, драйверов и библиотек при установке под разные ОС.
• Проверка прав на доступа к файлам, папкам и к системным записям для разных ОС.
• Проверка установленных на файлы приложения разрешений (Permissions).

Для упрощения процедуры тестирования рекомендуется создать таблицу, где колонками будут идти требуемые конфигурации, а строками — тестовые случаи (test cases) или тестируемые функции. В процессе тестирования на пересечении колонок и строк заполняйте результат, что сможет визуально показать прогресс тестирования и соответствие «кросс-платформенным» требованиям.

Если приложение должно работать в нескольких ОС, то инсталлятор должен проверять необходимый набор функций в процессе своей работы. Возможно, что где-то должен быть установлен какой-нибудь пакет обновлений или просто надо работать с другой библиотекой.

Случай из практики: «Приложение должно быть закрыто для установки на Windows Vista. Запускаем его, программа думает и выдает сообщение, что мол эта версия не будет работать под данной ОС. Все верно, нажимаем Ок. После этого компьютер думает пару секунд и сообщает следующее: „Приложение было некорректно завершено. Давайте попробуем запустить его в режиме совместимости?“ Соглашаемся и запускаем. Автоматически стартует наше приложение еще раз, но на этот раз ставится „на ура“. Не знаем, что и как там делает Vista, но код защиты пришлось переделывать.»

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

Случай из практики: «Для некоторых драйверов есть зависимость от файловой системы, на которой работает ОС. Точнее для некоторых типов ошибок. Был случай, когда на NTFS все прекрасно работало, а на FAT32 нет. Причина была в неверной записи при установке драйвера в реестр.»

Необходимо проверить, что инсталлятор имеет права на доступ к файлам, папкам и к системным записям. Особенно это важно при инсталляции под ОС семейства UNIX, с их жесткими ограничениями в доступе к ресурсам для разных категорий пользователей. При/после инсталляции на unix системах, у файлов должны быть соответствующие разрешения (Permissions). Т.е. если файл предназначен для запуска, то он должен быть запускаемым, если это конфигурационный файл, например, то должны быть разрешения на модификацию и т.д.