Основные показатели (метрики) производительности

1. Потребление ресурсов центрального процессора (CPU, %)

2. Потребление оперативной памяти (Memory usage, Mb)

3. Потребление сетевых ресурсов

4. Работа с дисковой подсистемой (I/O Wait)

5. Время выполнения запроса (request response time, ms)

Тестирование безопасности — оценка уязвимости программного обеспечения к различным атакам.

В ходе тестирования безопасности испытатель играет роль взломщика. Ему разрешено все:

· попытки узнать пароль с помощью внешних средств;

· атака системы с помощью специальных утилит, анализирующих защиты;

· подавление, ошеломление системы (в надежде, что она откажется обслуживать других клиентов);

· целенаправленное введение ошибок в надежде проникнуть в систему в ходе восстановления;

· просмотр несекретных данных в надежде найти ключ для входа в систему.

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

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

· Аппаратная платформа;

· Сетевые устройства;

· Периферия (принтеры, CD/DVD-приводы, веб-камеры и пр.);

· Операционная система (Unix, Windows, MacOS,...)

· Базы данных (Oracle, MS SQL, MySQL,...)

· Системное программное обеспечение (веб-сервер, файрвол, антивирус,...)

· Браузеры (Internet Explorer, Firefox, Opera, Chrome, Safari)

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

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

Достоинства метода:

· Позволяет быстро выявить ошибки в функциональных спецификациях.

· Тестировщику не нужна дополнительная квалификация.

· Тестирование проходит «с позиции» пользователя.

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

Метод имитирует поведение пользователя, у которого нет никаких знаний о внутреннем устройстве программы. Методом «черного ящика» проводятся следующие виды тестирования:

· функциональное;

· регрессионное;

· usability;

· smoke;

· GUI (тестирование интерфейса).

 

Тестирование белого ящика (white box) У этого метода существует несколько названий («стеклянный ящик», «открытый ящик» и др.), но чаще всего его все-таки именуют методом «белого ящика». Проверка «белого ящика» – это метод тестирования программного обеспечения, который предполагает, что внутренняя структура, устройство и реализация системы известны тестировщику.

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

· Unit-тестирование;

· интеграционное;

· системное;

· тестирование безопасности.

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

Достоинства метода «белого ящика»:

· Оптимизация кода путем нахождения скрытых ошибок.

· Доступность структуры кода позволяет выбрать тип входных данных, необходимых для эффективного тестирования.

· Возможность автоматизирования тест-кейсов.

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

Тестирование серого ящика (grey box) Проверка «серого ящика» – это метод тестирования программного продукта или приложения с частичным знанием его внутреннего устройства. Для выполнения тестирования «серого ящика» нет необходимости в доступе тестировщика к исходному коду. Тесты пишутся на основе знания алгоритма, архитектуры, внутренних состояний или других высокоуровневых описаний поведения программы.

Виды тестирования «серого ящика»:

· Матричное тестирование.

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

· Шаблонное тестирование (pattern).

· Тестирование с помощью ортогонального массива.

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

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

Достоинства метода:

· Тестирование серого ящика включает в себя плюсы тестирования «черного» и «белого». Другими словами, тестировщик смотрит на объект тестирования с позиции «черного» ящика, но при этом проводит анализ на основе тех данных, что он знает о системе.

· Тестировщик может проектировать и использовать более сложные сценарии тестирования.

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

· Предоставляет разработчику достаточно времени для исправления дефектов.

Недостатки метода:

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

· Тесты могут быть избыточными в том случае, когда разработчик также проверяет свой код Unit-тестами.

· Нельзя протестировать все возможные потоки ввода и вывода, поскольку на это требуется слишком много времени

·

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

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

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

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

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

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

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

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

Модульное тестирование, или юнит-тестирование (англ. unit testing) — процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы.

Этот тип тестирования обычно выполняется программистами.

Интеграционное тестирование (англ. Integration testing, иногда называется англ. Integration and Testing, аббревиатура англ. I&T) — одна из фаз тестирования программного обеспечения, при которой отдельные программные модули объединяются и тестируются в группе. Обычно интеграционное тестирование проводится после модульного тестирования и предшествует системному тестированию.

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

Альфа-тестирование и бета-тестирование являются подкатегориями системного тестирования.

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

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

o Дымовое тестирование (smoke testing)

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

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

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

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

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

В области же программного обеспечения, дымовое тестирование рассматривается как короткий цикл тестов, выполняемый для подтверждения того, что после сборки кода (нового или исправленного) устанавливаемое приложение, стартует и выполняет основные функции.

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

 

Регрессионное тестирование (англ. regression testing, от лат. regressio — движение назад) — собирательное название для всех видов тестирования программного обеспечения, направленных на обнаружение ошибок в уже протестированных участках исходного кода. Такие ошибки — когда после внесения изменений в программу перестает работать то, что должно было продолжать работать, — называют регрессионными ошибками (англ. regression bugs).

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

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

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

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

Критерии

Существует несколько различных способов измерения покрытия, основные из них:

· покрытие операторов — каждая ли строка исходного кода была выполнена и протестирована;

· покрытие условий — каждая ли точка решения (вычисления истинно ли или ложно выражение) была выполнена и протестирована;

· покрытие путей — все ли возможные пути через заданную часть кода были выполнены и протестированы;

· покрытие функций — каждая ли функция программы была выполнена;

· покрытие вход/выход — все ли вызовы функций и возвраты из них были выполнены.

· покрытие значений параметров — все ли типовые и граничные значения параметров были проверены.