Тестирование методом черного ящика

Думайте как враг

Каждая из предыдущих технологий имеет большое значение для предотвращения
случайных сбоев. Если их собрать вместе и правильно применить, то они сокращают
шанс необнаруженной непреднамеренной ошибки практически до нуля.
(Ну, не совсем до нуля, но до величины того же порядка, как вероятность того, что
случайные космические лучи заставят центральный процессор получить 3 в результате сложения 1+1.)
Но не все повреждения данных являются непреднамеренными. Что, если кто-нибудь
специально предоставит неверные данные
в надежде пробить брешь в системе безопасности вашей программы? Думать, как взломщик — вот следующий шаг
в защите кода.

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

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

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

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

3.Общая стратегия тестирования.

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

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

2. В любом случае необходимо использовать анализ граничных значений.

3. Определить правильные и неправильные классы эквивалентности для входных и выходных данных и дополнить, если это необходимо, тесты, построенные на предыдущих шагах.

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

Порядок выполнения работы:

1. Ознакомиться с теоретическими сведениями по стратегиям тестирования.

2. В соответствии с вариантом задачи, подготовить тесты по методикам стратегии«;черного ящика»;.

3. Предлагаемые тесты свести в таблицу.

   Номер теста	Назначение теста	Значения исходных данных	Ожидаемый результат	Реакция программы	Вывод

4. Разработать программу.

5. Выполнить тестирование. Занести в таблицу результаты.

6. Сделать вывод о роли тестирования с использованием стратегии «;черного ящика»; и возможностях его применения. Сформулировать его достоинства и недостатки.

Варианты заданий:

Задача 1.

Разработать программу решения уравнения , где a, b, c — любые вещественные числа.

Задача 2.

Разработать программу определения суммарной длины тени, которую отбрасывают на ось ОХ отрезки, параллельные этой оси и заданные координатами x начала и конца отрезка:

Задача 3.

Разработать программу исследования уравнений второго порядка с двумя неизвестными Ax2+2Bxy+Cy2+2Dx+2Ey+F=0. Программа должна определять вид графика: эллипс, парабола, гипербола, две пересекающиеся прямые, две параллельные прямые, две мнимые прямые.

Примечание. Вид прямой втрого порядка определяется по двум дискриминантам

большому: и малому .

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

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

Задача 4.

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

Задача 5.

Задача 6.

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

Примечание. Две прямые лежат в одной плоскости, если

, прямые параллельны если ,

где l=x₂—x₁, m=y₂—y₁, n=z₂—z₁ (верхний индекс соответствует номеру прямой).

Защита отчета по лабораторной работе

Отчет по лабораторной работе должен включать в себя:

1. Задание.

2. Алгоритм программы.

3. Таблицу с результатами тестирования.

4. Вывод.

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

Литература

1. Майерс Г. Искусство тестирования программ / Пер. с англ. под ред. Б. А. Позина. — М.: Финансы и статистика,1982.-176с.

2. Иванова Г.С. Технология программирования. – М.: Из-во МГТУ им. Баумана 2002, — 241 с.

Как работает тестирование по методу «черного ящика»

Тестирование по этому методу реализовать довольно просто:

1. Подготовьте корректный файл, предназначенный для ввода в программу;
2. Замените некоторые части этого файла случайными данными;
3. Откройте файл в программе;
4. Посмотрите, что идет не так.

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

Тестирование приложений, написанных
на языке С

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

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

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

Листинг 1. Класс, который заменяет часть файла
случайными данными

О коде

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

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

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

Техника

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

Переход (Transition) — Представляет переход из текущего состояния в новое, в результате выполнения какого-то действия. Изображается в виде стрелки.

Событие (Event) — Событие, ставшее причиной изменения состояния. Обычно событие поступает в систему из внешнего мира посредством некоторого интерфейса. Иногда это событие инициируется внутри самой системы например такие как срабатывание таймера, снижение ниже какого-то уровня. Считается, что событие происходит моментально. Событие может быть как независимым, так и связанным. Когда событие случается, система может изменить состояние или остаться в прежнем состоянии и/или инициировать действие. События могут иметь, связанные с ними параметры (номер карты, сумма на счете). Изображается как подпись к стрелке перехода.

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

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

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

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

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

Может быть выбран один из 4 вариантов создания тест-кейсов:

