Slider Background

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

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

Когда-то давно я подготовила простой обзорный семинар по тестированию для ознакомления разработчиков и ПМов с основными видами тестирования. Ниже приведен сам семинар.

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

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

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

Итак, начнем с описания видов тестирования. 


Функциональное тестирование


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

  • как написать тесты так, чтобы ими можно было пользоваться долго (даже после того, как напишут программу, которая будет несколько отличаться от ожиданий каждого человека из команды);
  • как написать тесты так, чтобы на их прохождение можно было тратить как можно меньше времени, при этом проверяя как можно больше. Сокращение времени на прохождение сценариев осуществляется за счет компоновки тестов таким образом, чтобы в процессе прохождения одних тестов происходила подготовка тестовой среды к прохождению других тестов;
  • как написать тесты так, чтобы они были понятны любому человеку, который будет их проходить. Ведь ни для кого не секрет, что в команде появляются новые люди, что не все понимают друг друга с полуслова... и так далее;
  • как написать тесты так, чтобы при тестировании мы попробовали все состояния системы. 
Вот показательный пример того, какими разнообразными могут быть сценарии тестирования (его часто рассказывают на семинарах, поэтому не могу вспомнить первоисточник): "Чего только не придумает пользователь! Вы думаете, что поле "возраст" всегда числовое? А вот и нет! :) Цифру можно написать и буквами. А что будет, если слово "восемьдесят" попытаться записать в базу в поле типа "int"? Конечно! Все сломается. Не говоря уже о том, что, изменяя размеры окна, можно крутить скролинг мыши, выделять при этом текст и еще пытаться его скопировать... Казалось бы, кому это нужно? Но пользователи в попытках как можно более полно использовать программный продукт иногда изобретают довольно оригинальные ситуации." 
как написать тесты так, чтобы в них потом не запутаться? Не секрет, что через 5 лет жизни проекта никто не вспомнит, кто писал кейс номер 1. Но если первоначально структура кейсов была выбрана правильно и она поддерживалась, то все будут знать, как этот кейс найти. 
Теперь перейдем к другим видам тестирования.

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

Тестирование пользовательского интерфейса


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

Тестирование удобства использования


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

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


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

Конфигурационное тестирование


После того как написаны функциональные тесты и определены планы по другим видам тестирования, начинается подготовка тестовой среды для конфигурационного тестирования
Для проведения конфигурационного тестирования необходимо подготовить операционные системы, в которых будет работать конечный пользователь. 
Также необходимо подготовить другое вспомогательное программное обеспечение: СУБД, драйвера, браузеры и другие возможные программы, с которыми будет взаимодействовать разрабатываемое приложение.
Конфигурационное тестирование проводится как для клиента, так и для сервера (если приложение клиент-серверное). 
Для конфигурационного тестирования существует проблема: зачастую невозможно проверить все конфигурации, с которыми будет работать пользователь. 
Первый метод ограничения количества конфигураций - выбор некоторого количества самых популярных. 
Второй метод: построение матрицы программного обеспечения (в заголовках связанные программные продукты располагают также по популярности) и тестирование только тех конфигураций, которые находятся на диагонали этой матрицы. 

Итак, настал момент, когда разработчики готовы отдать на проверку первую сборку! Когда первая сборка готова к тестированию, на ней проводят запланированные функциональные тесты, тесты UI, тесты безопасности и удобства использования по сценариям и свободно. В трекинговую систему вносятся найденные ошибки. 

Нефункциональное тестирование


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

Нагрузочное тестирование (англ. Load Testing) — определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству). 
"Если создаваемая нагрузка на систему превышает нормальные сценарии её использования с целью протестировать время отклика системы на высоких или пиковых нагрузках, такое тестирование называется стресс-тестированием. В этом случае нагрузка обычно столь высока, что предсказуема ошибочная работа системы, однако не существует четкой границы между тем, когда тестирование является нагрузочным и тем, когда оно становится стресс-тестированием." (с) Wiki 
Тем не менее, не стоит путать понятия "стресс-тестирование" и "нагрузочное тестирование", так как эти виды тестирования отвечают на разные бизнес-вопросы и используют различную методологию.

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

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

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


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

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


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

α-тестирование и β-тестирование

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

Итак, мы разобрали виды тестирования, необходимые для выпуска качественного программного продукта!
« Предыдущий
Следующий »

6 комментариев