к какой сущности относится требование ранжируемости в тестировании

Ранжирование функциональных требований

Состав и содержание включенных в профиль защиты функциональных требований определяются средой экс­плуатации ИТ-продукта. Чтобы обосновать выбор тех или иных требований и не вступать в противоречие сосу­ществующими стандартами в области безопасности ИТ-продуктов, функциональные требования, приведенные в «Федеральных критериях», ранжируются по уровням с помощью следующих четырех критериев: широта сферы применения, степень детализации, функциональный со­став средств защиты, обеспечиваемый уровень безопас­ности.

Широта сферы применения определяется множеством сущностей, к которому могут быть применены данные требования, а именно:

· пользователи системы, субъекты и объекты доступа;

· функции ТСВ и интерфейс взаимодействия с ТСВ;

· аппаратные, программные и специальные компо­нентыТСВ;

· множество параметров конфигурации ТСВ.

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

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

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

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

Ранжирование вести предполагает установление некоторого отношения порядка. Однако независимое ран­жирование функциональных требований по каждому из описанных критериев хотя и дает некоторое представ­ление о различиях между функциональными возможностями средств защиты, не позволяет установить четкую, линейную шкалу уровней безопасности. Однозначного отношения порядка, определенного на множестве функ­циональных требований, не существует, так как значение требований и уровень обеспечиваемой ими защиты зави­сят не только от их содержания, но и от назначения ИТ-продукта и среды его эксплуатации. Для одних систем наиболее важными будут идентификация и аутентифи­кация пользователей, а для других — реализация поли­тики управления доступом или обеспечение работоспо­собности.

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

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

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

В Приложении I приведен полный ранжированный перечень функциональных требований «Федеральных критериев».

Требования к технологии разработки ИТ-продукта

Основное назначение требований к технологии раз­работки ИТ-продукта — обеспечить адекватность усло­вий разработки функциональным требованиям, выдви­нутым в соответствующем разделе профиля защиты, и установить ответственность разработчика за коррект­ность реализации этих требований. Данный раздел рег­ламентирует процесс создания, тестирования, докумен­тирования и сопровождения ИТ-продукта. Таксономия требований к технологии разработки ИТ-продукта при­ведена на рис. 2.6.

Требования к технологии разработки ИТ-продуктов включают четыре раздела: требования к процессу разра­ботки, к среде разработки, к документированию и к со­провождению.

Таблица 2.3.Ранжирование функциональных требований «Федеральных критериев».

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

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

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

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

«Федеральные критерии» содержат ранжированный перечень типовых требований к технологии разработки ИТ-продуктов. Выполнение требований к технологии разработки является необходимым условием для прове­дения процедуры квалификационного анализа.

Рис. 2.6 Таксономия требований «Федеральных критериев» к технологии разработки ИТ-продукта.

2.8.6. Требования к процессу квалификационною анализа ИТ-продукта

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

Рис. 2.7 Таксномия требований «Федеральных критериев» к процессу квалификационнго анализа ИТ-продукта

Раздел требований к анализу ИТ-продукта содержит требования к проведению независимого анализа пред­ложенного решения и к его реализации в виде конкрет­ного средства.

Раздел требований к контролю регламентирует про­верку соответствия среды разработки ИТ-продукта и обеспечиваемого производителем сопровождения требо­ваниям к технологии разработки.

Требования к тестированию описывают процедуру проведения тестирования функций ТСВ как самим раз­работчиком ИТ-продукта, так и независимыми экспер­тами.

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

Выводы

«Федеральные критерии безопасности информаци­онных технологий» являются первым стандартом ин­формационной безопасности, в котором определяются три независимые группы требований: функциональные требования к средствам защиты, требования к техноло­гии разработки и к процессу квалификационного анали­за. Авторами этого стандарта впервые предложена кон­цепция профиля защиты — документа, содержащего описание всех требований безопасности как к самому ИТ-продукту, так и к процессу его проектирования, раз­работки, тестирования и квалификационного анализа.

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

