тестирование. Тестир. инф. систем Метод материалы. Сыркин Илья Сергеевич Тестирование информационных систем методические указания
 Скачать 2.91 Mb.
|
|
portability testing. porta- bility testing: The process of testing to determine the portability of a software product. 1. Уровни проведения тестирования Для клиент-серверных приложений конфигурационное тести- рование можно условно разделить на два уровня (для некоторых типов приложений может быть актуален только один): 1. Серверный. 80 2. Клиентский. На первом (серверном) уровне, тестируется взаимодействие выпускаемого программного обеспечения с окружением, в которое оно будет установлено: 1. Аппаратные средства (тип и количество процессоров, объ- ем памяти, характеристики сети / сетевых адаптеров и т. д.). 2. Программные средства (ОС, драйвера и библиотеки, сто- роннее ПО, влияющее на работу приложения и т. д.). Основной упор здесь делается на тестирование с целью опре- деления оптимальной конфигурации оборудования, удовлетворяю- щего требуемым характеристикам качества (эффективность, порта- тивность, удобство сопровождения, надежность). На следующем (клиентском) уровне, программное обеспече- ние тестируется с позиции его конечного пользователя и конфигу- рации его рабочей станции. На этом этапе будут протестированы следующие характеристики: удобство использования, функцио- нальность. Для этого необходимо будет провести ряд тестов с раз- личными конфигурациями рабочих станций: 1. Тип, версия и битность операционной системы (подобный вид тестирования называется кросс-платформенное тестирова- ние). 2. Тип и версия Web барузера, в случае если тестируется Web приложение (подобный вид тестирования называется кросс- браузерное тестирование). 3. Тип и модель видео адаптера (при тестировании игр это очень важно). 4. Работа приложения при различных разрешениях экрана. 5. Версии драйверов, библиотек и т. д. (для JAVA приложений версия JAVA машины очень важна, тоже можно сказать и для .NET приложений касательно версии .NET библиотеки) и т. д. 3. Порядок проведения тестирования Перед началом проведения конфигурационного тестирования рекомендуется: создавать матрицу покрытия (матрица покрытия – это таблица, в которую заносят все возможные конфигурации); проводить приоритезацию конфигураций (на практике, ско- рее всего, все желаемые конфигурации проверить не получится); 81 шаг за шагом, в соответствии с расставленными приорите- тами, проверяют каждую конфигурацию. Уже на начальном этапе становится очевидно, что чем больше требований к работе приложения при различных конфигурациях ра- бочих станций, тем больше тестов нам необходимо будет провести. В связи с этим, рекомендуем, по возможности, автоматизировать этот процесс, так как именно при конфигурационном тестировании автоматизация реально помогает сэкономить время и ресурсы. Ко- нечно же автоматизированное тестирование не является панацеей, но в данном случае оно окажется очень эффективным помощником. Контрольные вопросы 1. Что такое конфигурационное тестирование? 2. Какие основные цели преследует конфигурационное тести- рование? 3. Что такое матрица покрытия? 82 11. Лабораторная работа №8. «Тестирование установки» Целью работы является изучение тестирования установки ПО. Результатом работы является отчет, в котором должны быть приве- дены исходные коды программы, результаты тестирования установ- ки ПО. Для выполнения работы студент должен изучить приведенный ниже теоретический материал. Отчет сдается в распечатанном и электронном (файл Word) видах. 11.1. Тестирование Установки или Installation Testing Тестирование установки направленно на проверку успешной инсталляции и настройки, а также обновления или удаления про- граммного обеспечения. В настоящий момент наиболее распространена установка ПО при помощи инсталляторов (специальных программ, которые са- ми по себе так же требуют надлежащего тестирования). В реальных условиях инсталляторов может не быть. В этом случае придется самостоятельно выполнять установку программно- го обеспечения, используя документацию в виде инструкций или readme файлов, шаг за шагом описывающих все необходимые действия и проверки. В распределенных системах, где приложение разворачивается на уже работающем окружении, простого набора инструкций может быть мало. Для этого, зачастую, пишется план установки (Deployment Plan), включающий не только шаги по инсталляции приложения, но и шаги отката (roll-back) к предыдущей версии, в случае неудачи. Сам по себе план установки также должен прой- ти процедуру тестирования для избежания проблем при выдаче в реальную эксплуатацию. Особенно это актуально, если установка выполняется на системы, где каждая минута простоя – это потеря репутации и большого количества средств, например: банки, фи- нансовые компании или даже баннерные сети. Поэтому тестирова- ние установки можно назвать одной из важнейших задач по обеспе- чению качества программного обеспечения. Именно такой комплексный подход с написанием планов, по- шаговой проверкой установки и отката инсталляции, полноправно можно назвать тестированием установки или Installation Testing. 83 11.2. Особенности тестирования инсталляторов Инсталлятор – это «обычная» программа, основные функции которой – Установка (Инсталляция), Обновление и Удаление (Де- инсталляция) программного обеспечения. Всем известна народная мудрость: »Встречают по одежке, а провожают по уму». Инсталляционное приложение и есть та самая одежка, по которой создается первое впечатление о Вашем продук- те. Именно поэтому тестирование установки – это одна из важней- ших задач. Являясь обычной программой, инсталлятор обладает рядом особенностей, среди которых стоит отметить следующие: Глубокое взаимодействие с операционной системой и зави- симость от неѐ (файловая система, реестр, сервисы и библиотеки). Совместимость как родных, так и сторонних библиотек, компонент или драйверов, с разными платформами. Удобство использования: интуитивно понятный интерфейс, навигация, сообщения и подсказки. Дизайн и стиль инсталляционного приложения. Совместимость пользовательских настроек и документов в разных версиях приложения. И многое другое. Если эти особенности не зарядили Вас на серьезное отношение к тестированию инсталляционных программ, то хочу привести не- большой список рисков, который покажет всю значимость кор- ректной работы инсталляторов: Риск Потери Пользовательских Данных. Риск Вывода Операционной Системы Из Строя. Риск Неработоспособности Приложения. Риск Не Корректной Работы Приложения. В тоже время, как и на любую программу, на инсталлятор накладываются некоторые функциональные требования. Объе- динив их со списком особенностей, мы получим более полную кар- тину, показывающую объем предстоящих работ по тестированию В большинстве случаев инсталлятор представляет собой при- ложение в виде мастера (Wizard), которое может обладать специфи- ческими требованиями. С современным изобилием персональных компьютеров, серверов и операционных систем, возникла потреб- ность в установки одного и того же программного обеспечения на 84 разные платформы. Для этого инсталляторы должны понимать что и куда они устанавливают в зависимости от окружения. Распишем подробнее, «Что?» необходимо проверить, для оценки правильности работы инсталлятора: Установка (Инсталляция) 1. Наличие достаточных для установки приложения ресурсов таких как: оперативная память, дисковое пространство и т.д. 2. Корректность списка файлов в инсталляционном пакете: a. при выборе различных типов установки, либо установочных параметров список файлов и пути к ним также могут отличаться; b. отсутствие лишних файлов (проектные файлы, не включен- ные в инсталляционный пакет, не должны попасть на диск пользо- вателя). 3. Регистрация приложения в ОС. 4. Регистрация расширений для работы с файлами: a. для новых расширений; b. для уже существующих расширений. 5. Права доступа пользователя, который ставит приложение: a. права на работу с системным реестром; b. права на доступ к файлам и папкам, например %Windir%\system32. 6. Корректность работы мастера установки (Installation Wizard.) 7. Инсталляция нескольких приложений за одни заход. 8. Установка одного и того же приложения в разные рабочие директории одной рабочей станции. Обновление 1. Правильность списка файлов, а так же отсутствие лишних файлов: a. проверка списка файлов при разных параметрах установки; b. отсутствие лишних файлов. 2. Обратная совместимость создаваемых данных a. сохранность и корректная работа созданных до обновления данных; b. возможность корректной работы старых версий приложения с данными, созданными в новых версиях. 3. Обновление при запущенном приложении. 4. Прерывание обновления. 85 Удаление (Деинсталляция) 1. Корректное удаление приложения: a. удаление из системного реестра установленных в процессе инсталляции библиотек и служебных записей; b. удаление физических файлов приложения; c. удаление/восстановление предыдущих файловых ассоциа- ций; d. сохранность файлов созданных за время работы с приложе- нием. 2. Удаление при запущенном приложении. 3. Удаление с ограниченным доступом к папке приложения. 4. Удаление пользователем без соответствующих прав. «Как тестировать Инсталляции?» Установка (Инсталляция) 1. Ресурсы необходимые для установки программного обеспе- чения должны анализироваться именно в начале инсталляционного процесса. В случае их нехватки пользователь должен получать со- ответствующее предупреждение. 2. Получение списка файлов должно проводиться До, а про- верка самих файлов – После установки! a. самое правильное – это попытаться получить список файлов от сборщика инсталляционного пакета. Фраза: «Возьмите и составь- те список после установки ПО, там все верно» – это провокация и на нее лучше не поддаваться; b. если программа содержит файлы подписанные сертифика- том от MS, то не исключено, что могут попадаться временные фай- лы, которые уже не нужны для работы приложения (*.tmp и т. д.). Обратите внимание, что один и тот же инсталляционный пакет мо- жет устанавливать под разные ОС разные наборы файлов. Поэтому тестировать надо делать под каждую ОС отдельно. 3. Практически для любой ОС важна регистрация рабочих библиотек и служебных записей. Например, в ОС Windows вам не- обходимо будет проверить системный реестр на предмет коррект- ной записи новых данных и регистрации новых/нового приложения. 4. После установки приложения необходимо проверить пра- вильность регистрации расширений для рабочих файлов установ- ленной программы в ОС. Сделайте двойной щелчок по документу, в результате он должен открыться вашим приложением. Если же вы 86 получите в результате диалог выбора программы для открытия файлов данного типа или же он будет открыт другим приложением, то налицо будет ошибка регистрации расширения в ОС. 5. По-хорошему инсталляционная программа должна при старте проверять учетную запись пользователя и сразу корректно сообщать о каких-либо проблемах с правами. Но не исключен вари- ант, что на какие-нибудь служебные папки будут установлены до- полнительные ограничения. Можно попытаться самим смоделиро- вать ситуации когда какая-нибудь из папок закрыта для записи, на- пример «\Program Files», «\Windows», «%Windir%\system32», а так- же проверить как будет себя вести приложение при невозможности записать какие-нибудь из файлов по нужному пути. Не исключен вариант, что без некоторых файлов работоспособность всего при- ложения не будет нарушена. В этом случае достаточно указать о проблеме с копированием файла(ов) в лог и НЕ выводить сообще- ние об ошибке. 6. Необходимо провести полное Тестирование мастера уста- новки (Installation Wizard) приложения. 7. Достаточно часто встречаются ситуации, когда приложение помимо себя самого ставит еще какой-нибудь продукт. Это может быть, как отдельное стороннее приложение, так и демонстрация своего же продукта. В процессе установки обычно это будет не еще один набор шагов мастера установки, а просто небольшое сообще- ние, что мол ставится такой-то продукт. При тестировании необхо- димо будет обратить особое внимание на то, что мы имеем после- довательную установку нескольких продуктов. Если первый из них требует перезагрузку после своей установки, то второй может ин- сталлироваться некорректно, особенно если и там и там ставятся драйвера вглубь системы. Интерес представляют ошибки, возни- кающие именно на стыке установки двух приложений. 8. Встречаются приложения, которые можно установить в разные рабочие директории одной и той же рабочей станции, и при этом они будут работать независимо друг от друга, не создавая ни- каких конфликтных ситуаций. Но это не всегда так. Могут возни- кать конфликты с доступам к общим ресурсам на диске, в памяти и/или в системе. Все это должно быть протестировано тщательней- шим образом. 87 Обновление 1. По аналогии с пунктом 2 раздела «Установка (Инсталля- ция)». 2. Проверка обратной совместимости включает следующие шаги: a. после установки обновления, все ранее созданные приложе- нием объекты, такие как документы, формы, сохранения (если это игра) должны открываться и работать без ошибок. Такое поведение называется обратная совместимость (backward compatibility). Поль- зовательские настройки должны остаться прежними, конечно если обновления не затрагивали именно их изменение; b. созданные в новой версии однотипные документы должны корректно открываться в старых версиях, конечно если целью об- новления не стояло изменение формата и структуры файлов. Если же был внедрен новый формат, то в новой версии должна быть реа- лизована возможность сохранения документа в старом формате. 3. В случае если обновляемое приложение запущено, пользо- ватель должен получить предупреждение о том, что обновление не- возможно, при работающем приложении. 4. Заметим, что процесс обновления может быть остановлен в любой момент, при этом исходное приложение должно остаться не изменѐнным и в рабочем состоянии. Допустим, у вас установлено приложение версии 1, вы пытаетесь обновить его до версии 2, но в процессе установки передумали и прервали установку. В этом слу- чае инсталлятор должен вернуть все уже сделанные изменения, по- чистить использованные для обновления временные файлы и за- вершить свою работу. При этом приложение версии 1 остается в ра- бочем состоянии. Удаление (Деинсталляция) 1. Хорошей практикой считается удаление созданного в про- цессе инсталляции (регистрационные записи в системном реестре, библиотеки в системных каталогах %Windir%\system32, файлы и т. д.). Условно процесс тестирования деинсталляции можно раз- бить на несколько частей: a. проверка, что из системного реестра удалены, установлен- ные в процессе инсталляции, служебные записи и ссылки на биб- лиотеки; 88 b. проверка физического удаления файлов приложения; c. проверка того, что после удаления приложения, зарегистри- рованные во время установки файловые расширения удалены, а ра- нее существующие (зарегистрированные до инсталляции) – восста- новлены; d. проверка сохранности данных созданных за время работы с приложением. Вполне вероятно, что лежат они где-то в глубине ка- талога самой программы. Это могут быть служебные скрипты, со- хранения от игр или прочие созданные пользователем данные, уда- ление которых нанесет урон пользователю. Только предположите, что при удалении MS Office, все Ваши документы будут удалены вместе с ним. Поэтому подобные данные нельзя удалять без под- тверждения пользователя. 2. В случае, если удаляемое приложение запущено, пользова- тель должен получить предупреждение о том, что удаление невоз- можно, пока приложение работает. 3. Стоит проверить поведение инсталлятора, если каталог про- граммы закрыт для удаления по правам доступа. В данном случае процесс удаления не должен производиться, и пользователь должен получить соответствующее сообщение. 4. Если пользователь не авторизован для удаления приложе- ния, то он должен получить соответствующее сообщение и процесс удаления должен быть прерван. Тестирование мастера установки или Installation Wizard Testing Умные люди писали: «Визарды – это зло». С этим можно со- глашаться или нет, но тестировать их все равно приходится. Пред- лагается следующий план тестирования инсталляционного визарда: 1. Определить все пути от начала до конца, и затем расставить приоритеты для каждого из них. Это поможет нам избежать излиш- них затрат и усилий при прохождении низкоприоритеных путей. 2. Забудьте про GUI. Постарайтесь описать тест-кейсы без привязки к интерфейсным элементам. К примеру, GUI контролы checkbox/radiobutton или меню из двух пунктов это просто выбор между true и false, важно то, на что он влияет в конечном счете. 3. Если по результатам прохождения визарда получается ка- кой либо проперти файл (файл, описывающий свойства в виде спи- ска: свойство=значение), который потом передается дальше в про- цедуру экспорта. В этом случае можно разделить проверки на два 89 этапа – первый, создавать (генерировать) такие проперти файлы и проверять, что экспорт работает правильно. Второй – проверять, что через GUI получаются правильные проперти файлы. 4. Не забудьте заняться таким рутинным видом тестирования визардов, как ходить туда-обратно по страницам: a. ничего не меняя, все ответы должны сохраняться; b. меняя что-либо на предыдущей странице, на следующей должно произойти адекватное изменение либо сброс ответов. 5. Убедитесь, что визард адекватно реагирует на неправиль- ные ответы и не дает ходить дальше. 6. Кнопка Cancel (Close) должна работать всегда и на всех страницах визарда. 7. Создайте для каждого из возможных путей мастера уста- новки шаблонный результат (в идеале, сделайте их несколько – для разных входных данных). Затем, по возможности, автоматизиро- ванно или вручную сравнивайте полученный результат с шаблон- ным. 8. Выделите те опции, которые не влияют ни на какие другие и на которые другие не оказывают влияния. Работу этих опций можно будет тестировать изолированно от других. Контрольные вопросы 1. Что такое тестирование инсталляции? 2. Какие этапы содержит тестирование инсталляции? 3. Как тестировать установщик? 90 СОДЕРЖАНИЕ Предисловие ............................................................................................. 2 Содержание дисциплины в соответствии с учебным планом ............ 2 Содержание практических занятий и лабораторных работ ................ 2 1. Практическое занятие №1. Разработка тестовых сценариев .......... 3 1.1. Разработка тестовых сценариев ...................................................... 3 2. Практическое занятие №2. Обработка исключительных ситуаций .................................................................................................. 13 2.1. Основы обработки исключений .................................................... 13 2.2. Роль обработки исключений в .NET ............................................. 14 2.3. Составляющие процесса обработки исключений в .NET .......... 16 2.4. Перехват исключений .................................................................... 16 3. Практическое занятие №3. «Анализ результатов тестирования» 21 4. Лабораторная работа №1. Разработка тестового сценария ........... 23 5. Лабораторная работа №2. Использование инструментария анализа качества ..................................................................................... 28 6. Лабораторная работа №3. Функциональное тестирование ........... 45 6.1. Определение .................................................................................... 45 6.2. Black-box, white-box, gray-box тестирование. .............................. 45 6.3. Методы отбора тестов для Black-box тестирования ................... 46 6.4. Методы отбора тестов для White-Box тестирования .................. 53 7. Лабораторная работа №4. Тестирование безопасности ................ 54 8. Лабораторная работа №5. «Нагрузочное тестирование, стрессовое тестирование» ......................................................................................... 59 9. Лабораторная работа №6. «Интеграционное тестирование» ........ 70 9.1. Задачи и цели интеграционного тестирования ............................ 70 9.2. Организация интеграционного тестирования ............................. 71 10. Лабораторная работа №7. «Конфигурационное тестирование» 79 11. Лабораторная работа №8. «Тестирование установки» ................ 82 11.1. Тестирование Установки или Installation Testing ...................... 82 11.2. Особенности тестирования инсталляторов ............................... 83 |