Приблизительные ответы на билеты к экзамену (775818), страница 3

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 3)

Билет №11.

Тестирование программных средств.(нет)

Тести́рование програ́ммного обеспе́чения — процесс исследования программного обеспечения (ПО) с целью получения информации о качестве продукта.

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

С точки зрения ISO 9126, Качество (программных средств) можно определить как совокупную характеристику исследуемого ПО с учётом следующих составляющих:

• Надёжность

• Сопровождаемость

• Практичность

• Эффективность

• Мобильность

• Функциональность

Тестирование программного обеспечения

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

По объекту тестирования:

• Функциональное тестирование (functional testing)

• Тестирование производительности (performance testing)

  • Нагрузочное тестирование (load testing)

  • Стресс-тестирование (stress testing)

  • Тестирование стабильности (stability / endurance / soak testing)

• Тестирование удобства использования (usability testing)

• Тестирование интерфейса пользователя (UI testing)

• Тестирование безопасности (security testing)

• Тестирование локализации (localization testing)

• Тестирование совместимости (compatibility testing)

По знанию системы:

• Тестирование чёрного ящика (black box)

• Тестирование белого ящика (white box)

• Тестирование серого ящика (gray box)

По степени автоматизации:

• Ручное тестирование (manual testing)

• Автоматизированное тестирование (automated testing)

• Полуавтоматизированное тестирование (semiautomated testing)

По степени изолированности компонентов:

• Компонентное (модульное) тестирование (component/unit testing)

• Интеграционное тестирование (integration testing)

• Системное тестирование (system/end-to-end testing)

По времени проведения тестирования:

• Альфа-тестирование (alpha testing)

  • Тестирование при приёмке (smoke testing)

  • Тестирование новой функциональности (new feature testing)

  • Регрессионное тестирование (regression testing)

  • Тестирование при сдаче (acceptance testing)

• Бета-тестирование (beta testing)

По признаку позитивности сценариев:

• Позитивное тестирование (positive testing)

• Негативное тестирование (negative testing)

По степени подготовленности к тестированию:

• Тестирование по документации (formal testing)

• Тестирование ad hoc или интуитивное тестирование (ad hoc testing)

Уровни тестирования

• Модульное тестирование (юнит-тестирование) — тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция. Часто модульное тестирование осуществляется разработчиками ПО.

• Интеграционное тестирование — тестируются интерфейсы между компонентами, подсистемами. При наличии резерва времени на данной стадии тестирование ведётся итерационно, с постепенным подключением последующих подсистем.

• Системное тестирование — тестируется интегрированная система на её соответствие требованиям.

  • Альфа-тестирование — имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком. Чаще всего альфа-тестирование проводится на ранней стадии разработки продукта, но в некоторых случаях может применяться для законченного продукта в качестве внутреннего приёмочного тестирования. Иногда альфа-тестирование выполняется под отладчиком или с использованием окружения, которое помогает быстро выявлять найденные ошибки. Обнаруженные ошибки могут быть переданы тестировщикам для дополнительного исследования в окружении, подобном тому, в котором будет использоваться ПО.

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

Часто для свободного/открытого ПО стадия альфа-тестирования характеризует функциональное наполнение кода, а бета-тестирования — стадию исправления ошибок. При этом как правило на каждом этапе разработки промежуточные результаты работы доступны конечным пользователям.

Статическое и динамическое тестирование

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

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

Также к статическому тестированию относят тестирование требований, спецификаций, документации.

Регрессионное тестирование

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

Тестовые скрипты

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

Тестирование «белого ящика» и «чёрного ящика»

В терминологии профессионалов тестирования, фразы «тестирование белого ящика» и «тестирование чёрного ящика» относятся к тому, имеет ли разработчик тестов доступ к исходному коду тестируемого ПО, или же тестирование выполняется через пользовательский интерфейс либо прикладной программный интерфейс, предоставленный тестируемым модулем.

При тестировании белого ящика (англ. white-box testing, также говорят — прозрачного ящика), разработчик теста имеет доступ к исходному коду программ и может писать код, который связан с библиотеками тестируемого ПО. Это типично для юнит-тестирования (англ. unit testing), при котором тестируются только отдельные части системы. Оно обеспечивает то, что компоненты конструкции — работоспособны и устойчивы, до определённой степени. При тестировании белого ящика используются метрики покрытия кода.

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

При тестировании серого ящика разработчик теста имеет доступ к исходному коду, но при непосредственном выполнении тестов доступ к коду, как правило, не требуется.

Если «альфа-» и «бета-тестирование» относятся к стадиям до выпуска продукта (а также, неявно, к объёму тестирующего сообщества и ограничениям на методы тестирования), тестирование «белого ящика» и «чёрного ящика» имеет отношение к способам, которыми тестировщик достигает цели.

Бета-тестирование в целом ограничено техникой чёрного ящика (хотя постоянная часть тестировщиков обычно продолжает тестирование белого ящика параллельно бета-тестированию). Таким образом, термин «бета-тестирование» может указывать на состояние программы (ближе к выпуску чем «альфа»), или может указывать на некоторую группу тестировщиков и процесс, выполняемый этой группой. Итак, тестировщик может продолжать работу по тестированию белого ящика, хотя ПО уже «в бете» (стадия), но в этом случае он не является частью «бета-тестирования» (группы/процесса).

Покрытие кода

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

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

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

Билет №12.

Контроль программного кода.(нет)

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

В телекоммуникации целостность данных часто проверяют, используя MAC-код сообщения (Message authentication code).

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

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

• случайное изменение при передаче информации или при неисправной работе жесткого диска.

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

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

Целостность данных — свойство, при выполнении которого данные сохраняют заранее определённый вид и качество.

Область использования

Понятие «целостность объекта» (англ. integrity) используется в контексте терминологии информационной безопасности (объектом может быть информация, специализированные данные, ресурсы автоматизированной системы). В частности, свойство целостности информации (ресурсов автоматизированной системы) — является одним из трех основных критериев информационной безопасности объекта.

Обычно свойство целостности требуется наряду с конфиденциальностью (confidentiality) и доступностью (availability). Иногда к списку необходимых свойств информационной безопасности объекта добавляют неотказуемость (non-repudiation), подотчётность (accountability), аутентичность или подлинность (authenticity), достоверность (reliability).

Характеристики

Список файлов ответов (шпаргалок)