Разработчики «Федеральных критериев» отказались от используемого в «Оранжевой книге» подхода к оцен­ке уровня безопасности ИТ-продукта на основании обобщенной универсальной шкалы классов безопасно­сти. Вместо этого предлагается независимое ранжирова­ние требований каждой группы, т. е. вместо единой шка­лы используется множество частных, шкал-критериев, характеризующих обеспечиваемый уровень безопасно­сти. Данный подход позволяет разработчикам и пользо­вателям ИТ-продукта выбрать наиболее приемлемое решение и точно определить необходимый и достаточ­ный набор требований для каждого конкретного ИТ-продукта и среды его эксплуатации.

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

Данный стандарт ознаменовал появление новою по­коления руководящих документов в области информаци­онной безопасности, а его основные положения послужи­ли базой для разработки «Канадских критериев безопас­ности компьютерных систем» (п. 2.9) и «Единых критериев безопасности информационных технологий» (п. 2 10).

Источник

Тестирование на основе диаграмм состояний сущности

Требования к состояниям сущности

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

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

Пример: составление диаграммы состояний по требованиям

Требование 1: сразу после получения сообщений с почтового сервера они помечены как непрочитанные.
Требование 2: когда пользователь кликает на сообщение, чтобы открылось его содержание, сообщение становится прочитанным.
Требование 3: пользователь может пометить ранее прочитанные сообщения как непрочитанные.
Требование 4: пользователь может удалить сообщения (как прочитанные, так и непрочитанные), вернуть сообщения после удаления нельзя.

По этим требованиям можно получить такую диаграмму для сообщений:

Как проектировать тесты по диаграммам состояний

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

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

Пример: тесты для диаграммы состояний сообщения

Спроектируем матричное представление для следующей диаграммы состояний:

Таким образом, для этой диаграммы будет четыре простых позитивных теста и пять негативных.
Если проектировать негативные тесты для почтового веб-клиента, они будут выглядеть приблизительно так:

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

Сложные тесты по диаграмме состояний

Простые позитивные тесты представляют собой, как описано выше, проверку одного корректного перехода между двумя состояниями. Таким образом, можно сформулировать простейший критерий покрытия диаграммы тестами: протестированы все существующие переходы между состояниями, и объект побывал в каждом состоянии хотя бы один раз. Но можно проектировать и более сложные сценарные тесты, состоящие из более чем одного перехода. Такие тесты могут быть в дальнейшем использованы и для нагрузочного тестирования. Аналогично, можно задать более сильные критерии покрытия тестами: проверены все возможные пары переходов между состояниями, тройки и т.д. (до N-1, где N – количество состояний объекта). Такое покрытие называется покрытием переходом Чау или покрытием N-1 переходов. Соответственно, самое слабое покрытие будет покрытием 0 переходов.

Другие применения диаграмм состояний

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

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

Источник

Обзор частых вопросов по тестированию ПО на собеседованиях и ответы на них

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

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

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

Собственно вопросы:

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

Обеспечение качества определено в стандарте ISO 9000:2005 «Системы менеджмента качества. Основные положения и словарь» как «часть менеджмента качества, направленная на создание уверенности в том, что требования к качеству будут выполнены».

Менеджмент качества в этом же стандарте представлен как «скоординированная деятельность по руководству и управлению организацией применительно к качеству», а в примечании сказано, что он «обычно включает разработку политики и целей в области качества, планирование качества, управление качеством, обеспечение качества и улучшение качества».

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

Из этого определения становится понятно, что тестирование ПО включает в себя два различных процесса:
Валидация (validation): доказанное объективными результатами исследования подтверждение того, что требования для конкретного определенного использования приложения были выполнены. [ISO 9000]
Верификация (verification): доказанное объективными результатами исследования подтверждение того, что определенные требования были выполнены. [ISO 9000]

Цель тестирования (test objective, test target) — это причина или цель разработки и выполнения теста.

Следует также понимать что такое big-bang тестирование, тестирование «сверху вниз», восходящие и инкрементное тестирование;

Критерии входа (entry criteria) — это набор общих и специфичных условий для продолжения процесса с определенной задачей, например, фаза тестирования. Цель критериев входа — предотвращение начала задачи, которое может потребовать больше (бесполезных) усилий, чем на устранение не пройденных критериев входа.

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

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

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