1. Создать наборы тест-кейсов так, чтобы все состояния были пройдены хотя бы по одному разу. В одном тест-кейсе может быть описан переход через несколько состояний. Это довольно слабый уровень тестового покрытия.
2. Создать наборы тест-кейсов так, чтобы все события были инициированы хотя бы по одному разу. Тест-кейсы, которые покрывают все события в то же время покрывают и все состояния. Снова слабый уровень тестового покрытия.
3. Создать наборы тест-кейсов так, чтобы все пути были пройдены хотя бы по одному разу. Такой способ хорош с точки зрения тестового покрытия, однако практически не осуществим. Если диаграмма имеет циклы, то количество возможных путей может оказаться бесконечным.
4. Создать наборы тест-кейсов так, чтобы все переходы были выполнены хотя бы по одному разу. Этот способ обеспечивает хороший уровень тестового покрытия, поэтому рекомендуется использовать именно его.
   Рекомендуемая стратегия создания тест-кейсов состоит в том, чтобы хотя бы по разу протестировать все переходы между состояниями. В высокорисковых системах, где требуется более надежное тестовое покрытие, возможно создавать тест-кейсы на каждый путь (цепочку переходов) между состояниями.

Модель «черного ящика»: примеры

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

1. Входы – кабель питания, антенна, элементы настройки и управления.
2. Выходы – экран и динамики.

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

Возьмем другую систему – наручные часы

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

Далее следует учесть, что выраженная цель относится в целом ко всем часам, а не только к взятым наручным. Для их дифференциации можно внести следующее добавление – удобство ношения на запястье. Оно будет выступать в качестве входа. С этим добавлением возникает необходимость браслета или ремешка. С ним, в свою очередь, появляется обязательность удовлетворения правилам гигиены (выход), поскольку не каждое крепление допустимо на руке. Затем, если представить условия, в которых эксплуатируются часы, можно ввести еще несколько параметров: пылевлагонепроницаемость, прочность. Дополнительно можно применить еще два выхода. Ими будут точность, необходимая в повседневной жизни, а также доступность информации на циферблате для прочтения при беглом взгляде. В процессе исследования можно добавить еще несколько требований к часам. Например, вводятся такие выходы, как соответствие моде, соотношение цены с покупательской способностью потребителя.

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

Сравнение методов тестирования ПО

Использование всех динамических методов приводит к комбинаторному взрыву количества тестов, которые должны быть разработаны, воплощены и проведены

Каждую технику следует использовать прагматично, принимая во внимание ее ограничения

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

Ниже приведены основные отличия трех динамических техник тестирования — дана таблица сравнения между тремя формами отладки ПО.

Расположение элементов

Блок сбора и преобразования информации (БСПИ) полученные данные преобразует в вид, удобный для записи, и направляет их в кассетный бортовой накопитель (КБН), и в защищённый бортовой накопитель (ЗБН).

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

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

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

Т. е. на ленте остаются параметры не только последнего полёта, но и нескольких предыдущих.

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

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

Кроме ЗБН в хвостовой части самолёта устанавливается звуковой регистратор Марс-БН. Внешне он выглядит также как и ЗБН, но предназначен для записи на магнитную ленту всех переговоров экипажа в последние 30 минут. Впрочем, если быть точным, то Марс-БН записывает речь и звуки с каждой розетки подключения гарнитуры (наушники и микрофон). Естественно, что если, например, с гарнитуры второго пилота говорит не он, а скажем террорист, то будет записана речь террориста.

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

Однако это далеко не всегда так. Во-первых при катастрофах нередко записи повреждаются так, что из них мало что удаётся извлечь. Во-вторых, далеко не все, что хотелось бы знать фиксирует САРПП. Здесь немало технических трудностей.

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

Нравится

Системный анализ

Исследование некоторой реальной системы состоит из двух этапов: этапа анализа и этапа синтеза.

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

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

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

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

Попарное тестирование

Техника

1. Определить параметры (variables)
2. Определить количество значений для каждого параметра (choices for variable)
3. Построить массив, содержащий колонки для каждого параметра и значения в колонках, которые содержать все сочетания значений этих параметров друг с другом.
4. Сопоставить полученный ортогональный массив с целью тестирования.
5. Построить тест-кейсы.

Опытным путем было определено, что большинство дефектов это или одиночные дефекты (single-mode defects), или парные дефекты (double-mode defects), т.е. проявляющиеся при сочетании одного параметра всего лишь с одним другим параметром, при том что значение остальных параметров не имеет значения.

