Особенности тестирования инсталляторов

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

Всем известна народная мудрость: "Встречают по одежке, а провожают по уму". Инсталляционное приложение и есть та самая одежка, по которой создается первое впечатление о Вашем продукте. Именно поэтому тестирование установки - это одна из важнейших задач.

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

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

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

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

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

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

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

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

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

• Установка (Инсталляция)
  1. Наличие достаточных для установки приложения ресурсов таких как: оперативная память, дисковое пространство и т.д. (как тестировать...):
  2. Корректность списка файлов в инсталляционном пакете (как тестировать...):
     1. при выборе различных типов установки, либо установочных параметров список файлов и пути к ним также могут отличаться
     2. отсутствие лишних файлов (проектные файлы, не включенные в инсталляционный пакет, не должны попасть на диск пользователя)
  3. Регистрация приложения в ОС (как тестировать...)
  4. Регистрация расширений для работы с файлами: (как тестировать...)
     1. для новых расширений
     2. для уже существующих расширений
  5. Права доступа пользователя, который ставит приложение: (как тестировать...)
     1. права на работу с системным реестром
     2. права на доступ к файлам и папкам, например %Windir%\system32
  6. Корректность работы мастера установки (Installation Wizard) (как тестировать...)
  7. Инсталляция нескольких приложений за одни заход (как тестировать...)
  8. Установка одного и того же приложения в разные рабочие директории одной рабочей станции (как тестировать...)
• Обновление
  1. Правильность списка файлов, а так же отсутствие лишних файлов: (как тестировать...)
     1. проверка списка файлов при разных параметрах установки
     2. отсутствие лишних файлов
  2. Обратная совместимость создаваемых данных (как тестировать...)
     1. сохранность и корректная работа созданных до обновления данных
     2. возможность корректной работы старых версий приложения с данными, созданными в новых версиях
  3. Обновление при запущенном приложении (как тестировать...)
  4. Прерывание обновления (как тестировать...)
• Удаление (Деинсталляция)
  1. Корректное удаление приложения:(как тестировать...)
     1. удаление из системного реестра установленных в процессе инсталляции библиотек и служебных записей
     2. удаление физических файлов приложения
     3. удаление/восстановление предыдущих файловых ассоциаций
     4. сохранность файлов созданных за время работы с приложением
  2. Удаление при запущенном приложении (как тестировать...)
  3. Удаление с ограниченным доступом к папке приложения (как тестировать...)
  4. Удаление пользователем без соответствующих прав (как тестировать...)
     
     

