Тестирование.Часть 1: не доверяй и проверяй.

Дисклеймер

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

Зачем оно надо

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

  • Не понимать ТЗ / документацию / плохо написанный legacy-код / родной язык
  • Сдавать проект за 10 минут до дедлайна
  • Кодить корные библиотеки с бодуна
  • Писать огромные функции со сложнейшей логикой
  • Быть индусом
Это изображение имеет пустой атрибут alt; его имя файла - 2oJdVtQhKSI.jpg
TO THE RICE FIELDS!

Из-за всех этих свойств пролиты уже литры слез, сожжены сотни стульев, сгорблены тысячи спин и высланы триллионы матерных баг-репортов. И именно с этим безобразием помогает справляться тестирование.

Что это вообще такое

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

Вот, например: «Тестирование — это одна из техник контроля качества, включающая в себя активности по планированию работ, проектированию тестов, выполнению этих тестов и анализу полученных результатов. А это значит, дружок-пирожок, что,прежде чем хвастаться своим кодом, наполовину стыренным позаимствованным с GitHub, тебе придется:

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

Здесь необходима важная ремарка: ТЕСТИРОВАНИЕ != ПОИСК ОШИБОК. Когда стремишься найти ошибки, ты лезешь в самые нестабильные, древние и никому не нужные куски кода, проверяешь в первую очередь самые нестандартные кейсы и после этого чувствуешь себя молодцом. Так вот, так не надо.

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

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

Уровни тестирования

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

Каждый когда-нибудь сядет на эту пирамидку

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

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

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

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

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

Принципы тестирования

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

  1. Тестирование может показать, что дефекты присутствуют, но не может доказать, что их нет.
  2. Полное тестирование с использованием всех комбинаций вводов и предусловий физически невыполнимо, за исключением тривиальных случаев.
  3. Начинать тестировать нужно как можно раньше.
  4. Тестируй там ,где баги страшнее и жирнее.
  5. Меняй тестовые сценарии.
  6. Меняй контекст тестов.
  7. Исправляй в первую очередь то,что важно для пользователя.

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

Возможно, Вам понравится:

guest
0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии
0
Оставьте комментарий! Напишите, что думаете по поводу статьи.x
()
x