Тестирование кода для чайников

Кому, зачем и как.
31 октября 2016326451Илья Бубнов3653032

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

Виды

Вот 5 основных видов тестирования и их краткие описания:

  1. Юнит-тесты – проверка работоспособности каждого отдельного блока вашего кода. Это самый понятный вид тестирования даже для начинающего пользователя, ведь здесь идёт учёт лишь тех процессов, которые исполняются исключительно внутри отдельно взятого участка кода. Например, создавая блок для ввода имени в форме регистрации, вас интересует лишь соответствие языка, отсутствие цифр и спецсимволов. Юнит-тесты часто используют TDD (Test-driven development) методологию для написания кода, где вы сначала создаёте методику проверки (собственно сам тестовый модуль) и только потом пишите исполняемый код.

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

  3. Приемочное тестирование – исполняемые процедуры для установления факта соответствия требованиям заказчика. Актуально в тех случаях, когда требования к коду и работающему приложению описаны заказчиком в ТЗ или в любой другой письменной форме. На основании этого создаётся либо сценарий, либо простой перебор отдельных значений, чтобы наглядно показать возможность выполнения поставленной задачи. В частном случае, это привычный нам demo-mode, демонстрирующий возможности ПО.

  4. Регрессионное тестирование – оценка работоспособности уже проверенного кода после внесения в него изменений. Актуально для динамических систем, где появление новых данных может реально повлиять на работоспособность всего кода. Логично, что для элементарного заполнения БД создавать регрессионное тестирование не имеет смысла, но для полноценного ПО в состоянии вечной доработки – вполне.

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

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

Необходимость

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

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

Литература

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

  1. The Art of Unit Testing, Рой Ошероув;

  2. Growing Object-Oriented Software Guided by Tests, Стив Фриман;

  3. Эффективная работа с унаследованным кодом, Майкл Физерс;

  4. tестирование dot COM, Роман Савин;

  5. Тестирование программного обеспечения, Святослава Куликова;

  6. How to Break Web Software, Джеймс Уиттакер

  7. Software Testing, Рон Паттон

  8. A Practitioner’s Guide to Software Test Design, Ли Коупленд

  9. Тестирование программного обеспечения, Сэм Канер

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

 

Популярные статьи

Новые комментарии