Лекционный материал

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

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

В более широком смысле, тестирование — это одна из техник контроля качества, включающая в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis).

Верификация (Verification) — это процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа [IEEE]. Т.е. выполняются ли наши цели, сроки, задачи по разработке проекта, определенные в начале текущей фазы.

Валидация (Validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе [BS7925-1].

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

Тест дизайн (Test Design) — это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест кейсы), в соответствии с определёнными ранее критериями качества и целями тестирования.

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

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

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

Детализация Тест Кейсов (Test Case Specification) — это уровень детализации описания тестовых шагов и требуемого результата, при котором обеспечивается разумное соотношение времени прохождения к тестовому покрытию

Время Прохождения Тест Кейса (Test Case Pass Time) — это время от начала прохождения шагов тест кейса до получения результата теста.

Автоматизированные средства тестирования

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

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

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

Плюсы автоматизации:

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

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

3. Сокращение времени тестирования за счет быстрого выполнения – автоматизированный скрипт работает намного быстрее человека.

4. Меньшие затраты на поддержку – когда автоматические скрипты уже написаны, на их поддержку и анализ результатов требуется, как правило, меньшее время чем на проведение того же объема тестирования вручную.

5. Отчеты – автоматически рассылаемые и сохраняемые отчеты о результатах тестирования.

6. Сокращение времени тестирования за счет проведения тестов в нерабочее время.

Минусы:

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

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

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

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

Перечислим места, где нужно применять автоматизацию:

1. Труднодоступные места в системе (бэкенд процессы, логирование файлов, запись в БД).

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

3. Рутинные операции, такие как переборы данных (формы с большим количеством вводимых полей – автоматизировать заполнение полей различными данными и их проверку после сохранения).

4. Валидационные сообщения (автоматизировать заполнение полей некорректными данными и проверку на появление той или иной валидации).

5. Длинные end-to-end сценарии.

6. Проверка данных, требующих точных математических расчетов.

7. Проверка правильности поиска данных.

А также многое другое, в зависимости от требований к тестируемой системе и возможностей выбранного инструмента для тестирования.

В тестировании используется такое понятие, как тестовый случай.

Тестовый случай, тест-кейс (test case) – это набор условий и/или переменных, с помощью которых тестировщик будет определять, насколько полно тестируемое приложение удовлетворяет предъявляемому к нему требованию.

Для более эффективного использования автоматизации тестирования лучше разработать отдельные тест кейсы проверяющие:

Базовые операции создания/чтения/изменения/удаления сущностей (так называемые CRUD операции — Create / Read / Update / Delete).

Пример: создание, удаление, просмотр и изменение данных о пользователе.

Типовые сценарии использования приложения, либо отдельные действия.

Пример: пользователь заходит на почтовый сайт, листает письма, просматривает новые, пишет и отправляет письмо, выходит с сайта. Это так называемый end-to-end сценарий, который проверяет совокупность действий. Желательно использовать именно такие сценарии, так как они позволяют вернуть систему в состояние, максимально близкое к исходному, а значит – минимально влияющее на другие тесты.

Интерфейсы работы с файлами и другие моменты, неудобные для тестирования вручную.

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

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