• Как тестировать Инсталляции

  Воспользовавшись рекомендациями по тому "Что тестировать в инсталляционных программах?", рассмотрим "Как тестировать Инсталляции?".

  • Установка (Инсталляция)
    1. Ресурсы необходимые для установки программного обеспечения должны анализироваться именно в начале инсталляционного процесса. Об этом говорит сайт https://intellect.icu . В случае их нехватки пользователь должен получать соответствующее предупреждение.
    2. Получение списка файлов должно проводиться До, а проверка самих файлов - После установки!
       1. самое правильное - это попытаться получить список файлов от сборщика инсталляционного пакета. Фраза: "Возьмите и составьте список после установки ПО, там все верно" - это провокация и на нее лучше не поддаваться.
       2. если программа содержит файлы подписанные сертификатом от MS, то не исключено, что могут попадаться временные файлы, которые уже не нужны для работы приложения (*.tmp и т.д.). Обратите внимание, что один и тот же инсталляционный пакет может устанавливать под разные ОС разные наборы файлов. Поэтому тестировать надо делать под каждую ОС отдельно.
    3. Практически для любой ОС важна регистрация рабочих библиотек и служебных записей. Например, в ОС Windows вам необходимо будет проверить системный реестр на предмет корректной записи новых данных и регистрации новых/нового приложения.
    4. После установки приложения необходимо проверить правильность регистрации расширений для рабочих файлов установленной программы в ОС. Сделайте двойной щелчок по документу, в результате он должен открыться вашим приложением. Если же вы получите в результате диалог выбора программы для открытия файлов данного типа или же он будет открыт другим приложением, то налицо будет ошибка регистрации расширения в ОС.
    5. По-хорошему инсталляционная программа должна при старте проверять учетную запись пользователя и сразу корректно сообщать о каких-либо проблемах с правами. Но не исключен вариант, что на какие-нибудь служебные папки будут установлены дополнительные ограничения. Можно попытаться самим смоделировать ситуации когда какая-нибудь из папок закрыта для записи, например "\Program Files", "\Windows", "%Windir%\system32", а также проверить как будет себя вести приложение при невозможности записать какие-нибудь из файлов по нужному пути. Не исключен вариант, что без некоторых файлов работоспособность всего приложения не будет нарушена. В этом случае достаточно указать о проблеме с копированием файла(ов) в лог, и НЕ выводить сообщение об ошибке.
    6. Необходимо провести полное Тестирование мастера установки (Installation Wizard)приложения
    7. Достаточно часто встречаются ситуации, когда приложение помимо себя самого ставит еще какой-нибудь продукт. Это может быть, как отдельное стороннее приложение, так и демонстрация своего же продукта. В процессе установки обычно это будет не еще один набор шагов мастера установки, а просто небольшое сообщение, что мол ставится такой-то продукт. При тестировании необходимо будет обратить особое внимание на то, что мы имеем последовательную установку нескольких продуктов. Если первый из них требует перезагрузку после своей установки, то второй может инсталлироваться некорректно, особенно если и там и там ставятся драйвера вглубь системы. Интерес представляют ошибки, возникающие именно на стыке установки двух приложений.
    8. Встречаются приложения, которые можно установить в разные рабочие директории одной и той же рабочей станции, и при этом они будут работать независимо друг от друга, не создавая никаких конфликтных ситуаций. Но это не всегда так. Могут возникать конфликты с доступам к общим ресурсам на диске, в памяти и/или в системе. Все это должно быть протестировано тщательнейшим образом.
  • Обновление
    1. По аналогии с пунктом 2 раздела "Установка (Инсталляция)".
    2. Проверка обратной совместимости включает следующие шаги:
       1. после установки обновления, все ранее созданные приложением объекты, такие как документы, формы, сохранения (если это игра) должны открываться и работать без ошибок. Такое поведение называется обратная совместимость (backward compatibility). Пользовательские настройки должны остаться прежними, конечно если обновления не затрагивали именно их изменение.
       2. созданные в новой версии однотипные документы должны корректно открываться в старых версиях, конечно если целью обновления не стояло изменение формата и структуры файлов. Если же был внедрен новый формат, то в новой версии должна быть реализована возможность сохранения документа в старом формате.
    3. В случае, если обновляемое приложение запущено, пользователь должен получить предупреждение о том, что обновление невозможно, при работающем приложении
    4. Заметим, что процесс обновления может быть остановлен в любой момент, при этом исходное приложение должно остаться не измененным и в рабочем состоянии. Допустим у вас установлено приложение версии 1, вы пытаетесь обновить его до версии 2, но в процессе установки передумали и прервали установку. В этом случае инсталлятор должен вернуть все уже сделанные изменения, почистить использованные для обновления временные файлы и завершить свою работу. При этом приложение версии 1 остается в рабочем состоянии.
  • Удаление (Деинсталляция)
    1. Хорошей практикой считается удаление созданного в процессе инсталляции (регистрационные записи в системном реестре, библиотеки в системных каталогах %Windir%\system32, файлы и т.д.). Условно процесс тестирования деинсталляции можно разбить на несколько частей:
       1. проверка, что из системного реестра удалены, установленные в процессе инсталляции, служебные записи и ссылки на библиотеки.
       2. проверка физического удаления файлов приложения.
       3. проверка того, что после удаления приложения, зарегистрированные во время установки файловые расширения удалены, а ранее существующие (зарегистрированные до инсталляции) - восстановлены.
       4. проверка сохранности данных созданных за время работы с приложением. Вполне вероятно, что лежат они где-то в глубине каталога самой программы. Это могут быть служебные скрипты, сохранения от игр или прочие созданные пользователем данные, удаление которых нанесет урон пользователю. Только предположите, что при удалении MS Office, все Ваши документы будут удалены вместе с ним. Поэтому подобные данные нельзя удалять без подтверждения пользователя.
    2. В случае, если удаляемое приложение запущено, пользователь должен получить предупреждение о том, что удаление невозможно, пока приложение работает.
    3. Стоит проверить поведение инсталлятора, если каталог программы закрыт для удаления по правам доступа. В данном случае процесс удаления не должен производиться, и пользователь должен получить соответствующее сообщение.
    4. Если пользователь не авторизован для удаления приложения, то он должен получить соответствующее сообщение и процесс удаления должен быть прерван.

Тестирование мастера установки или Installation Wizard Testing

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

1. Определить все пути от начала до конца, и затем расставить приоритеты для каждого из них. Это поможет нам избежать излишних затрат и усилий при прохождении низкоприоритеных путей.
2. Забудьте про GUI. Постарайтесь описать тест-кейсы без привязки к интерфейсным элементам. К примеру, GUI контролы checkbox/radiobutton или меню из двух пунктов это просто выбор между true и false, важно то, на что он влияет в конечном счете.
3. Если по результатам прохождения визарда получается какой либо проперти файл (файл, описывающий свойства в виде списка: свойство=значение), который потом передается дальше в процедуру экспорта. В этом случае можно разделить проверки на два этапа - первый, создавать (генерировать) такие проперти файлы и проверять, что экспорт работает правильно. Второй - проверять, что через GUI получаются правильные проперти файлы.
4. Не забудьте заняться таким рутинным видом тестирования визардов, как ходить туда-обратно по страницам:
   1. ничего не меняя, все ответы должны сохраняться;
   2. меняя что-либо на предыдущей странице, на следующей должно произойти адекватное изменение либо сброс ответов.
5. Убедитесь, что визард адекватно реагирует на неправильные ответы и не дает ходить дальше.
6. Кнопка Cancel (Close) должна работать всегда и на всех страницах визарда.
7. Создайте для каждого из возможных путей мастера установки шаблонный результат (в идеале, сделайте их несколько - для разных входных данных). Затем, по возможности, автоматизированно или вручную сравнивайте полученный результат с шаблонным.
8. Выделите те опции, которые не влияют ни на какие другие, и на которые другие не оказывают влияния. Работу этих опций можно будет тестировать изолированно от других.

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

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

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

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

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

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

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

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

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