Реальный вопрос, на который мы ищем ответ: строим ли мы продукт правильно?

Процесс верификации (verification) выполняется, чтобы убедиться, что каждый этап жизненного цикла разработки ПО (разработка, тестирование и т.д.) строится на основе предопределенных требований (requirements) и спецификаций (specifications) и без каких-либо отклонений от них. (см. № 7)

Реальный вопрос, на который мы ищем ответ: строим ли мы правильный продукт?

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

Помните, валидация охватывает динамическую сторону тестирования, где определенное ПО тестируется и оценивается вопреки заданной SRS документации.

Отладка (debugging) — это процесс поиска, анализа, и устранения причин отказов и ошибок в ПО.

Эмуляция — это воспроизведение работы программы или системы (а не какой-то её мизерной части) с сохранением ключевых её свойств и принципов работы. Эмуляция выполняет программный код в привычной для этого кода среде, состоящей из тех же компонентов, что и эмулируемый объект.

Симуляция — это воспроизведение работы программы-оригинала сугубо виртуально, на движке специальной программы (средство разработки курсов, к примеру). Симуляция лишь имитирует выполнение кода, а не копирует его, всё виртуально на 100%, всё «понарошку».

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

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

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

Спецификация (specifications) — это текстовый файл с описанием того, что нужно протестировать в тестовых данных. В ней указывается какие результаты должна получить программа. Тестовый код находит реальные, вычисленные на живом коде результаты. А тестовый движок производит сверку спецификации и вычисленных результатов.

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

Кодирование (coding) — это процесс написания программного кода, скриптов, с целью реализации определённого алгоритма на определённом языке программирования.

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

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

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

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

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

Критичность (severity) — это важность воздействия конкретного дефекта на разработку или функционирование компонента или системы.

Приоритет (priority) — это степень важности, присваиваемая багу. Другими словами определяется, насколько срочно это ошибка должна быть исправлена.

Сборка (build) — подготовленный для использования информационный продукт. Чаще всего это исполняемый файл (двоичный файл, содержащий исполняемый код программы).

Драйвер (driver) — это компонент ПО или средство тестирования, которое заменяет компонент, обеспечивающий управление и/или вызов компонента или системы.

Обвязка (harness) — это тестовое окружение, включающее в себя заглушки и драйверы, необходимые для проведения теста.

Для измерения покрытия требований, необходимо проанализировать требования к продукту и разбить их на пункты. Опционально каждый пункт связывается с тест кейсами, проверяющими его. Совокупность этих связей — и является матрицей трассировки (traceability matrix). Проследив связи, можно понять какие именно требования проверяет тестовый случай.

Тесты не связанные с требованиями не имеют смысла. Требования, не связанные с тестами — это «белые пятна», т.е. выполнив все созданные тест кейсы, нельзя дать ответ реализовано данное требование в продукте или нет.

End-to-end тестирование — это тип тестирования где тестировщик использует ПО (сценарии, которые исследуют весь поток выполнения) в условиях которыми вероятней всего обладает пользователь.

Функциональное тестирование (functional testing) — это тестирование, основанное на анализе спецификации функциональности компонента или системы.

Функциональные тесты базируются на функциях и особенностях, а также взаимодействии с другими системами, и могут быть представлены на всех уровнях тестирования: компонентном или модульном (Component/Unit testing), интеграционном (Integration testing), системном (System testing) иприемочном (Acceptance testing). Функциональные виды тестирования рассматривают внешнее поведение системы.

Белый ящик — это тестирование кода на предмет логики работы программы и корректности её работы с точки зрения компилятора того языка, на котором она писалась.

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

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

Спасибо за внимание и удачи в ваших начинаниях!

P.S. Пожалуйста, обратите внимание, что это всего лишь перечень вопросов составленный на основе моего опыта (он не будет уникальным для всех интервью), а запоминание ответов как истинных может помешать вам работать в индустрии. Целью является помочь вам понять основные вопросы, с которыми вы предположено столкнетесь во время собеседования.

Призываю к активному и обоснованному холивару!

Источник