Если количество комбинаций значений переменных велико, не стоит пытаться протестировать все возможные комбинации, лучше сосредоточиться на тестировании всех пар значений переменных.
Два подхода попарного тестирования (pairwise testing): метод ортогонального массива (orthogonal arrays) и метод всех пар (allpair algorithm).

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

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

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

Нужно учитывать, что могут возникнуть ограничения связанные с тем, что некоторые сочетания параметров никогда не будут иметь места.

Самовольный алгоритм

По каким алгоритмам работает ИИ?

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

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

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

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

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

Поскольку эти алгоритмы являются секретными и остаются вне юрисдикции регулирующих органов, гражданам практически невозможно засудить создателей алгоритмов. В 2016 году высший суд Висконсина отклонил просьбу человека рассмотреть внутреннюю работу COMPAS. Мужчина, Эрик Лумис, был приговорен к шести годам тюремного заключения отчасти потому, что COMPAS посчитал его «высокорисковым». Лумис говорит, что его право на надлежащую процедуру было нарушено зависимостью судьи от непрозрачного алгоритма. Окончательная заявка на рассмотрение дела в Верховном суде США потерпела неудачу в июне 2017 года.

Но скрытные компании не будут пользоваться своей свободой в течение неограниченного времени. К марту Евросоюз примет законы, которые потребуют от компаний возможности объяснить заинтересованным клиентам, как работают их алгоритмы и как принимают решения. У США нет такого законодательства в разработке.

Автоматизация

Автоматические методы тестирования программных продуктов намного упрощают процесс проверки независимо от технической среды или контекста ПО. Их используют в двух случаях:

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

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

Тестовые инструменты могут быть классифицированы по-разному. Следующее деление основано на поддерживаемых ими задачах:

• управление тестированием, которое включает поддержку управления проектом, версиями, конфигурациями, риск-анализ, отслеживание тестов, ошибок, дефектов и инструменты создания отчетов;
• управление требованиями, которое включает хранение требований и спецификаций, их проверку на полноту и многозначность, их приоритет и отслеживаемость каждого теста;
• критический просмотр и статический анализ, включая мониторинг потока и задач, запись и хранение комментариев, обнаружение дефектов и плановых коррекций, управление ссылками на проверочные списки и правила, отслеживание связи исходных документов и кода, статический анализ с обнаружением дефектов, обеспечением соответствия стандартам написания кода, разбором структур и их зависимостей, вычислением метрических параметров кода и архитектуры. Кроме того, используются компиляторы, анализаторы связей и генераторы кросс-ссылок;
• моделирование, которое включает инструменты моделирования бизнес-поведения и проверки созданных моделей;
• разработка тестов обеспечивает генерацию ожидаемых данных исходя из условий и интерфейса пользователя, моделей и кода, управление ими для создания или изменения файлов и БД, сообщений, проверки данных исходя из правил управления, анализа статистики условий и рисков;
• критический просмотр путем ввода данных через графический интерфейс пользователя, API, командные строки с использованием компараторов, помогающих определить успешные и неудавшиеся тесты;
• поддержка сред отладки, которая позволяет заменить отсутствующее оборудование или ПО, в т. ч. симуляторы оборудования на основе подмножества детерминированного выхода, эмуляторы терминалов, мобильных телефонов или сетевого оборудования, среды для проверки языков, ОС и аппаратного обеспечения путем замены недостающих компонентов драйверами, фиктивными модулями и др., а также инструменты для перехвата и модификации запросов ОС, симуляции ограничений ЦПУ, ОЗУ, ПЗУ или сети;
• сравнение данных файлов, БД, проверка ожидаемых результатов во время и по окончании тестирования, в т. ч. динамическое и пакетное сравнение, автоматические «оракулы»;
• измерение покрытия для локализации утечек памяти и некорректного управления ею, оценки поведения системы в условиях симулированной нагрузки, генерации нагрузки приложений, БД, сети или серверов по реалистичным сценариям ее роста, для измерения, анализа, проверки и отчета о системных ресурсах;
• обеспечение безопасности;
• тестирование производительности, нагрузки и динамический анализ;
• другие инструменты, в т. ч. для проверки правописания и синтаксиса, сетевой безопасности, наличия всех страниц веб-сайта и др.